From the monthly archives:

May 2010


This is an introduction to Ruby metaprogramming where I cover two different ways to define a method. The idea actually started as a joke, but there are valuable lessons to be learned here.
Download 11.2 MB
Download (iphone & ipod) 4.9 MB

{ 14 comments }

During the summer of 2009, Eric Berry began recording screencasts about Ruby and Rails similar to the screencasts at RailsCasts.com. He also invited other Rubyists to join him and provide recordings for the Ruby community. This is where I got involved. I did my first screencast for Teach Me To Code on Ruby on Rails Routing. This resulted in two things. First, I realized that recording wasn’t that tricky. Second, TechSmith sponsored my efforts by donating a license for Camtasia Studio for Mac and an AT2020 USB microphone.

Having been a longtime podcast listener and feeling empowered by the success of a screencast, I decided to start a podcast. I contacted Gregg Pollack and asked him about recording podcasts and got a lot of great advice from him about putting one together. In the process, I interviewed him as the first recorded episode of what became the Rails Coach podcast.

After a few more months, I had built a small community around the podcast. At the same time, Eric was becoming more interested Groovy and Grails and was focusing on other things related to his family and career. Recognizing that the majority of the audience at Teach Me To Code was Ruby and Rails developers and that his interested were taking him in the direction of Groovy, Eric asked me to take over providing the screencasts and managing the site.

I became the primary producer of screencasts in April 2010. Eric is still involved as a content producer. I combined the Rails Coach podcast and renamed it the Teach Me To Code podcast and incorporated a blog for articles in May 2010.

Eric has done an amazing job setting up systems such as the Disqus comments and UserVoice forum for suggestions. I have been extremely happy to move things along and keep the community and discussion alive.

{ 1 comment }

This part of the interview starts off with Miles and I talking about professional tracks that we’re on. He downplays his understanding of Ruby on Rails a little. He did mention that he’s been using Michael Hartl’s Rails Tutorials.

He also brought up the idea of micro brigades—groups of 2-4 people who can become super intensive support systems to help each other learn. I think the idea is really a good one. It brings in accountability and pushes everyone to move ahead with what they’re learning and provide accountability. Everyone should bring their own project.

Having everyone bring their own project, weeds out the non-programmers like recruiters and entrepreneurs that want you to build their code.

It’s also interesting how widely spread the community is and how different the approaches are, not just to programming, but to life, throughout the Ruby community. The Ruby community is also very beginner friendly.

We also discuss what it takes to be a coder and how we can encourage ourselves and others to learn how to code.

Download this Episode

{ 5 comments }


Shoulda is a framework that sits on top of Test::Unit and adds a ton of nice features like macro’s, nested context, and the ability to create custom tests in a block-based DSL.
Download 160.2 MB
Download (iphone & ipod) 71.9 MB

{ 15 comments }

Miles is a great guy. We had a terrific time talking about podcasting, work, life, and programming.

One major theme that keeps coming up in my life and came up in this podcast was the discussion over doing what you love to do.

I met Miles at RailsConf 2009 and at Mountain West RubyConf in March. We discussed doing an interview and in this episode, we wound up interviewing each other.

I think my favorite part of the discussion was the explanation Miles gave of how he formed the Ruby Brigade in his local area.

I’m not really sure how to summarize the content of this interview, so I’ll just let you enjoy it.

Download this Episode

{ 8 comments }

This week’s episode is an interview I did a few weeks ago with Kevin Rutherford. Kevin is the author of Refactoring in Ruby. He’s an agile coach, and blogs at http://silkandspinach.net. Finally, he has written the reek tool, which identifies code smells in your code.

Kevin is a big proponent of project automation like build scripts, deployment scripts, etc. He recommends Ruby and several of the tools that are built in Ruby to provide this functionality.

It turns out that Reek came out of the Refactoring in Ruby book, which stemmed from his recommendation that people use Bill Wake’s Refactoring workbook, which is Java centric to people he was simultaneously recommending Ruby to.

Kevin did explain that measuring cohesiveness across multiple classes or files is difficult and is something that he hopes can come into Reek.

We also learned that each team needs to identify and figure out how to solve their own problems.

He specifically mentions these practices:

  • Test Driven Development
  • Continuous Integration
  • Mature use of version control
  • Team Working
  • Pair Programming

Regarding TDD, there are lots of different ways of writing tests and a lot of different ways to write code to pass the tests. Kevin gives us a few examples.

He also reminds us that there are four steps to TDD, not three.

  1. Write the test
  2. Write the code
  3. Refactor the code
  4. Integrate

Code Metrics should be part of your integration and should be publicly visible. Teams also should publish their bug count. If you’re embarrassed about your bug count, you should do something about it. You should be comfortable enough with your bug count that you wouldn’t mind publishing it on the company website.

Cycle time is also important. It’s the metric that drives everything. How long does it take from request time to implementation time. When you get to under a week, you’ve truly achieved agile.

Experienced programmers really understand the importance of customer satisfaction and needs over the perfectionism in your code. Your code should be solid, but your business needs to be agile too.

Kevin recommends The Goal: A Process of Ongoing Improvement as reading on this topic.

When asked what difference it makes in using these practices, Kevin told me that the amount of test coverage goes up, the number of tests increases, development speed grows, and class sizes decrease. Monolithic classes indicate a lack of Object Oriented design.

Little value objects like currency, dates, or times can be strings or ints, but the data representation of the concepts are scattered through the code and can introduce problems depending on how the string or int is later interpreted.

Code coverage does not actually represent bug free code. It makes more sense to have a team culture to write tests for each surprise or bug that you encounter (as well as writing new tests for new features.)


Download this episode

{ 1 comment }


RSpec provides an extremely concise way of representing simple tests to be called on new instances of a class or on explicitly defined receiver objects. You can do this by using ‘subjects’ either as defined by the ‘describe’ or the ‘subject’ methods.
Download 38 MB
Download (iphone & ipod) 18.2 MB

{ 12 comments }

This episode of the teachmetocode podcast, Dave talks us through the process he and Andy Hunt went through in founding the Pragmatic Programmers book series and publishing company. Dave also talks about the the advantages that they have had by not holding onto or being mired down by the way things have always been done and their growth in non-conventional book selling channels.

He also mentioned that if you would like them to come do training where you’re at, contact Mike Clark and find people who are willing to sit in on the course.

I think my favorite part of the interview was his explanation of where the Agile Manifesto came from. We also got to talk about what Agile development really is.

Dave explains the correlation between his musical interests and his programming interests. He figures that at least 30-40% of speakers at any conference would have some sort of musical background. The structure and the way things come together in music actually applies to software. You create patterns or structures that work well together at multiple levels.

Toward the beginning of the Pragmatic Programmers, Dave and Andy recommend learning a new language every year. He discusses his hobby of picking up new programming languages and investing in yourself.

Finally, I asked Dave about running a business and how to get one started. He gave some terrific advice regarding building your own application and business.

He wrapped up the episode by pointing out that programming is exceptionally hard. You have a huge amount of information you have to know in order to get into programming. On top of it, the world is complicated and makes the problems we have to solve hard. So, ultimately, make it fun!

Download this Episode

{ 16 comments }