There’s a dashboard in one of our applications that shows data from various external services. The more data we were adding to this dashboard, the worse its performance and user experience was getting until the site eventually became unusable. It got to the point where its user had to wait 10 seconds or even more for the content to show up. Unfortunately, caching didn’t help much.
Here’s the story of what we did to reduce the load time.
It seems like it happened yesterday. I arrived at the flat in a crumbling tenement located in the Old Town of Wrocław and my journey into the Ruby world began. The community was already large and very active, so I wouldn’t call myself Columb, but—at least—I can tell you about my first year experience and share both bright and dark sides of the story.
It’s time for New Year’s edition of our summary of the content found in couple of the last weeks. While you are getting back into ordinary flow you can read about Vim, objects in Rails and improve your hacker’s toolbox. Enjoy!
As you could notice I’m big fan of Vim and I promote it intensively among colleagues. Even if you think that it is not for newbies or you feel uncomfortable using it, you should be aware that you’re probably using an editor which is not designed for programmers. So, if you are interested in topic, just know that you can build an IDE around Vim, arm it in powerful search feature or configure for writing… prose.
Don’t forget to read our review of the awesome Practical Vim book.
At last but not least, if you’re still not convinced, check this amazing tip how Vim can save your time.
There are a lot of interesting ideas how to improve OO approach in Rails. Xavier Shay shared with his solution for form objects and completely redesigned idea of controllers. Chris Flipse shows how you can isolate validations from AR objects which plays well with the idea of form objects and splitting AR into Domain Objects and persistence layer.
DHH encourages us for more intensive usage of Concerns, which he compares to DCI idea. Actually, it’s not the same, so keep in mind Victor Savkin’s page about Ruby and DCI. If we are talking about DCI—there are some interesting voices in the discussion. Gregory Brown raised some common issues about this paradigm, and Rebo responsed with nice article about DCI’s ‘C’ part.
We are looking forward for another possible cure of AR-madness, which could be DataMapper 2. Solnic just wrote some notes about plans and roadmap of this well looking project. You also try some already available patterns to decompose fat AR models.
‘Small’ patterns are as important as those ‘big’ ones. So don’t forget that booleans are bad and do not overuse subject in rspec tests.
During last month we found some cool stuff and tips which could improve your hackers toolbox. Vidir is a vim-like tool for mass-edit of file names—open directory, edit names with power of Vim, save and quit and voilà! If you like functional programming you will probably add this simple map alias into your shell. For impatient devs we’ve got another tip, that would automatically reload your irb session.
From our stable: Tymon has a nice tip about tmux and ssh and Adam reveals hidden gems in less.
That’s all for today. Thanks for reading and I wish you a Happy New Year!
A couple of months ago Bartosz described how we use Facebook to improve communication in our team. Actually most of the content on our wall are more or less interesting links from the internet. We quickly noticed a troubling pattern though—they are easy to forget. And if you forget them, you can’t use them.
So we decided that we’ll be regularly preparing a brief summary of the best content so it’s easy to find and convenient to browse. Our goal is not to provide The Hot News™—you can find them anywhere—but the top of the top stuff which we believe will remain valuable for a long time. So… let’s start!
Roy Tomeij, one of the speakers on the last wroc_love.rb conference, suggested that classes should be replaced with data-* attributes for JavaScript selectors. Recently he followed it up with some benchmarks and shared the numbers. If that doesn’t convince you, read why classes are for designers and data-behavior is for JavaScript developers.
If you have problems organizing your JavaScript assets when using Sprockets, you should read an awesome article from Unholy Rails: adding JavaScript to Rails.
How to (and why) test factories—short and easy, but very useful protip from Thoughtbot.
If yours tests take too long, check if you can replace doubles with OpenStruct. Xavier Shay did some benchmarks on the subject.
There is new shiny tool on the horizon, Testacular, and I think it can soon replace Selenium. It allows to run tests in multiple browsers with your favorite testing engine under the hood. Read more in DailyJS article.
If you don’t feel comfortable writing tests, there is a new site for you: betterspecs.org, the collection of bad examples turned to good. It’s open-sourced so you can always add a new example or fix another if you disagree with proposed solution.
DCI is a hot topic these days, but there is still lack of good examples, especially in Rails context. Victor Savkin fills this gap with an article Data Context Interaction: The Evolution of the Object Oriented Paradigm. If you like the solution proposed by Victor also check his gist collection and DCI-Sample repo.
Another interesting approach to DCI in Rails is shown on already mentioned Xavier Shay’s blog in article titled Dependecy Injection for Rails Controllers.
At last, an article about patterns themselves: The First Step to Applying Design Patterns: Don’t. Very good explanation why design patterns are awesome, when you should use them and when not.
See you next time!
From time to time you need to turn off your app to make some more complicated changes, fix the mess when something goes wrong etc. In short – you want to turn maintenance mode on. In this brief article I will show you the simplest solution for apps running on awesome nginx.
What do we need?
Platform as a service is getting more and more traction recently. However it doesn’t mean that one should start developing his applications with Heroku or Engine Yard in mind from now on. Self-managed solutions, be it own dedicated servers or using cloud infrastructure (like Rackspace Cloud), are still valid choices in most situations.
At Monterail we’re maintaining tens of web applications that are hosted in all of above-mentioned environments. We developed most of them, but there are also some legacy ones (even Rails 1.2 or PHP). So there is plenty of factors that affect hosting infrastructure, and basically each app need to be evaluated individually.
If you are not a regular JS developer but Ruby one or whatever, you probably don’t know every feature of JavaScript or jQuery, even if you use them every day. But some of them are worth spending some time to get to know – for me one of such features was jQuery.Deffered which I would like to introduce in this post.
Currently 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.
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:
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
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.
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.
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:
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.
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”.
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!