Rails 4.1.0 beta1 released

http://weblog.rubyonrails.org/2013/12/18/Rails-4-1-beta1/

by chancancode • 13 years ago

194 57 13 years ago

weblog.rubyonrails.org

andyl• 13 years ago

Thank you Rails team - lots of useful stuff here.

Really like the six-month release pace.

annon• 13 years ago

Great new practical features. I can literally use every one of these, and many of them I've already been handling by rolling my own or using a gem.

Surprised to see enum support finally come to activerecord.

alxndr• 13 years ago

note that it's not "real" enum support

steveklabnik4• 13 years ago

  > This new release also follows our new policy of targeting a minor release every
  > six months. The idea being that the jump from minor to minor shouldn't try to
  > include everything under the sun. Just whatever is ready after the six month
  > mark.

EDIT: I have been misinformed. I didn't participate a lot in this release, and I missed some discussion. If you read my previous comment, I mentioned this was a policy change, which isn't technically true. Anyway, on to what is true:

People have always complained that upgrading Rails has been difficult, we want to make that better. Releasing often will help us make a smoother upgrade path, which should help with these issues.

mscarborough2• 13 years ago

Thanks for the work, looks exciting!

In addition to taking the pressure off of the rails team/community a bit, now you don't have to postpone til the next great feature can be included. I'm sure that devs knowing that what is left out now will probably be there in six months will help their planning and decision-making processes.

gfodor• 13 years ago

wow, the action mailer preview thing is one of those things you're amazed didn't exist until now. i remember rigging this up manually a few times after getting sick of sending a million test emails to myself. great work rails team!

mikeatlas• 13 years ago

The letter_opener gem is pretty handy to avoid that: https://github.com/ryanb/letter_opener

Or, you could easily just create controller actions which render your emails as well:

@body = mail.body.parts[1].html_part.body.raw_source

render '/mailer_notification/preview.html', :layout => false

And in preview.html.erb: <%= raw(@body) %>

joshdotsmith• 13 years ago

37signals actually has a gem called mail_view that I've been using to preview mailers: https://github.com/37signals/mail_view

Glad this made it into Rails itself.

And if you've ever wanted to put inline CSS into emails, roadie will help with that: https://github.com/Mange/roadie

dboyd• 13 years ago

Hat-tip to roadie. I am absolutely amazed at how well it works, and how much work it removes in producing HTML emails.

alexvay• 13 years ago

What is the template engine used to parse https://github-camo.global.ssl.fastly.net/c58b91097c12fa39e4... ?

purephase• 13 years ago

I used mailcatcher. It's pretty awesome for this stuff, but glad to see it in core.

danso2• 13 years ago

In fact, we're already running beta1 in production for Basecamp, so you know it's been taking a good beating. This helped us catch a couple of performance regressions, and we've verified that everything is still spiffy fast on Basecamp.

Wow. Well, having enough faith to run Basecamp off of it -- and the fact that 4.0 was a very smooth transition from 3.2 -- is enough reason to play around with this beta for a project.

Edit: nevermind, don't think I can handle this feature removal: https://github.com/rails/rails/commit/c300dca9963bda78b8f358...

steveklabnik4• 13 years ago

I don't work at 37signals, but it's my understanding that Basecamp has often been running near HEAD Rails. Everyone on the team tries to keep some apps running on edge before a release to catch regressions.

whalesalad3• 13 years ago

Wow. These are STELLAR improvements! Check out the release notes here: https://github.com/rails/rails/blob/master/guides/source/4_1...

So excited about all of it. Native enum is a blessing.

Took me a while to figure it out but here is the required line for your Gemfile:

    gem 'rails', '4.0.1.beta1'
    
    # This works too, but isn't required (thanks to cantoniodasilva's comment below)
    # gem 'rails', github: 'rails/rails', tag: 'v4.1.0.beta1'

Booya! Very excited to put it through the paces of this new app I am working on.

cantoniodasilva• 13 years ago

You should be able to point the gem to '4.1.0.beta1' too, instead of relying on the git tag.

whalesalad3• 13 years ago

Good to know, thanks.

Note to the Rails team: might want to add this to your blog post and/or release notes?

Perhaps I am the only person in the world who did not realize this would work. #noob

chancancode3• 13 years ago

We pushed a build to RubyGems.org[1], so you should be able drop the github option now:

    gem 'rails', '4.1.0.beta1'

We upgraded a few apps in our local Ruby meetup group lately[2], and it's worth mentioning that you might need to upgrade the following gems too:

    gem 'rspec', '~> 3.0.0.beta1'
    gem 'rspec-rails', '~> 3.0.0.beta1'
    gem 'capybara', '~> 2.2.0'
    gem 'jquery-rails', github: 'takkanm/jquery-rails', branch:' fix_action_view_require'
    (I'm not 100% sure about the last one, might have been fixed since I last checked)

I'll try to write this up in another blog post tomorrow.

[1] http://rubygems.org/gems/rails/versions/4.1.0.beta1

[2] http://www.meetup.com/vancouver-ruby/messages/61805312/

Edit: minor formatting fixes

jenseng• 13 years ago

It's a shame these aren't actual database ENUMs, but rather ints (with the mapping in ruby land): https://github.com/rails/rails/commit/db41eb8a6ea88b854bf5cd...

Even a text column would be preferable IMO ... you wouldn't need to worry about remapping if a value got removed, it's more easily queryable, and it's certainly more legible if you're looking at raw data (say, via psql). Plus you probably won't really save much (any?) space with an (64-bit) int.

whalesalad3• 13 years ago

I agree with all of your points, but I don't think it's a shame. It's an awesome contribution and will make my work a lot easier on future projects. I'm personally going to try and take a stab at implementing this with strings versus ints though, since I agree you don't really save much by using the int and it's much friendlier for debug and future changes.

yxhuvud• 13 years ago

Considering the sad state of mysql enums with the pitfalls it have, it really isn't a shame.

I totally agree that a text column would have been preferable though.

dwaltrip• 13 years ago

You can specify a smaller int size, I used 2-byte ints fairly often. Saves a good amount of space. This also makes it really easy to change the corresponding name of a value/categorization (no migration needed).

clarkdave• 13 years ago

Native "enums" (types) in PostgreSQL are a mixed bag. They do have some advantages:

- you can treat them like strings (e.g. `SET status = 'approved'`, but they are a fixed size (four bytes)

- when queried they appear as strings too. Nice for debugging

- if you enter an invalid value (anywhere, not just in Rails) PG will throw a wibbly

But the biggest problem with enum types is if/when you want to add a new value to an enum type, it's annoyingly non-trivial. You can't run `ALTER TYPE ... ADD` because it doesn't work in a transaction. [0]

Instead you need to drop the type, recreate it (with the new value) and then alter all the tables that use this type. If you have a huge DB this can get a bit silly, although you can at least do it all in a transaction.

It is fairly trivial to add support for real Postgres enum types - https://gist.github.com/clarkdave/5936375 - but it's not as elegant as having it properly supported by ActiveRecord.

As other posters have mentioned here, it'd be useful if Rails' enum support used text instead of integers. You could then set up a Check constraint in PG to enforce the correct values and stop invalid data slipping into your database from other sources, whilst keeping the nice sugar in ActiveRecord.

[0] http://www.postgresql.org/message-id/3543.1317224437@sss.pgh...

1qaz2wsx3edc5• 13 years ago

The only issues I have with this release is that they could of waited until after the holidays. I have a feeling we'll see a security patch right before xmas.

The second issue I have is `secrets` should be entirely removed from the framework. These settings should NOT be stored at the file level, it should be handled by environment flags. I feel this is a fundamentally broken feature.

Spring is neat, was it just a port of Zeus into Rails?

steveklabnik4• 13 years ago

Spring is neat, was it just a port of Zeus into Rails?

Conceptually, they're the same thing, but since Zeus is written in Go, it's totally different code.

These settings should NOT be stored at the file level, it should be handled by environment flags. I feel this is a fundamentally broken feature.

I personally use environment variables to handle this case, but basically, every single approach has pros and cons, not to mention that there's legacy codebases... small steps.

1qaz2wsx3edc5• 13 years ago

Conceptually, they're the same thing, but since Zeus is written in Go, it's totally different code.

Thank you, this is what I wanted to hear. :)

I personally use environment variables to handle this case, but basically, every single approach has pros and cons, not to mention that there's legacy codebases... small steps.

I just think it's a bloated feature when `Rails.application.config` already exists.

danso2• 13 years ago

No...Zeus is its own thing, AFAIK, though I guess it's described (by the Zeus maintainer) as "like Zeus but in pure Ruby, totally automatic, alpha and limited compatibility"

https://github.com/burke/zeus#related-gems

I started using Zeus a couple of weeks ago and then switched over to Spring last week...I never figured out how to get the custom Zeus files to let me run regular rails/rake commands with certain flags and parameters, but Spring pretty much worked right out of the box. It works so well that I've been wary that it might cause issues in edge cases of test configuration, but haven't run into any yet...and now that it's a part of Rails, guess I'll be even less wary.

It's definitely changed how I do TDD for Rails, in that I will actually do TDD for Rails, because the tests run so quickly. Yes, being hindered by Rails bootup just to run tests might be indicative of unneeded coupling, but sometimes a project doesn't require great abstraction, but still needs decent integration coverage. Spring is pretty handy for that.

bratsche• 13 years ago

Wow, that's an interesting description (the "alpha and limited compatibility" part). I've used both Zeus and Spring and I've found Spring to be more reliable. I've run into a number of issues with Zeus where it crapped out on me. I've never hit any such issues with Spring, it's felt very stable. I see the Zeus issue (#254) that plagued me the most has been fixed now though: it can now accept arbitrary-length commands. So maybe it's more usable now.

mscarborough2• 13 years ago

If a project owner updates prod to a new beta of a point release right during the holiday season, that's entirely their fault, not the rails team who delivered something fun for people to mess around with.

1qaz2wsx3edc5• 13 years ago

This is a fair criticism, I totally missed the beta flag. Cheers.

tomphoolery• 13 years ago

These settings should NOT be stored at the file level, it should be handled by environment flags. I feel this is a fundamentally broken feature.

According to https://github.com/rails/rails/blob/master/railties/lib/rail..., this YAML file is handled like every other YAML by Rails...it's parsed through ERB first.

That means, you can do something like

    development:
      secret_key_base: <%= ENV['RAILS_SECRET'] %>

And reference it with that `Rails.configuration` business.

With this, you basically get a nice little API for recalling env variables. Pretty neat!

1qaz2wsx3edc5• 13 years ago

Yes, I'm aware, but what was the problem with storing configurations under `Rails.application.config.thing` as ENV['vars']?

It just seems like bloated featured.

jrochkind1• 13 years ago

If you don't store secrets in a file... how do you share them? When a new developer comes on board; when a new deploy machine is provisioned; etc.

Honest question, I've been trying to figure out the best way to do this.

Even without considering deploying secrets to a new machine, doesn't 'keep them in environment variables' usually mean store in a .bashrc or something, which is of course still a file?

bri3d• 13 years ago

Chef encrypted databags or a similar approach where the environment variable is encrypted on disk and decrypted at runtime. Obviously your deployment nodes eventually need the secret in plaintext and all end up with the key, but at least the information is encrypted at rest (for example in your source control, a common source of breaches).

It doesn't seem wise to share secrets amongst developers (especially new ones) to me - that sounds like a recipe for disaster. GitHub accidentally deleted their production database by giving developers access to production secrets on their local machines a few years ago - regardless of how much you trust your people it's not a particularly solid plan.

benesch• 13 years ago

The idea is to keep them out of version control. At least ~/.bashrc won't end up in a repository under normal circumstances. You have no idea what pieces of your code base may eventually be open-sourced.

For small teams, a good solution is to keep a GPG-encrypted file in Dropbox or another team file share. When you onboard a new developer, someone reencrypts the file with the new recipient. If you use Chef, the knife-briefcase plugin will handle this for you.

For large teams, there shouldn't be any secrets that need to be disributed. In an ideal world, at least. Each user should get his/her own account on each server, his/her own AWS credentials, etc. At some point you'll run into sharing a secret among production servers (SSL certs, for example), but you should never need to share secrets among developers in a well-designed system. Individual accounts allows useful audit trails and limits the damage if a credential is leaked.

jcutrell• 13 years ago

Love Spring. Will help every day development immensely.

Thank you for the ActionMailer previews. Working on an app with a bunch of mailers - things get wily fast, and a bunch of static files sit around to be tested for display.

I think the secrets.yml idea, while in development, is awesome and helpful for organization. However, I'd be a little concerned that a single file has everything secret-y in it. Maybe that's paranoia though. It'd be nice if this wasn't just a config thing that I could hand roll myself, and instead offered some sort of obscuration/security measure in and of itself.

jbverschoor• 13 years ago

Having all secrets in one place is IMO a good thing, as it's unlikely you will accidently put secrets somewhere else.

During deployment, you will only have to inject one file.

kawsper• 13 years ago

Removed deprecated threadsafe! from Rails Config.

What are the consequences of this change?

steveklabnik4• 13 years ago

http://tenderlovemaking.com/2012/06/18/removing-config-threa...

bazz• 13 years ago

Thank you Rails team!!

netghost• 13 years ago

Always great to see new rails releases. The message signing looks pretty useful.

I'm curious when people would use `Module#concerning` though?

chancancode3• 13 years ago

The original gem has some examples in the README https://github.com/37signals/concerning#readme

grinnick• 13 years ago

Anyone know a gem which will provide the secrets behaviour without waiting for this release?

krainboltgreene• 13 years ago

figaro, with some extra benefits

Doctor_Fegg• 13 years ago

Genuinely surprised that AR is only now getting enums; DataMapper has had them forever.

aayushranaut• 13 years ago

Is there any good tutorial site or course where I can learn more about ROR? I have a pretty solid knowledge about programming(PHP, C, C++, Objective-C) and I am getting really excited about ROR lately.

octagonal• 13 years ago

http://ruby.railstutorial.org/ruby-on-rails-tutorial-book

steven_yue• 13 years ago

railscasts.com

Dirlewanger• 13 years ago

How different are these AR enums from, say, Simple enums?

VeejayRampay• 13 years ago

That release looks awesome, congratulations to all involved.

jasonkeene• 13 years ago

Does anyone have any links describing the new CSRF for JS GET requests? Also they misspelled CSRF in the blog post title :/

chancancode3• 13 years ago

Nice catch about the title, fixed!

In the release notes: http://edgeguides.rubyonrails.org/4_1_release_notes.html#csr...

In the upgrading rails guide: http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.ht...

In the docs: http://edgeapi.rubyonrails.org/classes/ActionController/Requ...

Rails 4.1.0 beta1 released

Related Stories