A digital watercooler – easiest way to improve communication inside your team

I have always been struggling with the goal of constantly improving the communication inside our development team. We always followed the idea that team is always more effective than any number of individuals. Since the team has grown to 15+ people and a few of us are in different physical locations throughout Poland, we had to find a way to communicate and share knowledge effectively.

We have tried couple different options:

  • Yammer – enterprise-focused twitter clone. Sluggy, overbloated and not effective for us at all – you don’t want to use a tool that you have to remember about and you find it hard to use!
  • Campfire – 1st choice for people that find IRC not being up to the modern web. A lot of ways to integrate great tools. A lot of great mobile and desktop clients. We used it for over a year and it played well – but it’s a massive distraction generator. We’re using it right now mostly to get notifications about git commits being pushed to our repository.
  • IRC – freenode or grove.io, every option had same problems as Campfire – you don’t want to get distracted by seeing an message and not knowing whether it’s important or not.
  • Jabber group chat – yes, we tried even that one. I won’t comment it.

Thanks, Captain Obvious!

For couple months we’ve been using Facebook groups to share links (and funny pictures, yeah).
Stuff that’s not important to making your job done. It’s a tool that you don’t have to remember about – basically every member of our team uses Facebook, and even ones that weren’t before, have to – simply because we’re building software for / integrated with the Facebook platform (not exclusively, of course, but we still do a lot of it).
We use it to share some cool hacks, tools that improve our workflow, interesting gems, backbone.js libraries, design resources and even to remind about using the water filter in a polite way.
It’s great because it doesn’t break your workflow. It’s easy to use. You don’t have to remember about it – you’re probably using Facebook in your spare time anyway. Think of it as a digital watercooler – a place where people meet to get a few minutes of rest and have a chit-chat – simply because everyone drinks water. And if you’re the guy that brings his own water to work (or do not use Facebook for whatever reasons), you are aware that you’re missing some of the social goodness. And it’s a water cooler that you can bring home along with the people around it. And access it from your iPad. And Android device. And a feature phone.

Important is important!

Don’t get me wrong. We still use an group email to share updates about the office issues, absences etc. We use jabber and email (not mentioning project management tools) to communicate about day to day work. But in this case, when we get an email or an IM, we know it’s the important stuff – noise separated, achievement unlocked.

Backbone.js, Rails 3 and asynchronous interfaces


Backbone.js and RailsCurrently at Monterail we’re building a frontend-heavy app. With a lot of cool stuff. Like preloading data for daily views so that you won’t have to wait for every surrounding day to load. Many, many interactive elements that should be really interactive – not in an oldschool, ajax “spinner” way. And a lot of other stuff we shouldn’t talk about yet.

We decided to put more emphasis on Backbone.js with Rails and build most of the app with this combination.

Below you can find some of our findings on the topic of making those two speak to each other in a nice manner.

Asset pipeline

Really makes things easier. Organizing your JS code before it meant a lot of things: handling dependencies, minifying & compressing the code, organizing it into a lot of different files and building connections between them. With asset pipeline and it’s awesome “require” directive, you can forget about handling it manually. You just create the structure in app/assets/javascripts. Or app/assets/javascripts/backbone. Your choice. You can have many different files in whatever directories you like – in the end you’ll get one (or more, if you decide to) JS file that has everything your webapp need.

Don’t forget to:

  • gzip your JS/css assets
  • minify them!

Rails-backbone gem

Also makes things easier. It puts backbone.js (& underscore.js) library code into your asset pipeline. It gives you some great generators to get started if you don’t know where to start. Definitely worth including in your Gemfile.

http://rubygems.org/gems/rails-backbone

Coffeescript & underscore.js

Obviously. It makes Javascript code feel fresh. You can fold, iterate and do a lot of stuff. Be sure to check out underscore.js docs. And coffescript docs, of course, but I bet you know it already.

“V” in MVC done right

Views are classes. You handle logic inside them using the hardcore code, which is receiving so much hate in Rails views. They can have many methods, they do not have to render a single “action”. And templates are templates – and nothing else. There is a lot of discussion recently on the matter of Views/Templates in Rails, but you can start implementing it right away. Go and try it. You’ll fall in love.

You have many options for templates – eco, Handlebars.js, {{ mustache }}, but we recommend haml_coffee_assets. It gives you the HAML you (probably) already know with the ability to use coffeescript within it.

Single-page app

Yes. You will use Rails to render only the core view of the application. Of course, you will have to handle all things around the core of your app.

For example, you should probably leave out:

  • authentication logic: sign up / in, reset password
  • steps necessary to use the app: billing pages
But, other than that, you can use the views rendered in JS. What does that mean?
  • if they do not include any dynamic data, they are lightning fast
  • if they include dynamic data, you can preload it and they still will be lightning fast
Backbone comes with it’s own router. You can utilise pushState without any effort. How cool is that?

Asynchronous interface

Since you’ll be doing most of the association/validation work in background, you don’t have to worry too much about server responses. It’s the same with rendering elements: you’ll be doing it in JS, not Rails. You don’t have to wait for the request to return the rendered element to actually display them. If you create something, the UI should respond right away and the ajax request can persist the data with it’s own pace.

You should, however, prepare a global “something went wrong, reload the page” request rescuer – in case of network outages, backend app failures and so on. But it’s way easier to manage.

API

You get it for free. It doesn’t have to be public, but if you decide to, it’s a matter of adding OAuth as the way of authenticating requests and it’s done. (Or you could go with http basic auth, which is obviously bad for a lot of reasons).

With smart caching (give redis-store a try), you’ll save tons of server power. You know, relating to the old ruby saying, “views are most resource-consuming”.

Conclusion

There are, obviously, downsides, which I’ll cover in future (I silently hope that there won’t be any reason to do that). And topics I haven’t covered. I’m curious about other stacks and ways of doing things. Share in the comments or ping me on Twitter!

wroc_love.rb

wroc_love.rb is a „Fresh Ruby-oriented conference in Wrocław, Poland” that happens on 10-11 March 2012.

We’re proud to announce that our team got involved in co-organizing the event and one of the outcomes is the launch of the new website – go check it out!

One of the goals of the conference is to supply some solid topics that, we hope, will result in long and red hot discussions.

Don’t forget to follow the twitter account, like the facebook page, follow the tumblr blog and submit a paper proposal - if you have something interesting to say!

Chosen: multiple choice select inputs made easy

Link

http://harvesthq.github.com/chosen/

Great tool for enhancing selects, multiple selects, grouped selects etc. made by the Harvest team (great timetracking tool we’re using on a daily basis).
We’re all about using native controls as much as possible, but multiple select boxes were always a non-usable pain in the ass. This one is a great solution in tight areas where you can’t afford displaying a list with checkboxes.

 

 

 

Outbound API rate limits: the nginx way

Implementing external API rate limits can be painful. There are some solutions that aim at this problem – let’s take Slow Web for example – but things tend to complicate when we start using background jobs, or even oldschool cron-rake setup. Slow web takes care of one environment at a time, not to mention that it relies on Net::HTTP so you can forget using more powerful stuff like Typhoeus.

Recently we started working on a project that uses heavily an API that limits our development calls to one per 500ms and production calls to one per 200ms (our first thought and initial information was that we can do five requests per second, but those are not the same). Inspired by a great post, „nginx JSON hacks”, an idea came to our minds. What if we could use nginx to implement limiting the API? Here comes the built-in nginx module, the HttpLimitReqModule. Let’s take a quick look.

http {
  limit_req_zone  $binary_remote_addr  zone=one:10m   rate=110r/m;

  server {
    listen       8080;
    server_name  localhost;

    location / {
      limit_req   zone=one  burst=100;

      proxy_pass        http://api.example.com/;
    }
  }
}

(Please bear in mind that this configuration is merely an example and you probably want a more comprehensive setup. You can hire us to do the job for you).

We set a simple proxy on localhost:8080, configure the limit_req_zone option, apply the zone, set the burst rate to 100 (depending on how you want to handle huge load, this could be smaller or bigger). We set the rate to 110 requests per minute for a little margin. Our benchmarks went fine, as we expected – no API calls were dropped. Setting it to exact 120r/m (or 2r/s) gave us some 403s, though.

Okay, so what about those cool examples in the post mentioned above? Let’s apply some caching!

http {
    limit_req_zone  $binary_remote_addr  zone=one:10m   rate=110r/m;
    proxy_cache_path  /tmp/nginx_cache levels=1:2 keys_zone=STATIC:64m inactive=60m max_size=128m;

    server {
        listen       8080;
        server_name  localhost;

        location /without_cache {
          limit_req   zone=one  burst=100;

          proxy_pass        http://api.example.com/;
        }

        location / {
            proxy_pass        http://localhost:8080/without_cache;

            proxy_cache STATIC;
            proxy_cache_methods POST GET PUT; # allow POST caching which is not allowed by default
            proxy_cache_valid 10s; # cache every API request for 10 seconds
            proxy_cache_key "$host$request_uri$request_body";
        }
    }
}

Why two locations, you may ask? It’s because we don’t want to have a rate limit for our cached version. In this case, when the first request finishes, every other gets an ultra-speed boost from being stored in a local cache.

We don’t have to worry about implementing API rate limits in every place in the app. We don’t have to worry about sharing those limits between different environments. All we need to do is to change the API host and enjoy pure coding goodness.