A few months ago, I chose to return to operating Langr Software Solutions full-time, after over two-and-a-half years working for the startup Outpace Systems. (I’m still providing development work for them.) Along with that move comes a new site design, intended to update from a 2010-ish look to something a little more modern and responsive.

I’m thrilled with the artwork. Madeleine Einfalt of Artmmmporium provided the commissioned painting of Pikes Peak; I love it. I sketched an attendant “national parks sign” logo, and my sister Christine worked it up professionally and precisely.

Indeed there will be bugs, however. Please let me know of any you spot! Also, I will need to start working to ensure all blog content is moved across; this will take some time. I suspect all the old material can still be reached, however, using the old links.

Hmmm. Why is my article list not coming up, for example? Time to fix that!

I’ve been amiss at my writing for the past year-and-a-half while knee-deep in a startup. I wrote this post somewhere near the end of 2013, but never published it until now. I’ll be adding a follow-on soon. You’ll also have an opportunity to read more about this distributed development experience at PragPub in an upcoming issue.

---

For the past three months, I’ve been working as part of a startup (minus a few weeks’ worth of other customer engagements). I’ve found myself more often than not working with a new (to me) technology each new day. Here’s a list of some of the new elements:

• MacOS (my first day-to-day Mac!). Getting used to the keyboard differences, particularly Ctl-Option-Command stuff, has been the most challenging aspect of things, particularly since I’ve still had to switch off to Ubuntu/Windows machines throughout.
• Ruby. I thought this would be my chance to stop being a Ruby newbie, but we’ve moved on to something better:
• …Clojure. I’m excited to being picking this up, though it’s my first-day-to-day experience in a functional language. I’m feeling somewhat comfortable with basic language concepts after maybe 6 days of working on it, but of course I’m not anywhere near knowing how to do things the “right” way.
• Coffeescript. My web UI development experience has always been minimal. It’s kind of weird to be learning Coffeescript with only a shallow foundation in Javascript, thought Coffeescript seems like a nice clean approach (but you still need to peek under the covers at times).
• Angular, D3, _, and a few other odd Javascript libraries
• Emacs. Never really wanted to take this on (I prefer vim), but glad I’m learning it. Learning a whole new voluminous set of keymaps is pretty challenging!
• RubyMine, IntelliJ. It’s been several years since I did any heavy lifting in IntelliJ. Another set of keymaps to remember.
• Elasticsearch, Sinatra, Jasmine, RSpec, Minitest, numerous other Ruby gems, Nginx, guard, lineman, bootstrap, RabbitMQ, Kafka, Amazon EC2, and maybe a few other small things I’m not remembering. Lots of little tools, none on their own very large an undertaking.

There are a few familiar things, including Jenkins and vim. Altogether, it’s well over 20 new technologies in less than 50 days of work. All this while occasionally bouncing back to Windows, Visual Studio, C#, Fitnesse, and some C++ (to support the release of Modern C++ Programming with Test-Driven Development). I’ve regretfully had to put aside my ramping-up on Android development.

Even more challenging: Most of us work from home.

It’s insane, frustrating, and somehow exhilarating. These are all technologies I’m happy to learn, so it’s all good, but most days I feel fairly stupid. Of course I’m not anywhere near mastering any of the new technologies. Right now, we’re bouncing mostly between Clojure and Coffeescript/Angular, so I hope to master them in due time.

It shouldn’t work, but it does. Why? Everyone on the team is an accomplished programmer. We pair online through most of the day using Google Hangouts, and switch roughly daily (though sometimes every couple days, a bit long for my taste but it helps to have the time to immerse more on the unfamiliar stuff). We communicate frequently through the day via a persistent campfire chat, a morning business briefing, a morning dev planning session, and ad hoc hangouts as needed.

What’s not to like? Well, the pairing constantly sometimes gets old, and we’re pairing a little longer per day than I’d prefer. Bouncing around so frequently between technologies has been rough. And remote communication has its hiccoughs that detract from the experience. Ultimately, nothing is as good as being there.

However, our efforts have been very effective, even with most of the other programmers (about 10) not masters of most of these technologies either (many are intimate with Ruby). We’ve managed to make the customer happy with a quick first effort, and are well into incrementing on a second product.

I can’t imagine attempting something like this without pairing. We’ve had at least one candidate dismiss the opportunity because of pairing–“it can’t possibly be anything but a waste of time to have sharp programmers work together.” But they’re the ones who are missing out–it’s hyper-productive, rewarding, and has been the glue in keeping us from devolving into complete chaos.

After a couple failed attempts, I managed to successfully run com.example.mapdemo in an Android Virtual Device (AVD). It’s not tough, but required cobbling together instructions from a variety of sources.

The following instructions work for the ADT installed under Ubuntu, version linux-x86-20130522. I make no guarantee that these steps will work for you. It’s possible that some of the steps are extraneous.

1. Using the Android SDK Manager, install Google Play Services (v7).

2. Using the Android SDK Manager, install Google APIs (v3) (located under Android 4.2.2 (API 17)).

3. Using the Android Virtual Device Manager, create an AVD with a target of Android 4.2.2 – API Level 17. (I created mine with a 4.65″ 720p, not sure if that’s important.)

4. Start the AVD

5. Download two application package files (APKs):

   com.google.android.gms-(3.1.36).apk
   com.android.vending-4.1.6.apk

6. Install the APKs using adb (located in the ADT directory ./sdk/platform-tools):

   adb install com.android.vending-4.1.6.apk
   adb install com.google.android.gms-(3.1.36).apk

7. Restart the AVD

8. Copy ./sdk/extras/google/google_play_services/libproject/google-play-services_lib/ to your Android projects area.

9. Create a project for Google Play Services (projects needing to use Google Maps will need to depend on this):
   Import->Android->Existing Android Code Into Workspace.
   Navigate to ./sdk/extras/google/google_play_services/libproject and select google-play-services-lib.

10. Create a project for the map samples:
    Import->Android-Existing Android Code Into Workspace.
    Navigate to ./sdk/extras/google/google_play_services/samples and select the maps directory.

11. Create a Google Maps API key (note: these steps supposedly will not work for your production deployment):

    • Copy the SHA1 from your Android Debug keystore. Here’s the instructions I used under Ubuntu to display the contents of the keystore:

      keytool -list -v -keystore ~/.android/debug.keystore

      By default, the password for the keystore is android.

    • Go to https://code.google.com/apis/console and select API Access from the menu (to the left).

    • Click the button marked Create new Android Key….

    • Paste in your SHA1, append a semicolon, then append com.example.mapdemo

    • Click the Create button.

    • Copy the API key into the paste buffer (you will use it in the next step).

12. Configure the map sample project:

    • From the project’s build path settings, Add External JAR: ./sdk/extras/android/support/v4/android-support-v4.jar

    • Go to the Order and Export tab, and export android-support-v4.jar

    • Go to Properties->Android. In the Library section, add the google_play_services_lib project as a dependency. (You will need to open google-play-services_lib if it is not already.)

13. Edit AndroidManifest.xml to contain your API key: In MainActivityManifest.xml, ensure you have a meta-data element with something like the following:

     <meta-data android:name="com.google.android.maps.v2.API_KEY"
               android:value="AIzaSyCawgR4hVSiAzHIg4wJMbg7jvNyt-KZNgs"/>
    

    Substitute your API key for the android:value attribute. The meta-data element is a direct child of <application>.

14. Edit AndroidManifest.xml to contain appropriate permissions. For example (don’t forget to substitute your package name):

    <permission
            android:name="com.langrsoft.plangrok.permission.MAPS_RECEIVE"
            android:protectionLevel="signature" />
    
        <uses-permission android:name="com.langrsoft.plangrok.permission.MAPS_RECEIVE" />
    

Run it!

Here are some of the links I used to piece this together:

Google APIs Console
Install Google Play Services SDK
Sample code
Getting the Google Maps Android API
Getting the Google Maps API Key
Emil’s Design (a useful blog entry)

Please let me know if I missed any steps or if you discovered something else.

Your business doesn’t want to hear about how you “delivered stories.”

The business wants you to deliver value, in the form of what they most likely refer to as features.

A story should trigger a conversation around a feature request. Your software product doesn’t contain stories, it contains features that help users accomplish goals.

Wikipedia describes a user story as “one or more sentences” that capture a user’s needs. Those sentences represent a brief description or summary based on the planning and preparation so far, and they are reminders of the conversation that you must continue to have around the feature you will build. The sentences are not the feature. They aren’t even the full story, in most cases, as it often takes the requester several more oral sentences or even paragraphs to say what they really want.

Why Does This Matter?

If you think about stories as a simplified form of a requirements document (“a couple sentences”), you’re constraining agile to be a small tweak to how you did things before, with a trendier name. That diminishes the most important aspect of how agile can help you deliver software successfully: Through continual collaboration and oral communication. Without understanding of the importance of collaboration, stories end up being another waterfall-like hand-off document.

On another front: Too many teams waste time over the wording of a story. It’s a discussion point, not an artifact. The “standard” story template should help you clarify feature requests by asking you to think about who needs them and why. But otherwise spending time on precise word-smithing of a story writeup misses the point. You’re going to discuss it, and you can iron out any ambiguities as you do.

Stories provide only minimal value as an artifact. The ensuing discussion is where the details come out. Unfortunately, most of us can’t fully recall details from a conversation a half year prior, or even a half month prior. Granted, the details end up embodied in the software, but source code more often than not does a poor job of expressing such details concisely and simply. Even programmers must sometimes spend hours to determine just what the code does for the smallest of features.

We need a better artifact than the few sentences that represent a story. Many successful teams have found that the best way to capture system behaviors is in the form of acceptance tests, best derived by use of acceptance test-driven development (ATDD) or BDD. The acceptance tests supplant the nebulous conversation with real meat. A test’s name describes the goal it accomplishes, and its narrative provides an example that quickly relates the details of system behavior. The set of test names describes the complete set of designed system behaviors. The tests capture the important detail behind the discussion triggered by the story.

A story is not a feature, and it should always trigger a conversation.

More often than not, explicit for loops that execute n times usually need to know what what n is. Sometimes they don’t, in which case the for-loop structure seems mildly tedious. It’s certainly idiomatic, and you’ve seen ’em all a million times:

for (auto i = 0; i < 5; i++) {
   // code to repeat here
}

Still, having seen them all a million times, you’ve encountered many either accidental or purposeful variations:

for (auto i = 1; i < 5; i++) {
   // code to repeat here
}

for (auto i = 0; i <= 5; i++) {
   // code to repeat here
}

for (auto i = 5; i >= 0; i++) {
   // code to repeat here
}

for (auto i = 0; i < 5; i += 2) {
   // code to repeat here
}

The result: A for loop is something you must always pause to inspect. It’s too easy for your brain to miss one of these variants.

I’d much rather be able to simply send a timesRepeat message to an integer, as I can do in Smalltalk (Ruby has a similar message, times):

   5 timesRepeat: [ "code to repeat here" ]

In C++, overloading the multiplication operator would allow me to code something like:

   5 * [] { /* code to repeat here */ }

(The [] is the capture clause, which indicates that the following expression is a lambda, and also specifies how variables might be captured. In this case, the empty capture clause [] indicates that no variables are captured.)

A lambda function is of type function, therefore I can support the times-repeat expression with the following:

int operator*(int number, function<void (void)> func) {
   for (int i = 0; i < number; i++) func();
}

In other words, simply translate the lambda into the corresponding for loop, iterating number times, and calling func() each time, where number represents the receiver (5 in the example usage above).

A simple test demonstrates that the construct works:

unsigned int totalGlobal;

TEST(Lambdas, CanSupportedASimplifiedTimesRepeatLoop) {
   5 * [] { totalGlobal++; };

   ASSERT_THAT(totalGlobal, Eq(5));
}

(Use of the global variable totalGlobal allows writing the lambda expression without requiring variable capture.)

The resulting expression is succinct and even better than idiomatic, it’s obvious. I don’t think I’d go as far as to say that you should replace all for loops, just ones where access to the index is not required.

You could, of course. Here’s the result, a couple small tweaks to the first solution.

int operator*(int number, function<void (int)> func) {
   for (int i = 0; i < number; i++) func(i);
}

TEST(Lambdas, CanUnnecessarilyReplaceAForLoop) {
   unsigned int total{0};

   4 * [&] (int i) { total += i; };

   ASSERT_THAT(total, Eq(0 + 1 + 2 + 3));
}

The operator overload now simply passes the loop index i to the function being executed.

In the test, I now choose to use a local variable to capture the total. The capture clause of [&] indicates that any variable accessed by the lambda function is captured by reference. The function now also includes a parameter list, specifying in this case the index parameter of i.

I doubt I’d promote use of the second form (lambda with indexer) in production code. The first (times repeat) seems succinct and appropriate.