October 28th, 2012

Written by Stoyan Rachev

I recently created Hanoier, a Tower of Hanoi implementation in JavaScript using jQuery. This is my next entry for the “Geeky Quickies” contest at SAP, after Feeder and Todor.

The task was somewhat simpler than the previous ones, and so there were not too many best practices to explore and showcase. So I focused on making it as simple as possible by leveraging the power of the used technologies, while maintaining the code as clean as possible by using object-oriented design principles and patterns.

You can play Hanoier live as it is published on GitHub Pages. As usual, you can also find the source code on GitHub. Feedback, comments, and contributions are welcome!

Main View

Game Features

  • Drag and drop disks to move them between the towers. If the move is not legitimate, the disk returns to the original tower in an animated way.
  • When all disks have been moved to a different tower, the game displays a victory message and restarts.
  • Choose the number of disks to play with, from 3 to 7.
  • Track the number of moves performed.
  • Start the game over by clicking a button.
  • Play on all modern browsers and mobile devices.

Programming Highlights

  • Uses the following jQuery features: selectors, events, HTML DOM manipulation for getting, adding, and removing elements, CSS manipulation for positioning elements, as well as jQuery UI draggable and droppable interactions for managing drag and drop.
  • Uses new HTML5 features such as canvas for drawing graphics.
  • A simple JavaScript object prototyping pattern is used to achieve object orientation while ensuring that “this is always this”.
  • The code is both clean and minimal. The entire game is written in less than 300 lines of JavaScript code (according to GitHub sloc) and very few HTML and CSS, courtesy of using jQuery rather than plain JavaScript.

Code Structure and Design

As mentioned above, Hanoier uses a simple pattern based on JavaScript prototypes to achieve object orientation. This technique is usually called methods added externally to the prototype to distinguish it from the more “advanced” prototype pattern or the revealing prototype pattern. The chosen technique is somewhat limited in terms of encapsulation and inheritance compared to its more advanced counterparts, however it has one major advantage: this always refers to the current object (except in event handlers). For more detailed comparison of the different JavaScript patterns, see the
Some JavaScript Object Prototyping Patterns article, the Techniques, Strategies and Patterns for Structuring JavaScript Code blog series, or the Learning JavaScript Design Patterns book.

In Hanoier, there are three classes:

  • The Tower class represents a tower. A tower has a number, dimensions, and an array of disks representing all disks that are currently on the tower. It provides methods for creating the HTML elements related to the tower, initialization, drawing, checking if a disk can be moved and actually moving a disk to the tower, manipulating the droppable property, and calculating disk coordinates for positioning.
  • The Disk class represents a disk. A disk has a number, dimensions, font, and a reference to the tower on which the disk is currently on. It provides methods for creating the HTML elements related to the disk, initialization, drawing, manipulating the draggable property, and positioning.
  • The Game class represents a game. A game has two arrays containing all towers and disks. It provides methods for initialization, as well as the actual event handlers for the drag and drop events that drive the game.

Each tower and disk is represented in HTML by a canvas element and an associated image which is drawn on the canvas. These elements are not part of the static index.html, instead they are created dynamically upon game initialization. All such elements have unique ids based on their numbers, which allows efficient selection by id, performed by the getElement() methods which expose the associated jQuery objects on which various jQuery methods are called.

There is very little code outside these three classes. Most notably this is the jQuery document ready event, which simply creates a new game and initializes it, and then sets-up a handler for the “Start Over” button which does the same:

$(function() {
	new Game().init();
	$("#startOver").click(function() {
		new Game().init();;


As already mentioned, the visualization of towers and disks is achieved by drawing images upon canvases. I am not good at creating graphics myself, so I decided to use simple grayscale images for towers and disks available freely on the Web (from For the background, I use a Chinese landscape converted to grayscale. Since all HTML elements that refer to the actual images are created dynamically, one could easily extend the game with different “skins” consisting of images with identical names placed in different directories.

Drawing an image upon a canvas is achieved simply by calling the HTML5 canvas drawImage() function. However, this function expects a pre-loaded image, so when I tried to call it inside the draw() method, which is invoked by the document ready event, nothing was drawn, because the images hadn’t been loaded yet. Eventually I resorted to setting up an event handler for the image load event and doing the actual drawing inside the handler:

Disk.prototype.draw = function() {
	this.getImageElement().load($.proxy(this.loadImage, this));

Disk.prototype.loadImage = function(event) {
	var elem = this.getElement();
	var ctx = elem.get(0).getContext("2d");
	var img = $(;
	ctx.drawImage(img.get(0), 0, 0, this.width, this.height);

Note the use of $.proxy() in the above code snippet – this seems to be the most portable way available to ensure that inside the event handler, this refers to the current object. Without it, the above code would fail. The standard JavaScript bind() function could be used as well, but it is not supported in IE 9.

Drag and Drop

When thinking about how to implement drag and drop, I wondered whether to use HTML5 drag and drop, or the same functionality available in jQuery UI. I found working “Tower of Hanoi” implementations based on both approaches (see hanoi-towers and towers-of-hanoi-in-HTML5), as well as some stackoverflow questions on this topic. Eventually, I decided to stick with jQuery UI for the following reasons:

  • The contest rules explicitly called for using “jQuery features”.
  • Currently, jQuery UI still has better cross-browser compatibility.
  • The jQuery UI API is very simple and convenient to use.

In the future, using the standards-based HTML5 approach would probably become a better choice than the outdated jQuery UI implementation, unless it is also ported to HTML5

Positioning Disks

Initially, I used the jQuery UI position utility to position the disks relative to their towers. This basically worked, but it had various issues with window resizing and zooming. Eventually I found using CSS positioning to be both simpler and more robust. The positioning code now looks like this:

Disk.prototype.position = function() {
	var elem = this.getElement();
	var top = this.tower.calcDiskTop(this.num, this.height);
	var left = this.tower.calcDiskLeft(this.width);
	elem.css({ position:"absolute", top:top, left:left });

In order for the above code to work, the disk parent element, in this case a div called game, must have the position: relative; style.

Browser Compatibility

I tested that Hanoier works smoothly on the following browsers:

  • Chrome 22
  • Firefox 13
  • IE 9
  • Safari 5.1.7
  • Opera 12
  • Chrome for Android 18
  • Android Browser 4.1
  • Blackberry Browser 6.0
  • Opera Mobile 12.1

Support for such a wide array of browsers without a single line of browser-specific code is possible since jQuery and jQuery UI ensure cross-browser portability for browser versions much lower than the listed above. The only advanced HTML5 feature that requires a newer browser is the canvas. Touch screen devices are supported via the jQuery UI Touch Punch plugin.

October 5th, 2012

by Ivan St. Ivanov

Community keynote

The last JavaOne day started with the community keynote. All the conference attendees gathered in the Continental Ballroom of Hilton hotel and cheered Sharat Chander, the conference chair person, who opened the session. He started his talk with the fact that this year 60% of the content at JavaOne was delivered by the community (and just 40% by Oracle). I felt from his words that the Java stewards had really got it: you cannot move Java forward without significant effort from the people who are using it.

Then on the stage came Donald Smith, director of product management at Oracle. He took over from Sharat and tried to cheer up the crowd by asking us to make one of those Mexican waves that you see on the stadiums. He then asked Gary Frost from AMD to talk a little bit about Project Sumatra. In my opinion, the announcement of Project Sumatra is news number one of this conference. Maybe it’s not really news as it will be based on a project that exists even now: Aparapi. But it’s something tremendous for the Java world. Its basic goal is to move the parallelism on the next level: from the cores of the central processor to the GPU. Gary showed us some demos on the performance of applications which require intensive calculations. The Paparapi enabled runs were way much faster than those that just used threads. The goal is that for Java 8 Paparapi’s APIs become even sexier with the introduction of lambdas and in Java 9 it is expected to be inside the JVM.

After that Donald invited for a panel discussion people from Eucalyptus, Twitter (Chris Aniszczyk), Cloudera, Eclipse Foundation (Mike Milinkovich himself) and Perrone Robotics (its CEO Paul Perrone), who represented the different types of participants in the Java ecosystem. What I will take with me from the short question and answer session was that entrepreneurship is not about venture capitalists, but about innovators. And that the more open your innovation is, the better ideas you get.

Then Georges Saab, VP of development at Oracle, welcomed on the scene Martijn Verburg (a.k.a. The Diabolical Developer) from the London Java Community. Martijn explained how this user group was formed: people who were not happy of what they were doing in their day-to-day jobs in the London city gathered and decided that instead of complaining and writing bad tweets, they could do something good. And thus the adopt a JSR and adopt open JDK initiatives were born.

And here came the quote of the day. Martijn said that the queen has told him that “if the presidential elections [in US] don’t work well, she is ready to take [the states] back as a colony.”

After we had Paul Perrone again on the scene to show one of his robots it was time for the biggest surprise of the conference: James Gosling, the father of Java, who left Oracle and never showed up on JavaOne since then, was back on the scene! This provoked great cheer and applause from the crowd (including myself). Welcome back James!

For the rest of the session James talked about the things he has been doing in Liquid Robotics, but the most important part for me was what we heard at the end by Sharat: reach out the youths and inspire them!

Project Errai

This was a talk given by my two new friends from JBoss: Christian Sadilek and Jonathan Fuerth. They are working on a relatively new and quite impressive project: Errai. In a nutshell, it’s a project that lets you write your web applications just in Java, it is based on Google Web Toolkit and brings you such things as CDI and other powerful Java EE APIs on the client side. Its mantras are:

  • Declarative works
  • Boilerplate sucks
  • Code it once

The most important project features (some of them already mentioned) are:

  • Unified programming model on the server and on the client
  • Java EE 6 APIs (including dependency injection and most importantly CDI’s event model) available on the client
  • The web application project has three basic folders: server, shared and client. The shared and client folders are compiled to JavaScript
  • You can easily do remote calls from the client to the server using RPC and REST
  • The objects that travel between the client and the server should be annotated as @Portable and may not have getters and setters

Then the speakers did a demo which showed some of the most impressive Errai features. They renamed one of the API method names using refactoring in the IDE and all the classes that used this method (including those on the client side) were updated accordingly. They then changed the path of the RESTful service endpoints at just one place and it worked out of the box for all the parties involved. But the most impressive thing was the fact that clients could observe server generated events: the speakers added a new entry from one browser session and the other session was updated without any refresh.

At the end Christian and Jonathan talked a little bit about some cool new features of the framework. You can use JPA annotations and entity manager on the client, which will result in persisting your data in HTML5’s local storage.  You can use HTML5 design templates for describing your UI in declarative way instead of the standard procedural approach of GWT. Errai takes care for binding your data objects’ fields to the HTML elements they correspond to.

Really interesting session and great work. You should definitely give Errai a try!

Testing JSF apps with Arquillian

This was the final session that I went to at this JavaOne. The speakers were again from JBoss. They are company’s representatives in the JSF expert group: Brian Leathem (project lead of RichFaces) and Lincoln Baxter III (project lead of Forge).

I found this talk as a sequel of the one about Continuous Development. The speakers started with the well known fact that unit tests with mocks are not testing the application in its normal environment, which make them not very useful. And they prepared the audience with a quick HelloWorld-like example of an Arquillian test, which showed how you can unit test your code without mocking what the container does for it.

If you want real test, however, you need to test your UI. And if it is a web application, then libraries like Selenium 2 and Web Driver come to the rescue. Unfortunately in your tests that use those APIs you need to write a lot of boilerplate code: initialize the web driver, start the browser and then shut it down. All this boilerplate is spared for us by an Arquillian extension called Drone (led by another cool JBoss guy whom I met here – Karel Piwko). The way Arquillian brings the container to the test, Drone brings the browser to the test. So there you annotate a WebDriver field of your class with @Drone and the library does all the plumbing code for you. You can additionally configure what kind of browser you want to test against.

The next project from the UI testing stack that was presented was another Arquillian extension: Graphene. It runs on top of Drone and brings much more injection to your test. Common practice in Selenium 2 tests is to make plenty of findElementById calls in order to see or change the content of an HTML element. Good practice used in web testing to make this more type safe is the Page Object pattern: you encapsulate all these calls in one class (called page object) and expose more meaningful methods to the client. So you have getUserName()  instead of findElementById(“userName”).getValue(). This pattern is abstracted very well by Graphene, which provides you with such annotations as @PageObject and @WebElement to further relieve you from writing the plumbing code.

Finally we came to the point of testing JSF pages. Brian and Lincoln presented us a third Arquillian extension, suitable for that: Warp. It is a relatively new project and its basic goal is to provide some features that JSFUnit lacks (like making assertions around all the phases of the JSF page lifecycle).

The session ended with some best practices when writing Aruillian tests:

  • Use remote target container, which is running, so that Arquillian doesn’t have to start it and stop it for you upon each test
  • Reuse browser sessions between tests
  • Use ShrinkWrap micro deployment instead of packaging your whole application


My first JavaOne is over. And to be honest, I liked it. Until now I always tried to follow blogs like this in order to get what is really going on at the conference. I still read them, as I can’t visit every session. But now the feeling is different: I don’t just read the reports, I feel like I participated there.

Next year? Well, maybe,… nobody knows! Now it’s time for packing and for the next conference: Java2Days in Sofia.

October 4th, 2012

by Ivan St. Ivanov

Who is more functional

The first session that I attended today was in the early morning slot, when JetBrains’ Andrey Breslav (the leading designer of the Kotlin programming language) compared four languages (Java 8, Groovy, Scala and Kotlin) in terms of being functional. The comparison was done following four criteria: availability of recursion, no side effects done by the language, higher order functions and availability of abstract and algebraic data types.

I must say that the no side effects part was most interesting for me. All of you have heard the ‘immutability’ mantra. This is a very popular word in today’s programming. Everything should be immutable so that our code can be parallelized easily and reliably and take advantage of the multiple cores of the CPUs. Immutability implies that there is no shared state between two objects, so the execution of an operation of one of them cannot potentially cause side effects on the other one. The operation (or as it is called in the functional programming – the function) just takes some parameters, does something without changing them and returns a result. Talking about side effects, according to Andrey writing to a file, to the network or even to the console is a side effect. That’s why all the compared languages failed to meet this criterion.

Another very interesting aspect of functional programming was also mentioned. FP is cool and makes you look smart, but this doesn’t mean that you must use it for every feature you develop. For example the functional implementation of the Fibonacci numbers algorithm is much slower and takes more memory, than the classical (iterative or von Neumann) approach with a loop. So there is always this tradeoff between clean code and performance that you should consider.

Another corner stone of the functional programming are the higher order functions (or lambdas, or closures, or what not). Instead of explaining what they are (most of the people visiting JavaOne should know them very well), Andrey pointed us to one of the patterns in the GoF book – the strategy pattern. It’s implemented most intuitively with lamdas in mind. Think about filtering the content of a collection. Instead of getting an iterator out of it, then iterating it, then creating the new collection based on a certain predicate, you just call a filter method with the predicate (or a strategy) as parameter. This is something that was also mentioned by Brian Goetz during the technical key note: the knowledge how to apply the function on the elements of the collection should be in the collection itself and not in the client code. As the collection knows best how its content is structured and organized and can do the job in most efficient manner.

The two ADTs (abstract and algebraic data types) represent the interfaces that define contracts and the data classes. The availability and ease of use of the latter is key to functional programming. Modern languages (like Scala and Kotlin for example) have case classes and easy pattern matching when working with them. While in Java you have to do:

 if (dataType instanceof Type1) {...}
 else if (dataType instanceof Type2) {...}

Which is not really elegant.

The final functional aspect that was touched was the ability to extend (or open) existing classes without changing their code. In Java it is not possible – you cannot add a new method to the String class for example. While other languages have it in some way or another: the expando meta class in Groovy, the implicit conversions in Scala and extension functions in Kotlin. In Java the standard approach is by creating static utility methods in other classes (Collections, Strings, Arrays classes are such examples).

Very interesting talk. Andrey as always was trying to provoke audience’s participation: he had funny slides, asked questions, stopped the presentation when somebody had a question.

Continuous development

Another agile software engineering (ASE) talk. It was given by my JBoss buddies Andrew Lee Rubinger and Aslak Knutsen. They are most known by their leading the Arquillian and ShrinkWrap integration testing projects. However, the focus of this talk was something beyond testing, which appears to be the focus of their upcoming book: continuous development. So after continuous integration and continuous delivery, we are now looking at the continuous development.

The core of the continuous development process is to write code, which is able to be tested. The tests should be portable to any environment. In the enterprise world this translates ‘to any container’. They should be executable without any tweaking both from the IDE and as part of the build. They should also leverage existing testing frameworks like JUnit or TestNG in the Java world and not make up ones of their own.

Before giving us these rules, the speakers talked a bit about testing in general, as it is the most important part of the continuous development. As Jeremy Norris had stated, “The purpose of automated testing is to enable change. Verifying correctness is just a nice side effect.” Another very important thing about testing is that it makes you use your own API and thus get an early feeling whether it is good and usable. Andrew didn’t insist that you should follow the test-first approach. Just make sure that at the end you have automated tests for all your features.

The next big topic in the talk was unit vs integration testing. When you unit test a piece of code, which interacts with other objects, you usually have to use stubs or mocks in order to be able to test that piece of code in isolation. But is this isolation always a good idea? Using mocks takes your class outside of the environment it usually runs in. Thus you miss large portion of the picture. This was a nice intro to the Arquillian framework (or library, or model…). If you are doing Java EE development and you haven’t heard or are not using Arquillian, then you should consider doing it.

The rest of the talk was a demo of some of the aspects of the continuous development:

  • Using Arquillian persistence extension to test persistent data by easy way of preparing the initial and the expected data sets
  • Using Arquillian Graphene – the enhancement of Selenium browser automation library
  • Using the cloud and Openshift in particular for running your own continuous integration server
  • The hotswapping capability of Openshift: while debugging your cloud application you can change the code locally in the IDE and it gets automatically updated on the remote location

Behavior Driven Development on the JVM

The agile track continued for me with the next session. It was John Ferguson Smart’s about modern JVM tools and frameworks for doing Behavior Driven Development (BDD).

The talk started with a theoretical introduction which, as John said, was more for the Business analyst type of people (nobody in the audience confessed to have such a role). The first thing about BDD is that it advocates common language between all the participants in a project: the business analyst, the developer, the tester and the customer. You don’t really write tests in BDD, you rather create specifications. This does not mean 100-page word document, but stories following a specific format. The most common such format is the “given, when, then” triad.

The stories should describe the most relevant features of the product as seen by the final user. Which are the most important features? Well, according to the speaker, those that meet the goals of the project and bring value (in terms of money).

The agile approach of defining stories is: as a ‘role’, I want ‘…’, so that I achieve ‘…’. According to John the order should be changed and the last section should come first – the reason why we need a feature is the most important incentive for doing it.

The second part of the session was on existing BDD frameworks in the JVM world. The first two presented were jbehave and cucumber. The common thing about them is that you define the stories in human readable style in a text file and then write annotated Java code where you state your given, when and then functionality. Next was easyb, BDD library with a Groovy DSL, where both the rules and the code are at one place. This sounds good, but the code may become unreadable for more complex tests.

A forth library was also presented. It is the one developed in John’s company and is called Thucydides. I have read quite a few articles and blog posts about it, so I kind of knew what it was doing. So, its basic idea is to encapsulate any existing BDD library (those from above and also many more, Selenium 2 for example), to run the tests, observe their results and report what happened (with many screenshots). Just a side note, John approached the Forge team after the talk as he was very interested in creating a Thucydides plugin that could spare its users writing some boilerplate.

The final part of the talk was called BDD for developers. It was about BDD frameworks that replace existing unit testing frameworks and the best one here is definitely Spock. It’s again based on Groovy-based DSL and follows the given-when-then style of writing unit tests. It has its own mocking framework that is easier to setup and use even than Mockito. It’s quite easy to write data driven tests as well (remember the Parameterized JUnit test cases?). Then the speaker spent some time talking about Spec2 (which is the same as Spock, but with a Scala DSL) and Jasmine, which is the same for JavaScript.

The slides are already available on SlideShare so you can go and check them out.

What’s new in Groovy 2.0

This talk was given by the Groovy language project lead Guillaume Laforge. It was the informative kind of talk, one of those where you don’t have too many funny slides or some philosophic diversions.

Actually Guillaume talked first about the Groovy 1.8 new features, as they are also very interesting and important:

  • After 1.8 Groovy is even better for creating DSLs as there are now a lot of other possible situations where you can drop your dots and parenthesis: in functions with multiple arguments, when you have named arguments or closure function parameters and even no arguments at all
  • GPars, the Groovy parallelization library providing such features as actors, fork/join, map/reduce, parallel arrays, etc. is now part of the official distribution
  • Annotations can take closures as parameters. This is very useful for validation frameworks for example: you can define your rules as boolean functions and attach them to your model as annotations
  • There’s now built-in JSON support, the same as the XML support – with the slurper and builder objects
  • A groovy compiler plugin can do some transformation on your code before translating it to byte code, based on common annotations. For example, if you add @ToString or @EqualsAndHashcode, after you compile, you’ll automatically get toString(), equals() and hashCode() methods (something like Lombock for Java). I counted more than 10 possible transformations on the slide, but there was no time for the speaker to talk about them all

And now for Groovy 2.0. It’s major release so you may expect something really major inside. However, Guillaume started with the (in my opinion) not the greatest new features.

So, as of 2.0 Groovy is more modular. Instead of needing to download the big 6MB jar that has it all, you can download just the core (3MB) and the modules that you might need for your application. There’s now another way to extend existing classes (like the expando meta class): the extension modules. There you have to do some more plumbing code like adding some files in the META-INF/services directory of the jar, but now the static compiler (ooops, spoiler!) and the auto-completion of IDEs can really understand that the class is extended with your own methods. Groovy has now full support for all the Project Coin enhancements (multicatch, binary literals, etc.) and also for the new InvokeDynamic functionality of the VM. The speaker mentioned that the Oracle engineers have some more work to do for invoke dynamic, as for now there is not a big change in the performance of Groovy code.

And now for the most prominent part: if you wish, you can make Groovy type safe! And this can be done in two ways:

  • Ask the compiler (and IDEs) to check for things like wrong method and variable names in the code, executing methods that are not part of the called type or return wrong result types. You just annotate your class or method with the @TypeChecked annotation and voila! The compiler will check all those things for you. Beware that inside such code blocks you cannot do things like parsing or creating XML or JSON as the API there relies on the dynamic features of the language
  • One step further is the static compilation: it not only checks for compilation errors, but generates byte code, which performs much better at runtime.

At the end Guillaume showed some benchmark results for Java, Groovy with static compile and older Groovy versions. And the result showed that the compiled Groovy is just slightly slower than Java is. Nevertheless, I’m sure that there will still be people that will continue saying that Groovy is slow. To be honest, they look to me like the folks who keep telling for the last 15 years that Java is awfully slower than native code. The history repeating?

Functional style of programming in Java

My day 3 started with functional programming and ended with the same topic. The speaker was John Fergusson Smart again (this is his third session that I attended this JavaOne).

The talk kicked off by introducing the main concepts and advantages of the functional programming style and they were basically the same as in Andrey’s talk in the morning:

  • Immutability is your friend: it makes your code thread safe. Unfortunately you cannot have true immutability in Java as even private final fields can be changed with reflection
  • No side effects: no matter how many times you call your functions, they give the same result for the same set of parameters
  • Avoid using loops: leave that to the library that you are calling, just tell us what you want, not the way how to achieve it

John then showed us how you can do most of these things in Java 8 with project Lambda. But… Java 8 will not be here any time soon. So if you need something now, you’ll have to look at the libraries that are available now in the ecosystem. So the speaker presented us two such libraries: Google Guava and LambdaJ.

The Guava part of the talk was relatively short, most probably because most of the functional features there are based on using anonymous inner classes. There are immutable collections in the library. They are immutable in a sense that you cannot add or remove element to them or change their order (by sorting for example). But the immutability of the elements themselves is not enforced. The ‘don’t return null’ programming style is also addressed. If you intend to return null for some reason in your code, then consider returning Optional<?> type. This looks and behaves much the same as the Scala Option type. And this was it for Guava…

The rest of the session was about LambdaJ, which seemed to be John’s favorite FP style library. Its APIs for collection operations like filter, sort, aggregate, convert, etc. are quite better than Guava’s. The magic is that it integrates with the Hamcrest matchers (usually used instead of the JUnit asserts in your tests). An very good example of the integration is the filter method:

filter(startsWith(“P”), arrayOfNames);

Here filter is LambdaJ static method and startsWith is Hamcrest matcher method. There are plenty of matchers and it is very easy to create one of yours, so you can easily do without any anonymous inner classes. Sometimes your code might not be very readable as the design of the Hamcrest APIs was not really intended for such use. In such cases John’s advice was to encapsulate the matcher code in your own method, give this method a meaningful name and use that in the LambdaJ functions.

At the end John showed a benchmark, according to which LambdaJ performs relatively slower than the iterative code (with loops). D?j? vu: the same thing was mentioned by Andrey Breslav in the morning, so again you have to make the trade off: readability or clean code.

As always, the slides are available on SlideShare.


This was my day 3: functional programming and agile software engineering. And finally I could get some sleep (Oracle, thank you for that!). The quote of the day was by John Smart: “The amazing thing about [the JavaScript BDD library] Jasmine is that it exists”.