Which tasks should a beginner, intermediate and advanced rails developer be able to complete

ruby-on-rails

I have been programming ROR for about a year now, and I think I am ready to start working on a project for someone else. The problem is that job postings for contractors don't really tell you which specific tasks you should be able to do at different experience levels (in rails and other technologies), so I don't know where to pitch myself. I think I am somewhere between junior and mid-level, but who knows? So my question is:

Which actual tasks should an junior programmer be able to do at, say, $35 an hour, which actual tasks should an intermediate programmer be able to do at, lets say, $75 an hour, and which actual tasks should an advanced programmer be able to do at, oh say, $140 an hour?

One or two examples should suffice.

Best Answer

35$ developers can build up rails apps, not on high level.
70$ developers do this with a test-driven approach, and can also build his own gems and work nice dry.
More than 70$ developers know something about performance, scability, and should always find the best solution. He also needs to do a perfect database design etc.
the way to find the price for a project (if a customer asks me): how many hours? how much many can i arn in this timeframe with my own projects?
also a hint: how much money do you need for your life monthly. how many hours of work do you need to reach this at 35, 50, 70 bucks. is it realistic to have enough work? i know some people who works for 20€ per hour. so maybe they have 80 hours of work, thats ~1600€ per month. sounds good, but he needs to pay healt-insurance (250€), business-costs (150€), so after these costs he only have a little of 1200€. (and for this he need to pay tax at the end of the year). i told him, he needs to increase the hourly, he tried with new customers, but they dont want to pay 35-40€. so its not easy to calculate your hourly.
and at least: i think its way easier to calculate $$$ in projects-sizes not based on hourlys. obvious i would do an hour easy work (as writing textes, cause the customer is lazy) for less then if i would making some tests.

Related Solutions

Rails MVC – Controllers vs Models for File Manipulation

That article is pretty much classic. Yes, you should stick to the "fat models, skinny controllers, stupid views" architecture as long as the models make sense as objects (and they almost always do).

In your case, I'm not really sure what the output "model" should look like, but let's say it's a gallery. So you can create a model like this:

class Gallery # no "< ActiveRecord" if don't work with database

  attr_accessor :zip_file_path, :xml, :images

  def initialize(params ={})
    @zip_file_path = params[:zip_file_path]
    @xml = nil
    @images = []
    @output = nil # model: html code, path to file...
  end

  def generate_model
    unzip_file! # populates @xml and @images
    transform_xml! # creates model into @output
    @output
  end

  def unzip_file!
    ...
  end

  def transform_xml!
    ...
  end

end

It's just a rough design, you might want to make it more function-oriented (@xml, @images = unzip_file(@zip_file_path) ) etc.

Controller will then act just as a mediator between model and views/user:

class GalleriesController < ApplicationController
  def new()
    # display upload form for zip_file
  end

 def create()
   # check input here, or leave it to model validations

  @output = Gallery.new(params).generate_model
 end

end

Web-development – Which is the convention in Rails to perform calculations and display the results

This is what a conventional rails controller would look like:

class HeroesController < ApplicationController
  before_filter :authenticate_user!
  before_filter :user_only

  def index
    @heroes = current_user.heroes.find_by_level(params[:level])
  end
end

Controllers should map to resources, and your controller is returning a list of heroes. Hence, HeroesController#index. All the finding stuff goes in the model.