This is the third and last of my posts about the Marshal format. The first part introduced the format and some straight-forward serializations. The second part touched on strings and object links. This post rounds us off with regexes, classes, modules, and instances of objects.

In a previous post I started to describe some details of Ruby’s Marshal format. This post goes further: a larger set of integers, IVARs, strings, and object links.

I recently tried to resolve a JRuby issue involving Marshal. I’ve used Marshal before, but never needed to pay attention to the actual bytes written to disk. I decided to write up what I learned in the process.

On 2012-12-08, I attended the Pittsburgh Global Day of Code Retreat facilitated by Joe Kramer and Jim Hurne. As usual, I had a great time, and got to meet new people from the Pittsburgh tech scene. It’s always good for me to remember that there are non-Ruby developers out there! I even started the day off by doing the Game of Life in C#.

One of the more contentious constraints of the day was “no return values”. I feel like I was the only one in the room that liked this constraint at all! As such, I wanted to finish it up to see what my final code and observations would look like.

If you combine refactoring and making a change to your code into the same commit, you are going to have a bad time.

Running your tests in a random order is a good idea to help shake out implicit dependencies between tests. Running your tests in a deterministic random order is even better.

At work, I am still working on finding and squashing fun test failures. In this case, “fun” means tests that have an intermittent failure rate of 5% (or less!). The test issue I worked on today had to do with the “lost update” problem.

At work, we’ve been using Capybara and Selenium to test our newest web application. Many of us have used this combination before for our own projects, but it’s new territory for a work project.

Every so often, we would get this error from a specific test:

1
2

Selenium::WebDriver::Error::StaleElementReferenceError:
  Element not found in the cache - perhaps the page has changed since it was looked up

The error was intermittent, so we fell into the seductive but dangerous trap of simply rerunning our tests whenever it failed. Recently, I had a bit of time and decided to dig into it and fix it once and for all.

Have you ever seen a variable with a terrible name? This is of course a trick question; everyone has. I’d like to look at a particular variable-naming annoyance: naming the variable based on the class name.

In programming, cleaning up resources you have created is an easily-overlooked problem. In languages like C, you have to clean up everything by hand: memory, files, network sockets, etc. Languages that have a garbage collector take away the need to explicitly free memory, but you still have to manage the other resources.