As some of you may know, I started work on a development team about 90 days ago. This is the first time i have worked full time (on the clock, inside a building owned by the company, for 40 hours a week) in a long while. Things have changed somewhat since the last time I have done this: answers are now a google search away, and there is an incredible amount of useful and valuable free and open source development material out there. Yes, those are all different, but this time, I am working on a team. I am inside the same room with everyone, and have probably learned more about the art of development than I ever have. I thought i would take a few minutes just to solidify some of these ideas:
- Write tests first – This is not just a good idea, it’s the law. For the past few years, I have been very interested in test driven development, but have not put the time aside to learn it. Starting to work on my current project was trial by fire. I need to quickly learn to use the tools, and learn to think about tests correctly. Without getting too extensive, I can now say that I am finally a TDD convert. While my first few weeks (months?) at it seemed very much unnatural, it is finally starting to sink in. I will probably write more about this later, but suffice it to say that; in software development, as in life, satisfaction is much easier achieved when your expectations are clear.
- Coding standards are a good idea – I have worked on several teams where, after just a few weeks, you could tell who wrote a block of code just by looking at their style. I always thought this was just how the world worked. I thought this was just another way that we humans expressed our individuality. This actually makes code harder to read and messier for everyone involved. Memory and hard drive space are cheap. You don’t need to name a variable: tds, when total_dollars_spent is much easier to understand. Most modern IDE’s will do all the typing for you, which leads to another point:
- IDE’s are not evil – I have used emacs for a million years. I have never really used any IDE extensively in the past decade. In talking to old school developers, most will cringe and whine if they were told that they were required to use an IDE. I decided to approach the adventure of learning a new IDE as, well, an adventure. I could write a whole article on this, too, but suffice it to say that using an IDE (RubyMine in this case) made my productivity surge. Sure, you have to learn a few other keyboard shortcuts, but it took less than a few hours. Sure, there are things that textmate, emacs, et al do better, but no system is perfect. IDE’s have come a long way in the past decade. I won’t bust your chops for using one.
- Just because it works, doesn’t mean it’s submittable – If your code works, but it’s ugly and fragile, it’s sub par. You know that blob of code you wrote. it works. Even though it works, you pray that the day never comes where you have to edit it. When that day comes, it will drop like a house of cards. When you have this in your codebase, it is not acceptable. Fix it before you submit it.
- Refactoring is not a luxury, it’s your duty – There is always a balance. A project has to be done. It has to work, and it has to be delivered on time. That is still no excuse to submit code that has repeated itself or that is downright ugly. Again, you know what this code looks like. It’s that messy, twisted pile of shart that you are hoping nobody will stumble onto. Chances are, they won’t. If they do, they are gonna be pissed (if they have learned any of the above lessons anyway). So, refactor your code. It will make you a better developer.
- Developing really has nothing to do with language semantics – Anyone (within reason) can write code that works. Working is not that big of a deal. There is much more to learn than bending a language to your needs. Learning to model what is going on in the real world effectively and concisely is a much more important skill than anything else. Learning how to understand when someone explains the above, then explain your ideas to someone else is even more important. Noodling out complex ideas, then learning to model them and explain those models is the crux of the entire problem.
Okay, I have prattled long enough. I think in the next few weeks, I might expound more on each one of these points with some real world examples. Not snippets of code, but sight sights, smells, and flavors. A whole different world than I am used to. Rather than banging out code that works, learning to bang out code that is sexy.
My goal for the next few years? Learn to write code like a world class chef, rather than the grill jockey at the local burger joint.
We are getting very close to this world today, and unfortunately, I am seeing the weaknesses. In my pocket, I now carry a smart phone that can do all of the things mentioned above. Yes, my cell phone is straight from the bedroom of Elroy Jetson. So, why am I not satisfied? I think that there is still a good place for single purpose devices. I think I am falling back into love with these devices.
A few Examples?
The kitchen timer
I like to cook. I find that I am always needing to time something in the oven. The oven has a timer in it. You have to fiddle around to get it to work. The microwave has one, too, but when you set it, someone always resets it by putting something in there mid cooking. Wait! My smartphone has a timer app! Unfortunately, there is much fiddling around to get that to work.
Enter the humble kitchen timer. I need it to ring in an hour and a half. I set it, and forget it. I need to work in the garage for a bit? No problem, I can drag my timer out there. It never fails. It just rings when it’s done, and it’s totally portable.
Now, more than ever, the current time is a big deal. I seem to need to be somewhere (on time) several times a day. Yes, my smart phone can do this! All I have to do is: dig it out of my pocket (try that while driving), unlock it (i keep financial data on there), wait for it to fully wake up, and then, read the time.
With a wristwatch, I just need to turn my wrist and look at the face. In milliseconds and no fiddling, I know what time it is.
My phone can even be a GPS! It can route me where I need to go, and give me turn by turn directions. The only problem is, it KILLS the batteries, so i need to make sure I keep my charger with me. Every time I turn it on, it takes a few minutes to figure out where I am. When someone texts or the phone rings, my directions stop working. This is not very good when this happens as I am negotiating an upcoming offramp.
Enter my TomTom GPS. I just turn it on, select a destination, an go! It sits there, doing its thing without any other interaction from me.
My smart phone even has a camera! It has a video and a still camera! If i want to make a video or take a photo, all I have to do is: unlock my phone, wait for it to wake up, turn on the camera, wait for that to wake up, select the proper mode, and wait for the camera to be ready to shoot. Oh, and I have to make sure that everyone stays still long enough for the camera to actually take the photo.
I also carry a nikon point and shoot camera. When I want to take a photo, I just turn it on, and shoot! I don’t have to wait for anything to wake up and start up. It is a camera. It was made to take pictures, and that’s all. It does so brilliantly.
My phone can also pull all of my kindle books into it. I can even do this on my computer. They all sync, so I can keep my place wherever I go. Unfortunately, the same rules apply. I have to fire up the app, wait for it to start up, and then be subject to all the other distractions of a smart phone. Texts, emails, phone calls, etc. All of these take an incredible toll on my concentration and patience.
A Kindle device, on the other hand, just reads books. You can turn it on, and it’s exactly where you left off. It doesn’t try to remind you that life is out there, ready to assault your leisure time. It doesn’t try to send you messages from your peeps. It just reads books.
Am I Old Fashioned?
I think the jury is still out on that one. I think I am just growing weary of the endless fiddling that goes along with doing something as simple as timing a loaf of bread in the oven or taking a quick photo of something that is interesting.
What about you guys? have you grown weary of the fiddling yet?
This was actually an older project that I worked on when I was at Red Red Design. It was a HUGELY ambitious project, and as we worked on it, we found that it gave us a keen insight into some of the requirements of a content management system that you can’t learn from around the web. The idea behind the site was to provide a clearinghouse of not only information for upcoming graduates to find jobs, but potential employees to get a list of upcoming graduates in their department of interest.
It also served as a place for prospective students to learn more information about their educational pursuits, including the closest locations to take required courses.
The site provides an innovative system that allows users to quickly drill through courses of study and examine the requirements of each. This is followed by the generation of a map that pinpoints the location of each class requirement.
- Ruby on Rails – Of course this was a great candidate for rails. The backend required some (but not a ton) of ajax magic. The URLs were well defined, and most of the actions of the site consisted of manipulating scads of interrelated data. We used rails on this one so that we could quickly take advantage of the advanced scaffolding abilities of rails.
- RedCloth – Since there was a great deal of text to lay out, and on one REALLY uses html (do they?) to layout static text, we used textile to make text layout more sane.
- Git – Once again, a ton of people were going to be editing the code and assets. One day, I might write an article on why I have chosen git over the other SCM’s out there. I have used them all (except mercurial) and found that git makes source code management much more clean.
- Ajax(programming) – There is a great deal of data moving through the pipe, but not much need for UI updates on this site. This made it a great candidate for ajaxifying many of the UI elements. You really have to fiddle with the site to get a feel for what is going on.
- Google Maps API – There are lots of nifty tricks going on in this one. We found a list of lat/long points that defined the counties, so there is a county overlay on the map. There are custom markers. Once again, if you poke around on the file, there are surprises everywhere.
This idea began one morning when I was in the shower. I just wanted to find a bunch of places (possibly nearby) that could be good candidates for ghost hunts. Not that I am one of THOSE kind of folks. I just enjoy history and stories. Most all hauntings I have ever heard of are rich in both.
I worked with Carl and Maryanne Nestor on the design.
The site currently:
- Lets users sign up for an account and add their own sightings.
- Comment on the listings of others.
- Search by free form string.
- Built in Ad system. Allows a repository of Amazon ads to be served on the front page.
Some plans for the future:
- Allow users to sign in via facebook.
- Google Maps APIs – All of the mapping and geocoding of addresses uses the Google Maps API. The fact that this API is free for anyone to use is incredible.
- Ruby on Rails – I initially wanted to use Seaside to build the project, but the deadline was too close to mess too much with a technology I hadn’t done a full scale project in yet.
- Git – We used git to keep the CSS and HTML templates updated.
- Blueprint – There are too many bonuses to using blueprint to list. Most importantly, no fiddling with finicky CSS rules to get it to work across the different browsers.
We have recently launched the Catholic Athletics website for the guys over at The Saint Sebastian Fund.. The site serves as a clearinghouse for Catholic schools to list their current needs for athletic gear.
Once a need has been listed and approved (via several manual and automated checks), the project goes live, and users can make donations to the listing of their choice. Donations are made via paypal. When a project is fully funded, the school receives the funds and is able to purchase the equipment.
This project was a little different than most any of the projects I have recently worked on in that as it was a project for a non profit, a great deal of care went into developing the flow of the project status and associated legal issues.
It is currently alive and well and generating funds.
This site was developed using:
- Ruby on Rails – As there was an incredible amount of object data being held for donors, schools, and projects, we decided that an object based solution would need to be implements from inception.
- Git – All designs were implemented by Jeff Davidson. This meant that the CSS files and templates were scattered a bit. In pretty much all cases (even cases with a sole developer), we use Git to track revision changes for the site.
- Blueprint – when developing informational sites, it’s a very bad idea to rely on css rules to build the site. We always use a template system of some sort. We try to use blueprint when possible, as it’s quick and easy.
- Prototype – Yes, we are well aware of jQuery but the functions we needed were native to rails and prototype, so we decided against loading up another library. Should our needs expand in the future, we might decide to work with jQuery.
If you have any other questions or comments on the development of this site, we’d love to hear from you.