. NET Programmer's reasons for learning Ruby on Rails

You are a veteran. NET programmer, and has built many Web applications with asp.net.

Countless sleepless nights, in order to allow the event-driven model in the ASP.net control lifecycle to execute in the way you want, you painstaking and delve into details.

You are proficient in using design patterns such as presentation model, Model View presenter to tier your application to make it easier to test and maintain.

You think Ruby on Rails is just one of many touted technologies. You will not give it too much attention until it has gained considerable market share.

Welcome to my world. If you are still reading this article, I salute you. You may be full of curiosity about what I say below. Why I--a senior. NET programmer, after one months of learning Ruby on Rails, I think: only after I understand Ruby on Rails, can I finish many of the previously developed applications with less time and coding?

Frankly speaking, I still think. NET is great. It provides a platform for me to provide a constant stream of business value to my customers. But I always remind myself: a simple problem, there are a lot of different ways and techniques to solve it, and there are always some better than others. A certain kind of technology will inevitably produce some unconscious prejudices, which will ultimately hinder my ability to provide business value to my clients. For example, understanding dynamic scripting languages like Ruby makes me think that I can spend less time writing simple, Batch/shell scripts than I do with compiled languages.

Why not?

Here are a few things that I (A. NET programmer) to learn Ruby, discover some typical differences. I hope you like it.

There is no need to compile the concept of no compilation in Ruby. Everything happens at run time. Some people think that code compilation can prevent careless coding. Well, you might want to take a look at how test-driven development works, continuous code integration (not to be built every day, of course), unit tests (which do not involve testing of database and Web services) and dependency injection can help you generate good quality code that allows you to flexibly change your code with confidence. The guarantee function of compiling becomes less important all of a sudden.

Dynamically increasing the behavior of classes--without using the decorator pattern in statically typed languages, we can use Decorator mode or template method to dynamically add the behavior of a class. In Ruby, there are more ways to do this simply without complicating the design structure of the object. This is only because the language itself supports it, such as using modules as Minxin, using Class_eval, Instance_eval methods, and so on. In fact, you can even programmatically define the methods of a class at run time. In a static type language, it can also be done by code generation. But knowing more is a step forward for you to be a good problem-solving person.

(Translator Note: Mixin is a class that provides some functionality to inherit from a subclass in an object-oriented programming language, but mixin cannot be instantiated.) Inheriting from a mixin is not a special form, and it is better suited to collecting functionality. A subclass can even choose to inherit all or most of its functionality by inheriting one or more mixin. A mixin can be deferred to the runtime to define and bind methods, while property and instance parameters can also be defined at compile time. This differs from our usual approach, such as defining all the attributes, methods, initializing at compile time, and so on. ）