Several reasons for liking Ruby programming language

Ruby programming language is developed by the Japanese pine line, is a simple and fast object-oriented programming language, today mainly talk about the ruby framework--ruby on Rails (http://www.maiziedu.com/course/ruby/), Maybe some friends don't like Ruby, but as a language, I think Ruby is well worth mastering and learning.

Let's talk about what it's good to learn Ruby.

The biggest advantage of Ruby on Rails is that I think there are four of them:

1. Language Dexterity and portability, suitable for rapid development and deployment.

2. A variety of "magic" that comes with itself and magic that can be loaded via gem or vendor code. Make the code beautiful and concise.

3. Easy integration with various front-end JS frameworks (including backbone,ember,react, etc.)

4. There is a Rails console that makes test and debug extremely easy.

If you do not believe what I say, you can go to the small and medium-sized companies to take a look, a large part of the original first code base is based on the Ruby on Rails. Although there are various splits and rewrites later on, it is also a very important skill to have a good grasp of the original Ruby code. I wrote C + + and Python in the early years, and for more than three years, I had 60% or 70% of the time to write Ruby and occasionally write Java and Scala, but Ruby is still the most handy language I've ever written, not one of them. Because of the many uses of both Square and Airbnb's two companies, Ruby Proficiency also became a small advantage in my work.

Although I love Ruby, I don't want to write too much nonsense to explain why Ruby is good except for the four points above. Rather, say something useful, and learn how to avoid the holes in Ruby on Rails as much as possible.

The biggest problem with Ruby on Rails may be that the language is fast to write code and difficult to maintain. What's the reason? How to avoid it?

First, Ruby is a dynamic type. What do you mean, we all know that a variable has no type declaration, and when run time gives it what value is it? The official word for language is called duck typing:

"If an object walks like a duck, Ruby happily thinks it's a duck," he says. ”

Code that does not have a type declaration is simple and convenient to write, especially when there are inheritable reuse relationships between different objects, and if a strongly typed language such as Java has to be used interface or abstracted class must be handled strictly according to the design pattern. In Ruby, as long as you want to give a variable what the value, then as long as the subsequent assignment is correct, the variable can have what value. This inevitably leads to two of troubles:

1. Accidentally assigning the wrong value, Ruby is still went ahead and does not complain. It's just that you can't find the north in the actual run, and get a completely unexpected result.

2. Refactor code is required, that is, when the code is refactored. This is almost a disaster. Imagine you have 100 keys. 100 lock, the language of the type declaration may be different types of keys and locks, and no type of declaration of the language all keys and locks are almost the same. Code refactoring is like messing up all the pairings and combining them in a new form. The final result is to look at the new code, which is very neat and exception.

A very effective solution is to enforce type checking and assertions for some important types of parameters, especially API. For example, on Airbnb, we use a validation gem to detect the type of all required variables in code, similar to assertions like "Validate Count Is_a Integer".

Second, many people are ActiveRecord smattering on the Ruby on Rails. ActiveRecord is probably one of the most powerful magic (or not one) of Rails. ActiveRecord is a mixture of database access and business logic access in code. If you write well, you can do more with less, write the DB access-efficient and clean database access related code, such as its scope and the use of association. However, if for ActiveRecord how to implement indefinitely, plus the execution plan smattering for MySQL, it is possible to write code that will crash in the production. Give three common examples:

1. To be honest, I don't know that programmers who n+1 Query are supposed to get a good look. N+1 Query is almost one of the most common mistakes I've seen causing production problems (perhaps not one of them).

2. Association of Rails. The most convenient 1-to-1, 1-to-many, many-to-many magic for wrap objects. Many other languages should not have this concept. There is an official document on Rails that is highly recommended for in-depth understanding. It is also one of the most commonly used magic to see.

3. Some jobs in Rails need to be records and processed in the database that meet certain conditions. Rails often have find, find each, and find in batch, and so on, although different query statements can give you the same results, but because of their corresponding SQL statement conversion is not the same, a lot of time efficiency days difference. This is also a common point in Ruby code that shows a programmer's knowledge of Rails.

A lot of examples, sit down can slowly write, here is just handy to write a few first thought. So we don't have to write the inefficient Ruby code and curse Ruby. That's not good. I think Ruby may feel more resentful.

Third, because of the magic in Rails, writing Ruby's RSpec Test example might be harder than writing Ruby code. Writing good RSpec actually has a lot of tricks, most commonly used:

1. A variety of stubbing, including applications for Factorygirl and Fixture, good Rspec can actually help avoid many of the pits inside Rails. How to write good Rspec, this is not an article can be said clear, interested can leave a message, if I have good information can be shared to everyone.

2. This article also applies to the preparation of all test examples of programming languages. is top-down or bottom-up, how to guarantee coverage, first write code or write test first, a lot of good books. The idea of writing test in another language is also applicable here.

To be honest, I've probably spent as much time writing RSpec as I did on the Rails code itself. Even now, I dare not say I can write RSpec well, can only say I am willing to spend time and energy to write the spec well.

Finally, Rails itself is a very refined language, and there's no need to use some pretty remote syntax to make the code more compact. Remember when I first started writing Ruby, one of the things I liked to do was to write the entire function I wrote with a single line of Ruby's tricks. And then what? Not only the readability is poor, sometimes time is long, oneself all forgot how to play. Later, the more the more honest, how easy to understand how to write. There is a principle of writing a program that I think is practical in all languages: good programs should not require too much comment. This includes the clarity of the structure and the most appropriate naming. This principle is especially important for Ruby, because Rails itself has a variety of magic, which makes it easy to write code very well and then be very readable. In particular, even if an IDE such as rubymine is not accurate in jumping to a function definition or function application, the poor readability of the code is almost destined to be a hole sooner or later. So when you write a Ruby code and you feel the need to add a note to explain what you want to do, you might want to think about whether you should rewrite the code.

In fact, fifth sixth seventh ..., because there are too many things to talk about in a language. Remember when Square had a special workshop for Rails every week, and a weekly chat, not to mention an article? Square two years in my biggest harvest also learned to write Ruby, remember I have half joked and friends said: "The longer the work, the more the skills are not afraid to write on the resume, because constantly see the real cow." After I look for a job, I will write a little Ruby code on my resume. "Because I like Ruby very much, my number takes the meaning of writing Ruby code on my Mac. Of course, Java and Scala I like it, too.

Several reasons for liking Ruby programming language