Category: Engineering

We use Cucumber for integration testing our Rails servers, and by default all Cucumber scenarios tagged with “@javascript” pop up a browser. We needed to get this running headless so we could run these tests on our build machine. We use the Atlassian suite, and Bamboo for CI, running on EC2.

This post is for developers or sysadmins setting up Rails integration testing on a CI system like Travis, Hudson, or Bamboo.

We use Cucumber for integration testing our Rails servers, and by default all Cucumber scenarios tagged with “@javascript” pop up a browser. We needed to get this running headless so we could run these tests on our build machine. We use the Atlassian suite, and Bamboo for CI, running on EC2.

The de facto way of running headless tests in Rails is to use capybara-webkit, which is easy to install and run locally following the guides here.

Capybara-webkit relies on Qt, which is straightforward (though slow) to install on OS X, which we use for development. Our build box however is Amazon Linux, which is supposedly a distant cousin of CentOS. We’re using Amazon Linux because Bamboo OnDemand provides a set of stock Amazon Linux AMIs for builds that we have extended and customized.

We started out following the CentOS 6.3 installation guide from the capybara-webkit wiki above but quickly encountered problems because Amazon Linux doesn’t ship with a lot of libraries you might expect from Redhat or CentOS, like gcc and x11.

Here are the steps we followed to get Qt installed and our headless Cucumber tests running on our Bamboo build machine. This installation process was tested on ec2 AMI ami-51792c38 (i686).

In the past week, Pedago has released 3 open source projects on our github page.

In the past week, Pedago has released 3 open source projects on our github page.

iguana

Iguanais an Object-Document Mapper for use in AngularJS applications. This means that it gives you a way to instantiate an instance of a class every time you pull down data over an API. It’s similar to Ruby tools like activerecord or mongomapper.

super-model

Iguana is dependent on super-model, which should someday include much of the functionality that activemodel provides for Ruby users. For now, however, it only provides callbacks.

a-class-above

Both iguana and super-model depend on a-class-above, which provides basic object-oriented programming (OOP) functionality. A-class-above is based on Prototype’s class implementation, and also provides inheritable class methods and some convenient helpers for dealing with enumerables that are shared among classes in an inheritance hierarchy.

This is our first foray into the management of open-source projects, so we’ll be learning as we go along. We’re trying hard to make these useful to the community, so we have packaged them up as bower components and spent time writing what we hope is useful documentation. We used groc for the documentation and focused on documenting our specs in order to provide lots of useful examples, rather than documenting each method in the API. We hope that this will be more helpful than more traditional API documentation would have been, and would love to hear comments on how it’s working for folks.

We hope that other AngularJS users will find iguana, super-model, and a-class-above to be useful and decide to contribute.

Given how useful the tinkering approach is for keeping learners motivated, how do we apply a similar approach to a subject like Finance?

By Artaxerxes (Own work) [CC-BY-SA-3.0], via Wikimedia CommonsMy friend Alfredo builds bikes as a hobby. He started by replacing a broken chain on his own bike. Then he upgraded his brakes. After a few more repairs, he understood the whole bike system well enough that he could gather all the parts and build one from scratch.

Experienced programmers generally learn new languages in a similar way. We get assigned to a new project for which there is an existing codebase that needs to be maintained or extended. Everything is mostly working, but something needs to be tweaked or added. So we tweak it. After working on five or ten features, we know the new language well enough that we could start a new project ourselves.

In more traditional educational environments, however, we tend to learn things the other way around. We start with simple, contrived building blocks and slowly work our way up to the point where we can comfortably manipulate a more complex and realistic system.

For example, a course that teaches the principle of the “Time Value of Money” is likely to start with a question like “if someone offered you $90 today or $100 a year from now, which one would you take?” This is, to say the least, an unrealistic scenario. But it is an introduction into the concept. After working through a number of similar examples in order to allow the student to master the math, the course will hopefully move on to a more reasonable explanation of how this concept is used in practice.

By Anna reg (Own work) [GFDL or CC-BY-SA-3.0-at], via Wikimedia CommonsNot that it was a bad course. I actually quite liked it. But this would be like if Alfredo had first worked on pedals, then wheels, then built himself a unicycle before moving on to gears and brakes. It would have been years before he had anything he could ride on. Knowing Alfredo, he would have had no hope of staying motivated for such a long time with no bike to show for it.

Given how useful the tinkering approach is for keeping learners motivated, how do we apply a similar approach to Finance? It turns out this is difficult to do because it often involves risking real money and waiting years to see any results. What a learner really needs is a safe environment to develop intuition around the long-term consequences of her decisions and to discover for herself the places where she needs to dig deeper.

At Pedago, developing alternative approaches to teaching tough topics is what we’re passionate about. Stay tuned over the coming months to see us tackle similar problems.

This post has been updated to include a clearer example. Thanks to Earthling for the feedback!

Bret Victor gave an entertaining talk on the history and/or future of computing at DBX 2013. In addition to the fascinating subject matter, Bret took the charming step of presenting with transparencies and an overhead projector.

Bret Victor gave an entertaining talk on the history and/or future of computing at DBX 2013. In addition to the fascinating subject matter, Bret took the charming step of presenting with transparencies and an overhead projector†.

We thought it’d be fun to recreate this effect. An evening of hacking resulted in a new toy: TransparenCSS (demo | source).

We’re abusing -webkit-mask-box-image, so for the full experience you’ll need Safari or Chrome. Firefox works, but you’ll be missing out on the “virtual glaucoma” effect.

Feel free to use TransparenCSS as a base for your own retro-future conference talks.