Teach Me To Code: Recent Episodes
Devchat.tv
[powerpress]
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 Programmerbook
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.
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.
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
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.
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.
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.
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.
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.
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)
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.
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 CraftsmanThe 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
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
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
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
Writing Code is the Easy Part is the new slogan for the website. It basically boils down to the fact that putting up syntacticly correct code is the simplest part of coding. More difficult is solving problems and all of the other things that come with having a job or working for clients.
Here are some of the things that I listed as the harder parts of coding:
- Legacy Code
- Readability
- Testability
- Best Practices
- Writing Tests
- Team Dynamics
- Customer Communication
- Translating Behavior into Code
- Data Integrity
- Security
- Maintainability
- Systems Integration
- Server Technologies
- Databases
- Finding a Job
- Hiring and Firing
- Working on Boring stuff
- Job Fulfillment
Here are affiliate links to some of the books that I mentioned:
- Refactoring: Improving the Design of Existing Code
- Design Patterns: Elements of Reusable Object-Oriented Software
- Code Complete: A Practical Handbook of Software Construction
- The Pragmatic Programmer: From Journeyman to Master
- The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life)
Here are the links to the podcast episodes by:
- Chad Fowler (Part 1, Part 2)
- Dave Thomas (Part 1, Part 2)
Finally, I would really appreciate a $5 donation to help me get to RubyConf.
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.
- Write the test
- Write the code
- Refactor the code
- 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 Improvementas 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
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.
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