Tuesday, December 16, 2008

Learning Ruby - A gift to the developer community

For those learning Ruby, I've posted my code samples from the years I taught at Spokane Community College. You can find the code on Github at http://github.com/kblake/learning-ruby/tree/master
You can view my Ruby/Rails screencasts on Viddler at http://www.viddler.com/explore/kblake/videos/


Thursday, October 30, 2008


After meeting tpope and pair programming with reinh I got to see the power of vim. I have never used vim before so this is all new to me. I've been using TextMate exclusively since starting Rails a few years ago. I came to work and started in on a pursuit of how I can do in vim what I do in Textmate. While on this quest, I will document along the way some useful tips that may help you too.
I'll document some vim things I've learned so far:
Vim commands I use often:
  • gf - when cursor is on class name it'll take you to that class definition
  • yyp - duplicate current line
  • :AS - I use a lot to look at code and spec at the same time
  • ^p - autocomplete word from any open file
  • control + shift + 6 - switch between two buffers
  • shift + s - to delete current line
  • :%s/old/new/g - to change text to new text
  • / - to go to line number on page
  • /text, then enter key - to find text in file, n to find next
  • :split - split screen
  • :Rake - run specs in current file
  • :on - if in split screen, will make selected buffer the only buffer
  • escape key - to exit insert mode
  • o - create new line below existing line and enter insert mode
  • v aw - select a word
  • v ap - select paragraph (works well for method definitions too)
What are your favorite commands? I'll post more as I learn.

Friday, October 3, 2008

The Me Meme

From Blogger Pictures

  1. Take a picture of yourself right now.

  2. Don’t change your clothes, don’t fix your hair…just take a picture. (should be super-easy with Photobooth)

  3. Post that picture with NO editing.

  4. Post these instructions with your picture.


Wednesday, May 28, 2008

Rails Chops: Model Associations

Ok, remind me not to create screencasts after 10:00 p.m. I have another 5 minute spot towards the end where I’m off in lala land. You can fast forward through it or use it as ammunition for our next conversation. :)

Please view in full screen.

Monday, April 21, 2008

Rails Chops: Editing data

  • ActiveRecord - update attributes
  • RESTful routing - edit/update
  • partials
Please view in full screen.

Monday, April 14, 2008

Rails Chops: Creating new stories and validations

  • New/Create RESTful routes
  • Form Helpers
  • Validations
FYI, video looks much better in full-screen.

Friday, April 11, 2008

Rails Chops: Starting a Rails App

  • ActiveRecord Basics
  • Migration Basics
  • Creating a controller and a view

Wednesday, April 9, 2008

Rails Chops: RESTful Routes

Reference: Chapter 4 (The Rails Way)

In Rails, by adding map.resources :stories to config/routes.rb, you get 7 predefined routes:

  • stories GET /stories {:controller=>”stories”, :action=>”index”}

  • POST /stories {:controller=>”stories”, :action=>”create”}

  • new_story GET /stories/new {:controller=>”stories”, :action=>”new”}

  • edit_story GET /stories/:id/edit {:controller=>”stories”, :action=>”edit”}

  • story GET /stories/:id {:controller=>”stories”, :action=>”show”}

  • PUT /stories/:id {:controller=>”stories”, :action=>”update”}

  • DELETE /stories/:id {:controller=>”stories”, :action=>”destroy”}

Slowly but surely we are going to build an app from the ground up and use all of these RESTful routes. Its very important to understand what each of these do and how to incorporate them into your application. These routes control how we setup our controller, actions, links, and forms. It is amazing how much is conventionalized around one configuration line map.resources :stories

  • POST is a CREATE

  • GET is a READ

  • PUT is an UPDATE


Sunday, April 6, 2008

Rails Chops: Working with databases



  • Configure Rails to work with a database (database.yml)

  • create table (migration)

  • use ActiveRecord to interact with our database

  • use script/console to learn how ActiveRecord works


  • handle application state (usually in the database)

  • encapsulate business logic, such as data validation and rules applied to data


  • ORM (object-relational mapping)

  • Instead of dealing with database through SQL statements, ORM layer presents records as a collection of objects

  • Table represents a collection of objects(stories)

  • Record represents an object/model (story)

  • Field represents an object attribute (title)

CRUD operations on database

  • C: create, insert record into table

  • R: read, select record(s) from table

  • U: update, update record(s) in the table

  • D: delete, delete record(s) from the table

Tuesday, February 19, 2008

Ruby Chops: Flexible Sort

So I was messing with the comparable module and the <=> method.  I implemented as I would in Java.  Then I played with sort_by and thought that was awesome. Which led me to writing my own method that would allow me to pass in a collection and attributes to be sorted by. The objects in the collection would have to implement my Sortable module. This was more for academic fun and try to keep my mind sharp. If anyone sees a cooler way to do it then please post it here.

Tuesday, February 12, 2008

GeneTree on NBC

The project I'm working on made another news story, this time on NBC.  View Now

Sunday, February 10, 2008

Code Documentation

There are two ways to communicate what your code does: the code itself and using comments.

Self Documenting Code

Source code should be understandable not because it has comments but because of its elegance and clarity – correct use of variable names, good use of whitespace, good separation of logic, and concise readability. Code will be read hundreds of times and written only a few times. So invest quality time into spelling out names such as fn into firstname. Fight the urge to use cryptic variable names.

Code Comments

Code should have comments however an abundance of comments can be just as bad as too few. Comments should explain why something is done. The code itself already shows what it is done. So commenting on what is done is redundant. Do not use commenting as a substitute for good code. Another way to say that is that if you need to comment code due to its unclarity then maybe you need to rewrite the code to be more clear and remove the comment.

I found this article which is about using natural language in your code to make it more readable. http://jamesgolick.com/2008/1/14/taking-style-tips-from-natural-language

Ruby chops: rubyisms

Rubyisms I've accumulated over time: check 'em out.

Ruby chops: module example

UnDRY code

Ruby chops: modules basics

Download Code

Ruby Chops: Class variables and methods

Download Code