I listen to a lot of podcasts on a bunch of different subjects. Architecture, math, music, philosophy, software engineering, art, news, history, civil rights – there is a wealth of information out there and it is amazing!

I have a bunch of podcasts that I can give a mention to, but there are four that stood out this year for me.

If you’re not listening to it, and many of you already are, Roman Mars’ 99% Invisible is fantastic. This is a series about architecture, design and how these things impact the world around us. I’ve been listening to this show pretty much from the beginning, and every year I continue to be more taken by it. It continues to be one of the podcasts I routinely recommend to people who are just interested in hearing something cool.

From 99% Invisible I found Song Exploder. This has rapidly made it to the top of my queue. Every episode is just so good. What you’re going to find here is a show about how musicians make music. We all know that artists all have their own style, but this series just brings that home in each episode. This may be my favorite show of the year.

I’m thrilled to hear Hrishi Hirway will be continuing Song Exploder into 2015. If you just want to try it out, all the episodes are amazing, but I would recommend Episode 24 with Tycho or Episode 22 with Nick Zammuto of The Books.

Doing what I do for a living, I listen to tech podcasts often, too.

My friend Shaun Ambrose mentioned that he had found a podcast on the philosophy of computing called On Computing by Grady Booch.

This series just sucks you in. I can’t describe it properly. It is part philosophy, part technology. It is liberal arts meets computer science. Booch offers so much in each episode. Every one of them is worth listening to multiple times. There are currently 14 episodes that run about 10 minutes per episode. You owe it to yourself, regardless of your profession, to listen to these shows.

The series comes up with a new episode fairly infrequently and it has been running since 2012. I’m hopeful that Grady Booch will continue to do more in the coming year.

Finally, thoughtbot started a new series in October called The Bike Shed hosted by my friend Sean Griffin and Derek Prior. I’m really enjoying this young series. Sean and Derek are taking us to a more technical discussion of software, and I’m grateful for that. I can’t wait to hear what they have to say in 2015.

So here’s the TL;DR.

My top four podcasts:

Roman Mars’ 99% Invisible
Hrishikesh Hirway’s Song Exploder
Grady Booch’s On Computing
Sean Griffin and Derek Prior’s The Bike Shed

Also: If you’re looking for a good way to keep up with podcasts for iOS I would recommend Downcast (@downcastapp). It is the absolute best podcast catcher I’ve ever used. And I’ve tried quite a few.

If you have a favorite podcast, I want to hear about it! Hit me up on Twitter: @geopet.

Sections in Ottinger’s Rules for Variable and Class Naming:
* Use Intention-Revealing Names
* Avoid Disinformation
* Make Meaningful Distinctions
* Use Pronounceable Names
* Use Searchable Names
* Avoid Encodings
* Avoid Mental Mapping
* Use Noun and Verb Phrases
* Don’t Be Cute
* Pick One Word Per Concept
* Don’t Pun
* Use Rich Name Sources
* Make Context Meaningful

Naming is one of those things in programming that is always there. Tim Ottinger wrote Rules for Variable and Class Naming for Object Mentor in 1997. This is still considered one of the seminal articles on the topic of naming and programming. I thought it might be fun to give it a read an add my thoughts.

Let’s get started.

Ottinger starts his paper with:

An expressive name for a software object must be clear, precise, and small. This is a guide to better clarity, precision, and terseness in naming.

This focus on “terseness” immediately worries me. With autocompletion and IDEs, the size of the variable or class name is the last thing I’m going to worry about. But let’s see where this heads.

Use Intention-Revealing Names

The problem isn’t the simplicity of the code but the implicity of the code: the degree to which the context is not explicit in the code itself.

This is Ottinger’s conclusion after looking at what appears to be a relatively simple Python sample. Ottinger’s meaning is here is: Even the simplest code needs to be clear in its intent.

In Ottinger’s example he takes the unexpressive names of the sample and modifies them to show the intent of the code. He takes his refactoring even further than name changing to introduce a new class using a name he had introduced in the previous refactoring. This new class adds an additional level of elegance and explicitness to the sample.

Something that started out as being difficult to understand, after some small changes, is significantly more clear.

If you have a heavy feature branch you may end up being in a place where your master local branch is actually another branch in your distributed repo. This can be confusing and cause challenges when pushing changes to your remote.

What you might see when you run git remote show origin is something like your Fetch URL and your Push URL are pointing to the same repo, and your local branch is properly configured for git pull, but git push is off. It’ll probably say something like:

master pushes to master (local out of date)

Now there are ways to configure push and use tracking, but this is how to properly push to a remote branch manually that you’re not tracking locally:

git push origin <local_branch_name>:<remote_branch_name>

or:

git push origin master:web_site

This pushes your local branch master to the remote branch web_site on the remote repo origin.

And that’s it!

For the longest time I could not get Webrick to work for me. It would boot up with rails s but would take several seconds for even the default landing page of a rails app to load. It was terrible.

I resorted to using Thin as my default browser by making sure it was in all my Gem files, but I still wanted to figure out why Webrick simply wouldn’t work for me. (Truth is, Thin is a better web server, but I still wanted to get Webrick to work for me.)

Searching for “webrick slow” brought up a possible solution via Stack Overflow. Basically you change the :DoNotReverseLookup symbol in your global Webrick config from nil to true.

If you’re on OS X Lion you’ll find the Webrick configuration here:

~/.rvm/rubies/ruby-1.9.3-p362/lib/ruby/1.9.1/webrick/config.rb

I found the :DoNotReverseLookup configuration on line 36.

Once I made the change Webrick was screaming fast. I’m pretty happy about it.

I still haven’t found the definitive reason why this problem is occurring, but at least this change appears to fix things for me.

Please note, depending on the version of Ruby you’re running ruby-1.9.3-p362 could be something different. Just as long as you’re changing the confg.rb file in the webrick/ directory, you should be fine.

To categorically define Ego is out of the scope of this writing. In order to make things easier on myself, and hopefully you, I will attempt to elucidate my meaning through example. But so that we’re all starting on the same foot, when I say ego I am referring to the informal and negative connotation of the word.

Why am I talking about ego?

For months now I have been trying to write about my journey as a newbie in the Ruby programming language. I have more than half a dozen starts to what should be a simple short piece of writing. All I wanted to do was provide some preamble so that I could then post the video I used as an entry into the Ruby Nuby contest that the Ruby Rogues podcast put together in October of last year. For some reason every time I attempted to write this article it came out feeling wrong. I’m going to try a different take on this subject now.

Several months ago I decided that I needed to broaden my professional horizons. I had been singularly focused on a few programming languages for far too long. I knew I needed to break out of that sedentary place and that there was a fundamental element I was missing. The problem: I didn’t know what that element was.

Now I say that several months ago I decided to do something, but the reality is that I have known for years that I could be doing more. This is where ego comes into play.

Ego may be the single biggest impediment to improvement.

Ego prevents us from asking questions. It prevents us from seeking out help. It stops us from acting in an empathetic way. Ego encourages us to be know-it-alls.

The astounding thing about ego is how difficult it is to counteract it. If you call someone out on their ego, what is driving that? There is likely a healthy dose of ego fueling the accusation that someone is filled with hubris. “This person is interfering with my greatness, I need to tell them to drop their ego!” At least that’s what I’ve tended to hear when someone has talked about another’s ego with me.

But for me, I believe ego has significantly impaired my ability to level up or move forward. I never wanted to accept that I was the least informed, or educated, person in the room. Often times I was being paid to be the most knowledgable person only to realize that I was maybe just slightly more experienced in the subject. Often I was either on even footing or worse! In these situations it wasn’t unusual if I found personal security in grabbing my ego tight and running with it. An opportunity for learning? I think not! I would have been more comfortable either attempting to look contemplative, while really just being confused, or, even worse, I would have attempted to derail conversations to a place where I was more familiar.

Was this always the case for me? No. Of course not. But in hindsight it happen more than it should have.

So why am I writing about this?

Ultimately breaking the ego chain was what I needed to write about when I have been trying to talk about starting fresh with Ruby. Yes, embracing newbiness requires a dismissal of ego. But the direction doesn’t go newbie to ego. It is the other way around! Ego must go before you can consider being a newbie of anything.

I wish I could say that dumping your ego was easy and that it felt good. Sometimes it does. It certainly depends on the people around you. Having a supportive group does make things simpler.

As a programmer it is tough to dismiss the ego outright. We pride ourselves on reviewing someone’s code and finding a bug, or figuring out a more elegant way to write the same method or class. Our ego is what drives us to solve problems! If I didn’t think I couldn’t do something I hadn’t done before I would never have made it in this profession at all. This is a time that ego is a benefit. Ego that pushes us, that drives us to become more than we are, that’s something we can embrace. Looking at it in this sense, it isn’t incorrect to say that ego is what is driving me to dismiss my ego now. How odd!

So in an effort to move past my typical embarrassment of asking questions that clearly show I don’t understand a subject with any sort of depth, or to try something, with varying degrees of success, just so that I can work on that particular skill, I am making a concerted effort to dismiss my ego. I made the video I’m embedding below with this in mind as well.

I want to continue to live a fulfilling life. In order for me to do that I need to know that I won’t allow something as insignificant as my ego get in the way of asking a question that could lead to a path of new experiences.

At the end of the day this is all about being a happier person.

Thanks for reading.

And here’s the video that I’ve been wanting to post here for months:

Vim is my text editor of choice. Drew Neil is an amazing Vim evangelist. If you haven’t, you should go check out VimCasts. He also has a book that I haven’t had a chance to dive into yet, but I will be shortly.

If you haven’t yet, you should check out Drew Neil’s presentation on Vim.

The first chunk, if you’re good with Vim, isn’t anything you don’t already know. It is mainly Drew trying to convince people that modality in a text editor is great. I agree. It is.

But about midway through, Drew busts out some of great power moves. Some of them I’ve not seen before, but I have immediately introduced to muscle memory workout.

The three that I picked up from this were:

1. dt. - delete until the dot.
2. vi[ - visually highlight everything between the square bracket.
3. gf - go to the file under the cursor.

Honestly, I don’t know how I never picked up gf before, but I promise it is one that I won’t forget. The other two I’m in love with. I used dt. while writing this post!

Anyway, here’s the presentation. Give it a look:

Vim - precision editing at the speed of thought from Øredev Conference on Vimeo.

Another quick tip for people using Octopress:

If you’re running Octopress on Mac OSX you may be running into some real performance issues when you run the rake preview command to check your posts locally before you run the rake deploy to get things up and running live. This is because, for whatever reason, the WEBrick server runs slowly on XCode 4.2+. I haven’t dived deep into finding a solution for this because I found a nice fix.

First, run gem install thin from your command line.

This command will install the Ruby Thin Server. This server is what I use for my Rails testing as well and it works exactly the way I want it to. (I have read many recommendations on using Pow as well, but I haven’t spent the time looking into it so I can’t personally recommend it yet.)

The next step is to change your Gemfile located in the top directory of your Octopress files. Simply add gem 'thin' to the development group and save the changes.

This is what your Gemfile should look like now if you’re running Octopress 2.0 without any changes up to this point:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

source "http://rubygems.org"

group :development do
  gem 'rake', '~> 0.9.2'
  gem 'rack', '~> 1.4.1'
  gem 'jekyll', '~> 0.11.2'
  gem 'rdiscount', '~> 1.6.8'
  gem 'pygments.rb', '~> 0.2.12'
  gem 'RedCloth', '~> 4.2.9'
  gem 'haml', '~> 3.1.6'
  gem 'compass', '~> 0.12.1'
  gem 'rubypants', '~> 0.2.0'
  gem 'rb-fsevent', '~> 0.9'
  gem 'stringex', '~> 1.4.0'
  gem 'liquid', '~> 2.3.0'
  gem 'thin'
end

gem 'sinatra', '~> 1.3.2'

The next time you run rake preview your blog on http://localhost:4000 should run smooth as silk on the Thin server.

Enjoy your sweet, speedy, dev environment!

File this under the I’m always referencing this, so I’m going to do a quick post about it category.

Tagging in Git is super powerful and can save your butt. Here are a few commands that I use often but never seem to remember.

List all your tags:

git tag

Create a tag:

git tag -a v1.4

Push tags:

git push origin v1.4

or

git push origin --tags

Checkout a tag:

git checkout -b v1.4

Deleting a tag

git tag -d v1.4

Deleting a remote tag

git push origin :v1.4

Search for specific tags:

git tag -l 'v1.0.2'

See tag data:

git show v1.4

Retroactively tag:

git tag -a v1.4 <<checksum>>

A couple of nice references on tagging:

Git Basics - Tagging
Git Ready - Tagging

Because I can’t seem to let this go, I continued to research the challenge I was dealing with a few days back where I was trying to get the cool python trick to work with Ruby hashes.

After scrubbing the Ruby documentation a more carefully, it seems that Ruby hashes and Python dictionaries are not entirely identical. Most importantly, Ruby hashes don’t have the same string methods that Python dictionaries do. Meaning: Ruby hashes and Python dictionaries, while similar, may be more of an apples and oranges sort of comparison.

With this in mind, I tried to trim up the code I wrote the last time to produce the same output. This is what I came up with:

1
2
3
4
5
6
7
8

hash = {"server"=>"gpetrie", "database"=>"localhost", "uid"=>"sa", "pwd"=>"secret"}
arr = Array.new

hash.each do |key, val|
  arr << "#{key}=#{val}"
end

puts arr.join("; ")

What I’m doing here is forcing myself to work within the confines of the initial premiss that the values are given to me in a hash. I convert the hash to an array and then use the join method on the array to do what I want to do to get the output that I want. Semi-colon success achieved!

I think we can generally agree that this is better than the option I proposed previously:

1
2
3
4
5
6
7
8
9
10

hash = {"server"=>"gpetrie", "database"=>"localhost", "uid"=>"sa", "pwd"=>"secret"}

hash.each do |key, val|
  if hash.length == 1
    print "#{key}=#{val}\n"
  else
    print "#{key}=#{val}; "
    hash.delete(key)
  end
end

For my money, the new snippet is much more readable and is just a smidge more compact. A win on all sides.

I probably won’t be returning to this subject again in the near term (unless I find out I’m totally wrong here), but expect more Ruby focused conversation coming up regularly here while I work my way through the language.

Contrary to the date listed, the previous post about Python and dictionaries and PHP and associative arrays was written a few weeks back. I’ve since been spending more time with Ruby.

After posting that article about how tight the Python code was in order to build a string with just the right number of semicolons, I decided to see if I could do the same thing with Ruby.

This is the solution I came up with:

hash = {"server"=>"gpetrie", "database"=>"localhost", "uid"=>"sa", "pwd"=>"secret"}

hash.each do |key, val|
  if hash.length == 1
    print "#{key}=#{val}\n"
  else
    print "#{key}=#{val}; "
    hash.delete(key)
  end
end

I think I’m missing something here that would make this code much tighter. This looks very similar to the PHP code that I wrote as the solution in my previous article. There’s got to be a method that I’m not using that would allow me to dismiss the delete and the hash.length that I am using.

If you have thoughts or suggestions, hit me up on Twitter and let me know.