Over the next few weeks I’m going to take the time and highlight a few of the projects that I’ve worked on in web development and any other technological area. I’m doing this so that employers that may be interested in my work can quickly see what I can do as well as my potential.
The first project I’m going to showcase is probably the biggest of all my projects, and quite possibly the most fun of all of them too: the 4-H Camp Control Center. This is the post that will explain in great detail the story behind this and how well it went. If you are more interested in only viewing the technical details of the project please check out this post.
A picture of the page used for logging into the 4-H System
Introduction
In the Fall of 2007 my mother was working with the 4-H Group in Martinsville and Henry County. There biggest task throughout the year was signing up children for their yearly summer camp. They have the largest registration of any group in Virginia(nearly 400 children) and their registration was held on a single day. The primary reason for being held on a single day was to allow for a fair method of “first come, first serve” mentality for sign ups as every year there are children who have to be denied due to limitations on spacing.
During a single registration there are typically 4 volunteers who sit at a table and take a set fee for camp registration in either check or money order. While doing this, they must fill out a receipt by hand and give it to the parent. They must keep a copy of the receipt so that after the typical 6 hour registration is over, they can verify how much money they have received and that all money is accounted for.
While the parents were waiting in line to pay for their child’s camp fees they were required to fill out a registration form which held all the childs pertinent information such as name, age, sex, but it also contained information regarding the child’s preferences for camp such as their roomate preference and the classes they wanted to take while at camp. Shortly after receiving their receipt this form was given to another volunteer that would place the paper in a stack which, at a later point would be entered manually into an excel sheet by one of the teenage volunteers. This sheet would typically then be passed around by a usb drive from person to person in the office as necessary and updated. If someone from the 4-H District Office needed information, this sheet would be formatted in the way that they requested and a copy would be sent to them.
A list of extra options including the excel sheets available in the system.
To put it lightly, this was a tedious system. Don’t get me wrong, data is not fun for anyone and that can’t be eliminated in most cases but it can definitely be improved. The system they were currently using had so many flaws that it was truly sad. To begin with, after a person had been receipted, if they wanted to receive a refund or if any of the staff wanted to verify a payment it required that the payment be tracked down, by hand, in a receipt book and verified. When the campers where entered into an excel sheet it did not allow easily for any sort of statistics or data manipulation. Also, the method of sharing the data was causing multiple issues due to multiple copies being on hand and some not being updated properly and data being lost. Simply put, they need a better solution.
The idea
At the time, I was a senior in college for web development. I knew most of the office staff that worked with 4-H and all were fairly “user” tech savvy but were not computer experts by any means and they didn’t really know what they needed or wanted. When my mom first approached me she was looking for something that would allow them to enter the receipts into an excel sheet all at once(4 users on the same sheet) and then print receipts out for each one individually. To be honest, at first I hesitated to even get involved due to my course load being heavy as it was and this sounded like something that would grow to a huge size and it would also be a completely volunteer effort, but in the end, I decided I wanted to see what I could do, so I jumped in head first.
After considering many solutions, some of which even included a basic Access setup to help them out, I came to the conclusion that a simple web application for entering receipts would be the most appropriate. The system would have a very simple form of authentication for the users to login. After logging in, the users would be given a very simple list of current receipts in the system or the ability to add more receipts. As they entered receipts, they would be able to list the receipts in whatever they preferred, modify them, delete them and eventually I wanted to add the ability to output the list in an excel sheet so that they could have it backed up in a form that they could use in the future if they ever decided to not use the web system.
I had been working with rails at this point for 3 months. I had dealt with PHP and perl before but after using a few tutorials in rails and kicking the tires a bit I decided that the best way to learn if rails was a good system or not would be to jump in and actually complete a project and so I did!
The Project Begins
The application started off just as requested, a simple CRUD(Create, Retrieve, Update, Delete) application. It used authentication for the logins and receipts were “owned” by the users who created them and each user had an image on file of their signature that would be shown on the receipt copy that would be given to parent. During this process I got excited about how quickly I update my work. I had this up and running in no time compared to what it would have taken me in php and I have even had some testing coding to back up my things! To put it lightly, I loved rails! At this point I got ambitious and decided that we should add other features before the big registration day in April and really speed up this process!
Now to back up just a bit and explain a few things. The rails development at the time was being done on my 12” Powerbook G4 1.33 ghz with 1.25mb of ram using Rails(pre 2.0 although I can’t be sure of the exact version at the time), MySQL and Textmate. I was using an old compaq 800mhz with 256mb of ram running Ubuntu Server to store my subversion repository. I was also using this server as the production server for use by the office(when it came to that point). After a lot of trial an error I finally had ironed out the process of using capistrano to deploy my application directly from SVN and was absolutely thrilled out how easy it was to develop, test and then deploy. I will be quite honest at this point and admit that my testing was lacking quite a bit but once again, I was just beginning.
The Plot Thickens
After deciding that the receipt entry was sufficient for use I decided to move onto the process of registering campers in the system was well. To begin with, this was also a simple CRUD step until we added in the fact that campers need to be associated with a “Pack”(somewhat like a team) which brought me into a many to one relationship and they also had to be put into classes which would force me to use a many to many relationship. At this point I considered that, due to the limited amount of time available, we should just set up each of these fields to just be a static value rather than having true associations. After all, previously they had no method of seeing how many children were in a pack or a class without sorting them appropriately and counting by hand, it wouldn’t be a huge problem if this was not a feature after my system came out.
Unfortunately, the programmer in me could not let this one happen. Having data be stored where it couldn’t be sorted and counted properly using database calls was just unacceptable so I had to research using many to many tables and also work on implement features so that the staff could easily add packs as well as classes to the system without much effort. This was not a light task by any means. This involved organization and planning. There was also another issue. The receipts could have multiple children attached to them but a camper registration was for a single camper. This made the task of pulling data directly from a receipt into a camper form a bit of a problem.
In the end, I decided that when you were viewing an individual receipt and see a child’s name and are interested in adding that child a registration form that it would automatically open the camper form and put that child’s details into the form so that you would not have to enter twice but there would also not be a direct link between the receipt and the camper because there were some students, such as scholarship students, who may not have a receipt attached to them. This is still a design decision that I’m debating on, but currently it is working.
A list of campers in 4-h system.
The day draws closer
After I had these features implemented and working I began to test all of them heavily. I had to find out what kind of verification of data I needed and exactly how to make all of this easier on the users. One of the first things I found out was that with the addition of campers, I needed to offer a few more options of excel sheets to be output so that when the district office or state office requested data be sent to them that it would be a simple button to grab an excel sheet for what was needed and send it up. This turned out to be one of the most valued features for the staff as it is not uncommon for them to be requested for this information multiple times in a week and usually it had to be compiled from multiple sources. With this method it was a simple 2 minutes to login, download the sheet and e-mail it to the appropriate resource.
Another feature that had never been considered by me before was the issue of accounting for the receipts in a single day. Though all the receipts were being stored and easily sorted and output to excel we had no way of knowing exactly how much money we had taken in for a given day or total. This was a simple addition of calculation the amount of money receipted either total or for a single day. This feature turned out to be a lifesaver on registration day as it would allow us to easily know the amount of money that we should have in checks and money orders.
After adding the last few touches to the features I decided to draw a line on features as the date was too close for any new features and I wanted to concentrate on fixing any possible bugs on the system. I’ll admit, I was terrified. My system was about to be bombarded by people who would rip it apart with multiple hits and entries. Only one of the four volunteers who would be entering data on the day of registration had even seen the system prior to using it so it had to be very easy to use as well as flawless in execution. I wasn’t sure how stable the system was and even more of a concern was how much of a performance hit it was on my poor little server. However after watching multiple requests come in during a controlled testing I had determined that my server could handle it and I thought the system was stable enough to handle four users and I’d be ok. This was when I got my last big shock…
ARE YOU CRAZY?
As we were prepping for the final days before registration, Brian, the head of the 4-H office proposed a scenario. The prior process required that after the day of registration someone enter all the registration information into the excel sheet by hand. The reason this was done the day after was that the number of applications coming in would exceed the workload for a single individual and because the file was only being shared by jump drive, having multiple people entering the data was not a great idea. Brian suggested that we should have 4 teen volunteers entering the camp registration data immediately as the form is turned in so that all the data input is done and over with on a single day. You have to be kidding me…
Now let me explain something here, this was my first big programming project that was going to actually be used in any manner other than for a professor to grade it. The idea that in addition to the 4 people who would be banging away on receipt entry, they now wanted another 4 people who have never seem my system and will have no prior training to also add registration information. The registration system was the newest and most definitely the least tested due to the fact that this would be entered by one person over a period of a few weeks so if there were small issues I could take care of them as they came up. This was definitely a shocking terrifying request, but the programmer in me assured myself that the code was ready to go and that my server could handle it so with much reluctance I gave the go ahead and setup user accounts for 4 trusted teens.
D-Day
On the morning of registration I was more frightened then I can ever remember being before. This was huge. My system, written entirely too fast and with not enough testing(in my mind there is never enough time or testing, no matter how much you spend on it) was going to be debuted in the most taxing situation possible. If my server died or my code failed I would be holding up approximately 400 parents and their children as well as the staff of the 4-H office. Heaven forbid a fatal error wipe out all my data and we lose all of what we’ve done.
I took precautionary measures. The system would automatically back the database up to an off site server every 15 minutes so that if something happened the most we could lose is 15 minutes. Unfortunately this done little to calm me but there was no time to freak out now, the process had began. At 8:00am we opened the doors, our receipt entry personnel took money and typed up numbers and our teens began entering classes and packs. I sat at my computer watching the log file go by, watching the processes on my server and praying to the Rails Gods to hold tight.
After about 30 minutes I began to relax some when I realized we hadn’t had any issues and I started to walk around and check out how things were going on a personal level. It was good! People were enjoying not having to write everything down by hand and everything seemed to be working well.
About 9:30am one of the teen volunteers came running to me with looking exhausted and said that I was needed at receipt entry. This was it. The server crashed, all my backups failed, my own personal hell had come to life! Lucky for me it was nothing that dramatic or even a problem. One of the people entering receipts was having an issue with entering a camper id number and the system had told her that the camper id number was already in use. They all insisted that this could not possibly be as the camper id numbers were in numerical order on the camp registration forms and none had been duplicated. I calmly agreed, assumed that there some small logic bug in my code and asked for 5 minutes while no one else entered a receipt. Just take a coffee break and I would let them know what we would do.
I walked over to my computer as calm as possible and started to pull up my code but I stopped myself. Before checking my code, let me just MAKE SURE that this wasn’t a human error. Surely it can’t be, but there’s never any harm in making sure. So I pulled up the receipts, about 100 had been entered so far, and I search for a camper id matching the one we were having issues with. Sure enough there it stood with another campers name on the receipt. I’m not sure I could have smiled more while I walked over and simply explained that a prior receipt had already been entered with this camper id and either someone had been given a duplicate number of there was a simple typing mistake that would need to be resolved. Within minutes we realized that it was simple typing mistake, updated the wrong entry and went along our merry way!
At around 10:45am I noticed that there were only a few parents left in line and began to inquire if we had a low turn out this year due to something else going on. Normally a registration takes at least 5 hours so for the line to be gone this quickly was unheard of. I pulled up the number of receipts we had handed out and realized that we had already receipted more than 350 parents and had more campers waiting to be admitted should someone drop out! The staff had completed their receipt entry at least 2 hours faster than what they normally do and this year they were also done entering registration also. To put it lightly, I was pumped. My system had completely outperformed my expectations as well as everyone else’s!
The Aftermath
Since that single day, I’ve made a few small changes to the system that we thought needed improving but nothing major. The office was so impressed that they recommended that we try and get the entire district to use it rather than just our office. I was excited about the idea as was the leader of the district but unfortunately due to budget cuts they could not afford to pay me for the development that would be required to expand it to multiple districts and the changes that each office would need based on their individual camps. They are still speaking with me about doing this in the future I would love to do it but for now, I’m only doing minor updates on the system and I’m preparing to see it in use again this year!
This project taught me more about programming than anything else. I was forced to work on a deadline, forced to work directly with customers to determine exactly what they wanted out of the system and what they actually needed from the system and I was put in a situation that demanded a lot from a system in a very short span of time. I have no doubt that this helped shape my impression of programming as well as the development process in general.
If you’re interested you can look at a more “technical” look at the project by checking out this post.
RSS
