Finding Clojure By Playing On The Seaside

The Technitai blog has been far too quiet for far too long, but it’s been because I’ve been burning the midnight oil learning a brand new, for me, way of thinking.

Late last year, I began compiling a list of programming languages and frameworks that I thought that I should at least know a little about. As part of this process, I  sat down with a project idea – a player/event management app for Firefight! That way, I could explore the problem domain and I knew where I could get a subject matter expert if I needed one. Early this past spring, I started digging in.

I started out with Opa, but didn’t get very far. Adam Koprowski, over at Opa HQ was very helpful with answering my early questions. But a few things made it difficult for me to gain traction with the language. The Opa project was transitioning from a Caml based syntax to one based on JavaScript. At the time, the documentation was split between the two which made the going quite rough as I have zero experience with Caml. Compound that with an inexperience in functional programming – well, sit back and imagine the soothing sound of grinding gears.

Opa, I shall be back. Oh, yes. I shall be.

I moved on to Seaside on the Pharo Smalltalk implementation. Six or seven years ago I attempted to dabble with Seaside on Squeak. I wouldn’t call it a crash-and-burn experience but I got nowhere fast. This time around things were totally different. I made some serious headway on the project and I fell in love with the expressiveness of Smalltalk. Years ago, the intrinsic coupling of the language and its environment threw me for a loop. Now I totally appreciate it for its elegance and empowerment. Seaside as a web framework is a stroke of genius. Couple Magritte with Seaside and you’ve got an extremely potent one-two punch for capturing and validating form data on the web. At the conclusion of the prototyping sprint, I felt like I developed an actual application rather than a collection of web oriented components. I thought that I had found my way of developing web apps.

Okay, two more languages were on the short list to check out: Scala and Clojure.

Scala looked the less exotic of the two. The biggest difference being not-LISP. Its syntax didn’t look all that far off from Python and Ruby where I felt quite comfortable. The functional bits could be ignored and used when desired. Kinda like how I was using JavaScript. Besides, it was Lift that put Scala on my RADAR to begin with, so I started heading off in that direction. But something made me pause and reexamine where I was headed.

Each week, I receive The Pragmatic Bookshelf monthly email filled with info on releases, news, and their PragPub magazine. That month they just released Programming Clojure (2nd Edition).

I remembered stumbling onto Clojure when it was new and noting to myself that I should learn-it-someday. I was of course intrigued by what I perceived as its arcane LISPness that verged on the mythical. Back then it was a someday-language. A language to learn someday when I’m suddenly smart enough to learn it.

I bought a copy of Programming Clojure and examined the Clojure web development field but didn’t find a counterpart to Seaside or Lift. Instead, I found stuff called RingHiccup, and Compojure. All of the moving parts had me a bit confused. What was I thinking? Then I found Noir:

Noir is a micro-framework that allows you to rapidly develop websites in Clojure.

And it couldn’t be any simpler.

Sold!

In less than a day, I put my eyes on every character of every word of Programming Clojure. After the once-through, I didn’t intimately understand everything that I read but I got it. On day two I began coding. There were some fits and starts and sudden stops, but soon, I gained some real velocity. After prototyping the Clojure project to be as close as possible to the one done in Smalltalk, I took a step back and thought that while it looked the same in the browser, it was relatively primitive underneath. At first, I thought that I went backwards. But I soon learned that this was a instead a strength.

I did a quick survey of what JavaScript frameworks were out there for building modern web apps. I went with AngularJS. It turned out to be an excellent fit with Noir.

Using AngularJS, I “modernized” the prototype and soon its functionality surpassed the one done in Smalltalk and Seaside. But even more importantly, I understood what Halloway, Bedra, and Hickey were talking about. The lingering doubts that I had about OOP modeling, all the while that I thought that I was good at it, were gone. To top it off, my code base was smaller and just as legible. Don’t get me wrong. My code was quite unpretty here and there and organization in places left much to be desired but those were things that I knew how to fix. And I could fix them without the fixes rippling out across the rest of the system. I freaking learned Clojure!

Okay, back to the mission. I didn’t want the exuberance of learning Clojure to limit my appreciation of Scala so I jumped into it headlong.

There are a lot of good Scala tutorials on the ‘net but I homed in on Programming Scala at O’Reilly. The book itself is a good value too, by the way.

The first thing I did was create a new Scala project to parse the Firefight! ePub in order to pre-populate the database with stuff. I had a heck of a time getting sbt, the Scala Built Tool, to download the project dependencies. Eventually, I gave up and just downloaded them manually. But I did get Scala to parse the XHTML and to insert data into MongoDB.

I’m totally sold on Scala as a scripting language. Having access to all of the libraries that run on the JVM is a huge boon.

As I worked through Programming Scala, I couldn’t manage to gain velocity on the prototype project. A ball of frustration grew inside of me because, as a language, Scala looked familiar. The functional parts were empowering. Traits looked, to me, lightyears ahead of Java Interfaces. After coming off Clojure, there seemed to be so much code but I could have gotten over that if I had a better experience with the build tools, and hadn’t encountered binary incompatibility with compiled libraries, all the while trying to learn both a language and a framework at the same time. It simply felt like too much, and I ran back to Lein.

Scala, Lift, and the Play! framework are all obviously powerful and I’ll be revisiting them before too long, but I’ve decided to build my app prototype into a full blown product using Clojure.

So, yep. I found Clojure by playing on the Seaside.

Useful Books For Developing Your First iPhone App

A few years ago I wrote a few small apps for OS X so I had some working familiarity with Objective-C but it was quite rusty. I turned to Cocoa Programming for OS X by Aaron Hillegass to shake off some of that rust.  Enough language fundamentals are presented in the book to be quite useful for iPhone development as well.

I flipped through every iPhone dev book on the shelf at Barnes & Noble and Borders, checked out every book preview that I could get my hands on. One of them stood out for its clarity when I was still trying to figure out where to start. iPhone Application Development For Dummies.  The book shows you around the various iPhone projects in Xcode, shows how to put a couple of apps together, walks you through the steps of provisioning your device, and gives you pointers to further exploration.  No deep concepts here but it really helped me get started.  I felt as if I was spinning my wheels till I purchased this title.

Once I had the basics under my belt I began to look for code examples and snippets in earnest.  The sample projects at the Apple iPhone Dev Center are outstanding but sometimes it’s hard know exactly where to look for a particular concept.  So I turned to the iPhone Developer’s Cookbook.  While I don’t think that the book is spectacular I did find myself referencing it again and again.  Most often I’d get enough out of the cookbook to continue smarter searching on Google.  This leads me to the next group of books.

Initially, I figured that I was going to persist application data as a plist file using Cocoa convenience methods to do the work.  I took a step back, peered over the horizon and saw Core Data.  I knew that if I wanted to build professional chops I should learn it.  So, I scrapped my data model class and jumped in.

Searching online wasn’t much help until I found a thread on a forum where someone asked about books. (Boy, I wish I remember the thread so I could give credit now.)  The guru in the thread linked two books.  iPhone SDK Development and Core Data: Apple’s API for Persisting Data on Mac OS X, both from the Pragmatic Bookshelf. I had seen both of them at a local Borders so off I went.

To be honest, earlier in my book finding foray I intentionally skipped over both titles even though I’ve put the Pragmatic Rails books to great use.  When I first saw iPhone SDK Development it looked like it was for folks doing 70 MPH when I was grinding the transmission getting into first gear.  I blew off the Pragmatic Core Data book because I thought it was for just the desktop.  Teaches me not to look closer.  These two titles were absolutely invaluable in getting Core Data into my first iPhone app.  They explain the entire Core Data stack, how and why.

So, hopefully this list can be of some use to someone else working to get their first app out the door.

Pop View Controller

In my iPhone app Hip Pocket AAR Writer I have a preview UIView that shows the assembled After Action Report.  From the preview view the user is given the option to delete the current AAR effectively wiping the slate clean.  At first deleting the AAR put a kink in the app’s workflow. Then it dawned on me. I’ve got the navigationController already. What if I asked it to pop the view?

Voila.

  1. [self.navigationController popViewControllerAnimated:YES];