Tuesday, November 20, 2012

Continuous integration for a Rails-based project. Why we moved away from TravisCI in favour of CircleCI.

We've faced an issue recently with TravisCI on a Rails project, that would better be avoided next time.

Initially we've chosen TravisCI due to an easy/simple project start based on it. Although it didn't support private repos, the project was in a public repo, so that wasn't a problem. It was a real good CI solution actually.
But our app specifics made its unit tests to be rather time-consuming at that stage (http requests making and their responses usage in the tests), so TravisCI in its turn was just interrupting the tests after 25 minutes, leading to build failures of course. As it turned out, this 25 min limit was NOT configurable in Travis (it becomes important in some cases, so it's looking rather dully to have such a limitation, isn't it?), so we had to look around a bit.

CircleCI became a good replacement. Allowing the tests without that limitation - it became the solution at that stage. A very simple quick setup, a clean nice list of revisions with build statuses, and (compared to Travis) while in its beta, for now, allows private repositories for free.

By the way, later we've "eased" the tests when running on the side of CI, in the sense of time consumption - a VCR-based optimizing solution (records your test suite's HTTP interactions and replays them during future test runs for fast, deterministic, accurate tests) allowed to greatly speed them up there - by reusing the HTTP responses VCR cache generated locally and then pushed to Amazon S3 storage for sharing among the environments. So that "25min limit issue" has lost its actuality in our case. But still, CircleCI has "occupied" the status of problem solver since the previous case :)

P.S. Thanks to Paul Biggar @ CircleCI for being so attentive and quick with his help when needed.

Wednesday, November 7, 2012

GPU-accelerated video decoding for Chrome enabled

Google Chrome Blog: Longer battery life and easier website permissions...: A wise person once said, “Modern life is a constant search... for a power outlet.” With today’s new Chrome Stable release , we hope you can ...

Tuesday, November 6, 2012

Leaving MongoDB in favour of {Riak & PostgreSQL}. A real feedback from Kiip.

MongoDB is definitely a great NoSQL solution, very popular, but its mission is also clearly defined, where it's the choice and where it's not. Kiip has shared their opinion and the whole story about why they moved to {Riak & PostgreSQL partly} after a year running MongoDB in production (A Year with MongoDB). So, it's not that it was a kind of a total failure, no. The basic factors've been listed, let's summarize them briefly - both cons and pros about Mongo, based on the actual experience.

The Good

  • Schemaless 
  • Simple replication
  • Query Language
  • Full-featured Drivers for Many Languages

The Bad

  • Non-counting B-Trees
  • Poor Memory Management
  • Uncompressed field names
  • Global write lock
  • Safe off by default
  • Offline table compaction
  • Secondaries do not keep hot data in RAM

Thanks Kiip, valuable details to be considered for decisions making yet on the early stages.