Tuesday, June 28, 2016

Why Assembly programming is growing so fast?

Assembly surprised me! In this list I posted it appears as one of the fastest growing programming languages.

What is the reason for this unexpected growth? If i was told by someone ten years ago that Assembly would be among the fastest growing programming languages in ten years, my reaction would be like "Are you crazy?"

But then I started thinking about it and suddenly I understood what one of the possible reasons was: IoT

With all this talk about Internet of Things, there must exist a large demand for device drivers for almost anything in the world, from refrigerators to cigarette lighteners! And Assembly is very good when it comes to this.

Here is my advice for the younger generations: Learn Assembly! It may be fun and very profitable!

Monday, June 27, 2016

Are iOS and SQL programming languages?

Yesterday I published a post here with two lists of the most demanding programming languages. I want to thank you all for reading this post. It had more than 1400 page views and helped a lot to improve my counter! A blog needs visitors!

But this is not the point here. I'd like to talk about the first list, this one here:

One of my readers named Peter Choe asked, very correctly, why SQL and iOS were listed among programming languages.

Well... as for SQL, this last "L" stands for "language". So, SQL is a language in a certain sense. It is seldom used as an "independent language", but it is a language, nonetheless. One could argue that there is no SQL "per se", but only flavors of a SQL concept, like MySQL, PGSQL, PL/SQL and so on. But this won't affect the general fact that SQL is a language.

When it comes to iOS... this is unforgivable, but understandable. The data used to create the image was extracted from indeed.com and there one will find job openings saying "Java Developer", "Ruby Developer", "Perl Developer"... and "iOS Developer". I'm sure nobody counted these job openings manually. A crawler did it, for sure. And if you are a crawler programmed to search "XXXXXXX Developer", you won't have ways to decide that Ruby is a programming language and iOS an operational system.

Sunday, June 26, 2016

Top programming languages 2016

It always sounds strange to my ears when I see this kind of list in June! We have half of 2016 to happen and people are already declaring things for the whole year, as if it had already finished.

But here we have another list of the top programming languages in 2016:

It includes an image, with data extracted from indeed.com:

Good news is that Ruby and Rails are there. Bad news is that they are in the last position! But don't despair, because we have this other list, extracted from http://tiobe.com. This one is updated till this month and if you want to go there to see for yourself, this is the link.

As you may see, Ruby jumped from the position 16 to the position 10! This is really good news.

On the other hand, languages like C#, Objective-C, Delphi/Object Pascal and COBOL are going down every new month. A good message for those who intend to spend time and money with them: Don't do it! Pick another language!

Thursday, June 23, 2016

USB Wine - Funny video

Balance is as important in personal and professional life as knowledge and technique.

From time to time you have to stop a while, walk, have some chat with your family (those people living in your house, that you only notice because the noise they make disturbs your programming activities...) and laugh! Laughing is very important.

This is an old video, but I always laugh a lot when I watch it!

Hope you enjoy it! And please, post in the comments other funny videos. Help get some good laughs too!

See you next post.

Implicit (and bad) type conversion

Sometimes it is interesting to know what happens behind the scenes when you are programming. The way the language you are using behaves under certain circumstances.

Someone called Keith L. post the following code in a StackOverflow question (If you visit this link, don't forget to upvote my answer there. Help me build a good reputation there.) yesterday night, asking where was the type conversion, because he could see none. The code supposedly gets a string with many words and returns the longest word in the string.

Just because you can't see something, it does not mean it is not there. Sometimes things are happening behind the scenes and this is one more reason to learn well about the behavior of your language and/or framework.

The problem here lies in the fact Keith L. is assuming (wrongly) that the index of the array is passed to the block, not its elements. Then, when this method receives a string like 'We are developing a method to find the longest word in a string', in the first pass of the each block the value of the inner i variable  is 'We', not zero as he was assuming.

So, when he writes the test if sen1[i].length > sen1[grt].length he is, in fact, doing if sen1['We'].length > sen1[grt].length.

Arrays in Ruby are always indexed by integers. When he tries to get the index of an array using a string, Ruby says this is impossible because this would mean an implicit conversion of a string type to integer type. So, you cant see the type conversion, but it is there!

What would be, then, the correct way to perform this task?

Changing Keith's code just a bit we could have it running.

As you may see, we just changed a few things:

  • The name of the method was changed from LongestWord to longest_word. This is not causing the error, of course, but it is kind of violating Ruby's naming conventions. The first letter in uppercase is reserved to constants and class names;
  • The regular expression used to split the string into word is not necessary. Split does it correctly with just a space (" ") passed as parameter. And a good rule in programming is: Take away unnecessary things; and,
  • The most important of all, the cause of the error, we changed from each to each_index. This will do exactly what Keith wanted in the first time, passing the index, not the element of the array, to the block. Changing this the code runs fine.
Runs fine, of course, but it's not good yet. Keith would still be spending ten lines of code to do something that can be done with three lines.

This is the real Ruby style! And if you want a good exercise to improve your Ruby skills, try to write things in just one line as much as you can. Remember that all things in Ruby are objects, even the return values of the methods. Then you may concatenate operations like in the code above. You know the result of str.split(" ") will be an array, so you may use the max_by method directly on it. You don't need to store this result in a variable and then to use max_by on this variable.

Learn the Ruby way and your code will be shorter and better.

See you next post!

Monday, June 20, 2016

HTML code inside a link in Rails

This is quite simple, indeed, but I see many people asking about this topic in StackOverflow and then this post may be of some help.

Let's see how we may create a link wrapping some HTML code, like this:

We tend to forget that the <%= link_to %> may start a block if you append a 'do' at the end of it. then we may do

It is even possible to mix image and other HTML elements in your link, doing something like this:

As you may see, Rails offers many possibilities if you need complex links. But remember that HTML specification won't allow some elements inside a <a></a>, although most browsers will render almost anything you imagine. And some things you can't imagine too!

To see a good example of this feature, visit this StackOverflow question and see my answer there.

See you next post!

Saturday, June 18, 2016

Building native extensions for Ruby gems

I decided to write about this because I visit StackOverflow everyday and this is one of the most common questions about RoR there.

When you run bundle install in your application directory, you will see something like this:

You may notice that we have two kinds of installation messages. The first, and more common, says only

Installing <gem_name> <gem_version>

while the other says

Installing <gem_name> <gem_version> with native extensions

This is the installation where people use to have problems sometimes. But don't despair!

It happens that some of these "native extensions" are written in C and you need to build them in your machine before using that gem. And most of the times this is happening just because you haven't installed all development packages needed to build C programs.

Once you have all the tools needed to build programs in your computer, everything will be alright. Well... most of the times!

Let's consider two different situations: 1) You are a smart developer and uses Linux or other Unix-like Operational System in your computer; 2) You use any flavor of Windows in your computer because you haven't learned anything better.

1) You are a smart developer and uses Linux or other Unix-like Operational System in your computer

If this is your case, the solution is very simple, indeed.

Just find out in your distribution the package group containing the development tools and install it.

In the Debian box I use mostly, I just have to do

$ sudo apt-get --install-recommends install build-essential

This command will install all build tools needed and after it you'll run your build install perfectly well, if nothing else is wrong with your installation.

If you use Ubuntu, it's just the same. Ubuntu is a Debian-like Linux and most of what applies to Debian will apply to it too.

If you use Slackware Linux and you have installed it FULL, you won't have problems building anything. Slackware contains all the packages needed. If you haven't installed it full, just re-run the installer and install all packages from "D" series. This "D" stands for development and this group contains everything you need.

If you use Fedora, just run

$ sudo dnf groups list

and you'll see a list of groups of packages. Install all those groups for development and you just can't fail. You may install a group doing

$ sudo dnf install group "group_name"

with group_name being the full name of the group desired. Cut and past from the list to be sure.

I use these three Linux distributions mostly, then I'm not sure about yours if it's not among these three. But don't be lazy and do a little research yourself and you'll soon find out how to install your development packages, whatever your distribution is.

2) You use any flavor of Windows in your computer because you haven't learned anything better

The best to do here is moving to Linux and going back to (1) above. If you don't want to perform this radical change at once, try at least install a Linux Virtual Machine in your computer with Oracle VirtualBox and develop using this VM.

The main reason to tell you this is the fact Windows is not made for RoR developers, as I explain in this article here.

But if you insist in using Windows, there we go...

Your best choice is visiting  http://installrails.com/ and do everything listed there.

The second best is installing DevKit after having used RubyInstaller.

In both cases you'll have problems. Versioning problems mostly. It happens that the libraries these two solutions offer are seldom updated to the latest versions of Ruby and Rails. Maybe you'll have to make some changes to your code in order to run it, putting aside the newest Ruby resources. This is never a good idea.

Well... here we are. I hope this helps you when having this problem in installing gems with native extensions.

See you!

Friday, June 10, 2016

Rails on Windows

We all know how difficult it is to run Rails on a Windows environment.

If you visit StackOverflow you'll find thousands of questions related to this fact. It's not an easy task and most of the times it requires non-orthodox solutions.

Recently, after almost five years doing RoR, I needed to run Rails locally on a Windows environment for the first time, because a customer had a requirement for this. His system must be run in his intranet and should be hosted in his Windows server. I had never faced such need before, for all my  systems were internet-based and most of them deployed in VPS servers I configured myself, so I had no problem in doing everything needed.

When this happened, people told me to use InstantRails (in http://installrails.com/) and I did it. It really helped me a lot and I started running my app in a few minutes with this installer. But...

As you may see by this print of InstallRails website,

we are far from having the newest Ruby and Rails versions. And as soon as I started running my system there I started suffering. My system used Ruby and Rails features not available in the versions provided by InstantRails!

After fighting a lot with this, and in fear of having to review all my code to downgrade it to Ruby 2.1.5 and Rails 4.1, I installed a Linux VirtualBox in my customer's server and did the Rails thing as I was used to do. I had it running perfectly in about twenty minutes.

This called my attention out to the following facts:

1) Rails for Windows is a dumb shit! And if it was like this to me (programming since 1984, used to Windows since its first version, doing Rails almost exclusively during the last five years...) I started wondering what a computer newbie would do in my place. He/she would probably give up RoR and move back to PHP, because then he/she would have easy install/configuration with XAMPP, for instance, in minutes!

2) Rails for Windows shouldn't be a dumb shit! After all, we have millions of Windows users around the globe, including many developers. And some of them won't use Linux for nothing, 'cause some of them don't want and some of them just can't install Linux in their work computers.

Even if don't like Windows, we need to improve our efforts to keep RoR running well on it. There are millions of developers like us facing all sorts of trouble with this. And we also have to consider those corporate environments where one can't simply install what he/she likes.

The lack of this is making it hard for the RoR culture to spread in large corporations still tied to Microsoft Windows.

Wednesday, June 1, 2016

Better algorithms (3)

This is the third article of this series {first: Better algorithms, second: Better algorithms (2)}. In the first two I stressed the importance of always try new approaches and the importance of knowing Ruby Core very well.

Today I'm going to talk about another important point to optimize your code: learning about the problem!

The first approach we use to solve a problem is seldom the best one. Common sense is not a good programmer, I tell you.

To give you a good example of what I mean, I'm going to use a simple mathematical problem: Write a method to tell if a number is prime or composite.

We learned at school that a prime number is the one only divided by 1 and by itself. This way, 5 is prime, because neither 2, 3 or 4 may divide 5 with a reminder of 0. But 6 is not prime, is composite, because 2 and 3 divide 6 with a reminder of 0. I keep telling "with a reminder of 0" because we are talking about integer division.

The first approach is almost obvious when you read this description. Given an integer n, we only need to test all numbers between 2 and (n-1). If even a single one of them divides n, then n is composite. It is prime otherwise. Like this:

But if we spend sometime reading a book on Elementary Number Theory like this, we'll find out a theorem stating that the smallest prime divisor of n is not greater than the square root of n. In other words, if p is the smallest prime divisor of n, then p <= Math.sqrt(n). Since we don't need to find all divisors, but only find out if there is one and the smallest is as good as any other, based on this theorem we could make our solution much better by adding a single line:

Why this solution is much better? The answer is time!

Let's do a simple benchmark comparing the to solutions and we'll see.

The first method running on a range from 1000 to 2000

The second method, running on the same range in the same computer

As you may see, we had a dramatic reduction in time. And this would be even easier to see with greater numbers.

So, every problem is worth a small research. You may improve a lot the performance of your programs by doing so.