Ruby on rails development flow/order

Question

Now that college is out for the summer and my classes have come to an end I need to be able to keep my mind sharp over the summer. I've decided to try my hand at making a nice enough ruby on rails app from start to finish.

I've tried doing this before but the problem I always run into is: "I can't really finish this until that's done but it seems like it won't work unless I finish this other thing that need the first thing to work."

Basically my project gets out of hand really fast because I have no direction regarding what to work on and when.

My question to you, oh great and wise community of SO, is what is the most accepted way to go about developing a rails app.

Do I start with models, views, or controllers? Is it better to make the HTML first or the server code? What is the best way to get things done?

Thanks in advance!

Answer 1

• Design
• Decide which features you are going to implement
• Decide which gems you are going to use to implement those features
• Configure and implement those gems/features in isolation - Use Git
  • Realize that you are spending a lot of time here.
  • Consider trimming the features or simplifying the design. Maybe go back to the top.
• Start coding your master app - Use Git
• Configure those gems together - Use Git
• Write the Models - Use Git
• Try to write controllers and views(Use scaffolding to get started, that way you'll be doing more hacking and less coding) - Use Git
• Run into a problem in last three steps, or discover a new feature that you must implement to make everything work.
• Solve that problem in isolation (in a separate rails app) - Definitely Use Git
• Repeat

About Using Git

Damien Roche has suggested in the comments to use Git branches instead of testing new tools in isolation.

I have been using Git with Rails from the beginning, and I recommend using Git branches and testing new tools in isolation.

e.g.: You can see a public Github repository of mine here: https://github.com/spundun/emblem-coffee-emberjs-rails-starter-kit . It's a simple single branch repository where I document each step I'm taking to incrementally shape my project.

But when using a new tool or library, many times things will break, and you will start with no clue as to why things don't work the way they say it will, in the tutorial. Did I use the wrong version of the library? wrong version of Rails? Did I add tools in the wrong order?

To make sense of such problems, many times you'll want to compare a working directory that works with working directory that doesn't. Meaning you will want to have two working directories side-by-side.

Of course you can achieve the above by cloning one directory into the other and checking out two different branches, but we are getting ahead of ourselves. Before making a gem co-exist with a dozen other gems that you are using, you should make sure that you know how to get it to work in the simplest of the scenarios. Meaning with vanilla rails, with the bare minimum that is required.

So first you will make this isolated branch incorporating the new gem into a vanilla rails app. This branch is not related to your main branch in anyway, except it should use the same version of rails that you are using for your app. You can host it in the same repository or a separate repository, really doesn't matter.

Once you feel confident that you know how it's supposed to work in isolation, you can trace all the steps you took using the commit log of that isolated branch and incorporate those commits as appropriate in a feature branch on top of your master branch. And when you are done fixing bugs and making all the gems work in harmony, your feature branch is ready to be pulled into the master branch.

HTH.

Answer 2

Many software development methodologies exist and continue to evolve albeit at a slower rate than the programming languages they implement. I'd recommend researching the Agile Manifesto and memorizing it's principles.

My typical Rails application workflow:

Write and implement a feature (Cucumber).
Write and implement a spec (RSpec).
Write a benchmark and refactor.

Answer 3

I think it's a good question and I expect to see some insightful answers here. In my opinion it's something that comes with practice, and you will constantly switch between M, V and C. I think the Model is usually the first part to implement, as it is often determined by the real world problem domain and therefore less fluid and subjective. Then the Controller and the View next. If you just implement the smallest working part with each iteration you get to see results sooner and it helps for not getting bogged down. (Although I like to try and define all fields in my model up front).

But really the best way to not get lost is step back and take pen and paper and sketch out the main workflow and entities in your system, in whatever notation works for you. Keep it simple so that you can visualise the main stuff your system does end to end, on just a page or two. Then when you're implementing, those designs can serve as a map for where you are in your build.

Of course you could also try to specify system tests up front (or rspec feature specs) to define what the system should do. This has never worked for me to be honest.

Answer 4

The Rails community strongly promotes some form of test driven development. When you're just getting started, it probably doesn't make sense to start out writing tests, but you can still keep the same approach.

So, essentially you would just try to do what you want in the browser and write what you need as you need it to accomplish that.

So getting started, just generate a new rails app and start the server. It will give you the default Rails environment information. You don't want that to be the home page, so you go to the routes.rb file and define your root address (e.g. root 'welcome#index').

Now you reload the page you get the error "Uninitialized constant WelcomeController'. So now you need a controller. Add the controller.

Now you get an error 'The action 'index' could not be found for WelcomeController'. Define the index action on your WelcomeController.

Now you get the error 'Missing template welcome/index'. Add your views/welcome/index.html.erb view.

etc. etc.

Soon you'll find yourself needing models. Reference the model as you'd like to interact with it from the view. e.g. @articles.each do |article| etc.You'll get an 'undefined method on nil' or similar.

Then you define your model as you'd like to intereact with it in your controller (e.g. @articles = Article.all). Then you'll get an error that your model doesn't exist. Create the model.

Add the attributes to the model that you need in the view.

Repeat the process...