Programming

Sep

2010

I Just Test-Drove My First Development

I’ve been hearing about the benefits of Test Driven Development (TDD) for awhile now, but have never taken the time to try it out with any of my own work.

That was until this past week.

The code that I work in with my job doesn’t really lend itself to TDD simply because it’s all straight-through procedural code. The few functions that do exist would only be able to be tested by checking the raw HTML that the emit against an expected result. It’s possible, but extremely tedious so we just avoid it completely.

Recently though, I had the opportunity to write some new code, a small module completely independent of any of our existing code. I decided to give TDD a shot and see how things went.

It took a bit to get PHPUnit up and running on my dev machine, but once I did things started to progress nicely. I stubbed out some of my initial functions and got my tests failing, it was pretty exciting in the way that playing with new tech usually is.

I’m by no means a TDD expert, but here’s some things I noticed with my experience so far:

I REALLY need to refresh my Object Oriented design skills, it’s been too long since I’ve used them
By doing just the minimum to make the tests ‘green’ I wrote far less code than I thought I would
My current code is far too coupled, I need to watch out for that because it’s hard to test
Once some tests are in place, refactoring is awesome, you know instantly if you broke something
TDD feels like another safety net above source control
Writing tests isn’t as hard as I thought
TDD is a completely different way of thinking about writing software

I’m pretty excited to continue on this path and fully explore what TDD can offer. I’m thinking some continuous integration and maybe, just maybe, some automated UI testing down the road. It’s a brave new world!

What’s your experience with TDD been like? Any tips PHP specific or not? Please just leave a comment below.

Mar

2010

After 10,000 of software development

At some point in recent history I hit a milestone and didn’t even realize it. It wasn’t a certain birthday (although next year is the big 3-0) or a 6 figure salary (sadly), but something a little more practical. The milestone I passed was 10,000 hours as a professional software developer. According to some it typically takes 10,000 hours of actively pursuing a skill before becoming successful at it. I don’t know if I can yet call myself a ‘successful’ developer, however recently I have come to a number of realizations that may be related to my 10,000 hours of experience. I’m not going to come up with 10 things just because it sounds good in a title, and I rather like the number 7, so lets see if I can put together 7 good realizations that can hopefully be useful to somebody.

Realization 1: The first production code I wrote was REALLY bad
It wasn’t exactly littered with GOTO statements, but the first thing I noticed when I went back to look at it was that it was really hard to read. My variables were all over the place, their names didn’t make any sense and the comments were essentially useless. Now that I have had Realization #5, I don’t write code like this anymore.

Realization 2: I really sucked at estimating how long things would take
I used to look at a problem and say ‘Ah, that’s pretty easy, it should only take a day or so’ (I still hear new people say this from time to time and cringe) However once I get into it, the time seems to melt away. I may get my original function up and running, however there’s certainly a bunch of edge cases I never thought of. Or, my favourite, the data I thought I had access to wasn’t actually available to a specific part of the code I’m working on, so I suddenly have to write a bunch of plumbing code. Perhaps the UI sucks once I see it working, or maybe I’ll be lucky and it’s just slow as hell.

Realization 3: A hack that works, in the end, still works
There’s doing it right, and there’s making it work. In the end, your customers don’t care how you do it, as long as you make it work. If it doesn’t work but it’s done right (which is possible by the way) then you wont have any customers so you’ll be screwed anyway. So, if you need a hack to fix something, go ahead, just note it in the comments and your bug tracking tool so that you can plan for it when you come back to refactor.

Realization 4: Deleting code is AWESOME
When I started programming, it was all about writing code, as fast as possible, so that I could see things moving forward. Now, my priorities have changed. I’ll look at some code and ask myself “Does this really need to be here?” The most exciting part of my day is when I get to hit the DELETE button on 100+ lines of code. Deleting code for me generally leads to more flexible software so that the next time I have to actually write some code, I often need less of it to get the job done.

Realization 5: Being able to read code is much more important than knowing how to write it, and reading code is harder than writing it
Let’s face it, unless there’s been a drastic development in cloning technology that I’ve managed to escape, there’s only one of you. There’s a LOT more of everybody else. You can be as efficient as you want, but you will NEVER be able to write more code than all of them. You don’t think the same as everybody else does, so you probably wont think about problems the same way others do. You NEED to be able to read someone else’s solution to a problem and understand what’s going on. If you don’t you’re very likely to introduce some pretty painful bugs into the system. I’ve been reading through Coders at Work and one of the primary skills each of the interviewees advocates is being able to read code. They’re way smarter and more experienced than I am so their advice is worth listening to.

Realization 6: Code doesn’t have to be perfect, more often then not it’s impossible
This is somewhat related to #3, but from a different perspective. It’s not worth it to hold on to code until you’ve convinced yourself that it’s perfect. Your users will tell you when it is perfect, so get your code out to them fast to get their feedback. If you’ve spent a month working on something and you feel it’s perfect, but your users have never seen it, you’re going to be a lot more apprehensive when you release it just because if they hate it you have just wasted a lot of time. I hate wasting time, it’s just not worth it. So, get your code out quick, get feedback, and iterate. It’s a bit of a cliche, but small course corrections are much less painful than large rewrites.

Realization 7: I feel like I know less now than I did when I started
I think this applies to any field, not just software development, but now that I have a bunch of experience at my back, my eyes have been opened to how much I DON’T know. When I started I felt that I was getting closer and closer to fully understanding what this is all about. Looking back that was incredibly nieve. Like an episode of LOST, each new thing I figure out exposes all these additional questions that I didn’t even realize existed. There’s just no way to know EVERYTHING. So don’t try.

While I started this post with a plan for 7 realizations, it’s not an exhaustive list, so if you have something you have realized with your experience, please let me know in the comments. Also, I’ve been writing this blog for awhile now, but I’m curious what others think of my writing, so feedback of that sort is greatly appreciated as well.

Jul

2009

Diving into iPhone development

After many long months of decision making and cash saving, I have finally decided to dive head first into the wonderfully complicated world of iPhone application development. It is something that I’ve had in the back of my mind since I first got my iPhone almost a year ago, but at the time with my wedding and everything I wasn’t in the market to get myself started.

The first step on this journey involved me purchasing my first Mac ever, the 13″ Aluminum MacBook. I was tempted to go with the Mac Mini instead, however for the money the MacBook just offered too many advantages.

I have to admit, after giving it an honest shot, I’m really starting to like how OS X does things. It definitely isn’t perfect but it is a refreshing change for somebody who has been looking at a Windows desktop for the last couple years. The mental workflow took some getting used to, though I’m now feeling nearly as comfortable on my Mac as I do on my Windows machine, with only a couple of exceptions that I don’t need to get into during this post. Maybe some other time.

So far I have really liked the Xcode development environment as well, like everything else on the Mac, it just takes some getting used to. Before you know it everything just makes sense. Even though I’m sure there’s a ton of stuff included in Xcode, it all sort of hides in the background instead of being right in my face and adding to the confusion. I was able to build and execute a simple iPhone simulator app very quickly without having to resort to a tutorial. I’ll admit that was a pretty exciting moment for me!

I still have an absolute TON of things that I need to learn before I start releasing stuff on the iTunes App store, but I’m going to do my best to document what I learn as I go. I’ll also try to point out any useful resources that I find along the way. I’m sure there will be plenty of surprises, it’s all very exciting!

Wish me luck! Hopefully I don’t suck at this…

Feb

2008

5 Things I wish I was taught in software school

It’s hard to believe, but it’s been 3 years since I graduated from Mohawk College’s Software Engineering Technology Program. That means that it has been 3 years where I’ve been able to reflect on what the program taught me, and some of the things that I wish I had learned. There are many things that I am happy that I now know, however I also feel that there were some key elements that were completely overlooked. I don’t want this to be a rant piece, that’s just not my style, I just feel that if I had graduated knowing about the following things I would have entered the professional world a much stronger developer.

1. How to use source control
This one is huge, everything I know about source control and version control systems I have had to teach myself since becoming a professional developer. I’m not saying that every software program should have an entire course dedicated to this, but at least knowing the basics would be nice since it’s so critical to the development process. Perhaps this is specific to the program that I went though, but when I graduated I had no idea what version control was, only that Visual Studio had something called Source Safe that I never bothered to install. Perhaps if it were a requirement for the larger final semester projects to be submitted through a source control tool, don’t even force students to use a specific tool, but use SOMETHING.

2. How to write secure code
When I was in school the web application world was still in it’s infancy so perhaps this isn’t as much of an issue now. Never once did I hear the term ‘SQL Injection’ or ‘Cross-site Scripting,’ but now they are serious issues, especially for developers working in web applications. The only parameter checking that we did were the ones that were enforced by the compiler/interpreter. We would never go so far as to verify that if your code expects a 4 digit number, a 6 digit parameter causes an error.

3. How to do automated testing
This is another big one, and in my situation as a PHP developer, one that I still don’t have figured out yet. We were taught that as long as our programs gave a specific set of output for a given set of inputs, it was correct. While the idea seems rational, our test inputs were more often than not insufficient to catch even the most glaring of errors (like the example in the previous section). Most software shops these days do some sort of automated testing so I think graduating school having never written a unit test puts us at a major disadvantage.

4. Agile development / Extreme Programming
I can’t completely blame them for this, but I think it’s important to mention anyway. The only SDLC that I was taught was the old-school waterfall processes. You know the one, design the entire system using a binder of varying diagrams covered with boxes of arrows, write code to make the boxes do stuff, test that it does what it’s supposed to do, then release it to the world at large. Fortunately for us, the software world is changing, people are starting to realize that software development is a more fluid process than building a bridge for example.

For anything large it’s nearly impossible to figure out every last detail without writing any code at all. This is where Agile/Extreme programming comes in, shorter release cycles, small increments or features between each release.

The other problem with the old methods, as I’ve learned from experience, is that most of the time customers don’t really know what they want to begin with, so how are you going to design it for them?

5. How to write modular software
This is another important one, most of us were taught to write our code as self-contained methods and/or classes. The idea was that it could be swapped out at some later date or extended with new functionality. This is totally fine, but what if you wanted to add functionality without having to change the base code? Not many of the developers I know were actually taught how to make their code extensible through add-ons or plugins.

I think it would be a great idea for students to have to write a base program with extensibility in mind. Later projects could modify it via plugins without touching the original base code.

I have a feeling that this topic wasn’t covered for two reasons, one being that the faculty assumed that all their students would be working on mainframes in banks. The other is that this sort of stuff isn’t exactly trivial code, from my limited knowledge of it anyway. I am still just at the beginning stages of this journey, walked through how systems like WordPress implement hooks in their API.

So there you have it
I’ve tried my best not to bitch too much. I think each of the 5 things I’ve mentioned are valuable tools for any software developer to have under their belts.

Please feel free to add to the list or let me know what you think through the comments.

Jan

2007

‘Synchronous AJAX’ or SJAX for Short

We had a problem at work the other day, we had a piece of JavaScript code that was making an AJAX style web server call, unfortunately other UI elements on the page required the results of that call to be available before the user attempts to use them. I tried searching the web for all sorts of things, ‘synchronous ajax,’ ‘ajax wait for response’ etc., leading to many explanations of the differences between asynchronous and synchronous requests, but no indication on how to do a synchronous request.

Finally, by looking through the JavaScript documentation for the XMLHttpRequest object and discovered that by simply adding an additional ‘false’ parameter to the normal http.open() call it forces the XMLHttpRequest object to run in synchronous mode. Exactly what we were looking for!

Here is an example: xmlhttp.open(“GET”, url, false);

This solved our problem completely, but since it was a difficult solution to find I figured I would post an example here in hopes of spreading the word of this useful tool.

Hope that helps!