Starting a new application from scratch is usually fun, but it also has some boring aspects. Here I write about some stuff I find rather boring, mostly because they give no visual feedback. The first units I coded and tested for my CRM application (a couple months ago), were:
- Database abstraction layer: I discovered the excellent ADODB library some years ago. ADODB supports an impressive number of databases. It is stable, used in many projects and most importantly I have successfully deployed large and small applications using ADODB, in the past. What I did, was create a simple layer on top of ADODB and use that throughout my application. This way I can replace ADODB in the future, if I need to, without much difficulty.
- Error handler: Using PHP’s set_error_handler() I route errors to a custom function. There I decide how to handle the error: whether to log the error, issue a warning to the user and continue or display an error message and halt execution. Obviously I use trigger_error() to… trigger errors.
- Session handler: I built a custom session handler, based on an article by Matt Wade. This gives me the following advantages:
- I can store session data in the database. So I don’t have to care about some php.ini settings (e.g. session.save_path) and I can store the user id associated with each session.
- I have better control over things like the “Remember me” (cookie_lifetime) and session garbage collector settings.
- I can allow/disallow simultaneous use of the same username. This will be part of the simplified copy protection scheme.
After these were in place, I developed the user login / logout procedures, so I could both test all three units and do something that gives a sense of progress (hey, I can login and logout! It’s almost done ;-).
Hey Dimitris, allow me to bask in some shamless self-promotion.
http://www.michaelsica.com/ataraxissoftware/2005/06/taking-step-back-defining-users-uses.htm
Please do your self a favor. Before you write another line of code, site down and start defining who will interact with your application. Write a story about how they will use the application, make a wireframe and a prototype (GUI mockups) BEFORE you write more code.
The coding is the easy part. You know how to program. What you need to know is WHAT are you programming. Don’t fall into the same trap I did of, “It’s all in my head. I know what I’m building. It’s what I’d want to use.”
Good luck man!
Comment by Michael Sica — June 21, 2005 @ 03:01
Ah! The link broke because I didn’t paste last character of the file. Correct link:
http://www.michaelsica.com/ataraxissoftware/2005/06/taking-step-back-defining-users-uses.html
Comment by Michael Sica — June 21, 2005 @ 03:02
Well, I guess it all depends on your school of thought. Although I don’t like extremes, I prefer this line of thought:
http://www.37signals.com/svn/archives/001050.php
over this:
http://www.joelonsoftware.com/articles/fog0000000036.html
(or your approach which is closer to the 2nd)
I have thought (and written) about who (and how) will use my application. I have documented what features will go in v1.0 and what will be left for later (and even this list changes often). But I can’t really commit to paper what I will be developing in say six months. I need to see things on screen, test them and often go back to the drawing board…
Comment by Dimitris Giannitsaros — June 21, 2005 @ 03:34
Hey buddy, I started to reply to your last comment but it got kind of long. Check out my latest blog post.
Please don’t take offense to my disagreement! I put it on my web site because I’ve been meaning to do a write up about prototypes, but I just haven’t been able to put it together. This little discussion really got my thoughts in order.
Keep working hard man!
Your fellow microISV-working-into-the-night-trying-to-live-his-dream-blog-guy,
-michael.
Comment by Michael Sica — June 21, 2005 @ 06:55
No problem at all!
Comment by Dimitris Giannitsaros — June 21, 2005 @ 11:08