private int MyAwesomeFunction(int pVar)
{
// coding magic
return pVar++;
}

…where pVar = 10, the returned value will NOT be 11!  The returned value will still be 10.  If you want to return an incremented value for pVar, do the following:

private int MyAwesomeFunction(int pVar)
{
// coding magic
return ++pVar; // or return pVar+1;
}

Just a case of postfix vs prefix.  In the previous example, the variable never gets incremented because the postfix operator would get evaluated after the line is processed, but that never happens because we’re returning the pVar.  By flipping to a prefix operator, we guarantee that we evaluate the opperator against the variable before we return it.

It’s also worth mentioning that being a little verbose here is also good.  Explicitly stating that you’re adding 1 to the variable (as displayed in the commented code) is the same number of characters and we eliminate the confusion over what’s getting returned.

Happy Coding!

My message to you is: TDD takes less time, not more.

Today’s example: I’m writing some code that uses a parsing library written by a cow-orker. He’s a sharp guy, and the library generally works well, but it has a couple of undocumented behaviors – they’re mostly benign, and probably work for other users of the library, but for me it’s stuff that would result in misbehavior way up the call stack, or in another module entirely.

While I’m test-driving the code that uses this library, I notice the library itself does not have automated tests. The natural-feeling thing for me to do here is to test some sample calls to the lib to make sure it does what I expect. I know it’s not exactly canonical behavior to test outside libs that are assumed to be functioning, but it is good form to write tests that teach you about the system you’re building, and I needed to learn whether this library was going to parse my input in the way that I expected. The documentation wasn’t there, I wasn’t going to figure it out by inspecting the code (which is relatively complex), so tests it was.

Surprise, surprise – I found out that the library did NOT behave as I expected in every case. Had I not taken twenty minutes to write tests to introduce confidence in the parts of the system I didn’t know well, I’d probably have spent a couple hours debugging and looking in the wrong places for the problems I was having downstream. It also led me to a relatively simple solution where I extended the library class and just overrode the elements related to my handful of problematic cases, without changing his library or breaking code that depends on it.

As an added bonus, not only do I know what the documentation does not tell me, but I’ll also know if and when my colleague makes changes to his library that break the expectations of my code.

So I’ve reduced debugging time, increased my confidence in my code, and protected myself against future changes. I see it time and again – the time saved by writing the extra test code is well out of proportion to the time spent writing it.

There’s an exception here for developers or shops that are fetishistic about 100% test coverage, and do not judiciously use automated testing to learn about the system, drive design, and catch regressions. Writing tests to cover trivial/obvious code (i.e., writing tests that do not teach you about the system) is a time-suck. I’d avoid it, if I were you.

As long as I’m raving about TDD, I have to recommend the work of Kent Beck. I follow him on Twitter, I read his blog, and his book on TDD changed how I write software – I count it among the indispensible books on my shelf, with the GoF Design Patterns and Knuth. Check him out if you’re interested in deep thought about how software gets made.

1. You need to add your main application executable target as a direct dependency of the test target, so that you’re always testing against your latest build. Do this by double-clicking on the test target, going to the “General” pane in the properties dialog, and adding your app under “Direct Dependencies”. (This was actually mentioned in the OCUnit tutorial for Cocoa, but not the one about iPhone testing.)
2. Your linker needs to know about the objects you’re testing. An easy way to do this is to add the .m files for those classes to the “Compile Sources” group in your test target. You’ll also have to make sure you link against any frameworks used by these objects. (You could also tell your app target to export all symbols, then link your test target to it as you would a library.) (Thanks to Chris Hanson for pointing out this procedural improvement in comments.) You need to explicitly link the object files of the classes you’re testing. These are the “.o” files in your build folder. To do this: Double-click on the test target, go to the “General” pane, add a new item under “Linked Libraries”. In the dialog that pops up, choose “Add Other…” and add your class’s .o file.
3. When you run your tests, one failure looks like two: Failed tests show up in Xcode as errors (just like compile errors, &c). Any test failure triggers a second error, and you’ll see something like “Failed tests for architecture ‘i386′ (GC OFF)”. The docs never say so, but this appears to be normal. Fix the failing test, and it goes away.

Anything else to add? Drop us a comment!

This post assumes that you’re familiar with the fundamentals of iPhone programming, including view controllers, UINavigationController, and delegates. There is sample code for this post, which is released under version 2 of the WTFPL.

The Problem

I’m working on a multi-step UI for a game. Expressing these steps as a regular drill-down table-style UI on the iPhone felt cumbersome, and games can’t afford for processes to feel cumbersome; people will stop playing. One solution that occurred to me was batching related sets of steps in a smaller navigation table – so in Step 1 you’d drill through substeps 1A, 1B, and 1C before moving to Step 2. The fact that the whole view wouldn’t be replaced with every choice seemed like it would be less destructive of the user’s mental context, and the chunking of substeps should make it easier for the users to wrap their heads around the process. (No word yet on whether this solves my UI problem, but I like it so far.)

My UI solution contained its own technical problem, though: If I’m expressing the process steps in a UINavigationController, and expressing the substeps in a nested UINavigationController, how does the inner navigation controller notify the outer one that the user’s last substep choice completes that step and it’s time to move to the next step – or in programmatic terms, how does the inner UINavigationController tell the outer one to push a new view onto the outer one’s stack?

Or, putting it more visually, how do I get from here:

…to here:

In the non-nested situation when you wanted to push a new view onto a UINavigationController’s stack, you’d do the following in the current view:

[self.navigationController pushViewController:nextViewController animated:YES];

So in my nested case, I need to do that, but pushing onto the outer navigation controller’s stack from a view controller on the inner navigation controller’s stack. I tried a number of naive (but sensible-seeming) targets for the pushViewController:animated: action, such as:

self.navigationController.navigationController
self.navigationController.parentViewController.navigationController

Nothing worked. I set a breakpoint and drilled down through the members of self.navigationController, and no path to that outer UINavigationController was apparent.

The Solution

While investigating the innards of UINavigationController, I stumbled upon a writable property that looked like it might help: The delegate. When creating the inner UINavigationController, I added one line of code:

innerNavCntlr.delegate = self; // THIS IS THE MAGIC, PART 1

Keep in mind that this is called in the view controller on top of the outer navigation controller’s stack, so “self” has access to the outer navigation controller.

When the view on top of my inner navigation controller’s stack is ready to signal the outer navigation controller, I do the following:

// THIS IS THE MAGIC PART 2
UIViewController *topVC = (UIViewController *)self.navigationController.delegate;
[topVC.navigationController pushViewController:nextCntlr animated:YES];

A couple of notes: First, the view controller that creates the inner UINavigationController must implement UINavigationControllerDelegate, or you’ll get a compiler warning – but you can just declare that it does so in the header file, as none of the methods in that interface are required.

Secondly: If you’re like me, this feels like an abuse of the delegate property. Now there’s no reason that you couldn’t actually use that object productively as the inner navigation controller’s delegate – I just haven’t done so here. And the fact that the delegate property has to be casted to be used this way says to me that it wasn’t meant for this – explicit casts are always a code smell. (Anal-retentive types might want to put in some type-checking around that cast for safety.)

That said, it works, and I haven’t run into a maintainability problem yet, as this code doesn’t really get re-used in many places. Were I expecting to use this trick often, I might package up a subclass of UINavigationController (call it NestedNavigationController) that actually took an outer UIViewController or UINavigationController property. Then again I’m finding that in Cocoa, subclassing is often a code smell…

Got a better solution? I’m interested – please leave a comment below!

Update: Whoops. Comments are enabled now.

To play along at home, you’ll need your own Google Maps key or you can just aim your mobile browser to my example code at http://kickasslabs.com/examples/gmap_events.html. (Note that this will not work in a regular desktop browser.) Besides a <script> tag importing the GMaps JavaScript, you should not need any other libraries or tools besides Mobile Safari to view and use the example page. If the page is zoomed way out when you start, just double-tap the map tile in the upper-left corner – it should zoom to fill your viewport.

What you should see is a map tile with a line painted on it. If you touch the screen, you should see one end of the line follow your finger.

It looks simple but I had a bit of trouble getting it to work, because touch events are not like mouse events (curious as to why?), and GMaps doesn’t respond to touch events by default.

Step by Step

First, you need 2 divs:

    <!-- This div holds our map -->
    <div id="map" style="width: 320; height: 320px"></div>
 
    <!-- This div lies on top of the map and acts as an event proxy -->
    <div id="mapoverlay" style="height:320px; width: 320px; position: absolute;"></div>

And you need to position one div over the other:

    mapDiv = document.getElementById('map');
    mapOverlayDiv = document.getElementById('mapoverlay');
    mapOverlayDiv.style.top = (mapDiv.offsetTop + 0) + 'px';
    mapOverlayDiv.style.left = (mapDiv.offsetLeft + 0) + 'px';

You set up the map div like you would for any other GMaps-enabled page:

    // the map
    _map = new GMap2(document.getElementById("map"));
 
    // coordinates for home base
    _lat = 37;
    _lng = -95;
    mapCenter = new GLatLng(_lat, _lng);
    _map.setCenter(mapCenter, 15);

Set up the overlay div to respond to touch events by firing a custom event for your map, e.g.:

    mapOverlayDiv.ontouchstart = function(e) {
      GEvent.trigger(_map, 'customTouchStart',
        (e.touches[0].pageX - mapDiv.offsetLeft),
        (e.touches[0].pageY - mapDiv.offsetTop));
    }

Now have your map respond to that event:

    GEvent.addListener(_map, 'customTouchStart', mapTouchStart);

…where mapTouchStart is a callback function that does something useful in response to a touch:

    function mapTouchStart(xPixel, yPixel) {
      redrawLine(xPixel, yPixel);
    }

And… well, then you’re done. My example also responds to the touchMove event and has a little code for drawing lines, but you’ve seen all you need to know to get event proxying up and running for your app.

Got a question? Got working code for an easier way? Drop me a line in the comments!

Thing 1: FasterCSV is really cool!  It’s easy to use and does exactly what it should.  Here’s Scott Becker’s exporting tutorial.  For importing, i’ve hacked together bits from Peter Larkmund’s travels and the FasterCSV documentation.  Thanks to these tutorials, AMB will give users the ability to upload and export CSVs.

Thing 2: Default values for the win!  If you have a table that has a column for an amount, feel free to set the default value to 0.00.  Otherwise you won’t be able to do the following:

a = Account.new
a.amount += 20

…because a.amount will be nil.  You’ll throw an error and if you just updated a bunch of code, you might waste an hour trying to figure out why you’re throwing an exception.  However, if you declare a default value, you’ll be able to avoid any issues.

If you want me to go into further detail on either thing, just leave a comment.

Thanks for reading and happy hacking.

Reduce your feature list
When I first started AMB, I wanted to do a TON of things:

• Implement Calendar & tabular layouts for my transactions.
• Add AJAX sliders, like Kayak.com, which would allow users to view a range of transactions and dynamically update the sum of those transactions.
• Add Dynamic charts of data like Finance.Google.com where users could dynamically add tracked months to the chart to compare trends.
• Create a way to track my checking, savings, & credit cards as individual accounts with individual transactions.
• Create a way to track credit card payments or moves from checking/savings.
• Track an estimated balance & current balance for each month for each account.
• Create a way to display and create recurring transactions.

Yeah…while ambition is important, limits are also important.  Getting all of these things done for v1 is possible of an experienced web team, but as a sole developer trying to scratch an itch and learn something at the same time, it’s not realistic.  Implementing all of these features and fixing bugs would take way too much time.  I needed to remember the original mission of replacing my budgeting spreadsheet.  To help reorient myself with my goal, I took another look at my spreadsheet and compared it against my feature list.  I noticed the following:

• I only have a tabular view of my transactions.
• I don’t have any AJAX sliders.
• I don’t have any charts.
• I don’t track my credit card or savings balances in the spreadsheet.  In fact, 90% of the time I use my debit card so it’s really all coming out of checking anyway.  Once I put money into savings, I don’t touch it again.
• I do track my current monthly estimated and running balances for my checking account.
• I implement next month’s budget by copying the previous month and editing values/dates where necessary.

This really helped to put things in perspective.  V1 really needs to give me the ability to enter and track the transactions of 1 account without any sexy AJAX or Flash.  The 1 feature I did want to implement was recurring transactions, but I’ve worked around this limitation already and clearly it’s not critical for v1.

Do it the wrong way, but get something out
The beauty of web development is that it’s not like building a car.  Car manufactures deploy once a year.  Websites can be deployed and re-deployed every hour on the hour if we want.  Implementing new features and optimizing code is part of the fun.  As a newbie, you’re going to put code that should be in your model in your view or helper code in your controller.  It’s ok.  Getting yourself into the correct mind set for where code lives takes time.  For v1, if you can get the desired effect, call it a victory and move on.  If this project becomes something that you want to maintain and improve upon, you will.
Also, though test driven development (TDD) is ideal, feel free to get something out without it.  TDD is something that you can come back to if you’ve started without it.  HOWEVER, I’d advise that you stop yourself from advancing to v2 without creating a few REAL tests first.

No one will judge you harshly
Well, that’s not true.  There will be jerks to will give you a ton of crap for not having a “MUST HAVE” feature in your app and how you’re dumb for not implementing it first.  Honestly, F@#$ those people.  You have to realize that your first rails app isn’t about pleasing the world.  It’s about the realization of your idea and getting it out the door.  That’s not to say you shouldn’t listen to a good idea here or there, but don’t feel bad if everyone isn’t a fan.

That’s it.  Now get out there and get v1 f@#$ing done and enjoy your release!

In that same spirit, I took Lopex’s advice and turned on the –server flag; performance gain went from almost 2-to-1 to almost 3-to-1, with no other changes or optimizations.

Before:

[~/project/jrubytest/primes]> ruby ./primes.rb
FINDING first 100000 PRIMES
1299709
Time: 57.716853s
[~/project/jrubytest/primes]> jruby ./primes.rb
FINDING first 100000 PRIMES
1299709
Time: 33.885273s

After:

[~/project/jrubytest/primes]> ruby primes.rb
FINDING first 100000 PRIMES
1299709
Time: 57.204178s
[~/project/jrubytest/primes]> jruby --server primes.rb
FINDING first 100000 PRIMES
1299709
Time: 21.067204s

Thanks to the JRuby crew for stopping by here, and for being so helpful generally.

On the performance front, I did a quick-and-dirty test with a CPU-expensive script that finds prime numbers – not a real benchmark, but something to give me an idea of how JRuby held up under a steady load of basic math operations. Details follow.

Disclaimer: I know this is not the optimal algorithm for finding prime numbers. The point here is not to find prime numbers, but to tax my CPU predictably. If you post a comment with the general intent of HEY FINDING PRIMES UR DOIN IT WRONG, I’ll just delete it.

The CPU is an Intel Core Duo in an old Mac Mini. The Ruby and JRuby versions under consideration were:

[~/project/jrubytest/primes]> ruby -v ; jruby -v
ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-darwin8.9.1]
jruby 1.1.6 (ruby 1.8.6 patchlevel 114) (2008-12-17 rev 8388) [i386-java]

The code for the test was:

#!/usr/bin/env ruby
 
limit = (ARGV[0] || 100000).to_i
puts "FINDING first #{limit} PRIMES"
 
t0 = Time.now
primes = [2, 3]
counter = 2 # starting with 2 and 3
 
currnum = primes.last
while counter < limit
  currnum += 2
  primes.each do |p|
    break if (0 == (currnum % p)) and (p <= Math.sqrt(currnum.to_f))
    if p >= Math.sqrt(currnum.to_f)
      primes << currnum
      counter += 1
      break
    end
  end
end
 
puts primes.last
puts "Time: #{Time.now - t0}s"

The results showed just shy of a factor of 2 gain using JRuby (which is consistent with other tests I’ve run since writing this up):

[~/project/jrubytest/primes]> ruby ./primes.rb
FINDING first 100000 PRIMES
1299709
Time: 57.716853s
[~/project/jrubytest/primes]> jruby ./primes.rb
FINDING first 100000 PRIMES
1299709
Time: 33.885273s

These results were gotten after I’d made sure I had plenty of free RAM so I wasn’t I/O bound; the difference you’re seeing is all CPU. Note also that the timers are inside the Ruby code – they don’t account for JVM startup time.

Just for laughs, let’s see what the difference is with JVM overhead taken into account:

[~/project/jrubytest/primes]> date ; ruby ./primes.rb ; date ; jruby ./primes.rb ; date
Sun Feb 15 22:26:36 EST 2009
FINDING first 100000 PRIMES
1299709
Time: 54.065758s
Sun Feb 15 22:27:30 EST 2009
FINDING first 100000 PRIMES
1299709
Time: 34.427694s
Sun Feb 15 22:28:05 EST 2009

So startup overhead is about a second for JRuby. Not too shabby.

Part 2 of this post is going to cover some of the hairier tasks involved in:

• Subclassing Java classes and implementing Java interfaces.
• Packaging JRuby code in JARs with Rawr
• Calling code in those JARs from Java

More to come…

Hadoop is a framework (written in Java) that supports distributed computing – specifically Google’s MapReduce algorithm. It also comprises HDFS (the Hadoop Distrubuted File System), which allows you to redundantly store large quantities of data across multiple disconnected disks as if they were a single storage unit. I’ve used Hadoop at two jobs and at home, and it rocks.

It comes with a problem, though, which you may spot in the first paragraph: It’s written in Java. Now, don’t get me wrong – Java’s a great language. But developing software in Java with the most commonly used tools (Eclipse, Ant/Maven, &c) is a monumental pain (and you’re hearing this from an old Visual C++ hand). I’m the first to admit that I should shore up my skills with the Java tools, but even if I were better at it, getting a non-trivial Java project from zero to first runnable build is still about as complex as the invasion of Normandy, and the proliferation of XML config files is just inhumane.

Still, the performance and solidity of Java make it the right choice for a production Hadoop project. But what if you just want to kick around an idea or test an algorithm? Wouldn’t it be nice if you could do that in 2 hours instead of a day and a half? Wouldn’t it be nicer still if you could do it in your language of choice?

Hadoop Streaming has made me a very happy man. Any language that can take data from stdin and give it to stdout can be used to make Hadoop MapReduce jobs.

So of course, I’m doing mine in Ruby.

As an example, I’ll transliterate the trivial canonical Hadoop word counting example into Ruby. This example involves taking a large text, and counting the number of instances of each word it contains. The mapper takes in rows of text, and emits key-value pairs where the key is a word and the value is the number of times that word has occurred in a given row of text. It would look something like this:

word_count_mapper.rb:

#!/usr/bin/env ruby
 
STDIN.each_line do |line|
  word_count = {}
  line.split.each do |word|
    word_count[word] ||= 0
    word_count[word] += 1
  end
 
  word_count.each do |k,v|
    puts "#{k}\t#{v}"
  end
end

Already, we’re at our first non-trivial design decision, and it’s due to a significant design difference between Hadoop Streaming and regular Hadoop jobs: When you’re streaming, a single instance of your script will handle many pieces of input – it’s a bit like a filter-style Unix command (e.g., grep). A regular Hadoop mapping job is more firmly seated in the functional paradigm – each call to your mapper gets one line of data, with no knowledge of others. Because of this, some tutorials will suggest shortcuts such as keeping the hash-based accumulator outside the STDIN loop, and emitting all your rows of [word, count] pairs at the end of processing. There are advantages to this, but I’m going to stick with my code above, for two reasons:

1. If you maintain global state in your mapper, you’ll incur significant rework if you try to port the code to a more purely functional Java Hadoop mapper.
2. This could get damagingly memory-intensive on large data sets. Going functional and streaming everything straight to HDFS will add some storage cost, but for large jobs I’m much more worried about RAM than disk.

The purpose of the reduce step is to bring together all the per-line counts for each word, and reduce them to a single, global count per word. This is facilitated by the fact that Hadoop orders all the records by key before handing it to the reducer (where by default the key is everything before the first tab character – in this case, the word being counted.) My version of the reducer looks like this:

word_count_reducer.rb:

#!/usr/bin/env ruby
 
current_word = nil
current_count = 0
STDIN.each_line do |line|
  word, count = line.strip.split
  if word != current_word
    puts "#{current_word}\t#{current_count}" unless current_word.nil?
    current_word = word
    current_count = 0
  end
 
  current_count += count.to_i
end
 
puts "#{current_word}\t#{current_count}" unless current_word.nil?

The whole business with current_count is necessitated by another Hadoop Streaming-vs.-Hadoop quirk: In a regular Hadoop reducer, one call to the reducing function gets a collection of all rows associated with a particular key. When you’re streaming, you’re getting only one row at a time, but you’re guaranteed that the rows will be ordered on keys, and that the rows for a particular key will not be split up across reducer instances. Again, the temptation might be to place a single accumulator outside the main STDIN loop, but I’m going to stick with my strategy of lean runtime footprint and going straight to storage. The price for that is keeping track of which key you’re on.

I have placed the mapper and reducer in a folder called scripts in my $HADOOP_HOME folder. To run them against an existing file in HDFS, I do:

bin/hadoop jar contrib/streaming/hadoop-0.19.0-streaming.jar \
  -mapper scripts/word_count_mapper.rb -reducer scripts/word_count_reducer.rb \
  -file `pwd`/scripts/word_count_mapper.rb \
  -file `pwd`/scripts/word_count_reducer.rb \
  -input texts/my_text -output word_counts

…and results may be extracted from the word_counts folder in HDFS.

This is all there is to the trivial example. There’s more, of course – I’m currently using this technology to prototype a much more ambitious project that I will eventually port to Java (more on that later). While I’m finding that there is (at least subjectively) some performance overhead associated with streaming that I don’t see otherwise, it’s proving incredibly useful and speedy for testing out algorithms and designs.

Are you working with Hadoop Streaming? Do you have questions? Drop a line in the comments – I’d love to swap learnings.