My experiences with web-frameworks was that they are relative "unstable". Not that they crash but that there are quite a few changes which then force one to reprogram ones code. I wonder what web development packages you've used and how much work it was/is to maintain that code?
"Changes are a part of the requirement."
I dont think that the web packages that we design changes a lot. If it changes, then it is a bad design. If we use external API's, a very few get deprecated, otherwise most of them are the same.
Some packages used as a JAVA/J2EE programmer:
- MVC
- Struts
- few AJAX frameworks
These are very basic one used. Most the other ones are self developed and once the design of the web package is done, we don't change the design.
Any library which is under active development would be unstable. Look at .NET for example, every month there's a new better way to do old stuff. On the other hand open source libraries tend more to throw old deprecated methods away because it makes code better and that's what makes them happy.
But I wouldn't recommend to use anything old and unsupported anyway, you'll be on your own although the environment would be completely stable.
The best way possible seems to be just freeze the version of library you start using and switch to new one only there's huge benefit in doing so. At least that's how everyone is doing that.
Frameworks like .NET and jQuery have been largely backward compatible and allows you to use new features slowly.
Mootools however... the API broke so many things from 1.11 to 1.2 to 1.3. Upgrading was not straightforward in that case.
As a rule, I try to wait for something to be out of beta before embracing it in production code. An endorsement can go a long way too - since Microsoft has called jQuery the winner of client-side frameworks its been easy to encourage others to pick it up too.
Most of my experience is with Ruby on Rails, so I'll share what I've seen with it over the last few years.
Rails updates at a pretty good clip, but you don't really need to update unless you need features or the rare security patch. As an example, I have a rails app running in our company right now that was coded about 2.5 years ago that only needed to have some work done to it once this year to upgrade it to a new version to be compatible with apache mod_rails, it was originally written against Rails 1.2 I believe. Of course, that was an intranet app which didn't have any security requirements. All in all, it's been pretty pain free. If I had kept using mongrel + mod_proxy it wouldn't have only needed to be updated once for a security patch.
Rails is pretty secure, vulnerabilities are fairly far between. There have been a few more Ruby vulnerabilities than Rails vulnerabilities if memory serves me right, but all in all it's pretty solid, and upgrading your ruby shouldn't break rails, especially if you use a distro that backports security fixes.
Related
soliciting advice about upgrading (or re-writing?) a legacy app. It's a single page webapp with lots of dynamically generated windows and forms, roughly comprised of
13,000 lines in .rb files
11,000 lines in .erb files
25,000 lines of javascript (not including large 3rd party libraries that bring this to nearer 60000 lines)
This acts as a UI for end users of our system, which also has a number of core business services (mostly written in Java, with a small amount of Node.js) and a fairly sizeable MySQL database (>200GB). Some of these services push AJAX to the client browser for real-time updates.
Reasons for upgrade
It's ruby 1.8.7, rails 2.3.15. Most of the core code dates from 2009. This makes it both insecure and hard to maintain (think "predates the existence of gemfiles".)
The app has been maintained by Java devs for most of its life, as most of the company's devs have been hired as Java devs to work on all the other services that perform business logic. It's probably safe to assume that this has lead to lots of hacks from people who didn't want to break anything, and certainly lots will not be done in a "rails way".
The javascript is also a bit of a mess. It's got a knot of frameworks (the original Angular is used sporadically; jquery and prototype are both fighting over the $ symbol in different places.) There are files that are 7000 lines long.
the css styling has been upgraded since 2009(!) but is starting to look a little tired. We'd like to implement a bootstrap theme that will look sharp without too much front-end skill, but right now the code that renders all of our pop-up windows, sidebars etc breaks badly if we try and add bootstrap.
It would be nice to modernise our push servers, replacing them with websockets.
Context
There are 3 of us on the dev team- this is my first job, and I've only been here since January. Of the other two, one has only been here about 4 months longer than me, and it's his first dev job too. The other guy is the only one who has ever spoken to someone who spoke to someone from the original team.
Oh, and of course we have little or no test coverage.
Options
When I was hired (as a Java developer), I was told that we were looking to replace the website with one based on Spring MVC. This effort is partially underway, having been attacked in drips and drabs over a couple of years. Because different devs who never met have attacked it as if it's their own brand new project, the same problems are solved in different ways in different places. They've tried some flashy techniques such as custom annotations that I find hard to follow, but as far as I can tell don't fully work. The most senior of us estimates it would take our team a year's dedicated full-time work to finish it (which is not a realistic business proposition, based on how many requests for new features we get from customers).
I'm inclined to upgrade the website rather than spin out a new one. This is partly because I can see the sense in that post. Another reason is that we're all employed as jack-of-all trade full stack developers (doubling as DBAs, sysadmins, etc...). We've got no particular expertise in UI design, and the UI for our present interface, although dated, is pretty user-friendly; it feels like a blank canvas would throw that structure out, and play to our weaknesses. Upgrading ruby/rails would also make any features we add during the upgrade much easier to add to the new site.
Apparently some experienced ruby devs who are friends with my boss have advised him informally it'd be so much work to bring the website up to date that it would be comparable to a complete re-write, which was the motivation for the spring project. This would have the advantage of only having to think about Java + javascript, and not trying to hire people who know both Java and ruby well.
Conventional wisdom seems to be upgrade rails in stages. I'm not sure how well this would work for us, for 2 reasons. For one thing, there 3 major versions for us to upgrade, which might have significant changes between them. More importantly, the code needs some TLC anyway with refactoring and the creation of a test suite.
I'm inclined to follow the following strategy:
Invest some developer time in training, to get a sense of the relevant best practises and the "rails ways" of doing things, rather than the "good enough to hack" knowledge most of us have now.
fire up a new rails 5.1 project on ruby 2.4.0
Configure active record to use our old database
Copy across the javascript from the public folder of the existing project in to the relevant parts of the asset pipeline and save that headache for "phase 2".
Sort out a gemfile with updated versions of our dependencies (for example, mysql gem has been replaced by a mysql2 gem.) Installing rubocop seems like a good idea at this point.
Copy files across from old to new project one at a time. Read the code, figure out what it's doing, write the relevant tests, fix where they break. Use the ruby API and rails upgrade guides to update the syntax. Refactor until rubocop is appeased.
Once we've reproduced the functionality of the existing site, write a new stackoverflow post on how to sort out the javascript ;)
This certainly sounds like a lot of work, but seems less likely to produce a buggy mess than trying to reproduce our existing functionality from scratch in a different language. So...
Questions
Does this strategy seem sensible? Is this a case where the re-write is really a better option? Is tackling the JS separately the best call, or is it better to restructure it as we're examining the calls to it from the views? Or should we really upgrade -> 3.0, 3.1, ... 5.0, 5.1?
We've altered the database manually, adding new tables, new fields and whatnot directly rather than using .rails generate. 'Rails magic' seems to make this work at present, but should we anticipate problems in step 3?
Is there any logical order in which to approach the migration of ruby? As there's major changes to the routing, which is the central entry point of the application, it seems sensible to start there, followed by authentication, then the main page, and then add functions one at a time.
Part of the problem is "not knowing what we don't know" about the rails way of doing things. Apart from the canonical Ruby/Rails tutorials (Hartl, Ruby Monk, Ruby Koans, Kehoe's rails book), is there any essential reading we should be aware of before trying to take on such a large job? I'm especially thinking about things that may not be immediately obvious, like proper use of helper functions, module structure, etc.
Any other advice, comments, prayers, ... welcome!
Yes, several similar threads exist, but we're now in 2011, and much has changed.
Grails 1.3.6 has improved hugely compared to v1.3 when I initially tried to learn the framework (and gave up to slow compile times and other groan inducing events).
Having spent a couple months with the latest release, I am impressed, protyping an app is an absolute breeze (GORM is great!). In development mode one no longer needs to restart, barring changes to domain classes. Groovy.lang is fantastic (bare in mind, this is compared to my day job life in PHP).
Now, on the flip side there is Ruby/Rails, which I have little experience with beyond perusing Ruby docs and exploring Active Record (to compare to GORM). Coming from PHP/Jquery, groovy syntax is cake, ruby not so much, although accessible.
Ruby/Rails is all the rage, while Groovy/Grails seems to be picking up speed in its own right.
I'd like to hear what both camps have to say (flame inducing lang war welcome) re: pros/cons of both langs/frameworks now in 2011. When choosing a framework it's important to know what you're getting into, so have at it, newbies will benefit, and experts can vent ;--)
Rails and Grails are both excellent frameworks with their current releases. You really can't go wrong with either. Here are some things I find interesting about them though:
Rails
Rails (Ruby) does not scale as well as Grails (Groovy). You will need more horsepower to run your application. This isn't a big deal at all with PaaS options like EngineYard (and hopefully a AWS BeanStalk Rails option in the future), but it might just cost a little more to run a Rails app vs a Grails app (obviously JRuby is also an option to though).
Rails is slightly better with NoSQL alternatives currently, but Grails is catching up quickly
Rails has many more plugins, but this can lead to trouble if you use some that aren't maintained (a lot of them don't currently work with Rails 3 yet either).
Rails is more mature and has more features at this point in time because it's been around longer
Rails REST support is amazing
There are many more "big" Rails websites than Grails
Ruby is much more popular than Groovy - TIOBE
No dependence on Oracle, ha! (Grails obviously needs the JVM)
Grails
Grails integrates with the JVM better than JRuby
Grails GORM is better than ActiveRecord (IMHO), although Rails 3 opened the door a little bit for other persistence options, but all the books, tutorials, etc all use ActiveRecord
Grails View taglibs are better than <=%...%> in view
Grails plugins are well documented and clearly state whether they are supported by SpringSource or not
SpringSource is investing heavily in Grails
There will be many more corporate jobs for Grails than Rails in the future, but more startups use Rails (where do you want to work?)
My perspective
I used Rails a couple years ago, I'm working on a Grails project now
I like them both better than Django (Python) or Zend Framework (PHP)
I plan to learn Lift (Scala) next
My Recommendation
If you have never done Java development and are working on a side project for a small to medium website, go with Rails
If you are working at a big company that uses Java, try pitching Grails to your management as the "next Java framework" they should invest in
If you are working on "the next twitter or foursquare," well then you are smart enough to answer this question yourself! :)
First time I begun a project with Rails I was really surprised:
How can I separate "repository" from "Service"? Oh my God: I have to put business logic on controllers... I can't imagine a real big project with Ruby on Rails: Is there Someone on 37signals remembering the basics of separating Business and Domain/Repository. The Rails folders/classes structure doesn't take care about this.
Second sock: "Active Record". Try to design a real complex Object Oriented Business layer and map it using the Rails Models (Active Record)... really: don't.
6 months later, with our project running: R&R is consuming 80% CPU (and memory...) using apache + passanger on a quad core server... and the Postgresql Database is in holidays (3-4% of CPU)... Oh my god (newly)
My old ASP/VB6 applications where capable of serve pages to 300 concurrent users in a real backoffice context with real complex databases and complex business installed on a standalone machine (a year 2001 1 CPU core server).
Of course, conventions and Ruby syntax are lovely... and no one needs a compiler (well... unit tests are used for this porpouses 90% of the time... just for solving the dissapeared typing each time I change some code... "Please, programming god, take care about my fingers mistakes" )
First impession with Grails:
A "Cool" stack inspired on Rails with professional power based on Spring framework (IoC, Hibernate, ...)
And YES!!!
There is a clean Domain/Service separation. NICE!!!
You can, eventually, forget Java.
Rails is fairly mature, has a HUGE ecosystem to go with it. I'm not familiar with Grails or it's support online, but the red flag I see in your post is that you've admitted Grails is playing catch up to Rails.
Ruby is an absolute joy to work with (and this coming from an old C++ hack... why, back in the day I used to program with just a hex keypad, young whippersnapper... now GET OFF MY LAWN!).
There are things about ruby that make it hard to follow at times (method_missing I'm looking at YOU) but I'm sure that can be said about any language.
Me? I'd go with ruby and rails.
Well for grails, i still think that even catching up, it has 2 main things that rails won't have in a easy way:
scaling up
tons of mature java libraries at your fingertips (personally geotools among others)
Ruby on Rails is outstanding - like the Pink Floyd of web dev.
Groovy on Grails is a decent copy of it - kind of like the Australian Pink Floyd show...
BTW - We have both at work - and I have seen many Grails developers eventually learn Rails and stick with it.
I have also seen Rails developers learn Grails, but NONE of them have preferred it.
About half of the time, our Java developers learn Grails and simply stay away from Ruby.
IMHO - If you truly know both fairly well, you will almost always prefer Ruby and Rails.
You also have to consider your IDE. When I started out with rails, it was quite painful. Rubymine was super slow and crashing, everyone I know were using textmate. Grails has STS (eclipse based) and gives you all the features you need.
We are currently running rails 2.1.
My main motivation for the upgrade is the fear that gems/plugins will get rarer/unavailable/unsupported day by day for our version (,and the excitement of the latest technology).
I understand there are many-many improvements that come with rails3, but probably what my manager would want to listen is the advantages that he'd get, in terms of the business.
Ours is a Saas application, load on the app is not very high, but the demand for reliability is more.
Edit :
Looks like my inclination towards the upgrade needs rethinking, so answers to "should I upgrade" are welcome.
my original question also needs answers - how to describe the business advantages of an upgrade from rails2.1 -> rails3.
The app is under active development/enhancements.
The longer you go without upgrading, the harder it will be when the time comes. Sooner or later, any actively maintained project is going to have to move up to the more recent versions, and the more versions you have to skip along the way, the harder and more risky it will be. If you upgrade regularly, it becomes a fairly simple maintenance task.
I'm afraid that going from 2.1 -> 3.0 is going to be a fairly rough one unless your app is pretty simple. You might try going from 2.1 -> 2.3.9 as a first step. However, doing it now, instead of when it's 2.1 -> 3.1 will save you heartache. Right now, everyone is focused on helping people upgrade. A year from now, there will be fewer fresh resources available and fewer people going out of their way to help people upgrade.
If your application is under development and is likely to have more and more features over the months to come then you should migrate to the newer and actively supported version.
If your application only needs bug fixes occasionally then you should stick to the current version.
Upgrade!
I'd say that you should definitely upgrade, for the reasons you stated, but don't rush it. If you have a well defined test suite everything should be ok.
Most of core Rails 2.x code works with Rails 3, you can just read the deprecation warnings and fix things one by one. You can also use the official Rails Upgrade plugin to automate the bulk of the editing.
As for the gems and plugins you use, you can check their compatibility at railsplugins.org and decide if it's worth the trouble if any.
And the elevator pitch for the boss: You said the app is under development, so upgrading later when you absolutely have to means that you have to first deal with all the issues arising under 2.x and then deal with the upgrade issues plus 3.0 issues of a much bigger app. Upgrading now saves time by saving you the trouble of having to deal with 2.x issues. And you also avoid some of the upgrade issues since your app is probably much leaner now than the heavyweight it will be when you decide to upgrade later.
Since reliability is high on priority, you should probably not upgrade unless it's absolutely required. Some unforeseen issue is bound to come up.
To address the excitement of the latest technology, you can always try out new plugins and Rails 3 offline.
Businesses should not be sandboxes of developers. Nor should development be Resume Driven.
But that's just my opinion. :)
There are several reasons to upgrade, all of which are under the assumption that the app is and will continue to be under active development.
Integration with 3rd party software- for example, rails 1 did not have ActiveSupport. An app remaining on rails1 all through say rails 2 might want to integrate with a 3rd party API that primarily supports restful json. At that point, the sensibile path is to upgrade, but since you delayed it so long your risk of having lots of issues in the upgrade will be significantly greater than if you upgraded early.
Using plugins that will help with new features - if you want to add a new feature and someone has scratched your itch already, then if you are stuck on an older version of rails you will have to write that code yourself. The more code you have to write yourself, the greater the likelyhood of bugs and the more maintaince the code will likely require, depending on the function.
Fixing bugs in older verisons of the plugins/gems - if you encounter a bug in rails, or a plugin, or a gem, or some sort of other integration issue, it might be fixed in a later version, but what that depends on a newer version of rails. This will make your path to fixing said bug or implementing said enhancement greater the longer you wait to upgrade.
I'm in the preliminary stages of designing a new web application, and have yet to begin any sort of implementation. The application models a fairly complex domain, and I'd feel more comfortable using tools such as the ruby DataMapper ORM (having using NHibernate in the .net world) than Rails Active Record. I also prefer jquery over prototype. All of these considerations of course point to using Merb, yet I'm aware that Merb is being merged into Rails for version 3 and will no longer exist as a distinct framework.
Is there any sense in starting work on the implementation of the application now given the fairly profound changes coming to rails? I'd really like to know if it would be worth starting development in Merb now and then porting it to Rails, but I've yet to find anything suggesting how difficult this may be. Another approach would be to start work on the domain now in Rails, and only give consideration to the ORM and frontend once v3 is released.
In essence, I'd like to know how portable a Merb app is going to be to Rails 3, but am aware that it may be too early for anyone other than the core developers to know this.
Any thoughts would be greatly appreciated. Thanks :)
-------------- Edit ---------------
Yehuda Katz, lead developer of the Merb project has this to say on his blog:
The plan is to start working on Rails immediately, and to continue fixing bugs and resolving other major issues in Merb in the interim. We will also release versions of Merb specifically designed to help ease the transition to Rails 3.
In particular, we will do Merb releases with deprecation notices and other transitional mechanisms to assist developers in tracking down the changes that will come between Merb 1.x and Rails 3. Expect a number of interim releases that get incrementally closer to Rails 3, and expect parts of Merb (most notably the helpers) to be ported to run on Rails 3 in order to further reduce friction.
To be perfectly clear: we are not abandoning the Merb project. There are many production applications running on Merb that are relying on both timely bug fixes and a clear path to the future. If you’re using Merb today, continue using Merb. If you’re considering using Merb for a project because it works better for your needs, use Merb. You will not be left in the cold and we’re going to do everything to make sure that your applications don’t get stuck in the past.
If you’ve already learned Merb, we will be working hard to make sure that you can parlay that knowledge into Rails 3. At Engine Yard, we fully intend to continue using Merb for our internal apps until Rails 3 is out, but we will be using those (non-trivial) applications to be sure the experience is smooth for everyone. There will be no huge jumps and you will not need to rewrite your application from scratch.
It's never a good time to start a complex application on a framework, really. It seems like there's always a major upgrade coming up or some other competing framework that may be a better bet. If you're having more success with Merb, stick with that right now and develop your project without fear! Both the Rails and Merb communities are going to have to cope with the merging of the projects with the release of Rails 3, but that's going to be awhile.
The project merge doesn't mean that Merb will be going away, however. Yehuda Katz will stop being the lead developer, but someone will take over the project. At the minimum, you can expect security patches and bug fixes for a few years, as long as you follow the official Merb developers' repository. Likely, after the Rails 3 release, you'll find great walk-throughs on upgrading your Rails 2.x/Merb 1.x application to Rails 3.
I'm wondering if it's possible to distribute a RoR app for production use without source code? I've seen this post on SO, but my situation is a little different. This would be an app administered by people with some clue, so I'm cool with still requiring an Apache/Mongrel/MySQL setup on the customer end. All I really want is for the source to be protected. Encoding seems a popular way to go for distributing PHP apps (eg: Helpspot).
I've found these potential solutions:
Zenobfuscate - not all types of Ruby code is supported however, so that counts that out
Ruby Encoder - may be the best option, as their PHP encoder looks alright (I haven't tried it however) but it's not available yet. I've used IONcube for PHP before and it worked well, but it doesn't seem that IONcube is interested yet.
Slingshot - it was mentioned in the other SO post, but it solves a different problem to mine and the source is still visible.
RubyScript2Exe - from the doco, it's not production ready, so that counts that out.
I've heard that potentially using JRuby and distributing bytecode might be a way to achieve this, but I've never used JRuby so I'm not sure what's involved.
Can anyone offer any ideas and/or known examples? Ideally I'd love to have some kind of automated build scenario as well.
Your best option right now is to use JRuby. A little bit of background: My company (BitRock) works with many proprietary and commercial open source vendors. We help them package their server software, which is typically based on PHP, Java or Ruby together with a web server or application server (Apache, Tomcat), the language runtime and a database (typically Postgres, MySQL) into a self-contained, easy to use installer. We have a large number of PHP-based customers (including HelpSpot, which you mention) but also several Rails-based ones. In the case of the RoR customers the norm is to use JRuby together with Tomcat or Glassfish although in some cases we also bundle a native Ruby interpreter to run specific scripts that rely on libraries not yet ported to JRuby (usually not core to the application). JRuby has matured quickly and in many cases it actually runs their code faster than regular Ruby. You will need to also consider that although porting your code to JRuby is fairly straightforward, you will need to invest some time on that. You may want to check JRuby Stack which is a free installer of everything you need to get started. Good luck!
If you release the source, obfuscated or otherwise, your app will be pirated. See, for example, Mint. It depends on what you're building, but you may find that you're better off releasing the app as a hybrid of sorts: A hosted app with a well-defined API, and a component that runs on the customer's server. As long as the true value of your product lives on the server side, you don't need to obfuscate your code, and you can just release the source code unmodified. Additionally, this may also give you the opportunity to reach clients running, say, PHP rather than Ruby. See, for example, Google Analytics, HopToad, Scout, etc, etc.
You can, but it wouldn't do anything to prevent somebody from reverse-engineering or modifying it. I remember there was an article about similar attempts to obfusticate Perl and how they could be effectively bypassed by a debugger and 5 minutes of effort.
If you can't wait for the delivery of RubyEncoder, then I think ZenObfuscate is the most promising. Though it may require some modifications to your source code, they do say this on their site:
ZenObfuscate costs $2500 for a site license or is individually negotiable for other licensing schemes. Yes, that is expensive. That was on purpose. But don't let that thwart you too much. If your product is really cool and we want to see it succeed, we'll make it work. "Really cool" is not freecell.
Of course, for $2500 (or more), you'd hope to get a few tweaks to the compiler that'd make your codebase fully supported. It might be worth engaging them in the conversation.
You can also take a look at Mingle from ThoughtWorks studios as an example of using JRuby for this.
It's a Ruby on Rails app, they run it using JRuby. They've customized jruby to load encrypted .rb files.
Take a look at JumpBox.
I've had conversations with them on the topic, and they seem to have a solution that will work soon for Rails apps.
I'm wondering if you could just "compile" the ruby code into an executable using something like RubyScript2Exe ?
To be honest I haven't used it but it seems like it could be what you want, even if it just packages up the scripts with the interpreter into a single executable.