Conj Labs: The Blog

Code snippets and considerations relevant to students of functional programming and the alumni of Conj Labs events. Visit Conj Labs

[conjlabs-blog]

Calabash-Script - iOS Test Automation using ClojureScript

h1, h2, h3, h4, h5, h6, p, blockquote { margin: 0; padding: 0; } body { font-family: "Helvetica Neue", Helvetica, "Hiragino Sans GB", Arial, sans-serif; font-size: 13px; line-height: 18px; color: #737373; margin: 10px 13px 10px 13px; } a { color: #0069d6; } a:hover { color: #0050a3; text-decoration: none; } a img { border: none; } p { margin-bottom: 9px; } h1, h2, h3, h4, h5, h6 { color: #404040; line-height: 36px; } h1 { margin-bottom: 18px; font-size: 30px; } h2 { font-size: 24px; } h3 { font-size: 18px; } h4 { font-size: 16px; } h5 { font-size: 14px; } h6 { font-size: 13px; } hr { margin: 0 0 19px; border: 0; border-bottom: 1px solid #ccc; } blockquote { padding: 13px 13px 21px 15px; margin-bottom: 18px; font-family:georgia,serif; font-style: italic; } blockquote:before { content:"\201C"; font-size:40px; margin-left:-10px; font-family:georgia,serif; color:#eee; } blockquote p { font-size: 14px; font-weight: 300; line-height: 18px; margin-bottom: 0; font-style: italic; } code, pre { font-family: Monaco, Andale Mono, Courier New, monospace; background-color: #222; } code { color: white; padding: 1px 3px; font-size: 12px; text-shadow: none; -webkit-border-radius: 3px; -moz-border-radius: 3px; border-radius: 3px; } pre { display: block; padding: 14px; color: #D8FA3C; margin: 0 0 17px; text-shadow: none; line-height: 16px; font-size: 11px; border: 1px solid #d9d9d9; white-space: pre-wrap; word-wrap: break-word; } code pre { margin-bottom: -20px; } pre code { background-color: #fff; color:#737373; font-size: 11px; padding: 0; } @media screen and (min-width: 768px) { body { width: 748px; margin:10px auto; } } body { color: #EDEDED; background-color: #000000; } .builtin { /* font-lock-builtin-face */ color: #FF6400; } .constant { /* font-lock-constant-face */ color: #4c83ff; } .keyword { /* font-lock-keyword-face */ color: #FBDE2D; } .string { /* font-lock-string-face */ color: #61CE3C; } .variable-name { /* font-lock-variable-name-face */ color: #D8FA3C; } a { color: inherit; background-color: inherit; font: inherit; text-decoration: inherit; } a:hover { text-decoration: underline; } By Karl Krukow, co-instructor at Conj Labs - professional Clojure training

This post serves as an introduction to CalabashScript which lets you test iOS applications using ClojureScript.

But first (as required by the Clojure community), The Rationale:

Rationale

Apple provides a technology called UIAutomation which allows one to use JavaScript to write automated tests for iOS apps.

The good thing about UIA is that it is officially supported by Apple, you can test any app built for debugging, and it is quite featureful: You can do things like locking the screen, turning volume up/down or even simulating a 'Shake' on the device.

Unfortunately, from a developer's perspective, UIAutomation (UIA) has several problems: tests are written in JavaScript using a verbose and rather awkward API. For example, this line of code finds the text "Chocolate Cake" in a table:

UIATarget.localTarget().frontMostApp().mainWindow().tableViews()[0].cells()[0].elements()["Chocolate Cake"];

Of course this could be shortened by introducing local variables, but the problems of UIA remain: one must explicitly and imperatively navigate through the view hierarchy. The explicit view structure, and imperative nature of the code leads to verbose tests that tend to be phrase too specific assertions.

UIA elements are represented using a proprietary API containing some awkward types that get us into an expression-like problem. For example, UIAElementArray which is not an array, and UIAElementNil which has unclear semantics.

Finally, the development experience is no less than horrible, IMHO. Ignoring for a moment bad and missing documentation, and the flawed instruments tool, my top problems are: No debugger, no stack traces, horrible error messages. Here is one:

2013-01-10 20:18:47.823 instruments[20240:1603] -[__NSCFBoolean makeNewlinesNotSpecial]: unrecognized selector sent to instance 0x7fff7709c020 Instruments Trace Error : -[__NSCFBoolean makeNewlinesNotSpecial]: unrecognized selector sent to instance 0x7fff7709c020

An Objective-C unrecognized selector from the underlying tool, no line number or anything that can point me back to the source. What did I do to deserve this error? I tried to log a boolean:

var elements = UIATarget.localTarget().frontMostApp().mainWindow().elements(); UIALogger.logMessage(elements instanceof Array); //the answer is false in case you're wondering

As you can imagine, I could go on, but let's instead focus on CalabashScript.

How does CalabashScript help?

Some of the mentioned problems are inherent to the UIAutomation technology while others can be solved to some degree. CalabashScript tries to solve some of the problems by replacing JavaScript with ClojureScript and providing

a data-centric model of the view hiearchy

a query language to declaratively find views (avoiding explicit hierarchy traversal)

providing a REPL for interactive exploratory development

providing high-level functions for interacting with views based on this query language (tap, pan, swipe etc).

Getting Started

You can read installation instruction on the CalabashScript github repo. Once you've setup a dependency on CalabashScript, you can define simple tests in ClojureScript. Key to writing these tests is understanding the query language. The query language is a language inspired by that in our testing framework: Calabash iOS. The idea is to declaratively find UI objects using queries which are like css selectors but phrased in terms of ClojureScript data structures. For example

[:button {:marked "Edit"}]

UIAButtons with "name" or "label" equal to "Edit". You can also (declaratively!) describe partial hiearchy:

[:navigationBar :button {:marked "Edit"}]

This query finds the same buttons, but only if they are descendants of a UIANavigationBar object.

For many tests, you rely on iOS accessibility labels, which are usually unique on a screen. For locating by accessibility label you can use [:view marked "Label"].

The result of the query function is a regular lazy ClojureScript Seq of maps, so you can use all the Clojure data functions to define your test scripts:

(when-not (seq (query [:view {:marked "Olympic Water Polo, past and present"}])) (fail "Olympic Water Polo, past and present"))

There is also a built-in helper function for this: (check-element-exists [:view {:marked "Edit"}]).

The query language is really useful in giving you the power of ClojureScript to write your tests in a declarative manner. The CalabashScript API exposes functions for tapping, typing and panning (drag-drop) - all based on queries. For example, a drag gesture from one table cell to another can be quite hard to express in pure UIAutomation - with CalabashScript

(pan [:tableCell {:marked "Cell 0"} :button] [:tableCell {:marked "Cell 2"} :button])

Finally you can group tests using define-uia-test. Here is a simple example:

(define-uia-test "Archery details should be accessible via Events" (fn [] (tap-mark "Events") (utils/screenshot "Events") (sleep 3) (scroll-to [:view {:marked "water polo"}]) (utils/screenshot "Events") (tap-mark "water polo") (sleep 2) (when-not (seq (query [:view {:marked "Olympic Water Polo, past and present"}])) (fail "Olympic Water Polo, past and present")) (utils/screenshot "Water polo details")))

Notice you can generate screenshots using utils/screenshot.

There are many more functions that what can be described in this introductory post. You can study the main API here: https://github.com/krukow/calabash-script/blob/master/src/cljs/calabash_script/core.cljs.

What else? A REPL!

One of my favorite things about Clojure and ClojureScript is the development experience, and particularly the REPL. The REPL gives us a way to explore APIs, try out small snipplets of code, work in an ad-hoc and exploratory way with data and functions, read documentation etc.

ClojureScript runs where JavaScript runs, but each JavaScript environment usually requires a separate implementation of a REPL. The classic and awesome example is the Browser-connected REPL (by Brenton Ashworth). Another cool example by Bodil Stokke (@bodil) is the REPL for Node.JS.

A great thing about ClojureScript is that to create a REPL for a new environment, you only need to implement a 4-function protocol.

UIAutomation is a separate JavaScript execution environment, so none of the existing REPLs work with it. However, with inspiration from Bodil's implementation, I've created a simple REPL for UIAutomation, which means that CalabashScript has a REPL!

The UIAutomation REPL can be used to play with the CalabashScript API, explore your iOS app, shape your automated tests and play with the UIAutomation APIs. To use the REPL you add a dependency on calabash/uia-repl (leiningen [calabash/uia-repl "0.0.9"]) in your CalabashScript project. With this in place, start a regular Clojure REPL. Here is an example session from the sample project (use instructions there to follow along):

user> (require '[cljs.repl.uia :as uia]) nil user> (def app-path "/Users/krukow/github/2012-Olympics-iOS--iPad-and-iPhone--source-code/2012 Olympics/build/Applications/2012 Olympics.app") #'user/app-path user> (uia/run-uia-repl :app app-path) [instruments -t /Applications/Xcode.app/Contents/Applications/Instruments.app/Contents/PlugIns/AutomationInstrument.bundle/Contents/Resources/Automation.tracetemplate /Users/krukow/github/2012-Olympics-iOS--iPad-and-iPhone--source-code/2012 Olympics/build/Applications/2012 Olympics.app -D run/trace -e UIARESULTSPATH run -e UIASCRIPT /var/folders/63/lq05__ys7xjfcw7fn6vpz6fc0000gn/T/uia-repl4390725227287728864.js] ...

The REPL is a bit slow to start up. This is an artefact of UIAutomation's JavaScript environment. We are using a bit of a hack to get dynamic JavaScript evaluation going in this environment (UIAutomation wasn't designed with this use case in mind!). First of all, you can only evaluate one chunk of JS code per second, and secondly chunks need to be split because there is a size limitation. Fortunately ClojureScript comes with the Google Clojure Compiler which makes it easy to parse up JavaScript and split it on a semantically valid position.

From here we can play with CalabashScript and explore the app (the open source 2012 olympics app in this case):

ClojureScript:user> (ns example (:require [calabash-script.core :as c])) ... ("calabash-script.core") Loading files for (calabash-script.core) ClojureScript:example> (c/names :button) ;; explore names/labes of all buttons on screen ("Home" "Events" "Count Down" "Schedule" "Anthem") ClojureScript:example> (c/tap [:button {:marked "Events"}]) ;; go to events ClojureScript:example> (c/scroll-to [:view {:marked "water polo"}]) ;; scroll to water polo ClojureScript:example> (c/query [:button]) ({:name "archery", :rect {:x 20, :y -1595, :height 101, :width 101}, :hit-point {}, :el #<[object UIAButton]>, :label "archery"} {:name "athletics", :rect {:x 199, :y -1595, :height 101, :width 101}, :hit-point {}, :el #<[object UIAButton]>, :label "athletics"} {:name "badminton", :rect {:x 20, :y -1486, :height 101, :width 101}, :hit-point {}, :el #<[object UIAButton]>, :label "badminton"} ;... )

I'd like a screencast...

OK! I've dumped to short screencasts on youtube showing CalabashScript running, and showing the UIAutomation-based REPL. Enjoy!

This link demos running a plain CalabashScript test.

This link demos CalabashScript in a UIAutomation-based REPL.

What is the status on CalabashScript

I find CalabashScript useful, and would use it in cases where a client would require that I use UIAutomation instead of Calabash. I've developed CalabashScript as a proof of concept and as an exercise in ClojureScript. I will maintain it on a hobby basis, but encourage contributions and would love to see a community form.

Where can we meet?

Well if you don't want to keep meeting like this... :) Please join Lau and I on our professional Clojure training: ConjLabs

[conjlabs-blog]

Pay it back!

.gist .gist-file .gist-data .gist-highlight{ font-size: 80%; } By Karl Krukow, co-instructor at Conj Labs - functional programming training

As Clojure users we leverage Java libraries all the time. In fact, many popular Clojure libraries and tools we use in everyday programming either use, are based on, or directly wrap Java libraries and tools. Of course, these Clojure libraries aren't dumb wrappers - they almost always provide idiomatic and functional Clojure interfaces to otherwise Java'ish libs. So as Clojure users we are happy to see good Java-based libraries. This is one of the powers of the JVM: any contribution to the ecosystem of a single JVM language is a contribution to all JVM languages. At least in theory…

What are we contributing?

Are Java users happy when a new Clojure library appears? Well most of the time, no - they're jealous! While you can simply call Clojure from Java you can't easily. Here is an example from the highly recommended Clojure Programming:

https://gist.github.com/3668983.js?file=grand-carper-emeric.java

So we can access Clojure via the runtime class clojure.lang.RT. In the example, the var method gives us access to a Clojure var in a namespace and the fn method dereferences the var as an IFn. Thus requireFn is a plain Java object that implements the IFn Java interface representing a function (in this case the require function). An IFn can be called with the invoke method. So while calling Clojure functions from Java is definitely possible, it is inconvenient and requires knowledge of Clojure internals.

For a Java programmer, this isn't an easy way to leverage a Clojure library. In fact, things are even worse: In Clojure, the preferred style for an API is to expose (pure) functions that take data structures as input and return data structures as output. In Clojure this is concise and powerful because of literals and since Clojure provides much leverage for working with data. But creating data structures in Java isn't as concise, which makes invocation of Clojure functions in Java quite verbose. Further, in an idiomatic Clojure API, the functions that take maps as input often require those maps to use Clojure keywords as map keys. Obviously Java hasn't got literal notation for Clojure keywords making creation of such maps more awkward.

For example, supposed I wanted to use Incanter in Java. I just want the equivalent of Clojure: (view (sample-normal 1000 :mean -2)):

https://gist.github.com/3669508.js?file=example-incanter.java

A little helps a lot

Let's look at a few simple things you can do to contribute more to the JVM ecosystem. You'll also get some easy techniques to increase the chance of introducing Clojure and functional programming in enterprises: You can show the organization how you can easily build part of a system in Clojure, and the rest in Java or other JVM languages. In most organizations, getting in is the hardest part -- you can always spread from there :)

If our library provides an API which is more easily accessible from Java, not only are we making the lives of Java programmers wanting to use our library easier, but we are helping all JVM languages since they can all interop with Java quite well.

Here are three small things we can do to iron out (some of the) mismatches, making the lives of our JVM fellows Less-Painful (sorry couldn't help the cheesy reference!).

We can use Clojure's gen-class to create regular a Java class exposing the API functions as typed Java static methods.

We can provide bridging helpers that makes calling your API functions less verbose.

Finally, we can make sure our APIs don't insist on taking Clojure data structures as input unless there is a good reason to do so.

I'll elaborate a bit on each of these below. As an example, I'll use Calabash JVM because it is fairly small, and because I'm using these techniques myself in that library.

A bit of gen-class

The macros gen-class, gen-interface, deftype, defrecord, defprotocol all generate Java classes or interfaces when you AOT compile your Clojure library, and thus can be used for interop. The gen-class macro has many features, and the documentation can be a bit scary. But with a small subset of the functionality you can expose your API easily.

Your Clojure library likely consists mostly of pure functions working on data structures. I believe you should stay true to your library and expose a functional interface, even if it doesn't feel completely native to a Java programmer. As functional programmers we believe that programs consisting mostly of pure functions are more robust, easier to understand and test - and we would program in this style even if we used Java. Exposing functions via static class methods is easy.

https://gist.github.com/3686238.js?file=calabash-jvm-1.clj

For Calabash JVM, I decided to simply expose a class calabash_jvm.API with static methods mapping to the core public API of Calabash JVM. The :methods vector is a list of static methods (^:static), for example recordEnd takes a single String argument and returns a String.

There are of course more methods than recordBegin and recordEnd but these are the simplest since they just take and return Strings. They can easily be called from Java (e.g., calabash_jvm.API.recordEnd("my_gesture")).

In Java we can even use import static to make this even less verbose:

https://gist.github.com/3686299.js?file=calabash-jvm-java-import-static.java

You can easily expose simple functional APIs using gen-class. Java users can use import static to leverage the API in a concise manner.

Briging the gap

Calabash JVM uses a simple query language for finding view components in mobile apps: Queries are simply values (data structures). Focusing on data is the recommended way of creating DSLs in Clojure, but less so in Java. Often queries in Java would be phrased in terms of strings: here is an example from the Spring docs

String sql = "select id, first_name, last_name from T_ACTOR" + " where specialty = ? and age = ?"; //... simpleJdbcTemplate.queryForObject(sql, mapper, specialty, age);

Here is a slightly different example in ClojureQL by Lau

(select users (where (either (= {:id 1}) (>= {:id 10}))))

Notice how this query is phrased in a DSL in terms of data structures and pure functions.

So how can we bridge this difference? By providing a Java API which is implemented in terms of data structures, but supports both data structures and Strings.

How? With Calabash we use a simple idea from the Datomic Database API which also provides a Java API: give Java users the ability to use strings to query. Here is an example from the Datomic page:

String uri = "datomic:mem://test"; Connection conn = Peer.connect(uri); Collection results = Peer.q("[:find ?e :where [?e :db/doc]]", conn.db);

Focus on the Peer.q method: the API allows String-based queries, but those strings are exactly the literal notation for the corresponding Clojure data. This doesn't mean that Java users can't call the API with data structures, it just means they have the option of using strings for simpler queries. In Datomic, the Peer.q method actually allows taking either a String or a Data structure (list or map) resulting in a fairly generic type signature

public static java.util.Collection<java.util.List<java.lang.Object>> q(java.lang.Object query, java.lang.Object... inputs)

With Calabash JVM I wanted the same, but decided to decompose it slightly. The core Clojure API functions take data structures as input. As with Datomic, this is also exposed to Java as static methods on a gen-class'ed class. However we also expose the parsing function which takes a strings and produces the corresponding query data structure (this function is also called q since it constructs queries). This means that the parsing function can be used outside of queries. For example you can create a data structure from Java using:

API.q("[:UIView {:text "Karl"} (index 1)]")

Now we can expose the Calabash JVM query function as two methods: query taking a data structure, and queryq taking a string. Users can call query with a data structure representing the query, they can call queryq with a string representation of the query, or the can construct a data structure with a string using q and then pass that to one or more calls to query.

https://gist.github.com/3686995.js?file=calabash-jvm-more-genclass.clj

Implementing q in Clojure is very easy. Since the input string is a Clojure literal, we can use clojure.core/read-string. The only slight challenge is that we allow DSL functions like index, css and xpath without their namespace. So we simply replace these with their corresponding namespaced functions.

If your API uses data structures a lot consider providing helper functions that will let Java users create data structures in a concise manner. Exposing a parser method, like q above or Peer.q in Datomic, is an easy way of doing this for small data structure creation.

Types of data

When we expose a static method to Java which takes a data structure as input, we should allow non Clojure data types. For example, the canonical query in Calabash JVM uses Clojure vectors and keyword. However, they will work with any java.util.List and with strings instead of keywords. To get this increased compatability you should ensure that you are not implicitly relying on Clojure data structures. For example a Clojure map can be called as a function: ({:a 42 "b" 11} "b"). This is neat, but relying on this in your API functions is a bad idea since it restricts the API to Clojure maps. For example: '

(let [m (java.util.HashMap.)] (.put m "a" 42) (m "a"))

Fails with a "java.util.HashMap cannot be cast to clojure.lang.IFn." Another example, where Clojure data types are required (here from Incanter):

List a = Arrays.asList(1,2,3); viewFn.invoke(a); //Fails: multimethod not defined for java.util.ArrayList //But this is OK: viewFn.invoke(clojure.lang.PersistentList.create(a));

In this example, the Incanter API accepts only Clojure data types, even when any java.util.List could have been used.

Finally, it may be a good idea to map between Strings and Keywords at the API borders. At the input, you could transform map String keys to Clojure keywords, and at the output map back to Strings. Here clojure.walk/keywordize-keys and clojure.walk/stringify-keys are useful.

For increased compatability try to let your public API functions accept the Java collection types instead of only Clojure data structure (unless there is a good reason to do so). Consider whether it is useful to translate between keywords and Strings at the API borders.

Conclusion

In Clojure we use Java libraries and tools all the time. When we create libraries we can make those libraries more easily accessible from Java using a few simple techniques that don't even require much Clojure or Java knowledge. If you are working in an enterprise project which doesn't allow Clojure, you may be able to get off with programming part of the project in Clojure, and then exposing a well-defined API to Java. Then spread from there!

[conjlabs-blog]

New Faces In Old Places

Ladies & Gentlemen, I am pleased to announce that after a 1 year break, Conj Labs is back in business. The very first Conj Labs was held in Brussels at the excellent Mercure Louise Hotel. At that time I had teamed up with Christophe Grand to provide intense technical Clojure training, but earlier this year we amicably discontinued our working relationship. Christophe has very strong insights into Clojure itself and has spent significantly more time working on the language Clojure, than actual Clojure Projects. In the reinvisioned Conj Labs we want to put a greater emphasis on how Clojure and the lessons you can learn from it can strengthen your daily work, even if you don't have the luxury of programming in Clojure 5 days a week. For this reason I'm proud to announce, that I have teamed up with Karl Krukow of former Trifork stardom and current CTO @ [LessPainful](http://www.lesspainful.com). Karl has worked on numerous enterprise-level projects in a several different languages, though chiefly C# and Java. In regards to Clojure Karl is a specialist and has been using the language for almost 5 years now. He was also an attendant at the first Conj Labs. Together we will be providing Clojure training which is aimed at developers looking to learn Clojure from the ground up as well as beginner-level Clojurians. The functional paradigmes and Clojures unique approach to parallelism provides an opporunity to grow immensely as a developer, which will be of great benefit to you and your customers, whether you use Clojure or not. You can read more about this concept at [Conj-Labs.EU](http://www.conj-labs.eu) and at the bottom there's a sign-up form if you wish to attend our October Lab. A huge thanks to Christoph for all his hard work and a warm welcome to Karl. Lau B. Jensen [Bestinclass.dk](http://www.bestinclass.dk)

[conjlabs-blog]

Google Code Jam

These Google challenges are typically a great suit for functional languages as the point is often to arrive at an algorithm which you can apply to the problem at hand. When reviewing the solutions, it is interesting to compare high/low level languages as well as imperative/funtional languages. After having solved the problem, I went to find other solutions on Google and here is one I came across written in Java: [Java Solution](http://www.harshadura.net/2012/04/googlecodejam-my-answer-algorithm-for.html) # The Java Solution When reading the solution I notice the following: * The developer spent 1.5 hours on it * A large part of the code is spent on reading/writing files * The translator itself is hardcoded - the program does not learn from the data # The Problem You can read the official explanation here: [Challenge #1](http://code.google.com/codejam/contest/1460488/dashboard) The short version is this: Google provides you with an unreadable language for which you must develop a translator. In order to make the translator you get 3 lines of pre/post translated text as well as 3 character mappings. The task is then to discover the remaining 24 mappings. # Repl Play Since we’re trying to produce mappings can start by constructing a hash map where the keys are english characters and the values are the Googleresesian counterparts, so lets begin by loading the sample: (def input ["ejp mysljylc kd kxveddknmc re jsicpdrysi" "rbcpc ypc rtcsra dkh wyfrepkym veddknkmkrkcd" "de kr kd eoya kw aej tysr re ujdr lkgc jv"]) (def google ["our language is impossible to understand" "there are twenty six factorial possibilities" "so it is okay if you want to just give up"]) In order to produce the initial mapping all we have to do is traverse each character in each string and store the relation: (->> (map #(map (fn [i g] (hash-map i g)) %1 %2) input google) flatten (apply merge)) {\space \space, \a \y, \b \h, \c \e, \d \s, \e \o, \f \c, \g \v, \h \x, \i \d, \j \u, \k \i, \l \g, \m \l, \n \b, \o \k, \p \r, \r \t, \s \n, \t \w, \u \j, \v \p, \w \f, \x \m, \y \a} The outer map walks the strings, the inner map walks the characters of each string, returning a hash-map with the key/val pair. All that’s needed is now to manually add the mapping given by Google in the explanation of the problem: (def dict (assoc *1 \z \q)) The *1 is simply short-hand for “the last result of evaluation”, in this case the mappings. With the dictionary, dict, defined, we can look up simply by calling it as a function (dict \a) > \y Here we see that an “a” translates to a “y”. To make a translate function all we have to do is call dict on every character and then return the resulting sequence of characters as a string: (defn translate [in] (apply str (map dict in))) The code becomes very succinct, partially due to the fact that hashmaps can be called as regular functions, ie. the first argument to map. Now all of the work is basically done and all we need to do is apply our translate function to the dataset and properly format our output: (def input (-> "A-small-practice.in" reader line-seq rest)) > input The input file to Google is cast to a reader then read as a sequence of lines, dismissing the first line which simply contains an integer which we don’t need. With a sequence of strings in input we could simply run (map translate input) and that would produce the correct translation, however to properly format the output we need to add an index and some text: (doseq [[idx txt] (map #(vector %1 %2) (range) s)] (println (str "Case #" (inc idx) ": " (translate txt)))) Case #1: our language is impossible to understand Case #2: there are twenty six factorial possibilities Case #3: so it is okay if you want to just give up Case #4: xoggk d yl wxo vkkvgo ekso uyl wonw sywy Case #5: xkf yto akj Case #6: yabba dabba yabba dabba yabba dabba yabba dabba yabba dabba yabba dabba yabba dabba yabba dooooooooo Case #7: a b c d e f g h i j k l m n o p q r s t u v y w x y z now i know my abcs Case #8: next time wont you sing with me Case #9: for those who speak in a tongue do not speak to other people Case #10: nobody understands them since they are speaking mysteries in the spirit Case #11: this is so exciting i have to go the bathroom Case #12: it was the best of times it was the blurst of times Case #13: let lips do what hands do Case #14: this here is gunpowder activated twenty seven caliber full auto no kickback nailthrowing mayhem Case #15: i have bested fruit spike and moon now i shall best you the guy Case #16: oh hai im in ur computer eating your cheezburgers and googleresing your textz Case #17: an eye for an eye and a pigeon for a pigeon Case #18: all your base are belong to error the spoony bard Case #19: you pissed off the chicken lady Case #20: now is the summer of our lack of discontent Case #21: by the pricking of my thumbs something wicked this way comes Case #22: in a world of direwolves and lions sometimes the rarest creature is a friend Case #23: greetings cheese popsicle the number you have dialed is currently out of porkchops Case #24: why do programmers always mix up halloween and christmas Case #25: im commander shepard and this is my favorite problem on the google code jam Case #26: f of two equals f of one equals one Case #27: for i between three and n f of i equals f of i minus one plus f of i minus two Case #28: how are you holding up because im a potato Case #29: dr zaius dr zaius dr zaius dr zaius ooooooooooooh dr zaius Case #30: whoooooooooooooooooooaaaaaaaaa i know c plus plus # Conclusion Working in a high-level language allow you to express your thoughts very quickly and succinctly. Over time, working with high-level languages, changes the way you think about problems allowing you more easily to see the bigger picture. To this end Clojure has been an excellent companion. The above program took only a few minutes to write and never made it as far as a file, it was simply written in the REPL while playing with the data. To put it in perspective a 1.5 hour task was reduced to a few minutes and a very lengthy solution was boiled down to a couple of lines of Clojure. Had this not just been a single function, but a larger project, the cost analysis makes Clojure a very attractive language even though it may require an initial investment of time to train your employees/co-workers. Thanks for reading, Lau