http://www.perlmonks.org?node_id=506850


in reply to Re^3: What is YOUR Development Process?
in thread What is YOUR Development Process?

I do have multiple instances of my application on a server; each one runs for a specific customer on its own web server, using its own database and directory path.

If I were being awfully clever I could have one set of code and multiple sets of data .. but I don't have to be that clever. Yet.

I'm that clever now, and it seems to be a source of my problems :) It's a beautiful thing in terms of code-reuse, I can have a separate instance of the same base app with a different appearance just by changing a few meta-data lines and dropping in some changed templates (and usually only the navigation templates, the "functional" ones often don't change). However, the fact that any one "application" isn't a thing in and of itself seems to be the primary cause of my confusion.

Are you talking about a Class::DBI backend? I'm not even sure I know what that is. Can you explain?

Sorry, I guess that's in house lingo. Yes, that's Class::DBI. The application module just controls the state of the I/O and the templates. It's run-modes will call methods on some non-web-based module that does the actual work. It probably calls on Class::DBI interfaces to our databases, and those interfaces are, of course, modules. Respectively we call those application modules, the data modules, and the CDBI backends.

use a command line interface to check files out,

That's been the issue. With the designer not involved in the source control, he FTP files to the server for testing, and edits them on his box (a method _I'd_ find cumbersome, but he's content). He finds connecting to another box to make commits as a cumbersome step, and is fighting it. Since we've failed (from a technical/practical standpoint) at the last two tries to get him in the process, we don't have a strong basis to gain trust from him on this issue.

  • Comment on Re^4: What is YOUR Development Process?

Replies are listed 'Best First'.
Re^5: What is YOUR Development Process?
by talexb (Chancellor) on Nov 08, 2005 at 19:55 UTC
      That's been the issue. With the designer not involved in the source control, he FTP files to the server for testing, and edits them on his box (a method _I'd_ find cumbersome, but he's content). He finds connecting to another box to make commits as a cumbersome step, and is fighting it. Since we've failed (from a technical/practical standpoint) at the last two tries to get him in the process, we don't have a strong basis to gain trust from him on this issue.

    Whoa, Nelly!

    He's part of the project but he's not involved in the source control? Oops -- software sevelopment disaster in the making.

    Strongly recommend you push to get that changed, pronto. I can't imagine how impossibly difficult the job of running a Production system and developing software would become without a source control system.

    And I'll stop right there.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

[reply]
      He's part of the project but he's not involved in the source control? Oops -- software sevelopment disaster in the making.

      I'm in total agreement...which is why I'm trying to overhaul our development process, which involves posting to Perlmonks to see what other people do since lots of people work where they can't run the webserver on their personal machines, and have more than one worker on the project.

      So please don't stop the discussion...good answers are the only way to FIX my situation.

      However, to soothe your fears somewhat, he is IN the source control, just not well. (Bascially he bugs a programmer to commit his changes). It's a kludge, and annoying, and it will break sooner or later, which is why I'm trying to fix it.

[reply]

        we have the same problem in our shop. and we (the developer) end up committing those changes for the designer. what i'm planning to have is a small cgi script that has a textbox for commit message and a button. that script should commit the latest changes of the whole tree. (or modify some svn web frontend to interact with the working copy... hmmmm).

        teaching the designer to use that interface would be much easier than teaching her to use ssh

        i've tried tortoise svn, but the problem is that the designer need to work with a running version and the webapp runs on linux.

        Badai
[reply]
        It looks as if your *actual* problem is figuring how to motivate one employee to get in the version control loop. Allow me to suggest some possible motivation techniques:
        • Money talks
          • If you are management, or can get management's backing offer to hire an intern who's job it is to simply check his code in for 1/2 the intern's salary. (ie. he's giving up half the intern's salary out of his own salary).
          • If you aren't management, offer to check his code in for him at $15 per instance, payable before checkin.
        • If he's not going to check things in correctly anyway, make it a process. He FTP's the files to the test server, someone else tests his code, provides feedback and if successful, the tester checks in the code

        -Scott
[reply]
Re^5: What is YOUR Development Process?
by perrin (Chancellor) on Nov 08, 2005 at 20:16 UTC
    There are some nice GUI tools for Windows and Mac that handle CVS and SVN interaction. Your designer may not like it, but the downside of not doing it is pretty clear: your app will not work with the wrong version of the templates.
[reply]
      In particular Tortoise(CVS|SVN) are very usable Explorer integration programs. Nice little colored blobs on each file/folder icon to indicate the status and a right-click menu to do stuff.

      If they never used version control before, of course there is a slight threshold, but these tools are nice once you get the hang of that.

      /J

[reply]

In Section Meditations