My experiences and opinions on Ruby/RoR

Over the past few days, I 've talked about a lot of things about Ruby. To sum up, I wrote this blog.

At the beginning of this year, I plan to thoroughly experience Ruby on rails. For me, I have not been familiar with "new language" for many years. In the years before this deep experience began, I also had a few simple experiences. I basically had a few games. I think there are so many things to learn. It is also very easy to use PHP to write one easily, give up.

However, I think there must be a reason why something swept the world quickly. Even if I don't actually use it, it is worthwhile to figure out the reasons behind it. So I put down the mentality of the old programmers. Like a beginner, I started to look at the most basic documents and tried various projects that everyone praised. I asked people familiar with Ruby where I could not understand them, ask not only how to implement it, but also "why?" and "What is the past?" and "How can other languages solve a problem here ". After a few months, although I haven't been able to use ror to really develop a completely independent project, I have a general understanding of the whole picture, and I know the history and culture, experience the Community atmosphere. At this time, I think I can make some comments on rails.

Before this attempt, I was most worried about "performance problems". Now it seems that this is a pseudo problem. First, Ruby's performance is not so bad (it was really bad in the past few years, but now it is quite good). Second, it is used for a website application. No matter what language it is, it should be solved by caching and distribution, that is to say, in the end, it depends on the correct system architecture, rather than the performance of the language itself. Finally, even if the performance is really poor and completely unsolvable, it can be written in a more efficient language, just give the processing result to Ruby through various communication methods. With the development of computer hardware, most performance problems do not exist, except the gap between architects. I have seen many systems that use dozens of machines but cannot withstand hundreds of thousands of loads. Can this blame the poor performance of languages and platforms?

Among all the advantages of Ruby, the only thing I cannot agree with is "smooth learning curve". In fact, Ruby is more difficult to learn than PHP, this is probably a gentle comparison with J2EE. I believe this is the source of many misunderstandings and attacks against Ruby. On the surface, to learn Ruby, especially ror, at least understand the design mode and know how the server system works, you even need to be familiar with the operating system, make good use of ror, and be more exposed to various projects and standards. This takes a lot of time to learn. At the same time, we also work with various testing tools and deployment tools. Although they are not necessary, we still need to learn them (I still lack a lot here ). I used to joke that people in the Ruby community destroyed the purity of English because they fork's new projects were too easy and everyone liked to create various open-source projects. The names that directly match the functions were exhausted, so I had to use a variety of strange related English words, so that I could find Ruby projects by searching many English words. It is indeed a great deal of pressure to put these things directly into a beginner. The Getting start of Ruby on rails is too stuck on the surface. It is barely an early adopter and far from practical use. Relatively speaking, PHP is much simpler. The page is intuitively mapped to the PHP file and can be written without understanding anything (of course it is not easy to write ), the result is that everyone can understand PHP, but not everyone can understand Ruby. It is easy for people to attack each other to conceal the learning pain. Before I made up my mind to study deeply this time, I also thought PHP was the best. I remember @ rainux told me that it was hard to feel the benefits of ror when I first started it, it takes a while to discover it.

Ror also firmly supports many theories in architecture and development process management, such as MVC, such as agile, such as TDD... these also increase the learning cost and, of course, the interfaces under attack. For example, TDD is too cool, so ror is also cool. Or: I hate agility the most, so I hate ror. In fact, agile and TDD are both true. They both have mature methodologies and practices, and have good enough tools to solve many problems. If you do not agree with this, it can only be said that there is too little experience in development and project management, and there is no complicated problem. What is wrong is the false propaganda of agile and TDD. The two cannot be mixed together.

Another common saying is to look for Ruby's large-Traffic Project case. However, finding top projects developed by Ruby is meaningless. Neither DHH nor 37s is a product suitable for everyone. They only wish to do their best in a certain field. Not everyone is interested in creating hundreds of millions of products, not to mention a few. For most projects, ten million is a good level, which is the best practice field of ror. In reality, most projects can achieve 1 million pv, which is already remarkable, it is too early to think about technical solutions with hundreds of millions of PVS.

On the issue of organizing technical teams, the difficulty of popular languages is almost the same. A team of 10 people can easily organize any language, but from another perspective, it is not easy to organize a team of 10 people in any language, but the difficult methods are different. Language A may be difficult to find people. I will receive one resume in A week, and language B may be difficult to identify. I will receive 200 resumes A day, but I can't see them all. In fact, the most difficult thing is to organize a reliable team of 10 people. The language used by the team is negligible as opposed to the difficulty of finding 10 reliable people.

Choosing a language is not just a language, but also a community. I was deeply impressed by the vitality, friendliness, regularity, and unified aesthetics of the Ruby community. DHH and 37s have a huge impact on this community. I also believe in their philosophy that small companies may not be bad, small companies may not be great, and the pursuit of pv is better than the pursuit of extreme products. We create a product to solve a type of human problems, not to surpass or compete with others.

15 years ago, PHP versions earlier than 3.0 were completely unavailable (of course, at that time, PHP was also called Personal HomePage ), at that time, using c to write cgi/isapi or using perl was the most common form of development for websites. At that time, PHP was the next generation language, and many programmers would disagree. They would pick out 10 thousand PHP less than c or perl. These are true, but the world will change. Today, PHP has become a widely used and suitable language. I don't think Ruby will replace PHP in the future, but at least, I think the next generation of high-quality internet products will have a greater chance to appear in the Ruby community, just like PHP vs perl in the past, which is the trend of the times.

Finally, I would like to say something that may not be nice. If you have not made up your mind to transform into a special fool like writing a letter to the teacher, if you still think that technology is a bit interesting, if you want to create some products on your own, you should maintain sufficient technical sensitivity and study new things carefully, instead of looking for excuses for yourself. Just like this cartoon. I have to ask myself whether this is really bad or I cannot learn it myself? Of course, it is difficult to acknowledge the latter. I did not learn it a year ago.
 

Link: http://blog.devep.net/virushuo/2011/03/23/rubyror.html