About 13 months ago, I started working on a project to replace the software used by the local Operation Red-Nose (ORN) organization. Up until then, they had been using an old DOS-based system that was long past its best-before date. In fact, they were only using part of the system, and even that had major usability issues. The project was suggested by my supervisor at the MCF Practice Firm, a volunteer at ORN. The purpose of the project was for me to pick up some specific programming skills. At the time, I couldn't complete the project since I got a job offer five weeks into the program. But that job didn't last, and I was able to return to the ORN project. (During the summer, federal funding for the practice firms was withdrawn, and so MCF was forced to close.)
For the ORN project, I decided on CakePHP and MySQL. I chose PHP and MySQL since they are pretty much ubiquitous in the I.T. realm. For the framework, I quickly narrowed down the choices to CodeIgniter and CakePHP. I chose the latter since it strongly encouraged the use of an MVC design. The ORM also impressed me, with its ability to get all the data associated with a transaction in one operation (typically). That is, all the SQL joins were taken care of automatically.
In a nutshell, the ORN application manages many aspects of the operation, in particular, the event nights during the annual campaign. The system keeps track of volunteers. During an event night, volunteers are checked in to the system and assigned to teams. Operators take calls from clients and enter their ride requests into the system. The dispatcher assigns the requests to the available teams, and tracks the progress of the requests. And at the end of the evening, the treasurer tracks the donations.
An essential part of the development process was demonstrating the system to the ORN volunteers and getting feedback. After each weekly meeting, I'd normally have several pages of suggested improvements. The main issue was understanding how he volunteers would learn the capabilities of the system, which wasn't always easy for a programmer geek like me. As the programmer, I knew how to get things done. But for others, especially those with little computer experience, it wasn't always clear.
Add to that some language issues. ORN Kingston is managed through La Route du Savoir, an organization that provides training and services to French speaking people in the Kingston area. Although everyone at ORN speaks English, one person had a bit of trouble with some of the more technical language I used. Often, someone had to translate my technical language into a form that that person could understand, and her requirements into language I could understand. But we managed, and the result was a system that everyone was happy with, even if it took a few weeks after the start of the 2012 campaign to get all the required features in place and the defects fixed.
Is there more work to do on the new Kingston ORN system? Sure. The data entry form for the telephone operators can be improved. I took a few phone calls myself, and readily saw one problem with the layout of the entry fields. For the 2013 campaign, I'll rearrange the entry fields to reflect the order that questions are asked of the callers. That is, if the first question is "Where are you?", the pickup location should be the first item on the form. In general, that form should have a list of questions for the operators to ask to ensure that nothing is missed.
How did CakePHP work out? In retrospect, I think it was a perfectly reasonable choice. At no time was there anything that CakePHP couldn't handle. There was one annoying issue with session timeout. However, upgrading to version 2.2 addressed that problem. The upgrade didn't go without some effort, though. When I started the project, I didn't always follow the preferred naming convention. For version 2.2, I had to rename my controller classes.
What about MySQL? The application currently uses 16 tables, which is puny compared to other production systems. Although I prefer more robust DBMS's, I could clearly see how MySQL has matured over the past few decades. The InnoDB engine (now the default) is sufficiently robust for this type of application, supporting foreign keys and transactions, vital features in even the smallest of databases. In contrast, today in the year 2013, there are still production MySQL databases that use the old MyISAM engine. In my opinion, any database administrator who entrusts vital company data to a MyISAM database should be fired immediately.
If I were to start the project today from scratch, would I do things differently? Styles of programming for web applications are always changing. For the ORN project, I designed it as a fairly traditional server-based web application, with just a bit of client-side programming. But the trend is to move more processing to the client, with the view and controller components on the client and the model on the server. But for this type of application, I don't think I'd do things any differently.
Showing posts with label CakePHP. Show all posts
Showing posts with label CakePHP. Show all posts
Monday, February 11, 2013
Saturday, June 30, 2012
PHP - What Really Sucks About It?
PHP sucks. That's something I think a lot of programmers will agree on, even PHP programmers. For example, Jeff Atwood offers an interesting viewpoint in his blog entry The PHP Singularity. But heck, a lot of programming languages suck. And even though they suck, there are many millions of KLOC written in languages like COBOL, PL/I, and RPG.
Programming languages, like human languages, evolve. PHP started life as a web templating system, and evolved into a general-purpose programming language. During subsequent releases, new features have been added and some cruft deprecated. Other languages, like Perl and RPG have over the decades undergone similar transformations away from their original purposes.
Why is PHP so maligned? Perhaps because many of us have had to deal with PHP code written 10-15 years ago when the language lacked many of the nice features added in recent releases. Or PHP code written by programmers who knew better than the previous programmers on the project. Or PHP code written by programmers without extensive programming experience. 10-15 years ago, programmers who knew the risks associated with web programming typically chose other languages if they could.
When I started doing PHP programming, I started with PHP 5 and CakePHP. With Cake, you can't help but structure your application using a more or less proper MVC design. It's probably too much trouble not to. And so I know from personal experience that it is indeed possible to write relatively clean code using PHP. Unfortunately, we don't all have the luxury of working with clean PHP code.
What kind of programming shop typically uses PHP? I would guess the typical PHP shop evolved as follows: The shop started out small, perhaps as a one-person company. As the business grew, the demands on the custom PHP application grew as well. Other programmers were brought in, each with their own programming styles. Perhaps one of them was assigned the task of managing the others. But without any significant management experience, eventually the programming staff gets to the point of running from crisis to crisis as the code base gets harder and harder to maintain. Does that sound like your PHP experience? It's a sure-fire recipe for job stress and significant staff turnover.
Based on my own experience, the next time I'm interviewed for a programming position, PHP or otherwise, I would come armed with a bunch of questions, including:
Cheers! Hans
Programming languages, like human languages, evolve. PHP started life as a web templating system, and evolved into a general-purpose programming language. During subsequent releases, new features have been added and some cruft deprecated. Other languages, like Perl and RPG have over the decades undergone similar transformations away from their original purposes.
Why is PHP so maligned? Perhaps because many of us have had to deal with PHP code written 10-15 years ago when the language lacked many of the nice features added in recent releases. Or PHP code written by programmers who knew better than the previous programmers on the project. Or PHP code written by programmers without extensive programming experience. 10-15 years ago, programmers who knew the risks associated with web programming typically chose other languages if they could.
When I started doing PHP programming, I started with PHP 5 and CakePHP. With Cake, you can't help but structure your application using a more or less proper MVC design. It's probably too much trouble not to. And so I know from personal experience that it is indeed possible to write relatively clean code using PHP. Unfortunately, we don't all have the luxury of working with clean PHP code.
What kind of programming shop typically uses PHP? I would guess the typical PHP shop evolved as follows: The shop started out small, perhaps as a one-person company. As the business grew, the demands on the custom PHP application grew as well. Other programmers were brought in, each with their own programming styles. Perhaps one of them was assigned the task of managing the others. But without any significant management experience, eventually the programming staff gets to the point of running from crisis to crisis as the code base gets harder and harder to maintain. Does that sound like your PHP experience? It's a sure-fire recipe for job stress and significant staff turnover.
Based on my own experience, the next time I'm interviewed for a programming position, PHP or otherwise, I would come armed with a bunch of questions, including:
- Can I see your documents describing your development process?
- Can I see proof that the documented development process is followed?
- Would I be reporting to a manager with specific management experience?
Cheers! Hans
Friday, January 27, 2012
I'm Shopping For A New Ukulele!
A while ago, we decided to move from Toronto to Kingston. We sold our house in Toronto, bought a house in Kingston, and planned and implemented the move. The last step in the process was for me to find a job in Kingston. We knew that wasn't going to be easy. Kingston is a much smaller place, with less demand for programmers. As motivation, I decided that one of the things I would buy with my first paycheck would be a new ukulele. Well, I can now shop for that ukulele! I start my new job on Monday!
How did I get to this point? My "sabbatical" started getting a bit too long. So back in the Fall, I went to the KEYS Job Centre for advice. To start with, my councilor gave me some great advice on resume writing. She also recommended the MCF Kingston Practice Firm. What's a practice firm? It operates very much like a real company, allowing participants to gain real work experience, albeit without a salary. But in addition, participants are expected to spend time searching for jobs and learning the skills needed to look for work. I decided to give it a try.
I decided to concentrate on developing skills in PHP, since that's used by some local firms. I was assigned the task of developing a new software system for the local Operation Red-Nose organization to replace an old DOS-based application. I visited their operation on New Years Eve, and for what they were doing with that ancient program, they could just as easily be doing everything on paper.
To cut a longish story short, what I had implemented in five weeks using PHP and CakePHP, I had originally expected to spend most of my 12 week stint at MCF working on. Within weeks, I was able to confidently add PHP to my resume. I had expected to be at MCF longer. But an opportunity arose, I sent off my resume and cover letter, and I went for an interview and testing. I accepted an offer, and finished my stay at MCF after just those five weeks. Granted, there's still more work left to do on the ORN project. But I expect to finish that in my spare time.
What have I learned from this? First, that CakePHP is a great way to implement a web-based application. Some point out that it has a harder learning curve than other PHP frameworks. And sure, you need to understand why the framework insists on doing things a certain way. But having strong conventions is not a bad thing. In all, I think CakePHP was a good choice for that project.
Second, it helped me convince myself that the things I wrote in my resume were true. I can learn new skills. I got the skills. I know what I'm doing. I demonstrated that nicely with the ORN project. Sometimes it seems we can forget what we're capable of, and lose confidence in ourselves. Especially when between jobs.
In my previous job, I used Zope and Plone, but without ever really reaching the point of fully mastering those frameworks. I took that job because it offered me the chance to use my favorite programming language, Python. But while I still love that language, I would never recommend using Zope. We just could never get the Zope-based project to where we needed to be, partly due to the complexity of the framework, and also due to some nasty intermittent bugs. These were the kinds of bugs that you could never really be sure you fixed. And no one should have to depend on that kind of system.
(Fortunately, the Zope-based project was shelved. Unfortunately, development moved on to an ambitious .net based system, which is not really a good place to be for a Linux/Unix geek. Frankly, I was glad that moving to another city offered me a good excuse to quit that job.)
But now my new job beckons, and I'm really looking forward to it. From what I've seen so far, it seems like a really great place to work, and I know I can make a difference there. And soon, I expect to add a new ukulele to my modest collection. A banjo-ukulele perhaps?
Later, dudes!
How did I get to this point? My "sabbatical" started getting a bit too long. So back in the Fall, I went to the KEYS Job Centre for advice. To start with, my councilor gave me some great advice on resume writing. She also recommended the MCF Kingston Practice Firm. What's a practice firm? It operates very much like a real company, allowing participants to gain real work experience, albeit without a salary. But in addition, participants are expected to spend time searching for jobs and learning the skills needed to look for work. I decided to give it a try.
I decided to concentrate on developing skills in PHP, since that's used by some local firms. I was assigned the task of developing a new software system for the local Operation Red-Nose organization to replace an old DOS-based application. I visited their operation on New Years Eve, and for what they were doing with that ancient program, they could just as easily be doing everything on paper.
To cut a longish story short, what I had implemented in five weeks using PHP and CakePHP, I had originally expected to spend most of my 12 week stint at MCF working on. Within weeks, I was able to confidently add PHP to my resume. I had expected to be at MCF longer. But an opportunity arose, I sent off my resume and cover letter, and I went for an interview and testing. I accepted an offer, and finished my stay at MCF after just those five weeks. Granted, there's still more work left to do on the ORN project. But I expect to finish that in my spare time.
What have I learned from this? First, that CakePHP is a great way to implement a web-based application. Some point out that it has a harder learning curve than other PHP frameworks. And sure, you need to understand why the framework insists on doing things a certain way. But having strong conventions is not a bad thing. In all, I think CakePHP was a good choice for that project.
Second, it helped me convince myself that the things I wrote in my resume were true. I can learn new skills. I got the skills. I know what I'm doing. I demonstrated that nicely with the ORN project. Sometimes it seems we can forget what we're capable of, and lose confidence in ourselves. Especially when between jobs.
In my previous job, I used Zope and Plone, but without ever really reaching the point of fully mastering those frameworks. I took that job because it offered me the chance to use my favorite programming language, Python. But while I still love that language, I would never recommend using Zope. We just could never get the Zope-based project to where we needed to be, partly due to the complexity of the framework, and also due to some nasty intermittent bugs. These were the kinds of bugs that you could never really be sure you fixed. And no one should have to depend on that kind of system.
(Fortunately, the Zope-based project was shelved. Unfortunately, development moved on to an ambitious .net based system, which is not really a good place to be for a Linux/Unix geek. Frankly, I was glad that moving to another city offered me a good excuse to quit that job.)
But now my new job beckons, and I'm really looking forward to it. From what I've seen so far, it seems like a really great place to work, and I know I can make a difference there. And soon, I expect to add a new ukulele to my modest collection. A banjo-ukulele perhaps?
Later, dudes!
Subscribe to:
Posts (Atom)