Tuesday, August 23, 2016


I seldom talk about services here. I only do this when I really believe the service maybe a good thing. And this is the case of SandCage, a recently launched startup which, maintaining a quality service, will be a great success, I believe.

I suggest you to pay a visit to their website and see for yourselves:

Saturday, August 20, 2016

Emerald Framework - Guidelines

After the post "MVC or not MVC?", many people wrote me to ask about Emerald Framework. I don't intend to talk too much about it before the first release is available, which is scheduled to next weekend, but I decided to post here about the guidelines I followed in the development, as well as about some special characteristics of it.

The first interesting point about it is the fact it is written in Ruby and will be distributed as a Ruby gem. But it is not limited to Ruby. In fact, it's slogan is

Many programming languages
One framework to rule them all
One framework to find them
One framework to bring them all
And in the web bind them

Yes, I love Tolkien's "The Lord of the Rings"! And the releases will be named after characters of this books. This first release will be named "Aragorn".

We are so used to the fact that all frameworks are tied up to one language that we tend to forget that a framework is not language, but methodology. It is more connected to the procedures, the flow of development, than to an specific language. As the name says, it is a frame of reference for development. A set of tools and rules, a specific architecture. Stealing a few words from Fabio Akita, in this article here, "a coherent, opinionated full-stack".

So, Emerald Framework will be written in Ruby, but it will make possible for its users to develop using Ruby, PHP, Python... and other languages in the future, if the community around it create new sets of generators for other languages. As long as they keep the development rules in mind.

Yes, because Emerald has rules! I'm going to tell you about some of them, the main ones.

  • Be simple, without being simpleton. I value simplicity. My ideal of perfection is not something we don't have anything to add, but something we don't have anything to take away. Something like a Japanese Zen garden.
 A Japanese  Zen garden

One of my criticisms about PHP language is the fact they inserted too many things in it's ecosystem and it ended up as a big mess. Similar what good old Richard Stallman did to Emacs. Hell, that thing may even act as psychologist, if you need one!!! And believe me, if you are ready to discuss your mental condition with a computer program, then your really need a psychologist!!!

 Richard Stallman
  • A total separation of (Ruby | PHP | Python | ...) code and views. As I said in the above mentioned post, I don't like HTML code being server-side processed to detect special tags, like ERB does in Rails. First of all, this impacts performance. Anyone who dealt with configuring Apache to run PHP, as I did thousands of time in the last twelve years, knows what happens to performance when you say to PHP module to parse all .html files instead of just .php files. As far as I'm concerned, the only acceptable programming language one may write within HTML code is Javascript.
  • Server serves data, not pages. One of the sequels of my above mentioned post was a comment done in a LinkedIn group by a programmer. He said I was making no sense at all when I said servers shouldn't serve HTML pages. It surprises me to see people thinking like that, when I've had so many talks with senior programmers and software architects about just the opposite in the last few years. The objective of a web server is not necessarily serving HTML pages, but serving 'things' for the web! If fact, in the last few years people are doing huge efforts to avoid this: AJAX; data-aware components reloading just pieces of data when data changes; push technology; libraries and frameworks like knockout.js, ember.js, react.js and others. This is why I got surprised to see that some people still haven't got the spirit of this movement. When one transfers the HTML creation to the browser level, the web also profits from this, with a massive traffic reduction. And if you do it smartly, your pages will load faster.
  • Forget MVC. This was another interesting sequel of my post. I was in a skype call with a customer of mine and one of his programmers. We entered this subject of Emerald and I mentioned that Emerald wasn't MVC. The guy asked, as if he was surprised: "If it is not MVC, then what?" I felt like if MVC were the only thing people knew about web development standards now, and this is absurd. There are lots of other standards, and some of them are obviously better to web development than MVC. Then, why is MVC so popular? Why, for instance, Rails adopted it? The answer is quite simple, indeed. It works and organizes things, then it is better than no standard at all. If you doubt what I'm saying, maybe you'll change your mind reading these articles.
  • Loosely coupled components. A simple implementation decision helps Emerald to have its inner parts, its inner components, loosely coupled. We have no special data type being passed from one component to another. We use JSON extensively to this. Adopting a widely used public standard, not a proprietary one, makes Emerald's components easy to replace in future releases and able to be used by any library capable of sending/receiving JSON. I know that it is not usual, these days, to think about the future, to plan for future releases. YAGNI, "You ain't gonna need it", they say when we talk about planning a bit more. And I tell you that this lack of planning is one of my usual sources of humor, every time I see a team involved in an extensive refactoring due to the fact they needed to perform some change that could have been predicted with a few more hours of planning in the very beginning of the project.

 There are certain moments when worse is better.
But generalizing this as a immutable truth is as stupid as any generalization.
  • Focus on DRY. We base our development in small components made of Javascript in the UI/UX and of [Ruby | PHP | Python | ...] in the back end. Both parts are small, clean and independent. Both very easy to reuse in other parts of the systems created with Emerald. This is a great help when it comes to enforce the DRY principle. We don't need to repeat code because we made it very easy to reuse code wherever we need to.
 Repeating himself didn't help Agent Smith
  • Provide archetypes. Those Java programmers who are used to Maven know how easy it is to start a new system when there is an appropriate archetype to model it to you. We are going to enforce among our users, and provide tools for, people uploading archetypes for many types of applications to Emerald servers. We believe we may have an easily accessible bank of solutions to help Emerald developers to do things quickly and easily, without the need to rethink solutions that are almost always based on the very same basis. Those who created a blog using a framework, for instance, know that all those who do this create the same classes, with the same names and almost the same content. Having archetypes is taking code reuse to a new extent in web development. And if you need more than the usual, go ahead and take the archetype as a head start and improve what you need.
  • Your app is completely disconnected from Emerald. If you want to know why I mention this, open this great article by Piotr Solnic, "My time with Rails is up", and search form ActiveCoupling inside it. Emerald does the perfect separation among the framework and the app. I'd like to thank Piotr, for he called my attention to this problem, helping me to avoid it in Emerald.
  • Emerald is SEO friendly. SEO techniques are very important today. Thanks to a gem I developed and to a simple routing process, it was easy to make Emerald SEO friendly.
  • Have a great CLI. A great command line interface has always been a must for me. This is something that attracted so much users for Rails. I opted for Slop gem to help me build this CLI.
I believe this is enough for now. If anyone has questions, suggestions or criticisms (which are always welcome), please send your ideas to


and I'll be pleased in discussing them. I'm also looking for beta testers to Emerald and if you want to take part in this project helping the tests, I'll thank you very much.

Thursday, August 18, 2016

Tiobe Ranking of programming languages - August/2016

This is the new ranking of programming languages published by TIOBE (http://www.tiobe.com). It is updated till August/2016.

Everytime I post this ranking here (and I've been doing this every month) I got a lot of strange reactions. People say things like:

"I am a Go programmer and I know Go is not the last language in the world."


"Of course there are more jobs for Ruby than for Java. I've been searching for a Ruby position and I noticed this."

Then, let me explain one thing. Or else... let TIOBE explain itself. This is a link to the page where TIOBE explains this ranking: http://www.tiobe.com/tiobe-index/programming-languages-definition/

Then, before calling me names or cursing me and my seed, please read the explanation to understand what the ranking really means.

I'm not a radical for any language. I love Ruby, but I also love Java, C, Object Pascal and LISP. And many other languages. Because what I really love is programming. And, as a matter of fact, I strongly believe in two things:
  • There is no "best programming language". It all depends on many factors, like what you are using it for and your knowledge of it.
  • The best tool is the tool you know better.

Tuesday, August 16, 2016

MVC or not MVC?

I've been away for a long time, without posting anything here, and I beg your pardon for that. I've been too busy with my life-project, the Emerald Framework. This framework will be the next good thing in web development. I'll talk a bit more about it soon. But those very curious may just drop me a message at emerald.framework@gmail.com and I'll send some material about it.

I'd like to talk to you about MVC. And the reason for that is exactly the fact I was talking about Emerald Framework with two people yesterday night and I got really surprised because when I said Emerald wouldn't use MVC  one of the guys (a developer!) asked me in surprise: "If it is not MVC, then what it is?" And he asked this question as if he never heard about other patterns for web development.

This moment I realized how MVC turned out to be popular in the last few years  and how people forgot about other patterns, believing MVC is kind of a "magical solution" to all problems.

Then, let me tell you some point about MVC people tend to forget:
  • MVC is far from being the unique pattern available. We have lots of them. In fact, here we may use that famous quote by Andy Tanenbaum: "The good part of standards it the fact we have so much of them". This ironic quote is oh-so-true when we talk about web development patterns: HMCV (Hierarchical MVC), MVVM (Model-View-ViewModel), PAC (Presentation-Abstraction-Controller), MVP (Mode-View-Presenter), NO (Naked Objects)... I could continue for a long time naming other patterns, but I prefer to let you free to research by yourselves visiting this link  here.
  • MVC is usually a BAD solution when it comes to performance, at least when compared to other options, but this is not MVC's fault. The fact is MVC frameworks were designed to favor maintainability  and readability, not to favor performance. If you really like MVC and is worried about performance, I suggest you to write your own MVC implementation designed for this.
  • MVC is not a good choice for small applications. It is counter intuitive in these cases. You will work too much to have a single page running with MVC, when compared to other options. In fact, if you have an application with only two or three pages, forget all you heard about patterns and code this yourself, in you own way, putting all possible frameworks aside.
  • MVC provides separation between code and presentation, but not as much as it would be possible. In fact, this is one of the questions I specially addressed when I was writing Emerald Framework. I just don't like ANY kind of Ruby (or other language) code mixed with my HTML code. ERB, for instance, is not a good choice to me. I don't like those <%= %> tags mixed with my HTML code.
  • Most MVC frameworks are going to force the web server to perform the inconvenient task of serving HTML code. It's just me or there are others here who believe a web server should be reserved to more noble tasks, like producing dynamic data? This is an old issue in certain circles: let the browser deal with interface generation, provide just JSON and let Javascript build the interface for you. Isn't this, for instance, the essence of knockout.js, for instance? Among other advantages, you may have not just dynamic data, but also dynamic interfaces, customized to each user.
And you? What do you think about MVC? I would really like to know what your opinion, so post a comment here and speak your mind.

See you next post!

Monday, August 1, 2016

Can't find the 'libpq-fe.h header

This is a very common error when you are make your

$ bundle install

in a Rails project using PostgreSQL. And the solution is very simple.

This error means a certain header is missing when compiling PostgreSQL native extensions. This header is provided, at my Debian 8 Linux distribution, by a package named libpq-dev. Then you just need to do

$ sudo apt-get install libpq-dev

and it will be installed.

When I'm using Fedora (before 22), I just do

$ sudo yum install /usr/include/libpq-fe.h

or, if your Fedora version is 22+, try the same with the new package manager, dnf

$ sudo dnf install /usr/include/libpq-fe.h

I am sure you may find this header for your distribution by using the greatest programming helper of all times, Google.