Improving test failures feedback by extending IPrintWithWriter protocol in ClojureScript

When Francesc and I decided to directly store ClojureScript +, -, * and / functions in our Operation record instead of keywords representing them our code got simpler.

However the feedback we received when a test failed got much worse because the whole function got printed in the test failure output:

The same happened when we were working on the REPL.

So we decided to extend the IPrintWithWriter protocol to improve the test failures feedback.

First, we tried to do it in the record declaration as we were doing for the Object protocol:

Surprisingly, it didn't work. We were still getting the ugly output shown before.

We were also getting this warning:

So we tried with extend-protocol:

This worked as we expected and we got a more useful failure feedback:

It also worked using extend-type:

Yet, we didn't understand why it was working as we expected with extend-type and extend-protocol but not in the declaration of the Operation record.

So we decided to ask it on the Clojurians slack.

There thanks to Alejandro Gómez and Nicolás Berger we understood what was happening. As Nicolás said:

That's the reason why it wasn't working and why we were getting that warning.

Check the code Nicolas is talking about in ClojureScript repository.

In the end, it was a nice problem to have, because we not only got a nicer and more useful failure feedback which was our initial goal, but also, learned more about extending core protocols in ClojureScript.

PS: Thank you very much to Alejandro Gómez and Nicolás Berger for their help.

Running cljs.test tests on node.js using doo and karma

Francesc and I are using doo and Karma to run our cljs.test tests on Node.js.

This is what we did to make it work.

First we installed Node.js, and then, Karma and its CLI following these instructions.

Once we had that, we added the doo plugin to the project.clj.

doo is a library and leiningen plugin that allows to run cljs.test on different JavaScript environments.

Next, we created a new namespace for the unit tests in the tests directory, and set up the test build in project.clj (we called the new namespace unit-tests):

Notice that in the setup you’ve to define which namespace will be used as the main of the unit tests: :main 'math-ops.unit-tests

In that namespace, we used doo to run the tests and register the namespaces containing unit tests:

Every time a new namespace containing unit tests is added, it has to be registered using the doo-tests macro in order to include it in the run.

Finally, to run the tests on Node.js we added it as a target to the build setup in project.clj:

Notice the addition of :target :nodejs to the compiler options.

Then we could run our tests writing lein doo node unit-tests on the console:

By default, doo watches the files in the source paths that we indicated in the build setup: :source-paths ["src/cljs" "test"], so any change to a file in them, makes the unit test run again.

You can check the code in this repository.

References:

• doo
• Karma
• How can you test ClojureScript applications and libraries?
• cljs.test

The joy of a live interactive spiking and stabilization flow in ClojureScript using re-frame and figwheel

Francesc and I are working on a pet project to learn a bit of ClojureScript.

We have a very small amount of time to work on it during the week (two hours and a half at most), so we try to make that remote pairing time as productive and fun as possible.

figwheel and the re-frame framework are helping us a lot to achieve that. On one hand, the re-frame framework makes it beautifully simple to work with state and events. On the other hand, figwheel allows a Live interactive programming experience.

We work remotely in small spikes in which we usually start with a hardcoded view and then give it behavior step by step while, thanks to figwheel, we can instantly see the resulting view on the browser and interact with it.

Live interactive programming with figwheel is not only a lot of fun but it also gives you a very quick feedback on what you’re doing.

Once these spikes are working we extract all the new behavior that we consider non-view related from the view and put it in a separated name space. This makes our views as dumb as possible (à la Passive View pattern).

Then we stabilize and document the extracted behavior writing tests for it. This protects us against regressions in the code and makes us reflect on what we did during the spike. Many times we had found better names or different ways to arrange the code during this stabilization phase.

This flow of live interactive spiking with figwheel and the ClojureScript REPL, and then stabilization through dumbing views and testing the extracted logic is making us enjoy GUI programming a lot.

Last Pet Project: Glowworm Swarm Optimization in Clojure

Lately I've been working bit by bit in an implementation of the Glowworm Swarm Optimization algorithm (GSO) in Clojure.

Some time ago I implemented the GSO algorithm in C++ to practice TDD.

I decided to implement it it again in Clojure to practice with something larger that Exercism exercises or katas an yet small and familiar enough to finish it in spare bits of time.

This is the code of the resulting Clojure GSO on GitHub.

This GSO Clojure version is much shorter than its C++ version.

Aside from practicing Clojure, I've learned many other things while doing it.

I'll try to enumerate them here:

• Mixing Java and Clojure code in order to use a Sean Luke's Mersenne Twister Java implementation.
• I learned more about Midje's checkers.
• dire library.
• Decomposing a bigger Clojure application in several name spaces according to roles and responsibilities.
• Using maps to model the data.
• Struggling to make the code more readable and keeping functions at the same level of abstraction.
• Using only higher-order functions to compose the algorithm (I set myself the constraint to use no global configuration maps).
• Taking advantage of those higher-order functions to test the different parts of the algorithm in isolation.
• Separating the code that builds the graph of functions that compose the algorithm from the algorithm itself.
• Where would I apply a library like component instead of relying only n higher-order functions.
• Many other little Clojure things.

But overall it's been great fun.

I'd like to thank Álvaro García, Natxo Cabré and Francesc Guillén from the Clojure Developers Barcelona meetup for their feedback and Brian Jiménez for rubbing elbows with me in the first C++ version.

Last Pet Project: Zambombator

Lately I've been developing an Android application with some friends.
Besides learning a bit about Android programming, we wanted to know the whole process of shipping an application to the Android market.
Zambombator is a very simple application that makes zambomba noises when you shake it. A zambomba is a typical Spanish Christmas instrument.
It was great fun developing it and I hope it'll be great fun playing zambomba this Christmas as well. You can get it for free in Google Play.

Last Pet Project: backmongo

@remosu and I have been working during the last months in another pet project: backmongo.

backmongo is a simple REST interface for MongoDB written in Python that can be used straight away from a Backbone application.

We plan to use it in our next backbone pet projects, so we'll add new features as we need them.

Last Pet Project: Event-Driven Molecular Dynamics

During the last week @remosu and I have been pair-programming a pet project: edmd.

It is a Python implementation of a simple Event-Driven Molecular Dynamics algorithm described in the Event-Driven Molecular Dynamics chapter of the book Computational Granular Dynamics: Models and Algorithms by Thorsten Pöschel and Thomas Schwager.

We plan to revisit edmd in the future to optimize the event-updating phase by using a cell list.

Last Pet Project: Glowworm Swarm Optimization in C++

Lately @irrati0nal and I have been working on a C++ pet project: glowworm++
It is a C++ implementation of the Glowworm Swarm Optimization algorithm as described in the original paper from Krishnanand, K.N. and Ghose, D., Glowworm swarm optimization for simultaneous capture of multiple local optima of multimodal functions, published in Swarm Intelligence, 3, 2, June 2009, 87-124.

I wanted to practice TDD in C++ and was looking for an interesting pet project. So when I knew about @irrati0nal wanting to use GSO optimization for his research on protein docking, I asked him if he wanted to implement it in C++ with me and he gladly accepted. I had worked with genetic algorithms before and I thought that Bio-inspired algorithms were just beautiful.

We worked in short sessions once a week after work and in longer sessions during the weekend once a month, we called the long ones "hackathons". It wasn't difficult to follow the description of the algorithm in the paper, but we had to implement the coordinates and objective function code several times until we were happy enough with the result.

From the very beginning we wanted to release glowworm++ so other people could use it if they wanted. Now it's finally done. If you want to use it you can find the code here.

We applied TDD using the CppUTest framework and pair programming throughout the whole development. We are newbies in these two thecniques. We tried to do our best but, in the end, I think we did a nice job at TDD but not that good at pair programming. We had a lot of fun though. We need to read more about how pair programming works and how to do it well.
We also learn a lot of C++ and realize that we still have so much more to learn.

I'll try to improve my TDD and pair programming skills with my next pet project: I'm working with @remosu on a single page application using Backbone.js

In the near future, I'll have to devote most of my time after work to the UOC, so I won't have more time for glowworm++. However @irrati0nal is starting to use it in his research and will go on improving it to adapt it to his needs. Next summer, once the semester in the UOC is over, I'd like to use glowworm++ as well. I'll try to apply it to search special genetic networks.

@irrati0nal, thanks a million for all the good times we spent rubbing elbows together.

-----------------------------

Update:
I've continued evolving the code in this fork.
I mainly fixed a bug, simplified the code a bit and used some C++11 new features.