Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby on Rails 4.0.0.beta1 released

weblog.rubyonrails.org

Post reply on HN
Print view View original

71–80 of 91 posts

Re: Ruby on Rails 4.0.0.beta1 released

#71

Post by abcbaby »

steveklabnik wrote: post #3

Hello everyone! I am MEGA EXCITED for this release, as it's the first version in which I'm a committer. Wooo! In addition, 954 other intrepid Rubyists in total contributed to this release: http://contributors.rubyonrails.org/edge/contributors Please note that this is a beta, not an rc, so some things may be a bit wonky. Please file an issue on GitHub and I will do everything I can to help you help us iron out all the…

As usual, you barely do anything but minor docfixes or merge other people's pull requests. Do you ever actually do substantial coding at all? or would that take too much time away from babbling on twitter and acting outraged over gender issues?

Biggest fraud ever.

Re: Ruby on Rails 4.0.0.beta1 released

#72

Post by pmarsh »

xutopia wrote: post #19
5vforest wrote: post #17

What is the "Rails way" of doing AJAX calls and updating the DOM? I've been embedding Backbone views in the parts of my app that are the most interactive, but I feel like there's gotta be a better way.

Rails 4 uses turbolinks. It is a mechanism that instead of loading a new page loads up the HTML via AJAX and replaces the entire content of the page without reloading all the resources(css, js, etc...) So instead of having to deal with plenty of small ajax calls you just build an app as it would work in plain HTML and just use turbolinks to leverage AJAX.

But if two pages have the same resource URLs for their css, js, etc they should be cached by the browser so moving from page to page shouldn't be reloading them.

This does not seem like a super great idea, like merry-christmas mentioned too much like ASP.NET.

I'll do some reading on turbolinks and see if there's something super I'm missing.

Re: Ruby on Rails 4.0.0.beta1 released

#73

Post by FooBarWidget »

jotto wrote: post #2

does threadsafe and ruby 2.0 mean we can create multiple instances with something like unicorn without forking the entire codebase?

You can already run multiple instances of Unicorn. In fact, Unicorn is designed to be a multi-process app server. When running multiple (single-threaded) processes you don't need to be thread-safe. This is the process model that Mongrel and (open source) Phusion Passenger use as well.

But what you probably meant with "multiple instances" is "multiple threads". You can't do multiple threads with Unicorn, it's explicitly designed not to handle multithreading. Instead you should use an app server that's capable of multithreading, e.g. Phusion Passenger Enterprise 4 which is hybrid multi-process/multithreaded.

The Phusion Passenger Enterprise 4 multithreaded stack is already being tested or used in production by multiple organizations. We've been using it in production for months without problems.

Also, multithreading does not require Ruby 2.0. Ruby 1.9 works just fine.

Re: Ruby on Rails 4.0.0.beta1 released

#74

Post by FooBarWidget »

nefasti wrote: post #24
atambo wrote: post #5

Earlier quoted context omitted.

Ruby 2.0 still has the GIL so if you want to run a threaded web server you'll still need to be using rubinius or jruby.

Any reason ruby still has the GIL and not moved to a thread implementation?

The GIL makes a lot of things in the Ruby interpreter much easier to implement.

Re: Ruby on Rails 4.0.0.beta1 released

#75

Post by FooBarWidget »

jeltz wrote: post #61
jotto wrote: post #2

does threadsafe and ruby 2.0 mean we can create multiple instances with something like unicorn without forking the entire codebase?

Ruby 2.0 means less memory usage with unicorn since the GC in Ruby 2.0 is copy on write friendly.

Memory savings would be similar to when you used Phusion Passenger or Unicorn in combination with Ruby Enterprise Edition, which also has a copy-on-write friendly GC.

Re: Ruby on Rails 4.0.0.beta1 released

#76

Post by FooBarWidget »

andrewvc wrote: post #4
jotto wrote: post #2

does threadsafe and ruby 2.0 mean we can create multiple instances with something like unicorn without forking the entire codebase?

Funny thing about unicorn is, forking is core to its design. It may handle threading now, but when I last looked at its code fork() and traditional IPC via signals were core to its operation. Puma looks like the more thread-oriented choice these days.

Unicorn does not handle threading now. :) It never had, and according to its author never will.

Phusion Passenger Enterprise 4 is also thread-oriented.

Re: Ruby on Rails 4.0.0.beta1 released

#77

Post by steveklabnik »

ctide wrote: post #44
jaggederest wrote: post #9

Earlier quoted context omitted.

Proud to be on the contributor list for this one - any of you considering contributing, it's not hard at all, the team makes it really easy.

I submitted my first contribution, but I never got a response: https://github.com/rails/rails/pull/8903 :( I suppose it's a lot less of an issue now anyways, but in 3.2, using fetch with memcache with raw objects is super gross since you get totally incompatible responses depending on whether an item existed in cache or not.

Sorry about that. :/

I personally read every single issue, comment, and commit that goes into Rails. But often tickets come up that I don't know anything about, so I don't say anything. This suggestion is one of them; I'm not mega familiar with that part of the codebase.

Re: Ruby on Rails 4.0.0.beta1 released

#78

Post by steveklabnik »

jaggederest wrote: post #52
timdorr wrote: post #40

Earlier quoted context omitted.

Is there any sort of prioritized TODO list, either by difficultly or importance? And that's not so I can knock out some big feature and be the hero, but so I can whittle away at some of the more nagging edge cases and make some random developers day when things just work.

The issues page is the best you have for that, sort by popularity or something like that. That's one of the only things I'm frustrated about - I wish there were a clearer list so that I didn't have to troll for tasks that need doing, or ask a core member on IRC/campfire

Every single issue is something that needs doing. We only keep bugs on the tracker, I'm pretty diligent about shutting them down.

Re: Ruby on Rails 4.0.0.beta1 released

#79

Post by steveklabnik »

timdorr wrote: post #40
jaggederest wrote: post #15

Earlier quoted context omitted.

In my opinion the easy way is to look through the github issues and pull requests and understand what's going on. From there, try reading docs and seeing what does / doesn't make sense and editing it. You pretty much always get feedback if you send a decently put together pull request. Look for places the code might not currently be clear, and try to improve clarity without changing behavior. Once you've done that ki…

Is there any sort of prioritized TODO list, either by difficultly or importance? And that's not so I can knock out some big feature and be the hero, but so I can whittle away at some of the more nagging edge cases and make some random developers day when things just work.

I'd love for you to whittle away at nagging edge cases!

One of the most common places where that's true is in the ActiveRecord issues, which are about half of the open ones: https://github.com/rails/rails/issues?direction=asc&labe...

Even just making a little Rails app or script that re-produces the bug would be helpful. Writing a test case that's failing would be mega helpful. Fixing the bug would be incredibly helpful. :)

Re: Ruby on Rails 4.0.0.beta1 released

#80

Post by steveklabnik »

_frog wrote: post #68
steveklabnik wrote: post #26

Earlier quoted context omitted.

It just so happens that one of my major contributions to this release was writing a 'working with JavaScript in Rails' guide: http://edgeguides.rubyonrails.org/working_with_javascript_in... Others mentioned Turbolinks, but they forgot about remote_form_for and friends. If you _are_ building a full JavaScript application, Ember.js works really well with Rails + ActiveModel::Serializers. There might be some rough patch…

Just want to chime in and say how fantastically ActiveModel::Serializers and the Ember.js REST adapter work together. I built a project with them over the weekend and the experience was overwhelmingly frictionless to a degree I hadn't experienced doing this kind of thing in the past.

Thanks. I've been kinda ignoring AMS in order to get this release out the door, but now that it's out, expect to see much more soon...
Post reply on HN