Tomorrow, I will meet a client that is not working in technology but might ask if RubyOnRails is the right choice for his site. He might think that there's not enough RoR programmers and that he will be "hostage" of the language.
I have good reasons to use RoR and the client has good reasons to like it (it costs less!).
Do you have "official" sources I could show them?
Using a framework ensures that the "next guy" can pick it up quickly
Rails has reduced my workload by 80% over hand-coding.
Huge, active, friendly community to draw upon
Self documenting testing frameworks
It uses Ruby, which is super easy to learn in a pinch
Open source language, framework, and database that uses an open source OS. FREE sells.
This is, in some sense, a variant on the "bus hit factor" problem. Any app, once developed, is pretty much "hostage" to the language, the question is whether it is also "hostage" to the single developer who wrote the app. I think that RoR is a perfectly reasonable choice for development, but the issue is really how many developers in your local area are available to take this over if you happen to "get hit by a bus." If the customer is willing to work with someone remotely, this becomes much less of a problem. To reassure him, though, I'd first look to the local scene and find out about local Ruby developer groups. The presence of active, local developer groups is one measure that might convince him.
If, on the other hand, he's concerned that RoR will not continue to be viable in the future that is a slightly different issue. Again, I think you're ok -- you may want to point out other applications that are written using RoR as an indication of continuing pressure to improve both the language (Ruby) and the framework (Rails). You can find a lot of this information at http://rubyonrails.org/.
"might ask if RubyOnRails is the right choice for his site. He might think that there's not enough RoR programmers and that he will be "hostage" of the language."
Have you considered the possibility that these are valid concerns that should be taken seriously?
"I have good reasons to use RoR"
How does that help your client, though?
"it costs less!"
Does it? Do you have any specific evidence to support that assertion? Have you factored in hosting costs? Rails on MRI uses a lot of RAM. You're probably in Java territory or worse. Depends on the app and the load of course. Phusion Passenger (mod_rails) has improved the situation somewhat, but it's still an issue.
As mentioned by others documentation is a "HUGE" issue. Ruby and Rails official docs are sparse, to put it kindly. The community tends to rely on paper books which become outdated and misleading in a matter of weeks, thousands upon thousands of unreliable, contradictory blog posts, and screencasts which also suffer severely from the "quickly-outdated" problem. Don't think PeepCode is going to save you.
I would still consider advising a client to use Rails because the claims of programmer efficiency are more or less true, sort of, but I'd do so with extreme caution and I'd let him know the downsides.
Documentation is HUGE when it comes to open-source projects.
One thing you could do would be to explain to your client that it will cost them much more to have you and your developers spend hours and days searching for documentation on some other open-source framework that is less used and supported. Explain that there may not be as much ROR developers out there as there are PHP developers per say, but the fact that there's such a great amount of documentation and information about ruby and rails makes it exponentially easier to for any open-source developer to learn and use the framework.
There would be some things I would try to convince the client-
Ruby Community is huge
Ruby is mature enough
Ruby works with most database systems.
Rails is a product based on an Idea(MVC) most other platforms have embraced.
Improved readability and testability of code.
COSTS LESS!!
Migration methodology in RubyOnRails
If you want you can even target the Java Platform using JRuby and Java Platform is a pretty respectable platform.
Show some cool RoR applications.
Explain how you could be Agile!
I know so well clients not agreeing when you dont have a big company backing a technology.
The "cost less" feature of RoR is debatable, I agree with you. But in my case, I have a complete RoR-ready environment and I know that I can charge less for a RoR app than any PHP app that I could do.
The hardware/software environment for PHP and Rails are almost the same... so is the price of it. What will cost less for the client is the robust environment that we built.
That's the "cost less" feature. I'm not talking about about memory comsuption or anything else. It all can be bought for almost nothing.
This depends a lot on location. If RoR developers are plentiful and work for prices comparable to other programmers then you can use that to help sell Ruby.
For a client one of the main concerns is cost. Perhaps he is concerned about maintenance costs of finding and paying for a RoR developer, not the cost of the technology.
I know a web shop who was bitten by the relative 'newness' of RoR. They hired a developer to make a site and that developer use RoR. After the project the developer left. In our area RoR developers are not only scarce, they charge more than any other type of web developer. In this particular case the web shop ended up losing their client. The last I checked their client's web site is in PHP.
I'm not trying to say RoR is bad and I think that's an extreme case, but make sure to consider the client's concerns. The cost of maintenance is a very valid concern.
Related
thanks for opening my question :)
I am a university student in Computer Engineering, and I've always done class projects in Java (apart from C, and Assembly, but for very specific things). Apart from that, I have worked for quite a lot of time on a web app done in ActionScript 3, contained in .jsp files and deployed onto a Google App Engine site.
Having that said, I now pretend to do a prototype of another web app, which will have registered users with blogs and a messaging system between them.
My question is, having time as a restraint (I have month and a half), and needing just to build a working prototype, could anyone tell me, in his/her opinion, what would be the best framework for me to start learning and use? (Take into account my Java & ActionScript background) I believe RoR is the most common in these cases, as its easy and quick, but I have no Ruby knowledge at all, and maybe it would be quicker for me to learn Scala (which coming fromJava shouldn't be that different) and Lift, and do it with them instead.
Many thanks in advance!
Pepillo
Last year I found myself in a very similar situation for creating a web based relationship browser for a computing science class. I would highly recommend RoR. Granted you will need to spend some time getting up to speed with Ruby, but it is well worth the small amount of time to learn. There is excellent documentation available and a ton of good tutorials.
Rails can generate much of the core code and database schema with the generator functions in seconds (see scaffolding generators). Considering your time constraint, I think this alone makes rails a good choice.
In terms of learning Ruby, you should not have much trouble with this if you are comfortable with any dynamically typed scripting languages.
Anyway, that has been my experience with rails. Good luck on your project!
I think I'm going with Play! Not only is the easiest for me, as I am a Java guy, but it's also the quickest when in conjuntion with Japid, according to a benchmark I saw.
I used Java for about 7 years now, mostly for web applications, and recently started using RoR. I must say it was really easy to pick up and get started. After only 2 months of working on my own project I started using it for a customer projects and it was far more easier to deliver production code then I had anticipated. So yes I can recommend Ruby and it was not hard at all to pick up.
However, RoR does require a nix platform like apple os or linux. I stated out with windows but there are simply too many drawbacks and bugs.
If you decide to go with ruby I can higly recommend Agile Web Development with Rails (Pragmatic Programmers) to get you started.
I have some (I think) really great ideas for an online strategy game similar to Travian. There's some content that I haven't yet figured out and some other challenges that I don't know of yet.
This is quite a big project and perhaps too heavy for one person that isn't a skilled web developer (yet). I'd still like to give it a shot, but I'm having trouble choosing a platform. The world "scales" has been thrown around a lot lately and I've seen Ruby on Rails being bashed because it doesn't scale well, so I've come here to get some answers.
I like Ruby on Rails, both Ruby and Rails. I'm certainly no expert at it but I love working with it. I have also worked with Python + Django before and also with PHP (which I am not fond of.)
Ideally the game would have, let's say, 7000 players per server, presumably a lot of data to be processed per second. Would RoR still be a viable platform?
I'm sorry if this question is vague, I guess I'm looking for a "RoR is fine, go at it!" kind of answer. Anything you might want to add is fine.
Thanks!
So if I were you, I would be looking into non-blocking servers like node.js, just because they are MUCH more suited to keeping many connections open for long periods of time, which is what games need to do, compared to traditional web servers.
That being said
There are 3 main things to worry about when you are scaling a web app; memory, execution speed, and io (hd and network) in that order.
For memory, things are much better then they used to be. Phusion Passenger uses copy on write to fork its workers, so the rails environment will get shared among all the workers on a given slice, which is pretty significant. There have also been huge improvements to the way ruby manages memory compared to "the dark times", if you are using 1.8.7 then you want to be using the patches that make up Ruby Enterprise Edition (the difference is like night and day). 1.9.x was pretty much a total rewrite of the runtime, so if you are using that the memory issues ruby had have already been addressed.
For execution speed, 1.8.7 is typically "fast enough" (at least after tuning garbage collection settings). 1.9.2 is actually around the same speed as python, which puts it on the faster side of interpreted languages. How important this point is completely depends on the nature of your application.
Last point is IO, which isn't really a concern of rails, but more your persistence strategy. Rubyists tend to love new things, so you will find first class support for things like redis and mongodb, with loads of people talking about using them and their wins/gotchas. I would look into mongo if I were you and see if the durability trade-offs are acceptable.
I was in java/.net before going to rails, and at the end of the day you are going to pay more for infrastructure, but the amount will be completely dwarfed by what you save in development time.
build it in Rails, host it on Heroku.com - job done. Almost infinite scaling that you don't have to worry about how it works (it just does) and it hosts a lot of highly trafficked Facebook apps so can more than handle it.
I think Ruby on Rails is a good choice for what you need. Actually, we recently created a platform for an online gaming tournament, where players and their gaming bots were playing a logic game.
We used Ruby on Rails and Sidekiq on the backend, ReactJS and WebSocket on the frontend. And it worked well for a quite massive number of players. Here is the tutorial based on what we learnt while building it: How to Write a Game Engine Using Ruby on Rails
As you said yourself, you already have the answer and you are only looking for encouraging words:). I am not RoR expert myself, but I don't think scalability is still such a great issue on this platform. I would advice you to do an architecture spike (XP terminology). Write a test with 7000 clients and method which would perform similar operations to what you intend to create. For example you might load files, render views or even just wait... The point is to test only the thing you are worried about. Good luck!
This is a bit of an impossible question to answer because in order to know whether rails is suitable for what you want to do we would need to a lot more about what you are trying to do. The best advice I can give in the absence of information is for you to check out the railslab scaling videos in order to work it out for yourself.
We've got an Excel spreadsheet floating around right now (globally) at my company to capture various pieces of information about each countries technology usage. The problem is that it goes out, gets changes, but they're never obvious, and often conflicting - and then we have to smash them together. To me, the workbook is no more than a garbage in/garbage out type application waiting to be written.
In a company that has enough staff and knowledge to dedicate to Enterprise projects, for some reason, agile and language/frameworks such as Rails, Grails, etc. are frowned upon. That said, I can't help but think that this is almost a perfect fit for the need, given the scaffolding features for extremely simple implementations of capturing raw fields with only a couple lookups (i.e. a pre-defined category). I'm thinking this would be considered a very appropriate use of these frameworks.
Has anyone worked on these types of quick and dirty apps before in normally large-scale, heavy-handed enterprise environments with success? Any tips for communicating this need/appropriateness to non-technical management?
The only way to get this implemented in a rigid organization is to get this working and demo it -- without approval. It's very hard for management to say no to a finished project.
I work for a really big company & have written many utility apps based on Rails (as well as contributed to some larger Rails projects). That said, the biggest concern is not the quality of the app, but who's going to support/maintain it when you leave or get hit by the bus.
IMHO, The major fear that an enterprise organization has - especially if the application becomes more critical to it's core business - is how to support it. If it doesn't fit into it's neat little box of supported technologies, it's less likely to happen.
Corporations have been bitten by this many times in the past & are cautious when bringing in new technology.
So, if you can drum up more folks to learn Ruby/Rails in your group (or elsewhere in your company), you may be able to make a good case for it. Otherwise, sad to say, your probably better off implementing something on Sharepoint :-(.
If you already have a Java infrastructure, then creating a Grails app will require little to no additional IT ramp up to support and maintain. The support and maintenance cost and effort should be the same as for a Java application (i.e. Grails apps run on Tomcat, use the same JVM, use the same diagnostic/profiling tools, etc.).
In my experience, larger IT organizations have a harder time supporting Ruby when its not already in the toolchain because its a new language, new deployment environment, and requires a considerable amount of support and maintenance ramp up.
I would develop a minimal viable product, then make friends with someone in IT who can help you deploy it into a staging or production environment. Then get a few of the users to hop on board and test it like its a Beta product. After that, open it up to a larger audience.
So as others have said, forgiveness over permission, but be smart about the impact on the IT organization.
I am working on a project for a client of the IT company I work for and I am convinced that Rails is perfect for it. I have a meeting in the next day or so, where I am afraid I am going to get bombarded with "why Rails?" type questions, and no doubt, a whole bunch of rhetoric like "Rails doesn't scale", "Rails is just a CMS" and the thousand other myths people seem to have about Ruby on Rails.
We have all seem the arguments about how Rails doesn’t scale, it’s hard to deploy or that it will explode in your hands at any given moment. For those of us that use Rails on a daily basis, we know that just like any other language or framework. It seems like there is a lot of misinformation about RoR and often Rails gets a bad wrap. To help me with this meeting, I was hoping to compile a list of myths - perhaps one myth per answer - and we can vote for the myths we've heard before - to eliminate the Fear, Uncertainty and Doubt that often clouds the truth about Rails.
After some googling I found this blog post which is exactly the kind of thing I'd like to collate here. As David Heinemeier Hansson says in the post:
So I thought it would be about time to
set the record straight on a number of
unfounded fears, uncertainties, and
doubts. I'll be going through these
myths one at the time and showing you
exactly why they're just not true.
This is not really to convince you
that you should be using Rails. Only
you can make that choice. But to give
you the facts so you can make your own
informed decision. One that isn't
founded in the many myths floating
around.
Let's Clarify!
Myth: "Ruby on Rails doesn't scale"
Bust: That is not a specific, answerable question. Please clarify.
Saying that whatever-technology "doesn't scale" sounds very professional and very enterprisey - but it's not a clear question. It's just a lazy way of dismissing the unknown/unproven I'd ask for clarification:
"What precisely do you mean by 'scale'? and how do you measure it at the moment?"
It could mean:
Maximum user sessions
Average response time given load
Throughput of given concurrent scenarios per server in a fixed time.
... difficulties organising the project so a large team of developers could work on it.
There are lots of ways of dealing with "scale" but until you know which one you're dealing with it's not always obvious what to do about it.
There are loads of ruby-based solutions, including
caching fragments of HTML
sharding the application across multiple databases
pre-computing work that's shared between users
pushing lots of view-rendering work off into AJAX/Javascript land so it happens on the client
using a front-end web server more efficiently
just use more hardware (i.e. developer time is expensive & hardware prices fall) but this approach depends on a shallow rate of growth in demand
doing less interactively and having more batch work
doing only part of the work in ruby - e.g. existing legacy backend+rails frontend, or maybe the transactions through a functional programming system+rails frontend
If the challenger can't come up with a specific meaning of "scale" then it isn't a valid concern.
However if the challenger does come up with something specific and measurable, then I'd use a timeboxed, spike solution ( http://c2.com/xp/SpikeSolution.html ) to come back with some numbers - and possibly a few options on how to do it.
Make the argument from the only perspective the client understands, money!
Show how long you think it will take to make in Java, JSP, or whichever is their current technology, together with the pros and cons, such as easier to obtain developers. Then, state the timescales in Ruby, which for sure will be lower development costs, but also at a cost of the admins having to deploy a different system, possibly harder to recruit staff who know Rails, etc. Its their money, so give them the facts and let them make the decision.
In response to the specific criticisms a company could have against Ruby on Rails compared to their own systems there are many reasons a company can give, some of them not specific to Ruby or Rails, such as they already have many Java develops in house, or existing infrastructure written in Java, which will always be easier to use with a same language system such as Java. Anyway, to answer your specific points:
1) Why Rails?
Simple, Rails is "designed " for building web sites, and does an efficient job. Find some statistics to back you up (I'm not saying the statistics in the link are accurate but numbers will always impress a client)
http://www.theserverside.com/news/thread.tss?thread_id=33120
2) Rails doesn't scale
http://trak3r.blogspot.com/2008/03/rails-doesnt-scale.html
3) Rails is just a CMS?
If they are building a CMS then recommend Drupal, not Rails
I guess you will have to think on your feet when you answer your clients questions, and they will want someone who understand other frameworks apart from just Rails, kind of like using the right tool for the right job
Myth: Rails is not mature enough to have the plethora of hardened open source libraries built around it that one needs to pull off a large scale project quickly and reliably.
Bust: In fact, there are a ton of gems and plugins available to the RoR community, many of which have been tried and found true by the active community. Not only are the resources there, but they are simple to manage with 'gem' and Rails' built-in plugin architecture. Worst case scenario: you can't find that perfect gem or plugin. In that case you can easily write your own or borrow from the Java world if you use JRuby.
Myth: it is hard to hire a good Ruby on Rails programmer.
(Actually, I can't bust it, that's just an idea of a potential myth. Who can, please, edit this one or create another answer)
I'm a big fan of ruby on rails, and it seems to incorporate many of the 'greatest hits' of web application programming techniques. Convention over configuration in particular is a big win to my mind.
However I also have the feeling that some of the convenience I am getting is coming at the expense of technical debt that will need to be repaid down the road. It's not that I think ROR is quick and dirty, as I think it incorporates a lot of best practices and good default options in many cases. However, it seems to me that just doesn't cover some things yet (in particular there is little direct support for security in the framework, and plugins that I have seen are variable in quality).
I'm not looking for religious opinions or flamewars here, but I'd be interested to know the community's opinion on what areas Rails needs to improve on, and/or things that users of Rails need to watch out for on their own because the framework won't hold their hand and guide them to do the right thing.
Regardless of framework the programmer needs to know what she's doing. I'd say that it's much easier to build a secure web application using something as mature, well designed and widely adapted as Ruby on Rails than going without the framework support.
Take care with plugins and find out how they work (know what you do, again).
I love Rails too, but its important for us to understand the shortcomings of the framework that we use. Though it might be a broad topic addressing these issues wont hurt anyone.
Aside from security issues, one other big issue is DEPLOYMENT on Shared Hosts. PHP thrives in shared hosting environments but Rails is still lagging behind.
Of course most professional Rails developers know that their apps need fine-tuned servers for production and they will obviously deploy on Rails-Specific hosts.
In order for Rails to continue success the core team should address this issue, especially with Rails 3.0 (Merb +Rails) coming..
An example of this is simple: I have a bluehost account, and i noticed the Rails icon in my cpanel. I talked to the bluehost support and they said its more or less a dummy icon, and that it doesn't function properly.
Having said that any professional who wanted to deploy a Rails App would not use bluehost. , but it does hurt Rails, when hosts say that they support it and then users run into problems which their support know nothing about..
The article you refer to defines technical debt as
[the] eventual consequences of
slapdash software architecture and
hasty software development
With rails, any development that is not test driven incurs technical debt. But that is the case with any platform.
At an architectural level Rails provides some deployment challenges. A busy site must scale with lots of hardware or use intelligent caching strategies.
My advice to anyone adapting Rails would be to:
use TDD for all your development
verify the quality off any plugin
you use by reading its tests. If
they are not clear and complete,
avoid the plugin
read "Rails
Recipes" and "Advanced Rails
Recipes" (Advanced Rails Recipes has
a good recipe for adding
authentication in a RESTful way)
be prepared to pay for hardware to scale your site (hardware is cheaper than development time)
From my experience, by far the biggest tolls you end up paying with RoR are:
Pretty big default stack (not counting plugins you might be using)
Updating models tends to be a pain in the ass, at least in production servers.
Updating Rails or Ruby themselves is a bit more complicated than it should, but this differs depending on your server setup.
As ewalshe mentioned, deployment is sometimes a drag, and further down the road, should you require it, scaling gets a bit iffy, as it does with most development frameworks.
That being said, I'm an avid user of RoR for some projects, and with the actual state of hardware, even though you do end up paying some tech debt to using it, it's almost negligible. And one can hope these issues will be reviewed eventually and solved.
With any level of abstraction there is a bit of a toll you pay - genericized methods aren't quite as fast as those specific to something built just for your purpose. Fortunately though, it's all right there for you to change. Don't like the query plans that come out of the dynamic find methods? write your own, good to go.
Someone above put it well - hardware is cheaper than developers. I'd add "at a sufficiently low amount of hardware"
I'm reading Deploying Rails Applications and recommend it highly to answer your concerns.
The book is full of suggestions to make life easier, taking a deployment-aware approach to your Rails development from scratch, rather than leaving it to later.
I don't think the choice of RoR implies a technical debt but just reading the first few chapters alerted me to practices I should be following, particularly on shared hosts, such as freezing the core rails gems so you can't be disrupted by upgrades on the host.
The 30-page chapter on Shared Hosts includes memory quote tips such as using multiple accounts (if possible) with one Rails app per account. It also warns about popular libraries such as RMagick possibly pushing your memory size to the point where your processes are killed (such as a 100MB limit, which it suggests some hosts periodically apply).