I have been a user of Rails for a while and used version 2.3.4 recently.
Rails 3 Beta just came out recently and it seems have significant performance improvement especially with the merge with Merb.
I'm planning on building an application that will take 4-6 months. Should I use Rails 3 for it starting with beta? Knowing that it will be buggy until full release?
Performance is definitely an important requirement for my application.
You can help me if you can provide insight in the following questions:
1- Do you think Rails 3 will be out in 4-6 months?
2- Will it be easy to migrate code should I choose to go for Rails 2.3.5?
There are certain aspects to consider:
Does your application depend on 3rd party plugins/gems? If so than you should check if those are already Rails 3 compatible. You're probably gonna find libraries which are incompatible as yet but there is a big chance that these are gonna "get fixed" sooner or later.
Also, it really depends on what kind of application you are talking about. Personally I'm porting one of my 2.3.5 based sites to Rails 3 but only for preparing and learning purposes. Since Rails 3 is only public beta as yet, IT IS DEFINITELY NOT CONSIDERED TO BE PRODUCTION READY. You can download it, use it and play with it but that's pretty much it for now.
If you decide to upgrade one of your existing projects (which I'd encourage you to do) than have a look at Geoffrey Grosenbach's screencast which will guide you through the upgrading process.
There's also an official plugin which contains a handy script that you can use to find out which parts of your application need to be upgraded.
afaik there is no definite release date set yet. another point to consider is on how many rails plugins does your project depend on as i think most of them will need to be upgraded too ...
I think you should do it for version 2.3.5 but always think about Rails 3. Read release notes. For example use this plugin to escape html by default.
Try to use plugins that are ready for Rails 3. Check list here.
Use unobtrusive javascript.
Related
I recently get to know grails and start to using it, I know that grails is a great language and it is very helpful for rapid development, but I cant understand why grails dont have a good backward compatibility, I use grails 2.3.8 and grails 2.4 for my projects but many of sample codes in the internet are 2.2 or less, and it isn't time efficient to convert them to 2.3.8 or 2.4 because there are many changes from one version to another. And some times although I do any things right and every thing must work like it works with grails 2.1 or 2.2 but some things still remains.
Am I wrong? I skipped some things that make converting version so hard?
And above all this, what are the guaranties that projects I'm developing right now will be compatible with higher versions of grails that comes in the future?
Joshua Moore is right with his answer, but I do not see it as passimistic as he does.
The grails development team is brave enough to make changes which break with the past. I consider this as a great feature - Grails does not ride dead horses.
For me, most of the changes don't seem to bee too radical. Most of the time, I skip 2-3 version and then upgrade my apps to the current stable version in less than a day. This also helps me to get to know the new features.
If you don't know how to upgrade, the safest way is to use the grails upgrade command. Just increase you version number step by step and do an upgrade and re-run your test (yes, tests help you in your upgrade process :-). If tests fail, take a look at the great changelogs and the "What new in Grails x.y?" sections of the documentation.
Often it is also helpful to compare your old grails version app with a new and empty target version project with a good comparison tool like BeyondCompare. This way you easily spot changed configurations.
Hope that helps
Update: When you are new to "all those webconcepts" you should first decide on the platform you want to work on. If it is the java ecosystem, Grails is the best webframework on the market :-) Otherwise PHP, Rails, DJango etc. could also be a match.
So if you want to learn Grails (and with Grails all those webconcepts), I would suggest to start reading the Guide which will tell you how Grails works. If you need more examples, I can suggest the "The Definitive Guide to Grails 2" published by Apress. It covers basically the same content as the guide, but it does so by walking you through a process of building a sample application.
When it comes to the samples you find on the net... as soon as you get to know the framework better, you will probaply know ho to handle the examples - but there is no silver bullet...
Nothing guaranties that your projects will be compatible with future versions of Grails. In fact, from my own experience, they won't. Often things change, and sometimes radically too, as Grails matures into higher versions.
The same holds true of backwards compatibility as well.
All you need do is take a look at the introduction section of the Grails documentation to see how often things change significantly between versions. A lot of times these changes require significant refactoring of older projects to upgrade them. I still have several large projects running on the 1.3.x branch of Grails because we don't have the resources (time) to go through and upgrade them.
Often this upgrade process involves creating a new empty project then slowly moving the code from the old project into the new project, updating code to reflect newer means of doing the same thing and testing. It's not easy for projects where you have 100+ Domain classes, 1000+ GSPs, 50+ Services and several hundred thousand lines of tests.
I am upgrading rails 3.0.20 to rails 4.0 (current ruby version 1.8.7), how important is it for me to build unit testing into my application before starting the update? Integration testing? Acceptance testing? End to end testing?
Are ALL of these ABSOLUTELY crucial to incorporate before starting my updates?
How about if I focus on upgrading rails from 3.0 to 3.2 first (as per my employer's request)? Would any of these tests become less "necessary" and could be temporarily put aside? (given that the difference between rails 3.0 to 3.2 is not as large and significant as the difference to rails 4.0)
Note that my company's app has been working smoothly for a couple of years (without any testing mechanisms whatsoever), and updating to rails 3.2/4.0 is of HIGHER priority than incorporating testing into the app at this point in time, thus proceeding with the rails upgrade without creating any tests would currently be preferred.
Any insights, advice, warnings, would be greatly greatly appreciated. I am a novel programmer and was asked to take on this upgrading rails project on my own.
I agree with the comment that testing is always important. There should be tests in any case, never mind about when upgrading rails.
I would recommend having tests in place before doing anything else. It could save you a lot of hassle later. Quoted from the rails 4 release notes:
"If you're upgrading an existing application, it's a great idea to have good test coverage before going in."
In the end, I suppose it's up to your employer as they're paying you, but if they want to make you upgrade rails without an automated test suite you need to make it clear to them that they will likely be opening themselves up to various problems/bugs. Do they have any thorough manual quality control (human testers)? (I don't know if you were just referring to automated tests when you said they have no testing mechanisms.)
In any case, how painful the upgrade is depends on the app. Things like its size and the rails features it uses would be a factor. If you don't have extensive knowledge of the app's code base, it's going to be more difficult to know the implications of the differences in the rails versions and writing tests would be a good way to get to know the codebase!
You mentioned that the current version of ruby being used is 1.8.7. This means you'll need to upgrade ruby too, because rails 4 requires at least ruby 1.9.3.
Have you looked at the release notes for the versions of rails you'll be upgrading through/to? They contain information about changes that have been made and pointers on the upgrade process. They recommend the upgrade path 3.0 -> 3.1.x -> 3.2.x -> 4.0.x
http://guides.rubyonrails.org/3_1_release_notes.html
http://guides.rubyonrails.org/3_2_release_notes.html
http://guides.rubyonrails.org/4_0_release_notes.html
This seems to be where the upgrade guide for 3.2 -> 4.0 actually is (linked to from the 4.0 release notes), and it also contains the upgrade guides from the 3.1 and 3.2 release notes:
http://guides.rubyonrails.org/upgrading_ruby_on_rails.html#upgrading-from-rails-3-2-to-rails-4-0
Basically I went through the upgrade without any integrated testing.
I had to manually check the functionality of the site is working, about 90% was working fine and the rest I had to catch.
Most issues involved gem compatibility, some had to do with JS libraries that I choose to include in the application.js file in my assets folder.
If your app is of moderate size and you can spend a week or so testing it yourself manually, I wouldn't worry about having any integrated testing, as important as it is to have.
The application I'm working on was started with Rails 3.0.6, I believe 3.0.7 is available and 3.1 is just around the corner.
I realise 3.1 will likely have some breaking changes, requiring a proper read through of release notes etc, before attempting to update the project.
My question though, is what is considered best practice for the x.x.x updates and the x.x updates? Should they be treated differently? Barring breaking changes, is it best to create a brand new project each time and drop in the changed files?
Rich
The best way is always to specify your Rails and other Gem Versions within your Gemfile.
gem 'rails', '3.0.7'
When a new version is released you simply bump the version, bundle and run your test suite. Following the change log will allow you to assess if any changes will be required. Rails is very good at providing Deprecation warning for your code segments so you should know about a change before it happens. Hope this helps, all the best.
I have a bit of a mixed opinion on this.
On one hand, you want to be pragmatic about your upgrades and assess whether taking the time to upgrade your version of Rails will bring about any benefits for you. Sometimes this is obvious--speed improvements to slow parts of your app, improved pipelines or workflows, etc. might bring obvious gains, and you can easily justify taking the time to upgrade the app. Sometimes, it's not so obvious, and there's certainly a great number of production apps, some very well known, still running 2.3 and Ruby 1.8.7.
On the other hand, Rails is a fast-moving project, and I personally wouldn't want to sit around on a very old version. The longer you wait to upgrade, the more work you'll likely have to do to modify your app accordingly.
If you feel like it's time to upgrade, or that upgrading is a good idea, my advice to you is create a new branch in your version control system and test and profile the new version. That way, you and the rest of your team can continue working on the app in the old branches as normal, and you can get a good idea of how much work it'll take to upgrade Rails. Then, if everything goes horribly wrong, you can just delete the new branch and move on your merry way.
TL;DR
Be pragmatic about your upgrades--assess if the upgrade will bring any real, measurable benefit to your app or your team
Always test and profile new versions of Rails (or any other dependency!)
I've spent a fair bit of time with PHP & Python frameworks and recently thought I'd branch out to rails. The framework itself I like, but I seem to spend at least half my development time navigating through odd bugs and/or version incompatibilities between rails/ruby/rake/gems.
I'm happy to battle through it all if it gets less of a hassle, but even after a month it seems like I spend 90% of my time chasing down other people's bugs & only 10% of my time chasing down my own. The only guy I've talked to (who used it extensively until 2008) suggests "For the past 2 years, that's pretty much rails"
Any opinion on this? Does it get better, or is this just par for rails development at the moment?
Running it through Ubuntu 10.04, if it matters.
Rails is in transition right now between 2.3x and 3.0 so you are going to find it quite challenging as much of the most recent documentation and rails plugin readmes are being updated for rails 3. There are several tools that are indispensable right now for negotiating this stuff. First, Rails 3 uses bundler to manage dependencies, it is a much more civil way to manage gems.
gem install bundler
cd my_rails_project
bundle install
RVM (ruby version manager) is awesome and I would recommend installing it. Then you can build gemsets and dependency sets on a per project basis. and you don't need to superuser access to install.
also, if it were me, I'd just go ahead and start in rails 3
gem install rails --pre
if you want to stay with rails 2.3.x use the rake task for installing declared dependencies.
rake gems:install
if the project is a good project, it will be pretty specific about what it needs (declared in the config/environment.rb file), then if it doesn't run, checkout the stack traces to see where its failing.
In my experience this is not par for Rails development.
While using gems read the README file on github project repos and have a look at the issues and wikis....that should give you a fair idea of which gem is compatible with your Rails version. Regarding the framework, it is pretty stable....major bugs or patches or releases are reported on weblog.rubyonrails.org
Things grow incrementally with each release and that is obvious. There are some deprecations which are well documented in the Rails code and are reported when you run the code.
Rails itself is pretty bug free. I've not witnessed a bug in the framework itself now for a while unless I've been duplicating open tickets.
Where the problems you're seeing have crept in have been over a couple of different areas:
We've moved as a community from Ruby 1.8.x to 1.9
over the last year or so, and some
gems have specific Ruby version
requirements you need to check out
before using them. Most of the more
popular gems are fine and tested to
work in multiple environments. Read the docs first.
Rails itself has matured
significantly over the last few
years, and that has meant many
features have been deprecated. Lots
of plugins out there were written
for an older version of the
framework and expect behaviour that
just isn't valid any more. Read the docs first.
Several different Ruby interpreters
are now available (which is great),
but these sometimes can have an
impact when it comes to 3rd-party
code, but that's rare. Basically,
some gems and plugins expect to be
running on a specific interpreter.
None of the really popular ones are
like this, but you need to be aware
some gem builders are idiots. Read the docs first.
You might notice there is a common theme to the end of each point: read the docs first. :-)
I would say your experience is not at all typical of most Rails developer's workflows, although we've all had a day of struggling from time to time.
You will learn quickly which gems to trust, which ones you'll need but may struggle with from time to time (mysql - building that kills me on OS X, every time), and which ones you should avoid.
Overall though, the development cycle is more fluid (and you'll develop more rapidly) with Rails once you've got your bearings and are adopting good practice. There's a reason why we all like TDD and BDD though - if nothing else it helps us get through a gem update knowing stuff still works when a developer we don't know has done something moronic. :-)
I've a portal project built in Rails 1.2.3. I've finished it at end of 2006.
The project are using the following plug-ins:
acts_as_attachment
acts_as_ferret
betternestedset
simple_http_auth
I know all plug-ins (or dependencies) was changed today, or doesn't exists anymore. The DHH says: Don't overestimate the power of versions. But I'm worrying about this.
If I update the rails version, all things will gonna fail. I can change my application to work with new rails version. I think I can read what's now deprecated and change it. But now I need to support all dependencies by myself or change it to other dependencies (Eg: acts_as_attachment to atachment_fu or paperclip). What to say about tomorrow?
My doubt isn't only about Rails, it's about using dependencies to increase productivity. In other projects I've used pure Python code, or even pure Ruby code, or pure Php code. Today I can run it in latest versions of "language/environment" without (or few) changes.
These projects haven't external dependencies, it's just the application code. Maybe using some web framework just as skeleton, but not external projects.
What do you think about this?
When you use someone else's code you pay with your independence for the ready-baked solution for a problem. So it's up to you to decide in each case what's more important to you - build your own stuff and lose time on it now (probably - a lot of time), or use someone else's projects and get the job done right now, but keep tied to them or pay with your time for upgrade/migration later on.
You've said the project worked for you for three years already - and I think it's great, if you need to bring it up to date - it's natural that you have to invest some time to do it, three years is a long timeframe in this area.