I need your help here!

Posted by JP Tue, 31 Jul 2007 19:26:00 GMT

I'm looking for a web-based software project management and bug/issue tracking system.

Here's my basic requirements:

  • Multi-user
  • Basic project management
    • Milestone management
    • to-do lists
  • Bug/Issue tracking
  • Must have a built in wiki
  • Integration with Subversion is a plus!

I can't, for technical, install Trac easily on my shared hosting account. The setup is a PITA. So I'd like to use something else.

One last thing, it must be free, so stuff like Basecamp is not an option.

Any suggestions? What are you using? Out of curiosity, let me know if you're using Trac, even though it's unlikely that I'll be able to install it.

Thanks!

Posted in  | Tags , , , , , ,  | no comments

Good Web Application Development Practices

Posted by JP Tue, 22 May 2007 02:03:00 GMT

Or, how to decrease the probability that you shoot yourself in the foot.

Here's a checklist of things you might want to do early on during a web application. Doing these simple things will save you trouble, save time and help you put out a better quality product. The earlier you do them, the more time you'll save.

1 - Commit Source Code to Subversion

If you prefer another source-control system, use another one. The point is, use source control software. If you don't, bad things can and will happen.

Source control will help you:

  • Track regression bugs.
  • Remember what your code looked like before after you change your mind.
  • Bring other people on board. Having more than one person modify a code base without source-control is a surefire way to attract problems.
  • Document what you did and when you did it.
  • Undo errors. Yours or others'.

2 - Write Automated Tests

Automated tests are a key component of Quality Assurance. If you can't hire QA people because you're running a small operation, fine - but do the minimum.

Automated tests let you:

  • Find bugs as soon as they are created.
  • Know when you break an interface.
  • Find bugs before you deploy.
  • Find bugs before your client/co-workers/boss finds them for you.
  • Test your code in a relatively thorough fashion in a fraction of the time you would do it by hand.
  • Increase the quality of your projects constantly.

3 - Set up a staging environment

Sooner or later, you'll need to deploy things that can't be tested in a development environment: server configuration changes, database server upgrades, whatever. The only way to test this reliably is to do it using a staging environment.

While testing your deployment on the staging environment, take note of everything you do so the real deployment will be smooth. To be safe, you can even stage the deployment twice. The second time around, you'll be sure that you didn't forget anything.

A staging environment will help you

  • Deploy your software easily.
  • Test the deployment procedure itself somewhere else than your production environment.
  • Document changes done to the production environment.
  • Get up and running quicker should you need to restore your entire production environment.

4 - Automate your deployment procedure

Scripts are faster than you are and if they're set up properly, they don't make mistakes. If your scripts are intelligent enough, they let you undo the deployment. Write them to be what you want them to be. My advice on the subject is to do it good enough so you save time without going overboard.

Automating your deployment procedure will let you:

  • Minimize your application's downtime.
  • Deploy urgent fixes quickly. It happens.
  • Deploy more often by removing overhead. The easier it is, the more you'll do it. Your product will be incrementally better, faster.

5 - Fix problems as soon as they show up

Procrastinating is bad. Procrastinating bug fixes is especially bad. Fix problems while they are fresh in you mind. Don't wait two months to fix something that you could fix now. That way, you won't forget it, and it will take less time ot fix.

Out of lazyness, no bullet list for this item!

6 - Backup everything

On-site, and off-site. Your local machine and the servers. On site backups aren't enough: they won't protect-you against theft, fire, or whatever mother nature can cook up these days.

My friend's father who's a graphic designer used to backup his work on a Zip Drive. Too bad his backup disk was in his computer when it was stolen. Not only did he have to deal with the theft itself, but he had to redo a few weeks worth of work, with the ensuing consequences. Let's all learn something from this anecdote. I know I have.

Now, Business consultants charge four figures to walk into a conference room and tell you the same things I just told you with PowerPoint slides. One could say that they are crooks for doing so. One could also say that the return on investment will make up for that cost.

Maybe your project isn't there yet, fine, but as soon as a project becomes a source of revenue - or expenses, you want do be following these tips to make sure you're not burning your profits, potential revenue, or even worst, money out of your pocket.

The bottom line is that if you're not doing these things, you're lazy, but in a bad way. Lazing is an art. Do it well.

Please share any other ideas/suggestions you might have.

Posted in  | Tags , , , , , , ,  | no comments