Gray Soft

The programming blog of James Edward Gray II (JEG2).
  • 11

    MAR
    2012

    When 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.

    Read more…

  • 1

    MAR
    2012

    The Right Ruby Mix

    Ruby is a melting pot language. It borrows ideas from many things that came before. It combines several different programming philosophies.

    This aspect of the language can be a plus. It means that Ruby is suited to multiple applications. It also opens up some pragmatic shortcuts. Even better, it sometimes encourages us to think about problems using a different lens of thought.

    Of course, this cuts both ways. Ruby living at the intersection of many ideas does have some downsides. First, there's more to learn than you find with some simpler languages. There's a cost for the extra knowledge we have to track. Even worse though, in my opinion, is that it's sometimes hard to know exactly what Ruby's style really is.

    Going Off Script

    One culture Ruby borrowed heavily from is that of the so called "Scripting Languages." The main source of these features was Perl, in my opinion, but you can also find influences from Bash and other sources. I found this comforting since I came to Ruby from Perl, but the truth is that it bothers some people.

    Read more…

  • 22

    FEB
    2012

    Refactoring: The Gilded Rose

    It's time for another refactoring challenge. This time we will attempt a fun problem called The Gilded Rose Code Kata.

    That original description of the problem was for C# developers and it didn't have things us Rubyists love, like tests. Luckily for us though, Jim Weirich ported the code to Ruby and added the tests as he did so. Let's use that version of the challenge.

    As always, I recommend you try the refactoring before you read what I have to say about it. Being familiar with the problem will help you understand what we are dealing with below.

    Setup

    The first step in this problem is to get the code running locally. I started by pulling down Jim's code from GitHub:

    $ git clone https://github.com/jimweirich/gilded_rose_kata.git
    Cloning into gilded_rose_kata...
    remote: Counting objects: 114, done.
    remote: Compressing objects: 100% (46/46), done.
    remote: Total 114 (delta 71), reused 109 (delta 66)
    Receiving objects: 100% (114/114), 15.38 KiB | 13 KiB/s, done.
    Resolving deltas: 100% (71/71), done.
    $ cd gilded_rose_kata
    

    Read more…

  • 11

    FEB
    2012

    Test Driving an Algorithm (Part 2)

    In the last article, I built a quick and dirty solution to PuzzleNode's Hitting Rock Bottom puzzle. I didn't use specs, objects, or even multiple files. In this article, I'll repeat the exercise but using all of those elements. Let's see how that affects the results.

    The Disciplined Approach

    This time, I'll reign in my desire to push forward and solve the problem more carefully, without having to build a fully formed algorithm all at once.

    I still think the input is the right place to start. I need to read in the units. Let's add a spec for that in spec/parser_spec.rb:

    require "minitest/autorun"
    require "stringio"
    
    require "hitting_rock_bottom/parser"
    
    describe HittingRockBottom::Parser do
      let(:units)  { 42 }
      let(:io)     { StringIO.new(units.to_s) }
      let(:parser) { HittingRockBottom::Parser.new(io) }
    
      it "reads the units number from the beginning of the stream" do
        parser.units.must_equal(units)
      end
    end
    

    If you haven't seen the standard stringio library before, it simply wraps a String with an IO interface. That's will allow me to call gets() and other IO methods on it in my implementation. It's perfect for tests like this.

    Read more…

  • 1

    FEB
    2012

    Test Driving an Algorithm (Part 1)

    I want to take a look at some of the differences between Cowboy Coding and Test-Driven Development. To do that, let's solve a problem both ways and see what we can learn from the exercise.

    A Puzzle

    I needed some random problem to solve in this article and the PuzzleNode site is pretty handy for that. Two programmers I've been working with have recently experimented with problem number 11, Hitting Rock Bottom, so I am familiar with it. Let's use that.

    You will probably want to read through the challenge before finishing this article. You may even want to try solving it yourself, just so you'll be more familiar with what I am doing here. The short, short story is that this problem is about simulating the flow of water into a cave for a fixed amount of time and then measuring the depth at each point. It doesn't take too long to solve.

    Setup

    Let's setup a project. I created a few directories and pulled down the data files given with the problem:

    $ mkdir -p hitting_rock_bottom/{bin,data,lib,spec}
    $ cd hitting_rock_bottom/data/
    $ for f in simple_cave.txt simple_out.txt complex_cave.txt
    > do
    >   curl --silent -O \
    >   "http://puzzlenode.com/puzzles/11-hitting-rock-bottom/attachments/$f"
    > done
    $ cd ..
    

    Read more…

  • 21

    JAN
    2012

    Iteration Patterns

    I love studying how the human brain works. It's an amazing biological machine capable of impressive feats. Of course, it also has its quirks.

    For example, the brain is a terrific pattern matcher. That's probably one of its favorite activities. It wants to do this so much that it will often even find patterns that aren't there.

    While this "feature" of your brain can get you into trouble, you can also make it work for you. Some parts of programming really are about patterns. If you prime your brain with the right data, it will just take over and do one of the things it does best.

    How I Teach Iterators

    One evening, at a post Ruby conference dinner, Glenn Vanderburg and I had a lengthy discussion about iterators and patterns. During this discussion we nailed down a plan for how the iterators could be taught.

    I know that we've both used the strategy we came up with in multiple Ruby trainings and we have both seen it work wonders. This is hands down the best way to learn the iterators, in my opinion.

    Read more…

  • 13

    JAN
    2012

    Rubies in the Rough

    [Update: the Rubies in the Rough articles were originally available by subscription, but they are now free on this blog.]

    I know this blog has been quiet for quite some time now, but I'm still writing about Ruby. In fact, I'm very excited about a new series of articles I am producing called Rubies in the Rough.

    In that series, I am working hard not to teach the language or syntax or anything else that's trivial, but the thought processes behind how I program Ruby. I think this is some of the most important work I've ever done for Ruby. Anyone can learn a few keywords, but understanding how to think about problems and the solutions we code for them is key, in my opinion.

    This new series isn't free, but it is a steal. It works out to two bucks an article and I often write close to 20 printed pages. This is some serious content.

    If you want to learn how I think about programming, do yourself a favor and subscribe to Rubies in the Rough. It can teach you to see programming challenges as I see them and loan you my confidence as you solve them.

  • 11

    JAN
    2012

    Experimenting With DATA

    In the last article, I talked about the importance of a culture that encourages experimentation. It's hard to fiddle with something and not gain a better understanding of how it works. That knowledge is valuable to us programmers. I mentioned though that the way Perl programmers experiment is not the same way us Rubyists do it. Let me show you some actual Ruby experimentation I've witnessed over the years…

    Executing Your Email

    Some of Ruby's features are fairly obscure. Even worse, some of us who use those obscure features try to bend them to even stranger purposes. This is one way Rubyists like to experiment. Ironically, the features I'm going to talk about in this article are inherited from Perl.

    Ruby can literally use your email as an executable program. Assume I have the following saved in a file called email.txt:

    Dear Nuby:
    
    I just thought you would like to know what the Hello World program looks
    like in Ruby.  Here's the code:
    
    #!/usr/bin/env ruby -w
    
    puts "Hello world!"
    
    __END__
    
    I hope the simplicity of that inspires you to learn more.
    
    May Ruby Be With You,
    Ruby Jedi
    

    Read more…

  • 1

    JAN
    2012

    Perl's Golf Culture

    I'm stealing some time to write this while on vacation. I am also under the weather. Given that, we'll make this article short and easier on me to think up. That's not always a bad thing though. There are plenty of simple concepts I would like to get across. For example, let's talk about how Perl programmers do what it is they do.

    Ruby's Sister Language

    I spent plenty of time in the Perl camps and I really learned a lot about programming there. That may shock you to hear, because Perl programmers often get a bad wrap from the rest of the programming community.

    One reason they catch a lot flak is that their language is often terse to the point of obscurity. We joke that Perl is a "write only" language or too hard for other developers to read. That would be bad enough on its own, but Perl programmers seem to intentionally make this worse.

    Perl programmers love to play the programmer's version of golf. That is writing a program with the fewest possible keystrokes. To shrink their program's size, they will resort to every dirty trick in the book, including:

    Read more…

  • 21

    DEC
    2011

    Refactoring: rcat

    I use these Rubies in the Rough articles to teach how I think about code. Well, I have a scary admission to make: I didn't really understand refactoring until I was many years into being a programmer. Sure, I knew what it meant, but I just didn't get it. I hope to save you from the same mistake.

    Refactoring is important. Very important. It may be one of the most important things we do as programmers. If I learned one thing from reading Smalltalk Best Practice Patterns, it's that code's primary purpose is to communicate with the reader. Let's face it though, when we are trying to get something working, it's often like stumbling around in the dark. We are running into all kinds of things, breaking stuff, and just trying to reach that "Holy cow it works!" moment. We're probably not thinking too long and hard about how well this mess we are making communicates and that's perfectly fine.

    Refactoring is where you get to fix that. It's about taking working code and making it sexy. Note that I said it starts with working code. Until you have that, there's nothing worth communicating to a potential reader. Make it work, then make it sexy. (I believe that saying really involves speed, but that's a very different conversation we can have at a later date.)

    Read more…