Daveblog5000

My Book's in Beta!

2011-10-25T00:00:00-04:00

Build Awesome Command-Line Applications in Ruby

Control your Computer, Simplify your Life

Woot!

My Book is in Beta! Whoohoo! It’s all about writing amazing command-line apps in Ruby. This isn’t about hacking together UNIX commands, or bash scripting…this is about making apps that are easy to learn, easy to use, easy to write, and that will delight their users. Seriously, stop making crappy command-line scripts, read my book, and start kicking ass.

It’s been a long time coming. Please stop now, and go check it out. I started this almost a year ago during PragProWriMo, where I wrote (almost) every single day in November of 2010. When I saw that Travis Swicegood (one of the few who made it all the way through) had gotten his manuscript accepted, I cleaned up a chapter and submitted and the Prags accepted!

I’ve spent my time since then writing, re-writing, re-organizing, and working hard to get this thing done. It’s in beta, meaning that you can buy the e-book and read the work in progress. It’s almost complete, just a few chapters to go, and by reading it in beta, you can give me valuable feedback to make the book even better.

Check it out now!

DC's New 52 Review

2011-10-21T00:00:00-04:00

I’ve always liked superhero stuff, but was never into comics as a kid. Reading Wikipedia summaries of the insanity that is the DC universe’s continuity makes me never want to touch the stuff. Now, it seems, they’ve thrown all of that out and started things fresh. Though it’s not a reboot. Whatever.

Having zero desire to locate, much less visit, my local comics store, the awesome Comixology app is my gateway to nerdom. I’ve used it to read a few short-run titles like Kick-Ass and Wanted, and they carry the DC titles. And, the New 52 titles are being released digitally at the same time as they are in print. Awesome. Nothing more annoying than downloading some 5 year old comic that just abruptly ends because they didn’t feel like digitizing all of it.

Based on what I know about the characters, and a few recommendations, I got the #1’s for several of the new titles:

Action Comics - Superman’s young and pissed, and Lex Luthor is out to get him. Love this one. And, I’m cool with his costume being jeans and a T-shirt.
All Star Western - Jonah Hex is a kick-ass dude in 1800s Gotham City. I like the vibe, but the story seemed a bit formulaic, and I’m not sure I care about yet another grumpy badass character. I’ll read #2 and see if it picks up.
Batman - YES. So very good. The first two issues deal with some shadowy assasins coming to Gotham and Batman is ready to kick some serious ass.
Batwoman - No clue who or what Batwoman is supposed to be. I bought the first two issues based on a recommendation and I probably won’t continue. Story is kinda boring and the character just doesn’t interest me. Plus, it seems the bad guys are stupid supernatural demons or something, and I just hate that stuff.
Catwoman - Dumb fun. This one’s been getting flak for it’s overt sexuality, but I love the idea of a character who’s in it for herself and not trying to be a hero. The scene in the second issue with Bruce acting like a drunken idiot while watching Selina’s every move is awesome. Definitely keep reading this one.
Detective Comics - I dont even remember what this one’s about. Batman plus blood-n-guts. I dunno. Wasn’t really into it, and Batman is just way better so far.
Justice League - Love it. The League hasn’t formed, no one knows each other or trusts each other and the government’s out to get all the heros. And Darkseid is sending bombs and dudes to Earth. Green Lantern: “You’re not just some guy in a bat costume are you?”. Ha!
Wonder Woman - REALLY boring. No idea what the story is, but there’s centaurs and Zeus and other boring shit I can’t stand.

The rest of the new 52 titles don’t look super interesting to me; I think a lot of the Justice League characters are kinda boring on their own, with Superman and Batman being the exception. The other “Bat family” titles look OK, but I’m pretty happy with what I’ve got for the time being.

The only thing I don’t get how all this fits together; Batman’s in three of the titles I’m reading, and so is it the same guy at different points, or totally different stories that are timeless or what? Ah well.

Curation FTW and the End of References

2011-08-07T00:00:00-04:00

Museums aren’t the only things curated anymore - now, everything is!

If there were a “trending word” of the decade leading up to this one, it would be “curated”. Although I’d heard the word before its launch, the iOS App Store certainly brought it to the forefront of everyone interested in technology.

However, it’s a concept that’s been around forever. I posted this picture on Instagram a few months ago titled “A study in usability”:

This is a device my wife got from her dad that allows you to “look up” the recipe for about 80 different cocktails. You find the one you want on the front, and turn a dial, which reveals the recipe in the small window in the center. Old school and retro, it adds some nostalgia to our home bar setup.

Compare this to a book of cocktail recipes I’ve had for quite sometime:

It has hundreds, if not thousands of cocktail recipes. It is, in every way, far superior to the Bar Aid, right? It has more recipes, it has several indeces, and it has plenty of space to describe how to make the cocktail in question.

The Bar Aid is actualy much more usable, and gets a lot more use when I’m at the bar. Why?

Curation.

The Bar Aid is, for all intents and purposes, a curated list of cocktails. It’s not only a list of 80 popular and common cocktails, but it’s also a list of 80 cocktails whose recipe fits in a 5”x1” window. Common and simple. It has never steered me wrong.

What if I want a cocktail not on the list, or if I have a strange ingredient and want to see what cocktails I can make with it? Do I reach for the “Ultimate A-Z Bar Guide”? Not often. I usually reach for the Internet (yes Google). The Internet is my new reference guide. It has more information and choices than any reference I have at home, and is infinitely searchable.

In this modern age we live in, references, like the A-Z Guide, are useless when compared to the Internet. They’re also useless compared to curated material like the Bar Aid. When I want to look up a “good cocktail”, I can quickly flip through the Bar Aid and find something easy to make. When I need something more involved, I’ll hit Google.

I find this fascinating and I think it’s a big problem for creators of reference materials of any kind. I don’t need 100 of Gordon Ramsay’s best dishes, I need his 20 best starters. I don’t want to know how Roger Ebert rated every movie of the last century, but I’d love to know his 10 best straight-to-video releases.

I think this is a great way for those knowledgable on something to spread that knowledge and create interest in their field. Focused, curated information is going to continue to be important. It’s just too hard to search the Internet when you only want “something good”, and a reference book is too limiting when you want to hunt down something specific.

Since I’m a huge nerd who recently spent a few hours in Ground Kontrol, I’ll leave you with my curated list of 80s video games that are the easiest and most fun to play:

Centipede - fast, great sound FX, lots of shooting
Frogger - great music, colorful, easy to grok, hard to master
Ms. Pac Man - AMAZING sound, nonviolent, rewarding
Star Wars (the vector one) - vector graphics are so great, sound design and music is wonderful, and the controls are natural and fun
Super Sprint - fast-paced car racing that’s just realistic enough to be challenging, but not so much that you’re bored
Tempest - abstract vector graphics and premise; just shoot things with satisfying sound effects
Tron - four awesome games in one; you get to be the light cycle, fight tanks, and kill that pesky MCP.

Why I'd never work for Google, Twitter, or Facebook

2011-08-01T00:00:00-04:00

Just got back from OSCON 2011. There were some really interesting talks, and “the big three” were all over the place: Google, Twitter, and Facebook. I attended the Twitter talk on how they moved from Ruby to the JVM, as well a talk by Rob Pike (of Google) on Go. I use Twitter and Google a lot, and enjoyed hearing about how they work (Facebook, on the other hand, I use begrudgingly).

My first reaction to these talks was “Wow, it sure sounds like a lot of fun to work at these places!” From inventing programming languages to using Scala to scale a massive architecture, it sounds like developer shangri-la. Until recently, I was slinging Spring MVC code in vanilla Java. Sucks for me, right?

This is lazy thinking, and I haven’t fallen victim to it in quite a while. Ask yourself: “Why would Google spend the time and money to get Rob Pike to work for them and invent an entirely new programming language?” Ask: “Why would Twitter spend the time and money to design and deploy an elegant, scalable architecture using the JVM and Scala?”

An awesome new programming language, or an impressive, scalable architecture is not an end to itself. These are tools that serve some other purpose.

In the case of Google, Twitter, and Facebook, that purpose is to serve ads.

Although Steve Yegge’s keynote features him “quitting” his project at Google (which he describes as “sharing cat pictures”) to work on some higher calling (still within Google), he’s just trading one ad-serving system for another.

Google+ isn’t about sharing cat pictures, it’s about serving ads. Twitter’s massive network of 140-character bits of information isn’t about connecting people across the globe or to view current trends in worldwide thinking, it’s about serving ads. Facebook isn’t about entertaining yourself with games or sharing interesting links, it’s about serving ads.

So, why are the best and brightest in the industry busting their asses to work at these places? If all you care about is watching performance metrics increase, or playing with something new, or just watching lots of tests pass, I guess it’s nice to get paid well. But, how can this be truly fulfilling? For me, it wouldn’t be. I need the tools I’m building, the products I work on, and the architecture I’m helping to create to all serve something I’m interested in.

I’m not saying that my code needs to save the world or support humanitarian causes, but it should at least be something that I like, or I would use, or that I care about.

And I can’t fucking abide advertisements. Honestly, I don’t know anyone who does. Except, apparently, a lot of really smart software engineers.

I spent a dollar on something that's free

2011-04-28T00:00:00-04:00

Co-worker sent out an email today, letting everyone know about a handy Mac app called cdto. You drag it to Finder and, if you click it, it will open a Terminal window where the current working directory is the folder you’re viewing in Finder. Pretty handy.

I click the link and get to a Google Code page, with a link to a zip. Then, I thought, maybe the developer is being nice and has put it in the App Store; that way, I can install it here with one click, and install it at home with one click.

Nope.

But, another developer has created a similar app called ShellTo. The icon is similar, and it does exactly the same thing. However, it’s 99 cents.

Now, I have a bit of a dilemma. Do I download cdto, find the expanded folder (called “cdto dist”) in my Downloads folder, search that for the executable (there were several directories, only one having the app), drag it to the Applications folder and then repeat the process (which I can make slightly faster via Dropbox) at home?

Or, do I pay a buck to have this done instantly and painlessly?

I paid the buck.

If you could pay a dollar for 5 minutes of your time back, would you?

Hyperscheduling - How I find time to do things I hate

2011-04-06T00:00:00-04:00

You don’t need schedule time to play video games - Merlin Mann

Merlin Mann has said this more than a few times on his great podcast with Dan Benjamin, and it really strikes a chord with me. Not that I play video games (I don’t), but the underyling message really speaks to me: “you don’t need to schedule time to do things you really want to do.”

It’s true; I don’t have any problem finding time throughout the week to work on my book, or hack on open source stuff, or have a great meal with my lovely fiancé. What I do have a problem finding time for are the things I hate doing, but that I feel, intellecutally, that I should be doing.

Given that, in less than two months, I’ll be on a beach in Puerto Rico, getting married, and having my picture taken, I started to get worried. I’m not obese, but I’m far from a healthy weight, and I lead a mostly sedentary lifestyle. I also rarely eat breakfast, leading me to just devour massive amounts of food at lunchtime.

About once a month, I’ll “buckle down” and make breakfast about twice, and make it to the gym a few times, and the back to normal.

Not this time. Other than a life-long partner, the other thing from a wedding that lasts are the pictures. And, if I can’t get myself in some semblance of shape for that, well…I just can’t do it. And I hate not being able to do things.

Doing the things I hate

My problem was this constant feeling of “not enough time in the day.” We seem to have solved this problem at work, and that’s way more complex than my life.

So, I started with a completely empty day, and started to carve things out, one by one.

I wanted to leave work at 6pm every day. That means getting there by 9:30am. And if I want to go to the gym, I’d need to be done working out by 9:00am. I worked all the way through everything I’d need to do, including making breakfast and packing my bag the night before.

As you can see, I’ve scheduled things down to the minute: I get up at 6:50, start making breakfast by 7, and clean it all up in time to leave for the gym by 7:35. I set each of these to loudly alarm on my iPhone, so I keep the right pace.

And yes, I also planned when to eat lunch and what to have (I eat at one of the same three restaurants every day anyway, why bother having to make the decision?).

Does it work?

So far, it has totally worked. I’ve never, ever in my life made it to the gym more than twice in one week. EVER. The first three weeks, I made it 4 times each week, and did 30 minutes of cardio, plus stretches, weights, etc. I was also in bed by 11:00 each night, with my bag packed and ready to go.

And then I got food poisoning, forcing an entire week of not following this schedule.

I was really worried I’d lost all my momentum, that maybe the “newness” of this technique would wear off.

I started right back up

Not a problem; started back into my routine with no problems at all. Now, I’m not tracking calories, weight, or anything (this can’t be about manipulating metrics, it has to be about establishing a healthy routine), but so far, I think this has the highest chance of working its way into my life.

Why does this work?

When I’d make it to the gym, I’d feel rushed. “Shit, I have to hurry, so I can get to work in time to put in the right hours so I can get home and then do fun stuff!” “I won’t go to the gym, because I overslept and I won’t get a proper workout, so why bother?” The excuses went on and on.

Now that everything’s scheduled, I’m not rushed. I never worry that I’ll miss out on anything, because all of my “chores” are accounted for: getting up in time to make a proper breakfast, getting to the gym in time to get a proper work out, getting to work in time to put in my hours and leave at a reasonable hour, etc.

Getting ready the night before is also crucial: it reduces friction for the next day, and also represents a commitment to myself. If I’ve already gone to the trouble of packing up my clothes and stuff for the gym, when I’m groggy the next morning, trying to convince myself to sleep more, I think about that bag: “Well, I’m actually all ready, so I might as well actually go.”

What about scheduling “free time?”

I decided to explicitly not schedule “free” activities. There’s nothing on my calendar that says “work on book” or “make dinner” or “watch TV with fiancé.” As Merlin says, these don’t need to be scheduled, and, honestly, free time doesn’t feel free when the iPhone alarams are going off.

What’s next?

Keep doing it and hope my wedding pictures turn out great! I’ll report back after the honeymoon with the results!

Why not use bash?

2011-04-02T00:00:00-04:00

At RubyNation, I gave a talk on Making Awesome Command Line Applications in Ruby, which I’ve done a few times, and is what led to my currently-in-progress book on the subject.

One of the assertions I added to the talk, based on my work on the book is the specific advice to not start off in bash…use Ruby. This was questioned by a member of the audience (who I realized later was Blake Mizerany of Heroku/Sinatra fame, i.e. someone far more knowledgable than me about CLI apps, Ruby, and shell programming).

My answer was about as eloquent as a middle-school debate team closing argument and amounted to “Me hate bash.”

Although I do dislike shell programming, it’s not exactly fair of me to transfer my personal preferences into solid “advice,” nor is it fair to imply that shell programming is a lame or worthless skill; it’s certainly not.

So, I thought about it a bit more and I have a real answer to the question “Why use Ruby instead of shell?”

Blake made the point that one of my examples (in Ruby) would’ve been very trivial in shell, and further that issues I was discussing could be easily avoided by simply better-wielding the shell. His preference was to convert to Ruby only when things got complicated.

I would generally agree, for some definition of “when things get complicated.”

For me, things get complicated in shell very quickly…I’m just not a shell expert and likely won’t ever be. A lot of developers aren’t shell experts, and are not going to be able to use the shell programming language nearly as effectively as they could Ruby.

So, rather than write bad shell code and then port to Ruby later (once you’ve made a mess), my advice, assuming you aren’t a shell expert and aren’t looking to become one, is to just start off with Ruby.

I say this because the average developer is much more likely to be able to write clean & idiomatic Ruby code than to write similarly idiomatic shell code.

That said, I probably should become more of an expert on shell programming and would love some resources if anyone has any.

One Week of using my iPad for personal stuff at work

2011-01-10T00:00:00-05:00

On Jan 3, I tweeted:

All personal stuff only on iPad; no twitter, email, or RSS on work computer. Will it keep me more focused?

Essentially, what I decided to try doing was to bring my iPad to work every day, and use it for Twitter, RSS, and personal emails. The only “personal” stuff I would be doing on my work machine would be IM, simply because the IM experience on iPad is not very good, and the immediacy of it would be lost on a computer that’s not right in front of me. I don’t do a lot of personal IM’ing anyway, so this seemed like a good compromise.

Why?

Normally, I get all kinds of notifications on my machine: new emails, new stories in RSS, new tweets, etc. This divides my focus. I’ll spend upwards of five minutes reading mail or blogs while waiting for a two minute test run to complete. Not good. It’s hard enough to focus where I work as it is, so I thought this would help. Further, when I do take a break and focus on RSS or personal email, I’m bombarded with work-related things…the very things I’m trying to take a break from!

How did it go?

In a word: “smashing.”

I tended to keep Twitter for iPad running, as that’s pretty easy to duck in and out of. Any interesting link, I sent right to Instapaper for reading on the train home. I only read RSS feeds a couple times a day, usually during lunch, and during the dreaded 3pm doldrums where I just start fading and need a break.

I got to most personal emails I would normally deal with, however, because of the iPad’s virtual keyboard, I pushed off dealing with emails that required a bit more writing. This turns out to be a good thing, because most of the time these sorts of emails can just wait until I get home.

I’m going to keep it going as long as I can; I think it’s going to be a great way to maintain focus without just ditching the handy notification systems that are useful throughout the day. When I’m working, I’m not thinking about personal email or what’s been posted to Daring Fireball. When I’m taking a break, I’m just dealing with email, taking in blog entries and actually recharging for the next block of work.

I don’t think this would be possible on just a phone; the iPad provides a near-to-a-real-computer enough experience that I can do just about everything I need to on it.

2010 in review; what's next for me in 2011

2011-01-01T00:00:00-05:00

Yesterday, while waiting for guests to arrive at my mostly-annual New Year’s Eve party, I found a txt file I created called 2010_goals.txt. It’s contents:

speak at at least one more user’s group
speak at some sort of conference
deploy an App to the iPhone App Store
Deploy a Rails 2 app to Heroku

I had totally forgotten about this, although I accomplished almost everything on that list. This year, I spoke at DCRUG twice, NOVAJUG once, and spoke at ScalaDays 2010 in Switzerland (and was subsequently trapped by that stupid volcano) as well as Lone Star Ruby Conf in Austin. While I still haven’t quite submitted my iPhone app to the app store, I did deploy a Rails three app to heroku, namely my Rails Rumble ‘10 entry Carl The Robot. On top of all that, I successfully completed PragProWriMo, writing a 170+ page book on command-line applications in Ruby in just one month. And had more than a few patches accepted to some open source projects.

So, I created 2011_goals.txt to continue the tradition:

Deploy my iPhone app to App Store
Speak at at least 2 conferences
Publish my command-line application book
Develop and deploy an iPad app
Blog twice a month
Learn JavaScript more betterer
Get my rudimentary scaladoc doclet accepted.

I think it’s doable, but I’ve got a busy year planned in the non-geek-related parts of my life, so who knows? What are your goals for 2011?

Static vs. Dynamic Typing: A matter of keystrokes?

2010-08-24T00:00:00-04:00

In Java, I almost never make type errors. The type errors that are possible in Java fall roughly into two categories:

Using an object of the wrong type (this is caught by the compiler)
Casting an object to a more specific type at runtime (this can only be caught by tests or users :)

I’d make error #1 on occasion, but the compiler catches it. As to #2, before generics, I can count on my hands the number of times I got a bona-fide ClassCastException at runtime. After generics? Never.

I don’t mean just that I didn’t experience these runtime type errors, but that they didn’t even make it to the compiler. If you think about how Java syntax works, it’s no wonder:

List<String> someList = new ArrayList<String>();
someList.add("Foo");
someList.add("Bar");

I had to type almost the exact same thing twice. After about 2 days of using generics, my muscle memory literally prevents me from making type errors. To even simulate one requires a pre-generics library call, or some herculean efforts. An arguable win for static typing, if at the price of verbosity.

Of course, in Ruby, I make type errors all the time, especially when using new libraries I’m not familiar with. Ruby libraries rarely document the types of things (though they are frequently liberal with what they will accept). The solution here is just better unit tests. And that’s a pretty good thing. So, a slight negative for dynamic typing that leads us to a better tested system, reduced verbosity, and better productivity once the learning curve is dealth with.

This pretty well illustrates the tradeoffs between dynamic and static typing. Case closed, right?

Enter Scala. With Scala, I make type errors just as much as I do with Ruby. The only difference is that the compiler catches them. Here’s the Scala equivalent to the Java code above

var list = List("foo","bar")

Notce how I haven’t specified a single type? It’s nearly identical to the Ruby version:

list = ["foo","bar"]

These examples are obviously simplistic, but in a more complex system, Scala’s type inferencer tends to be one step ahead of me. While it’s handy that I have a compiler to catch these type errors, the fact remains that, despite Scala being a statically typed language, I’m making far more type errors than I would in Java.

This seems kindof odd, but I think it’s ultimately a win: I get the brevity and productivity of a dynamically typed language, but the safety of the compiler catching my type errors for me.

Scala puts a subtle spin on the “static vs. dynamic” debate, because you aren’t annotating your types nearly as much as with Java, but you still get all the benefits. I’ve certainly heard many criticisims of static typing, but having the compiler check types for you wasn’t one of them.

Of course, sometimes you do need to tell Scala what your types are, but, they seem to be exactly where you’d want them anyway:

/** get users with the given name and age */
def getUsers(name:String,age:Option[Int]):List[User]

This says that we take a requires String and an optional Int and will return a list of User objects. To give the same information in Ruby, you’d need to:

# Gets the users with the given name and age
#
# name - a String
# age - an Int or nil if not searching by age
#
# Returns an array of User objects
def get_users(name,age=nil)
    ...
end

(Sure, you could leave off the comment, but do you really hate your fellow developers (and future you) that much?)

Now which language is more verbose? Perhaps the static/dynamic typing debate is really just about entering text?

In "Offense" of Scala's Option class; a guarded defense of Cédric's rant

2010-07-30T00:00:00-04:00

In a recent blog entry, Cédric Beust calls out scala’s Option class as nothing more significant than null checks. Commenters rightly set him straight that the thesis of his blog post was marred by an ignorance of idiomatic use of the class.

But, it’s hard to really blame Cédric, when you look at what he had to go on. Odersky’s book states that one should use pattern matching with Option, and the scaladoc for Option is just abysmal:

This class represents optional values. Instances of Option are either instances of case class Some or it is case object None.

That is the entire description of the class, no examples, nothing. Worse, the method that commenters called out as idiomatic, flatMap, has the following description:

If the option is nonempty, return a function applied to its value. Otherwise return None.

This is not what Option#flatMap actually appears to do (nor is documented to do; it’s documented to return an Option[B]!):

scala> val s:Option[String] = Some("foo")
scala> val n:Option[String] = None
scala> val f = { (x:String) => Some(x + "bar") }
scala> s.flatMap(f)
Some(foobar)
scala> n.flatMap(f)
None
scala> val result = s.flatMap(f)
r: Option[java.lang.String] = Some(foobar)
scala> r.getClass
res6: java.lang.Class[_] = class scala.Some

It certainly doesn’t call itself out as “the way” to use Option. A simple example in the scaladoc could have gone a long way.

So, angry post + helpful commenters == problem solved, right?

Wrong.

The Option class is, really, an implementation of the NullObject pattern, and a more elegant way to handle optional values. In scala, we might have this method signature:

/**
 * Updates the full name
 * @param lastName the last name
 * @param firstName the first name
 */
def updateName(lastName:String, firstName:Option[String])

This means “update my name; lastName is required and firstName is optional”. In java, this method might look like this:

/**
 * Updates the full name
 * @param lastName the last name, may not be null
 * @param firstName the first name, may be null
 */
public void updateName(String lastName, String firstName) {
    if (lastName == null) {
        throw new IllegalArgumentException("lastName required");
    }
    StringBuffer b = new StringBuffer(lastName);
    if (firstName != null) {
        b.append(", ");
        b.append(firstName);
    }
    this.fullName = b.toString();
}

So, what’s the right way to do it in Scala? According to the commentors:

def updateName(lastName:String, firstName:Option[String]):Unit = {
  val b = new StringBuffer(lastName)
  firstName.foreach( (name) => b.append(", "); b.append(firstName) )
}

Yech. Does anyone else think that calling a method called “foreach” on our “optional value” is just nonsensical? Or that the idiomatic way to treat an optional value is as a collection, e.g. by using the for comprehension? This just feels hacky. Naming is one of the most important (and challenging) things in software engineering, and Option’s API is an utter failure (even its name is wrong; when one has an option, one typicaly has many choices, not just one or nothing. Optional is really what is meant here, so why are we afraid of adding a few more letters? Especially given how “precise” some of the documentation is, mathematically speaking, why are we not being precise with English?). If Option is just shorthand for a “list of zero or one elements”, and we get no better methods than what comes with List, then what’s even the point of the class?

I’m not saying we remove all the collection methods from Option, but how about a throwing us a bone to make our code readable and learnable without running to the scaladoc (or REPL) to see what’s going on? I mean, there’s a method on Option called withFilter whose documented purpose (I’m not making this up) is: “Necessary to keep Option from being implicitly converted to Iterable in for comprehensions”. Am I expected to believe that it’s ok to have this hacky pile of cruft, but we can’t get a readable method for “do something to the contents if they are there”?

class Option[A] { 
  def ifValue[U]( f: (A) => U ):Unit = foreach(f)
  def unlessValue[U]( f: () => U):Unit = if (self.isEmpty) f
}

def updateName(lastName:String, firstName:Option[String]):Unit = {
  val b = new StringBuffer(lastName)
  firstName.ifValue( (name) => b.append(", "); b.append(firstName) )
}

Which would be less surprising? Couple this with some better scaladoc:

/** This class represents an optional value.  
 *
 * To use as a null object:
 * val optional = getSomePossiblyOptionalValue
 * <pre>
 * option.ifValue { (actualValue) => 
 *   // do things with the value, if it was there
 * }
 * </pre>
 * or
 * <pre>
 * optional.unlessValue { log.debug("missing optional value") }
 * </pre>
 * 
 * To use as a Monad or collection:
 * <pre>
 * val first8upper = option.flatMap( (y) => Some(y.toUpperCase) ).
 *                          flatMap( (y) => Some(y.substring(0,8)) )
 * </pre>
 */
class Option[T] {
  // etc.
}

With these examples, you cover the two main uses of this class, show newcomers how to use it, and demonstrate its superiority over null checks.

It’s frustrating to see this, because Scala has so much potential to be a lucid, accessible, readable language, but API usability and learnability are just not prioties. Scala needs to take some lessons from Ruby in terms of API design (and Java in terms of API documentation).

Of course, none of this does save you from null, because Scala is perfectly happy to assign null to anything. It kinda makes the whole thing seem a bit pointless.

My first iPhone App - Part 5

2010-07-18T00:00:00-04:00

See Part 1, Part 2, Part 3, and Part 4 first

I’ve been working on the app more than my recent lack of blog entries indicates. At this point, I have what could roughly be called a beta version; almost all the features are there, and things seem to be generally working pretty well.

User Experience

The biggest change in the UX is the ability to add tasting notes, date tasted, and location tasted. This is a new screen accessible from the main entry screen. The most obvious way to do this in my mind, was a big button at the bottom:

In designing the new screen, the “where tasted” and “when tasted” were straightforward; I used stock controls. For the tasting notes, I needed a UITextView, which is akin to an HTML TEXTAREA. The visual appearance of this control is pretty lacking compared to the UITextField; there is no nice beveled edge, no rounded corners, and no placeholder text. I really just wanted a multi-line field much like the UITextField, but there is nothing available to create that.

So, I hacked something together.

An option for the UITextField’s appearance is to have a beveled edge with square corners. In this configuration, you can adjust the height of the text field. So, I placed such a field on the screen and sized it about the size of my tasting notes field and made the background color white. I then put the tasting notes field on top of it, with a clear background color, and, well, it looked pretty good:

I then implemented some UITextViewDelegate methods to give the apperance of placeholder text:

- (BOOL)textViewShouldBeginEditing:(UITextView *)textView {
    if ([textView.text isEqualToString:DEFAULT_TASTING_NOTES_TEXT]) {
        textView.text = @"";
    }
    return YES;
}

- (void)textViewDidEndEditing:(UITextView *)textView {
    if ([textView.text length] == 0) {
        textView.text = DEFAULT_TASTING_NOTES_TEXT;
    }
}

I considered using some third-party controls that mimic this behavior, but didn’t want to get side-tracked adding new frameworks to my app at this point.

User Testing

Once I had this, I handed my phone to Amy for some more user testing; She brought up a few obvious things that I had completely internalized and begun ignoring:

Clicking “Save” on the details screen brought you back to the “new wine” screen, instead of just saving and bringing you back to the top. A minor but obvious annoyance.
She kept tapping on the “Choose Varietal” text field, thinking that would bring up the varietal chooser, instead of clicking the much smaller blue “disclosure” button
She was a bit sad that the wines we had entered in the app would not be available on our shared Google Spreadsheet

To smooth the navigation after saving, I used a stock feature of the UINavigationController to “pop” more than once up the chain. Since my design of the details screen used Apple’s delegate pattern (essentially, the “add new wine” view controller was the delegate to the details view’s lifecycle; when you click “Save” on the detail view, it triggers a callback in the “add new wine” view controller; the perfect place to save before the detail view controller popped back two screens).

The problem with the “Choose Varietal” control had bugged me, too, but I got used to it and didn’t think about it. The solution was very simple, though hacky. I placed a clear button on top of the field the exact size of the field and had it trigger the same action as the blue disclosure button. Problem solved.

As to maintaining the list up on Google Docs, I think I may need to implement this sooner rather than later; I think it’s important to be able to get your data out of an application, and Google Docs is a reasonably user-friendly way to do it (as opposed to emailing some CSV file).

Other Random Bits

I still didn’t get around to setting up iCuke for testing; I really should because I don’t know what missing retain calls might be lurking. I also finally created an icon, using a picture I took in Napa. Not sure I like it, but it beats the white blob:

(Taken from my original).

Finally, the app no longer starts up on the actual device. A seemingly serious problem that I assume would be remedied by a re-install from scratch, however I have a few wines that I’ve added and don’t particularly wanted to lose them. Not sure how I could gain access to the SQL database to get them out, but I’m currently downloading the 4.0.1 update for my phone and the 2+ GB SDK update (!).

As a followup, I had to re-install the application from scratch, though I was able to access the SQLite database from an iTunes backup. I really need to implement a quicker backup/export mechanism…

My first iPhone App - Part 4

2010-07-08T00:00:00-04:00

See Part 1, Part 2, and Part 3 first

The past week was spent trying to understand the best way to expand my application’s features without have a ton of duplicated code or UI. It was also a learning experience on Core Data. Thankfully, Stackoverflow and its amazing contributers were very helpful.

Core Data Blunders

It started as I made my first foray into implementing the search screen (i.e. the home screen of my app):

Three of the searches (most recent wines, wines by rating, and all wines) end up doing the same thing more or less: Query for some data, sort it a certain way, and show it in a UITableView. I ended up creating a custom table cell view and I wanted all three to use it:

Access to Core Data-provided entities is done through objects of the class NSFetchedResultsController, which takes what amounts to a database query and provides many ways of accessing the results, including caching, callbacks, and iteration. When using a table view, you typically have your view controller handle callbacks for this class, which allows the table to update itself when items are added, removes, or changed. All of this boilerplate is given to you at the start of the project. So far so good.

My plan was to create additional NSFetchedResultsController instances inside my table view controller class and then switch between them. A fine idea that lead that numerous random difficult-to-reproduce crashes.

It turns out the basic idea of what I was doing was good, but my implementation exposed a sore lack of understanding of how all this stuff fit together. I’m still not sure I fully grasp it (and wish the book I bought had a bit of a deeper dive into Core Data), but after some more reasoning, I got around it. Essentially, leaving the unused NSFetchedResultsController instances connected to my table view and having caching turned on and not properly reloading data when switching searches created a situation where they were all pretty confused about the underlying state of the database.

With some judicious management of these instances, as well as disabling caching, I now have a fully-functional “Recent Wines”, “Wines By Rating” and fancy indexed “All Wines” view (index meaning I can jump to wines by letter, a la the Contacts application).

Unfortunately, the result of turning off caching is that it takes a noticable blip of time to summon any of these views. I may just come full circle and end up with three different UITableViewController instances and NIBs just so I can leave Caching on.

User Experience

Once I had gotten back to a stable app, I loaded it up on my phone and headed into the field. A few nights ago, Amy and I ended up at one of our favorite restaurants/wine bars in DC, Proof. We’ve been there several times, and many of their wines-by-the-glass are in the Wine Brain. While they rotate their selections, I was curious as to what I’d had there previously. Unfortunately, I had yet to implement the search-by-location feature :) Combing through the “All Wines” view was a bit frustrating. This made obvious several features that are now on the top of my list (some planned previously, some not):

Find wines by location
Actually entering the location at which I had a wine
Location-aware assistance of location (e.g. “Are you at Proof? Here’s what you’ve had there…”)
Ability to text-search the “all wines” list

The good news is that my cursory reading of my book and the API docs indicates that these things are going to be very easy to implement.

Objective-C

There’s a lot to like about Objective-C, and a lot to dislike. Even though the handling of multiple arguments is a bit strange, I find it actually results in fairly readable code. It feels very Apple; different, but usable. Even though it’s a lot to type out something like:

NSString *stripped = [canonicalName stringByTrimmingCharactersInSet:
                       [NSCharacterSet whitespaceAndNewlineCharacterSet]];

It is pretty readable, regardless of what programming language you are coming from. That being said, stack traces and error messages on crashes are nigh-useless, and the overall testability of iPhone apps is pretty behind the times. This months issue of Prag Prog’s magazine has an interesting article on iCuke, which I look forward to trying out. I’ve resulted to keeping a text file of test cases that I have to manually run through to make sure I haven’t broken anything, and it feels, well, 1997. The rumours of a Apple’s switch to Ruby are too good to be true, but one can always dream.

Continued in Part 5

My first iPhone App - Part 3

2010-06-29T00:00:00-04:00

See Part 1 and Part 2 first

Just a quick update for tonight. I’m starting to get the hang of how the user interface elements I create in Interface Builder get hooked up and become available in code. It’s a bit odd and not terribly intuitive, but it’s starting to make a bit more sense. Under the covers there’s some sort of dependency injection going on (even if Apple doesn’t call it that) that smells of Spring-style magic; objects get created for me and populated if I do the right thing.

At any rate, I decided that, before making any more changes, I needed to get a reasonable data set into the app. I spent two painful hours exporting my Google Doc Wine Brain into CSV and parsing it with Objective-C, mapping it to my Core Data model objects. In the end, I was successful, but, WOW, what a pain compared to Ruby or Perl.

Seeing this large set of data on the home screen was very motivational to start working on a drill-down/search interface, as you can see here:

Before delving into my new homescreen, I decided to work up a better color scheme that was more “wine-like”. I’m not a big fan of apps that have fancy graphics and obscure the idiomatic iPhone UI, but a bit of a color splash would go a long way (and, not to mention, be well within my graphic design skill level). In addition, more user testing (via Amy once again) revealed that the rating control needed a much starker contrast between the selected and unselected choices. There isn’t much I have control over via the API for this, so I chose an alternate style of UISegmentedControl that used the “iPhone blue” for the selected state. I think it works OK with the color scheme, though I’d prefer the “merlot red” that I chose for the nav bar and wine type:

I’m starting to think that my desire to have wine entry confined to one screen might not pan out. The “slot-machine” control will become more and more unusable as more varietals are added, and there’s really no way to even add a new varietal here. I think I may have to go with the drill-down method where by I push another table view onto the stack to select (and possibly add) a varietal. For another day.

Lastly, I took a stab at a better home screen:

This pretty-well represents the ways I think I’d want to navigate the data. Time will tell once I implement these searches, but this seems like a reasonable start.

I also have to say that, despite Objective-C’s overall wackiness, it was pretty easy to put this together and have the “Add New Wine” button bring up the “Add Wine” screen and to have the “All Wines” button navigate to the old home screen. Apple has done a reasonable job of making it easy to make an idiomatic, normal-looking iPhone app.

Continued in Part 4, and Part 5

My first iPhone App - Part 2

2010-06-27T00:00:00-04:00

See Part 1 first

For the past several days I’ve had the app on my phone and used it to enter in wines to see how the UI was working. Yesterday, I integrated Core Data (Apple’s Object/Relational Mapper (ORM), for lack of a better description) so that I could actually save some data. I discovered some nuances to using Core Data, as well as a refinement in the UI.

UI

Last night, I had both my girlfriend Amy and my good friend Clay (who is also reasonably into wine) play around with the “new wine” screen. Neither have an iPhone, and there were a few obvious problems:

They were very unaccustomed to the “Done” button being in the upper-right corner, as well as the “slot-machine” control
Both had trouble with the “Wine Name” concept
Both had trouble dismissing the keyboard
Clay thought he was entering search terms and not a new Wine

Later that evening, I had a glass of wine at a bar and entered it into my app. Up until this point, I was just typing in wines I knew about, so this was the first “real use” of the app in the field. I quickly realized that the “Wine Name” concept, while important, was too vague and confusing to be the first field you enter. Most wines are known by the vineyard and some don’t even have proper names or appellations. So, I swapped the fields and added some examples in the placeholder text:

I also added a title to indicate that this screen is for adding a new wine. Finally, I used the background button trick along with some events on the rating and type controls to dismiss the keyboard if you tap anywhere outside of a text field.

This feels much cleaner and flows a bit better. While varietal is probably the third most important thing (at least for New World wines), the slot-machine control would be awkwardly placed right below the vineyard/vintage text fields, so I left it where it was.

As to Clay and Amy’s confusion over some idiomatic iPhone design choices, I’m not worrying about them a whole lot; a typical iPhone user will understand what’s going on (I hope :).

Core Data

Backing all this is Apple’s Core Data, which grew out of the Enterprise Objects Framework (and was, incidentally, my first exposure to an ORM way back in 1998), is the simplest and most idiomatic way to store and manage data on the iPhone. As with Interface Builder, you create the model visually, using a simplistic data modelling tool. I set up the bare bones of my data model and generated the classes.

The first problem I ran into was in changing the model after the database had been created on the device. Core Data doesn’t migrate your model for you by default. I ended up starting over with a “versioned” model and implementing their default migration. This will probably work for simple changes, but for more complex changes, it looks like it’s somewhat difficult to migrate the model. An unfortunate reason to do some Big Design Up Front.

My next problem was initializing reference data. In my case, I wanted the list of varietals as well as the list of wine types (e.g. “red”, “white”) to be in the database and managed by Core Data. I ended up creating an array of the values inside the app and then checking the database for their existence, adding them if they were missing. It’s a bit cheesy, but I can extract the lists to plist files later. It did give me a chance to play with Objective-C’s blocks feature. I needed to map my list of Varietal objects to a list of strings, so I could compare that list against my default list. While NSArray doesn’t provide a map function, it does provide the equivalent of Ruby’s each or Scala’s foreach. In true Apple/Objective-C style, it’s called enumerateObjectsUsingBlock :)

NSMutableArray *strings = [NSMutableArray arrayWithCapacity:[array count]];
[array enumerateObjectsUsingBlock:^(id obj, NSUInteger i, BOOL *stop) {
    [strings addObject:[obj valueForKey:@"name"]];
}];

The stop pointer is an out-only variable that you set to YES to allow for an early exit from the loop. I’m glad they’ve adopted this functional style; I forsee explicit loops becoming just as quaint as GOTOs in the near future.

One thing bugged me about this process, however. I had these generated classes and it wasn’t clear how to add my own methods to them without losing the code every time I re-generated my model. Enter mogenerator. This provides a more sophisticated bit of code generation, givng you two classes for each model: one for machines (i.e. for Core Data to manage) and a subclass for people (to which I can add custom methods). Perfect! I wasn’t able to incorporate it into XCode, but I’m happy running in on the command line as needed for now.

Random Bits

I spent more time than I would’ve liked tracking down a nasty bug where every attempt to convert a string to a number (for the wine vintage year) resulted in a nil number. It turns out I was confused about when some object lifecycle methods were being called and my pointer to an NSNumberFormatter was, in fact, pointing to nil. Unlike Java, where you’d get a NullPointerException, or C, where you’d get a core dump, it seems Objective-C just returns nil and doesn’t even issue a warning. Very strange. Once I realized that, the solution was obvious.

I’m still not 100% sure I’m structuring my code properly, but Stack Overflow’s stalwart iPhone SDK answerers have been incredibly helpful in pointing me in the right direction.

Next Steps

Now that I’ve got the ability to save and retrieve data, the next step is to start looking to browsing, viewing, and editing the database. I think the domain is restricted enough that I can use the iPhone’s idiomatic drill-down table navigation to filter the database.

Continued in Part 3, Part 4, and Part 5

My first iPhone App - Part 1

2010-06-23T00:00:00-04:00

Background

Last year, I spent most of my free time becoming familiar with Ruby, Rails, and Scala. I’m by no means an expert, but I’m trying to follow the advice of the Pragmatic Programmers and learn a new language/system every year. This year, it’s going to be the iPhone API and Objective-C. I coded some WebObjects applications in Objective-C many years ago, so the language isn’t totally unfamiliar, but the iPhone SDK, obviously, is. After working my way through the first several chapters of the Dudney and Adamson’s “iPhone SDK Development” book, I decided I was ready to try my first real app.

First App

My girlfriend and I enjoy wine, but are largely novices. On a trip to Napa we started writing down the wines we’d tried and keeping personal ratings of them. The idea being twofold: try to remember good wines/avoid bad ones, and try to hone in on what our tastes are. There are so many wines and so many flavors and smells, it’s just impossible to keep in your head. So, I created a Google Spreadsheet and a form to allow us to enter wines on the go, via our smart phones. The Goolge Docs form is less than usable, and this seems like the perfect job for a native iPhone app.

User Experience

Aside from learning the ins and outs of the SDK, another main goal is focus on making a highly-usable application (at least for myself and my girlfriend). So, before diving into Core Data and modelling the domain, my first version of the applicaton simply presents the “add a new wine” screen. This will be the screen I spend the most time in, and it’s important to make it fast and easy.

The Google Spreadsheet currently collects:

Wine Name
Vineyard
Vintage (year)
Varietal
Type (e.g. red/white)
Where we had
When we had
My rating
Her rating
Tasting Notes

That’s obviously too much for one iphone screen, and, if I’m entering something in a hurry, I might not have time to go through all that. Further, I think adding multiple ratings makes things a bit confusing, so I focussed my screen on the identifying characteristics (name/vineyard/vintage), the rating, and the type:

As you can see, I tried to fit the “where” on the bottom, as well as a “enter more information” button. After loading this on the phone, it was just not working out, plus I was missing the varietal, which is fairly important (at least to me).

My next attempt simply ignores the “add more” concept, and, by using the segmented control, I was able to fit the type into a more compact area, while including the varietal as a “slot-machine”/picker.

My plan is to load this onto the phone and try using it the next few times I’m out. I figure I can do without the tasting notes or location if it keeps the UI simple

The Code

Objective-C and XCode are a whole different world from Java or Ruby. First thing that bit me is the memory management. I was familiar with the rules (or so I thought). Basically, if you call a method like “copyXXX” or “initXXX” to create a new object, you must release it when you are done with it. If you get access to an object through any other means, you should not release it.

// my class has an NSArray called varietals that I'm initializing here
varietals = [NSArray arrayWithObjects:
                  @"Barbera",
                  @"Cabernet Franc",
                  // snip
                  @"Zinfandel",
                  @"Other",
                  nil];

Since I’m not calling an “init” style method, I figured I didn’t need to release it in dealloc. For some reason, this made me decide that I didn’t need to retain it. This caused my first crash and trip through the debugger to figure out what in the heck is going on.

// my class has an NSArray called varietals that I'm initializing here
varietals = [[NSArray arrayWithObjects:
                  @"Barbera",
                  @"Cabernet Franc",
                  // snip
                  @"Zinfandel",
                  @"Other",
                  nil] retain];

Since I needed varietals to survive the method where I was initializing it, I had to retain it.

Other struggles

Interestingly, laying out the UI and getting that hooked up isn’t too bad; the thing I’m having the most trouble with is figuring out what is the “unsurprising” way of doing things; tutorial code from books is rarely very well written; it’s usually done in a certain way to make concepts clear, but I haven’t yet found a definitive “here’s how you organize your code” or “iPhone best practices” that seems relatively comprehensive.

At any rate, I figure if I can get the UX to be reasonably good, the rest should sort itself out.

I’ll continue posting about my progress here on my blog. If I can get the app polished and working, my girlfriend might demand and Android version. Would be interesting to compare the two paradigms (especially since Android is all Java, which has been my bread-and-butter for many years).

Continued in Part 2, Part 3, Part 4, and Part 5

In defense of vi

2010-06-14T00:00:00-04:00

Sadly, I was unable to attend RailsConf this year. It was in Baltimore, and it would’ve been a lot of fun, but it just wasn’t in the cards. One of the great things about RailsConf is that the videos are posted online very quickly and are always of high quality. While I always like hearing DHH speak, I try to never miss one of Uncle Bob Martin, author of the must-go-read-this-right-now Clean Code.

This year, he gave an awesome talk on the (lack of) innovation in software development. He pointed out that we were still writing the same type of code now as we were 40 years ago. In one part, he asks the crowd what editor they use (knowing full well most will say vim). He then proceeds to make light of the audience for using a 19-year-old editor based on a 34-year-old editor. While his criticism is brief, I think it speaks more to the sorry state of text editing than to the developers (like me) who are “still” using vim.

I’m sure that unclebob is one of the more advanced IDE users, but it just pains me watching my co-workers meander through their code, selecting things with the mouse, and deleting long swaths of text by just hitting the delete key a lot.

While an IDE is great for learning a new environment (especially one as pedantic and verbose as Java or Objective-C), the editing capabilities are counter-intuitive and degenerate. vim may be hard on the newbie, but it’s intuitive and logical. When you understand the “zen” of vim, you can fly through your code, playing it like a musical instrument. It affords muscle memory and allows sophisticated chaining of movement, intent, and action. You can see what you want to accomplish and your hands make it so, all without reaching for a mouse, cursoring, using the delete key, or contorting your hand with some awful combination of key modifiers.

Think of it as a piano; it’s a very simple base of simple sounds and actions that, when chained together, can be used to make beautiful music. An IDE is more like a fancy Casio keyboard with built-in songs and beats. Shiny, but hollow.

Are private methods code smells?

2010-05-26T00:00:00-04:00

Having had discussions with co-workers on the utility of private methods and recently on the scala mailing list, there’s been the notion that private methods (or even protected methods) are code smells – indicators that there is something wrong with the design of your code. I believe in many cases they can be, but that private (and protected) methods still have their uses, especially in maintaining a clean design under constraints of getting things done. First, we need to know what we are talking about.

Definitions

While the technical meaning of access modifiers varies with the language, the intent these concepts communicate is what we’re talking about here. I assert that the intent of public/protected/private is (and/or should be) as follows:

public - this method is part of the published API and will not change within major versions of the class
protected - this method is a hook for modifying the behavior of this class using subclasses. It, too, will not change within major versions of the class (of course, it also might exist for code-reuse internal to the class hierarchy).
private - this method was refactored out of a well tested public or protected method for reasons of clarity or internal re-use. This method may absolutely change, even in patch releases, and should not be relied upon to even exist
package private (bonus for Java) - this method was written by someone lazy or ingorant, or by someone who acknowledges that this code should be pulled out into its own class, but hasn’t done so, yet still wants to test it seperately, thus breaking encapsulation.

Why would private methods be code smells?

The most concise argument is that private methods could indicate that the class that contains them is doing too many things. Consider this code from shorty, my URL shortener:

override def contextInitialized(event:ServletContextEvent) = {
  event.getServletContext.log("Initializing our hasher/DB")
  val dirName = event.getServletContext.getInitParameter(
    ShortyServlet.DB_DIR_PARAM)
  if (dirName != null) {
    val dir = new File(dirName)
    if (dir.exists()) {
      if (dir.isDirectory()) {
        val hasher = URIHasher(DB(dir))
        hasher.start
        uriHasher = hasher
        event.getServletContext.setAttribute(
          ShortyServlet.URI_HASHER_ATTRIBUTE,uriHasher)
      }
      else {
        throw new ServletException(dir.getAbsolutePath 
          + " is not a directory")
      }
    }
    else {
      throw new ServletException(dir.getAbsolutePath + " doesn't exist")
    }
  }
  else {
    throw new ServletException("You must supply a value for " 
      + ShortyServlet.DB_DIR_PARAM)
  }
}

Is it totally clear what this method does? If not, it basically checks that the directory configured for our database exists and is a directory, giving us a specific error message if not. It’s a bit long and full of error checking, so the meat where it creates our URI hasher and gives it to the servlet is somewhat obscured. Here’s a cleaned up version:

override def contextInitialized(event:ServletContextEvent) = {
  event.getServletContext.log("Initializing our hasher/DB")
  getDBDir(event) match {
    case Right(dir) => {
      val hasher = URIHasher(DB(dir))
      hasher.start
      uriHasher = hasher
      event.getServletContext.setAttribute(
        ShortyServlet.URI_HASHER_ATTRIBUTE,uriHasher)
    }
    case Left(errorMessage) => 
      throw new ServletException(errorMessage)
  }
}

private def getDBDir(event:ServletContextEvent) = {
  val dirName = event.getServletContext.getInitParameter(
    ShortyServlet.DB_DIR_PARAM)
  if (dirName != null) {
    val dir = new File(dirName)
    if (dir.exists()) {
      if (dir.isDirectory()) {
        Right(dir)
      }
      else {
        Left(dir.getAbsolutePath + " is not a directory")
      }
    }
    else {
      Left(dir.getAbsolutePath + " doesn't exist")
    }
  }
  else {
    Left("You must supply a value for " + ShortyServlet.DB_DIR_PARAM)
  }
}

We’ve added lines of code, but our public method is a lot clearer: we get the dir for our DB; if we get a “right”, we have a usable dir, and if we get a “left” (the Scala convention for an error), we have the error message to use for our exception.

So, is getDBDir now a code smell? This is a private method and, this means that contextInitialized was tested and we extracted the private method as step three of the TDD “Test/Fix/Refactor” cycle.

Of course, getDBDir has nothing to do with the ServletContextListener and is really all about checking for a valid path. So, we should extract it to a new class, right?

Well, if we did do that, we’ve now actually added a public API to our codebase. Unless we make the new class completely private to the enclosing class, we’ve now introduced a new public class that must be tested and managed as part of our system’s public API.

I don’t see the benefit to doing that. I don’t particularly want this method to be in the public API (at least not now). So, what about making it a private inner class? That doesn’t seem to be much different than what we have now, though it might save a few minutes on a future extraction.

When IS this a code smell?

This was a simple example. Consider a class like SignedUrl in my Gliffy Ruby client. This class has a fair number of private methods and, overall, is pretty large. The private methods are vague things like handle_params and get_signing_key. The private methods aren’t really the problem, however; They are a symptom of the fact that this class is just doing too many things. A better design would be to split this class up into something like a UrlParams, UrlSigner and UrlAssembler (just off the top of my head). The result would be more smaller classes, each with fewer public and private methods.

What about protected methods?

In Ruby, you don’t see a lot of protected methods. In well-designed Java frameworks (such as Spring), you’ll see them as I’ve described above: hooks into a helper class that allow you to customize how that class behaves via subclassing. In non-library code, protected methods tend to get used for code-reuse in narrowly-focused class hierarchies. For example, the project I’m working on has a BaseController that provides common methods to the actual web controllers. Having used protected methods for both of these purposes, I think that, honestly, both can be code smells.

Protected methods as hooks

In the case of providing “hooks”, I think it’s clear that by providing them at all, you are acknowledging that your class might be poorly designed (or that your language lacks the expressiveness to better design it). Consider the venerable (and now deprecated) SimpleFormController, a Spring MVC class that provides many protected-method hooks, one of which is protected Map referenceData(HttpServletRequest request). This is called during the lifecycle of the controller to get any data needed by the form that should be available to the view (for example, a list of U.S. states from the database). Your subclass of SimpleFormController overrides this to provide the data as a map.

Why not create an interface called ServletRequestToReferenceData that contains this method, and inject an instance into SimpleFormController? This would be very Spring-like. My guess as to why this isn’t the case is that there is simply too much overhead in making yet another one-method interface and the designer of SimpleFormController just felt this was a reasonable tradeoff.

In Scala, however, this could simply take a function:

  def referenceData[A]((HttpServletRequest) => Map[String,A]);

  // ...


  controller.referenceData{ request => 
    // create our map based on the request
  }

In Ruby, the overhead of creating a new class isn’t nearly as onerous, and we could still inject a block as we do in Scala.

Ultimately, I would say that you have to make a tradeoff here, and it has to take the language and frameworks into account; a class with many, many hooks might be a code smell, but using it as a means to avoid language ceremony in the name of OO purity is probably a reasonable design tradeoff.

Protected methods as code sharing

This use of protected methods is harder to justify, but incredibly handy. Still, this could be another case of Java (e.g.) not providing the necessary language features to make class extraction more straightforward. As mentioned, in my current application, I have a BaseController. It has a helper method as follows:

protected Person getAndValidateLoggedInPerson() {
  Person p = this.personService.getPerson(
    this.authenticationService.loggedInUserId());
  if (p == null) {
    throw new NotFoundException;
  }
  return p;
}

Because of Spring MVC, we have specialized exceptions for HTTP errors, such as “NOT_FOUND”. Here we contain the logic to identify the id of the logged-in person as well as the check for existence. Having this available to all controllers in the entire system is very handy.

But, is this a code smell?

We could make a class that does this, turning this code:

Person p = getAndValidateLoggedInPerson();

into this:

Person p = this.personValidatorAndGetter.getPerson();

creating a one method class that has many lines of injected dependeicies and other boilerpalte with a few actual lines of code.

I think this is yet another case of pragmatically dealing with language ceremony. In Scala or Ruby, the overhead of creating re-usable bits of code like this is far lower than for Java; In Scala one could envision a simple function, possibly with some implicit parameters. Ultimateley, “too much” of this sort of thing should be a code smell, but small bits of this, in the name of simplicity, clarity, and simply keeping the codebase smaller isn’t an automatic red flag.

Conclusions

So, are non-public methods code smells? If we take the wikipedia definition, which is clear that a code smell indicates merely the possibility of deeper problems in your code, then, yes, private and protected methods are code smells.

But, should they be avoided at all costs? Absolutely not. There’s many valid reasons to use them, and they do not deserve the blame for an ill-concieved class. Coding in the real world is about tradeoffs; we have to do the best thing we can with the time, resources, and tools at our disposal. These tradeoffs may not result in an According-to-Hoyle OO (or functional) design, but we’re not writing code to provide examples of programming paradigms or design patterns; we’re writing it to accomplish something and provide value. And, as professionals, we need to do it at a predictable rate that doesn’t incur too much technical debt.

Video of My Talk at ScalaDays 2010

2010-04-30T00:00:00-04:00

Video of my talk at ScalaDays is online. Check it out. Feedback very much appreciated!

Scala Days Impressions

2010-04-22T00:00:00-04:00

I had the good fortune to not only attend ScalaDays 2010, but also to speak (generously supported by my employer). The experience overall was great. I talked to some really enthusiastic and interesting people (including two high school kids from Austria who were using Lift because, after three years of Java, they were tired of it already!)

Overall Impressions

Scala 2.8 has some really powerful new features; I'm almost glad I don't have a significant codebase using 2.7, because I would hate to not be able to use 2.8
The conference had a wide variety of talks, at varying skill levels; this was not a "beginners-only" conference, though there were plenty of introductory talks (e.g. the Akka talk).
The Scala team seems very interested in moving Scala into industry and changing the perception of it as an "academic" language (though I'm not convinced they know what to do, nor should this be their responsibility).
Most people I talked to who weren't using Scala at their jobs were looking at the strategy I had employed (using it for better testing), or were just frustrated with not being able to take advantage of Scala's productivity.
Scala's flexible syntax and powerful constructs are being used for a very wide variety of things; there were talks on using it for Processing, parallel collections, and cross-compilation to non-standard architectures (i.e. chips with no JVM available).
The term "monad" was mentioned during exactly one talk and not at all for the rest of the conference. This made me feel very good, because the impression I get on the Scala mailing list sometimes is that if you don't understand mathematical type theory, you are a moron who can never understand Scala. This impression has been proved false.

Talks I Attended

It was very interesting to compare this conference to a No Fluff Just Stuff conference. At those, the speakers are professional, both in that they are getting paid and that they are just, really, really good at speaking and presenting. Their talks, however, tend to be introductory and not terribly advanced. I think that's fine, these are the type of speakers you want to have when you need to "get the message out" on some new and interesting technologies.

The speakers at ScalaDays, however, were just regular people using Scala and wanting to talk about it. As such, things like presentation style and slides were highly varied in terms of quality. That being said, even the speakers who had the most trouble, still had some interesting things to talk about. Following are my quick thoughts on each of the talks I attended:

Opening Keynote

by Martin Odersky

His talk was on the new features of Scala 2.8 which, as I said above, are quite exciting. Package objects, new collections library, and default/named arguments are just some of the highlights. All-in-all, some very exciting features.

Runing Scala in the Browser

by Wolfgang Kuehn

He had created a way to write Scala code and turn it into JavaScript, much like how GWT does this with Java. His approach wasn't geared around UI widgets, however, but in creating AJAX applications using WebSockets. I've always felt JavaScript was assembly language (which is why I think coffeescript is so interesting), and this was another way to leverage JavaScript without having to deal with it.

Scala Parallel Collections

by Aleksander Prokopec

This was a preview of a Scala 2.8.1 (or later) feature, where a subpackage of the new 2.8 collections library was created that could perform the collection operations in parallel. Consider a filter on a collection; this is highly parallelizable. This library is being created to basically implement that in a transparent fashion. Really interesting stuff. They had even considered load balancing, via some interesting work-stealing mechanisms. In only 30 minutes, there wasn't a huge amount of detail, but this seems to be another way in which parallel computation could be done very easily.

Developing the Scala Bindings to the Fly Object Space

by Channing Walton, Nigel Warren, Simon Kent

The concept of "object spaces" never really sunk in with me, but it wasn't actually that relevant to the talk. This was basically a comparison of a Java library and it's straight-port to Scala. As expected, the Scala implementations were all much more succinct and (to me) clear. The speakers hadn't used a lot of Crazy Scala Magic™ to achieve the real code reduction that was shown. This talk made it very clear that even if you write "Java in Scala", you still get a lot of productivity gains.

CCSTM: Library-based STM for Scala

by Nathan Bronson, Hassan Chafi, Kunle Olukotun

Software Transactional Memory is one of the go-to features of Clojure. Clojure supports it natively, while Scala does not. This talk was on an implementation of STM as a library for Scala. It seemed relatively simple to use and understand. While it's not as "clean" as the Clojure way of doing things, the speaker made a solid case for a library implementation being a better tradeoff, given the difficulty in adding it to the language at this point in Scala's life (it's easy to forget how mature the Scala language and compiler are, despite how "new" it seems).

Lightweight language support for type-based, concurrent event processing

by Philipp Haller

This talk proposed a function type called "Translucent Functions" that were better-suited to concurrency than the partial functions used in the actor library. Honestly, it was a bit over my head, and I wasn't able to catch up with the speaker. Perhaps the paper would be more elucidating for me.

Data Parallel Programming in Scala

by Bruce Lester

This talk was very similar to the one on Scala Parallel Collections. Here, the speaker had created a collection library separate from the Scala one, designed specifically to allow parallel processing. He had a very different approach, using control structures to indicate areas where parallelism could occure. It was pretty interesting, but the Scala 2.8 Collections Library implementation seemed a lot cleaner to me than this.

Type Specialization in Scala

by Iulian Dragoș

One of the new features of 2.8 is the ability to "specialize" your code to work with primitive types and avoid boxing/unboxing. This is something Java cannot really do. This talk was an overview of how that worked and what specializations were done to the Scala library. I guess it's nice that this kind of optimization if available, but I think it would have negligible gains for most real-world applications that weren't doing constant number crunching. Even in that case, you don't necessarily need this.

Leaky Monads

by Josh Suereth

How could I not attend the only session (and mention!) of Monads? The speaker gave a good overview of using Monads to implement automatic resource management (e.g. File.open { |file| file.readlines.whatever }). The idea was that since Monads are designed to hold onto the objects they manage, it's a bit inconvienient when dealing with the results of operating on managed resources. Thus, his monads "leaked" their contents to create more concise code.

Type-safe SQL embedded in Scala

by Christoph Wulf

Akin to LINQ, this talk showed how to write SQL directly inside Scala code, but maintain type safety. It uses a compiler plugin to achieve this, and he talked a lot about how to tell the difference between embedded SQL and regular Scala code. I guess the plugin introspects your database to get the types and generates a bunch of code using some Scala classes that get substituted in during compilation. Pretty interesting. I'm not sure I'm really missing SQL right in my code, but it is certainly cleaner than JDBC.

Scala at LinkedIn: Distribute Computing with Norbert

by Chris Conrad

This was a talk about how LinkedIn is using Scala to glue together some enabling technologies to create their social network graph. It seemed really clean and simple, especially since the underlying technologies are all Java-based. This was mostly an overview of the API and some usage examples. It's open source, and looks pretty interesting. I'm not sure it would be useful for me at my job, but definitely seems like a cool project.

Akka

by Jonas Boner

I was looking forward to this one quite a bit, as akka gets a lot of hype on Twitter. I think 30 minutes was just too short, as it was pretty light on details. There was a lot of assertions about Akka that the speakers just didn't have time to elucidate or substantiate. I would love to see a comparison of Scala Actor vs. Akka Actor code and discuss why the Akka way is better. Similarly, I'd love to see the basis for all the assertions on Akka's performance; it certainly gets a lot of hype. Jonas is currently working on publicizing the production deployments of Akka (which would go a long way) as well as establishing commercial support for it (which also goes a long way :).

Scala IDE for Eclipse

by Miles Sabin

I went to this purely for my co-workers. I hate IDEs in general, and Eclipse does some pretty evil things to my co-workers, yet many of them still swear by it. At any rate, Miles was almost impossible for me to understand (despite being English!) and most of what I got out of the presentation was that Eclipse was very much designed to work with only Java, requiring some nasty hacks to get Scala working with it. It seems Miles' Herculean efforts have been used to get around this and there now seems to be a nice development environment for extending and enhancing the Scala plugin.

sbt Design and Implementation

by Mark Harrah

While sbt isn't my ideal build tool, but it's a billion times better than Maven and Mark's talk actually made me appreciate it a lot more. He is unabashedly in favor of terse symbols over long method names, and he spent some time explaining the rational behind them (thus making things make a bit more sense). His assertion is that you will eventually internalize the symbols and achieve productivity gains at a cost of a slight bump at the start. I tend to disagree with this, because how often is one modifying their build? This is why learning and retaining Ant and Maven is so difficult (I can't write a copy in Ant without a trip to the docs). At any rate, this was a good talk and great overview of sbt, and, despite me not being into the crazy symbols, I will take it over Maven or Ant any day. At least it's based in a real programming language and not some XML nonsense.

Processing with Spde

by Nathan Hamblen

This was a brief over of Processing, for those unfamiliar with this (horribly‐named) visualization tool and then a review of the Scala bindingns the presenter had created. Interestingly, he created SPDE as an SBT plugin so that users could gain the benefit of SBT's automatic re-compilation and running features. His plugin + a text editor is a makeshift IDE for Processing, which is pretty cool. It was very high-level and didn't get into too much detail, but the Scala code was, as expected, much more concise than the Java code.

Sneaking Scala Into your Organization

by Me!

I was pretty nervous, as the many of the previous speakers' topics were all quite heady, but I had practiced my ass off, and delivered the talk as well as I could. I think it was pretty well received and got some good questions. I had talked with a few people previously in the conference who were using testing as a way to get Scala into their jobs and a few other people who were interested in what I had to say. Several people were curious as to how the other developers at OPOWER liked Scala. I felt pretty good about it.

Future of Scala

by The Scala Team

For this, we broke into small groups and basically unloaded on a poor member of the Scala team as to how anything related to Scala could be better. Then, the Scala team assembled all of this info while Martin gave a very long term roadmap for Scala. I do worry that the universe will never catch up to Martin and Scala team as they add more and more advanced and innovative features.

After this, a member of the Scala team did a very fast tour of the feedback. I wish the entire list could be posted; there was a lot of very heartening complaints in there that would not be obvious from the Scala mailing list (e.g. hate on the underscore, desire to be less academic in terminology) This fed my (arguably self-biased) impressions that people want to get Scala into industry and that there is a large hole in this part of the Scala universe.

There were also some updates on IntelliJ's support for Scala. They sound way ahead of the curve compared to Eclipse and NetBeans, but I was a bit frightened by IDEA's guy saying that they way people learn languages is to ask for auto-completion and see what's available. I see this trend all to often and I think it's harmful. More on that later.

Overall

Despite still being stuck in Geneva, I'm glad I went. Giving my talk was fun, but it was also great to hear about all the many ways in which people are using Scala. I went in expecting massive academia overload, with a lot of theoretical type system and functional programming talk and got, instead, a wide variety of topics and just the right amount of academia (i.e. not that much). Really encouraging. Also encouraging is that ScalaDays 2011 will likely be in the Bay Area, which is a much nicer place to get stuck that stupid Geneva.