I’ve been thinking about code reviews a lot lately.
My mom has often worked as an editor, and she once told me of the most difficult thing about being an editor (I paraphrase):
You have to let the writer keep his or her style. The challenge is to improve the writing without making it seem like you wrote it.
Working as a technical writer and as an English teacher, I thought about these things a lot. I would often think, “that is not a sentence that I would have written, but it is clear. It works.” Sometimes I would read a sentence and think, “I don’t know what that meant; that sentence doesn’t work.” I would change the sentence in the second situation but not the first. Continue reading “Throwing Darts at Code”
I’ve been thinking a lot about how and when I work recently. I missed a couple Wednesdays posting here, so I’ve been looking at ways to become more consistent.
I looked at two big resources here: MPJ‘s great video on timeboxing and The Power of Habit by Charles Duhigg. Continue reading “Habits and Timeboxes”
The other day, I had an idea for a simple website. I wanted to find an easier way to deploy side projects than I’ve used in the past. AWS gives me too fine a control over things I don’t care about, so I decided to try out Heroku. It was much easier than I thought it would be. Here is basically what I had to do to get a prototype on the public internet, admittedly at a subdomain of herokuapp.com. Making a Heroku account is the usual “sign up with an email and a password,” to I’m assuming you’ve done that step.
Continue reading “Heroku Is Fun”
Yesterday at work, a colleague had what I think is a common issue for developers: Code was behaving incorrectly, and he couldn’t see why. We’ve all been there; the trick is not hanging out. Today I’m going to talk about two great developers I follow online, Safia Abdalla and Eric Lippert, and what we can learn from them about not getting stuck in a debug issue. Continue reading “Shrink Your Search Space”
I’m always looking for side projects that are the right mix of feasible, fun, relevant to my career, and interesting. Recently I joined Excella’s Ruby Book Club, and started a side project that is just the right mix: A silly retro game in Ruby!
The game is built on the gem
gosu. Gosu does the actual C++ calls to deal with I/O and graphics, and gives you nice, pretty Ruby abstractions so you can draw rectangles and ask whether the spacebar is down. I’m having a blast so far.
Continue reading “Gosu and Special Cases”
When I started Ruby, I wanted to learn the language in some real depth. I asked a few coworkers, “What is the C# In Depth of Ruby?” Eventually, someone recommended Ruby Under a Microscope. This book helps me see through some Ruby magic and understand a little bit better. Scott Hanselman recently posted that some people learn from the metal up, wanting to understand CPUs and compilers, and some people learn from the glass back, making something the user can see, then tackling technical details as needed. I am definitely a metal-up learner, and Ruby Under a Microscope is definitely a metal-up book. There are almost as many code samples in Ruby bytecode as in Ruby.
Continue reading “Book Recommendation: Ruby Under a Microscope”
I’m in the middle of Ruby Under a Microscope by Pat Shaughnessy. I love the book so far, and I will certainly post a more specific review and recommendation soon, but I just noticed a real semantic difference between Ruby and C# that I wanted to blog about, because it would certainly have tripped me up if I had stumbled across it in production code. From Shaughnessy’s chapter on hash tables:
In the case of strings and arrays, Ruby actually iterates through all the characters in the string or the elements in the array and calculates a cumulative hash value (p. 183)
“That’s weird,” I thought, “I bet that means that it’s not safe to use arrays as hash table keys in Ruby. So I did an experiment:
Continue reading “Hashing Arrays in Ruby vs. C#”