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).
Related
I'm new to Ruby on Rails and have been seeing people use auto boilerplate generators like Rails Brick or Rails Composer to create boilerplate user-management systems, etc. Coming from a background that doesn't trust auto-generated code, is it good/legitimate practice in Rails to use such systems. Also, I'm working on a project with a startup. Is it fine to use such generators and how widespread a habit is this.
P.S. Mods please note that this is not a question asking comparisons/opinions/disputes. I'm curious about the general practice in Rails and how often is this used in production.
I'm the maintainer of Rails Composer so I believe I can answer this question with authority.
I respect (and share) the urge to build from scratch. That's a healthy impulse. Rails includes a facility for application templates (Rails Composer is an application template) because automation saves time and effort. For people who build many web apps, a time comes when you decide to automate the process.
Rails Composer offers an advantage over roll-your-own application templates because it is open source, used by thousands of developers with code contributions by many. As Rails and gems change, Rails Composer gets updated so you get a current "reference implementation" every time. It gives you well-tested starter apps that integrate all the bits and pieces that require tweaking, like RSpec plus Capybara and FactoryGirl, flash messages and navigation with either Bootstrap or Foundation front-end frameworks, Devise or OmniAuth for authentication, Pundit for authorization, and many utility gems that developers like to add (Guard, Pry, etc.). It lets you choose your stack (for example, ERB, Haml, or Slim), offering choices to the extent that the community has contributed options.
If you're concerned about the safety of running an install script, the code is open source and used by thousands of Rails developers (you can see over 2000 watchers on the GitHub repo). It's purely an application template using the Thor library, and though in theory someone could contribute code that tampered with your files, we'd never accept a pull request like that. Rails Composer only offers well-known popular gems, so you are not exposed to potential risk of using unknown gems.
Rails Composer is widely used, particularly by consultants who build lots of apps. Many of the prominent consulting firms have an in-house application template (Thoughbot Suspenders, for example) and some use Rails Composer or the rails_apps_composer gem that generates custom application templates. Developers who work on on only one application regularly (maintaining a big project, for example) tend to be less familiar with application templates like Rails Composer, but it is popular with developers who start a lot of apps.
Stack Overflow is not a place for opinions, so if you want a range of opinions or debate about the merits of Rails application templates, Reddit or Quora might be a better place to ask.
Welcome to Stack Overflow! I hope all your questions will be answered accurately and timely.
I'm the developer of Prelang which is similar to the generators you mentioned. It differs by adding data modeling, GitHub integration, and deeper configuration for some features. Like Daniel, I believe I too have some authority on this and agree with his very complete answer.
To answer your question, Prelang is newer but it's already used by thousands of developers ranging from beginners to dev shops.
I'd like to note that Prelang (and the other builders) are different than what you traditionally think of when you hear "code generation". When working on Prelang, my goal is to automate "everything that a Rails developer would have done anyways". Prelang does generate methods/code but mostly it's automating install processes of Gems, setting configuration values, creating models, and running rails commands. That said, Prelang is opinionated in terms of which gems it uses but I've selected the most popular gems for each feature and will give the flexibility to choose between multiple routes once I get a little more traction.
Prelang also makes real Git commits so you can look through every commit after your project generates giving you full visibility into your codebase. This is intended to further ease concerns relating to generated code.
Erik
Most gems are so easy to set up nowadays, that I think you won't need such a generator. After all it's just a question of taste – I like using the command line, and I like knowing exactly what's in my codebase. From my personal experience, I have never seen someone use such a thing in professional Rails development, but clearly there are people out there who use them.
The one case I can think of where these generators make sense is when you're bootstrapping projects very frequently. In this case however, I find the existing generators not to be flexible enough. Thoughtbot for example has built their own app generator called Suspenders, which of course includes a very opinionated set of gems etc. but it gives them exactly what they need.
As a side note regarding your security concerns: for me, the dependency trees that are spanned up when you use many gems are a far worse security threat. For example in a medium sized Rails project it is not uncommon to depend on 100+ Gems; no-one can read all of them. You'll have to trust all of those as well.
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.
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.
I have a memory of talking to people who have got so far in using Ruby on Rails and then had to abandon it when they have hit limits, or found it was ultimately too rigid. I forget the details but it may have had to do with using more than one database.
So what I'd like is to know is what features/requirements fall outside of Ruby on Rails, or at least requires such contortions that it is better to use another more flexible framework, even though you may have to lose some elegance or write extra boilerplate code.
Rails (not ruby itself) is proud to be "Opinionated Software".
What this means in practice is that the authors of rails have a certain target audience in mind (themselves basically) and aim rails specifically at that. If X feature isn't needed for that target audience, it doesn't get added.
Off the top of my head, things that rails explicitly doesn't support that people may care about:
Foreign keys in databases
Connections to multiple DB's at once
SOAP web services (since rails 2.0)
Connections to multiple database servers at once
That said, it is very easy to extend rails with plugins, and there are plugins which add all of the above functionality to rails, and a lot more, so I wouldn't really count these as limits.
The only other caveat is that rails is built around the idea of creating CRUD web applications using MVC. If you're trying to do something which is NOT a CRUD web app (like twitter, which is actually a messaging system, or if you are insane and want to use a model like ASP.NET webforms) then you will also encounter problems. In this case you're better off not using rails, as you're essentially trying to build a boat out of bicycle parts.
In all likelihood, the problems you will run into that can't just be fixed with a quick plugin or a day or 2 of coding are all inherent problems with the underlying C Ruby runtime (memory leaks, green threads, crap performance, etc).
Ruby on Rails does not support two-phase commits out of the box, which maybe required if your database-backed application needs to guarantee immediate consistency AND you need to use two or more database schemas.
For many web applications, I would venture that this is not a common use-case. One can perfectly well support eventual consistency with two or more databases. Or one could support immediate consistency with one database schema. The former case is a great problem to have if your app has to support a mondo amount of transactions (note the technical term :). The latter case is more typical, and Rails does just fine.
Frankly, I wouldn't worry about limits to using Ruby on Rails (or any framework) until you hit real scalability problems. Build a killer app first, and then worry about scalability.
CLARIFICATION: I'm thinking of things that Rails would have a hard-time supporting because it might require a fundamental shift in its architecture. I'll be generous and include some things that are part of the gem/plugin ecosystem such as foreign key enforcement or SOAP services.
By two-phase commits, I mean attempting to make two commits to physically distinct servers within one transactional context.
Use case #1 for a two-phase commit: you've clustered your database, so that you have 2 or more database servers and your schema is spread across both servers. You may want to commit to both servers, because you want to allow ActiveRecord think do a "foreign key map" that traverses across the different servers.
Use case #2 for a two-phase commit: you're attempting to implement a messaging solution (sorry, I'm J2EE developer by day). The message producer commits to the messaging broker (one server) and to the database (a different server).
Also found some good discussion about the limits of ActiveRecord.
I think there is a greater “meta-question” here, that could be answered and that is “when is it OK to lean on external libraries to speed up development time?”
Third party libraries are often great and can drastically reduce development time, however there is a major problem, Joel Spolsky calls this “the law of leaky abstractions.” If you look that up on Google his post will come up first. Essentially this means that the trade off in development time means that you have no idea what is going on under the covers. So when something breaks you are completely stuck and have very limited methods of debugging. This also means that if you hit one of the features that are simply unsupported in RAILS, that you really need, you’ll have no next step except to write the feature yourself, if you’re lucky. Many libraries can make this difficult to do.
We’ve been burned badly in my dev shop by this issue. Our solutions worked fine under normal load, but we found that the third party subscription libraries that we were using simply could not stand up to the kind of load that we experienced once our site started to get a large number of concurrent users. This puts us in a very difficult place; essentially we have to rewrite the entire subscription service ourselves, with performance in mind. Doing this means that we’ve wasted all the time that we spent using the library.
Third party libraries can be great for small to medium sized applications; they can drastically reduce development time and hide complexities that aren’t necessary to deal with in the early stages of development. However eventually they will catch up with you and you’ll likely have to rewrite or re-engineer your solution to get past the “law of leaky absctractions”
Ruby don't have a functionality like IsPostBack in ASP.Net
Orion's answer is right on. There are few hard limits to AR/Rails: deploying to Windows, AR connectors that aren't frequently used, e.g. Firebird, ), but even the things he mentioned, multiple databases and DB servers, there are gems and plugins that address those for legacy, sharding, and other reasons.
The real limitation is how time-consuming it is to keep on top of all the things that rails devs are working on, and researching specific issues, given how many blogs, and how much mailing list volume there are.