Taking time to understand the problem

    This is more of a “developer diary” kind of post, but it’s the most poignant lesson I’ve learned in a while, and if I post it here, I’ll be reminded of it whenever I see this post. Today I spent over two hours on a problem that I could have theoretically solved in less than half of that time if I had approached it with more patience.

    After a good hour and a half of frustration, I gave up on the solution I was pursuing and decided to start over. I printed out a few methods, grabbed a pen, and forced myself to understand each piece before I moved on. I had avoided doing this at the beginning, because I thought I could. It took me all of ten minutes to do.

    Once I had done this, I created some test data. A short while later, the solution jumped out at me. One line of code, which had been there the entire time, suddenly appeared “wrong” based on what I knew about those methods I had printed earlier. If I had taken the time to understand all the relevant code at the beginning, I would have saved myself an hour and a half, as well as all the discouraging feelings that accompany the failure to grasp and fix a seemingly simple problem.

    Sun 23 Mar 2014

    Markdown with Redcarpet + Syntax highlighting with Pygments

    I thought it’d be nice to be able to use Markdown in my posts and also have highlighting for bits of code. I originally followed Railscasts Episode 272: Markdown with Redcarpet, but it’s far enough out-of-date that nothing was working. Luckily he covers Redcarpet in Episode 207: Syntax Highlighting (revised), and also shows how to add syntax highlighting using the pygments.rb gem.

    Tinkering with the out-of-date implementation from #272 cost me some time, but once I stumbled across the revised syntax highlighting episode, everything came together quickly. That is until I pushed everything to Heroku. I've spent quite a while trying to get the highlighting to work, but nothing has been successful so far. Unfortunately, I've got other things to attend to, so until then, I'll have to settle for nicely formatted, but un-highlighted code blocks.

    def prettily_highlighted_code?

    Wed 19 Mar 2014


    A friend recently sent me a link to Codewars, a language exercise application that presents you with a problem to solve, a place to write tests, and an interpreter to run your tests in. Once you are satisfied with your solution, you submit it to be run against the codewars test suite. Once it passes their test suite, you can submit your solution and view passing solutions submitted by other users. Solutions can be up- or down-voted, so the top few solutions are usually the best. This isn’t strictly true, though, since people take different approaches. While the top-voted code tends to be the shortest and simplest, some people will re-implement built-in Ruby functions or just try different things, and of course, those are worth reading as well (sometimes even more so than the “best” answer).

    The solution submission and voting part is my favorite aspect of the site, because often another user has come up with a better solution than me, which I get to learn from. And in cases where my solution is the same as the top solution, it’s a great feeling!

    Another aspect worth mentioning is that there are ranks (16 in all), and users work their way up through the ranks as they complete katas. This lends a game-like atmosphere to it all, which I enjoy.

    Thu 13 Mar 2014

    New Stuff- Testing

    As I mentioned in the previous post, I wanted to write a bit about some of the new things I’ve encountered while working on the application for the tutoring company.


    Prior to this, I had used RSpec + Capybara for all of my testing, but the test suite for this application used Test::Unit instead of RSpec. Really, it wasn’t much of a leap, since I had some familiarity with Ruby’s assertions already. I had never combined them with Capybara’s matchers before, though, but it didn’t take long to get comfortable with.


    The test suite uses fixtures to generate test data, which was different from the factories-based approach I had seen and used elsewhere. Fixtures are fairly simple though, so again, it didn’t take long to get accustomed to using them.

    Functional (controller) specs

    While researching functional specs, it became apparent that there’s no consensus on whether they’re necessary, or whether good integration tests would effectively test everything that functional tests would. Although the decision was made to favor integration specs over functional specs when writing future tests, I did get a chance to write a few functional specs to get a feel for them.

    Learning about functional specs and reading discussions about their necessity (or lack thereof) gave me a better understanding of testing theory in general, and what should and should not be tested in unit, functional, and integration tests.

    Mocking & Stubbing

    I’ve read a half-dozen different explanations of how to write tests using mocks and stubs, but the explanation given by Sandi Metz in her book Practical Object-Oriented Design in Ruby (POODR) was by far the clearest and easiest to understand. I’m glad to have a new testing tool at my disposal.

    Speaking of POODR, all of Chapter 9 has been immensely helpful in changing how I think about testing. It has also helped me to understand why the tests I’m working with are designed the way they are, and what I should look for when reading tests.

    Javascript testing with Poltergeist

    I will probably give this topic a post of its own in the near future, once I’ve got a better handle on it. All I can really say now is that I’ve been able to write integration tests for features that rely on Ajax calls, but it can be tricky. I’ve been using Capybara + Poltergeist. I’ve run into a few difficulties, though, namely a timing issue, which causes a few tests which fail sporadically. I “fixed” this by adding 0.1 second sleep statements at certain points, but I haven’t been able to get a real solution to work yet. I want to get this ironed out soon, though, since expanding integration test coverage is one of the goals for the near future.

    Mon 10 Mar 2014


    For the past few months, I’ve been working for another freelancer on a pretty neat project. The client is a company which provides high-end tutoring services, and the project is a new application which takes care of both internal and customer-facing needs.

    When I started, the application was about 85% of the way to its initial launch, which was great, because that meant lots of code-reading to get up to speed. And because the application is many times more complex than anything I’d worked on previously, any time spent reading code is extremely useful to me, both because it exposes me to new design patterns and good coding practices, and also because it’s a great opportunity to practice tracing through code, usually across many files, to understand what’s happening.

    I’m also learning a ton of things that are Ruby- and Rails-specific, such as new-to-me Ruby idioms, and various ways of organizing code within a Rails application. I plan to write a few posts discussing some of the new things I’ve learned over the past few months.

    Also, since my schedule and workload varies day-to-day, I’ve been able to find time to read and study more, which has been great. I’ll write about some of the books I’ve been reading in an upcoming post.

    One final note: subcontracting is fantastic. The person I’ve been subcontracting for has been assigning me a good mix of issues that are within my current capabilities and issues that are far enough outside what I currently know that I’m exposed to new and more complex things (but not so far outside that I run into roadblocks or get overwhelmed).

    While I enjoy learning for its own sake, it’s much more motivating and satisfying to learn while adding value to a real-world business. If you’re a freelancer who might be interested in working with a subcontractor, drop me a line.

    Fri 07 Mar 2014