Rails 3 : Vaporware To Awesome(slideshare.net)
slideshare.net
Rails 3 : Vaporware To Awesome
http://www.slideshare.net/wycats/vaporware-to-awesome
51 comments
Video:
http://sdruby.org/video/075_rails3.m4v (366 MB)
The sound quality on that is.. unbearable.
I second this! I also looked at the other video's SDRuby has up, and all of them I have tested are also horrible. If someone from SDRuby is here, FIX YOUR AUDIO!! It sounds like my dad's AM talk radio going through a tunnel!
I would also like a fix. It sounds like someone simply encoded the video with way too strong audio-compression - the original material is probably fine.
I'm very interested in the talk but it's near impossible to understand him and the warbling noise gives me instant-headache. No way for me to consume it as it is.
I'm very interested in the talk but it's near impossible to understand him and the warbling noise gives me instant-headache. No way for me to consume it as it is.
It seems it has been fixed, I watched it last week and recheck it today, far easier to understand.
Rails 3 is going to be so cool. It looks like they're expanding on the features relating to Rack, which is going to open so many possibilities. Kudos to the Rails team!
I have to say, this looks like a major step up. The performance benchmarks are very impressive on their own, so that Rails 3 is also more flexible and easy to configure is great.
The thing that excites me most is that Rails is moving to jQuery with "unobtrusive javascript" for all of the ajax helpers. Currently, its Prototype with inline spaghetti code.
Most excited about the new router - doing subdomain and custom domain support is a hack in Rails 2.3
Looks like an awesome web framework. Rails blew my mind when I first learned it, but over the course of the last two years the various warts and inconsistencies have become apparent.
I look forward to learning this new web framework that is also called ruby on rails ;-)
I look forward to learning this new web framework that is also called ruby on rails ;-)
That's how I've felt about it too. Back when it came out, Rails was very easy to fit into your brain in the course of a day or two of absorption, but now it's a very large collection of ideas, DSLs and overall lingo. It's probably more than a little bit overwhelming to newcomers, and even some of those of us who come back to it every year and scratch our heads in awe at just how big the Rails universe has become.
I also hope that Rails 3 will cut down some of the noise for newbies and oldies alike.
I also hope that Rails 3 will cut down some of the noise for newbies and oldies alike.
The thing I like about Rails is, unlike some technology stacks I could name (why hello there Enterprise Java), you don't have to know it all on day one. The first version of my site was an awful lot like Baby's First Bookstore, Rails 2007 Edition. It has gradually accumulated more features and sophistication as I've grown as a web programmer.
A lot of the complexity in Rails is hidden until you need it. If you don't understand Rails caching yet, that's no problem, you don't have to understand it until you actually have to use it. Ditto the more advanced ActiveRecord tricks like named_scope, or the deep rabbit holes in the general vicinity of templating engines.
A lot of the complexity in Rails is hidden until you need it. If you don't understand Rails caching yet, that's no problem, you don't have to understand it until you actually have to use it. Ditto the more advanced ActiveRecord tricks like named_scope, or the deep rabbit holes in the general vicinity of templating engines.
The term I like (don't know where I picked it up) is "discoverable." The simple things are easy, but you can discover over time how to do the complex things. This has two benefits: the obvious benefit is that it allows the user to be productive immediately, without training, without having to memorize a manual. The "hidden" benefit is that the program becomes an adventure game... it continues to surprise, delight, and reward the user long after the excitement of the initial purchase has faded.
IMHO, this is Apple's "secret sauce." Their hardware and software is just hardware and software, it can be mimicked. The thing that sets their hw/sw apart is its discoverability, and that is very, very hard to copy because it is a thought process, a concept, a zen.
Jason Fried makes this point in SvN: http://37signals.com/svn/posts/1561-why-you-shouldnt-copy-us... (with a recursive reference to HN http://news.ycombinator.com/item?id=469940 :-).
IMHO, this is Apple's "secret sauce." Their hardware and software is just hardware and software, it can be mimicked. The thing that sets their hw/sw apart is its discoverability, and that is very, very hard to copy because it is a thought process, a concept, a zen.
Jason Fried makes this point in SvN: http://37signals.com/svn/posts/1561-why-you-shouldnt-copy-us... (with a recursive reference to HN http://news.ycombinator.com/item?id=469940 :-).
Looks really cool. It's definitely not cool though that Yehuda's keeps saying things like "Sinatra has failed because...", and "because Prototype sucks..." and so on. I'm only half way through the video, but it really bothers me when smart software developers disparage other open source projects that came before the latest shiny framework or tool. Especially when it's to brag about whatever project it is that they're currently working on. It's childish, rude, and basically makes you look like a dick no matter how whiz bang cool or better what you're currently working on actually is.
Some day, Rails 3.0 will be old news and I'm sure he won't appreciate it when some young kid gets on stage saying "Rails 3.0 sucked, how could they have been so stupid?! Look how much better my code is!"
Give credit where credit is due -- and remember we all stand on the shoulders of giants, show a little respect, eh?
Some day, Rails 3.0 will be old news and I'm sure he won't appreciate it when some young kid gets on stage saying "Rails 3.0 sucked, how could they have been so stupid?! Look how much better my code is!"
Give credit where credit is due -- and remember we all stand on the shoulders of giants, show a little respect, eh?
Yehuda didn't simply say that Sinatra failed. What he said was that Sinatra (and other similar projects) failed to achieve a critical mass of support. The reason for this failure was because these projects were trying to do fundamentally different things than what most people were actually doing with Rails at the time, and as a result, they didn't catch on.
This statement was made in comparison to merb, which succeeded in getting more mindshare than the other 'Rails competitors.' This was largely because merb attempted to do much the same things that Rails was trying to do, but to do them in a much better way.
He was indirectly positive about Sinatra throughout his talk, and when covering router changes, kept describing how you could mount Sinatra applications inside of your Rails3 app.
The "prototype sucks comment" was made along with a very tongue-in-cheek "everyone will move to jquery" comment. He was laughing when he said it, and I got the impression that he was simply making a joke as the author of jquery.
He never once said anyone was stupid. Actually, that's not entirely true, he was pretty critical about some of the code found in Rails 2.x. He backed his criticism up by showing the code, and I certainly didn't think he was out of line.
This statement was made in comparison to merb, which succeeded in getting more mindshare than the other 'Rails competitors.' This was largely because merb attempted to do much the same things that Rails was trying to do, but to do them in a much better way.
He was indirectly positive about Sinatra throughout his talk, and when covering router changes, kept describing how you could mount Sinatra applications inside of your Rails3 app.
The "prototype sucks comment" was made along with a very tongue-in-cheek "everyone will move to jquery" comment. He was laughing when he said it, and I got the impression that he was simply making a joke as the author of jquery.
He never once said anyone was stupid. Actually, that's not entirely true, he was pretty critical about some of the code found in Rails 2.x. He backed his criticism up by showing the code, and I certainly didn't think he was out of line.
"This was largely because merb attempted to do much the same things that Rails was trying to do, but to do them in a much better way."
Or maybe because Merb was done by people already hooked into the Rails community, and so could more easily get the attention of developers who don't otherwise seem interested in exploring other frameworks?
Nitro, for example, predated Merb (it came out at the same time as Rails) and was doing many things better than Rails (multi-threaded, easy to swap out ORMs, no boinking of built-in classes, Rack-like app request processing pipeline before there was Rack; much faster overall), but got almost zero traction. And I don't think it was because people tried it and didn't care for it, but because all the noise was (rather deliberately) about Rails.
There is a "winner takes all" mentality among some Rubyists that leads them to dismiss anything that isn't the clear leader. Sort of like high school kids who are afraid to be seen talking to the nerds because people might think them uncool.
Or maybe because Merb was done by people already hooked into the Rails community, and so could more easily get the attention of developers who don't otherwise seem interested in exploring other frameworks?
Nitro, for example, predated Merb (it came out at the same time as Rails) and was doing many things better than Rails (multi-threaded, easy to swap out ORMs, no boinking of built-in classes, Rack-like app request processing pipeline before there was Rack; much faster overall), but got almost zero traction. And I don't think it was because people tried it and didn't care for it, but because all the noise was (rather deliberately) about Rails.
There is a "winner takes all" mentality among some Rubyists that leads them to dismiss anything that isn't the clear leader. Sort of like high school kids who are afraid to be seen talking to the nerds because people might think them uncool.
I haven't had a chance to watch the video yet, but one correction - John Resig is the original author of jQuery, Yehuda is on the core team.
One thing I've learned over the years is that there is a certain level of tact one needs to have when talking about other peoples' work. It's very easy for people to be offended when you talk about things they've worked on negatively. As I've matured as a software engineer I've come to realize that no, my code is not a beautiful unique snowflake, and yes, I am probably the dumbest guy in the room.
This means that generally I've shifted from the thinking "this other person's code is shit" to "I'm betting there was a reason they did it this way." As it turns out, there almost always is. With the benefit of hindsight, those reasons can sometimes seem foolish, but that's the thing about hindsight. More often than not though, once I take the time to understand them, the decisions of the original author turn out to be better than my knee-jerk response.
When your overall attitude is still in the "everyone else's code sucks" mindset it leaks out through your language, and I think that's what is happening here, however slightly. There is no reason to use the word "failed" or use the word "sucks" when talking about another person's work, particularly when it's work that people are using in production for free and work that is open sourced, like Sinatra or Prototype. Even moreso when you're promoting an iteration of improvements on a platform that benefits from the work and experience of many man-months of volunteers, an iteration that is still not even released yet.
This means that generally I've shifted from the thinking "this other person's code is shit" to "I'm betting there was a reason they did it this way." As it turns out, there almost always is. With the benefit of hindsight, those reasons can sometimes seem foolish, but that's the thing about hindsight. More often than not though, once I take the time to understand them, the decisions of the original author turn out to be better than my knee-jerk response.
When your overall attitude is still in the "everyone else's code sucks" mindset it leaks out through your language, and I think that's what is happening here, however slightly. There is no reason to use the word "failed" or use the word "sucks" when talking about another person's work, particularly when it's work that people are using in production for free and work that is open sourced, like Sinatra or Prototype. Even moreso when you're promoting an iteration of improvements on a platform that benefits from the work and experience of many man-months of volunteers, an iteration that is still not even released yet.
> It's definitely not cool though that Yehuda's keeps saying things like "Sinatra has failed because..."
Agreed. That's apples and oranges! Rails and Sinatra are different tools for different problems, IMO.
Agreed. That's apples and oranges! Rails and Sinatra are different tools for different problems, IMO.
> That's apples and oranges! Rails and Sinatra are different tools for different problems, IMO.
Actually no. With rails3, rails will just be a meta gem. If you install rails-core you'll get something like Rack plus not much more which is basically what sinatra is.
Actually no. With rails3, rails will just be a meta gem. If you install rails-core you'll get something like Rack plus not much more which is basically what sinatra is.
Ah, looks like I have some Rails 3 learnin' to do! Thanks! :)
Some day, code will be old news and I'm sure you people won't appreciate it when some young kid gets on stage saying "textual non-interactive computer code sucked, how could they have been so stupid?".
Rails 3 is waayy faster and better then. Rails in general is great. Its really got the abstraction thing and taking into consideration crazy things like developments in software engineering practices and programming languages.
Having said that, I don't really know much about Rails. This comment is not about Rails. I just have to tell people because I keep thinking about something and almost no one seems to get it and realistically I am probably never going to follow through with it so if I can't communicate this idea it might not go anywhere. And with all of the positive progressive things Rails developers are doing, maybe, just maybe someone reading this will get what I am talking about.
Basically, I keep thinking, especially just now when I was looking at that Rails code in his slides, the way everything is so well abstracted and so _structured_, and how he keeps going to the model with the circles connecting, and how we keep repeating keywords all over the place, and how no one ever wants to look at unsyntaxhighlighted code anymore, I have to say _again_, one-dimensional non-interactive (or two dimensional if you insist on calling it that) textual representations of software are outdated and unnecessary now.
Sure, we do still have to type a lot of text in, and I am not trying to throw out my keyboard, or stop thinking or something. But there just really isn't any reason we have to be limited to text on a daily basis anymore. People just have a cognitive bias towards the status quo which is preventing them from taking the step to add a layer of two-dimensional widgets or something over the code. I am talking about code generating widgets, or intentional software, or a generic interactive graphical representation for function calls, control flow, model development. Things like that.
Because basically a lot of code, even the things that involve a lot of abstractions with embedded textual mini-languages in them, are mostly mapping from one thing to another. Doing transformations on structures. Code-completion is a start, but what we really want are more useful iteractions with the models and algorithms. The way forward is things like code generation, projectional editing, live coding, dynamic evaluation and representation (widgets) etc. Anything that provides more interactivity to the software development process is where we should be going.
And the next big step is to get out of the limitation of using textual code as the default editing level. Often times we are basically configuring/connecting functions/components, editing models, or using text to generate two dimensional features like tables/grids, UI forms, sometimes mathematical functions, or dynamic systems that we really need to interact with at runtime with dynamic graphical editors to manipulate and comprehend properly. So we should start on the two-dimensional, graphical level. Also, downloading open source projects whose claim to fame is completeness and ease of integration and then reading documentation which amounts to what commands to enter on the command line and then cutting and pasting and editing configuration text files in terminal windows is not cutting it anymore. There are these things called (graphical?) components. We can accomplish this with things like projectional editors, or even more simply by interacting with widgets that generate code. And yes, I know what LabView is, and no, that tool and other attempts at visual programming systems haven't proven anything. Its just hard to get these types of tools to be as generic as text-only systems, especially fully integrating keyboard and text use, AND, the number one hindrance, I believe, is status quo bias like loss aversion.
Having said that, I don't really know much about Rails. This comment is not about Rails. I just have to tell people because I keep thinking about something and almost no one seems to get it and realistically I am probably never going to follow through with it so if I can't communicate this idea it might not go anywhere. And with all of the positive progressive things Rails developers are doing, maybe, just maybe someone reading this will get what I am talking about.
Basically, I keep thinking, especially just now when I was looking at that Rails code in his slides, the way everything is so well abstracted and so _structured_, and how he keeps going to the model with the circles connecting, and how we keep repeating keywords all over the place, and how no one ever wants to look at unsyntaxhighlighted code anymore, I have to say _again_, one-dimensional non-interactive (or two dimensional if you insist on calling it that) textual representations of software are outdated and unnecessary now.
Sure, we do still have to type a lot of text in, and I am not trying to throw out my keyboard, or stop thinking or something. But there just really isn't any reason we have to be limited to text on a daily basis anymore. People just have a cognitive bias towards the status quo which is preventing them from taking the step to add a layer of two-dimensional widgets or something over the code. I am talking about code generating widgets, or intentional software, or a generic interactive graphical representation for function calls, control flow, model development. Things like that.
Because basically a lot of code, even the things that involve a lot of abstractions with embedded textual mini-languages in them, are mostly mapping from one thing to another. Doing transformations on structures. Code-completion is a start, but what we really want are more useful iteractions with the models and algorithms. The way forward is things like code generation, projectional editing, live coding, dynamic evaluation and representation (widgets) etc. Anything that provides more interactivity to the software development process is where we should be going.
And the next big step is to get out of the limitation of using textual code as the default editing level. Often times we are basically configuring/connecting functions/components, editing models, or using text to generate two dimensional features like tables/grids, UI forms, sometimes mathematical functions, or dynamic systems that we really need to interact with at runtime with dynamic graphical editors to manipulate and comprehend properly. So we should start on the two-dimensional, graphical level. Also, downloading open source projects whose claim to fame is completeness and ease of integration and then reading documentation which amounts to what commands to enter on the command line and then cutting and pasting and editing configuration text files in terminal windows is not cutting it anymore. There are these things called (graphical?) components. We can accomplish this with things like projectional editors, or even more simply by interacting with widgets that generate code. And yes, I know what LabView is, and no, that tool and other attempts at visual programming systems haven't proven anything. Its just hard to get these types of tools to be as generic as text-only systems, especially fully integrating keyboard and text use, AND, the number one hindrance, I believe, is status quo bias like loss aversion.
That way lie frameworks such as Visual Studio, Visual Studio, Delphi, PowerBuilder, Oracle Developer, SQL Server Studio, various CASE tools, etc. All good products that remind us that the road to Hell is paved with good intentions.
While often excellent, these frameworks usually disappear (or morph to new incompatible forms) within a decade leaving behind cast-off skeletons, the underlying code they generated, to be maintained for decades to come.
Programmers seek security in a lingua franca, a common level of coding/specification that they are comfortable with and that they believe will remain useful as long as possible. The programming language level seems to be the sweet spot today. It is no accident that most frameworks generate code at the programming language level.
While often excellent, these frameworks usually disappear (or morph to new incompatible forms) within a decade leaving behind cast-off skeletons, the underlying code they generated, to be maintained for decades to come.
Programmers seek security in a lingua franca, a common level of coding/specification that they are comfortable with and that they believe will remain useful as long as possible. The programming language level seems to be the sweet spot today. It is no accident that most frameworks generate code at the programming language level.
Tools like PowerBuilder etc. are enhanced over time and evolve. The old applications built with those tools have to be either maintained with the old versions of the tools or converted/ported to the newer platforms. Oftentimes the underlying source code is using older libraries also and quite possibly outdated language features.
I'm not sure I have ever really sought security in any particular programming language or version. Also, when you say "the programming language level" -- some languages evolve very quickly, and from one project to the next, even though it is basically the "same" language sometimes requires developers to learn very different ways of doing things. C (from procedural to object-oriented) or C# and its rapid changes are examples.
Since we are starting with the machine hardware level there must be some route from the representation closest to the problem domain to that level. So we generate code for the next lowest level. A 4GL editor generates 3GL code and 3GL compiler generates 2GL code and a 2GL assembler generates 1GL (machine) code.
I guess I don't feel like the 4GL (or call them 5GL if you want) tools have the capabilities we need to be able to throw out the 3GL, and I want to throw it out, or at least use it much, much less.
I'm not sure I have ever really sought security in any particular programming language or version. Also, when you say "the programming language level" -- some languages evolve very quickly, and from one project to the next, even though it is basically the "same" language sometimes requires developers to learn very different ways of doing things. C (from procedural to object-oriented) or C# and its rapid changes are examples.
Since we are starting with the machine hardware level there must be some route from the representation closest to the problem domain to that level. So we generate code for the next lowest level. A 4GL editor generates 3GL code and 3GL compiler generates 2GL code and a 2GL assembler generates 1GL (machine) code.
I guess I don't feel like the 4GL (or call them 5GL if you want) tools have the capabilities we need to be able to throw out the 3GL, and I want to throw it out, or at least use it much, much less.
There is probably a lively discussion or possibly a flamewar to be had on your topic. Unfortunately, it is totally unrelated to the topic of this thread. If you want to talk about this other thing, why not post it on a blog and submit to HN?
[deleted]
Here is where I posted it on a blog and submitted it to HN 230 days ago. It received like 0 upvotes and 1 comment that didn't say much of anything. 2D programming via composed code-generating widgets
http://news.ycombinator.com/item?id=569349
Is there an online multiuser environment for coding/interacting with widgets? http://news.ycombinator.com/item?id=670228
Is there an online multiuser environment for coding/interacting with widgets? http://news.ycombinator.com/item?id=670228
One thing to push this forward would be to have a standard set of visual "atoms". Right now text editors all share the same "atoms", which are characters. If there were a standard set of visual atoms then you would get generic visual editors and there would be more reason to work within this shared visual language.
This reminds me of the Atlas connections interface. (see screencast: http://280atlas.com/what.php)
How does that compare to your vision?
How does that compare to your vision?
Right, binding properties on components to other components' properties or to code through visual drag-and-drop operations is the right direction I think. I would like to go further, with finer-grained components, all the way down to the code level, so even when we are building components, we are building them out of interactive two-dimensional widgets/models or something. I think it would be easier to interact with branching statements, function calls or classes or some more appropriate abstraction using some type of two-dimensional interactive widgets rather than having to type code.
Also, I am not sure what the best approach is, but I think we can go beyond even the ability to connect properties on components. Not sure if it needs to be as complex as projectional editors like Intentional Software is creating or if maybe in some ways that might be more complex than we want. Here is one idea I had awhile ago. (Just an idea, certainly doesn't represent a vision or anything http://ilaksh.wordpress.com/2009/04/19/2d-programming-via-co...)
I also think that real-time collaborative environments are a huge boost.
Also, I am not sure what the best approach is, but I think we can go beyond even the ability to connect properties on components. Not sure if it needs to be as complex as projectional editors like Intentional Software is creating or if maybe in some ways that might be more complex than we want. Here is one idea I had awhile ago. (Just an idea, certainly doesn't represent a vision or anything http://ilaksh.wordpress.com/2009/04/19/2d-programming-via-co...)
I also think that real-time collaborative environments are a huge boost.
When is Rails 3 going to be released and where do I download the current (unstable?) Rails 3 version?
The latest Rails is at GitHub: http://github.com/rails/rails/
As for the release date: "[T]he Rails 3 release date will likely be in the first quarter of 2010, or even before Christmas 09 if things go really well." (http://railsnotes.com/745-rails-3-release-date-news/)
As for the release date: "[T]he Rails 3 release date will likely be in the first quarter of 2010, or even before Christmas 09 if things go really well." (http://railsnotes.com/745-rails-3-release-date-news/)
Alpha release maybe. I'd estimate at least 6 months between the first alpha release and the final. Yehuda's been pretty clear that he wants all the plugins to be updated and working with the new public api before they go final on 3.0
Every year I have this realization that I need to put a week aside and re-lean Rails because it changes so fast. But I'll take that any time over a framework that just atrophies.
I have always liked how Merb was structured. With Rails 3 is there any reason to use Merb for new projects?
No, Rails 3 is also Merb 2.
http://yehudakatz.com/2008/12/23/rails-and-merb-merge/
http://yehudakatz.com/2008/12/23/rails-and-merb-merge/
Am I the only one who perceives minimal value from slideshare. Without context, slides are pretty useless. I'm not saying Yehuda's presentation wasn't good. I did not see his presentation. I am saying, the slides have little value without an explanation of the slides.
So if you're new to rails, is it better to learn rails 2.x and move to 3.0 later, or to just learn 3.0 now?
2.3. The public API supposedly won't change much. There are a lot of internal changes that will make a lot of new things possible on the public side, but they have said they plan to support the existing Rails 2.3 public API in Rails 3.