I have an old MVC application I need to make changes to. It would be nice to update all the recommended NuGet packages, but I know from experience that this can break a project.
In particular, I'm troubled by the following:
If one reads this a certain way, it appears that it's actually suggesting I upgrade to Twitter Bootstrap 5.1.2. I know for a fact that numerous breaking changes have been implemented since my current version.
I prefer not to have to rewrite the site. I thought Updates might have been a little smarter. Do I really need to know each package well enough to know if it would include breaking changes? Is there no way to specify compatible updates? Did Microsoft consider this aspect?
You do need to know each package well enough. Why? Because there's not a single way of doing versioning. Some packages, probably a lot of packages even, follow Semantic Versioning, but there's nothing to stop anyone from using any versioning they want (even if it doesn't make sense). There's nothing preventing you from going 3.0.1 to 15.14.13 with a change in an unimportant .txt file.
It's your responsibility to know what to update and when. Look at this Q&A to see how you can restrict the versions suggested: NuGet Limit max major version of a package
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.
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 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.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've seen a lot of blogs talk about RubyMine lately, as a best of breed Rails IDE. Currently, I am using NetBeans IDE for my Ruby and Rails stuff, but I was wondering if anyone here would personally recommend this IDE, and reasons why I should fork out $99 for it.
I used NetBeans for a while, before switching to RubyMine some month ago prior the first release.
I can say the IDE is worth the entire price.
RubyMine has the best autocomplete support I have ever seen. It's a really clever IDE, it can understand most of the Rails "magics" including method references by symbols
class Controller
before_filter :mymethod
def mymethod
end
end
metaprogramming, Rails/Ruby convention and so on.
Also, RubyMine 2.0 introduced i18n support for Rails and, having to maintain a couple of Rails apps localized in 5 different languages, I must say this is an awesome feature.
It supports the latest testing frameworks in the Ruby ecosystem, including Shoulda, Test::Unit, RSpec and Cucumber. Unfortunately it lacks RCov support, while I know Netbeans is going to integrate it.
A couple of co-workers are still using NetBeans and they often have problem with SVN because Netbeans doesn't auto-refresh the working copy when you update it outside the IDE.
RubyMine has an excellent SCM support and ships with SVN, CVS and even Git compatibility.
I don't want this answer to seems like a RubyMine promo, so I encourage you to give it a try for 30days then make a choice.
I've tried Netbean, RadRails and RubyMine. In my personal opinion it's well worth the money, and I heartily agree with weppos.
Your best bet it to try the evaluation version for a while and make your own mind up. I find IDE preferences are very subjective, the only real way to know if it's any good is to try it for yourself.
it is a little buggy and a big resource eater but has the better "intellisense", refactoring, and complementary areas support (haml) i ever seen for ruby/rails. it's appearance under mac os x is lame and is much less usable (in terms of UI usability) than any other ide. i guess that in the next major versions it will become the ruby/rails killer-ide. i would wait to buy it, as i see it as an immature project right now.
Suffice to say that Rubymine (2.5 EAP version) is the first IDE I actually like. Having used
to excellence of developing Rails apps in OS X with TexMate, when I switched the job and was forced to get along without OS X, I was quite satisfied to find Rubymine.
A veteran Emacs user (over 10 years) and recent Vim convert (gotta love the extremely powerful command system and short key bindings), I soon found that either the file navigation, cucumber editing or refactoring support was quite lacking in those. With Rubymine, I get TextMate-style file navigation which is just awesome, the only IDE which actually has a type inferencing engine and is able to capture many run-time errors during the editing phase, plus all the features I ever used in Rails projects.
Yes, I'm going to buy the software when they release 3.0 or so, and I don't know if I'll use TextMate in the future when I get again access to OS X. They say the OS X support is very good in Rubymine EAP versions, but what's nice that you can have that for every other OS as well.
Apologies for answering in short. I'll add that debugging via RubyMine is very convenient. Just set a breakpoint and try to hit the point. You can see all of your vars, set watches, and investigate objects right in the debug console.
I'd highly recommend it to any Ruby developer.
To me, there are 3 big advantages in RubyMine that other free or cheap editors/IDE's don't have (notably TextMate and Ruby VIM):
The ability to browse all the gem sources, navigate to the definition of a library method deep in a gem in a single keystroke (CTRL + B on Linux, Cmd + B on Mac), or related docs (CTRL + Q on Linux).
Graphical debugger integration. If you are debugging with print statements and the command line debugger is too cryptic too you (can't see the forest for all the trees), then the time savings alone of debugging a running test suite or live server are worth the price of RubyMine (if you value your time at all).
The continued dedication of the JetBrains team to keep up and integrate with all the whims and trends of the open source tool chain. In the 3 years, I've used RubyMine exclusively, I've seen them follow and integrate with every thing that's gaining traction. Their responsiveness is unmatched. Just 3 examples of this: Native cucumber specs in 2009, RVM in 2010, CoffeeScript in 2011.
I use it, and as of right now, don't think it's quite worth it - if you like working with a full IDE, RadRails is as good (though in different ways), and free. I admit, I haven't got all the keyboard shortcuts in RubyMine down, so I'm not as productive with it as I hope to be, but I find myself doing stuff at the command line more than I think should be necessary with a 'real' IDE. It's been pretty stable for me (on linux), the source control integration is good, and it's not as slow as it used to be (though I still end up in vim at times, if I don't want to load it). I'm hoping a 'plugin' ecology will develop around it. Overall, it's a pretty good product, but not (yet?) worth the $99 over RadRails (haven't used NetBeans)
I've used Netbeans for a while(1+ year) now. and have tried RadRails too. but i choose RubyMine cause:
the base IDE is very solid and has a
ton of plugins
it's generally more intelligent and have good refactoring abilities.
it supports a good number of other frameworks and technologies outside ruby and rails (like SaaS, haml, cucumber, shouldr, rspec...etc).
it supports my favorite version control system: git.
all in all i think if you take some time to learn its key mappings, you can be very productive with it. you wouldn't need to use a shell at all(well sometimes you might need to but...you get the idea).
just my 2 cents
I've been using Rubymine to develop Rails apps for a while now.
There was a point a few months ago when I would have been hesitant to recommend paying for it.
However the rate at which it has been improving and adding new features is really impressive.
If you're doing BDD (with Cucumber) then it's worth buying just for the step completion and navigation.
Also the features that have come from IntelliJ like Javascript, HTML, CSS, VCS support etc are excellent.
I am a former NetBeans user. I LOVE RubyMine! It has excellent rvm, git, Rspec and cucumber integration, all of which are in my stack. Go with it. You won't be sorry.
I used both Redmine and Textmate but I tend to spend more time coding in textmate. It's a matter of preference whatever gets the job done quicker is the best tool in my opinion.
Good Luck #johnrlive
I love how "project aware" RubyMine is. Coming from ST2 (which is still use daily), it's hard not to miss the elegance of an editor like ST2 but working on large scale projects with versioning, RubyMine is the IDE of choice for me. I just wish the would improve the editor and UI.
I just started to explore the IDE concept, being a happy TextMate programmer until just a couple days ago. But now that I've played with both NetBeans and RubyMine, I gotta say RubyMine rocks. NetBeans is cool for the price, but it's slow, slow, slow. Sometimes windows will lock up for long periods of time while something is apparently "thinking" - of what, I can't imagine. On the other hand, even as a fairly novice Ruby programmer, I was able to get RubyMine conversing with Git and AutoTest within a few minutes -- in short I got up and running and back to programming pretty quickly. On the flip side, I still haven't figured out how to get it to work with Heroku or Growl, but I'm still pretty new at it.
I would say depends on what your looking for. Netbeans is definitely a very capable and sufficient IDE. Rubymine shines in its autocompletion and really easy Git integration. If you have a lot of money to spare I would say ruby mine is the way to go. However, in my case, as I am a broke college student Netbeans and/or text mate does the job fine. Spending an additional minute on git outside of netbeans and using my extra monitor for documentation has worked well for me thus far.