
Rails 4.1.0 beta1 released - chancancode
http://weblog.rubyonrails.org/2013/12/18/Rails-4-1-beta1/
======
whalesalad
Wow. These are STELLAR improvements! Check out the release notes here:
[https://github.com/rails/rails/blob/master/guides/source/4_1...](https://github.com/rails/rails/blob/master/guides/source/4_1_release_notes.md)

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.

~~~
jenseng
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...](https://github.com/rails/rails/commit/db41eb8a6ea88b854bf5cd11070ea4245e1639c5)

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.

~~~
yxhuvud
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.

~~~
masklinn
Shouldn't the mapping to database be backend-dependent anyway? SQLite has more
or less no feature, yet ORMs don't feel the need to restrict themselves to
what sqlite can do.

(nota: oracle and mssql don't, afaik, have an enum type either)

(and in Postgres, enum is not a type, it's a type constructor. First you have
to `CREATE TYPE yourtype AS ENUM ( values... )` then you can use `yourtype` in
a table, you can't have a column of type `ENUM ( whatever )` because Postgres
enums are disjoint and not structurally equivalent)

------
steveklabnik

      > 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.

~~~
mscarborough
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.

------
jcutrell
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
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.

------
danso
> _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...](https://github.com/rails/rails/commit/c300dca9963bda78b8f358dbcb59cabcdc5e1dc9)

/s

~~~
steveklabnik
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.

------
gfodor
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!

~~~
joshdotsmith
37signals actually has a gem called mail_view that I've been using to preview
mailers:
[https://github.com/37signals/mail_view](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](https://github.com/Mange/roadie)

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

------
annon
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
note that it's not "real" enum support

------
1qaz2wsx3edc
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?

~~~
jrochkind1
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?

~~~
benesch
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.

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

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

~~~
chancancode
The original gem has some examples in the README
[https://github.com/37signals/concerning#readme](https://github.com/37signals/concerning#readme)

------
kawsper
> Removed deprecated threadsafe! from Rails Config.

What are the consequences of this change?

~~~
steveklabnik
[http://tenderlovemaking.com/2012/06/18/removing-config-
threa...](http://tenderlovemaking.com/2012/06/18/removing-config-
threadsafe.html)

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

~~~
chancancode
Nice catch about the title, fixed!

In the release notes:
[http://edgeguides.rubyonrails.org/4_1_release_notes.html#csr...](http://edgeguides.rubyonrails.org/4_1_release_notes.html#csrf-
protection-from-remote-script-tags)

In the upgrading rails guide:
[http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.ht...](http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.html#csrf-
protection-from-remote-script-tags)

In the docs:
[http://edgeapi.rubyonrails.org/classes/ActionController/Requ...](http://edgeapi.rubyonrails.org/classes/ActionController/RequestForgeryProtection.html)

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

~~~
krainboltgreene
figaro, with some extra benefits

------
VeejayRampay
That release looks awesome, congratulations to all involved.

------
bazz
Thank you Rails team!!

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

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

------
andyl
Thank you Rails team - lots of useful stuff here.

Really like the six-month release pace.

------
aayushranaut
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
[http://ruby.railstutorial.org/ruby-on-rails-tutorial-
book](http://ruby.railstutorial.org/ruby-on-rails-tutorial-book)

