Rails off the rail: Why do I rewrite Archaeopteryx in CoffeeScript
Have you been to parties where friends from work and friends from college don't talk ?
I posted a video on Tumblr that I never posted on Facebook:
This is a guitarist, annealed by Skrillex's Bangarang.
I did not post this video on Facebook because I have friends from Uni on Facebook (who, judging by Spotify, listen to Skrillex), and also friends in the rave scene since I lived in San Francisco. I really do not know their opinions about Skrillex, but I can assume that they would not be delighted, because some of them are real techno-purists and indeed musical hipsters who cannot tolerate pop music who knew dubstep years before Skrillex. In fact, I heard some very early pre-dubstep recordings in London in 2000 and I probably wasn't the only one of this group of friends who listened to this — which means that at least some of us knew about dubstep ten years before Skrillex.
My old hipster friends in the rave scene probably would have spat on this video for the same reason why my naively musical friends would have liked it: Skrillex achieved a phenomenal success at the expense of a style that is essentially a pivot table pulling a column from the tables of rock and rave. Posting something similar on Facebook seems to mean pushing two different groups with your foreheads, despite their diametrically opposed tastes and despite the fact that I haven’t seen all of them for years. Waste of time.
It reminded me of an old quote from Why the Lucky Stiff:
When you create nothing, your tastes determine you, not your abilities. Your tastes only narrow the social circle and repel people. So create.
I remembered this because I saw excellent presentations at LA RubyConf , the only drawback of which was a huge number of impish subkolov towards almost all languages ​​except Ruby. In my opinion, the only exception was Smalltalk, which, as usual, received a standard portion of respect from rubists talking about Smalltalk. I used to like Smalltalk too, but I don’t like idolatry. I once bought an old Mac Mini from a Los Angeles-based rubist who collected so much old computer stuff that looked like a techno-historian. One of the exhibits in his collection was a boring and dreary IBM Smalltalk tutorial — one of the most tasteless corporate documents I've ever seen in my life; besides, a good counter-argument to the cries of rubists from a cult called "Smalltalk was the coolest thing in the world."
A couple of years ago, Rails was just as awesome as Skrillex is today. But in the courtyard of 2012 and on Hacker News, this post appeared:
What should I learn deeper, Node.JS / Express.JS or Ruby on Rails?
For many job openings, knowledge of Rail is required, but it seems that Noda is planning to bite off a decent piece of web development pie in the near future.
In other words, should I teach the dominant technology that will simplify the search for a job, or should I trust in the new awesome?
We all know what is the opposite of the new fucking awesome.
Indeed, in that topic on Hacker News there is such an answer:
Rails - yesterday. This is a fat meta-framework, which requires a great deal of peripheral knowledge to understand.
Needless to say, you should filter everything that you read on Hacker News (if you take it seriously at all), but what does it mean for Rail to become “yesterday”? If you look at Rails as a framework, then this statement is nonsense, but you should look at Rails as a fashionable joke, how everything falls into place. The rails were at the height of fashion a couple of years ago, but these days are already in the past.
People diminish the influence of fashion on the development, but in fact not everything is so simple. As Alan Kay (creator of Smalltalk) said: " As long as there are things that are developing faster than education, we will always have a pop culture ."
The rails are old and stupid, and Node.js is a new awesome. But people hate Node.js because of excessive “noise”. For me personally, it looks funny, because the main noise around Node.js comes from people who hate Noda for this noise.
I am not surprised by the stories about how Noda is cheeky. When Rails were at that age, they were no less cocky. At RailsConf 2007 there were a huge number of excellent technical reports, but also a critical mass of narcissistic assholes gathered there. Then, as far as I could, I tried to ignore this narcissism, and now I advise you to do the same with Noda. And that's why.
The pompous and daring Rails had three main points that they used to troll old men from the Java world: design patterns, a long JVM launch time, and a too ceremonial approach to writing code that did not meet the requirements of developing simple, modern web applications. Today, the launch time of the Rail is so long that the community had to write Spork - a special gem that keeps the environment alive alive between running tests . Otherwise using TDD with Rails would be difficult. Running tests in Rails can take so much time that by the time you finish you may well forget that in general you are writing now, and sometimes even your own name. When the Community Rail was at the age of today's Noda, they made fun of design patterns. But look at the implementation of ActiveRecord :: Base, which overrides "inherited" and you will understand that this
We have to use strange and confusing mechanisms to attach the ClassMethods and InstanceMethods modules to ActiveRecord :: Base, because if we try to inherit from it, we won’t get a pure heir. In fact, we get a new class that is created using ActiveRecord :: Base. As you can see, ActiveRecord :: Base is actually a hidden ActiveRecordClassFactory factory.
As for too ceremonial code, let me tell you about my eggs. I actually have rake-tas for scrubbing eggs. Someone once told me that a real programmer should definitely write code for scratching his crotch, and I seriously approach such questions. My code uses the serial port to control the Arduino. The Arduino has a servo drive to which the comb is attached. This whole mechanism is located on the shelf under my table, at the level of the belt.
I literally have to write “bundle exec” every time I want to scratch my balls. And I’m not thrilled about having to write “bundle exec” every time to scratch my eggs. I called the task “balls” so that I could write “rake balls”, because it scrubs my eggs ( “it it rakes my balls” ), and Bundler crap all my beautiful syntax. Do you think I'm complaining? You think, I try to draw your attention to what to require me to write “bundle exec” every time I want to scratch my own eggs - does it mean to show incredible charity to me as a user? In the end, I use rake precisely because I write in a language that is designed to facilitate the work of the programmer! But of course not, I will not say anything like that, because it will not be constructive, and it will not help the cause, so I just type “bundle exec rake balls” to scratch my eggs in deathly silence.
The need to type “bundle exec” every time I want to scratch my eggs is the personification of an overly ceremonial code that Rails spat on from 2005 to 2007. Community Rail has become everything that makes fun of itself. Despite this, they were able to fundamentally change web development for the better. And not only in Ruby, but also in almost all other languages. When Rails first appeared, they launched a wave of clones that bloomed in other languages ​​almost daily. As Rail grew older, other platforms also grew up. Today we do not see the new clones Rail, which appear on every Tuesday, as it was in 2006. But we can see how the Rail community creates code generators, conventions before configurations and neat routers every time it leaves its comfort zone. For example, CoffeeScript received its dose of inspiration from both Ruby and Rail, setting developer happiness to the highest priority.
That is why I think that listening to the hype around Noda is stupid. It is not worth the spent nerve cells. The hype leads to empty disputes supporters and opponents. It is pointless, just hammer. In process of development, Noda will change, absorbing all criticism. Just like Rails at the time. In the meantime, there is a lot of interesting work around. People create wonderful things, and browsers are developing at such a pace that by the time Noda grows up a bit, the principles of web development will change significantly.
The same thing happened with Rails. That is why writing under Rails was so much fun, while Rails were on horseback. And precisely because today's Rails is a powerful and useful tool. But just a tool.
However, going back to the quote from Why the Lucky Stiff, it makes no sense to hate Rails for the fact that now they are not as fashionable as they used to be. Of course, you can look at Rails, as a dinosaur, out of fashion, but much more constructive to look at them as a useful tool for creating different things. But here we are also waiting for a couple of problems. Let's forget about the “Rails - Yesterday” argument, but back to this comment on Hacker News:
Rails - ... is a fat metaframe for understanding which requires a huge amount of peripheral knowledge.
The first thing that reminds me of this is a meaningless stuffing comparing Rails with “wearing shorts on the head” . I cannot agree with this point of view, because most of this criticism applies only to how official documentation advises you to use Rails, and not to how serious, well-known, selective Rails developers use them (except, of course, for DHH). I think that the argument about "a huge amount of peripheral knowledge" hit the bull's eye. And the main thing among these peripheral knowledge is an understanding of the difference between what the official documentation of Rail teaches you and how the developers actually act.
For example, I can’t imagine that anyone other than DHH, and perhaps a couple of other developers of Rail, would actually use rail tests as Rails itself recommends. I don’t think that anyone other than DHH and perhaps a couple of other developers Rail generally takes the official Rail approach to testing seriously. Rail modular tests are not really modular, rail integration tests are not really integration tests, but rail functional tests are not functional. Most developers simply create a “spec” directory, put RSpec and throw everything else to hell. So to bring such arguments in a dispute against Rail is a waste of time.
In the “Rails - old and stupid” argument, the “old” part can be ignored. “Old fucking” means “classic.” But “stupid” is something that you should pay attention to, because the Rails do have enough stupid garbage. Show me what happens if you forget to put “source: rubygems” as the first line in your Gemfile?
Are you fucking kidding me ?!
This is what Google’s hint “perhaps you had in mind” would look like if it were developed by the Bandler team:
Translation: Perhaps you meant "Britney Spears." Then please enter your search query correctly, fucking dumbass.
Bundler makes dependency management very simple compared to how it was before, but due to the fact that 'source: rubygems' is not enabled by default (although the Bandler knows that it should be enabled), the Bandler fails to completely apply the convention. before configuration. And I do not mean "could be better", I mean "you count, fail, stay the second year." It is the same as “proving a little with clothes”, having come to work in only shorts worn on the head, and also in dirty ones.
Bundler is not the only problem. With the advent of Rails 3, Rails went off the rails.
Translation: Rails 3 makes it easy to create new applications: ...
This link is ironic, it leads to a giant page with a list of things you need to do before you can start writing your application.
Translation: When I started to learn rails, roughly version 0.6, I had one executable file that installed ruby ​​+ rails. I typed one command and started coding.
Check out this discussion:
Transfer:
@topfunky: Rails 3 promised the opportunity to "collect their little rails" only with what you need. Does anyone actually do this?
@jashkenas: @topfunky I don't think so. IMHO, the consequences of Merb Merb'a - this is so far the saddest thing that happened with Rails.
@ j3: @jashkenas can be more? / cc @topfunky
@jashkenas: @ j3 All progress stalled for two years, third Rails is largely * still * slower than the second, Bundler is a nightmare, Node.js won.
You can read the rest here if you want. I'll just give a couple of excerpts.
Translation: @tomdale Okay. For applications from scratch, I would probably choose Node. If Rails had really developed over the last 3 years, perhaps everything would have been different.
Transfer:
@jashkenas: @tomdale I agree on all points. Basically, I'm just upset that the third Rails does not look qualitatively better than the second. Same features, different API.
@josevalim: @jashkenas @tomdale if you evaluate Rails 3 only from the perspective of an application developer, then yes. but the third rails were always aimed at the plug-in developers community.
To paraphrase Jose, Rails 1 and Rails 2 were meant for application developers. Rails 3 is intended for plug-in creators and programmers who support existing applications. This is all great, but creating an application framework by ignoring application developers as the main target audience is just one of the things Rails made fun of in Java in 2006. José is one of the main developers of Rail, and he wrote a terrific book describing the incredible power of the third modular API Rail , but sometimes tweets sound louder than books.
Translation: “Node.js is the future of server applications” @wardcunningham #nodepdx
Ward Cunningham is such a sick argument .
My answer to that guy with Hacker News, who asked if he should teach Noda or Rails - the same one he would get from Jeremy Ashkenas (teach CoffeeScript - approx. Lane ): teach Noda. (Actually, I can’t speak for Jeremy, so rather learn both, but more attention was given to Noda). Sometimes it's fun to be a party-goer, and the music behind the next door is more fun now. Today, it is more important to learn Node.js, CoffeeScript and Backbone, because the work that is boiling in these communities changes paradigms. The current work with Rails lies in combing the paradigms that Rails changed in due time - however, the third Rails added as many sharp corners as they removed.
By the way, about sharp corners. The browser turns into an operating system. If you have a new version of Chrome, you can already play with the browser - based drum machine , as well as with filters, compressors and synthesizers . Of course, at the moment it may end in a browser crash, but soon everything will be awesome. Also, it is very likely that web applications will look outdated compared to mobile applications , and it will be easier for Node to benefit from this than Rails.
When you learn something new, you want it to be fun. Rails are still useful, but no longer give birth. Although they are full of awesome pieces, the air is also filled with all sorts of “what the hell? what did they even think ?! ” To rake this shit is not a pleasant pleasure. If you want to work with what will be fun, try Clojure, Scala or Node.js. Clojure and Scala work on the basis of Java, the memories of which still do not allow me to sleep at night, and Node.js implies a language to which I am having fun, despite its frequent nonsense. CoffeeScript is far from perfect, but it’s nice to write on it, because it reduces the WAT factor of JavaScript to an acceptable level of background noise.
Rails is no longer the future, but the past.
http://www.youtube.com/watch?v=WM1RChZk1EU
I think that now it is easier to find a good job with Node.js than a good job with Rails. But personally, I find it more interesting to work on my own projects, on which I also enjoy the Noda. So I am preparing a series of videos in which the creation of music will be used for teaching Node, CoffeeScript, Backbone, Socket.io and, most importantly, jasmine-node - the port of Jasmine's Javascript BDD library on Node.js. Using jasmine-node, you can perform your specs on the server in most cases (or always always tell the details in these videos), and the winnings are just awesome.
I never liked to do the specs in the browser. Instantly executing them in the command line is a great pleasure, because you can push them into continuous integration, and basically anywhere, using unix return codes. Seriously, in 2012 there are no more excuses left to not write your javascript in the style of TDD / BDD.
Returning to the javascript script machine theme, I wrote a library on Ruby called Archaeopteryx. It is a combination of a MIDI interface, a drum machine and a probabilistic breakbeat improviser. I started rewriting it in CoffeeScript. The new version is called Clyde and its code has become much cleaner.
I also prepared a couple of really fun hacks.
I chose the name Clyde partly because I was asked too many questions about how to pronounce Archaeopteryx (Archeopteryx) correctly, but mostly - in honor of the legendary drummer Clyde Stablefield - not just a tough drummer, but the coolest drummer , about whom James Brown sang - which, by the way, will be RAPPORTEUR at Madison RubyConf this year. This is the same conference that I rasssychalsya last year after saying that testing JavaScript is not necessary. I can't even tell you how excited I am.
To be fair, Ari Russo wrote a terrific Ruby MIDI library called Unimidi, which looks much better than I ever wrote, but for this project I’ll focus on JavaScript. Partly - because it seems to me more profitable to invest my time in this language, and not in Ruby (especially because I will repeat the same things that I already did in Ruby), and partly because I believe in its technological superiority .
By the way, it's not just that Clyde is easier to pronounce. Many people complained that Archeopteryx is hard to read. Despite the fact that Clyde is in active development, its source is already much easier to read. First, I had to natyrim a lot of low-level MIDI interfaces for Archeopteryx from Topher Cyll's excellent book for authorship called Practical Ruby Projects . (Later Ben Bleything rewrote them, creating a cleaner interface library called MIDIator ). On the other hand, to add MIDI support to Clyde, it was enough for me to install the excellent Node.js library and write some simplest code. Entire pieces of Archeopteryx code are devoted to the implementation of setTimeout () javascript equivalents and copying lambda to L, so that objects can be freely assigned to methods. Like how we pass functions to javascript.
Roughly speaking, JavaScript is better suited for projects of this type, because Archeopteryx uses a bunch of hacks just to get Ruby to work like JavaScript. And while JavaScript itself is pretty vigorous, CoffeScript is so beautiful that it sometimes makes Ruby look awkward.
Transfer:
@gilesboatboy: every time I see do | foo |, a little zadrot wakes up in me, wanting to kill. how to call it? zadrotognev? because “do” is completely unnecessary letters :-p
@judsonlester: if there were real macros in Ruby, then there would be no need for these letters.
@topfunky: where is my CoffeeScript for Ruby ?! let the compiler use indents, which everyone already writes, instead of useless do-end.
The guys who were playing with Clyde also liked the simple integration with Garageband, which means that any Mac user can easily and easily raise Clyde, while trying to install Archeopteryx on their computer baffled many. An open-source project that works only on the author's machine is useless.
I like the idea of ​​my videos, because they will teach advanced technologies with fun and interesting examples. They can actually become the best, most exciting way to learn modern JavaScript development. In my opinion, it is important that learning how to develop software is fun, because I want to inspire people to search for their own hacker solutions, because we remember best what we are concentrating on. This idea is permeated by our hacker languages: when we study a new technology, we say that we are “playing with it”. Tomorrow, after lunch, I will publish my first video for free, so you can look here on Friday ( here it is - approx. Lane. ).
Since this blogpost is to some extent an advertisement for these videos, and truth is important in advertising, I must admit that in fact I don’t have a rake task for scrapping eggs. And yet, I got the impression that I needed to type “bundle exec” every time I scratched my eggs, although this garbage could have been avoided with minimal knowledge of Unix paths and environment variables. (A little more whining about Bundler: if you write “bundle && foo”, you will never get to foo; it seems that Bundler does not support return codes at all).
Returning to the global problem, Rails is definitely off the rails. A clean and modular API is an important goal, but not as important as the speed of development, a modern set of features (why Rails still does not support HTML5 in the way Ajax supported at one time?) And, above all, the happiness of a programmer. The integration of Merb was a huge and time-consuming departure from the goal, which brought only a small benefit, and DHH, who wrote two whole books on why it is worth refusing to add new features, had to cut these initiatives at the root. I, nevertheless, will continue to use Rails, because they still remain a wonderful framework, but in my opinion it would be absolutely fair to say that Rails 3 took a step backward with respect to Rails 2, and Bundler, however useful it may be, is still very far from ideal. They say they have reached version 1.0, but I don’t think that anyone takes this seriously.
Update : Yehuda Katz, one of the developers of Bandler and Rail, sent me this useful piece of code :
I posted a video on Tumblr that I never posted on Facebook:
This is a guitarist, annealed by Skrillex's Bangarang.
From the translator:
The original text was posted in the personal blog of the author and was not designed for subsequent translation. It is written in a very free style, which I tried to recreate, including a light profanity. As a result, the translation came out quite artistic, so I strongly advise pedants to read the original article in English .
Although the author sometimes deviates from the main topic and is a bit of a PR, I still found this article relevant for Habr.
')
And yes, the article is really about Rails, despite the lingering introduction :)
I did not post this video on Facebook because I have friends from Uni on Facebook (who, judging by Spotify, listen to Skrillex), and also friends in the rave scene since I lived in San Francisco. I really do not know their opinions about Skrillex, but I can assume that they would not be delighted, because some of them are real techno-purists and indeed musical hipsters who cannot tolerate pop music who knew dubstep years before Skrillex. In fact, I heard some very early pre-dubstep recordings in London in 2000 and I probably wasn't the only one of this group of friends who listened to this — which means that at least some of us knew about dubstep ten years before Skrillex.
My old hipster friends in the rave scene probably would have spat on this video for the same reason why my naively musical friends would have liked it: Skrillex achieved a phenomenal success at the expense of a style that is essentially a pivot table pulling a column from the tables of rock and rave. Posting something similar on Facebook seems to mean pushing two different groups with your foreheads, despite their diametrically opposed tastes and despite the fact that I haven’t seen all of them for years. Waste of time.
It reminded me of an old quote from Why the Lucky Stiff:
When you create nothing, your tastes determine you, not your abilities. Your tastes only narrow the social circle and repel people. So create.
I remembered this because I saw excellent presentations at LA RubyConf , the only drawback of which was a huge number of impish subkolov towards almost all languages ​​except Ruby. In my opinion, the only exception was Smalltalk, which, as usual, received a standard portion of respect from rubists talking about Smalltalk. I used to like Smalltalk too, but I don’t like idolatry. I once bought an old Mac Mini from a Los Angeles-based rubist who collected so much old computer stuff that looked like a techno-historian. One of the exhibits in his collection was a boring and dreary IBM Smalltalk tutorial — one of the most tasteless corporate documents I've ever seen in my life; besides, a good counter-argument to the cries of rubists from a cult called "Smalltalk was the coolest thing in the world."
A couple of years ago, Rails was just as awesome as Skrillex is today. But in the courtyard of 2012 and on Hacker News, this post appeared:
What should I learn deeper, Node.JS / Express.JS or Ruby on Rails?
For many job openings, knowledge of Rail is required, but it seems that Noda is planning to bite off a decent piece of web development pie in the near future.
In other words, should I teach the dominant technology that will simplify the search for a job, or should I trust in the new awesome?
We all know what is the opposite of the new fucking awesome.
Indeed, in that topic on Hacker News there is such an answer:
Rails - yesterday. This is a fat meta-framework, which requires a great deal of peripheral knowledge to understand.
Needless to say, you should filter everything that you read on Hacker News (if you take it seriously at all), but what does it mean for Rail to become “yesterday”? If you look at Rails as a framework, then this statement is nonsense, but you should look at Rails as a fashionable joke, how everything falls into place. The rails were at the height of fashion a couple of years ago, but these days are already in the past.
People diminish the influence of fashion on the development, but in fact not everything is so simple. As Alan Kay (creator of Smalltalk) said: " As long as there are things that are developing faster than education, we will always have a pop culture ."
The rails are old and stupid, and Node.js is a new awesome. But people hate Node.js because of excessive “noise”. For me personally, it looks funny, because the main noise around Node.js comes from people who hate Noda for this noise.
I am not surprised by the stories about how Noda is cheeky. When Rails were at that age, they were no less cocky. At RailsConf 2007 there were a huge number of excellent technical reports, but also a critical mass of narcissistic assholes gathered there. Then, as far as I could, I tried to ignore this narcissism, and now I advise you to do the same with Noda. And that's why.
The pompous and daring Rails had three main points that they used to troll old men from the Java world: design patterns, a long JVM launch time, and a too ceremonial approach to writing code that did not meet the requirements of developing simple, modern web applications. Today, the launch time of the Rail is so long that the community had to write Spork - a special gem that keeps the environment alive alive between running tests . Otherwise using TDD with Rails would be difficult. Running tests in Rails can take so much time that by the time you finish you may well forget that in general you are writing now, and sometimes even your own name. When the Community Rail was at the age of today's Noda, they made fun of design patterns. But look at the implementation of ActiveRecord :: Base, which overrides "inherited" and you will understand that this
class User < ActiveRecord::Base; end User = ActiveRecord::Base.new or in other words User = Struct.new(:username) We have to use strange and confusing mechanisms to attach the ClassMethods and InstanceMethods modules to ActiveRecord :: Base, because if we try to inherit from it, we won’t get a pure heir. In fact, we get a new class that is created using ActiveRecord :: Base. As you can see, ActiveRecord :: Base is actually a hidden ActiveRecordClassFactory factory.
As for too ceremonial code, let me tell you about my eggs. I actually have rake-tas for scrubbing eggs. Someone once told me that a real programmer should definitely write code for scratching his crotch, and I seriously approach such questions. My code uses the serial port to control the Arduino. The Arduino has a servo drive to which the comb is attached. This whole mechanism is located on the shelf under my table, at the level of the belt.
I literally have to write “bundle exec” every time I want to scratch my balls. And I’m not thrilled about having to write “bundle exec” every time to scratch my eggs. I called the task “balls” so that I could write “rake balls”, because it scrubs my eggs ( “it it rakes my balls” ), and Bundler crap all my beautiful syntax. Do you think I'm complaining? You think, I try to draw your attention to what to require me to write “bundle exec” every time I want to scratch my own eggs - does it mean to show incredible charity to me as a user? In the end, I use rake precisely because I write in a language that is designed to facilitate the work of the programmer! But of course not, I will not say anything like that, because it will not be constructive, and it will not help the cause, so I just type “bundle exec rake balls” to scratch my eggs in deathly silence.
The need to type “bundle exec” every time I want to scratch my eggs is the personification of an overly ceremonial code that Rails spat on from 2005 to 2007. Community Rail has become everything that makes fun of itself. Despite this, they were able to fundamentally change web development for the better. And not only in Ruby, but also in almost all other languages. When Rails first appeared, they launched a wave of clones that bloomed in other languages ​​almost daily. As Rail grew older, other platforms also grew up. Today we do not see the new clones Rail, which appear on every Tuesday, as it was in 2006. But we can see how the Rail community creates code generators, conventions before configurations and neat routers every time it leaves its comfort zone. For example, CoffeeScript received its dose of inspiration from both Ruby and Rail, setting developer happiness to the highest priority.
That is why I think that listening to the hype around Noda is stupid. It is not worth the spent nerve cells. The hype leads to empty disputes supporters and opponents. It is pointless, just hammer. In process of development, Noda will change, absorbing all criticism. Just like Rails at the time. In the meantime, there is a lot of interesting work around. People create wonderful things, and browsers are developing at such a pace that by the time Noda grows up a bit, the principles of web development will change significantly.
The same thing happened with Rails. That is why writing under Rails was so much fun, while Rails were on horseback. And precisely because today's Rails is a powerful and useful tool. But just a tool.
However, going back to the quote from Why the Lucky Stiff, it makes no sense to hate Rails for the fact that now they are not as fashionable as they used to be. Of course, you can look at Rails, as a dinosaur, out of fashion, but much more constructive to look at them as a useful tool for creating different things. But here we are also waiting for a couple of problems. Let's forget about the “Rails - Yesterday” argument, but back to this comment on Hacker News:
Rails - ... is a fat metaframe for understanding which requires a huge amount of peripheral knowledge.
The first thing that reminds me of this is a meaningless stuffing comparing Rails with “wearing shorts on the head” . I cannot agree with this point of view, because most of this criticism applies only to how official documentation advises you to use Rails, and not to how serious, well-known, selective Rails developers use them (except, of course, for DHH). I think that the argument about "a huge amount of peripheral knowledge" hit the bull's eye. And the main thing among these peripheral knowledge is an understanding of the difference between what the official documentation of Rail teaches you and how the developers actually act.
For example, I can’t imagine that anyone other than DHH, and perhaps a couple of other developers of Rail, would actually use rail tests as Rails itself recommends. I don’t think that anyone other than DHH and perhaps a couple of other developers Rail generally takes the official Rail approach to testing seriously. Rail modular tests are not really modular, rail integration tests are not really integration tests, but rail functional tests are not functional. Most developers simply create a “spec” directory, put RSpec and throw everything else to hell. So to bring such arguments in a dispute against Rail is a waste of time.
In the “Rails - old and stupid” argument, the “old” part can be ignored. “Old fucking” means “classic.” But “stupid” is something that you should pay attention to, because the Rails do have enough stupid garbage. Show me what happens if you forget to put “source: rubygems” as the first line in your Gemfile?
Gemfile . 'source :rubygems' Are you fucking kidding me ?!
This is what Google’s hint “perhaps you had in mind” would look like if it were developed by the Bandler team:
Translation: Perhaps you meant "Britney Spears." Then please enter your search query correctly, fucking dumbass.
Bundler makes dependency management very simple compared to how it was before, but due to the fact that 'source: rubygems' is not enabled by default (although the Bandler knows that it should be enabled), the Bandler fails to completely apply the convention. before configuration. And I do not mean "could be better", I mean "you count, fail, stay the second year." It is the same as “proving a little with clothes”, having come to work in only shorts worn on the head, and also in dirty ones.
Bundler is not the only problem. With the advent of Rails 3, Rails went off the rails.
Translation: Rails 3 makes it easy to create new applications: ...
This link is ironic, it leads to a giant page with a list of things you need to do before you can start writing your application.
Translation: When I started to learn rails, roughly version 0.6, I had one executable file that installed ruby ​​+ rails. I typed one command and started coding.
Check out this discussion:
Transfer:
@topfunky: Rails 3 promised the opportunity to "collect their little rails" only with what you need. Does anyone actually do this?
@jashkenas: @topfunky I don't think so. IMHO, the consequences of Merb Merb'a - this is so far the saddest thing that happened with Rails.
@ j3: @jashkenas can be more? / cc @topfunky
@jashkenas: @ j3 All progress stalled for two years, third Rails is largely * still * slower than the second, Bundler is a nightmare, Node.js won.
You can read the rest here if you want. I'll just give a couple of excerpts.
Translation: @tomdale Okay. For applications from scratch, I would probably choose Node. If Rails had really developed over the last 3 years, perhaps everything would have been different.
Transfer:
@jashkenas: @tomdale I agree on all points. Basically, I'm just upset that the third Rails does not look qualitatively better than the second. Same features, different API.
@josevalim: @jashkenas @tomdale if you evaluate Rails 3 only from the perspective of an application developer, then yes. but the third rails were always aimed at the plug-in developers community.
To paraphrase Jose, Rails 1 and Rails 2 were meant for application developers. Rails 3 is intended for plug-in creators and programmers who support existing applications. This is all great, but creating an application framework by ignoring application developers as the main target audience is just one of the things Rails made fun of in Java in 2006. José is one of the main developers of Rail, and he wrote a terrific book describing the incredible power of the third modular API Rail , but sometimes tweets sound louder than books.
Translation: “Node.js is the future of server applications” @wardcunningham #nodepdx
Ward Cunningham is such a sick argument .
My answer to that guy with Hacker News, who asked if he should teach Noda or Rails - the same one he would get from Jeremy Ashkenas (teach CoffeeScript - approx. Lane ): teach Noda. (Actually, I can’t speak for Jeremy, so rather learn both, but more attention was given to Noda). Sometimes it's fun to be a party-goer, and the music behind the next door is more fun now. Today, it is more important to learn Node.js, CoffeeScript and Backbone, because the work that is boiling in these communities changes paradigms. The current work with Rails lies in combing the paradigms that Rails changed in due time - however, the third Rails added as many sharp corners as they removed.
By the way, about sharp corners. The browser turns into an operating system. If you have a new version of Chrome, you can already play with the browser - based drum machine , as well as with filters, compressors and synthesizers . Of course, at the moment it may end in a browser crash, but soon everything will be awesome. Also, it is very likely that web applications will look outdated compared to mobile applications , and it will be easier for Node to benefit from this than Rails.
When you learn something new, you want it to be fun. Rails are still useful, but no longer give birth. Although they are full of awesome pieces, the air is also filled with all sorts of “what the hell? what did they even think ?! ” To rake this shit is not a pleasant pleasure. If you want to work with what will be fun, try Clojure, Scala or Node.js. Clojure and Scala work on the basis of Java, the memories of which still do not allow me to sleep at night, and Node.js implies a language to which I am having fun, despite its frequent nonsense. CoffeeScript is far from perfect, but it’s nice to write on it, because it reduces the WAT factor of JavaScript to an acceptable level of background noise.
Rails is no longer the future, but the past.
http://www.youtube.com/watch?v=WM1RChZk1EU
I think that now it is easier to find a good job with Node.js than a good job with Rails. But personally, I find it more interesting to work on my own projects, on which I also enjoy the Noda. So I am preparing a series of videos in which the creation of music will be used for teaching Node, CoffeeScript, Backbone, Socket.io and, most importantly, jasmine-node - the port of Jasmine's Javascript BDD library on Node.js. Using jasmine-node, you can perform your specs on the server in most cases (or always always tell the details in these videos), and the winnings are just awesome.
I never liked to do the specs in the browser. Instantly executing them in the command line is a great pleasure, because you can push them into continuous integration, and basically anywhere, using unix return codes. Seriously, in 2012 there are no more excuses left to not write your javascript in the style of TDD / BDD.
Returning to the javascript script machine theme, I wrote a library on Ruby called Archaeopteryx. It is a combination of a MIDI interface, a drum machine and a probabilistic breakbeat improviser. I started rewriting it in CoffeeScript. The new version is called Clyde and its code has become much cleaner.
I also prepared a couple of really fun hacks.
I chose the name Clyde partly because I was asked too many questions about how to pronounce Archaeopteryx (Archeopteryx) correctly, but mostly - in honor of the legendary drummer Clyde Stablefield - not just a tough drummer, but the coolest drummer , about whom James Brown sang - which, by the way, will be RAPPORTEUR at Madison RubyConf this year. This is the same conference that I rasssychalsya last year after saying that testing JavaScript is not necessary. I can't even tell you how excited I am.
To be fair, Ari Russo wrote a terrific Ruby MIDI library called Unimidi, which looks much better than I ever wrote, but for this project I’ll focus on JavaScript. Partly - because it seems to me more profitable to invest my time in this language, and not in Ruby (especially because I will repeat the same things that I already did in Ruby), and partly because I believe in its technological superiority .
By the way, it's not just that Clyde is easier to pronounce. Many people complained that Archeopteryx is hard to read. Despite the fact that Clyde is in active development, its source is already much easier to read. First, I had to natyrim a lot of low-level MIDI interfaces for Archeopteryx from Topher Cyll's excellent book for authorship called Practical Ruby Projects . (Later Ben Bleything rewrote them, creating a cleaner interface library called MIDIator ). On the other hand, to add MIDI support to Clyde, it was enough for me to install the excellent Node.js library and write some simplest code. Entire pieces of Archeopteryx code are devoted to the implementation of setTimeout () javascript equivalents and copying lambda to L, so that objects can be freely assigned to methods. Like how we pass functions to javascript.
Roughly speaking, JavaScript is better suited for projects of this type, because Archeopteryx uses a bunch of hacks just to get Ruby to work like JavaScript. And while JavaScript itself is pretty vigorous, CoffeScript is so beautiful that it sometimes makes Ruby look awkward.
Transfer:
@gilesboatboy: every time I see do | foo |, a little zadrot wakes up in me, wanting to kill. how to call it? zadrotognev? because “do” is completely unnecessary letters :-p
@judsonlester: if there were real macros in Ruby, then there would be no need for these letters.
@topfunky: where is my CoffeeScript for Ruby ?! let the compiler use indents, which everyone already writes, instead of useless do-end.
The guys who were playing with Clyde also liked the simple integration with Garageband, which means that any Mac user can easily and easily raise Clyde, while trying to install Archeopteryx on their computer baffled many. An open-source project that works only on the author's machine is useless.
I like the idea of ​​my videos, because they will teach advanced technologies with fun and interesting examples. They can actually become the best, most exciting way to learn modern JavaScript development. In my opinion, it is important that learning how to develop software is fun, because I want to inspire people to search for their own hacker solutions, because we remember best what we are concentrating on. This idea is permeated by our hacker languages: when we study a new technology, we say that we are “playing with it”. Tomorrow, after lunch, I will publish my first video for free, so you can look here on Friday ( here it is - approx. Lane. ).
Since this blogpost is to some extent an advertisement for these videos, and truth is important in advertising, I must admit that in fact I don’t have a rake task for scrapping eggs. And yet, I got the impression that I needed to type “bundle exec” every time I scratched my eggs, although this garbage could have been avoided with minimal knowledge of Unix paths and environment variables. (A little more whining about Bundler: if you write “bundle && foo”, you will never get to foo; it seems that Bundler does not support return codes at all).
Returning to the global problem, Rails is definitely off the rails. A clean and modular API is an important goal, but not as important as the speed of development, a modern set of features (why Rails still does not support HTML5 in the way Ajax supported at one time?) And, above all, the happiness of a programmer. The integration of Merb was a huge and time-consuming departure from the goal, which brought only a small benefit, and DHH, who wrote two whole books on why it is worth refusing to add new features, had to cut these initiatives at the root. I, nevertheless, will continue to use Rails, because they still remain a wonderful framework, but in my opinion it would be absolutely fair to say that Rails 3 took a step backward with respect to Rails 2, and Bundler, however useful it may be, is still very far from ideal. They say they have reached version 1.0, but I don’t think that anyone takes this seriously.
Update : Yehuda Katz, one of the developers of Bandler and Rail, sent me this useful piece of code :
~/Code/ember.js ‹ruby-1.9.3› ‹master*› $ bundle && echo "fuck you giles" Using rake (0.9.2.2) Using confparser (0.0.2.1) Using multi_json (1.0.4) Using execjs (1.2.13) Using libxml-ruby (2.2.2) Using faster_xml_simple (0.5.0) Using httpclient (2.2.4) Using json (1.6.5) Using nokogiri (1.5.0) Using net-github-upload (0.0.8) Using github-upload (0.0.2) Using rack (1.4.1) Using thor (0.14.6) Using rake-pipeline (0.6.0) from https://github.com/livingsocial/rake-pipeline.git (at master) Using rake-pipeline-web-filters (0.6.0) from https://github.com/wycats/rake-pipeline-web-filters.git (at master) Using sproutcore (0.0.1) from https://github.com/wycats/abbot-from-scratch.git (at master) Using uglifier (1.0.4) Using bundler (1.1.rc.7) Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed. fuck you giles Source: https://habr.com/ru/post/141295/
All Articles