We are joined by Heather Payne, founder of Ladies Learning Code, a [a women-run not-for-profit group working to empower everyone to feel comfortable learning beginner-friendly technical skills in a social, collaborative way.] (from ladieslearningcode.com)

Discussion

• Ladies Learning Code events
• workshops have a 4:1 ratio of students to instructors
• it is more difficult to build web apps than simple websites
• PyLadies workshops
• workshops are open to all, men and women
• Ladies Learning Code would like to know: Have you transitioned from the workshop to development work?
• JavaScript
• HTML/CSS
• Ruby
• WordPress theme development
• Mobile Web
• Photoshop, Illustrator and InDesign
• Reception has been positive
• This is an intensive 8-9 hour process
• Workshops make it clear that women are welcome
• Assumptions of women’s involvement in tech projects tend to be more toward marketing/social media, and not development
• Job description language should become more gender neutral
• There is a demand for developers
• Is foul language and naming conventions in some libraries off-putting or offensive for women?
• Parents make assumptions on their children’s interests based on sex, this contributes to less interest in technology later on
• “It’s cool to act dumb in math and science class”
• Mozilla Community Space
• Build interest in technology when people are younger
• Kickstarter
• LEGO Mindstorms
• Scratch
• Hackety Hack
• Hackasaurus
• HIVE Learning Network
• HopScotchKits.com
• CodeNow
• KidsRuby
• CodeAcademy
• You’re more qualified than you think you are
• eMail list
• Ladies Learning Code on Twitter
• Heater Payne on Twitter
• Ladies Learning Code on Facebook

Peter Ledbrook is an engineer at VMWare and an evangalist for Groovy and Grails.

Discussion

• The Grails Podcast
• Groovy
• Grails
• JVM
• Static typing
• Dynamic typing
• Optional static types in Groovy
• closures
• Ruby
• Rails
• Java
• Spock
• Jar files
• EnvyCasts Video on Java Jar’s
• Dependency management
• Java resources for Grails
• Spring
• Spring Beans
• Apache Camel
• Spring Integration
• Spring Security
• Servlets
• Breadth of libraries in a particular language
• Spring Social
• CloudFoundry
• Grails’ Plugin Ecosystem
• Groovy web console
• Groovy books
• Groovy user guide
• Grails user guide
• Introductory screencasts on grails.org
• Groovyblogs.org

Peter also gave me these links via email for people to look at:

Groovy website:

http://groovy.codehaus.org/Documentation

Online Groovy console:

http://groovyconsole.appspot.com/

Groovy Blogs:

http://groovyblogs.org/

Grails user guide:

http://grails.org/doc/latest/

Free PDF book!

http://www.infoq.com/minibooks/grails-getting-started

Introductory screencasts:

http://grails.org/screencast/search/?tag=gswg

Chris Mattmann is a Software Engineer at NASA’s JPL. He’s the VP of OODT in the Apache Software Foundation and an adjunct professor at USC.

OODT is a framework for managing data from multiple sources and adding them to other data sources for different purposes (like a database and a search engine.) It manages hundreds of thousands of job in a day and terabytes or petabytes of data from various sources.

Mentioned in this episode:

• Apache OODT
• Nutch
• Hadoop
• Apache Software Foundation
• NASA
• NASA JPL
• ftp
• sftp
• Solr
• Lucene
• Hive
• File Catalog vs Search Engine
• Tika
• Goodle
• Project Management was the hard part
• Assume that failure happens and recover quickly
• Ganglia
• Torque
• PBS
• struts
• IDL
• CHLA (Childrens Hospital of LA)
• VPICU
• OODT Contact page (info on mailing lists, etc.)

Today I am joined by Karl Wright, Nokia engineer, ManifoldCF developer and author of ManifoldCF in action. We discuss ManifoldCF, an Apache Incubator project, its beginnings, its purpose and its inner workings.

AppDynamics is a company that provides a monitoring solution for .NET and Java platforms. I spoke with the VP of Engineering and one of the developers of the AppDynamics platform to dig into how they instrument your Java or .NET code and some of the tricks for following transactions from beginning to end.

There were a lot of neat tricks in this podcast episode

Jim Jagielski is the president of the Apache Software Foundation and works for Red Hat. He’s a founding member of the Foundation and has been a developer on the HTTP server for over a decade.

We had an inspiring conversation about the Apache Software Foundation, the origins of the HTTP server, how the Foundation manages projects, and the incubator program. If you manage or contribute to Open Source software, then this is a discussion you’ll want to hear.

Jonathan Ellis is the Project Chair of Cassandra and co-founder of DataStax,  a company that specializes in helping companies set up BigData stacks with Cassandra, Hadoop, and other open source software.

His company just released DataStax Enterprise.

We had a great discussion about the origins of Cassandra, what it’s good at, how it stacks up against relational databases, and how a lot of its different parts work.

Lucene is a terrific tool for powering searches. Solr adds a layer of functionality on top of it that makes things even more easy to use.

In this interview, Grant and I discuss the ins and outs of using Lucene to power searches on your websites.

I got an email from Michael Seely asking about being a freelancer. I emailed him back and asked him if he’d like to interview me for my podcast and ask me whatever questions he had. He agreed. This is the podcast that resulted.

I haven’t done a podcast in about 3 weeks. I’m changing some things around and wanted to let you know what they were.

For this podcast, I plan on foregoing my occasional rants on programming and do interviews every week. If you know someone who I should have on the podcast, then let me know.

I’m going to change the format of the Screencasts as well. I’m going to move from a library demo meme to actually building web apps from start to finish. I think these tutorials are useful and insightful. It’s also a little different from the other things out there.

RailsRookies.com was launched last week. Right now it’s a page listing the courses I’ll be teaching over the next few months. If you’re interested in those courses or something that isn’t up there, then fill me in on what you want. I’d love to provide it for you.

The Ruby on Rails Basics course starts next week.

The newsletter is going to be published every other week. I’ll try to share some insight from what I’m reading, studying and working on. I hope you enjoy it.

I’m also trying to figure out who is interested in a Freelancing community centered around Ruby. If you’d like to be involved, contact me.

Finally, I’m working on some new projects to try to supplement my consulting income. One of them involves Boy Scouts. The other involves online Pay Per Click marketing.

Coulda
Filet
Test::Unit

Thoughts on what make good acceptance tests:

• Don’t write brittle tests
• Communication between the coder and customer
• Not being low level
• Keep them at the same level of abstraction

Thoughts on Cucumber:

• Jorge likes Cucumber’s Given-When-Then
• Cucumber’s plain english definitions are extra overhead when your customer isn’t going to read your
• english definitions.
• Evan likes Cucumber for:
• Popping the why stack
• Given When Then And
• Evan doesn’t like:
• It’s an external DSL
• Boundary between the test language and the code
• Has loose coupling between step definitions

We need our acceptance tests to run fast too.

How do you test your javascript?

• Selenium tests on the critical parts
• Ignore the javascript and test the ajax requests.
• capybara-webkit

parallel_tests gem
Hydra
jasmine-fixtures

Marty is the organizer of the Boulder Ruby Users’ Group and Rocky Mountain Ruby Conference. He’s been programming Ruby since 2005.

Charley has been programming Ruby for about 6 or 7 years and doing IT for about 15 years. He got involved with Watir, which led him to Ruby.

The Rocky Mountain Ruby Conference is held in Boulder and includes several hikes and other activities not normally included in a conferences. I’ll also be speaking at the conference.

We went over the differences between the “Boulder Area” and the “Denver Area”. They’re 15-30 minutes apart, but culturally they’re pretty diverse. Boulder is small, but is becoming a startup and technology hub.

Both Marty and Charley have been talking about the food experience in Boulder and they’re setting up the conference to be a great food experience as well.

I asked if Marty and Charley view the community and regional conferences has changed after organizing a conference. Marty actually helped with Mountain West Ruby Conference. He also went into some of the challenges of picking a date and arranging the conference. He came up with the conference to get local people involved.

They also went into how they work around repeated talks and whether or not they want them. Repeaters are OK, but you want a unique program and conference.

We also discussed how talks are picked. How much weight the topics, speakers, and explanations get.

The discussion finally turned to the venue, which is the historic Boulder Theater. It sounds like a terrific way to run a conference with some of the options they have with setting up the experience. Much different from the hotel based conferences.

Igor started developing in Nginx in 2002. He started building it because he needed something that would effectively proxy connections in an event driven manner. The other webservers at the time could only handle static content and didn’t scale well.

Initially, Nginx was used to proxy Apache webserver.

Igor was never really fond of fastcgi. It took him 1 to 1 and a half years to add it to Nginx after it’s public release. He explains his opinion on fastcgi.

Igor also tells us the primary differences between Apache and Nginx and explains the tradeoffs between the two models.

We also dug into what is coming up in the next releases of Nginx and how things will move ahead now that they have formed a company around Nginx.

If you would like to donate to Nginx, go to http://sysoev.ru/en/donation.html
You can also get on the mailing lists for Nginx at http://mailman.nginx.org/mailman/listinfo
Finally, follow Nginx on twitter at @nginxorg

In this episode we discussed:

• MongoDB
• Standardization of NoSQL databases
• Portability between non-relational databases
• CouchDB
• PostgreSQL
• AGPL license
• PostgreSQL license (like the BSD license)
• MySQL is GPLv2
• Drizzle has rewritten their MySQL driver so it’s not GPL
• Oracle’s behavior toward products they own that compete
• InnoDB MySQL engine
• Microsoft SQL – The price hike and bug report that drove Josh to PostgreSQL
• Customer expectations vs Intended functionality
• GreenPlum
• Alexa
• Implementing the minimum feature set and getting feedback.
• Transactional DDL - All operations are transactional except create database.
• Database Migrations – PostgreSQL can do migrations with no downtime.
• Memcached
• Redis
• Solr
• ElasticSearch
• Foreign Data Wrappers – a driver for external data sources that can then be managed through PostgreSQL
• Lucene
• Hadoop HBase
• Cassandra
• Project Voldemort
• HyperTable
• Riak
• Amazon Cap Theorem Papers
• VoltDB

Here’s a list of several of the things we discussed:

• How PostgreSQL got started
• Ingres
• The Apache Foundation
• The PostgreSQL core team and it’s role.
• Data Warehousing
• It’s community property like Linux
• The SQL Query Language
• The C Programming Language
• gcc
• Standardization
• Google Summer of Code
• XML Indexing
• XPath Support
• ISN/ISBN Data Type
• Array Data Types
• HStores (Dictionary or Hash)
• Full Text Search
• Tri-grams
• Sphinx
• Lucene
• Why people switch from MySQL
• Performance
• Reliability
• Special Features
• Supports really complex queries
• Worry about the future of MySQL
• Skype – 200 Postgres servers
• Sky tools clustering platform
• Heroku
• San Francisco PostgreSQL User Group
• Differences between MySQL and PostgreSQL
• MySQL was originally written to please web developers
• Postgres was written by DBA’s
• Postgres will throw out a feature they can’t stabilize
• MySQL will accept a feature and then try to stabilize it
• Postgres really allows you to run code inside the database
• Postgres is more reliable and secure
• Lowers admin cost due to better uptime
• Rails was originally built around MySQL
• You can get some boosts by bypassing the ORM and going directly to the database
• Full JSON support is upcoming
• Django
• The PostgreSQL Ruby driver
• ByteA binary data type
• Simplified data types (Text data type)
• Why people switch from PostgreSQL to MySQL
• MySQL has been commercially successful longer than postgres
• Vendor tools
• Cheap hosting for MySQL
• A lot of things are designed to work out of the box with PostgreSQL
• PGSQL Novice list
• Postgres Open
• Postgres has a new version coming out soon (changelog)
• Postgres 9.2
• Multi-core support
• Postgres included documentation
• Beginning Databases with Postgres – Dated but gives the basics

To hire Josh’s guys, go to http://pgexperts.com.

Download 6.08 MB
Download (iPod & iPhone) 4.61 MB

In the Pragmatic Programmer it talks about your knowledge portfolio and recommend that you invest in it regularly. In fact, it draws the analogy of a stock or financial investor and how they invest.

I discuss my experience in investing and my thoughts on the content of the Pragmatic Programmers book.

The only major difference or disagreement I have between their suggestions and my experience is that today most of the content you’d find in books or trade magazines is available online in blogs, videos, and other media. However, in some cases, the best documentation is in a recently written and maintained book.

Here are some of the things I mentioned in the podcast:

• Ruby Reloaded Peter Cooper’s Ruby Course
• Teach Me To Code Academy – Ruby on Rails Course
• The The Pragmatic Programmer book

One of my clients had Pivotal Labs build them a website. After Pivotal Labs finished the project, they helped them find a developer to maintain it for them. I took over from him.

This last week, I had to dig deeply into the javascript code to make a piece of functionality I was modifying conform to what they had in other places on the site. What happened during the two days I worked on it was that I learned how they had things set up. Here are some of the things I found.

Jelly

Jelly provides you with an extension to the JQuery framework that allows you to trigger callbacks from your Rails controller. It’s exceptionally useful for things you need to occur when your server call is completed.

Namespaced Functions

The Pivotal Labs developers put a lot of things under a namespace named after the project. They further namespaced functions under namespaces corresponding to controllers and widgets, with some functions matching up with action names where widgets and other functionality could be implemented and initialized.

This is really handy in cases where you need specific functionality only is specific cases.

Javascript Loading at the end of the page

Finally, a method in the ApplicationHelper was provided that added all of the requisite javascript files to an array and then called javascript_include_tag on the array to include all of the files. This was done at the bottom of the page to avoid holding up the rest of the page loading while waiting for assets.

This also allowed for functions that required the DOM to be loaded to simply be called instead of using the JQuery $(function(){…}) callback style.

I’ve had two people ask me about freelancing within 1 day of each other. So, I’m going to give some advice. I also talked about finding freelance clients a few weeks ago in this episode.

Talk to other freelancers to see if they know people looking for work. It’s a great way to get advice as well as referrals.

Start talking to people in the community. I found all of my original clients directly or indirectly by talking to people I knew both locally and in the international community.

You should also go find a good accountant and have him advise you on setting money aside for taxes and structuring your business to save you on taxes. My accountant has probably saved me thousands of dollars on just this alone.

Your accountant will probably tell you this, but set up a business entity (usually an LLC or S-Corp) and get an EIN tax ID. It makes it much easier to write off expenses, avoid being dubbed an “employee” of your clients by the IRS, and makes keeping your books simpler since you will have to get a separate bank account.

The IRS looks for freelancers who are, for all intents and purposes, employees of their clients. To avoid this not only do you need your own business entity, but you also should have more than one client and use your own equipment when working for them.

Figure out what you need to charge and charge it. There are cheapskates out there who will be shocked that you want to charge them more than $20-30 per hour. Stick to your guns! Go to the Freelance Switch Hourly Rate Calculator and figure out what you need to charge to get by.

The problem you run into with the cheapskates is that these people are looking at Filipino and Indian developers on oDesk. Several of these developers are decent developers. A lot of them aren’t. Your potential client usually doesn’t know how to weed them out. So, if they insist that they’ll go overseas, let them.

Start a blog. Write about the stuff you’re doing. Someone will want something similar done. I’ve gotten a bunch of business off the Twitter Clone videos Eric did a while back because people are googling “Twitter clone.” I’ve also seen quite a bit of interest from my podcast, even though it’s geared much more toward programmers.

Finally, don’t be afraid to fire clients that don’t fit with your lifestyle or business. And don’t be afraid to raise your rates periodically when you need more time or money to make things work.

Gregory Brown is a longtime member of the Ruby community. His contributions to the community include his recent involvement in the RubyGems discussions, Ruby Best Practices, the Prawn library, and Ruby Mendicant University.

Ruby Mendicant University is a free online school for software developers. It’s a blended teaching and mentoring program that helps people improve their coding skills. It’s aimed toward intermediate level programmers.

The “RubyGems uprising” is something that Greg stepped in and opened up some dialog about the direction and movement of the RubyGems project. The future is looking bright and the public management of the project is much better.

Greg has contributed to open source through the Prawn library. He responded to Brandon Hays’ query about getting involved in open source software and gave us some pointers about getting involved and managing open source projects. One thing that stood out was when he talked about not taking feedback on your open source project personally.

It’s really eye opening to consider that when people deprecate or remove features from a project like RubyGems, it may be so that things can move forward in a meaningful way.

Finally, we talked about the Ruby Best Practices book, the process of technical book writing, and the process of teaching and learning programming. Greg has given a lot of thought to how and why we learn to program.

Ryan Smith is an engineer at Heroku.com. He wrote the queue_classic library in Ruby. He was a speaker at RailsConf talking about the Worker Pattern. He blogs at http://ryandotsmith.heroku.com/ and tweets at http://twitter.com/ryandotsmith

We talked about several things, including:

• Heroku (the company and the service)
• Salesforce’s acquisition of Heroku
• queue classic
• postgresql
• the Worker Pattern

He also mentioned these things in relation to the topics we discussed.

• h-store
• mvcc
• postgres wiki
• web sockets

Gary is well known for a few things including destroyallsoftware.com, Ruby vs. Python: A battle to the death, and his discussions on tools, process, and programming practices.

We had a great discussion regarding learning to use your text editor, learning tools like git, and overall ways to improve your skill and efficiency when programming.

Over the last few weeks I’ve been using macvim and janus to write code. The more I learn about VIM, the more I love it.

It’s not so much that VIM does things that I find particularly natural or “better”, but rather it’s that it’s extremely powerful for opening, managing, and editing files. Each little trick I get brings me more and more to the place where I can code as fast as I can think.

The Pragmatic Programmer (book affiliate link) tells us to know our text editors. The more I get to know about my text editor, the better off I am.

Here’s the video:

There’s a lot more to the ABC iPad app than just the iOS components. There’s a HTTP Live Streaming level to this that manages all of the content for the application and streams it to the devices.

Tyler explains the history of Protoven, Uplynk, and a lot of technical details behind how the ABC iPad app hangs together both on the backend and frontend.

Here’s the video of the interview:

Jamis Buck is a Ruby on Rails developer working at 37signals. He was part of the Rails Core Team, created the SQLite driver for Ruby, and created the Capistrano library for deploying applications in Ruby.

We talked about several things including:

• the Maze algorithms he’s been working on on his blog
• Capistrano
• Ruby on Rails
• 37signals
• Vim and text editors
• Testing tools

Here’s a video of the interview.

Tom Preston-Werner is one of the founders of Github.com. He’s a Ruby programmer who has successfully launched a business used by hundreds of thousands of programmers all over the world to host their programming projects. He is also the original developer behind Gravatar.

We discussed how Github.com got started. Tom also mentioned Gravatar, god, and Jekyll.

We also discussed open source software, contributing, hiring developers, and what makes Github such a great place to work. If you want some good pointers about how things should work at a development shop, I recommend this episode.

Freelancing is a lot of work. One of the hardest parts is finding clients. I’ve been getting a lot of work lately and I’m going to explain where I get most of my work from.

• Podcasts and Screencasts – I’ve had several people come to me after listening to my podcasts or watching a screencast and ask me to do some work for them.
• Referrals – I’ve made several contacts within the community and though some of my clients that have resulted in getting referrals. Make friends. Build your network. It will pay off.
• Users’ Groups – This is similar to the referrals comment. However, some entrepreneurs and other non-technical people sometimes come to the meetings. You can also meet people who are connected to the local community. It’s amazing to me how much business I’ve got because I met the right person in the local community and they heard about business that didn’t come out to the wider community.
• Job Boards – This has been the least productive for me. Effectively, you are chasing cold leads. They do work, but the conversion rate is much lower than any of the others I’ve listed.
• Recruiters – I found my first long term contract through a recruiter. I was referred to him and it worked out really well. I’m still working for this client.

In the podcast I share some other stories and thoughts. Listen and then leave a comment to let me know if there’s anything else you’ve tried that worked for you? I’m also interested in your success stories using some of these ways of finding work.

Download this Episode

I got asked the question “When do I stop testing in order to get stuff done?” My answer was “I go faster doing TDD.” Here’s why I get more done with TDD.

It forces me to think through the problem. This allows me to tackle the programming problem and solve it more quickly.

I can define the behavior. I can determine the inputs and outputs and any other behavior related to the function I’m writing.

I know it works when I’m done.

I know when I’m done. (All the tests pass.)

It provides a challenge I can focus on. I love a challenge and it gives me that sort of strong direction.

If you have trouble getting things done and getting tests in, you need to practice. You need to get used to working with tests and testing frameworks. The more you do it the better you are and the more it becomes integrated into your routine.

Learn your tool. The better you understand what it can and can’t do, the better and quicker tests you’ll write.

Only test what you need to test. You don’t need to cover the entire code stack. Just the limited set of code that solves your problem.

Transcript

Teach Me to Code Episode 54 Hey everybody and welcome back to another Teach Me to Code podcast. This is your host, Charles Max Wood and this week I’m gonna be talking about, well I wanna answer a question that somebody post to me and I kinda going to enhashing out, what I think. But before I get started I want to acknowledge our sponsor. We have New Relic. New Relic is a super application management tool. They really do a good job by providing just some great information regarding what’s going on with your application, what exceptions are being thrown, what other problems, performance problems there are. Most of what I’ve used it for is actually either tracking down exceptions or working through and optimizing areas of the application that are slow. And they are so useful for that. Even their free version is actually pretty useful in just a couple of useful information you can get out of it. It’s really good, I highly suggest you go check ‘em out. You can do that by going to the website and clicking on the link on the right or you can go to newrelic.com. and just tell them that we sent you over. That would be great. Now, I’m gonna go ahead and jump into this topic. I’m trying to get some interviews lined up. I just haven’t spent the time to talk to people. I’ve had a few people say they’re willing, I just haven’t followed it up. So, I need to follow up and get some people on here and hopefully we can line up a few interviews here for the next few weeks. I’m thinking about changing the format of this a little bit, but I haven’t finalized what I’m thinking about so that’s just something to be aware of, that things may change within the next few podcast episodes. Alright, well let’s get into this question. So, I was chatting with a friend of mine and he asked me, cause he was facing a deadline. He said, “At one point, do you just give up on writing the test and just crank the code out because you need to get it done yesterday.” And it was interesting because I thought about it for a second and I realize that, writing the code without the test, like not doing TDD for me, actually it hampers me, and it hampers me in a lot of different ways. Mainly it’s just part of my workflow now. So, it’s kind of an interruption not to have TDD around. The other thing is it provides some real benefits to me as I’m coding that I think really make it worth the payoffs. So we’re gonna talk about those. The first thing that I think TDD really gives for you is that it allows you to think through the problem. So, you can quantify the behavior of whatever you’re testing. And even just a basic input-output kind of approach. So for example you say, “If I called this method with these arguments I should get these result”. And sometimes that’s enough. But the other thing is you also are then force to think about what other effects or behavior should come out of these. For example: should it save the record. In Rails that’s a relevant thing or should it save the object to the database or should it change certain attributes of my object or do this other things and so then you start running through the scenarios of: “Ok, so when I put this and I should get this back out and this object that I passed into it should now look like this.” And the nice thing is, once you have that in place, not only do you know what it’s supposed to do and know what you expect the behaviors of the other things that are being passed to it to be. But you’ll know when it’s done and you’ll know that it works when it’s done. Because you finished it off and you specified what it’s supposed to do. And so, you really get that benefit of knowing that, “Hey it works, and it works right and I’m done with this and I can move on to the next part”. The other thing is that, it forces me to think through the problem. Not just to codify, “Ok this is what it’s supposed to do and this is what supposed to go in and this is what suppose to come out.” But usually when I’m thinking that through I’m thinking: “Okay, so when I implement this, I’m probably gonna do something like X and Y and that would get me 90% of the way there or all the way there.” And it really just pays off. And so by the time you get around the coding and you work through the problem somewhat mentally because you wrote the test for it. The other thing that really pays off for me is that you wind up, for me I love having a challenge. So, you know, I get a puzzle and I solve the puzzle and if I’m working on a puzzle that’s interesting, I actually wind up getting really focus on the problem and try to solve it. And the test provides that for me. So when I write the test, I’m basically writing myself a puzzle or a challenge that I need to solve. And so I wind up going in and solving it. And I can focus on that for few hours and, you know, really wind up doing some interesting things. And so ultimately, I think it goes faster because in the end, you know that the thing works but you don’t wind up debugging this and that to try to figure out why it’s not working. You wind up doing a little bit of that sometimes but ultimately if you’re running into that, you can just write another test. “Okay, so let’s see. This test isn’t passing and this is what going on. So what if I assert that this other case is the case”. You know some intermediate step. Or you may find out that you need to pull part of your method or function out into another method or function that it calls into so you can test that one little piece. And what that does is it actually winds up cleaning up your code and forces you to re-factor things into a sane setup and ultimately makes you really think through the problem. And it gives you a framework to do that in because when you’re done all your tests will pass and you’ll know “Okay, not only have I covered what it suppose to do but I’ve also covered a few of the gotchas that is part of this algorithm.” Now when people ask me a question like this, and this is something that I really want to tear into. It usually comes down to, that they’re not as comfortable or committed to TDD. And ultimately, there are few reasons for this. One is it that they don’t see the importance of the test so they’re not committed to testing in general. And that’s a hard thing to solve because ultimately when you’re writing your code, if it works you don’t see the benefit of the test. But when you go back and you’ve had an experience where the test either told you that you broke something or the test told somebody else that they broke something you wrote or you’ve seen something like what we’ve just talk about TDD, where you wrote the test and it really payed off in the sense of “Hey, this worked you know, this worked, it‘s done.” And you’re like “Oh wow, that really worked out cause otherwise I would been sitting here trying to figure out whether or not it’s doing what it suppose to do.” And when you start getting those payoffs then you start to really get committed to testing. Before that I think it really just a matter of “Well this expert said that I should” or “My boss says that I need to” or “The senior developer that I’m working with does” or “Whatever the community in general thinks that a good idea”. Or “I read this book and this guy said that I oft to”. And so you start doing it and you know, if you don’t get that payoff pretty quick, then in a lot of cases people just don’t get committed to it. The other reason I’ve seen is that people start writing test and they realize real quick that: “I’m not really sure I’m doing here” or if their okay with the kind of the general “I need to write the test to make sure this functionality is in place.” Then what happens is they wind up not knowing their tool or, you know, some other thing kinda gets in the way and makes it hard for them to write the test and so they are like “Well, theoretically this is worth the effort but it’s a lot of work”. And it is upfront. It is, even if you understand the testing tool in general, you wind up seeing “Oh man, this is an interruption in the middle of my normal flow”. And when I first started doing TDD that was the way it was for me. I really felt like it was just getting in the way and causing me issues up front. But once I had fought my way through the test, writing the code was actually pretty easy. So, I highly recommend one that you try it for a while. It’s kinda like pairing in that sense, I’ve had a few people tell me that they want to start pairing with their development teams. And I usually tell them a couple of things I see. First off when you start out, don’t do it all the time but do it half the time. The other thing is, when you start pairing, you need to talk over how you wanna handle certain things like interruptions and things like that. And that’s how it go for pairing. Doesn’t apply too much to testing. However the last one is, you have to do it for at least a month. And for the last half of the month, you need to be doing it all the time. And the reason is because, once when you start, your productivity drops with pairing. It just, it does. I mean, your code quality goes up and there are certain benefits and payoffs. But ultimately your productivity goes down because you have two people that aren’t used to working together figuring that out along with figuring out the problems that they’re solving. But by the end, what you’ll see is that you usually get back to at least the productivity you had before with two people working on the code. And what you gain from that is a high level of communication and a better understanding between your team. And it’s the same thing for testing. So, ultimately, at first it is tedious, it gets in the way, it takes a while. It’s hard. “Do I test this? Do I not test this?” You know it’s really does get tricky. But if you give it at least a month, you will really become engrained. What you get out of it is it becomes a part of your flow so it’s not an interruption anymore and then what happens is you start to see these things pay off. And as soon as you see it starts to payoff then you really get committed to it. And that makes a huge difference. One other thing that I really want to tell you is, go learn your tool. So in ruby you have rspec and you have test unit. In other languages you have J unit or N unit. I don’t even know. I mean, there are dozens of them. If you’re writing for the web you can use selenium or water. You need to know what the tool is that you’re using. What it does well. What it doesn’t do well. What you can test with it. What the limitations are. And that will help you write better test. It will also help you work around some of the hairy issues because you’ll know how to hook into them with your tool because you understand it. I’m going through a little bit of a learning curve right now because I’ve been using cucumber for my integration test for a long time. And I’m always using it because a few people that I considered to be experts were saying “Use cucumber, it’s awesome!” And generally that’s true but the recent debate with David Heinemeir Hansson and a few other people regarding rspec versus test unit really made me think and I think this is really the thing that get out of it. Really made me think why am I using this tool. And it really occurred to me that the value of cucumber is so that somebody else can read my test. Well most of my project, nobody is looking at my tests. And the few people who are, are technical people like me. Ain’t gonna understand code just as easily as they can understand English. So there is no reason for me to be writing these English sentences and then figure how to parse them apart so that I can use webrep or capybara to hook into my website. So I am learning capybara and I’m just gonna hook it in to rspec. But that means I need to learn capybara instead of relying on the built in steps that come with cucumber than to use capybara. So in that case it was a simple translation to English and it was built-in that it would translate that to capybara but now I just want to use code I have to learn the library. Honestly it’s something I should have done before. I’ve used it before but it’s really something that I really want to do better. Now the last thing that I want to focus on is just test what you need to test. So for example, If you’re building Ruby on Rails applications, you don’t need to test the framework. You don’t. Unless you’re running into a problem where you think that the problem might be the framework. In which case then you’re write to test it to rule out the framework. But other than that, there’s just no reason to do it. The developers that are writing Ruby on Rails have, I think they have pretty good test coverage and hopefully the library will just work. It’s not your job to test somebody else’s library. But if you needed to work and it is the library, then maybe you need to. So again, it comes down to what you need to do. But testing, for example, if you’re writing a test for user class, you don’t need to go out and test the post class from the user class when you’re working with post on the blog. That doesn’t make any sense. You just need to test the user class and if it does have interaction with the post class then mock it out so you don’t have to worry about the post class and just assume that they behaves in a certain way. That it gives a certain result or whatever it is that you needed to do. And then make sure that your test of the post class guarantee that it has that behavior. If you can tears it apart that way, that keeps your test a whole lot cleaner, simpler and easier to write. Marking and stabbing is something that I think is essential for writing your test. But I’m not gonna go to it right now. Make sure though that you do have a good tool for any of this practices. So in Ruby on Rails, I typically use rspec. I typically use capybara, it’s what I’m using now for my integration test. I use flexmark for my marking and stabbing. I use Factory Girl to generate new objects that I need to operate on. Which Factory Girl is another thing that I wanna bring up. And this is a debate within the Ruby on Rails community. Ruby on Rails comes with a concept of fixtures which basically is a file that sets up several objects for you. And then you can operate on those objects. The problem with fixture is if you change a fixture that a test depends on, then it could break the test. So, I like instead to use factories and each test gets its own object. And this created when it runs. Factory Girl provide you with creating valid, consistent objects you can use across the board and you can customize them if you need. So it’s a nice way to just get a consistent result or a consistent baseline that you can run from. So I use a factory and I use marking and stabbing pretty frequently. And on occasion I use other tools like, I use selenium to test my java script on my pages which is kind of fun. I think it’s kind of fun to watch it run because it actually pops open Firefox and runs and then closes it again. So, anyway, those are just my thoughts there but ultimately, if you understand the tools, you know how to use them, you know how to interface with them, you can make it do what you need it to do and you just practice. You’ll get a whole lot better with TDD and ultimately you’ll find that it is an essential part of your workflow and it really does make your code better. So in general, you should be testing. If you want to write your test afterward, fine with me. TDD for me though is an integral part of the way I work. And in the end I get the added benefit of knowing that something broke or didn’t break. So anyway, I’m just gonna wrap this up. I do wanna again, acknowledge that New Relic is the sponsor of this podcast and I really appreciate them helping me out with it. I also want to just remind you that if you need help with your Ruby on Rails application, you can contact me. My phone number is 801-367-6164. I also restarted the Rails coach podcast and you’re maybe interested with that if you’re learning Ruby on Rails. I’ve changed tactics a little bit. I’m trying to cover concepts that will help you become a better Ruby on Rails developer. But I’m not gonna go into specific code implementations anymore. Mainly because I feel like that those are better covered on screencast rather than a podcast. And anyway, so if you’re learning Ruby on Rails that is a good place to go or you can just give me a call and we can set up a time where I can kinda help coach or mentor you. I generally do that for charge but if it is a 10, 15-minute thing I might just help you out for nothing. But I do wanna make sure that people are learning this and they are comfortable with it. I just, oh that was the other thing I wanna talk about. I gotten together with a few other people and we’re gonna start a new podcast. If you’re fan of Leo Laporte and Twit.tv, this is kind of the same style of podcast. We’re gonna be talking about issues, we’re not gonna talk about news. We’re gonna talk about issues surrounding ruby and ruby community. So for example, some of the topics that I’ve thought of that we could talk about are, whether or not it is worth using Rails over Senatra. Or some of the other frameworks that are out there. Things like that. Rspec vs test unit vs Emex. How to test java script. Whether or not to use jquery with your Rails applications. Just stuff like that, you know. We’re probably talk about the copy script debate that’s going over right now over the Rails 3.1 standard. Anyway, I have James Edward Gray, Peter Cooper, Aaron Patterson and David Brady that are all going to join me on the first episode of that podcast. It should be really fun. We haven’t nailed down what the topics are gonna be at but it should be really, really good. And if you’re wondering about any of those guys, just Google them and we’ll come out. I’m just gonna wrap this up and remind you that writing the code is the easy part.

Every programmer should find opportunities to learn something new.

Why?

• It causes you to confront new problems.
• It increases your ability to solve problems.
• It expands your skill sets/profitability/versatility.
• It keeps your mind sharp.

How?

• Jump in
• Take a course
• Find a Mentor
• Read a Book
• Search the Web
• Read the Code

Reasons why I sometimes fail at this:

• Time
• Family
• Clients
• Projects
• Podcasts
• Money

Solutions:

• Spend 1 hour per day on learning new technologies.
• Leverage my time better.
• Set a schedule.

Download this Episode

Here’s the video version:

You can get the video version of this podcast here.

David Heinemeier Hansson sparked a debate on Twitter about Ruby testing frameworks. A lot of people saw it as slamming RSpec and others saw it as constructive conversation about what tools you use and why. This is how I view to see it and where I come down on this debate.

I also discuss why we have these debates in general and what we can learn from them.

At Mountain West Ruby Conference, Mike Moore brought up that many members of the Ruby community have lost part of the community roots. Particularly, the acronym MINASWAN, which stands for “Matz is nice and so we are nice.”

There are a lot of people out there who, rather than looking to help, are looking to fight or trying to look good. The funny thing is that if you can make a real contribution, you do look good. So, here’s a discussion on how to contribute to the community in a positive way.

Download this Episode

This week’s episode is an interview with Chad Fowler—author of The Passionate Programmer.

This week I go into hiring developers and how you determine whether or not they’d make a good employee. The hard thing with hiring is that you really don’t know what you’re getting until you’ve made the hire.

You can look at their code, pair with them, and talk to them to get a feel for who they are and how they operate, but in the end, there’s only one definitive test—putting them to work and seeing how they work out.

Download this episode

This turned out to be a great interview with David Heinemeier Hansson. He’s the creator of the Ruby on Rails web framework and a partner at 37 signals. We discussed what inspired him to build Ruby on Rails and work in Ruby. We talked about how 37 signals approaches things. We went into the Rails community and its ecosystem.

A few things that were mentioned:

• Capistrano
• Basecamp

On entrepreneurship, David tells us that building a company and concept has never been easier or cheaper. The barrier to entry is extremely low. You need more than programming power or business acumen to start a company. You need people who have an actual skill that will move the product or service forward.

Download this Episode

I’ve been reading the Software Craftsmanship mailing list where they were discussing whether software is a craft. Someone brought up the concept of what makes a “Master Craftsman” in software and I started thinking about how to determine if someone is an expert or master.

There are a few concepts out there including these:

• Someone who has read at least 3 books on a subject.
• Someone who knows more about a subject than someone else.
• Someone who has published something on a topic.
• As discussed in Pragmatic Thinking and Learning: Refactor Your Wetware (Pragmatic Programmers)
  (affiliate link)

Here are my thoughts on the subject.

Download this Episode

This week’s podcast guest is Evan Light. I met Evan at the Ruby|Web Conference at Snowbird. He’s responsible for Coulda and the Ruby DCamp.

Evan recommended Get Clients Now!(TM): A 28-Day Marketing Program for Professionals, Consultants, and Coaches (affiliate link) for marketing as a freelancer.

We talked about organizing a conference and what it takes.

He also had some great suggestions for people thinking about switching to freelance.

I also found his discussion of why he wrote Coulda very interesting. It inspires me to think that if I want something different, I can create it.

If you’re looking for a way to increase readability of your code, look at flog or metric_fu.

Jake Scruggs’ talk at Lone Star Ruby Conference 2008

Next month I’ll be teaching a Basic Ruby on Rails course. Go check it out and sign up.

Download this Episode

Michael Hartl put together a free rails tutorial online. We met at RubyConf and determined to talk about his tutorials. His path into Rails development has been interesting to listen to. Similarly, his thoughts on business are inspiring.

We talked about a great way to support Teach Me To Code. And that is by purchasing his videos and book here.

I don’t usually promote products, but I think this one is a terrific one and I hate asking for money in return for nothing, so in this case you get some great videos and a book!

Download this episode

So, between family stuff, more work than I can realistically handle, and being sick, I’m afraid I fell behind on the podcast. However, not to worry, I have big plans for 2011 including dedicating a full day to getting all of the podcasts, screencasts, blog posts, and other stuff out the door and into your hands. So, if you’re looking for details or an explanation, then listen to this episode.

Download this Episode

Go checkout our sponsors New Relic and Chargify.

Feel free to leave feedback at (801)753-8279 or chuck@teachmetocode. You can also reach me on twitter at http://twitter.com/cmaxw.

Our guest this week is Dave Hoover. He’s a member of the Software Craftsmanship movement. He’s the Chief Craftsman at Obtiva. He’s also written Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman The most exciting part, was learning about apprenticeship from the guy who wrote the book.

Dave got started by reading Software Craftsmanship: The New Imperative.

He also mentioned a few people that he considered masters:

• Fred George
• Uncle Bob Martin
• Corey Haines

There’s some great advice on figure out where you are and determining where you can get to and how.

There are a lot of opinions about what makes code readable. This was a short discussion of a few of them. I also recommend checking out these links.

What is Code Readability?
How to write readable code? 5 Tips to improve your code readability.
Stack Overflow discussion on Implementing Readable Code

Download this Episode

Andy Hunt is the author or co-author of several programming books including:

• The Pragmatic Programmer
• Programming Ruby (the Pickaxe book)
• Pragmatic Unit testing in C# with Nunit
• Practices of an Agile Developer
• Pragmatic Thinking and Learning: Refactor Your Wetware

He’s also one of the original signatories of the Agile Manifesto.

Andy is a great person to talk about regarding Agile Development. Here are some things he says you need to become agile and where to start:

• Do a little of the right things all the time
• You’ll be the expert on the project at the end of the project. Defer important decisions until you understand the problem.
• Stand up meetings
• Set ground rules
• Make sure you have a stable build environment and version control
• Unit Tests
• Continuous Integration
• Code Reviews/Pair Programming – Check the code
• Involve the Customer
• Produce something every 1-4 weeks
• Retrospectives – Get Feedback

Download this Episode

Thank you guys so much for helping me make it to RubyConf this year. It was a great experience. I was exposed to a lot of new technologies that I’m anxious to help you figure out. I’d heard about some of these, but here is a list of some of them:

• mustache.js
• gdb
• memprof
• Ruby 1.9.2 and Ruby 2.0
• Rite (Ruby Lite) which was announced as an embedded systems version of Ruby
• Metric Fu Hotspots
• Citrus

I also ran into some familiar voices (from interviews) and new voices (that will be interviewed) including:

• David Heinemeier Hansson
• Yehuda Katz
• James Edward Gray II
• Wayne Seguin
• Michael Hartl
• Chad Fowler
• Dave Thomas

Finally, I’d like to thank the handful of people who came up to me and told me how much they enjoy the podcast and screencast. It’s great to talk to you guys. You inspire me to do better.

Download this Episode

Show notes are forthcoming.

Download this episode

In this podcast episode, I discuss writing unit tests vs integration tests and why you need both.

Here’s the link to Ben Mabey’s talk on Cucumber.

You can also find out more about Cucumber in the Screencasts and at cukes.info

Download this Episode

This week’s interview with Peter Cooper was terrific! He talked a lot about entrepreurship and social media.

A few sites that he has set up are:

• Ruby Inside
• Ruby Weekly
• Coder.io
• Rails Inside
• Ruby Flow

You can also find out more about him by going to peterc.org and twitter.com/peterc

Download this episode

I got an email from someone dealing with Legacy Code and decided to discuss some of the principles of working on Legacy Code.

I mentioned Working Effectively with Legacy Code(affiliate link) by Michael Feathers.

Download this Episode

Joe is one of the talented developers at Thoughtbot in Boston, MA.

Joe is a maintainer for the shoulda gem. Here’s a video on how to use shoulda.

Some of the gems we talked about are:

• Factory Girl
• Shoulda
• Suspenders
• Clearance
• Paperclip
• Rspec
• Trout
• Effigy

Thoughtbot is responsible for HopToad.

Joe also mentioned that Thoughtbot uses Pivotal Tracker and most developers use VIM. His VIM config files are here.

Here’s the article on Team Rotation.

Download this Episode

Here’s the link to the pledgie where you can help me get to RubyConf.

This week’s episode is an interview with Corey Haines. He’s pretty well known as the Software Journeyman and his coding tours where he traded time pairing on code for room and board.

You can keep up with him at http://coreyhaines.com.

You can also check out the following links for other things he’s doing:

• http://www.katacasts.com/
• http://www.coderetreat.com/

Here’s a link to the Software Craftsmanship Manifesto which is tied a lot to the discussion we had on Software Craftsmanship.

Corey mentioned the Structure and Interpretation of Computer Programs – 2nd Edition (MIT Electrical Engineering and Computer Science)
book, which is a mind-blowing set of instruction and exercises for computer programmers.

We also discussed pairing in relation to the code retreats. Corey mentioned the paper by Arlo Belshee called “Promiscuous Pairing and the Beginner’s Mind”

You can reach Corey on twitter as @coreyhaines and by email at coreyhaines@gmail.com

Finally, checkout the latest news on the XP Universe conference.

Download this Episode

Mike and I talked about Ruby Web Conf. It’s coming up fast, so go sign up. Remember to use the code TEACHME to get $30 off.

Here are some of the other topics we covered:

Mountain West Ruby Conf
RailsConf
The Semantic Web (Wikipedia)

The speakers and sessions from the conference we discussed can all be found under the sessions section of the Ruby Web Conf website.

Download this episode

Time management essentially breaks down into two parts: Eliminating Distractions and Planning.

Planning begins with estimating and ends with scheduling. Long term scheduling won’t help you stay on task as well as short term planning. One method for this is The Pomodoro Technique. You can get some software to help you do the pomodoro technique.

Eliminating distractions has more to do with what you’re doing than with what others are doing. Checking email, answering the phone, instant messaging, social media, and internet browsing can typically be postponed.

There are some great tips in The 4-Hour Workweek

I also recommend that you try working from home or from a cafe near your office. It gets you away from the people who need your help, but can really wait, without completely isolating yourself.

Finally, keep track of what you spend your time on with Rescue Time.

Download this Episode

Estimating your workload can be tricky, but most management, marketing, and sales departments want to know when new features or bug fixes will be out so they can project where what they’ll be able to sell in the future.

You can estimate on the following scales:

• T-shirt sizes
• Fibonacci Numbers
• Algorithmic/Exponential scale
• Linear scale

You can estimate in several units of measurement as well:

• Points (Complexity)
• Hours
• Days
• T-shirt sizes

Overall, estimation can help you inform timelines, identify problems in features or your development cycle, and open discussion on tough features.

Download this Episode

Ron Stephens has been programming python as a hobbyist for the last 10 years. He’s a technologist, hobbyist, poet, and manager at a firm that makes hardware for satellites. He is the host of the python411 podcast and the awaretek podcast. He has tried many different languages including Perl, Ruby, Java, and Python.

During his exploration of programming languages, he has read and recommends:

• The Pickaxe Book – Programming Ruby: The Pragmatic Programmers’ Guide, Second Edition
• The Camel Book – Programming Perl (3rd Edition)
• A book called something like ‘Hacker Revolutionaries.’ I can’t find it. Could someone give a link if you know where to get it?

When asked about what philosophies, approaches, and principles python developers adhere to he mentioned the Zen of Python.

We discussed podcasting and education. If you’re looking for Grammar Girl, click here.

If you want some python tutorials, check out Ron’s Tutorial page.

For new developers, Ron recommends:

• Show-me-do
• Python news group

For advanced developers, Ron recommends:

• Reading Python Books
• IBM DeveloperWorks
• David Beasley

Download this Episode

Agile Retrospectives are a great way to keep your agile methodology on track. There are a lot of ways to do retrospectives. I go over my recent experience with retrospectives and discuss some of the things we did right and what I have learned over the last few weeks while researching this topic.

Download this Episode

This podcast is sponsored by New Relic.

Geoffrey Grosenbach well known for his screencasts at Peepcode.com as well as the Ruby on Rails podcast and Nuby on Rails.

He’s also doing some interesting things at blog.peepcode.com. Primarily, he’s writing articles that each have their own themes. Go check it out!

Geoffrey mentions that he’ll be speaking at SchnitzelConf in Vienna, Austria. It’s a conference about and for entrepreneurs.

It turns out the Geoffrey also created the Gruff library. Geoffrey now does his graphs with Raphael.

I also brought up http://roughunderbelly.com which is a task manager. It’s pretty simple and was an experiment with AJAX and RJS.

Resources that Geoffrey mentioned for developers are:

• Peepcode Screencasts
• TeachMeToCode Screencasts
• John Nunemaker’s Blog
• Peter Cooper’s Coder.io
• the Rails Documentation

Download this Episode

I’ve been thinking about the podcast and realized that I haven’t told my story. So, I’m going to talk about how I got into programming and technology. It’s a story that started early in my life and leads through my college years and into my career.

I love programming and helping people and I would love to have more time to do that, but that means that I need to build a business that lets me do that. I’m not begging for money. But I would like your input.

BTW- Sorry for the scraping noise. I didn’t realize my mic was picking up my mouse scraping across the table.

Download this Episode

Eric has his own company at elucidsoft.com. He’s a freelancer and is developing a new product called Agile Dash.

Eric is bootstrapping his company. Some of his inspiration comes from Peldi from Balsamiq Mockups and Joel Spolsky.

Eric does his prospecting through LinkedIn, Facebook, and Twitter for his freelance business.

Here are some books recommended in this episode (affiliate links):

On Business:

• Rework
• Freakonomics: A Rogue Economist Explores the Hidden Side of Everything (P.S.)
• Influence: The Psychology of Persuasion (Collins Business Essentials)
• Crossing the Chasm
• Anything by Guy Kawasaki
• Don’t Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition

On Programming:

• Code Complete: A Practical Handbook of Software Construction
• Working Effectively with Legacy Code
• Design Patterns: Elements of Reusable Object-Oriented Software

Download this Episode

This is a discussion of the practice of Continuous Integration or Continuous Builds. Continuous Integration is a very important part of insuring that your code is of the highest quality. It runs tasks against your code that provide you information like whether your tests pass or your code compiles.

The services I’ve used to do this are:

• Hudson
• CruiseControl.rb

You can use Continuous Integration to do the following:

• Catch failing tests
• Run and compare metrics
• Verify your development process
• Trigger deployments

Things mentioned in this podcast with links:

• Hudson
• CruiseControl.rb
• Kevin Rutherford Interview
• Metric Fu and Screencast Tutorial
• Pragmatic Programmer book

Download this Episode

This was a fun interview with Bryan Liles. Bryan is a very expressive guy. He’s noted in the Ruby on Rails community for TATFT (Test all the f*ing time) and his blog at smartic.us.

In this discussion, we talk about TDD (Test Driven Design), TATFT, Lifehacking, leaving the mouse behind, and opinions on software.

Some things mentioned in the podcast:

• Unicorn
• Cucumber
• Shoulda
• RSpec
• Test Unit
• Wirble
• Hirb
• VimCasts

You can check out his blog and follow him on twitter.

Download this episode

This year’s Agile Roots conference is focused on building great software. They have a terrific line up of speakers and it only costs $250, which makes it a great deal! The conference this year focuses on the development process and how it formulates requirements that lead to great software. Not just great software to maintain and build. But also great software that provides value to users.

Andrew explained that we, as developers, need to realize that we’re enabling a business experiment, not just building code.

He also went into the value we receive from open source software. The problem some of these people have is collecting the value of their work. You don’t get paid for being smart. Rather, we need to find ways to receive value from what we’re providing, even if it’s not designed specifically to make us money.

Pat Maddox wrote a blog post called “Are you punching your users in the face?” It was designed to help people to understand was that the value of the code isn’t in the tests or the code itself. Its value is in building software that users want to use.

We got a great recommendation to read “A Big Ball of Mud”. The author asked “What do you call someone who writes code like this?” after talking about every antipattern and code nastiness and he said “millionaires.” Historically this is true. Someone solved someone else’s problem with ugly hacky code, and walked away with millions of dollars.

We tend to discount sales and marketing personnel, when they are the ones that make your money. They build the brand and they bring the money in, even if you don’t have the best products.

Tim O’Reilly said, “Create more value than you capture.” If you do this your users will love you and your community will grow and support you.

We go into the idea economy and how agile ties into the idea economy. People are trying to sell each other on their ideas in agile as much as anything else.

Andrew was first introduced to Agile he found most of the practices as wasteful, painful, and wrong. So, he started discovering the roots of Agile. What he found was that Agile was bout solving our problems with our strengths. Once he started going to the Agile Round Table, he found that it was actually about delivering working software.

Over the last year and a half, Andrew has been working on taking agile into other areas of work.

The term ‘agile’ has become overloaded. Some people say agile, what most people mean is a watered down half implemented version of scrum.

Agile, the word, has crossed the chasm. The practices haven’t.

Trying to agile isn’t what you should do. You should be trying to be awesome.

Listen to the interview for some great tips on being awesome.

Here are some links to following Andrew:

Twitter: littleidea

Blog: http://stochasticresonance.wordpress.com/

Download this Episode

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

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

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

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

Dave Thomas is one of the founders of the Pragmatic Programmers. He is a signatory of the Agile Manifesto. He’s written several books, including: The Pragmatic Programmer, Programming Ruby (The Pickaxe Book), and Agile Web Development with Rails

This discussion covered a wide variety of topics, including how he picked up Ruby, learning new languages, and building businesses.

I think one of my favorite parts were his description of how he came to write his books Programming Ruby and the Pragmatic Programmer. For me it was valuable to get that type of view into some of the early documentation on my primary programming language.

I also appreciated his insight into building code better, rather than building better code. He offered insight into code that is appropriate to the task that is being built. He offered the following questions as qualifying whether you’re building code better:

• Does it do what the customer wanted?
• Can it continue to provide value so in the future?

This sort of purpose driven development is really the whole point of what we do as programmers. Thank you Dave for pointing out that the important thing is keeping the practices that allow us to adapt to changes in the ecosystem our applications run in.

Dave also shared with us that talent in programming is important. Like musicians, you need talent to be able to perform. You can only get so far pushing your way through programming. Can you think about things as explicitly as a computer?

More importantly, rather than the introverted programmer who doesn’t communicate, a good programmer has the ability to translate the customer’s requirements into computer instructions. You need the ability to communicate clearly and represent the computer and its capabilities to the customer.

One of the most important things you can do is find a good set of mentors. Someone who can teach you what you’re doing right and what you’re doing wrong. Dave shared a terrific example where he said the right thing in the wrong way and explained how his mentor approached him and what to look for in a great mentor.

Here is what Dave recommends in looking for a mentor:

• Spend some time getting to know them.
• Look for people around you.
• Look at what they do, since you’ll be modeling yourself after them.
• Ask them to be your mentor. If they’re not willing, they’re not a good mentor.

Oddly enough, the person I approached after this podcast is also named Dave.

If you want to know where the Pragmatic Programmer came from, Dave tells us toward the end of this episode. We pick up the discussion next week talking about his businesses and entrepreneurship.

Download this Episode

Here are some affiliate links to Amazon for Dave’s Books:

The DRY principle is a guiding principle behind frameworks like Ruby on Rails. It’s basic tenet as provided by the Pragmatic Programmers is:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

This basically means that between your database schema, code, architecture, etc. you should only have one representation of each piece of knowledge that applies to your system.

This goes far beyond your basic avoidance of Copy/Paste Programming. Your code does not have to be identical to be duplicate. For example, you may have code that tells you how to build an address. This may use as business name, address fields, city, state, and zip. You may also have code that builds an address for a user, using the user’s name, address fields, city, state, and zip. This is a simple example that shows code duplication.

But what about mathematical algorithms. Or, an example that I just worked through at work, we’re using flash and HTML authentication. Both systems need to be able to authenticate. So, how do we consolidate our code so that authentication knowledge is only managed in one place?

I’ve also seen instances where duplicate code is hard to generalize to match all cases. In those circumstances, I ask myself the following questions.

• Do all of these processes need to be maintained for consistency? Or in other words, if I change class A’s behavior, do I need to change class B’s behavior?
• Is this the same process in both cases regardless of dependencies?
• Is there a case where one process will need to be modified to significantly deviate from the other?
• Am I creating more work by combining these processes than I would by simply maintaining them as they are?

I’m fully aware of that after making my decision, I may not get back to modifying this code, so I have to make the best decision I can. The main concern I have is maintainability.

If I can maintain things in one place, for example building code generation off of a configuration file that fans out to multiple parts of the system, keeping the implementation details in the config file. (Think about a SOAP WSDL file.) Or if I can build a configuration off of some code implementation. Or I can generate some documentation from the code. I can avoid circumstances where I can break my code in one place by changing it in another.

That’s the true power of the DRY principle.

Download this Episode

This is take II of the Pair Programming episode. The first take wasn’t what I wanted to communicate about pair programming. Please give it a listen and check out the show notes on the original recording.

Download this Episode

This week’s episode on pair programming discusses where you might see pair programming, HashRocket’s pairing setup, perceived and real disadvantages to pair programming, its advantages, and what it takes to do good pairing.

Pair programming is usually associated with Extreme Programming. It is sometimes seen as a mentoring practice, but is actually a collaboration practice, not a mentoring practice. This is because both programmers participate equally, not one leading and the other following for long durations. Pair programming is done with 1 computer and 2 programmers. I’ve never seen it work well with 2 computers and 2 programmers unless one computer was being ignored or under-utilized.

Obie Fernandez shared HashRocket’s pairing setup and much more on his blog. The setup is not cheap. It’s envied by many a programmer.

Some of the disadvantages of pair programming (some of which are only perceived disadvantages) are:

• It ties up two programmers. It would appear that you’re wasting at least one person’s time. They programmer not actually programming. The problem with that statement is… which one isn’t programming? They both are. They’re both doing the same job. And in the end, I’ve experienced about 1 and a half times the work done in a pair as I or the other programmer could get done on their own.
• So, doesn’t it cost more if two of you only accomplish 1.5x the work? Maybe. The quality of the code produced by pair programming is decidedly higher. This doesn’t mean that pairs can’t produce bad code, but it usually reduces the chances, which leads to higher productivity later on due to mistakes that were not made. Does this account for the other half of one person’s work? Like I said, maybe.
• It’s inconvenient and reduces flexibility. Sometimes it is inconvenient. I really enjoy working on something until it’s completed. If I have to switch pairs and tasks, it really bugs me that the other task wasn’t finished first. You also have fewer pairs than people, which means fewer tasks being worked on at the same time.

The advantages are:

• Flexibility: If you pair on everything, then you can contribute to anything. This is a huge advantage. My friend and co-worker measures this depth of expertise in buses. “If I get hit by a bus, we lose all of our expertise in X.” Pairing and sharing increases your bus-depth. (I still haven’t been able to pair with him.)
• Code Ownership: If you worked on each piece of the application, then you bear some responsibility when it breaks. If you spread this across the team, problems get solved very quickly.
• Collaboration Nothing builds team unity like solving problems together. You also get the benefit of gaining your co-workers’ expertise when you code with them.

Here are a few things that are critical to good pairing:

• Communication: How many times did Chad Fowler mention communication? If you can’t communicate well your intentions either verbally or through code, then you have one guy coding and another watching. This is where you validate at least one of the disadvantages to pair programming.
• Ability to work together If you can’t stand the guy, or stand to sit next to the guy, you can’t pair with him. His odor or personality will overwhelm your ability to communicate and concentrate effectively.
• Skill Level The company I work for has a strong mentality for “We don’t hire idiots.” Weeding out the idiots or not hiring under-qualified people really makes the team stronger and pairing easier because you don’t have to spend time explaining, you can spend it working.
• Setup Read Obie’s article. He really summed it up best. It’s hard to work where it’s hard to collaborate.

Download this Episode

In this episode, Chad discusses how he broke out of a comfortable job as a forklift operator, which ultimately led to him becoming a programmer.

He discusses his job, Ruby Central, and the Pragmatic Studio as contributions he makes to the community.

We also discuss the ebb and flow of passion for programming and how to avoid burnout on the things that we love. He has actually put a ban on himself for travel so he can spend time on the things that are important.

Chad told me that he espouses the Test Driven Development mindset, Continuous Integration, and Agile or dynamic methodologies. We discuss task automation, Puppet, Chef, etc.

The important things in software development boil down to quality. If you can automate your common, important tasks and make it easy for the person who needs it to kick off the process on their own.

Chad also had some great suggestions for new developers. First, read code. Second, write tests for the areas of code that don’t have tests. This will force you to refactor the code and make it better.

To get involved in the community, you can start or organize a conference, create open source projects, help software maintainers meet Ruby 1.9 compatibility issues, join a mailing list, and so much more…

Download this Episode

This week I interviewed Chad Fowler. He and several others have helped organize Ruby conferences around the world, most notably RailsConf, RubyConf, and RubyConf India. He has also written The Passionate Programmer and Rails Recipes. Finally, he has contributed to open source projects like RubyGems and Facebooker.

You can follow Chad at his website or on twitter.

Chad is an organizer at Ruby Central which is a non-profit which provides support to the Ruby community. Among other things, they provide a Regional Conference Grant which local conferences like Mountain West RubyConf can take advantage of.

He told me a bit about his inspiration for writing The Passionate Programmer and his experience working in India. The Passionate Programmer is about fulfillment in programming and work. It lays out a methodology for managing your career.

We discuss the paths that a career can take and things that people should consider as they move through their career.

One example he gives is from the book What I Talk About When I Talk About Running. He talks about what we do when we have to do it to succeed, versus what we do when “success” comes naturally.

Overall, there was a lot of great information in the interview. I’d like to thank Chad for coming onto the show and for all of his hard work in the Ruby and Rails communities.

Download this Episode

Test Driven Development and Behavior Driven Development can be terrific tools in defining your code and ensuring the highest quailty software. In this episode, we discuss the differences between TDD and BDD and what the advantages are to doing them.

We also talk about these test tools:

• Rspec
• Cucumber

Download this Episode

Download this Episode

In this episode, we discuss why your application needs tests. Here’s a summary of the thoughts given in this episode:

Why you should test:

1. You know your code works the way you expect.
2. You guarantee that later changes to your code don’t break existing functionality.
3. It documents your code.

Testing should be done by developers as well as Q. A.

A lot of Q.A. personnel are not developers. They don’t read code, they don’t write code, and they can’t test the code. Q.A. folks usually test the application’s behavior. Developers usually test the code functionality. Both levels of tests are required to provide the highest quality of code.

What do you test?

Tests are written to test two things. Behavior and data.

The behavior you’re usually testing is whether or not your code deleted, updated, changed, or saved information. Did it display what it was supposed to? Given certain inputs or settings, does it do something different.

Data is more centered around whether or not it returned specific expected values. This is tied to behavior, but has more to do with information correctness, than with how it is presented or where the application moved on to.

Here’s the link to my blog post about TDD.

Please remember to take the survey and write a review in iTunes

In order to contribute as an employee or a freelance developer, we need to understand the nature of business. Specifically, we need to understand the nature of how our employer or client makes money so we understand our contribution and so we recognize where our value is.

Once we understand the nature of business, we can look for other pain points people are facing and find ways to solve those problems. That’s how we get paid.

Here are some resources for starting your own online or otherwise business.

• Internet Business Mastery
• Coach Radio
• Past Due Radio
• 48 Days to the Work You Love
• The Digital Marketer
• Doctype
• Sales Guy
• Internet Marketing This Week
• Planet Money
• Money Girl
• NPR Technology Podcast
• PRI The World Technology Podcast
• Walt Mossberg’s Personal Technology Podcast

Here’s the cool stuff I get to do at work.

Download this Episode

This week’s episode is about work fulfillment. To start out, I provide context for my experience by briefly reviewing my work history. Then we go into the 6 things that I believe are critical to a great job. The 6 P’s that define a great job:

• Passion
• Purpose
• People
• Progress
• Project
• Pay

The companies mentioned as my previous employers:

• Brigham Young University
• Mozy
• Solutionstream
• PMA Media Group
• Public Engines Inc./CrimeReports.com

Resources mentioned in this episode:

• Intentional Excellence Podcast Episode 5: Work Fullfillment
• Internet Business Mastery
• 48 Days to the Work You Love Podcast
• Lukas Coaching

Download this Episode

In this interview with Pratik, we discuss several things, including:

• Cramp – A web framework in Ruby (the repo on github)
• Practicing coding – Write more code
• Reading other people’s code
• Rails Core
• 37Signals
• Freelancing
• Submitting patches to Ruby on Rails
• Rails 3 (the repo on github)
• Arel
• Learning to Program
• Adapting other people’s code
• Testing
• Best Practices (the Basics)
• Code Organization
• Shoulda
• Webrat

Download this Episode

Here is the link to my blog post about coding exercises.

Here’s a short list of the coding exercises that are out there.

• Project Euler
• My Project Euler Solutions
• Ruby Quiz
• Code Katas
• http://www.knowing.net/index.php/2006/06/16/15-exercises-to-know-a-programming-language-part-1/
• http://www.knowing.net/index.php/2006/06/16/15-exercises-to-know-a-programming-language-part-2-data-structures/
• http://www.knowing.net/index.php/2006/06/16/15-exercises-to-know-a-programming-language-part-3-libraries-frameworks-and-mashups/
• http://programmingpraxis.com/
• http://codingkata.org

Here’s an awesome example of a code kata: http://charlesmaxwood.com/8-lessons-from-corey-haines-performance-kata/

Programming exercises are terrific with a mentor. Check out the episode on mentors.

Download this Episode

Download this episode

Subscribe in iTunes

Remember to leave feedback by calling 801-753-8279 or emailing podcast@railscoach.com.

Conferences are a great way to learn and meet people.

The conferences I’ve attended:

• Mountain West RubyConf
• RubyConf
• RailsConf

Tips for getting the most out of conferences:

• Put away your distractions.
• Sit next to and meet people you don’t know.
• Take the opportunity to meet with the “greats” in your community.
• Talk to people between sessions and find out what they’re working on.
• Find open source projects to contribute to.
• Submit a proposal to speak.
• Ask people what worked and what didn’t work for them to avoid the same problems.
• Take advantage of the conference energy to get things done.
• Collaborate or program with other developers.
• Talk to the speakers who cover a topic that interests you.
• Go to the meetups or Birds of a Feather meetings.
• Find community movements occuring outside the conference.
• Review the basics.
• Find a job or increase marketability.

Conferences in the Ruby and Rails Community

• RailsConf
• RubyConf
• MountainWest RubyConf
• acts_as_conference
• Lone Star Ruby Conf
• Ruby Hoedown
• Windy City Rails
• GoGaRuCo
• Aloha on Rails

Download this Episode

During the interview with James, we talked about several things. You can find him on twitter at http://twitter.com/JEG2

James ran the RubyQuiz for 3 years and wrote Best of Ruby Quiz Volume One (Pragmatic Programmers) and Textmate: Power Editing for the Mac (Pragmatic Programmers).

Mountain West RubyConf

James’ talk at Mountain West RubyConf 2009 is available at ConFreaks

Scout

Pomodoro Technique

Pomodoro Technique Illustrated: Can You Focus – Really Focus – for 25 Minutes? (Pragmatic Life) (the book)

Tokyo Cabinet

NoSQL

Perl Quiz of the Week

Code Katas

Project Euler

Ruby Talk List

FasterCSV

Mastering Regular Expressions (the book)

Ruby 1.9

Perl Beginners

Perl Monks

Lonestar Ruby Conference

James’ Blog

Things James said to look up:

• Hash#fetch
• Hash#Array
• Regular Expressions

Also, I just added the podcast to Podcast Alley. Here’s a link to My Podcast Alley feed! {pca-0b125abf61f52ffc632391fdcb8adbb5}

NOTE: All links to books are affiliate links for which I will be compensated.

Download this Episode

This week I talked to Ben Johnson, who built the authlogic and memorylogic (among many other) libraries for the Ruby and Rails communities. He talked to me about the side business he’s running, what he looks for in developers who come work for him, and about being a passionate programmer.

If you want to keep up with him and what he’s doing, you can check out his blog or his github profile. He also said that he’ll be at RailsConf this year in Baltimore.

Download this episode

One of the things that has helped me the most in learning to program well is having a good mentor. I didn’t necessarily choose mine, but I’ve had some excellent mentors. Here’s what made them great for me.

1. They had been where I was at.
2. They were at where I wanted to be.

What they did that was so powerful.

1. They explained topics and details when I needed to apply them.
2. They didn’t solve my problems for me.
3. They encouraged me to explore the areas I needed to learn about.
4. They provided structure for the environment I was learning in.
5. They provided an example of where I wanted to be.

Where do we find them?

• Users’ Groups
• Work
• Online Communities
• IRC
• Forums
• Blogs
• We find their code
• We contribute to their code
• We use their code
• Conferences

Download this episode

This episode is my interview with Gregg Pollack. We had a great discussion about podcasting and podcast styles, users’ groups, what makes a good developer, Envy Labs, and a whole lot more. Here are links to several of the things we discuss.

Rails Envy Podcast

Viral Videos

Orlando Ruby Users Group

Envy Labs

Ruby5

My post about Ruby5 and Rails Envy

Dave Thomas’ Code Katas

RubyQuiz

Utah Ruby Users Group

Railsbridge

Rails Activists

RailsCasts

Yehuda’s Aloha on Rails talk

Yehuda’s Mountain West Ruby Conf talk

Ruby Heroes

Scaling Rails Screencast

Rails Github Repository

Music: Midnight Composition by Al Phlipp and The Woo Team