Monday, February 29, 2016

I want to use Heroku, but my app uses MySQL



Heroku does NOT work with MySQL databases, as everybody knows. But some people, like myself, prefer to have a single database server in his local development environment. And in my case, and in the cases of many others, this database server is a MySQL server.

In fact, I prefer not having PostgreSQL installed in my development environment. Nothing against this database, but I've been working with MySQL for a long time and my development machine is not a state-of-art notebook, but an old Dell Vostro who has seen  better days in its life. Installing many database servers with my Fedora 22 would only damage its performance.

How may I, then, use Heroku for deployment?

First of all, create your app using

$ rails new your_app_name -d postgresql

This will generate a Gemfile and a config/database.yml ready to use PostgreSQL. 

Now edit your Gemfile and write the following:

group :development, :test do
  gem 'mysql'
  gem 'byebug'
end

group :production do
  gem 'pg', '~> 0.15'
  gem 'rails_12factor'
end

This will separate things. MySQL will be used for development and test, in your local machine, while PostgreSQL will be used for production at Heroku. This platform sets RAILS_ENV to production, then this will do the magic for a now. But this is not enough.

Now edit your config/database.yml.

Having created it as said above, you'll have a few lines saying:

default: &default
  adapter: postgresql
  encoding: unicode
  # For details on connection pooling, see rails configuration guide
  # http://guides.rubyonrails.org/configuring.html#database-pooling
  pool: 5

Don't touch this! Let it be exactly as it is.

Now, right below this you may have your settings for the development environment. Replace them with:

development:
  adapter: mysql
  username: <your_database_username>
  password: '<your_database_password>'
  host: localhost
  database: <your_database_name>

And do the same for your test environment:

test:
  adapter: mysql
  username: <your_database_username>
  password: '<your_database_password>'
  host: localhost
  database: <your_database_name>

Now you run

$ bundle install
$ git add .
$ git commit -m "Heroku"
$ git push heroku master

and you are ready!

Now Heroku will accept your deploy and your app will work fine. Maybe you'll just need to run some rake tasks to generate your database and migrate it. I'll teach you to do this in the next article, just in case you don't know.

By the way... You surely noticed the gem rails_12factor installed in production environment. Heroku requires it and it is better to add it to your production environment whenever you are going to use this platform.


Friday, February 26, 2016

Computer programming is not in the right track



Every time I see a computer programmer asking for advice at StackOverflow because he/she is writing a login routine or something of this kind, I feel sad.

Yes, sad because I've been programming computers since 1985, 31 years now, and I'm still seeing people doing the same old things, as if all this stuff hadn't been done thousands, millions of times by other programmers.

It is true that now things are a bit better than when I started. Things like Ruby gems allow people to reuse code in efficient ways.

But then, why people still do the same old stuff?

According to some, it is necessary, because beginners need to learn all this stuff. But I don't fully agree with this theory. Only a partial agreement.

They need to learn, of course. And doing things is the best way to learn. But when it comes to practical matters, they don't need to learn doing all this stuff. They need to learn, yes, but only the principles of these elementary and repetitive tasks. Not the repetitive coding to make the same tasks all over again. More than that, they need to learn how to use what others did before. How to start from the point others stopped.

We need to create a perfect development environment, where this kind of stuff is available, ready and tested and well documented, for those who need. We must provide conditions for programmers to focus on things really valuable.

Ruby gems are a good beginning, but we still need to have the same provided to other languages as well. Programmers must be free from repetitive tasks if we really want programming to reach the peaks we believe it may.

Programmers should not be forced to repeat things all over the time, forced to reinvent the wheel. Our minds would be much better used if we could focus on the complexity of the systems we deal with nowadays.

Where is all that stuff about Artificial Intelligence we were learning in the middle of the 80's? Why haven't it advanced as expected? And we started talking about this again, about Machine Learning, when they coined the expression "Big Data". But where are the real advances? I tell you where...

These advances, these technologies, are restricted to Google-sized companies. (Is there really something Google-sized but for Google itself? I doubt it!) While the common programmer is still imprisoned by login procedures, queries, loops and other small things.

We need to be free of all this!

Suggestions? 

Wednesday, February 24, 2016

Ganesha PHP Framework



Up to five years ago, when I started with Ruby, I was a PHP developer. In fact, I like PHP a lot and the main reason for not using it anymore is the fact, correctly stated by Rasmus Lerdorf, PHP's father, that all PHP frameworks sucks!

Whoever worked with Zend framework, for instance, as I did a lot in the past, knows exactly what I'm talking about. Bureaucracy, lots of code and configuration for just a small result... It has everything that we, Rails developers, learned to reject, to despise.

After Rasmus' claim, I started talking to a bunch of friends about the criteria to create a new PHP framework. One who doesn't suck.

In the beginning it was just talk, mainly because we were all too busy at that time. But now we decided to start working in this project seriously.

Then I'm inviting Ruby developers interested in taking part of this project to write me at edvaldoajunior@gmail.com

This development requires bilingual developers. One must know Ruby well and also know, at least, the basics of PHP. Some experience with MVC frameworks would be good, but you may learn while doing it happen.

This is not a job offer! We are looking for volunteers to take part in an open-source project. If you enjoy taking part in things like this, join us.

Monday, February 22, 2016

India as a Coding Nation



We all have seen how the number of computer programmers in India has grown in the las few years. What people don't know is that this is not a coincidence, but the result of well defined strategies used by the Indian Government, by companies and by NGOs from India.

Last week I saw some news about a US 4 smartphone launched in India, named Freedom 251. I haven't believed at first, but then I read more about it and found out all this is all part of a project to make the acquisition of electronic gadgets easier for Indians, as part of a government effort, helped by private companies, to create an appropriate environment in that country for the development of programming skills among the population.

Yesterday I visited the site http://www.snoopcode.com/ (follow them at Twitter here) which is, independently, part of the same effort. This website teaches people how to write code in HTML, CSS, Javascript and jQuery, which is a pretty good start for a front-end development career. This website has a very interesting pilot project.


Computer programming is a interesting career. We wouldn't be here, writing or reading this blog, if it wasn't so. With a few device like a desktop or notebook computer, a smartphone and other small things one can really create a valuable piece of software. And while most of us are still working hard to make ends meet every month, some people are rich writing code!

An effort like this may represent a lot of money for a country and its people, as well as a growth of self-esteem for a large number of people. One may go from unemployment to a job position or even to an entrepreneur position.

I would really love that Brazilian government could engage in a similar effort. Unfortunately all we have in this country is a left-wing government dedicated to destroy private companies by raising taxes in order to give money to those who don't want to work. Here in Brazil government believes in "social programs", not in computer programs. I believe, as Ronald Reagan would say, that the best social program is a job.



So, I urge those who can help this kind of initiatives to do it. Our world is living a serious crisis. We may just wait for things to go better or we may just wait for governments to fix things. But we may also WORD HARD and help people to find their ways to a good job and a good living for themselves and for their families. This is much better than donating money.




Saturday, February 20, 2016

Don't try to code in Ruby using other language style



Ruby newbies tend to write ruby code just like they did in other programming languages, just using Ruby syntax. And sometimes not even this!

A good example is in this post here at StackOverflow.

My suggestion is: Dive into ruby documentation and learn the resources Ruby offers you. 

My solution could be even smaller, I think. But the goal there was to make things clear to someone, not confusing him even more with strange constructs.

By the way... strange constructs are pretty good. But if you have a team working with you, please make sure all you team will understand these constructs. Good programming is also team programming and it doesn't help a lot if you write code that only you can understand. But this does not mean you have to avoid strange constructs. Just teach people what they mean.

Friday, February 19, 2016

Good reasons to replace db/schema.rb with db/structure.sql



Everybody knows that after running a

$ rake db:migrate

the file db/schema.rb is updated to the present state of de application database. You may even rebuild this database by running 

$ rake db:schema:load

But db/schema.rb has two problems.

1) It is "Rails dependent"

If you want to reproduce this very same database out of a Rails environment, you just have to to the heavy work yourself, recreating the tables. Without Rails framework you just don't have a way to generate all tables just based in db/schema.rb.

2) db/schema.rb does NOT support functions

So, if you need to use a function like "now()", db/schema.rb won't help. You may see a bit more about this here.

The solution for the two problems is changing the way Rails stores the database description. You won't use db/schema.rb anymore, but just a good old SQL dump named db/structure.sql.

You may do this easily by adding 

config.active_record.schema_format = :sql

to your config/application.rb file.

From now on, the output of your migrations will be a file named db/structure.sql, with a traditional SQL dump of the database.

The only problem with this is the fact that Heroku doesn't like migrations in this format. Heroku is always demanding, as we already know. But there is a solution here too. Instead of just the like above, add to your config/application.rb the following code:

if Rails.env == "production"
  config.active_record.schema_format = :ruby
else
  config.active_record.schema_format = :sql
end


Monday, February 15, 2016

Two things to check when your Travis build fails



You created a gem, tested it all in your local development environment, all tests passed and you a happy developer. But...

Then you push your gem to GitHub and your repository there is connected with Travis (https://travis-ci.org). More than that, you have a badge in your README.md page. And when you refresh your GitHub project page, you see your Travis build failed!

What a frustration!

Well, this already happened to me and it is not good at all. But let me tell you the good news: there are two small things to check before desperation when your Travis build fails.

1) Have you required sudo powers?

This is a fundamental question, because you are just a visitor in Travis platform and you have no special powers there. At least not all powers needed to run some of the tests in some cases.

So, if your gem requires, for instance, that you have write access to the file system, better ask for sudo powers. It is easy. Just edit the .travis.yml file in your gem's home directory and append

sudo: require

to it.

2) Check your Rspec tests for absolute references to files

This is a usual mistake. We are in our local development environments and we know exactly where we may read/write or not. Then we give a full path to the file to be read/written and it all works fine. But then we moved to the Travis file system and the paths we used don't even exist and Travis build fails.

This already happened to me and it is not funny at all. So, I hope this helps you to avoid the same.


Saturday, February 13, 2016

Meddling in other people's business



This post is the kind of thing I seldom do. I'll be meddling in other people's business, something I was thought to be unfair since my early childhood.

If so, then why am I publishing this post?

Because I strongly believe it is time to say something about things happening all around me. I've been silent about these facts for a while, but it is time now to speak my mind.

I know I'll hurt the feeling of some people, but this is what life does all the time. It is impossible to have opinions without hurting other people's opinions. And learning how to deal with different opinions if an important step to anyone's maturity to be reached.

This post is about the (not so) recent problems with the development team of OPAL (https://github.com/opal/opal), a Ruby to Javascript compiler most of us have already used in our own projects.

It all happened in June 2015 and since then I've been asked by some friend developers about my position in all the issue, but always refused to answer directly to them, until now. Now it's time to make my position on this subject clear to everyone. And my position is, I believe,

AN APPEAL TO REASON

First of all let me explain, for those unaware of the subject, what happened.

In June 18th, 2015, a developer know as CoralineAda raised an issue (https://github.com/opal/opal/issues/941)  at GitHub's OPAL page, requiring that another developer named Elia Schito to be removed from that project because, in her ow words: "Elia Schito is publicly calling trans people out for 'not accepting reality' on Twitter. His Twitter profile mentions that he is a core contributor to opal. Is this what the other maintainers want to be reflected in the project? Will any transgender developers feel comfortable contributing?"

This issue generated a long discussion (which I won't reproduce here because anyone can read there in the gitHub issue directly) when another OPAL core member know as meh answered her and said he was against the removal of Elia Schito and closed the issue.

In fact, things degenerated in a flame war. One side had all those who, like CoralineAda, believe that one is not supposed to express opinions which may hurt other people's feelings. The other side had those support unlimited freedom of expression and those who believe Elia Schito's personal opinions were his problems, not OPAL's problems.

As in all discussions of this kind, harsh things were said by both sides. After a while one just couldn't tell right from wrong anymore, because reason wasn't the guideline anymore, but personal feelings. Whenever this happens people tend to forget the real goal of a discussion: finding a compromisse between different positions.

Our society is enduring kind of a revolution when it comes to many things, including sexuality. Back in the 70's homosexuals were "leaving the closet" and fighting for their rights. At that time this caused a strong reaction in some sectors of the society. Some people refused to accept the fact that sexuality wasn't a matter of character or competence. Job positions were denied to homosexuals. Public workers in some more sensitive areas of government who were found to be homosexuals were asked to resign their positions, 'cause people would think (right in the middle of the Cold War) they would be entitled to blackmail to reveal secrets or something.

Now, forty years are passed and things changed a lot. Homosexuals are all around and the mere thought of blackmailing someone for being gay is quite ridiculous. Come on... Elton John is now a Knight of the British Empire! And he is not just using pink spectacles anymore. He married a guy formally!

Point someone in the streets and accuse him or her of being homosexual nowadays. First of all, you'll give this person the fifteen minutes of fame Andy Warhol talked about, remember? Second, if someone is going to be hurt in this situation, it's probably you, not the person accused.

I even suspect that some people claim to be homosexuals nowadays just to get some fame!

Things change. Sometimes they don't change as fast as people would like to, but they change. Maybe you don't believe this when you are twenty, because you haven't lived enough to see the changes. But when you are almost fifty like me, and you can remember things from forty years ago as I can, then you'll see how things change.

Now many people are questioning their "sexual identity". They say they were born in the wrong sex. A male says he is a she, or a she says she is a he. 

Well, as far as I am concerned, one may say he or she is whatever! I don't really care. If you want to say you are a sofa or a refrigerator, it is your business, not mine. As far as you don't attack me anyway, I won't waste my  precious time attacking you. I have a family to take care, a job, lots of personal projects and no time enough to take care of all this stuff. Certainly wouldn't lose my precious time attacking you or anyone else for saying you are a woman, or a man, or a cat (like this woman here) or a martian.

But there are two important points to be considered here:

1) I'm not a role model to everybody. I think like this, but you may think differently from me, of course. Many people will express different views. Some will feel offended by the idea that a man may consider himself a woman, or a woman consider herself a man. Anyone is entitled to have a personal opinion about this.

2) I have my personal opinion. And it is not very different from the one expressed by Elia Schito, I must say. I believe people are having trouble, these days, in dealing with reality. Because the fact of being born a man and saying you are a woman does NOT makes you a woman. It does not change your genoma; it won't give you an utherus; it won't make you capable of having a baby like a woman. A man may dress like a woman, speak like a woman and anything else, but he won't be a real woman, in fact.

So, it is said. This will hurt the feelings of some people, but that's what I believe. But...

I also believe I must be gentle to others. So, if I have no reason, if I'm not directly asked (and depending on the context, even if I am), I should not throw my beliefs and thoughts all around without considering the fact I'm going to hurt people needlessly.

What good would I do by offending a male friend or colleague who says he is a woman by saying he is not a real woman? This is not my business! Unless, of course, he wants to have sex with me. Then it turns out to be my business and I'll have to refuse and clearly say I only have sex with real woman. Because now it concerns to me, not just to him/her. Except for this situation, I see no advantage in fighting over something which is not my business.

My point here is that we are not supposed to interfere in other people's thoughts and opinions. If you want to believe you are a woman, a man, a cat or a dog, this is your business, not mine, and I am not supposed to interfere in your belief, unless it affects me directly. The same way, no one may be forced to agree with your beliefs and if a person disagrees in his mind, it is not your business too.

During this long flame war in the above mentioned GitHub issue someone asked meh if he would work with a child molester if this child molester created good code. This question was raised because meh's position was that personal ideas, beliefs or tastes were out of the scope of the project and no one should be forced out of the project for this.

I miss the times when people studied rhetoric at school. This helped a lot when discussing things, because analogies were much better crafted then.

The comparison is completely inadequate. Child molesting is a crime! I wouldn't even talk to a child molester. If I find out any of my  relatives, friends or colleagues is a child molester, I'll call the police immediately, without hesitation. But having an opinion may hardly be compared to hurting children!

Come on...  Sometimes I feel like if I were living in George Orwell's "1984", with the Thought Police being represented by these politically correct squads that are all over the place trying to control not only what we do, but also what we think.

Going back to the poor analogy of the child molester... How may we know how many of our relatives, friends or colleagues have sexual fantasies of molesting children? We just can't know! What we can judge, then, are the actions. If I see someone molesting a child I may call the police. If I see photos in a colleague's computer of children being molested, I may call the police (here in Brazil having this kind of material is a criminal offense, even if the photos don't picture yourself). But how may I control someone else's thoughts?

Logic says, then, that no one may be punished by his thoughts, but just for his actions. Molesting children is a crime. Thinking about molesting children is not, even if this makes one a disgusting person to me.

What is happening today, going back to the transgender issue is that people are asking for respect for their positions and beliefs, but at the same time refusing to respect the positions and beliefs of others. In other words, they are asking everybody  to "accept differences", but just when it comes to their differences. They just can't accept different opinions. They ask for tolerance but they refuse to be tolerant.

Late comedian George Carlin expressed perfectly this context in one of his sketches, by saying: "I have a right to my opinion and my opinion is that you have no right to your opinion." 

Finally, because this is already too long, let me say a few words about two things.

Context is the first thing. There are private things and public things, and they are not the same in most cases. Personal interests are different to public ones. CoralineAda has the right to avoid personal relations with people who think like Elia Schito. This is her personal right. But she has no right to force all other people to to the same, as it seems she believes she has. And the context of a software project is hardly the place to discuss other people's opinions on sexuality. 

And then consider the dangerous extensions of CoralineAda's request. She says "What will people think of opal project if you have a developer against trans people" and if we extend this thinking she is implying in her request Elia Schito must be expelled of all software projects, 'cause people will think bad of all them with such developer. But this is his profession. He is a software developer. Then she is asking that he is kept unemployed forever, living in poverty.

What next? Go to Elia Schito's neighbors and say "What will people think of this neighborhood with such a person living here?" And there we have Elia Schito homeless, forced out of his house for expressing an opinion. 

What next? His family? His friends?

Is she really trying to sentence this guy to a faith worse than death just because he has a different opinion?

Is an opinion quite a terrible crime? Because we don't sentence people to perpetual unemployment and to being homeless, with no family and friends, even for a cruel murder...

Let's go back to reason and create good code. In forty years things will have changed and this trans people issue won't even be remembered, probably.

Thursday, February 11, 2016

Erratum (1)

Days ago I published a post named "Measure your code to make it better" and there I mentioned Code Climate, a wonderful service you my use to apply some metrics to your software to check for quality of code and reduce your tech debt.

It happens that I made a mistake in this post. I said that it was a commercial service and you needed to pay for it. This is only partially true, as Kären Engelbrecht, from Code Climate, explained me today by e-mail.

Code Climate is FREE for Open Source projects. So, there’s no charge to use us for analyzing your Ruby gems. You only have to pay if you intend to use it with private repositories.


Wednesday, February 10, 2016

Some rules to be a great software developer



This is one of these days I'm in the mood to talk more than just about Ruby, Rails or any other specific language or framework. Maybe it is because I spent part of the night awake. Maybe it is because my kidneys are hurting. I don't know, but the fact is that I am a bit philosophical this morning.

What does it take to make one a great software developer?

I don't really know the complete answer, of course. If I knew I would be a great software developer, and I am far from this. But I've been programming computers in the last 31 years and I believe I learned something about this, more by observing others than by watching myself.

Then, here are some of my rules to detect a great software developer. If you fit on them, or consciously try to follow them, you'll certainly turn out to be a great developer. But this is not an easy path, I tell you. I know because I've been trying to follow my own rules in the last 31 years.

1) You have to love solving problems 

There is an old joke about Augustin-Louis Cauchy, a French mathematician and also a Roman Catholic like me. He attended the mass and his priest preached about how Heaven would be. According to the priest, in Heaven all your deepest needs would be satisfied. When the mass was over, Cauchy went to talk to the priest privately and asked him how the priest thought Heaven would be for him, Cauchy. The priest said: "Well, since you are a man who solve mathematical problems and enjoy doing this, I believe that in Heaven all math problems would be pretty clear and easy for you to solve". Then Cauchy said to the priest: "Forgive me, father, but I'll leave the church now and commit a deadly sin". "But why?", asked the priest, surprised. And he said: "If Heaven is like this, I prefer going to Hell. There they will give me lots of pretty difficult math problems to solve!".

If you intend to be a great software developer, then you must be at least a bit like Cauchy. Because this is software development. People are going to bring you problems all the time and you... or you'll love solving them, or you'll go crazy after a few years, or you'll move to another profession. A colleague of mine used to say she detested all the problems people would give her on a daily basis. She gave up programming and she is now a great lawyer. On the other hand, I had a friend here in Brazil who used to come to my working place every morning and we gamble, usually with dice. The winner could pick the hardest task of the day.

2) You have to love studying and learning

I started programming computers when I was in graduation still. At that time I was sixteen and now I am forty eight years old. During all this time not a single day passed without hearing about something new in this field.

Being a software developer is not like being an accountant, a field where the last great technical advance, the "Double Entry Book System" was first described by Luca Pacioli in 1494! (know more)

In software development the last technical advance was created now... sorry, now... no... now!

Things are  happening all the time and if you don't like to study and learn new things, soon you'll be completely out of date and, worse of all, out of the market. I know exactly how it is, because I've been into software development since 1985 and I'm the guy still standing, when most of my colleagues left this field for others just because they refused to continue studying long after graduation, post-graduation and so on.

Just to keep going, to continue making a living of programming computers, I have to study at least one hour a day. Most of the days it is a bit more. No, a lot more. And I'm not among the top ten. Not even among the hundred ten. Hell... not even among the first thousand! If you want to be in these lists, you'll have to do much more, believe me. 

3) You may NOT believe it is all about programming languages

Most people believe that learning deeply a programming language is the path to be a great software developer. It is not!

Software development is all about logic applied to solving problems. Programming languages are only the tools you use to express your logic. So, don't delude yourself. You may be a complete encyclopedia about a certain programming language and still be a mediocre programmer. On the other hand, if you are a great programmer, you'll write good solutions even using no specific language at all. Great programmers will draft great code on a napkin, using pseudo-code, or natural language, the same way a great composer would write a symphony with the same material.

4) You must not limit yourself to one programming language

You must definitely learn more than one programming language. It sounds strange, because I just said programming languages were not that important.

No, I haven't said that!

I said that logic and solution are not dependent off a certain programming language. But I also said that programming languages are tools to express your logic and your solutions. Then, if you know many programming languages you be able to express your ideas in a greater number of ways. And considering that certain programming languages are better than others to certain kinds of problems, the more programming languages you know, the more you'll be able to solve problems!

One of ways to recognize a mediocre programmer is when you see a fixation, an obsession, by a certain programming language. Those who say (*) [replace the * with Java, Ruby, Perl, PHP, Pascal... anything you like] is the best programming language ever and that one does not need to learn anything but it are NOT great programmers.

First of all, when someone says that a certain language is the best one, I always ask "For what?"... Because there is no such thing as a better language if you don't consider the kind of problem you are working on. Even if someone loves good old COBOL, this person will have to accept the idea that COBOL wasn't written to write device drivers. On the other hand, if you are performing the old art of "number crunching", COBOL works very fine, indeed.

But in order to choose the best language to write a solution to a certain problem one is supposed to know many languages. As people say, if all you have is a hammer, all things will look like nails. So, don't have a single tool if you want to be a great software developer.

5) Specialize in something

Here I'm using the advice a former teacher gave me about 37 years ago: "Learn a bit of everything, but choose something for you to really master".

Old José de Arimateia, a former math teacher of mine when I was eleven (yes, this old man here was eleven someday, long time ago...), didn't even knew at that time how important this piece of advice was going to be to me. In fact, I used it most of my  life and, in spite of the fact I don't even know if he is still alive after all these years, I frequently remember him saying so and thank him mentally for the advice.

You'll hardly find a generalist in the list of great software developers. And, in fact, you may replace "software developer" by mathematician, physician, lawyer... anything you like, in the last sentence. You'll hardly find a generalist in the list of the greats in ANY field, exception made to people like Leonardo da Vinci and Pythagoras. But may you tell another names like them in all human history? No? Then it is not safe to place all your bets in being a generalist.

As time passes, science and technology grow in larger and larger proportions. Nowadays it is almost impossible to anyone to be great in two different fields of study, like being a great musician and mathematician at the same time. Same happens in software development, a field in constant growth.

Then, if you want to be among the top ten of all times in software development (and all of us dreamed about this once or twice, specially when we were young...), find a niche, find something to be the very best on it. And work hard! Being the best is not just a matter of will, even if the "self help" authors keep repeating this all the time. Being the best is a matter of great efforts and sacrifice. Read the bios of the greats in any field and you'll see how some of them sacrificed even their families and personal lives to reach that position.

6) Remain single

I'm Brazilian and Portuguese is my native language. So, English is a language I started studying when I was ten years old. But I'm not telling this just to beg for your forgiveness to my mistakes in writing. I'm telling this to explain my fascination with an English word: bachelor.

This word is used to talk about an academical degree, as in "He is a Bachelor in Fine Arts" or "She is a Bachelor in Computer Science". But bachelor also means single, not married. And this is not a mere coincidence.

It is very difficult to study hard when you have a family, a wife or husband and kids. Very difficult indeed. I think about this everyday, when I stay awake after hours, when my wife and my son are both sleeping, drinking cup after cup of coffee, to study a new programming language, a new technology or finishing a freelancer job to make some extra money.

It happens that software development is made of study, as I said above (2). Then, if your goal is really to be  the "king of the hill, top of the heap", as old Frank Sinatra would say, you'll have to dedicate long hours of your time to study. And believe me, it is difficult to do so with a family.

So, the same way my advice to the married ones is "keep married" (I'm a Roman Catholic and against divorce), my advice to the single ones is "remain single".

7) There is always a better solution

Accept this fact. You may always find a better solution than the one you already found. So, do not delude yourself. This clean, elegant and correct solution you just found to a certain problem is not the best one. If you try harder, you may do something even better. And other people will surely find something better.

So, don't be so proud of your code. Remember the "Rule of the Six Months". According to this rule, if you look at your own code six months after having written it, you'll not even believe you were capable of writing such a crap!



This is not an exhaustive set or rules, of course. But they will surely help you when it comes to being a great software developer. Any other tule you can remember? Please, post it as a comment here.




Tuesday, February 9, 2016

Measure your code to make it better



Let's talk about code quality, a subject that should be of interest of all software developers.

Low quality code is a great problem. It may render a system completely useless, if you don't do something about it. Measuring the quality of your code is not an option, it is an obligation. There is no excuse to low quality code nowadays, when we have many tools to help us to detect this.

First of all, we Ruby developers (should) always start by creating tests, not by writing code. This helps a lot when it comes to be sure our code does exactly what is expected of it. If this is a good practice in Ruby, it should also be considered as a good practice for all other languages.

But we most not delude ourselves. When our code passes our tests, it means the code does exactly what is expected of if, but it means nothing more than that. It does NOT mean, for instance, that our code does what is expected of it in the best possible way. Or that it does what is expected of it respecting all criteria for good coding. Or respecting Ruby principles, like DRY.

If we intend to have the best possible code, we must do more than testing. We must measure our code according to certain criteria. This article will discuss ways to do so.

Flog

If you run

$ gem install flog

then you'll have a great tool to measure the complexity of your Ruby code. This gem flog, when run against a piece of Ruby code, uses a technique quite similar to ABC analysis (we'll talk about this some other day, but you may find info about it here) to give you a flog score of your code. It is kind a convention that the flog score of a certain piece of code must be smaller than 20. Anything above 20 indicates your code needs refactoring. Also, anything above 60 will be considered quite dangerous.

To run flog against your User model, just do

$ flog app/models/user.rb

Flay

Avoiding code duplication may be easy if you use the gem flay. You may install it with the command

$ gem install flay

Flay will look for large identical syntax trees to determine where you have code duplication and will tell you if it finds it.

To run fly against your code, just type

$ fly /path/to/your/app

and see the results.

Badges

Consider adding some badges to you project.


These badges are offered by many public and private service, and they are very useful because not all people who will have the time (or patient, by the way) to test your code over an over again. These people need to see immediately if that gem is safe, for instance.

Adding badges indicating your code is building correctly (https://travis-ci.org), the amount of code covered by your tests (https:coveralls.io) and the CodeClimate GPA coeficient (ranging from zero to four) you are helping people to know how safe and sound your Ruby gem is.

  • Build status badge


Visit https://travis-ci.org and signup with GitHub, then add your GitHub repositories. After doing so, all pushes to a repository added there will trigger a complete build of your app. You may get a badge indicating your app is building or not.

I'be seen some developers saying things like "Why should I use a badge saying my app is not building?" or "I'm going to remove the build badge because my app is not running right now. I'll put it back whe the build is fine". You use such a badge even when you break the build because you live in real world. People will know your build is broken even if you don't tell them. And they will know because they will test it and it will fail. And they will not trust your code anymore, because it was broken without a warning.

I'll write an article soon to give some advice about good practices to make Travis build easier. This platform requires some attention to details in order to build correctly your application. Your RSpec tests, particularly, must be written carefully, considering you are now the platform owner and your powers are limited there, specially when it comes to directly accessing the file system.

  • Code coverage badge


This is another good info you may add to your README.md file at GitHub. this badge indicates the rate of your code covered by your tests. the ideal situation would be 100%, but we all know this seldom happens. But it is important to have the highest code coverage rate possible.

To get a badge like this, visit https://coveralls.io, sign up with github and follow the procedures there to start gathering this statistics. 

Then againg, if your code coverage is low, don't try to hide this fact by avoiding the badge information. Right the opposite. Put the badge there and improve your code coverage. The badge is for other people to see, of course, but it is also a warning to you about a bad practice of writing code without writing the corresponding tests beforehand.

I'm telling this to you, but my own badge is not telling me the code coverage, as you may see in the image above. I just don't know what is happening and had no time to investigate this. By the way, if you have a clue to me, post it as a comment in this article or send me by e-mail (edvaldoajunior@gmail.com). I'll thank you a lot.

  • Code Climate badges


I'm using two Code Climate badges. The first one tells me the GPA coefficient of my code, ranging from 0.0 to 4.0, higher values being better than lower values. This metric evaluates complexity, bugs and even your programming style according to Ruby standards.

The second one tells me the number of issues in my code.

To get these badges, visit https://codeclimate.com.

IMPORTANT: This is a commercial service FOR PRIVATE REPOSITORIES. You may sign up for a 15-days free trial, but after this period you'll have to pay to use the service if you intend to use it to measure private repositories. But it is completely FREE for Open Source!

If you google 'metrics for quality of software' you'll probably come out with other tools. What really matters is that you use some kind of metrics to evaluate your code and act accordingly, fixing the problems detected. Your customers will thank you a lot.


Friday, February 5, 2016

Different bundles for different applications



Let's assume we created a Rails application named our_app using

$ rails new our_app

This application will use, by default, the global bundle, a common repository where all your gems will be installed when you use bundle install inside each of them.

If we have many applications using the global bundle, their gems will be all together. This may be good if we have strictly the same set of gems in all our applications, but this is seldom what happens. Unless, of course, if we only have clone applications. But then, what kind of programmers are we?

Using the global bundle may be a bit confusing, specially if you have applications using different Ruby versions.

The ideal situation is having one set of gems for each of our applications, and this may be easily achieved.

On the console, let's navigate to our application directory and type the following commands:

$ touch .ruby-gemset
$ touch .ruby-version

Then, using our favorite editor (Mine is emacs! Death to vi, vim and all other flavors of vi existing and still to come!) we shall open .ruby-gemset and type just a name in the first line. This name will be used, as you probably have already noticed by now, to name the bundle where this application's gems will live from now on. By default we use the name of the application, but we may use any name in fact.

After saving this first file and closing it, we shall edit the second one and write just a line again, saying something like

ruby-2.2.3

Save it and close it. Now we shall use

$ cd ..

to navigate out of our application directory. But we will be out for just a moment. As soon we leave, we'll enter the application directory again, and them we'll receive a message saying something like

ruby-2.2.3 - #gemset created /home/edvaldo/.rvm/gems/ruby-2.2.3@our_app
ruby-2.2.3 - #generating our_app wrappers - please wait

This means we are in the right path. But we haven't finished yet. We still need to install our gems with bundle install.

But when we run this command we have a surprise:

zsh: bundle: Command not found...
Install package "rubygem-bundler" to provide command "bundle"? [N/y] n

But if you think a while, this is not a surprise at all. Our gem bundle is empty! Then the gem bundler is not there yet.

Before using the command bundle we must run 

$ bin/setup

and this will install the gem bundler for us and also run bundle install for us. Now we just need to wait until the installation is over and voilà! We have a separate bundle for our_app!

Repeat this process for all your applications and you'll have all them separated.

Wednesday, February 3, 2016

Mutatis mutandis (2): Disabling sprockets is dangerous



Among many options you have when you create a Rails application using the command line, there is a flag --skip-sprockets. This flag allows you to disable rails Assets Pipeline.

Since Rails 3 the assets pipeline is systemic and sprockets-rails is inserted by default in the app Gemfile.

According to Rails documentation: "The asset pipeline provides a framework to concatenate and minify or compress JavaScript and CSS assets. It also adds the ability to write these assets in other languages and pre-processors such as CoffeeScript, Sass and ERB."

In other words, the assets pipeline is the Rails subsystem which allows you to manipulate easily your application assets, like images, javascript files and other things.

Why would one disable this? Who knows?!

But our best advice is: DON'T DO IT, UNLESS YOU REALLY KNOW WHAT YOU ARE DOING!

There are many reasons for this advice. Rails documentation gives some of them when it says that disabling sprockets will prevent sass-rails and uglifier gems to be included in your app Gemfile. Without these gems you won't have assets compression and this will penalize your app in terms of bandwidth, since assets will be loaded uncompressed. But this is not the worst part.

Just yesterday coldnebo, a Rails developer, opened this issue at GitHub Rails page: rails --skip-sprockets option creates many undocumented issues for the unwary #23431

Clicking on this link you'll see good reason. But if you decide not to click, here is a summary:

  • jquery-rails won't work properly and this will break, among other things, your layout if you use Bootstrap, which depends on jQuery.
  • gems active-scaffold and cells won't work properly either
  • constructs like form_for and ajax won't work, because these features depend on jquery-ujs, which is inside jquery-rails gem, which, as we said above, will be broken by --skip-sprockets
But what frightens us most is the fact that these issues are NOT documented anywhere!

So, be careful when you try to change this Rails default. The rule here is: if you don't really know what the assets pipeline does, and how it does, then you are not entitle to disable it.