TL;DR: Docker on Mac is viable and seems like it’ll soon be great.
If you are building a single page ClojureScript app, you might be wondering how to write integration specs for it. By integration specs, I mean tests that are run in the browser against a build that is as close to the production app as possible.
In this post, I’ll show you our setup to get autorunning integration
A few weeks ago, we’ve released our first user-facing ClojureScript app. We developed it over the course of couple of months, starting from scratch.
We had previously launched a couple of non-critical Clojure apps (our slack bot, some testing tools), most of our projects being written in Ruby.
Storing and sharing secrets is tricky. At Zimpler we used to do it by having a password encrypted file, and sharing that password with all the devs.
This actually became a problem as we grew, because sharing a password is annoying. If we need to change the password for safety reasons, we need to communicate that to all devs.
The solution is of course to use GPG encryption, and it’s actually not that difficult either.
The other week we talked about reviews, why do we do them, what do we look at, and what do we get out of it.
What we didn’t really discuss was the technical hows, these details come down to your own style. Some people like seeing the changes in increments, in a commit by commit view, some like to see the sum of changes in all their glory. This might be another meeting and another blog post.
So this is how it ends.
This week was the last week we ran TorqueBox in production. We’ve had it running in production for 5 months. That’s something! We switched to TorqueBox in the first place to avoid headache with system administration. Sadly, There Ain’t No Such Thing As A Free Lunch (TANSTAAFL), and we traded our problems with new ones, namely JRuby and the JVM.
At Zimpler, we like to program in pairs. When everyone is working in the same office, that’s pretty easy: we just share a computer, and use whatever text editor the owner of the computer has (in our case Emacs, Vim or Sublime Text 2).
But things get complicated when one of the developper decides to move abroad for a couple of months…
So here is the thing. As a DevOp, SysAdmin is a PITA. Time spent tweaking the servers to add such or such service is time not spent actually producing value.
At Zimpler, we try to be agile and always look at the trade-offs that are involved in every decision we make. So as we started developing our product, we decided to go with the easy and fast track, and that meant Amazon, Rails and MySQL.
Unfortunately, easy does not necessary mean simple, so we kept using the same tools to the point where easy became complex. It was time for us to do something difficult which was to use more tools and turn our architecture simple again.
We recently made the shift to TorqueBox here at Zimpler, and that meant moving from MRI to JRuby. I order to cope with the slow start-up induced by the JVM we started using spork and nailgun for running our tests.
Spork preloads instances of your application for you to have faster startup for your tests. And nailgun (wich comes with JRuby) is a lower level tool to have jvm instances ready to go.
Both of them stay alive between test runs and can get “corrupted”. You also need to restart spork every time you change something that is outside what it reloads between each test (blueprints for example in our case).
So we (eq me and Jean-Louis) decided to spend an hour to make this a bit easier. With the answer to all technical problems!