-
20
JUL
2014Dave's No Tests Challenge
I've mentioned before my difficulties in the 2014 IPSC. But taking one beating is no reason not to try again. The first loss just showed me that the contest still had more to teach me.
A buddy of mine has spent some time with the crossword problem and told me that he enjoyed it. I didn't try this problem during the actual event, but I was a little familiar with it from my friend's description.
To add to the fun, I decided this would be a great excuse to take up the recent challenge Dave Thomas gave to the Ruby Rogues: "Stop writing tests."
Step 1: Feedback Loops
Without tests to guide me, I really want to see what's going on. One of the biggest advantages of tests, in my opinion, is the feedback loop it provides. So I set out to provide my own feedback.
Since the problem at hand involves filling in a crossword board, the easiest feedback loop I could think of was to see the board as it fills in. The final board is also the required output. Therefor, I decided a good first step would just be to read the board into some data structure and write it back out. Once I had that, I could insert code between those steps to fill it in. And constantly seeing the board evolve would let me eyeball things for obvious mistakes.
-
10
JUL
2014One Programmer's Library
I have always enjoyed the posts where people list out all of the books they think are important, given some subject. They vary wildly. For example, some are very to-the-point while others are rich in detail (and Danielle makes one of those each year).
I began to wonder what my list would look like. Below I've tried to make those decisions. I was surprised by just how hard it is to restrict myself to the bare essentials. A lot of things that I read influence me in some way.
The Classics
I'll start with the super obvious titles you've likely heard mentioned before.
- Refactoring: Improving the Design of Existing Code is probably the classically great programming text that had the biggest effect on me. This book teaches you how to turn the code you have into the code you want. It doesn't get much more essential than that.
- Smalltalk Best Practice Patterns is the book I learned a new language just to read. It's worth that. This is The Field Manual of Object-Oriented Tactics and it helps you know what to do line-by-line.
- Patterns of Enterprise Application Architecture is the book you should read so you can see how much great knowledge we've had about building programs for over a decade. Odds are that this book can teach you multiple strategies for problems you face regularly.
- The Pragmatic Programmer: From Journeyman to Master is one of those rare books that can make you a better person, in addition to a better programmer. Advice like "Fix Broken Windows" and "Make Stone Soup" have universal scope. This is a must read.
- Programming Pearls (2nd Edition) is a book about algorithms and, eventually, all programmers need to learn some algorithms. The upside of this title is that it's fun from page one. That helps to keep you interested in what can be a dry topic.
- Growing Object-Oriented Software, Guided by Tests is almost surely the single biggest influence on how I do Test-Driven Development. There are other schools of thought but pick one and dig deep enough into TDD until you're confident about when and how to use it. This is a tool everyone needs in their toolbox.
-
26
JUN
2014IPSC 2014 Postmortem
I decided to give the Internet Problem Solving Contest (IPSC) a go this year, with a couple of friends. I've done it in the past and enjoyed it. I like how it only eats a few hours one day and I like how the variety in the problems they give you keeps things interesting.
That said, my performance in the IPSC this year is probably best described as, "Three strikes and you're out!" I did terrible.
I solved one very simple problem. I spent the rest of the contest chasing after a much harder challenge that I couldn't complete in the time allowed.
The worst part is that I made some silly mistakes that I've learned to avoid in the past. As penance, I offer up this article, mainly as a reminder to myself, but hopefully also as a tool that could save others from some of my folly.
Let's start with a simple mistake I made…
Not All Problems are Programming Problems
The IPSC does a great job each year of reminding us that some problems are trivial to solve without programming. It's a good thing they do too, because I seem to need a lot of reminding.
-
17
MAY
2014A Library in One Day
I was super inspired by Darius Kazemi's recent blog post on small projects, so I've been looking for ways to speed up my process.
Today, I tried an experiment: develop a library in one day. I wanted to go from an empty repository to a published gem that I could start using.
Topic
Obviously, I had to select a pretty simple idea to use. I wouldn't have time to do a huge project.
I think this may be the killer feature of this technique.
On one hand, you could argue that what I built may not be very library worthy. It's around 50 lines of code. It has ten specs and they really cover what it does. This isn't a complex beast and you could pretty easily hand roll a solution to replace it.
But in some ways that's the best part. I've dropped a 50 line pattern that I like down to a one line
Gemfileinclude. I'm making it even easier for myself to get some mileage out of experimenting with this code. I can mix and match this new library with other small tools to build up the ecosystem that I want for a project. Plus, if it turns out to be something I regret, it's not like I'm tied down to a huge dependency when I go to rip it out. This thinking actually has me wanting to keep this library minimal, at least for now. -
11
MAR
2012When Passion Goes Wrong
I usually stick to pretty code heavy topics in these articles, but please allow me to take a detour this time. Our industry struggles with a problem that we don't discuss enough and I want to give it some air time.
The fact is, we're pretty lousy at controlling stress.
Let's look at why that is and some of the ways this problem manifests. Remember, the first step is admitting that we have a problem.
We are a Passionate People
I really believe good programmers are passionate about what we do. Our job can be pretty mentally taxing and, if you don't love it, it would be pretty rough to endure that day in and day out.
Because of that, we generally find that the programmers who survive the climb are passionate folks. Really think about that for a minute. I'll give some examples.
Kent Beck is a name I bet most of us know. One of his great successes was actually writing a book of guidelines for how individual lines of code should be structured. He had to care about the individual lines. That's how far he had to go to manage his programming. He's also done a ton for testing, for similar reasons.
-
8
FEB
2009Pragmatic Thinking & Learning
I have a new standard by which all future reading material will measured. Any book that casually mentions lock picking and follows it up with a footnote reference to further reading that will improve your lock picking skills when restricted to an improvised toolset is an instant hit. Pragmatic Thinking & Learning does exactly that. While that description may be a bit of hyperbole (I had to look that word up Andy), the book really does deliver, both on the lock picking references and the great content.
If I had to sum up Pragmatic Thinking & Learning in one sentence it would be: it's a book about how to start thinking about thinking, with a moderate computer programmer slant. If that sounds a bit general, well, it is. A construction worker or anyone else could learn new things that would help them in their jobs and just day to day lives from this book. I know I would love for my teenage foreign exchange student to read it, because she could learn a lot from it. I'm pretty sure this book does exist in many other forms targeted at different groups of people. The advantage of this one is that I get the jokes and metaphors. Hooray for geek humor!
-
7
NOV
2006Doing It All!
I'm not really in the habit of putting non-code content on this blog, but more than one person asked me the same question at RubyConf. If people really want to know, I'll try to answer. Paraphrasing, the question was:
How do you keep up with so many Ruby projects?
First, this question surprised me. Do I really do that much? If you just said yes to that, I would like to introduce you to Ryan Davis. He easily doubles my output and his projects are wicked complex compared to mine.
That doesn't answer the question though.
In short, I do as much as I possibly can with the time I have. The truth is that I would like to do a lot more. I turn down at least as many damn cool Ruby projects as I accept because I'm a wimp and not willing to give up my sleep. There are so many crazy cool Ruby projects out there that I would love to be a part of. There just aren't enough hours in the day.
I guess I still didn't answer the question.
The question was "How…" and the answer to that is actually trivial. Masayoshi Takahashi summed it up with a single slide in his presentation at RubyConf:
