Portland Startup Weekend - May 23-25
I just signed up for the Portland Startup Weekend for the weekend of May 23-25. Anyone else going in the Portland Area?
It should be an exciting and overwhelming couple of days.
Posts from graeme nelson...
I just signed up for the Portland Startup Weekend for the weekend of May 23-25. Anyone else going in the Portland Area?
It should be an exciting and overwhelming couple of days.
I’ve opened a new chapter in my life. I decided to leave PLANET ARGON due to some family issues and the need to free up my time to work on freelance projects. I really enjoyed working with everyone at PLANET ARGON and I still plan on working with them from time to time.
If you are looking for an experienced rails developer, then I would be happy to talk with you about your project and needs. You can contact me through GraemeNelsonPDX.com or write me at graeme @ graemenelsonpdx.com.
Cheers, Graeme
Again, its been a long time since my last post. A post about not posting. Its been very difficult to find time to write blog posts when you spend most of your time creating new apps. I love creating apps. Most of the applications were for other people, but I did manage to squeeze out an app for myself and friends. It’s called tastymate. Its a place to find and share tasty spots with your friends.
In the process of building tastymate and the other applications, I was able to play with the following:
I have several nice topics to write about in the future. I hope to get on them soon.
On an unrelated rails note, I took a look at jaxer and I am impressed. It will be interesting to see what traction this project gets. Have I told you that I am loving javascript :)
Cheers, graeme
It’s been several months since my last blog post. Things have been pretty busy for me, and my blog has taken the backseat. What have i’ve been up to you ask?
I am going to try harder to keep up on my blog. I do have some interesting things to say sometimes.
If you find you need a little break from the programming world, how about participating in the Festive Fun & Fancy Free Flying Friend Giveaway!
A talk I really enjoyed at Rails Conf 2007 was Clean Code by Robert Martin. An important idea from that talk was “Always check in your code a little bit cleaner than when you checked it out”. I never looked at refactoring as being that simple, but it is. Prior to this talk, I looked at refactoring as this big undertaking. I mean the whole application can use some improvement, right? I also tended to take on big refactoring endeavors by deleting the current code and starting over. Robert Martin urges against this, since you might break the current application with the rework code, and that’s much worse than ugly code. At least the ugly code is working. Tackling the smaller refactors, by improving the code a little bit at a time, the refactoring process becomes manageable.
If you are attending RailsConf (or Portland in general) and you love BEER, be sure to check out PLANET ARGON Portland Revealed article.
I am looking forward to meeting others in the Rails Community, please hit me up if you are interested in meeting up. I am sure I will be at several of the after conference get togethers.
In the coming weeks, PLANET ARGON will be introducing a new hosting service called Boxcar. Be sure to sign up on the email list or watch the official PLANET ARGON Blog for more updates.
So, what is Boxcar? [from the official PLANET ARGON blog]:
”...a new hosting service, which aims to provide you with even more privacy, more guaranteed resources, and better options for scaling your Rails application as your business grows.”
Robby was interviewed last week for The San Jose Mercury News. The article focused on Sun and its contribution to the open source community.
A quick note, Robby Russell will be speaking at Ostrava on Rails. I wish I could attend, I would love to go to the Czech Republic
When I first started out developing, I was concern with getting things done and working as quickly as possible. I didn’t really understand the benefits of refactoring. Later on in my development career, I understood why refactoring was important, but I still couldn’t find any time to refactor – unless it was physically added to a project schedule, which wasn’t too often.
What I have finally come to understand, is that I just needed to find time to refactor. The time I spend on refactoring now, will probably save me a lot more time in the future tracking down bugs in a bloated code base. So today, when I ran into an issue because of a bloated code base I decided to refactor the code. Sure I spent all day cleaning up the code, but I feel more confident in the code base and I was able to add much more rpecs.
So, how often do you refactor? and when do you find time to refactor?
It was nice to visit with friends in Seattle this past week. I forgot how many talented friends I have. Check out Gustav Braustache a film shot and directed by my friend Rob Cunningham and staring my other good friend Ken Jarvey, who is also a member of The Can’t See
Okay, I took a break from ruby on rails development this weekend. It was Anisa birthday, so we decided to go to Seattle. We stayed with my brother the first night and played with his new Wii machine. I am not a big gamer, but I’ve been wanting to try out the Wii for some time. I must say Nintendo did it right. It was just entertaining. My mom even loved playing it. You can’t say that for the xbox or playstation. But the one thing I really loved about the Wii, was my Wii character. I can’t believe how much it looks like me. Take a look.

Just incase you can’t tell, I am the one on the right.
The team at PLANET ARGON is excited that RailsConf 2007 in Portland is fast approaching. We are looking forward to meeting other ruby on rails developers. We are hoping we can help out our peers and find cool things to do in Portland during the conference. We have started a Portland Revealed Series. Okay, there’s only one post, but we hope to add a few more (busy times at PLANET ARGON).
We would also like to get recommendation from you on what types of things you would like to know about Portland.
Recently, I’ve vowed to remove most of the model.find methods from my controller. I am not talking about simple find statements like:
model.find(1)
model.find_by_title("my title")
I am talking about find methods like so:
model.find(:all, :conditions => ["status = ?", my_status]) model.find(:all, :conditions => ["title = ?", my_title])
I would add methods on the model called, find_all_by_status(status) and find_all_by_title(title). Now, you may be thinking that these are simple find statements too. And I would agree with you. But in my opinion it makes the controller code look dirty. What would you rather see in your controller?
model.find(:all, :conditions => ["status = ?", my_status]) ~OR~ model.find_all_by_status(my_status)
Which one can you comprehend faster? For me, the first statement takes some time for my brain to process, where as the second statement doesn’t not. Ok, if this isn’t enough to convince you. What if you introduce a new boolean attribute on your model called ‘active’ and the logic is to only show active model instances? Now you have to change all the places where you have:
model.find(:all, :conditions => ["status = ?", my_status]) ~TO~ model.find(:all, :conditions => ["status = ? and active = ?", my_status, true])
You say you were thinking ahead and have a private method on your controller to handle this call, so you only have to make the change in one place. I would say congratulations, but I would point out that I think the controller knows too much about the model and thus breaks encapsulation.
I would like to hear what other think, and how they handle this situation.
Hi Everyone -
Finally released the first version of the Makool Loves You store. It took a bit longer than expected (does’t everything), but Anisa and I are really happy with it.
Hopefully, I will have some time to write more blog posts.
Hey everyone,
PLANET ARGON is looking for intermediate to experienced ruby on rails developers. Having been there for a little over 2 months, I can say its a really nice environment to work in.
I spent most of the morning trying to get my GoDaddy Turbo SSL working on my nginx setup. Thanks to Skiz for pointing me in the correct direction. Here are my steps:
ssl_certificate /etc/nginx/certs/combined.crt;Find more information on setting up ssl on nginx here
I feel the area where I need to improve most is in cleaning up my views. I feel like I’ve done a good job cleaning up my controllers and models, thanks to posts like Skinny Controller, Fat Model.
I have known about the content_for in rails views. Which basically allows you to have a layout like so:
<% yield :header %>
<%= yield %>
And in your view the following:
<% content_for :header do %>
This would appear for the yield :header call
<% end %>
<% content_for :sidebar do %>
This is the sidebar content
<% end %>
<% content_for :footer do %>
This is the footer content
<% end %>
<%# the rest would just be the content for the plain yield call %>
This is would be my main content
This is nice, but I wanted to find a way to supply default content and this is what I came up with.
def yield_with_default(yield_on, content=nil, &block)
yield_content = eval "@content_for_#{yield_on} || ''"
if block_given?(&block)
concat(yield_content.empty? ? capture(&block) : yield_content, block.binding)
else
Binding.of_caller do |binding|
concat(yield_content.empty? ? content : yield_content, binding)
end
end
end
I placed this in my application_helper.rb file. And now I can add something like this to my view.
# with a block
<% yield_with_default :header do %>
This is my DEFAULT header content
<% end %>
# without a block
<% yield_with_default :header, "This would be my default content" %>
This feels pretty clean to me. But if anybody has any other suggestions I would love to hear them.
I am also looking for more information on best practices with views in Rails. There doesn’t seem to be much information on the subject.
UPDATED: 04/01/2007 – forgot the do in the content_for statements
I came across a way to overwrite the default fieldWithErrors div that gets created when an input field has an error. Someone else might have already discussed this or has a better way. But I thought I would share what I came up with.
The code that creates the fieldWithErrors div around an input field with errors associated with it is defined in active_record_helper.rb file and it looks like:
module ActionView
class Base
@@field_error_proc =
Proc.new{ |html_tag, instance| "#{html_tag}" }
cattr_accessor :field_error_proc
end
...
end
In my config/environment.rb file, I overwrite the behaviour like so:
ActionView::Base.field_error_proc =
Proc.new{ |html_tag, instance| "#{html_tag}" }
When I firsted started writing Rails Apps, coming from the Java world, I forgot all my good OOP training. Within Rails, I viewed the model as this magically class that gave me all this power and I was afraid to add any of my own behaviour to the model. Which went against my previous way of doing things, which was to place as much of the business functionality within the model.
Well, I am glad Jamis came along and wrote this post.
I am back on track. I don’t know how many times I wrote something like this in a controller:
def update
@user = User.find(params[:id])
@subscription_plan = SubscriptionPlan.find(params[:plan_id])
@subscription_plan.update_attribute(:status, 'active')
# deactivate previous plans
@user.subscription_plans.each {|plan| plan.update_attribute(:status, 'disabled') if plan.status == 'active'}
@user.subscription_plans << @subscription_plan
end
This is just ugly. And goes against a lot of OOP best practices. The controller knows too much about the internals of the User and Subscription Plan models. Also, if I wanted to test this controller action using mocks and stubs, I would have to write a bunch of code. What if I fixed the controller code to be like so:
def update
@user = User.find(params[:id])
@subscription_plan = SubscriptionPlan.find(params[:plan_id])
@user.upgrade_to_subscription_plan(@subscription_plan)
end
This is much cleaner and easier to mock/stub. Also, if I decided to change the behavior of how a user upgrades their plan, the upgrade_to_subscription_plan method isolates any changes from the controller action – as long as the method signature doesn’t change.
So, go ahead a love your models.