Øredev 2013

The trip to Øredev is a long one, but worth it. This year, the Øredev conference proposed a theme celebrating the arts and technology. I wasn't sure what to expect heading toward Sweden, but I arrived tired yet open-minded. The first activity of the week was sleep, an attempt to catch up on a few hours of shut-eye after 14 hours of travel and a 7-hour timeshift. On the night of arrival, the first conference-organized activity I participated in was a Swedish cultural event involving sauna, the cold Baltic, and Swedish hospitality. The event took place at Kallbadhuset, a sauna/restaurant situated on a pier over the Baltic sea.

It was a cold and rainy night. When we arrived at the restaurant by bus, the rain and wind made the pre-sauna beer go down very nicely. There were a men's and a women's saunas, and the size of the group that showed up for the event that night was larger than they'd anticipated. They ran out of towels and I went to the sauna armed only with two sheets of paper towel to separate me from the baked cedar inside the sauna room. And it was hot in there. I stayed until I'd worked up a massive sweat and then headed out into the cold night to race down the long pier, the end of which descended into the frigid waters of the Baltic Sea. The transition from the hot sauna to the icy waters of the Baltic was stark. The immersion into that water brought out my barbaric yawp. I stayed in the water for nearly a minute, then rushed back across the pier to jump into the hot sauna for another round. The second dip in the Baltic wasn't as satisfying as the first and I declared the experience to be over for me.

After showering and dressing, I remember the open-air walk back to the restaurant from the sauna area being much more pleasant than what I'd experienced in the long, wet walk from the bus that brought us to the restaurant. The transitions from extreme heat to extreme cold had conditioned my body to find the center and be at peace with the conditions of the night.

They served a lovely meal and the conversations at the all the tables in the restaurant were lively. The experience of sitting naked in the sauna and testing our mettle in the cold waters had exposed a bit of the shared humanity that the conference was embracing with its arts theme. That night was a celebration of the feelings and the extremes our bodies are capable of withstanding. Connecting with that and each other is what the arts often enable, and, what I suspect the conference hoped we would experience.

The first keynote of the conference was given by Anna B. Scott (@doctoradancer). Anna is a dance professor who told a very poignant story about how a brain injury changed her life and robbed her of her mobility for a while. She described how technology came to the rescue to keep her connected to humanity, how she discovered a community of people whom she connected with despite not being able to move around very much. This story she told, about interface of the physical and the technological was delivered partly as a talk and partly through interpretive dance. Anna said that the arts are expressions of our humanity; they are what lead us out of the forests that we hide in. It was a gripping performance that set the tone for the conference: how do the people we are relate to each other via ideas and technology? What changes in how we can relate when our communication shifts from face-to-face interaction to words streaming across screens in front of us? Does technology disrupt us or do we disrupt each other by our use of technology? She was a brilliant choice as the opening keynote of the conference. I got a chance to speak to her afterwards and pass on how much her talk grabbed me.

There were many other talks at the conference that I found memorable. One was given by Douglas Crockford on RQ, a library for writing functional JavaScript that includes "monads, promises, and various flavors of FRP". Crockford said that event-based systems are inside-out inversion of control models, versus procedural architectures which are systems of dominoes. He also mentioned a JavaScript port of QuickCheck that he wrote called (JSCheck). I can't help but look at Crockford's disapproving avatar from his github page and assume that I am doing it wrong.

I saw a presentation on Scala and the Play framework by James Ward. What I saw made me think that Play still had a way to go before it would as enjoyable to write web applications in compared to Rails.

There was a presentation by Thomas Q. Brady about how great design pushes developers to connect users to a moment and to each other through technology. He recommended the movie, Jiro Dreams of Sushi, as a source of inspiration for pursuing mastery in the art form that is your calling.

Angela Harms gave a very personal talk on pairing and mindfulness. About showing up with your whole self and being present with your pair while thinking through a problem. Also about being open to ideas that you may not agree with for the purposes of exploration. She told a great story about pairing with someone and agreeing to go down a path she thought was wrong only to learn that it turned out to work. That sticking with your pair and being open to an alternative approach (even one that was counter to where you should be going) could lead to learning both for you and your pair. I really liked this idea.

Steve Klabnik gave a tour of through the history of Rails. How an environment that gave @dhh the freedom to create a framework that innovated away from practices that no one else was questioning. The time was right for a new way of organizing and writing web applications. In the last few years, the landscape has changed yet again. Rails is still alive but JavaScript has seen a massive resurgence and in the client and server space. Steve acknowledged this trend and made a point of saying that Rails makes a great API server for JavaScript web applications.

The talk that generated the most notes in my notebook was given by Fred George on Implementing Micro Service Architectures. Micro service architectures are systems where requestors and responders are completely decoupled and communicate via event messaging. The services that respond to event "requests" (though the events may be requests or they may just represent data known about something) are small (hence the 'micro' component of the architecture) and are meant to be replaceable/disposable at any time by some "better" form of the same or a similar service. Fred described a rule-of-thumb of no more than 100 lines per service. He also said that one of the benefits of this architecture is that it allowed rapid deployment and feedback about the efficacy of any service. As well, in adopting this architecture, his teams had abandoned the normal TDD (or unit testing in general) of the services themselves. That instead of writing automated tests for services that may be thrown away at any time, service monitoring became the means of bug/design feedback. In the talk, he didn't go into much detail about the monitoring and what (other than that a service was up and responding to events) was being monitored. There were many interesting ideas from this talk, lots more than what I've mentioned here. I recommend watching the talk and perhaps reaching out to Fred with questions. I asked several from the audience.

The coolest talk I saw was a live-coding demonstration by Bodil Stokke, wherein she created a CRUD site in Clojure for managing MLP-related data. Aside from being fantastically impressed by the coding feat, I took from the demo that Clojure a DSL for creating MLP websites.

I had the greatest meal of my life on this trip. It was at a curiously named restaurant called Bastard. It was a 5-course meal that consisted of meats, baked vegetables, fish, pickled spicy things, and perfectly paired wines. I don't remember what the dessert was because by then I was in a food coma. At several points in the evening, I had to cover my eyes and disengage from the dinner conversation because I was utterly overwhelmed by the experience the food was creating in my mouth and I just had to focus on that. The meal was crazy expensive. And worth it. If the conference was a celebration of the arts and technology, and the arts reflect our humanity, Bastard grabbed hold of my humanity from the inside of my mouth and reminded me how good it is to be alive.

Interface Segregation Principle in Ruby

I was recently asked whether Ruby had a way of honoring the Interface Segregation Principle (ISP). ISP says that a client of an API should only depend on the methods it needs/cares about. In languages like Java, ISP is easy to manage with static typing and judicious use of Interfaces. Ruby doesn't have the same thing, though. Consider the following example:

Let's say that you want to put the controls to fly and land a drone in the hands of someone with Secret clearance, but restrict access to operations like taking pictures and launching missiles to a client with a different security clearance. The problem with the Drone class is that the methods for doing all of the operations are visible to anyone with a reference to a Drone instance. ISP says that the lower-level clearance client should only be able to see a subset of all of the methods on a Drone instance. We can't control this on the instance itself very easily because the class is defined to expose all methods to anyone with a reference to an instance of it.

What you can do in Ruby is present access to an object via a proxy to it using the Forwardable module. In the example below, the Pilotable class tells Forwardable where to send invocations of the methods "take_off", "land", and "fly_to". Any other method invocation will blow up. An object of Pilotable class doesn't expose the reference to an aircraft it is wrapping, instead it simply provides a means of invoking a subset of its methods.

This is the essence of the Interface Segregation Principle: provide a client with an interface limited only to the methods needed in the context of the client's interaction.

Styles of handling conditional logic

TLDR: Raising & catching exceptions is a programming style. Designing functions/methods to always return a value to indicate success or error is a programming style. My preference is the latter, as I will explain below.

This post is a response to a Twitter discussion about the use of exceptions as an indicator of a condition that an API caller must either deal with or defer handling to logic at a higher level of a call stack. To read that discussion thread and all of its branches, you can start here.

In the case above, the get_user method communicates a condition where it is not able to return a user object by means of raising an error (RecordNotFoundError). Anything that calls this method can choose to call it and ignore the possible error case as is shown below:

Or it can wrap the call to get_user in a block that guards against the possibility of the call failing and handling that condition in a rescue block:

What should the code do in the rescue block? Whatever is appropriate given the requirements of the system. Frankly, it doesn't matter. The rescue block is a form of conditional logic branch. The logic of the branch above could be rewritten if, instead of blowing up, the call to get_user always returned something. But what? It could return nil (or whatever value represents "nothing" in your language of choice, if such a concept exists in the language). With this design, the calling code would have to test for whether the method returned a value or not.

Is this better? I think it is not better because the un-value value (nil) is being INTERPRETED by the calling code to mean something. The calling code must know that either a useful object will be returned, or else a reference to something that the calling code must make a decision about will be returned (nil). What is nil? In the style above, nil can mean whatever the API designer wants it to mean. At the same time, nil can mean whatever the caller to the API wants it to mean. It is a value open to interpretation, like a work of art. No right answers, and no wrong answers... And no useful information passed between caller and callee. At least with raised exceptions, the caller can have multiple rescue blocks each catching a different sort of error condition and responding in kind. In my opinion, though, it is better to be uniform and explicit about conditional behavior instead of expressing logic using a mixed set of language constructs.

So how is this accomplished? There's more than one way to do it. One approach is the Null Object pattern . This pattern introduces an object that is meant to behave like an "empty" instance of a type, one which has no real values. So given a type Product:

A variation of Product could be a PerishableProduct:

And for cases where some function or method may return a product or may fail to retrieve a product for some reason, a NullProduct may be returned instead so that calling code which wants to operate uniformly on all products to do something qualitative can get an object reference that will behave like a Product but does not actually represent one.

This approach is useful when the caller needs a usable reference to something but doesn't care what kind of thing it is. The caller relies on polymorphic behavior in whatever is returned in the call that yields either a "real" Product or a NullProduct. However, this is different from the original problem. One where calling an API either returns something useful or blows up, and this dichotomy requires the caller to use conditional logic to account for both sets of outcomes. An alternative to NullObject for more accurately representing the return of something usable or something to indicate a failure or error is the "Either" pattern.

Either is a wrapper object that can hold the "ideal" return value of a call or something that is informationally indicative of the failure to return the ideal value.

The Either is an ideal return value from an API along with whatever error indicator may have occurred in the course of creating (and therefore in lieu of) that value. Callers of a method or function that return an Either must ask the Either reference whether it has a real value or an error and behave appropriately. This turns the original example above into the following:

In this style, there is the same amount of conditional behavior as in the begin/rescue approach, but it is more explicit about handling the conditions. I prefer the clarity of this style. Languages (like Java) that distinguish between checked and unchecked exceptions (ones where the compiler either enforces explicit handling of method invocations that could result in a raised exception vs. ones where a RuntimeException may be thrown that the calling code can either handle or allow to leap up the call stack) put the responsibility of imposing the conditional logic via try/catch blocks in code that calls into an occasionally explosive method or function. For these kinds of languages, API designers have (in my opinion) too much influence over the coding style of the callers of their code with respect to handling success or error cases where their APIs are invoked.

I have been intentional in the use of the word "style" in this post. Expressing conditional logic via if/else, switch/case/when, try/catch/begin/rescue, or polymorphic semantics (depending on the language) is a matter of coding style and developer preference, that of the API designer. The outcome of each is effectively the same, a running program goes down one logical branch or another. Stylistically, I think code should be simple and prefer to use constructs like Either instead of designing APIs that may return something useful or blow-up.

I would like to thank Jessica Kerr for first introducing me to the Either style. It is not an uncommon approach for return values in the Scala world.

Ruby Immutability

Recently, I was thinking about immutability in Ruby and how (if I was so inclined) to design classes and objects that contained immutable state.  Ruby is such a flexible language.  It's submissive; the language bends to your will with a minimum of effort, and to great enjoyment.  I wondered how to design an object that I could initialize with some state and have the object just hold onto that state and make it available to me, but not let go of it.  And not allow the values I pass into its initialization to be changed.

Any reasonably experienced Ruby developer knows that all Ruby objects have a method #freeze that lets an object's state be frozen (restricted from external change).

For example, if I have a String:

s = "Heynow"
s.freeze
s.upcase! # [Kablooee]

Freezing the s String causes its internal state to be fixed such that any calls to a method that would result in an internal state change raise an exception. That solves my problem, right?

For some class of immutability problems in Ruby, that actually does what you want. If you don't "own" the object you are freezing, though, calling #freeze on any object whose state you fancy fixing in place is like painting your favorite colors on your best friend's bicycle; it may feel right, but that don't make it right.

For the case where I wanted to preserve the state of objects handed to my classes but allow my own classes to manage objects as they pleased (IOW, borrow my neighbor's shovel and not damage it while clearing the snow off my driveway), I would need an idiom for fixing some but not all state in an object of my design.

I came up with a trick for tucking away objects handed to my initializer in a place where it would be difficult for me (or anyone else) to tamper with them. The case I am solving is one where an object of my design is handed some other object that I may initially modify or just hold onto, but want to fix its state at a specific point. In the example below, I have a class that receives an email value and I need to make sure that the email I'm handed doesn't get changed by whoever asks me for it.

In this approach, the value handed into the Profile object is tucked into a lambda and set as a method in the instance. This sets aside the email object passed into the initializer so that no other instance methods can modify the value of the email parameter (as they would be able to if email was simply referred to via an @email instance variable name).

The trouble with this approach, though, is that the email value itself is mutable by whoever passed it into the initializer of the Profile class. This is preventable (if true immutability is important).

By duplicating the parameter passed into the initializer and freezing the copy, the object can safely tuck the value away in a lambda and sleep soundly, knowing that no code (internally or externally) will tinker with a value that should not be changed.

This isn't perfect immutability, though. You could still write code to replace the method on this object instance with a new method that returns a different value for email. Any code doing this, though, isn't operating via an accidental course, changing state on objects unintentionally. The lambda, and dup/freeze combination is a reasonable tradeoff for creating a form of immutability in a language that is designed to be as mutable as you want it to be.

New England Clam Chowder

(preparation time 40 minutes)

This is what you'll need for 4 servings (though Anna doubles the recipe):

• 4 slices bacon or salt pork
• 1/2 cup finely chopped onion
• 4 medium potatoes, peeled, diced
• 1 Tbsp. all-purpose flour
• 2 cans (6 oz. each) minced clams with liquid
• 1 cup bottled clam juice
• 1 cup half-and-half
• Salt and pepper to taste
• 1/2 cup whipping cream (optional)
• 2 Tbsp. finely chopped parsley (very optional)

Preparation:

1. In a large heave saucepan, sauté bacon or pork until brown and crisp. Remove. Drain on paper towels. Dice or crumble.
2. In same skillet, sauté chopped onion and potatoes for a couple of minutes. Sprinkle with flour.
3. Add clam juice from cans and from bottle. Stir to combine. Bring to a boil. Simmer, stirring from time to time, until potatoes are soft (about 15 minutes).
4. Add half-and-half and season to taste with salt and pepper.
5. Add minced clams. Heat until simmering. Do not boil. Add whipping cream, if used. Sprinkle with parsley or diced pork or bacon. Serve immediately.

Good served with croutons or small crackers, hearty bread and beer, red wine or beverage of your choice.

The Teacher

I was fortunate enough to help organize the Strange Loop 2011 conference, but this post is not specifically about that. During the conference, I had the privilege to talk to several of the speakers, and one stood out for me in a way I won't forget. Professor Gerald Sussman is the Panasonic Professor of Electrical Engineering at MIT and is perhaps best known (at least among the people that might read this blog) for inventing the Scheme programming language and co-writing Structure and Interpretation of Computer Programs (also known as "SICP" and the "Wizard Book"). Though this textbook is nearly 30 years old, it continues to be recommended reading for hackers who seek a deep understanding of computer programming.

During the conference, I had several occasions to speak with Professor Sussman about a great range of topics. Professor Sussman is fantastically knowledgeable about many things. If you ever get a chance to have a conversation with the man, I highly recommend dropping everything to do it. At one of the session breaks, I caught the Professor at a coffee station and asked him about something I had heard, which was that in addition to being an expert in electrical engineering he was also a watchmaker. He told me that he had received a Rolex watch as a gift after earning his doctorate (in 1973) and that at some point the watch needed to be cleaned. He sent the watch (which he still wears) to Rolex and noticed upon its return that they had been careless in cleaning it and had either smudged the inside of the crystal or damaged the watch face (I unfortunately don't recall exactly the detail of the blemish). His abundant curiosity lead him to taking it apart to fix the mistake made at the factory. This was apparently Professor Sussman's introduction to the fine art of watch making.

Since that time, the Professor has been pursuing experience in the art of watch making. He told me that he travels weekly to the shop of one of the few Master Watchmakers in Massachusetts (somewhere in Stoneham) to do work in exchange for guidance in an art that only a master watchmaker can provide. I couldn't get this story out of my head. Here I was, talking to one of the most revered computer scientists of our time and listening to him recount his own journey toward mastery in a field other than what has been his life's work. It was both humbling and inspiring to hear that the man still lives the life of a learner.

Dr. Sussman doesn't have a cell phone and he doesn't watch television. Free time is too valuable to him to waste on such things. He occupies himself pursuing new understanding and sharing his panoptic knowledge with his own students. This man is a nerd. He is a nerd's nerd. I might say he wears his nerd on his sleeve, but he wore short-sleeve shirts during the conference and instead wore his nerd where it belongs: on his shirt pocket. (Below is a pocket protector generously given to me by Julie Sussman, Professor Sussman's wife and co-conspirator in the pursuit of awesome).

As we were chatting casually, I mentioned that I have trouble getting more than five hours of sleep a night. He only smiled and said I was "winning" because it gave me more hours to be alive. This perspective reflects an attitude that recognizes how many things there are in the world to learn, and more than that to relish in understanding. It was one of the most inspiring, personal experiences that I can remember.

The lecture above was taken from MITWorld.

Thank you Scott Bale, for capturing the shot when Professor Sussman was teaching me a great lesson.

Test-Driven Learning (with Koans)

I wrote a piece on my employers tech article site about learning programming languages by fixing broken unit tests meant to expose little nuggets of wisdom. The article covers projects that provide programming exercises for 3 languages: Ruby, JavaScript and Clojure. Please read and let me know if you like it: http://sett.ociweb.com/sett/settJan2011.html

Strangeloop Day 2

Opening Talk: NoSQL in the Enterprise (Billy Newport)

Came in halfway through this talk but really enjoyed what I heard. The talk pointed out how NoSQL datastores aren't a clean replacement for relational databases and that their use must be considered carefully because of inherent complexities that come with schema-less distributed data storage. This talk was video taped, look for it online when the conf talks are published.

Next talk: JavaScript Functions (Scott Bale)

Scott went through a number of function invocation patterns that Douglas Crockford describes in his book, "JavaScript, the Good Parts". This talk was also video taped, look for it. I am in the process of reading the book this talk is based on at the moment and I recommend it for anyone who has an interest in JavaScript.

He discussed the use of constructor functions to restrict scope and access to data as well as using modules to apply a namespace to JS functions.

Next talk: Classes are a Premature optimization (Justin Love)

What many people think of as object-oriented programming seems to be class-oriented programming.

Class-based inheritance introduces complexities because classes are objects that have metaclasses.

Prototypal inheritance is simpler because there isn't a distinction between concepts like classes vs. objects. With a prototypal system, nested contexts form chains of connected functions, where type identity is traded for extensible, inheritable behavior.

The lunch hour had a panel discussion on NoSQL was well moderated by Ken Sipe, but the discussion left me wanting more. This was followed by a "dream team" panel discussion that included Douglas Crockford, Alex Payne, Guy Steele, Josh Bloch, Bruce Tate and was expertly moderated by Ted Neward.

This was an often spirited discussion that ranged from topics like what languages new aspiring developers should learn, to whether programming languages will ever form to help make parallel problems more easy to address and understand.

Perl got a lot of hate in the languages panel. Bad show, panelists!

Next talk: Android Squared (Bob Lee & Eric Burke)

Eric explained how the Square reader decodes the wave form from the magnetic stripe on a credit card. They have to deal with peculiarities from different mobile devices interfering with the wave form from swiping a card as well as variations like swipe speed and other factors.

He also talked about how having a large database of swipe samples (containing phony numbers) allows them to write tests to examine holes in their decoding algorithms.

Square has released an open source library for Android that contains some Android and Java extensions (I believe): http://github.com/square/retrofit

Bob went into detail about how square queues metrics and server communication data on the device until it connects with the server. He also explained the API he wrote for reading and writing efficiently into flash file sectors on Android.

The queue file API and a shake API are included in retrofit. Bob later described a REST API that the android client uses to make network data exchanges.

Bob also shoed a POS app he wrote for Taste St. Louis in 2 hours that used the POS square API available for Android 3rd party apps. Very impressive!

Next talk: Dimensional Data in a distributed hash table (Mike Malone)

He spent the beginning of his talk describing CAP theorem and how at his company, their needs were better served by availability instead of consistency. They have implemented a distributed hash table implemented on top of Cassandra. The major points of his talk were: Integrity vs. Availability, Locality vs. Distributability, and Reductionism vs. Emergence.

Sadly, this talk was totally over my head.

Next talk: Outside-in TDD in Clojure (Brian Marick)

Brian contrasted Detroit-style TDD vs. London-style TDD (bottom-up vs top-down approach to designing systems guided by tests). He then played a pre-recorded coding example that showed the progressive implementation of an animal reservation system he previously created in Ruby.

Along the way, we got to see the mocking framework he is working on: Midje. In the coding example, we saw test definition, test execution result, and the code under test all within the same editor pane. This was interesting because it means that the eye doesn't have to move around the length and width of the monitor.

He explained why working with his mocking framework lets the course of development slice the problem domain into layers that can be tested totally independently.

Final Keynote: Douglas Crockford brought down the house

Epilogue

Strangeloop was an example of a brilliantly thought-out and executed conference. There was an excellent mix of well-known experts and new comers offering highly technical insight for a price within most developers reach. I'd say this was a conference that developers could ill-afford to miss and I can't wait to see what Alex Miller follows-up with next year.

Strangeloop day 1 (part 2)

After a great lunch with Jeff Barsciezski, Luigi Montanez, and Yehuda Katz, I listened to a standing room only talk on civic hacking which covered many examples of companies that build up around serving public (government collected) data.

Next talk: mobile HTML 5 (Michael Galpin)

Mobile browsing is being done on many different platforms (iOS, Android, Blackberry).

Frameworks like PhoneGap & Titanium are powerful ways to create apps for mobile platforms, but aren't what HTML5 is about.

Viewport, Geolocation, DOM storage (local storage vs session storage) became the replacement for the original proposal for database storage on the device. Web workers, and many other aspects of HTML5 were covered.

Next talk: nodeJS (Ryan Dahl)

At the start of this, it seemed to be the same talk Ryan gave at jsconf. Then he went into live coding examples, demonstrating dns resolution and streaming command-line apps.

Eventually, he started talking about scaling node deployment strategies, which included having node running in multiple processes communicating with each other via unix file handles (letting the kernel handle load balancing rather than using an explicit load balancing component). He also talked about clients using webworkers acting as actors for interacting with asynchronous node servers.

During Q&A, a question was asked about how node compared to other async servers (erlang). According to Ryan, they are comparable, but he didn't have numbers he could show.

Keynote: Guy Steele

(programming while the earth was still cooling, everyone knew math and was apparently insane)

He gave a long and detailed analysis of the worst code he ever wrote (card programming from 40 years ago). This had lots of humor and maddening complexity. But he transitioned well into Fortress, the research language he is designing for parallel execution problems. Heady stuff. I needed beer afterwards.

Strangeloop talks day 1

Hilary Mason starts the day with a talk about machine learning and how the technology has evolved. Among the advances that have made machine learning accelerate:

• Algorithms
• On-demand (elastic) computing
• Access to large amounts of data

Analyzing large amounts of data to find either patterns or to identify data trends requires algorithms to disambiguate data that is contextually unrelated.

Data classification through statistical modeling based on characteristics.

And then she went into math and Bayesian probability.

Bitly trick:
http://bit.ly/3ert+ <-- add a plus to the end of a link to see realtime metrics about a link (statistics about clicks and where they are coming from over time).

Next talk: Riak (Rusty Klophaus @rklophaus) Dynamo-inspired NoSQL key-value datastore

Nosql is being driven by narcissism, voyeurism, and materialism :)

• Has same interface for single and multiple node deployment
• Configurable replication for buckets
• Data relationships can be defined for querying
• Replicates data across nodes as they are added to a cluster
• Supports map/reduce operations
• Can have HTTP interface to introduce caching and streaming
• Full-text search
• Riak is slower in virtualized environments.
• Multi-site replication is an enterprise feature

Upgrading instances doesn't support rolling upgrades, so non-multisite upgrades would mean bringing down the ring to change the software.

http://hg.basho.com

Next talk: supporting an open source community (Yahuda Katz)

Rails optimizes for developer happiness. The python community optimizes for explicitness. Focusing on happiness as a primary goal would draw developer attention faster than another more easily measurable metric. Performance or other kinds of optimizations can be attacked later.

Nothing beats adoption. Making your project easy to adopt (friendly licenses, support community) makes a big difference.

Business is good for the ecosystem; projects that allow independent businesses (training, consulting) to be built up around them will create the ecosystem that supports the viability of a project and the community involved in it.

Human beings underestimate the network effect.

MIT is a great license to promote a "network effect" for a project.

PDI (please do investigate): ask the community to fix a problem they care about and then incorporate the change if it makes sense for the larger community.

Market early with good propaganda.

Many, many other points (couldn't keep up). Outstanding talk! (Best talk of the day, actually.)

Watchr is teh awesome

Autotest spoiled me for immediate feedback during the development cycle. So as I was going through the Relevance functional koans for Clojure, I had a little Watchr script continually re-running the tests from the exercise at every file save. This is what that script looked like:

There's barely anything there. All it does is run the "run.sh" script that comes with the koans whenever a ".clj" file in anywhere under the "src/koans" directory is saved. It's just a simple little thing, but so very useful.

I later discovered a fork of those koans (from David Laing) that adds JavaScript lessons. So I adapted my watchr script to start the KoansRunner file in Safari, reload the test page, and scroll to the bottom on every save of the JavaScript files.

I can't say enough about the value of rapid feedback from automated tests during the learning/development cycle. The absence of context switching to manually rerun the tests is great WIN.

Clojure sequence comprehensions

I am learning Clojure and I like it. Following the ThinkRelevance functional koans has given me a really good interactive playground for learning this language. Reading through examples in a book cannot compare to actually having to write code in order to solve a problem and in the process learn syntax and the rules of a language. What a concept!

I came across something in the sequence comprehensions section that I thought was interesting.

The "for" macro can loop over one (or more) groups of things and produce the vector combinations above. I was reminded while reading this of Ruby's Array#product method, which does the same thing (return the product of 2 or more arrays).

Thoughts from Code Retreat - St. Louis

Yesterday was the St. Louis Code Retreat and I wanted to capture my experiences and observations. I hadn't heard of Game of Life before reading about Corey Haines' code retreats last year. My field of study in college was life sciences so I missed out on things like Conway's game of life that mathematicians and CS majors are probably exposed to. In prep for the event, I gave Game of Life a try for myself. It was a great experience! I felt totally sucked into the elegance and simplicity of the problem. But enough about that.

On organizing it

We were fortunate to have great sponsors. Microsoft provided the venue, a large space with ample capacity for the 40 people who were signed-up for the event. Oasis Digital funded the breakfast (fantastic pastries, fruit, and coffees) and Object Computing, Inc. (my employer) paid for the sumptuous buffet lunch from Mayuri.

The event was announced back in July and within a week of the free tickets becoming available, all were taken by eager developers from various technical backgrounds. However, of the 40 who signed up to attend, only 26 made it to the event. I had read accounts of previously held code retreats that warned to expect people signing up for the event but canceling at the last minute; given how hard it is to coordinate with a large group of people, this is not surprising. But to have only 65% attendance was, honestly, a disappointment. Given the size of the turn out, though, I was very happy with the range of technical interests among the folks that were there to learn, experiment, and enjoy programming.

Languages, Tools & Format

At the beginning of the day, I said a few words about how the day would be organized. We were to have 3 40-minute pair-programming sessions before lunch, with developers implementing the Game of Life problem in their preferred language or technology, and doing it test-first. Then switching pairs at the end of each session, deleting the last sessions effort and starting over.

The point of the event was practice. Through exploring new languages and experimenting with different approaches to a common problem, all those who made it that day would get a chance to improve on some skill they already had or work with someone who could teach them something they were interested in learning. Attendees took on the game of life problem using a number of different languages and tools.

• Eclipse
• Emacs
• IntelliJ IDEA
• TextMate
• Visual Studio

• C#
• Clojure
• F#
• Java
• JavaScript
• Objective-C
• Ruby
• SQL

A common reaction to the 40 minute time limit was that it was far too short to get a working implementation of Game of Life. The time constraint led to some sessions that scrapped testing altogether in the interests of getting a working implementation as quickly as possible. For others, it meant only being able to implement a partial, test-backed solution. Personally, I appreciated peering into the lightning-like minds of some of St. Louis' most talented software professionals. I liked what I saw in the clojure implementations that I watched and paired on and found myself inspired to take clojure on as my next language of study.

Organizing this event was a learning experience for me. Several people asked whether there would be another one next year. I really hope so ;-) It wasn't a crazy level of effort to organize (nothing on the scale of a major conference). I am curious whether I'd set the date for the event too far in the future and whether that was why there were so many people that cancelled their tickets. Next year, if the stars align like they did this year for venue and food sponsors, St. Louis will see another Code Retreat.

Interesting implementations

I have found a number of Game of Life implementations on the web that I think are pretty cool. Here are just a few.

• GoL using N-dimensional array
• GoL using JS & Web Workers
• GoL with JS & HTML5 canvas
• GoL attempts from the day
• Another code retreat attendee's work from the day
• An implementation from the day in SQL

module_function (where have you been all my life?)

I recently discovered a feature of Ruby that surprised me. Really, I was surprised that I hadn't heard of it before (for as long as I have been a fan of the language).

module_function can be used to make one or more Module methods accessible as type-scoped methods (in the same way that declaring them as self methods would). For example:

In this form, the methods of the module must be declared before the line containing module_function. You can pass one or more method names (as symbols) in the call. In fact, you can even re-write this as follows:

This form makes all methods declared after module_function behave as type-scoped functions (callable in the form of: Foo.bar or Foo::bar). You can "turn-off" the behavior of what is given type-scoped calling access by declaring a visibility modifier after the last method you want to expose in this way.

Now the Foo functions can be called either as type-scoped functions or Foo can be included in a class or added to an object.

One thing you now can't do, though, is refer to the module_function scoped methods as instance methods of classes or objects into which the Foo module is included. IOW, trying to call: Something.new.foo in the above sample code blows up with a warning about trying to access a 'private' scoped variable.

Regex riff (for words not containing a string)

I had the need to figure out how to parse a string and pull out any words that didn't contain "Foo" in them. After a lot of cursing, I came up with something that works. For the string "Which BarFoo Is It Foo Bar":

Yields: "Which", "Is", "It", "Bar"

Regular expressions are diabolical.

My dot-Autotest

Among the things that make me ga-ga for Ruby testing libraries is the ZenTest gem, which includes a super handy utility called 'autotest'. Autotest is meant to be run from the top of your project directory and it will search through your /test directory and run all test files it finds there (and report passes/failures on the console). My own development preference is writing specifications for my software using RSpec, which includes a tiny utility script called 'autospec' that enables 'autotest' to run anything it finds under the /spec directory of your project environment. As well, setting an environment variable called AUTOFEATURE=true tells autotest to search through your /features directory and run all your Cucumber features after file-system changes (this capability is added by Cucumber and not actually part of the ZenTest gem).

I have been running autospec nonstop as I tinker with a Sinatra app I have been writing. The normal behavior for autospec is that it runs all specs & features and then stops, watching the filesystem for any file changes that trigger it to run specs again. Recently, though, I noticed that the specs would start running and then go into an infinite loop of running and running and running... At first I thought that I'd updated a gem in the vendor directory of my Sinatra app that broke autospec somehow. After doing a lot of tinkering, I tracked it down to a Webrat log file that gets updated each time my Cucumber specs make it all the way through the login feature of my web app.

Autotest includes a configuration capability that lets you specify which file updates it should ignore (i.e. which files can be updated without triggering an execution of all the specs for your project). These exceptions can be declared in a .autotest file that needs to reside in the home directory of your development environment. I think I have covered all the bases for things that I want to keep from triggering my autospec runs. Here is what my file looks like:

The 'autotest/growl' require is so that I can see growl popups when my specs pass or fail. The gem for this is 'autotest-growl'.

UPDATE - 12/28/09: The 'autotest' script supports a '-v' flag which will cause it to report what file it saw changed to trigger your last test run. I only learned about this flag thanks to a comment on this original post by the great Ryan Davis.

Calculator Kata revisited

Just as a follow-on, I went back to the Calculator Kata and applied a functional Ruby approach with the rule of no mutable state allowed. I was inspired by Tom Stuart's Thinking Functionally in Ruby talk.

This time I create a reusable Proc for scanning the expression according to the regex that extracts [left_operand, operator, right_operand] arrays. I evaluate the expression with reduce, using the evaluation of the first equation in the expression as the initial value, and then applying that as the left hand side of all other equations in the expression. The drop(1) call removes the first element of the parsed expression so that the reduce call can operate on the second and all subsequent equations in the expression. Since the initial value passed to reduce is the evaluation of the first equation, the memo passed to all evaluations in the reduce block is the last evaluated result.

The above code passes the same spec as I included in the previous post

Strange Passions Confusion

A funny thing happened to me on Friday. I was scheduled to present at one of the Strange Passions events for the first Strange Loop conference. Earlier in the morning, I practiced a code kata I was planning on showing when it was my turn to present. The kata was an exercise I use when I do tech interviews of prospective candidates for developer positions at the consulting firm where I work. It calls for building a calculator that can parse a string expression and return the result of the expression as a string. This is an exercise that I have used for years, one that I have done many times in Java as well as in Ruby. The problem is ideal for observing test-first habits in programmers because it is a very easy problem for which to write tests.

When the time came for me to present, I gave a few minutes of introduction to the exercise and dove in. The first test took less than a minute to write, and I switched over to writing just enough to pass the first test. And then I froze. My mind went completely blank. This is an exercise that can be solved many different ways, and at that moment, in front of a decent crowd, I couldn't think of a single one. It was a totally unnerving experience. So I sat there for a minute or two, struggling to remember how I had solved this before. The audience grew impatient. I can only imagine that it was like watching a train wreck. Then, after what felt like an eternity, something unclogged in my brain and I started up again.

The next day, I thought a lot about it. I remembered that something similar happened to me on the night of my wedding. My wife and I took Tango lessons for 4 months prior to our wedding because we wanted our first dance to be a Tango. We had a routine that the dance instructor helped us work out and we practiced and practiced. On the night of the reception, the music started and I began the routine. Then, mid-way through, everything went blank. It was a two-part routine, and the lights went out in my head at the end of the first part. I panicked and led my wife through the first part of the moves we had practiced.

These lapses in memory to execute something that is almost second nature while in front of a crowd is generally thought of as stage fright. It may very well be that I have sporadic bouts of this phobia, and what happened Friday at Strange Loop was just another occurrence. I teach classes and had presented the day before at the conference, so it is not unusual for me to be presenting something in front of an audience. It was, however, disappointing to leave the crowd twiddling their thumbs while the wheels in my head spun for traction and I am unsure what to do to prevent this same episode from happening again.

I have written several variations of the calculator kata, that I present here to anyone interested in picking this up as an exercise for their own practice. The exercise is as follows: create a simple calculator that accepts a String arithmetic expression and returns the result of the expression, also as a String.

The Spec

Solution 1

This is the ugliest of the bunch. Split the expression at each space character, then add the parts of the expression into an array until there are 3 elements in the array, at which time I figure out which operator should be applied to the left and right sides of the expression, and then calculate and store the result as the left side of the expression to be evaluated next. On line 7, I am also adding a convenience method to the array to reduce some code duplication. This solution is readable but wordy.

Solution 2

This next approach greatly simplifies the strategy for calculating a binary expression. I still split on spaces and add each part of the expression string to an array, but instead of figuring out the operator for the expression, I take advantage of the operators existing as methods on the Fixnum class. This solution turns the left and right operands into integers, passing the right operand and the operator to the 'send' method of the left operand integer, and storing the result of the evaluation back in the parts array.

Solution 3

This one is a variation on Solution 2. Instead of splitting on spaces, I use a regular expression and capture groups to extract out the operands and operators for each part of the expression contained in the string. This solution still takes advantage of arithmetic operations existing as methods on the Fixnum class, so the difference from Solution 2 is primarily in the way that the parts of the expression are extracted.

Solution 4 -- Updated - 10/27/09

This final solution is defers to the Ruby interpreter to solve components of the equation. This approach can't simply rely on the Ruby interpreter to evaluate the entire expression because the arithmetic operators have different precedence order in Ruby. I use capture groups and positive lookahead (?=(\d+)) to get the three parts of the binary expression, thereby ensuring left-to-right expression evaluation (which is how I wanted the Calculator to work).

Special thanks to Michael Easter for pointing out the flaw in the original version of solution 4, which actually did just hand the expression over to the interpreter. I hadn't included a test that combined all four operators, which exposes the order precedence issue in Ruby. That has been remedied in the spec above.

Handy RubyMine feature - Open Current File in Browser

I just discovered a little feature in RubyMine that I think is very cool and useful. Editing a view file causes a little overlay to appear in the corner of the editor pane showing icons for Firefox, Safari, and Opera. Clicking any of these will open the currently edited file in the browser of your choosing (assuming you are working in development mode and have a server running).

Neat!

My Code Review Criteria

As a Scrum Master, I do code reviews. Recently, someone on my team asked whether what I look for in a code review was documented anywhere. This post is my starting point for documenting what I look for. I am hopeful that someone reading this may point out things that I haven't thought of that would be good to add to the list.

Backed by automated test
This should be self explanatory. No conditional logic or otherwise observable behavior should be added to the system without an automated test that confirms the predicable flow of the code.

Reinvents the Wheel
Does the code recreate some function that exists in a library included in the code base (or perhaps something from a utility library)? The chances of this are higher if you are reviewing code written by a developer new to the team. Does the code recreate a micro-framework or design pattern for which supporting types already exist and can be reused?

Doppelganger
Does the code contain logic duplication from elsewhere in the source file or from other files in the code base? Are there refactoring opportunities to extract code under review into a block reusable within the source file?

Maintains Harmony
Does the code under review look like it was written by the same hands as the rest of the code in the source file? In my mind, all source should read as if it was written by a single diligent developer, no matter the size of the team responsible for the system. That said, a projects' code style is an issue for teams to agree on internally and be ever vigilant for its application.

Says what it is / Says what it does
Are variables, constants, methods, and types descriptively named? Are any names inappropriately abbreviated or otherwise confusing?

Tell, don't ask
Classes and other types should accept their dependencies (through injection) rather than calling out for them (either via instantiation or other means). Accepting dependencies simplifies the ability to test code as well as change implementations of the types supplied at runtime. Does the code provide some means for external dependencies to be handed to the object? Are those external dependencies specified as interfaces or other non-concrete type declarations?

Too many notes
Are there any obvious opportunities for refactoring to simplify or reduce the size of the code under review? Does each method fit entirely within the view screen? The Single Responsibility Principle says that each type in a system should have one and only one reason to change. Are any methods, functions, or types written with multiple responsibilities?

Does it work?
Finally and most importantly, does running the system or related tests demonstrate that the code under review functions as expected?