I am (quite) an experienced programmer but totally new to Ruby and Ruby on Rails.
RoR looks great to get working quickly, specially the automatic screen generation for CRUD operations.
It really it gets you productive quickly.
The questions is with the last 20% of the work, when I must finish my application. Won't RoR conventions stand in my way? Because not every database table must be available for all users, and not all users can edit all columns and/or all rows, and the views must be adapted to my site's look and feel, etc.
I understand RoR has been used successfully in live sites, but how exactly do you gain enough speed in RoR to escape gravity after the first phase has been burned out.
I don't think scaffolding gets you 80% there. Scaffolding is nice in that it shows you how the pieces of Rails fit together, but I wouldn't build my application off of scaffolding code. Now that you've been impressed by scaffolding it's best that you forget all about it. :)
Where Rails really shines in my mind is database migrations, the awesomeness of how dynamic ActiveRecord is, and the plugin ecosystem.
There's a lot to learn when deciding to go with Rails. You have a new language, new framework, and new plugins - but if you take the time to learn those things you can be very productive with Rails.
I've been doing ruby on rails for quite sometime. The 80/20 problem is not unique for rails. It applies generally to the entire world. I'm also not aware of any framework that can just do business logic for you.
To answer your specific questions. Conventions will not stand in your way while doing the 20%. Instead, conventions will help you to get through that 20% quicker.
Personally, for user authentication, I use Authlogic. For user authorization, I use Lockdown or Authorization plugin depending on customer need.
I also use inherited_resource in most of my projects to simplify controller code. This is another power of convention.
To increase speed of development, you will not only need to know Rails, but rails gems/plugins that does the right things for you, so you don't have to reinvent the wheels again. Also, knowing Ruby language is a must for quickly develop beyond the 80%.
Ruby Toolbox provides some of the most popular gems and plugins used in typical rails projects targeted at specific domains. You can look through the relevant categories and know what most people use. (And it's probably a good idea to use popular, well maintained gems)
TDD/BDD style development will also help you to speed up in the long run.
Lastly, a warning: If you stray away from rails convention, you will have a painful time in general.
P.S. I used Merb before. My feeling is that conventions helps you in merb, but you won't get too much penalty for not following them in merb. However, my experience with Rails is that if you decide not to follow rails convention while developing rails app, it will come back to bite you in one way or another! So think twice when you really attempted to stray away from rails conventions... (This is from my own experience, and of course subjective, but you can think of it as a warning...)
Won't RoR conventions stand in my way?
Because not every database table must
be available for all users, and not
all users can edit all columns and/or
all rows, and the views must be
adapted to my site's look and feel,
etc.
This is a bit of a non-sequitur. Rails is a framework that has been lifted from real world applications. Those applications had to deal with all those issues also, as well as others you may not have thought of yet. Generally, the conventions make life easier once you learn them.
Another point is that the conventions are merely conventions. You don't have to follow them. You do not even have to use RoR for everything, though I've yet to find a case where I didn't/couldn't, I do generally try to push as much into the DB or cache layers as possible.
I don't believe that you'll ever have a serious problem with Rails conventions. Just stick with the conventions and trust the RoR system. The people behind Rails put a lot of effort into these conventions to support 99% of the common usage scenarios.
If you really need to do something outside the conventions it will eventually get complicated quite fast. However, you are not alone. There are a lots of excellent resources on the net to get help (for example the StackOverflow community).
To sum it up:
Stick with the conventions whenever possible (excellent resource to get started: Rails Guides.
Don't reinvent the wheel. Look for Rails plugins and Ruby Gems instead (don't forget GitHub).
Consult the StackOverflow community if you need something out of the ordinary.
Test all the f***ing time (just for fun).
Related
Working with Ruby on Rails for somewhile now. I'm enjoying it's builtin "Convention over Configuration" for small project. But, I'm little anxious about CoC application in Large Rails Projects.
I know some pre built-in configuration raises more difficulty than ease, when need to scale the application in broad.
What is those all specific Configurations will raise problem for me to scale? I will very grateful, if you please briefly explain those issues?
Convention over Configuration is more of a problem with estimates and prediction than scaling. Sometimes it just seems like everything is easy and all of a sudden, you will spend a lot of time on something that you thought was a 5 minute work. But all of this is actually a learning problem. Once you get proficient enough with Rails, the would be no danger anymore.
Concerning scaling, Convention over Configuration is not a problem at all. The problem here is that Rails is a strongly opinionated framework. If you do it the Rails way, Rails helps you. If not, Rails sometimes stand in your way. A few examples:
RESTful routes and controllers - what if your routes and controllers cannot be designed as RESTful resources?
Strict ORM mapping - what if you can't actually easily map database tables to objects and you'd rather work with joined data?
Other than usual CRUD pages, unconventional single page applications, wizards, etc.
I'm curious about alternatives to the components of RoR or RoR itself.
Some research brought up the ORM alternatives to ActiveRecord here on SO.
So remaining is the question about alternatives for...
... the controllers (ActiveController)
... the views (ActiveView)
... RoR itself
... any other component I'm missing here :D
Really, I'm very happy with all of them, but I'm asking out of pure curiosity.
In place of ActiveRecord, there are a few to choose from. The biggest competitor (and my favorite) seems to be DataMapper, then there's Sequel, Mongoid, MongoMapper. There are plenty of others too, but these are relatively big players.
In place of ActionView (not Active... Action... confusing, I know), I haven't come across anything. I've seen plenty of additions to it, but no complete replacements. I guess that means people are mostly happy with ActionView. Now, there are other template-engines available though. The big player here is HAML. Using HAML doesn't mean you're not using ActionView though. You're still using ActionView, just with a different template pre-processor.
Alternatives to RoR itself. Again, there are a few. The big players are Sinatra, Merb (which started in the early Rails days by some people who disagreed with a thing or two in Rails, and then Rails learnt a thing or two and took some bits and pieces back again... confusing!). There's also Ramaze, but I don't know much about it.
The thing is, Rails is more or less unrivaled in what it does. If you get your hands on a web app written in Ruby, it's probably going to either be a Rails app or a Sinatra app. Sinatra meets a different need to Rails. Rails wants to provide you with a whole array of tools to get things done quickly, while Sinatra's main goal is to be lightweight and keep out of your way. Rails is huge, while Sinatra basically boils down a glorified route map/dispatcher (I mean this in a good way), leaving you to build your web app however you see fit. Sinatra makes it easy to package a small web admin tool inside a gem, for example. You probably wouldn't want to include a Rails app inside a gem. That would be pretty overkill.
In terms of "other components", the big thing (though it's not a Rails thing) that comes to mind is Test::Unit. While Rails just ships with Test::Unit, and doesn't constrain you from using something else, it's worth mentioning that there are other testing frameworks available. RSpec is the other big player here, and there's also ZenTest. You may also look at Shoulda, which is an add-on, more than an alternative.
I been intersted in ruby and rails lately but what I always encounter in blog/ podcast / book is they will always teach how to use ruby or rails plugin/ ruby instead of writing one. Did we really always need to use plugin, even thing like authorization? Authenticate? Is it really waste time Or hard to write from start? Then if it hard and waste time why rails say make web development less painful?
Or I was wrong in term of concept? Goal ? Or anything else? Of rails? Anyone can guide me ?
It can be a good learning experience to write your own tagging system, or authentication system, or what have you. That's one argument for "rolling your own".
The argument for using libraries is the "standing on the shoulders of giants" concept. By using popular, actively-developed libraries, you can be reasonably sure that they're well-tested in multiple production environments and are extremely stable. And it gives you more time to focus on your actual application.
As an example, I would be very wary of writing my own system to process credit card payments when there are already full-featured, well-tested alternatives.
I think it really has to do with edge cases. With something you build yourself, you can think of many of the edge cases up front, but there are just as many that you will not be able to think of until you come to them. That's where the time savings comes in.
That being said, if you don't understand how to write an authentication system, then you should probably write your own. Conceptually you should fully understand how the parts of your app work, and if you don't, writing from scratch is a good way to learn. But with things that you already understand, I recommend using a gem.
Duplicate: Django or Ruby-On-Rails?
I have been reading on Ruby on Rails, and it seems like on some threads, some users like Django a lot too?
Can someone who have used both give some insight about using them, such as
ease of use
productivity
fun factor
deployment issues
or any other framework you'd highly recommend?
Both are excellent frameworks. Though, I've found Rails to be more suited for the agile developer. For the most part, you'll run some generators to get the files you need as placeholders for your code. Things will work right away, and you just build up from these conventions. It's really flexible and has a large community, lots of innovation and interesting practices are being put into Rails. It's development cycle seems faster paced than Django.
After only touching the surface with Django, it has some interesting differences. As far as I know, you don't get the schema migrations like Rails has out of the box. But you get an extremely simple CRUD mechanism for your models with the extensible admin interface, which is great for testing/managing content. The entire project is documented really well, from the Django Book to the vast amount of information on docs.djangoproject.com.
I personally prefer the Rails way of doing things. But honestly, you need to try them both to see what works for you, and since we're talking about two very good, yet totally different frameworks, it's a tough decision to make either way. So, if you already know Ruby or Python well enough, start with what you know and just go from there. Once you understand how one works, you'll be able to evaluate the smaller differences yourself. Hope that helps.
I'm planning on taking the time to actually learn Ruby on Rails in-depth (I've previously done some very minor dabbling with it) so I can hopefully reinvent myself as a Rails developer.
The issue I run into though is that there are a fair bit of related technologies that are currently used in the Rails community, and I'm not sure if I should learn the whole shebang or focus on learning Rails with the defaults first, and then branch out into the additional stuff.
For example:
Templates. I took a look at Haml and it looks really cool (shouldn't be hard to learn either).
Testing. I've wanted to learn test driven development for a while now, but the "next big thing" in Rails-land seems to be behavior driven development with RSpec
Javascript. I'm not sure if I should stick with RJS or use something like jQuery which seems to be converting people.
I've never really used version control much. Rails seems to be using Git for most of it's projects.
Basically I want to learn Rails "right", but there seems to be a lot of different ways that I could go. Should I ignore the "variants" and focus on the Core stuff until I've written an application or three (e.g. core, unmodified Rails; RJS w/Prototype and Scriptaculous for Ajax, regular Test::Unit for testing, ERB for templating, Git for version control), or should I try to pick up some of the variants along the way?
If you want to do well in the rails world you should plan on learning (and relearning) things on a regular basis. It isn't as hard as it might sound, but it is important. I'd suggest you make a list of things to learn, and just work your way down it doing by getting an hour or so of hands-on-time with something new each day. If you feel like there's more to learn (or that the subject is in flux) throw it back on the tail of the list to revisit another day.
A starter list (yours plus a few you didn't mention), in no particular order:
erb
gems
acts_as...
test driven development
git
rspec & behavior driven testing
javascript
prototype.js
jquery
sql
rail's finders
rake
the rails console
plain old ruby
duck typing
ruby's metaprogramming facilities (how the magic is done)
css
rails generators
And so on and so forth. As you're going through one and come across something interesting, throw it on the list.
The point is, if you try to take a narrow view you will probably make life harder on yourself and learn slower than if you make a commitment to perpetually, steadily expanding your horizons.
I've been a full time rails developer for over a year now and what you use really depends on what kind of team you end up on. I've barely used RJS, have never used RSpec, but I use git, jquery and rails every single day.
My Advice: stick with rails for at least a few months. There is plenty to learn in the framework alone. I would consider ignoring RJS as I feel like it's going out of "fashion" as developers trend towards jQuery.
Regular Test::Unit is great, although I like to add thoughtbot's Shoulda to provide some testing macros that save a whole lot of time (consider ignoring all the Shoulda context stuff though).
Learning git feels pretty important IMHO, mainly because it's a great and is gaining quite a bit of popularity. It also enables you to feel comfortable using github, which can be a big advantage.
I'd recommend starting out with the basics of Rails. Haml, RSpec, jQuery, and Git are all great things, but if you try to learn it all at once, you may become overwhelmed.
I would start with the defaults first, as I agree with Matt's comment that trying to learn it all at once would be overwhelming.
Plus it may turn out that depending on your applications you may or may not need jQuery, you may be happy with the default testing, and there are tons of ways to do templates so starting with ERB to get the basic understanding of how the view/templating works is a good idea.
Once you get more experience and know exactly the requirements you will have for your application(s), you can then more easily pick up and swap out some of the variants.
Git is important. Make an account on github, install git, and get used to it - you need some kind of version control, might as well make it the new cool buzzwordy one.
The other stuff, not so much. Bang out a few applications and then add them in one at a time.