Using the story of The Sorcerer’s Apprentice -the one with Mickey Mouse, not the one with Nicholas Cage-, I explain what is metaprogramming, the most common techniques and some of its dangers.
You can also watch the presentation in video:
]]>By the way, you should watch his keynote. The best moment: “Designing a language means programming programmer’s mind. So I designed a language that programmed you. I brainwash you!” (16:35).
]]>Anyway, last week I was able to share my experiences on startup metrics in a talk in the Conversion Thursday Barcelona, a monthly event about web analytics and marketing online.
Unluckily, the talk was in Spanish: I hope my next one will be in English. Anyway, enjoy it!
]]>This article is NOT about architecture (you can read a great article about that here. This article is about some very basic tips and tools that all Rails developers should use when trying to improve their application performance. Things like:
before_filter
hooks. This is mandatory if you are using authentication, for example.Anyway, action and page caching are deprecated in Rails 4. The real thing here is fragment caching: to cache any part of a process, including part of view rendering. This is specially useful in expensive calculations that don’t change in a long time, like periodical statistics. In Playfulbet, I cache using memcached and dalli.
For a better understanding of Rails caching, I would recommend to read the episode Obie Fernandez wrote about it in The Rails 3 Way. Rails documentation is fine, too.
An example:
user.bets.map { |bet| bet.option.odds }
This code will result in 1 + n calls to the DB, where n is the number of bets that the user has.
user.bets.includes(:option).map { |bet| bet.option.odds }
This code will result in 2 calls to the DB.
You also can include a deep hierarchy of associations using a hash: user.bets.includes(:option => {:market => :event})
. Eager loading also accepts a :conditions
option.
There is another issue with eager loading: that it is not lazy. That means that the query will get executed in the controller, not in the view: and that could lead to unnecessary queries (for example, if part of the view is cached).
You can learn more about it in this Railscast episode.
The “materialize” rule has another meaning: to avoid recurring queries materializing the value in a column. A basic example of this philosophy is counter-cache, a DB column automatically updated by Rails that saves the total amount of a multiple association. Like this, it completely removes the burden of a recurring SELECT COUNT(*)
.
There is a third meaning: to materialize in a model an attribute of another model that the former is using recurringly. You need to be EXTRA cautious about that -somehow it’s a violation of basic OOP principles- and only use it when it will make a big difference in performance. For example, when there are many classes between the accessor and the accessed.
pluck
: If you are using queries that return a large amount of records, that’s a big burden for your server’s memory. That’s specially not optimal if you only need a single column of the record.pluck
, a method added to Rails in 3.2, solves that problem. Essentially, it selects a single column in your SQL query. I will give you a real example from Playfulbet code. In the first case, we make a Bet
query loading thousands of User
objects, which are quite heavy:
user_ids = User.where("created_at < ?", Time.now.beginning_of_month).map(&:id)
Bet.where(:user_id => user_ids)
On the other hand, this loads only an array of integers for making the same query:
user_ids = User.where("created_at < ?", Time.now.beginning_of_month).pluck(:id)
Bet.where(:user_id => user_ids)
A simple example: the very popular will_paginate
performs a SELECT COUNT
query to calculate the number of pages. This query can be avoided if you materialize its result and pass it directly to the paginate method in the :total_entries
option. In this case, I paginate the bets of a user without querying the total amount and using counter-cache:
@bets = @user.bets.paginate(:page => params[:page], :total_entries => @user.bets_count)
]]>Even if this victory doesn’t imply any investment, it obviously shows the potential of Playfulbet. We thank all the First Tuesday attendants for trusting us.
You can read more about it here (in Spanish).
]]>This same presentation brought me a nice surprise today. It was featured in Slideshare homepage:
Sorry, I couldn’t take any screenshot of the actual Slideshare homepage.
Mine was the first Itnig’s Fridays presentation featured in this popular site homepage. I hope this helps to extend the use of Open Graph!
]]>To explain this, and much more, I made the presentation One Graph to rule them all: Integrating your application with Facebook at Itnig’s Fridays. In the presentation, I described all the process that a developer must follow to publish its application’s actions in the Open Graph: asking the right permission from the user, creating a page for every object that will be used in the actions and, finally, defining the action itself. I also talked about the most typical issues: the weird behaviour of Facebook’s cache and the unpredictable response of Facebook staff when they have to approve your action. I finished the presentation remarking what a great difference can this make in your application visibility.
Usually all the Itnig’s Fridays talks are recorded, but this was lost because of some weird technical error. Anyway, if you have any doubts about the presentation or the Open Graph, you can tweet me at @crplanas.
]]>Until now, I was Senior Ruby developer and Project Manager at Itnig: a start-up accelerator. There I worked as developer in projects like PharmaDating or the Instituto Maxilofacial website. But my main task was being the project manager (and lead developer) of Playfulbet. And I liked the project so much that I decided to dedicate myself entirely to it.
So a big nominal change (from Ruby developer in one company to CTO in another), but smaller in fact: I am still the man behind Playfulbet. Maybe the real change is philosophical. Before I was a developer who happened to like the start-up environment; now I am also risking myself as an entrepreneur.
¿And why did I decide to risk myself? First of all, I think that Playfulbet is an extremely cool project with a bright future ahead. Playfulbet is a sports betting social game, a project that puts together two areas which are greatly growing: social gaming and gambling. Also it has some of the elements that attract me more to a project: big data (bets and users data) and a social aspect.
Wish me luck!
]]>$("#menu li").on("hover", $(this).siblings().css("background-color", "red"))
]]>Anyway it would be much better if the speaker explains himself:
PD: And by the way, in the last BaRuCo I was able to talk with him and get his book signed.
]]>The day started with some talks, where some Facebook employees presented all the features of the Open Graph: that was pretty convenient, as I am developing right now the Graph integration of Playfulbet.
After the talks, the Hack itself started: all the developers there had to create teams and start building an application using the Graph. There was even some prizes for the best ones.
Unfortunately, most of the assistants were PHP developers, so I decided to leave a bit earlier, without participating in the Hack. Sometimes I wish that Ruby was more mainstream!
]]>First of all it’s important to remark how amazing the organization was: all the attendants were really well treated. In the picture below, you can see the delicious breakfast that we were able to enjoy just before the first speakers started:
But the main point in any conference is the quality of the talks, and BaRuCo speakers did a real good job: the quantity of the talks was small compared to other conferences, but most of them were really interesting. Some of them were slightly too technical for the audience who approaches for the first time the topic that is exposed, but most of them found the perfect middleground between depth and simplicity. However, there were some that stood out…
Bronze medal for…: Programming workout by Michal Taszycki. A description of how to get from beginner to master in any discipline, with some useful techniques for improving in any area. I really like this kind of talks with a broader, more humanistic scope.
Silver medal for…: Micro-Service Architecture by Fred George. I already praised in this blog another awesome talk given by Mr. George: he is a really gifted speaker. This time, he exposed how his company faced some difficult cases dividing the architecture in multiple applications, managing to reduce the complexity of the solution.
Gold medal for…: Why Agile (A short history of software engineering, and other ideas that didn’t work) by Paolo Perrotta: I was a big fan of Mr. Perrotta since I read Metaprogramming Ruby, a book which changed the way I understand developing; but now… fuck, everybody in the congress fell in love with him. He stole the show with a great and very funny talk about how the own concept of software engineering is a misunderstanding of our craft.
Summarizing, looks like that Barcelona has a new you-can’t-miss-it event. We are already waiting for 2013 tickets.
]]>In the next weeks I will explain some of my new projects, describing some of the difficulties I had to face and how I solved them. Mainly, issues with the architecture of a social sport betting application and a gem that I developed for it. But this won’t be today.
What I would like to explain today is how Drew Neil, the creator of Vimcasts and author of Practical Vim ran a Vim Masterclass at Itnig HQ, where I work. It was more than one month ago, but it was so cool that it is worth to write about it after so much time. :P
Talking about the workshop, my impression was very positive. As always with Vim, I really feel that I am using only a very small part of its amazing features. The workshop proved me right (about my own lack of skill, but right): Vim is as flexible as you want it to be, and it gives you the possibility to -as Neil’s book tells- “edit text at the speed of thought”.
PS: This weekend Baruco starts. I will be there, and I hope to tweet quite a lot about it. Follow @crplanas on Twitter!
]]>In this, Ruby also stands out. Developers not only are able to use the usual if and else idioms, but count with some nice additions.
In any kind of code, negative conditions are used quite often: and the
if not
idiom is not natural at all. Ruby provides of an specific idiom
to state a negative condition: unless
. For example, this:
if array.length != 1
looks much more nice like this:
unless array.length == 1
This also has its counterpart in loops, as until is the opposite of while.
And thinks that most of the time people are saying the truth. So when Ruby evaluates a variable as a condition, everything except nil and false will be passed as true. That has some interesting effects:
if 0 puts 'C developers, 0 is true in Ruby!'
Ruby always try to be as readable as possible, so it adds a new way to define a condition: leaving it after the actual code. For example, following the example given before:
puts 'C developers, 0 is true in Ruby!' if 0
That’s a great help. For example, imagine we have this code:
puts "The length is 2" unless a.nil? || a.length == 2
In the case that a is nil, in other languages we would have an exception, as the nil element doesn’t have any method called length. But Ruby is smart enough to know that in an OR you don’t need to evaluate the other conditions if one is true.
When a Ruby beginners faces a piece of code, the most exotic idiom he can find will probably this: ||=. This is called the nil guard. It comes to save a typical problem: an assignation that only should be executed when the variable assigned is nil.
a ||= []
that’s much better than
a = [] if a.nil?
it’s just more elegant. As you can see, the nil guard is related with the executing the conditionals in order thing.
]]>One of those apps, probably my favorite, is TweetMovies: a special social network to discover great films and sharing your opinion about any of your favorite, or least favorite, movies. “Tweet. Read. Share. Discover cinema the social way!” is the motto of TweetMovies, and everything in the application, from the specification to the graphic design, is around that. In the end, we live in the 2.0 world!
In the creation of TweetMovies, integration with other social networks was truly important: users don’t need to register in TwM, as they can access the main features of the application only logging in with your Twitter account. TweetMovies also integrates with Facebook as any comment written on our application can be redirected to the Twitter and FB accounts of the users, giving you the power to share your views on movies with your friends and the world.
One of the main goals of TweetMovies was to create a space where all the opinions around the film world could be organized. Twitter and the other social networks are fantastic jungles of information, an utopy for any datamining lover. But often it’s hard to find interesting and fair judgments about some topics: TwM tries to be a solution to that. The opinions of our users are ranked by other users and our own algorithm, giving them the chance to read first the most important ones. This way, TwM tries to be not only a social tool, but also a point of reference for anyone interested in movies. With TweetMovies, you will get a quick and attractive answer to the most typical questions: Should I watch this movie? Is it good? In TweetMovies we don’t believe that a number is enough, like other applications do. For us, words are more important than numbers: anyone trusts more a friend giving a reasonable opinion than other saying ‘six point three’.
Being a complex and modern application, in the creation of TweetMovies were used a great variety of tools. As a true Ruby believer, I used Rails in the application development. For the integration with FB and Twitter, Omniauth; for user authentication, Devise; and in the general design of the site, Slim, Sass, CoffeeScript and JQuery. Lots of other tools, mainly ruby gems, were used but it would be boring to talk about all of them.
That’s all. I hope you try and enjoy TweetMovies. Because as Truffaut said, Le Cinema Règne!
]]>In it, Fred George exposes with a great amount of humor a development process where programmers are not just developing the application, but designing and modifying it beyond the customer’s expectations. He also reasons the need of removing certain roles (most of them, actually) that don’t produce code in the development process. As the popular agile (or antiagile?) manifesto says… Programming, Motherfucker!
Personally, I have always thought that developers should take a more active role when discussing the application with the customer: how many times have we ended coding some feature that we knew for sure that was stupid? We have to remember that, in the end, we are fucking technology experts, specially compared to most of the clients (yeah, not being too humble now). We should be stakeholders, and not minor ones, of our own projects.
Here you can watch the conference. I would recommend it, even if you are not very interested in the topic. If you know the IT world, it’s really hilarous:
]]>But they are not the same. In fact, BDD is an evolution, or an extension, of TDD. Let’s try to define and point out the difference between them.
All code is guilty until proven innocent.
In the university, we are taught that the main phases of the software are specification, design, implementation and testing, in this order. In TDD, testing comes before implementation; and thanks to some testing tools, it can be used as a kind of specification.
In a TDD process, we develop first the test and then we work on the “real” code until the test accepts it. In an advanced project, when we implement a change into the code, we run all the tests, and not only the new one: like this we can detect quickly if a new piece of code is causing errors in old features.
The TDD process:
BDD is a business-like, natural language, user-approach to TDD. In it, we first define an acceptance test: we execute it and, obviously, it fails. Then we define a unit test: it fails too. Then, and only then, we can start with the code itself. When the given unit test passes, we execute again the acceptance test, and if it fails, we start the process all over again with a new unit test.
Using Ruby speech, we could say that BDD wraps an acceptance test around a group of unit tests.
The BDD process:
In BDD we also try to make tests particularly readable, using tools like Rspec and Cucumber.
Even if it’s an expansion, and a good one, BDD is not “better” than TDD. It’s just different. In some cases, using BDD doesn’t have sense. For example, in a gem or a plugin, to test the behavior of the user is just impossible.
Actually, developers instinctively understand that: they just are confused by the similar names of B(bi)DD and T(ti)DD. You don’t develop a gem using BDD, even if it sounds cool: it’s TDD.
PS: Another day we should talk if BDD and TDD are so useful or if it’s only a hype.
]]>Being myself quite an eccentric developer, a lot of times I started in a language without caring about this kind of advises. OK, I follow most of the typical patterns -trying to maintain a scalable, blablabla code- but nothing very specific, certainly nothing that cares particularly about MVC.
So when I started to develop my first Rails project, Fundido a Negro , I gave a shit about maintaining small controllers and did as most Rails beginners do: creating grotesquely giant controllers. After some months, that made the code almost impossible to understand, and even if I could have continued with it, it was boring and confusing. So I stopped the project in a “more or less OK” phase and started with something else.
After some months and experiences, I naturally understood what every Rails guru (and most of developers) say: a big controller is a terrible pain in the ass. But why a big model is (much) better than a big controller? I don’t really know the correct reason; I only can adventure a few hypothesis that, I think, tell a lot about MVC.
What the fuck is a controller?. Of the three elements in the MVC, we can easily identify the first one with “real” objects (as in object-oriented); the views are, like in the famous tale, the only part of the real world (more like the data world) that users can see; they care about the relationship between the user and the models. So far, it’s OK. But what are controllers? Only the middlemen, the border policemen between the world of the data/objects/models and the view country where users live.
Code in the model is easier to reuse and harder to duplicate. Imagine that in a given action, you need the first n objects which its relation x applies to a certain condition. If you write that method in the model you can reuse it any other time, or even define it as a scope and save you an awful lot of code. Giving access to every action of every controller to that method will save you from the dangers of duplication, and also will make you more conscious of the tools you already have created, as the models tends to be in the center.
A big model is good for your imagination. When you have available methods that deal with the data in your application in multiple different ways, it’s easier for you to think about new features.
Right now, I already feel like I’m repeating the obvious, but I will show you another example. Those two pieces of code to the same:
Big controller style:
def index_by_trending
@premieretweets = Movie.with_tweet.inject([]) do |res,movie|
res << movie.tweets.by_score[0]
end
end
Small controller style:
def index_by_trending
@premieretweets = Tweet.index_trending
end
(In the model)
def self.index_trending
tweets = Movie.with_tweet.inject([]) do |res,movie|
res << movie.tweets.by_score[0]
end
end
OK. Now let’s imagine we create another action in the same controller, one that needs only the first 5 elements:
Big controller style:
def short_index_by_trending
@premieretweets = Movie.with_tweet[0..5].inject([]) do |res,movie|
res << movie.tweets.by_score[0]
end
end
Small controller style:
def short_index_by_trending
@premieretweets = Tweet.index_trending[0..5]
end
In the end, you are reusing and not repeating code with the “small controller style” solution and well, it also looks much tidier.
Those are some of the reasons why I really appreciate initiatives like inherit_resources, even if I don’t really use it so often (shame on me).
]]>method_missing
.
method_missing
?I discovered method_missing in a great Ruby book: Metaprogramming Ruby by Paolo Perrotta. Originally, method_missing is a function that is only called when Ruby can’t find a given method into an object. If the object is the last in the jerarchy (in 1.9, BasicObject), method_missing
raises an error; if not, it calls the same method in the inmediate superior object in the jerarchy.
Because remember, in Ruby you can redefine methods as you like. With that feature, method_missing
becomes the ultimate hook: you can intercept literally every action (that doesn’t have a method defined yet)) and treat it as you wish. For example, let’s make that everytime we call write_{#something}
, Ruby writes it:
def method_missing(method, *args)
method_name = method.to_s
if method_name.start_with?('write_')
puts method_name[6..-1]
else puts 'This method does not exist here'
end
end
Maybe, but it’s in the core of some of Ruby most popular gems, like (guess) Rails. Have your ever thought how some ActiveRecords methods like find_by_#{attribute}
work? You are right, thanks to method_missing
.
Actually, ActiveRecords combines method_missing
with another great metaprogramming technique: dynamic methods. The first time you call a reader or writer method in an object of a given class, those methods are not still defined: then method_missing
appears, defining the actions for each of the table columns. Clever, elegant and really, really useful.
It doesn’t sound cool, it is cool. But OK, it has some flaws. As with some other metaprogramming techniques, one is tempted to use them constantly, even when there isn’t any reason to use it over dynamic methods or even normal vanilla methods. And those are much better in terms of cost.
Another big flaw: it’s hard as hell to debug. In the end, we are “hacking” an error method, and one of the most basic ones.
As I told in the beginning, it’s a philosophical matter. method_missing
ilustrates perfectly those famous words by Matz:
Ruby trusts you. Ruby treats you as a grown-up programmer. It gives you great power such as meta-programming. But you need to remember that with great power comes great responsibility.
To be able to wait in the backdoor for those treacherous method calls and giving them a good beating -I mean, dealing with them- it really changed my concept of software development. And I guess that is why I like method_missing
. Exactly the same reason that makes me love Ruby.
But, so far, this blogs were essencially about some of my other passions: literature and cinema. This blog will be different: it’s main topic will be my experiences with Ruby and other languages. Of course, I know that it’s always risky to predict the real content of something before creating it, but at least that is my purpose.
But why should a developer write about his job? First of all, to share the new lessons one takes everyday with other developers; right now, for any of us, it’s impossible to think about how it would be our coding without the help of the community via Google, blogs or Stackoverflow. But also because, quoting Einstein:
If you can’t explain it simply, you don’t understand it well enough.
And that’s enough for this entry. Let the real action begin!
]]>