The presentation took place some time before DHH’s keynote at Railsconf 2014 and before #isTDDDead discussion began. However, there is a connection: DHH encourages to write “higher level system tests” and in this post I express slightly more balanced opinion on black-box testing.
Here you can find a couple of my personal opinions about talks at wroclove.rb 2014 which took place in March 14th – 16th in Wrocław. I tried to keep my feedback 100% positive in order not to upset anybody, but if you are – write a comment and we’ll discuss.
Recently I’ve been forced by the circumstances to learn Chef. It’s simply not possible to manage about 15 servers without any automation tool. I’m not a master of shell scripting (neither I like it), so using Ruby in this field sounds great to me.
Rails and JSON
Dealing with JSON in Rails is pretty easy and straightforward. The support is built into the framework, request data is automatically available in
params hash. Then we just have to say
render :json and we are done.
This may be sufficient if JSON is one of the formats which we use. For instance, we can render both JSON and HTML in the same controller action. Or we may create an action intended for AJAX call which changes some model and returns JSON with
On the other hand, we may use Ruby on Rails for building JSON API – app with the assumption that JSON is the only format we support. In such a case we know that the app won’t render HTML. There is no View layer (or you can say that JSON is your View layer). We probably won’t need cookies support and the code specific to handling browser requests.
We are using Paperclip to handle image uploads in one of our applications and after migrating from 4 GB instances to a number of really small 512 MB instances we started to experience an error which looked similar to this:
This was rather weird – we are running one app instance on each server, so the amount of free RAM memory is not critically low. In fact it should be enough to run