Saturday, April 30, 2016

Interesting Paper: "Objects of value"

I've just read this very interesting paper by Kevlin Henney

Kata: Mars Rover in Java (recorded)

I've recorded myself using TDD to code the Mars Rover kata in order to be able to later watch me and detect problems to correct.

This is the recording of what I've done so far (all the possible movements of the rover): If you decide to watch it, please do it at 2x speed (I still write slowly).

These are the commits after each green and every refactoring step.

You can see the code in the using_java_enum branch of this GitHub repository.

Friday, April 29, 2016

Interesting Paper: "Public versus Published Interfaces"

I've just read this great paper by Martin Fowler

Books I read (January - April 2016)

January
- El Eternauta, Héctor Germán Oesterheld and Francisco Solano López
- Barcelona. Los vagabundos de la chatarra, Jorge Carrión and Sagar Fornies
- Rip Van Winkle, Washington Irving
- La guerra interminable (The Forever War), Joe Haldeman
- Maintanable JavaScript, Nicholas C. Zakas
- Ve y pon un centinela (Go Set a Watchman), Harper Lee
- El nombre del viento (The Name of the Wind), Patrick Rothfuss
- You Don't Know JS: Async & Performance, Kyle Simpson
- Sapiens: A Brief History of Humankind, Yuval Noah Harari
- The Principles of Object Oriented JavaScript, Nicholas C. Zakas

February
- The Leprechauns of Software Engineering, Laurent Bossavit
- The Wise Man's Fear, Patrick Rothfuss
- Fundamentals of Object-Oriented Design in UML, Meilir Page-Jones
- Old Man's War, John Scalzi
- Cevdet Bey e hijos (Cevdet Bey ve Oğulları), Orhan Pamuk
- Ringworld, Larry Niven
- Why Nations Fail: The Origins of Power, Prosperity, and Poverty, Daron Acemoglu and James A. Robinson

March
- The Grumpy Programmer's Guide To Building Testable PHP Applications, Chris Hartjes
- The Grapes of Wrath, John Steinbeck
- The Coding Dojo Handbook, Emily Bache
- Fahrenheit 451, Ray Bradbury

April
- Implementation Patterns, Kent Beck (3rd time)
- The Power of Habit: Why We Do What We Do in Life and Business, Charles Duhigg
- How to Win Friends and Influence People, Dale Carnegie
- Understanding the Four Rules of Simple Design, Corey Haines (2nd time)
- La llamada de Cthulhu (The Call of Cthulhu), El horror de Dunwich (The Dunwich Horror) and Las ratas en las paredes (The Rats in the Walls), H. P. Lovecraft
- The Tales of Beedle the Bard, J. K. Rowling

Tuesday, April 26, 2016

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.

Friday, April 22, 2016

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:

Tuesday, April 12, 2016

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.