Thursday, July 28, 2016

PostgreSQL migrations' problem solved

I'm not a great PostgreSQL user. Sincerely, I prefer MySQL nine in ten times. But this is not a matter of quality, but just the fact that I started my life as a web developer with the couple PHP/MySQL and use this database for years. I even took a MySQL certification! Then you may see the personal feelings involved in my personal choice.

But life is not what we want, but what we have. And learning to avoid personal feelings is important, specially when you are working with a team.

And this is exactly what happened to me this week, when I started with a new project named Routely, a tool designed to make a revolution in the area of field services (like House Cleaning, Pool cleaning, Pest control, Lawn Service and Parking Lot Service). It helps companies to keep a high quality level for their services; helps contractors to be safe in execution time and helps people that need these services to receive the best for their money.

Routely is a great tool and it will be available soon. And I'm working with a great team, led by a brother of mine, Alex (https://github.com/AlexVKO).

The project uses PostgreSQL and I had to install it in my home server to perform the development and test tasks. That's when problems started.

I use PostgreSQL frequently, because I've been using Heroku a lot in the last few years. But then, Heroku infrastructure does all the hard work. A PostgreSQL Heroku user just have to avoid interference and everything will work fine. 


As you may see, I specify databases for sqlite3 for test and development in this configuration file, but when it comes to pg configuration I just let Heroku work and do nothing!

The main point is: I'm not used to install PostgreSQL! My fault! 

Then it wasn't a bit strange when, after install it in my Debian 8, I couldn't run my migrations, getting the following error:



This error

-- enable_extension("citext")
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:

PG::UndefinedFile: ERROR: couldn't open the extension controller file "/usr/share/postgresql/9.4/extension/citext.control": File or directory not found
: CREATE EXTENSION IF NOT EXISTS "citext"

means I was lacking an extension.

If you face this problem with Debian, there is a simple solution. Run

sudo apt-get install postgresql-contrib libdbd-pg-perl

and have this postgresql-contrib installed. This package has all extensions needed to a smooth run of all your features.

If you are not a Debian user, don't worry. Fedora installs this package as a dependency when you install PostgreSQL, and other distributions probably has a similar package. Google it and you'll surely find. And don't forget other great resources for programmers like StackOverflow.

Monday, July 25, 2016

The smallest Mac in the world

One more post to relax! 


Thursday, July 14, 2016

Ruby is among the fastest growing languages for two consecutive months

The TIOBE index for July/2016 is already online and you may see it here.

It is not a surprise that Ruby is among the fastest growing languages, for the second consecutive month, having ascended five positions since July/2015.


Assembly continues its ascension. TIOBE people, exactly as I said in this article, claim this is due to IoT. If your toothbrush needs some software, it'll probably be written in Assembly. Speed and code size demand this.



Cohesion



Today it is time for us to talk about more generic things on programming.

We say that a certain method has a good cohesion when it does one, and only one, thing.

I know... I know... this is too abstract! Let's see an example to make things clearer.

Consider the following piece of code

This will print all integers between 1 and 1000 whose sum of digits is 10. An easy task. I only separated it in two methods because we need this in order to better understand how important cohesion is.

If you take a look at these two methods, you'll notice the first one (some_method) invokes the other (sum_is_ten?) to ask if the sum of the digits of a certain value is ten. It passes only the value and receives only the information required. This is the perfect behavior, the perfect coupling between two methods. And this is only possible because sum_is_ten? has an excellent cohesion.  It does only one task, deciding if the sum of the digits in the numeric parameter received is ten or not.

Now let's consider another problem, a bit more complex. Now we need sum_is_ten? returning false when the parameter received is not multiple of four, even if the sum if the sum of the digits is ten. We could write it this way:

Or this way:


In this first way sum_is_ten? has a bad cohesion, 'cause it must decide for two things. But what are the consequences of this fact?

First of all, sum_is_ten? is less reusable. Imagine we had another method, say some_other_method, who also need to know if the sum of the digits of a certain number is ten, but not with this restriction about the number being multiple of four. It can't use sum_is_ten?, of course. In this situation we should write another method to perform this task and we wouldn't be able to avoid certain duplication of code.

Besides, the lack of cohesion makes the name of the method inconsistent.The name sum_is_ten? does not express clearly the goal of the method, as it is the ideal situation.

Of course this example is completely artificial, but it helps us to understand why cohesion is so important.

But there is still a point to be made clear: How to achieve a good cohesion?

Breaking things, is the answer! Separating different tasks in different methods and composing its results. In order to understand this, let's see the ideal  solution to our second problem, the list of all integers between 1 and 1000 whose sum of digits is equal to ten and who are also multiple of four.


As you may see, the ideal solution has a new method to decide if the given number is multiple of 4. This answer is composed with the the answer given by sum_is_ten?. Tasks are separated now, and each method executes one, and only one, task.

See you next post!