07.31.08
Posted in Agile, Iterative Development, Software Development, TDD at 7:24 pm by Pablosan
My latest TDD & Erlang article is up on CodeNotes: Atomic Tic-Tac-Toe. I know I’m favoring Erlang right now, and that’s because I’m simply having too much fun! I have several ideas, both for Java and Objective-C and I’ll get to them… hopefully soon. For now I’m trying to make the best of the momentum I have in learning Erlang: striking while the iron’s hot, as the old adage goes. This latest article starts getting into the good stuff, as it deals with atoms and tuples.
Additionally, I currently have Tic-Tac-Toe on the brain. I chose it for my first iPhone app, but the app keeps getting sidetracked as I dig into Test-Driving a Tic-Tac-Toe model. I am surprised at just how fascinating this coding problem is. Jeff Langr and I have paired on this problem in Java a couple times, and you can read a bit about that on his blog.
I’ve been trying to judge whether or not my coding example articles are sized appropriately: long enough to cover some ground, but not so long that they become hard to follow. Any feedback on that, or any other critiques of my meanderings is always appreciated.
Thanks for tuning in and I hope you enjoy the new article!
Permalink
07.27.08
Posted in Agile, Software Development, TDD at 10:04 am by Pablosan
Floating Atoms is my latest installment in the using-TDD-to-learn-Erlang thread over on CodeNotes. The original plan was to cover floating point numbers and atoms; because I thought either of those wouldn’t be enough to fill an article by themselves. Oops!
Writing this article taught me two significant things about Erlang: 1) as in pretty much any language, floating point numbers are trickier than they first appear, and 2) it’s pretty tough to talk about atoms without getting into tuples. So I did my best to cover floating point numbers well, and introduced the concept of atoms and tuples at the very end of the article.
Now I’m really looking forward to the next Erlang article. Digging into atoms and tuples means I’m starting to get into the “good stuff!”
Permalink
07.26.08
Posted in News at 2:34 pm by Pablosan
Okay, so it’s been nearly two-and-half years since Twitter made their big splash. Now that it’s a cultural phenomenon, it’s time to see if an old curmudgeon like me can keep up. My first problem is that someone already laid claim to my favorite nom de plume (how dare they!). So you can find me under the moniker TheRealPablosan. I honestly wasn’t thinking of TheRealAdam when I chose this, but it was probably rattling around in my subconscious, as I have been to a couple Dallas Ruby Brigade meetings and have met him. Ah, well…
My feed is public, so feel free to follow me if you’d like. I’m already following some of you. 
Permalink
07.23.08
Posted in Agile, Software Development, TDD at 8:04 pm by Pablosan
The more time I spend with Erlang, the more I like it. EUnit is pretty good too, though I already found a discrepency in the online documentation, which shows an assert macro named “assertEqual”. Static documentation misleads yet again! I finally did the smart thing and checked eunit.hrl only to find that, though there were many assertion macros defined, assertEqual was not one of them. There isn’t even an assertEquals.
There is, however, an assertMatch, which makes much more sense in Erlang. Erlang doesn’t generally test equality. It is much more common to perform pattern matching, which is exactly how the equals sign is defined.
Ah, well… sometimes pre-conceived notions can be misleading. At any rate, you can find my latest Erlang article, “Variables That Aren’t”, here.
Note: As of 9:00 PM CDT on 23 July, 2008 the documentation linked to above seems to be experiencing an error. In the interim it can be viewed in Google’s cache.
Permalink
07.22.08
Posted in Agile, Software Development, TDD at 7:54 pm by Pablosan
I’m working through Joe Armstrong’s Erlang book
, and I decided to add a bit more content to my Getting Started With EUnit article. This article covers the basics of using EUnit to Test-Drive Erlang development, but it also demonstrates the very important benefit of documenting your learning.
The first few exercises in the book bother me, because they are done completely in the console. The problem with this approach is that, as soon as you exit the console, all documentation of your session is lost. If you’re like me, it could be days before you get to your next learning session and a significant portion of your time will be spent remembering what you learned in the last session.
Since I’m using TDD, I have excellent documentation of my progress. When I get to my next learning session, it only takes me a couple minutes to remember where I left off, minimizing the amount of ramp-up required in every session. Saving time and effort: that’s always a good thing!
In my next TDD & Erlang article I’ll even use variables (Gasp)!
Permalink
07.18.08
Posted in Agile, Software Development, TDD at 11:05 am by Pablosan
I’ve hinted at this in a previous post. Practicing TDD turns writing code into solving a puzzle with an entertaining twist: I get to cheat! In fact, cheating is encouraged!
The rules of the TDD game go something like this: If the current set of tests let me get away with bad code and/or bad design, I must exploit that weakness. So I get to be the evil coder, writing nasty code. At first, it can be very difficult: we’ve been working so hard for so long to become good coders, it feels… dirty to solve things in a bad way. Not to worry – we’re going to fix it before the code gets checked in.
I know I’m letting my geekiness show, but when I’m approaching TDD this way, the silly, sometimes obnoxious solutions that the lack of comprehensive test coverage allow me to get away with become a funny joke… in a twisted, techie kind of way. I’ve laughed out loud at the nonsensical solutions I’ve dreamt up; and actually implemented… temporarily.
It’s an excellent game, because it fits the “Minutes to learn… Lifetime to master” rule. It’s an excellent approach to software engineering because:
- It keeps me focused on code design: by implementing a solution I know is bad, I am automatically asking myself “What is the right design?” and “How am I going to write a test to force me down that road?”
- It improves code coverage: because I allow myself to cheat, I am also forcing myself to add quality tests to my suite until I’m left with zero wiggle room.
- I know when I’m done: once my suite of tests have left me with one viable solution and all those tests are passing, I’m done!
The finishing touch in the TDD game is the end result: we end up with tight, well-designed production code as well as comprehensive test coverage. Oh… and we had a blast doing it!
Be careful, though, or you might find yourself saying “I can’t believe they pay me to do this!” It’s okay to think it: just don’t say it out loud!
Permalink
07.17.08
Posted in Agile, Software Development, TDD at 11:03 am by Pablosan
I have been teaching Test-Driven Development in the classroom for nearly a year now and I continue to be surprised by the high level of resistance to adopting the practice. I’ve started to formulate a theory as to why that is the case. TDD is a discipline, which puts it in the same category with exercise, walking the dog and eating your vegetables. That means most people will find excuses for why TDD doesn’t work for them:
- I can’t afford the time
- It’s just as effective to do Test-After
- I’m a developer: I write code, not tests
- The code I’m working on is untestable
- I don’t need tests: my code is perfect the first time
- I know I should; I just don’t
These may all sound like different arguments, but I’m becoming more convinced all the time that these arguments have the same root: I don’t want to. If I really want to do something, I will find a way to do it. If I don’t, I’ll find an excuse.
Not only is TDD a discipline; it is a strict discipline that encourages a very short cycle or tight loop: Test, Code, Refactor. It demands that I isolate my tasks: I don’t write production code or refactor when I’m in “test-mode”; I don’t write new tests or code when I’m in “refactor-mode”; and I don’t write tests or refactor when I’m in “coding-mode”. Additionally, I am forcing myself to take the smallest steps possible. When I’m in the Test Phase, I stop adding test code as soon as I have a failing test. The same is true when I’m in the Code Phase: I only write the absolute minimum amount of code required to get the currently failing test to pass.
TDD forces me to stop and think. It forces me to understand the problem before I try to solve it. And TDD, like any discipline, takes lots of practice. All of this makes TDD unpopular. Yet I have found that, with a bit of commitment and time, TDD actually makes coding a lot of fun. It feels good, much like the euphoria felt by a jogger after a long run.
So make the commitment to adopt the discipline of TDD. If you stick with it, I’m confident you’ll eventually be wondering why you didn’t start earlier!
Permalink
07.14.08
Posted in Agile, Software Development, TDD at 9:58 pm by Pablosan
I’ve been consistently tweaking my CodeNotes site as well as adding new content as I can. One of the articles that seemed to get a lot of traffic on my wiki was an introductory article on Erlang and EUnit. I have resurrected that article and you can find it here.
I look forward to adding new articles soon, keeping the forward momentum. Java, Ruby and Erlang are all on the list for future articles, but I may have to add one more language now that I have a new toy. Objective-C anyone?
Permalink
07.12.08
Posted in Apple, News at 9:36 am by Pablosan
I had it all planned out: instead of going to the Apple Store, I headed to the smaller AT&T store near my home yesterday (July 11th). I had planned to get there at 7:00, but it ended up being 7:20 and there was already a line wrapping around two corners of the building. Four hours later, I walked out of the store with the last black, 16GB iPhone 3G. Whew!
To paraphrase one of Bobby Shaftoe’s Haiku’s:
This is my iPhone
There are many like it but
This iPhone is mine
Permalink
07.10.08
Posted in Agile, Iterative Development, Software Development, TDD at 8:17 pm by Pablosan
Not long after completing the first KarateChop Kata article, I decided I didn’t like the fact that extra methods were needed in the production class. This was because I chose to use an anonymous inner class. Another possibility, and the one I demonstrate in my latest article, is to have the test class, KarateChopTest, inherit from the production class, KarateChop. This makes both the test and the production code a lot cleaner, but it does come at a cost. Of course, so did using an anonymous inner class.
I’ve decided to follow up these two articles with a Retrospective article, which will cover the pros and cons of these two approaches and may even touch on some other possible solutions. That may not come right away, though, as I am about to encounter a major diversion… more about that soon!
Oh yeah… and what do you think of that new, spiffier CodeNotes logo? Pretty… er, spiffy, eh?!
Permalink
« Previous entries Next Page » Next Page »
