Experts, Passion, and Pinpoint Control

Quick and random:

The book Ball Four had a big impact on me as a kid. I stumbled across a copy when I was about 12. If you don’t know, Ball Four, written by Jim Bouton and published in 1970, was one of the first big athlete tell-alls (though it seems much tamer these days than it did when it came out…) Anyway, a lot of the book can be read as the story of an articulate outcast trying to understand and navigate the other teammates that he’s basically stuck with.

One passage from the book that’s always stuck with me, is this one, which is Bouton taking about his early career:

When I first came up I thought major-league pitchers had pinpoint control, and I was worried that the best I could do was hit an area about a foot square. Then I found out that’s what everybody meant by pinpoint control, and that I had it.

How great is that? That is a form of impostor syndrome from a major-league pitcher.

It’s a strategy I use to this day — when I’m upset because I’m not sure if I qualify for some vague category like expert, or passionate programmer, or author, or senior developer, I at least consider the possibility that I’m setting the bar for that term too high, and that I’m already that thing.

Because experts look things up.

And senior developers ask for help.

And passionate programmers do other things sometimes.

And pinpoint control is a foot square.

Programming Sound with Pure Data now in print and shipping

Programming Sound with Pure Data now in print and shipping

Routing Basics: Ruby on Rails for Front-End Developers

Routing Basics: Ruby on Rails for Front-End Developers

This guest post is by Miles Matthias, who in between trips and sips, usually with planes and bourbon, enjoys talking to people about difficult challenges and tapping on his keyboard to help solve them. He moved to Boulder in January of 2012, after meeting his future wife and picking up degrees in Computer Science and Information Assurance in Omaha, Nebraska. Boulder was his ninth move after growing up in Virginia, Kansas, Illinois, and Indiana, and would be more than happy if Colorado became his permanent home. With experience in network security monitoring, vulnerability assessments, red hat teaming, bash scripting, and web and iOS development, he enjoys building simple and beautiful applications, contributing to the open source community, and writing about his life experiences.

Miles Matthias Here’s an excerpt from my book’s chapter on routing, and then I’ll give you some examples:

Routes config

Remember that bit about convention over configuration? Well rails definitely prefers configuration to convention in one instance – routes. In the file config/routes.rb, you’ll find direction given to the rails router on which controller method to call for a given request. Here’s a simple route declaration:

match 'articles', to: 'articles#index'

If a user makes a request to, the rails router will look for a controller called ArticlesController and if there’s a method called index, it will call it, passing along the information in the request. Then it’s up to the controller to respond.


You’ll also see what rails calls resources in the routes file, which promotes the convention over configuration pattern. Resources handle the 85% case where your application is representing standard RESTful CRUD operations on a ‘thing’, such as an article. The above example route could be replaced with:

resources :articles

which would then mandate that the method names in the matching controller match the rails resourceful actions.


If we had the following in your config/routes.rb file:

resources :articles

and our /app/controllers/articles_controller.rb file looked like this:

class ArticlesController < ApplicationController
    def index
        @articles = Article.all

    def show
        @article = Article.find(params[:id])

    def edit
        @article = Article.find(params[:id])

Here’s the list of what HTTP Verbs and URL combinations match to what methods inside a controller:


Notice in the controller that we didn’t call render at all. That’s because Rails automatically attempts to render a view that has a filename of the same name of the method called in the controller. If it can’t find one, it will default to the index.html view for the controller, or the application index.html.

For example, if someone wanted to get an article at, Rails would call the show method in our controller with 1234 as the id param. That method (above) will find the article that matches that id and then rails will call render on a view in /app/views/articles/show.html.erb. Here’s an example of what that view might look like:

<h1><%= @article.title %></h1>

<h2>by <%= %></h2>

<%= @article.body %>

If you’d like to learn more about how Ruby on Rails’ front-end stack works or you’re a front-end developer needing to do some work in Ruby on Rails, check out my book, “Ruby on Rails Explained for Front-End Developers”.

Feel free to ask questions and give feedback in the comments section of this post. Thanks!

Technorati Tags: , ,

(Powered by LaunchBit)

Learn Ruby Programming – 50th Batch Since 2005

Registrations are now open for RubyLearning’s popular Ruby programming course. This is an intensive, online course for beginners that helps you get started with Ruby programming. The course starts on Saturday, 8th Feb. 2014 and runs for seven weeks.

Course Fee and Discount

Please create a new account first and then pay US$ 34.95 (for the first 10 participants, after which the course fee will be US$ 69.95) by clicking on the PayPal button Paypal

Download ‘Advice for Ruby Beginners’ as a .zip file.

Here is what Sandra Randall (Butler), a participant who just graduated, has to say – “You kindly offered me the opportunity to join your Ruby course. I’m new to development and found the course, even though basic for programmers, a little tricky for me. I managed to complete all of the assessments and really learnt a lot. Thank you very much for the opportunity. It has really given me the push I needed to learn Ruby and I’m currently treading my way through both the pickaxe and Agile Development books and enjoying it. I’ve recently been offered a position as a Junior Systems Developer at a local Software house in South Africa – all thanks to the push you gave me which gave me the motivation and drive to get going.”

What’s Ruby?


According to – “Ruby is a dynamic, open source programming language with a focus on simplicity and productivity. Ruby’s elegant syntax is natural to read and easy to write.”

Yukihiro Matsumoto, the creator of Ruby, in an interview says –

I believe people want to express themselves when they program. They don’t want to fight with the language. Programming languages must feel natural to programmers. I tried to make people enjoy programming and concentrate on the fun and creative part of programming when they use Ruby.

What Will I Learn?

In the Ruby programming course, you will learn the essential features of Ruby that you will end up using every day. You will also be introduced to Git, GitHub, HTTP concepts, RubyGems, Rack and Heroku.

Some Highlights

RubyLearning’s IRC Channel

Some of the mentors and students hang out at RubyLearning’s IRC ( channel ( for both technical and non-technical discussions. Everyone benefits with the active discussions on Ruby with the mentors.

Google Hangouts

There is a Hangout Event that is open for students, for drop-in hangouts where students can pair program with mentors or with each other. This is often where you can get help with your system, editor, and general environment. Anything that can help you with your coding environment that you are having problems with are usually discussed interactively here.

Git Repositories

Shared (private) repositories available for those that want to learn git and the revision controlled programming workflow. This allows students that want to collaborate while learning. This is a great way to record your progress while learning Ruby.


The course is based on the The Ultimate Guide to Ruby Programming eBook. This book is priced at US$ 9.95. However, the Kindle edition of the eBook is available for US$ 6.

Challenges and Side Tracks

This is course material not found in the RubyLearning Study Notes nor in the E-Book! Depending on participation levels, we throw a Ruby coding challenge in the mix, right for the level we are at. We have been known to give out a prize or two for the ‘best’ solution.

Who’s It For?

A beginner with some knowledge of programming.

You can read what past participants / online magazines have to say about the course.


Satish Talim, Michael Kohl, Satoshi Asakawa, Victor Goff III and others from the RubyLearning team.


The course starts on Saturday, 8th Feb. 2014 and runs for seven weeks.

How do I register and pay the course fees?

  • You can pay the course fees either by Paypal or send cash via Western Union Money Transfer or by bank transfer (if you are in India). The fees collected helps RubyLearning maintain the site, this Ruby course, the Ruby eBook, and provide quality content to you.

To pay the Course Fee:

Please create a new account first and then pay US$ 34.95 (for the first 10 participants, after which the course fee will be US$ 69.95) by clicking on the PayPal button Paypal

How does the course work?

For details on how the course works, refer here.

At the end of this course you should have all the knowledge to explore the wonderful world of Ruby on your own.

Remember, the idea is to have fun learning Ruby.

Technorati Tags: , , ,

(Powered by LaunchBit)

From Lousy to Beautiful

From Lousy to Beautiful

This guest post is by James Schorr, who has been developing software since 1999. He is the owner of an IT consulting company, Enspiren IT Consulting, LLC.  He lives with his lovely wife, Tara, and their children in Kansas City, Missouri. James spends a lot of time writing code in many languages, doing IT security audits, and has a passion for Ruby on Rails in particular. He also loves spending time with his family, playing chess, going to the shooting range, hiking, fishing, and investing. His professional profile is on LinkedIn.

James M. Schorr Due to the inherent flexibility of Ruby, there are often several ways of doing the same thing. But how do you recognize the best way, the “beautiful” way to go about something? It can be tough to describe and there may indeed be several “best ways” to do something. The ease of expressing real life through Ruby can give us a false sense of security. I have come to realize that terrible code can be written — even with such a beautiful language.

Let us work through a simple example together. In our example, we’re calling a remote API service with HTTParty, and parsing through the JSON response, which consists of a simple array of stats, which we’ll refer to as “Today’s Stats”. Please note that comments in the code intended just for the reader of this article will be prefaced with ‘## Reader’. Hopefully, you’ll see the progression of the code’s quality as we go.

Here’s our first attempt, which is pretty lousy. Can you spot a few of the reasons why?

Attempt 1 – Blind Trust

module StatsApi
  require 'json'
  require 'httparty'
  require 'jsonpath'

  def find_users_stats(users_handle)
    params = { user: users_handle }
    a = HTTParty.get('', params)
    t = JsonPath.on(a.body, '$.').first
    u = {|k,v| k['user'] == users_handle }.first
    @users_stats = u['stats']

Did you spot the issues? There are quite a few, some that affect us now and some that might affect us in the future. For now, let’s focus on the most pressing, immediate issues:

  1. We are trusting that our call to the API will succeed.
  2. We are trusting that the account that we pull back will indeed have the user that we’re looking for.
  3. In both cases, we are then attempting to parse through the data that may not even make it back to us or have what we expect it to have.
  4. What does ‘a’, ‘t’, and ‘u’ represent? Would the next developer working on this code know what I’m referring to? While it saves space, it isn’t very friendly to the next developer.

Attempt 2 – Handling the Unexpected

module StatsApi
  require 'json'
  require 'httparty'
  require 'active_support/core_ext/string' ## Reader: provides .present? and .blank?
  require 'jsonpath'

   def find_users_stats(users_handle)
    params = { user: users_handle }

    a = HTTParty.get('', params)
    ## Reader: .present? (or .blank? when appropriate) can be nice to use as they checks for more than just nil.
    ## Additionally, we make sure that 'a' is 'present?' before calling 'response' on it.
    if a.code == 200
      todays_stats = JsonPath.on(a.body, '$.').first
      if todays_stats.present?
        users_info = {|k,v| k['user'] == users_handle }.first
        if users_info.present?
          @users_stats = users_info['stats']

Now we seem to have solved a couple of issues, but this code could still be improved a bit. Notice that:

  1. Nothing is returned if the call to the API fails or the user’s stats aren’t found. Now, of course in the code that calls this method, we could handle that there but is that the “beautiful” thing to do? Perhaps in the future we’ll have 10 areas in our code that call this method.
  2. Nested if statements are present — ugh. When I was newer to Ruby, I would often write a lot of these; reading through them months later made my head hurt. It certainly wasn’t beautiful to look at and made it tough to follow as more logic was added over time. Thankfully, there is a better way.
  3. Note that we could add more conditionals to ‘a’ to ensure that HTTParty returned a response correctly, but we’re going to choose not to as it’s a well-tested gem.

Attempt 3 – Bringing Clarity

module StatsApi
  require 'json'
  require 'httparty'
  require 'active_support/core_ext/string'
  require 'jsonpath'

  def find_users_stats(users_handle)
    # This will call the Stats API and pull back the user's stats.
    params = { user: users_handle }

    todays_stats = HTTParty.get('', params)
    raise "Today's Stats not found." if todays_stats.code != 200

     # Finding the User's information...
    users_info = {|k,v| k['user'] == users_handle }.first
    raise "User's stats not found." if users_info.blank?

    # Determining the User's Stats...
    @users_stats = users_info['stats']

Okay, we’re getting closer. Now we have ‘todays_stats’ and ‘users_info’ in the code so that it’s more  clear as to what we’re referring to and an appropriate error message is returned if the account or user are now found. Notice how we added a little white-space and comments to make it easier to read. However, we’re still calling the API and also parsing through stats in this one method. This might be fine for now if we only call the API for one purpose. But what about the future? What if a need arises to adjust the stats, add new stats, etc… via the API?

Let’s try to future-proof our code a bit by making it more flexible and configurable. We’ll use the excellent Settingslogic gem (you can add that yourself) to make the API settings configurable. This will help when the Stats API’s URL, version, etc… changes. We’ll also add a method to adjust the user’s stats and one that performs the actual API call. Notice how we can accomplish this by using ‘send’. Thus the various HTTP verbs can all be used as desired while keeping the code pretty DRY.

Attempt 4 – Sustainability

module StatsApi
  require 'json'
  require 'httparty'
  require 'active_support/core_ext/string'
  require 'jsonpath'

  ## Reader: note that @error is raised so that we can easily handle that in our parent methods...

  def find_users_stats(users_handle)
    # This will call the Stats API and pull back the user's stats.
    # All of the API settings are found in config/settings/api.yml.

    # Finding the Account...
    params = { user: users_handle }
    call_stats_api('get', 200, true, params)
    ## Reader: note that the following line is optional as you could have conditional code in
    ## the parental method based on @call_succeeded.
    raise @error = 'Account not found.' unless @call_succeeded

    # Finding the User's information...
    ## Reader note that we raise @error so that we can easily handle that in our parent methods...
    todays_stats = JsonPath.on(@result.body, '$.').first
    raise @error = "Today's Stats were not found." if todays_stats.blank?
    users_info = {|k,v| k['user'] == users_handle }.first
    raise @error = "User's Stats not found." if users_info.blank?

    # Determining the User's Stats...
    @users_stats = users_info['stats']

  def adjust_users_stats(new_stats)
    # Adjusts the users stats with the new_stats Hash.
    call_stats_api('put', 201, new_stats)
    ## Reader: note that the following line is optional as you could have conditional code in
    ## the parental method based on @call_succeeded.
    raise @error = 'Stats adjustment failed.' unless @call_succeeded

  def call_stats_api(http_verb, success_code, response_body_reqd=false, data=nil)
      # This calls the Stats API, passing along the necessary params. The data refers to what
      # should go in the JSON payload.  The success_code is the desired code that the parent method
      # would consider to be 'successful'.  This allows us to pass in the actual HTTP status codes
      # that the 3rd party API returns.
      ## Reader: Note that the various Settings mentioned below reference the
      ## config/settings/api.yml file in order to make it very easy to change things in the future.

      ## Optional but more future-proof; these don't have to be configurable but probably should be:
      params = { headers: AppSettings::Api.stats_headers, version: AppSettings::Api.stats_version,
                 format: AppSettings::Api.stats_format }

      # Adding the JSON data to the params...
      ## Reader: notice that we don't blindly trust that the data parameter is indeed
      ## a hash; what if something else was sent to this method by mistake?
      raise 'Invalid data received' unless data.is_a?(Hash)
      params[:body] = data.to_json

      ## Reader: notice that we use Object's 'send' so that we only need one method
      ## for API calls with the desired HTTP verb. The following line will be what's
      ## returned to the parent method.

      ## Optional (you can just write in the URL if you wish) but more future-proof:
      @result = HTTParty.send(http_verb, AppSettings::Api.stats_url, params)

      # Determining the success of the response.
      code_matches = @result.code == success_code

      ## Reader: if the response_body_reqd is set, then a call is only considered successful if the
      ## response code matches and the body has data in it. Otherwise, only a matching code is considered
      ## successful.
      @call_succeeded = response_body_reqd ? @result.body.present? && code_matches :
    rescue => e
      ## Reader: notice that in production-ready code, we'd never return the real error message to the
      ## end user as it would expose too much and not be very human friendly.  It would probably be best
      ## to just return a "human-friendly" error message and log the atual one.
      @error = e
      Rails.logger.error("Sorry, an error occurred: #{e}")

Now our code is quite a bit more readable, more flexible, and easier to maintain. There are a few spots where we could probably get away with removing our comments since the variables are so aptly named. We could also (and should if there are needs for other types of APIs to be called) create a new class that calls APIs. We’ll leave that for another day, though.

In general, though, our code has improved quite a bit.

Here are a few Ruby resources that I would like to recommend (discounts given with author’s permission):

Feel free to ask questions and give feedback in the comments section of this post. Thanks!

Technorati Tags:

(Powered by LaunchBit)

Dart for Hipsters, 1.0

Dart for Hipsters, updated to 1.0

Conference Prompts: Or How to Submit Proposals and Influence People

I’m going to be conducting a few of the tracks for this year’s RailsConf, specifically the Novice, Testing, and Crafting Code tracks. I’m very excited, this isn’t an opportunity I’ve had before.

What I want from all of you is awesome proposals. I want to have to make hard decisions. I want to be inundated with all your amazingness.

Because I want to hear from all of you, here are some opinions on how to best present yourself in a speaking proposal.

Yes, You Can. In Fact, Please Do

In response to my initial round of begging for proposals on Twitter, somebody commented that they didn’t think they were the most qualified person to talk on a particular subject.

To which I have three cheesy but true responses:

  • A conference that was limited to only people that really though they were the most qualified person to talk would be depressing, if not completely horrific.
  • You are absolutely the most qualified person to tell me what you think on a particular topic.
  • This is how you become qualified. You study something, you teach it to other people.

In other words, please don’t let that stop you. If you don’t submit a proposal, you have zero chance of being accepted.

(In a similar vein, here’s a talk I once gave about how everybody has technical writing in them. Video’s poor, but audio is okay.)

I can’t speak for any of the other conductors, but I’m also looking for people who want to give shorter talks (10-15 minutes) with the idea that we might have a session that is 2 or 3 awesome shorter talks. If that interests you, definitely mention it when you submit.

What Should I Talk About?

Let’s say, for the sake of argument, that I’ve convinced you that you should submit a proposal to RailsConf or the conference of your choice.

But you don’t know what to talk about.

Here are some ideas. This is the kind of process I go through when I try to get ideas for a talk, though by writing it down I’m making it more systematic.

Think of these as prompts and use them as starting points to find an idea for a talk that excites you.

These are far from the only seeds for good presentations, but it’s a start.

  • What is the last thing you spent more than 15 minute trying to figure out?
  • What is the last tool, process, or code you wrote that made you excited enough to tell somebody else?
  • What was the last question you asked a more senior developer?
  • What was the last question a more junior developer asked you?
  • What do you wish somebody had told you a year ago?
  • What was the last blog post or presentation in the community that you disagreed with?
  • Do you have a hobby or interest that informs your work?
  • What is the best line of code you wrote this week? How could you tell?
  • What was something you did for the first time in your last project? How did it work out?
  • What was something you did for the last time in your last project (or something you stopped doing for your last project)? How did that work out?
  • What is a tool or process you would like to learn more about?

Once you have an idea, try to answer these questions about it.

  • Who is the audience for this? It often helps to think of one specific person that you’d like to talk to.
  • Is there a story here? What is the beginning, the middle, and the end?
  • If a person watches this talk, what will they be able to do after the talk that they would not have been able to do before?

UPDATE 1/19 It seems worth pointing out that I’ll be speakng at MountainWest RubyConf this year. The talk is on Smalltalk, and it’s a direct result of a presentation I saw and wanted to respond to (I didn’t actually disagree with the presentation, but I had another take on the topic). Also, I know for a dead certain fact that one of the other speakers is a much bigger Smalltalk expert than I am. And I am going to take may own advice and not let that bother me.

What Makes A Great Submission

I have opinions on the actual submission — watch for updates after I dive into the actual submissions.

I’m going to share with you the first rule of submitting anything. This rule is applicable to any situation where a person has to spend a lot of time evaluating submissions — resumes, conference proposals, writing submissions all included.

Rule One: The person reading these submissions is always looking for a way to save time. Don’t give them a reason to reject you out of hand.

That means: if they have a format, hit the format. If they have a word count, hit the word count. Spell words correctly. Write in grammatical English. Sure, the reader might take extra time to figure you out if you bend the submission rules. But why take the chance?

Have somebody else read and edit you if you can. Find a buddy and read over each others. (I’m willing to be your editing buddy — contact me via this web site).

In most cases, the talk descriptions on conference web sites are taken directly from the submission — look through some, and see what makes them compelling.

Specifically for conference proposals:

  • Make sure you specify: a) who the audience is, b) what they should expect, c) what they will learn.
  • For a long time I was afraid to give out details of my talk in the abstract for fear of “giving stuff away”. That was a bad idea. You need to give people an idea of what to expect. (The RailsConf CFP has a details field that lets you put in details for the organizers and not the abstract — use that)
  • You don’t have to explain why you are an expert, but if you have a particular reason why you might have insight into the subject, mention it. This reason is not at all limited to you having vast experience on the topic.

Good luck, and I look forward to hearing from you.

Seven Web Frameworks and Web Development with Clojure now in print and shipping

Seven Web Frameworks and Web Development with Clojure now in print and shipping

Ruby on Rails developers in New York

We’ve had a number of clients in New York over the years. After a recent trip this last fall to visit clients and attend Cultivate we decided that we should spend more of our time in the city.

<p>In 2014, we&#8217;re looking to expand our client base there. If you&#8217;re in the <span class="caps">NYC</span> area and are looking for an agency that has great Ruby on Rails developers&#8230; <a href="">get in touch</a>.</p><div class="feedflare">