You're reading a blog by arkency, a Ruby on Rails development shop.

Zero uptime deploy

Photo remix available thanks to the courtesy of Rob Boudon. CC BY 2.0

Unicorn has a nice feature that bought it a lot of popularity and set standards for other Ruby web servers: The ability to do Zero Downtime Deploy, also known by the name rolling deploy or rolling restart aka hot restart. You start it by issuing USR2 signal. But here is something that most websites won't tell you. It can fail and you won't even notice. You will be thinking that everything went ok, living in Wonderland, whereas in reality your deploy achieved uptime of exactly 0 seconds.

So what you need is a small verification procedure that everything worked as expected. This article will demonstrate simple solution for achieving it in case you are using capistrano for deploying the app. However you can use very similar procedure if you deploy your app with other tools.

continue reading →

Don't call controller from background job, please. Do it differently!

Photo remix available thanks to the courtesy of francescomucio. CC BY 2.0

Some time ago while doing Code Review for one of our clients I stumbled on a very unexpected piece of code. Background job calling a controller.

class OrderPdfJob
  def self.perform(order_id, locale)
    controller = PdfController.new
    pdf = controller.generate_pdf_for_order(order_id, locale)
    OrderPdf.create file: pdf, order: order
    # ...
  end
end

class PdfController < ApplicationController
  skip_before_filter :authenticate_user!

  def generate_pdf_for_order(order_id, locale)
    # ...
  end
end

I was a bit speechless. Calling controller out of HTTP request/response loop sounds like an odd thing to do. I had to investigate and refactor.

continue reading →

2 ways to deal with big and complicated features

Photo remix available thanks to the courtesy of EladeManu. CC BY 2.0

From feature vision to stories

One of the challenges of managing software projects is delivering big features. We already told you that we prefer to work with small, prioritized and unassigned stories that anyone can take and finish. But how do any up there? Especially, if what the customer comes to you with, is a big document, describing the features that you must implement.

continue reading →

Sitemaps with a bit of Metal

Photo remix available thanks to the courtesy of tinkerbrad. CC BY 2.0

Sooner or later, you will probably start taking care about your application's SEO, especially if it provides a lot of content and you want to be discovered by users in search engines results. There are several ways to do this in your Ruby app. You can create sitemap.xml file manually if there aren't very much urls, but it will become pretty ineffective when you have more than a dozen or so. There are some very neat tools which will do this for you out of the box, even if you need a lot of customization.

continue reading →

Pretty, short urls for every route in your Rails app

Photo remix available thanks to the courtesy of Moyan Brenn. CC BY 2.0

One of our recent project had the requirement so that admins are able to generate short top level urls (like /cool) for every page in our system. Basically a url shortening service inside our app. This might be especially usefull in your app if those urls are meant to appear in printed materials (like /productName or /awesomePromotion). Let's see what choices we have in our Rails routing.

continue reading →

37 signals was not lying, you win by being remote

There is such moment in developer's life when you start looking for a new job, sooner or later. You can observe that even in Poland, there are plenty of Ruby on Rails job offers, often in very perspective companies. I probably could find interesting job in Poznań, where I live, but there were some presumptions which pushed me to apply to Arkency.

continue reading →

Rails and SOA: Do I really need to have this big app?

Developing complex web applications (not particularly Rails apps) is a tricky task. You write your models, controllers, services and optimize application architecture iteratively. But even with the great architecture when your application starts to be huge, bad things happen. Every little feature you'll add will cost you precious time - tests must pass on your CI and workers needs to be reloaded every time you deploy. In addition, you begin to realize that mental overhead with keeping modules separated is huge - you have to remember a lot of things to keep it in right fashion. Ultimately, working on a project is hard, TDD technique is inefficient to use and you're not happy at all with your code.

Have something gone wrong? No. You just didn't notice that you need more applications than just one.

continue reading →

CoffeeScript acceptance tests

You've already learned how to implement simple model and view tests, so as I promised now I'll show you how you can introduce acceptance tests on client-side. We're not too far from this goal - you know how to write test cases, make assertions and “click through DOM”. Let's apply some abstraction then - to look at our app like the end user.

continue reading →

3 ways to do eager loading (preloading) in Rails 3 & 4

You are probably already familiar with the method #includes for eager loading data from database if you are using Rails and ActiveRecord. But do you know why you someties get few small and nice SQL queries and sometimes one giant query with every table and column renamed? And do you know about #preload and #eager_load which can help you achieve the same goal? Are you aware of what changed in Rails 4 in that matter? If not, sit down and listen. This lesson won't take long and will help you clarify some aspects of eager loading that you might not be yet familiar with.

continue reading →

Developers oriented project management: Leave tasks unassigned

As with software, improving your company is an ongoing process consisting of multiple small steps. If you want your company to be more remote-friendly it is also not all-or-nothing decision. You can gradually start using techniques that will bring you closer to your goal. This series of blogposts is not about why you should go remote, but rather how. Also, we belive that those techniques will help you even if you are not planning to work remotely.

The first part was about having very small stories and how it helps everyone track progress and provides closure. Today we are going to talk about leaving tasks unassigned instead of delegating them to particular developers at the beginning of an iteration.

continue reading →

Services - what are they and why we need them?

Model-View-Controller is a design pattern which absolutely dominated web frameworks. On the first look it provides a great and logical separation between our application components. When we apply some basic principles (like 'fat models, slim controllers') to our application, we can live happily very long with this basic fragmentation.

However, when our application grows, our skinny controllers become not so skinny over time. We can't test in isolation, because we're highly coupled with the framework. To fix this problem, we can use service objects as a new layer in our design.

continue reading →

Throw away Sprockets, use UNIX!

The Sprockets gem is the standard way to combine asset files in Rails, but it wasn't very straightforward to use in stand-alone projects, like Single Page Applications without backend, before the sprockets command was added.

Few weeks ago I realized that Sprockets solve the problem that has been already solved, but in a different language and in different era of computing.

Later I wanted to check whether my idea would actually work and started hacking. You can see the results below.

continue reading →

Developers oriented project management

Working remotely is still a relatively new thing compared to going to an office, which has centuries long tradition. Despite its tremendous growth recently (especially in IT industry), there is not a lot of literature about best practices and working solutions. We still miss patterns for remote collaboration.

Many companies try remote working, but fail at doing it effectively.

They go with the conclusion that it is a broken model. But the truth is, that working remotely is just different, and expecting it to be the same as stationary work, with just people in different places, is the biggest mistake that one can made about it. To fully benefit from it, one must learn how to get most out of it.

You need to learn how to embrace remote work, instead of working around it.

On the other hand, some companies are already there, when it comes to remote working. Or at least they think they are. But is there something more that we can strive for? More ideas that we can try and benefit from? Many of them.

continue reading →

CoffeeScript tests for Rails apps

You may know this pain too well - you've created rich client-side in you Rails app and when your try to test CoffeeScript features it consumes much time to run all test scenarios with capybara and any of browser drivers (selenium, webkit, phantomjs). Let's apply painkiller then - move responsibility of testing front-end to… front-end.

continue reading →

Ruby and AOP: Decouple your code even more

We, programmers, care for our applications' design greatly. We can spend hours arguing about solutions that we dislike and refactoring our code to loose coupling and weaken dependencies between our objects.

Unfortunately, there are Dark Parts in our apps - persistence, networking, logging, notifications… these parts are scattered in our code - we have to specify explicit dependencies between them and domain objects.

Is there anything that can be done about it or is the real world a nightmare for purists? Fortunately, a solution exists. Ladies and gentlemen, we present aspect-oriented programming!

continue reading →

Implementing worker threads in Rails

If you care about your application performance you have to schedule extra tasks into background when handling requests. One of such tasks may be collecting performance or business metrics. In this post I'll show you how to avoid potential problems with threaded background workers.

continue reading →

The A Team

I work in Arkency for almost 4 years and lately I've started to think how it influences me. Working together is not only about delivering some good as a bunch of people - team has own identity, own culture. These days I decided to write down what I found out about my team for two reasons. First is just to see some day how it evolved over years - but that's a good reason to write it in “My sweet diary”, holden under a pillow. I'm also inspired by great blog series “We are principled” by 8th Light.

continue reading →

Is it cute or ugly?

Yesterday day I presented a small code snippet to my dear coworkers (who I of course always respect) and (as usually) they were not impressed, even though I liked my solution. So I wanted to know your opinion about this little piece of code. Let's start with the beginning.

continue reading →

Naming in OOP

There is a well known cite on naming in our industry:

“There are only two hard things in Computer Science: cache invalidation and naming things.” Phil Karlton

To be honest it's not Computer Science specific issue, but common problem for whole science. History of science is composed of discoveries and evolution of definitions. Every math theorem is based on some definitions - I would call it “theorem dictionary”. There is also huge branch of philosophy aiming to figure out how our language infleunce on our thoughts. So I asked myself - how naming can influence my design. What can I learn from bad names?

continue reading →

Black-box Ruby tests

Chillout.io architecture is distributed - currently just as few processes on same production server. As professionals we decided to prepare integration tests for each of application (maybe in terms of their business we could call them acceptance tests), but that wasn't enough - we wanted to expose business scenarios that we're actually aiming in. We achieved that with fully black-box tests. Curious how we did that? Read on.

continue reading →

Rails API - my simple approach

I have seen people using very different techniques to build API around Rails applications. I wanted to show what I like to do in my projects. Mostly because it is a very simple solution and it does not make your models concerned with another responsibility.

continue reading →

You don't inject for tests

What is unit testing for? Is it a way to make sure that your code is correct and bugless? Or rather OOD tool, that expose most of places where you break object orientation principles? You may have your own answer (please comment though) but I would vote for the second one - of course it may assure me that I haven't introduced some totally stupid bug, but that's less interesting part.

continue reading →

Blogging for developers

There are many possible blogging platforms out there to be used, yet we decided not to use any of them. It was a controversial decision even inside our own, small team. Before we started blogging there was a heated discussion whether we should use something that can quickly get you running so that when you feel in a mood for a blog post, there are no obstacles preventing you from writing. Or the alternative was to build something custom and have more control. We ended up using existing tools but put a little effort to combine them together into something that we like.

continue reading →

Sending async data from Rails into the world

Exceptions and business metrics. These are two common use cases involving delivery of data from our Rails application (or any other web application) to external services that are not so crucial and probably we would like to send them asynchronously instead of waiting for the response, blocking the thread. We will try to balance speed and certainty here, which is always a hard thing to achieve.

This is a series of posts which describe what techniques can be used in such situation. The first solution that I would like to describe (or discredit) is ZMQ.

continue reading →

JavaScript objects philosophy

As a web programmer you use JS from time to time or on daily basis. You probably know how to create and use objects, but don't feel that approach is natural. It's awful JS, right? No, it's you and your lack of knowledge. Let's see what object orientation in JavaScript mean.

continue reading →

Filepicker and Aviary - Image uploading on steroids

We all have been using the same code for uploading images for years, but didn't you always feel that there is something wrong with it? For every other task like writing texts, picking a date, selecting from lot of choices we have a good tool that can help in implementing such feature and improve the user experience, but file uploads almost always feel a little broken. There are some Flash tools that might help, but they are still not good enough.

continue reading →