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

11–20 of 91 posts

Re: Ruby on Rails 4.0.0.beta1 released

#11

Post by habosa »

jaggederest wrote: post #9
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…

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.

Any pointers for getting started?

Re: Ruby on Rails 4.0.0.beta1 released

#12

Post by jrochkind1 »

atambo wrote: post #5
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 still has the GIL so if you want to run a threaded web server you'll still need to be using rubinius or jruby.

ONLY if it's important to you that one process be able to run multiple threads on multiple CPU cores concurrently.

Even without this, there are MANY use cases where multi-threaded concurrent request dispatch makes a LOT of sense. For instance, the recent controversy about heroku routing, right?

With MRI or another interpreter with the GIL, you'd want to run one app process per CPU core -- but having each of those processes also do multi-threaded request handling can still even out latency (that is, avoid those awful ~95th+ percentile latencies in the heroku routing debacle), and increase overall throughput.

Especially if your app, like most but not all web apps, is more I/O bound than CPU bound (waiting on DB, disk, or external APIs).

Re: Ruby on Rails 4.0.0.beta1 released

#13

Post by steveklabnik »

habosa wrote: post #11
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.

Any pointers for getting started?

We have a guide here: http://edgeguides.rubyonrails.org/contributing_to_ruby_on_ra...

If there is anything I can do to make this more clear, please let me know. Documentation is something I enjoy.

Re: Ruby on Rails 4.0.0.beta1 released

#14

Post by andyl »

jrochkind1 wrote: post #10
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?

I'm not sure what you mean by 'forking the entire codebase'. Even if Rails3, though, Rails supported multi-threaded request dispatching IF you had an app server stack that supported it. In Rails3, you just had to explicitly turn it on with `config.threadsafe!`. Rails4 makes that the default, always on. That's really the only difference. There are at least a few concurrency-related bugs that have been fixed in Rails4…

> Finding a mature, reliable, well-documented app server stack that supports multi-threaded concurrent request dispatch may be harder.

Try Jruby and Puma.

Re: Ruby on Rails 4.0.0.beta1 released

#15

Post by jaggederest »

habosa wrote: post #11
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.

Any pointers for getting started?

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 kind of thing, sky's the limit as far as I am concerned. I'm working on understanding and improving the parameter parsing behavior at the moment.

Re: Ruby on Rails 4.0.0.beta1 released

#16

Post by newhouseb »

I'm not a rubyist but I'm really excited for the russian-doll caching and really hope it catches on in other frameworks. Data dependency tracking makes everything from straight-up caching to real-time updates effortless and I think is one of the few places where an ORM can be really helpful (queue the two hard problems quote about cache-invalidation and naming things). Quora has been doing this since the beginning and I'm surprised it hasn't caught on in other open source (namely python) frameworks to the same degree, hopefully RoR will add some fuel to the fire.

Re: Ruby on Rails 4.0.0.beta1 released

#18

Post by awj »

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.

According to recent discussions, turbolinks. It's built into Rails 4 and essentially works by making a call out to the server to fetch raw html and replacing some/all of the DOM with the result.

Personally I just use Backbone and try to structure things in whatever way seems natural. It looks like there's been a lot of work done in integrating Ember.js if you want to look into that.

Re: Ruby on Rails 4.0.0.beta1 released

#19

Post by xutopia »

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.

Re: Ruby on Rails 4.0.0.beta1 released

#20

Post by JuDue »

awj wrote: post #18
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.

According to recent discussions, turbolinks. It's built into Rails 4 and essentially works by making a call out to the server to fetch raw html and replacing some/all of the DOM with the result. Personally I just use Backbone and try to structure things in whatever way seems natural. It looks like there's been a lot of work done in integrating Ember.js if you want to look into that.

Turbo links is more suited to traditional web pages.

Backbone for single page mini-apps.

Post reply on HN