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.
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.
> 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.
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.
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.
> 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.
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.
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!
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?
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.
> 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.
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"
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.
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?
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.
[+] [-] whalesalad|12 years ago|reply
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:
Booya! Very excited to put it through the paces of this new app I am working on.[+] [-] chancancode|12 years ago|reply
[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|12 years ago|reply
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.
[+] [-] cantoniodasilva|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
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|12 years ago|reply
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|12 years ago|reply
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|12 years ago|reply
During deployment, you will only have to inject one file.
[+] [-] danso|12 years ago|reply
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...
/s
[+] [-] steveklabnik|12 years ago|reply
[+] [-] gfodor|12 years ago|reply
[+] [-] joshdotsmith|12 years ago|reply
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
[+] [-] mikeatlas|12 years ago|reply
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) %>
[+] [-] purephase|12 years ago|reply
[+] [-] annon|12 years ago|reply
Surprised to see enum support finally come to activerecord.
[+] [-] alxndr|12 years ago|reply
[+] [-] 1qaz2wsx3edc|12 years ago|reply
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?
[+] [-] tomphoolery|12 years ago|reply
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
And reference it with that `Rails.configuration` business.With this, you basically get a nice little API for recalling env variables. Pretty neat!
[+] [-] mscarborough|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
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.
[+] [-] danso|12 years ago|reply
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.
[+] [-] jrochkind1|12 years ago|reply
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?
[+] [-] netghost|12 years ago|reply
I'm curious when people would use `Module#concerning` though?
[+] [-] chancancode|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] kawsper|12 years ago|reply
What are the consequences of this change?
[+] [-] steveklabnik|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] jasonkeene|12 years ago|reply
[+] [-] chancancode|12 years ago|reply
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...
[+] [-] grinnick|12 years ago|reply
[+] [-] krainboltgreene|12 years ago|reply
[+] [-] VeejayRampay|12 years ago|reply
[+] [-] bazz|12 years ago|reply
[+] [-] Dirlewanger|12 years ago|reply
[+] [-] Doctor_Fegg|12 years ago|reply
[+] [-] andyl|12 years ago|reply
Really like the six-month release pace.
[+] [-] aayushranaut|12 years ago|reply