Recently I had the pleasure of trying out a new pairing service called airpair.co
I sign up for the developer path and list the host of technologies I feel comfortable philosophizing about over a pseudo-anonymous pairing service.
A nice chap named Jonathan contacts me and asks if I could comment on the code at this gist below
I look at it and end up thinking I could add some value there. There is a fat controller, and I can only imagine what the model and routes are - and because I’d like to see this model and routes file I suggest I could add some value.
Somehow I find myself doing a google hangout with two strangers discussing a rails controller and how we may go about refactoring it. We all agree it is a bit of a mess - just too much going on. How do we improve it?
One thing we begin to notice is that the methods / controller actions are not always mapped to routes and appear to be doing things to the model. For instance, there is a controller method like so
def event_list @events = current_company.events @communication = if params[:communication_id].to_i > 0 current_company.communications.find(params[:communication_id]) else Communication.new end render layout: false end
The above could easily become a method on the communications model.
Then we thought about the idea of creating a new controller that is subclassed from communications. This is useful because these actions do seem to be acting on a different type of a communication. We went through and played around with making the communications a little more restful, and it was a fun experience I’d love to do again. Next time I think I’d like to use some tmux and actually dig into the code together… similar to how we did earlier here
Modified controller => https://gist.github.com/anonymous/ce917ac4867b7de57bc9