Category Archives: Programming

Thought for the Day: Exceptions

Use exceptions for exceptional circumstances. Will your program still run if the exception handling code is removed? If so, you may be misusing exceptions. In effect, you may be using exceptions as a way to emulate goto statements!

(Found this today in a collection of programming thoughts I wrote back in 2005.)

Knowledge, Reality and Reconciling the Difference (Part 1)

Values often need to be tracked as they change over time. Imagine we’re building a payroll system. A foundational requirement would be to store an employee’s pay rate. In all but the most basic of systems, saving this rate as a simple value is insufficient (“Joe’s wage = $20/hour”); rather, a history of the rate over time needs to be maintained (“Joe’s wage = $15/hour as of 10/15/13; Joe’s wage = $20/hour as of 2/1/14”). We do this by giving pay rate a time dimension.

What our system knows about a given moment in time and what really was at that same moment can differ. Suppose Joe’s manager signs paperwork on January 20 giving Joe a pay raise but leaves for vacation before turning in the paperwork. At close of business on January 20, the payroll system knows Joe’s rate to be one amount when, in reality, it’s a different amount. Joe has been given a raise but the system doesn’t yet know about it. Continue reading

Quick Tip: Setting Variables Inside Array & Hash Literals

Did you know that you can assign variables inside Ruby’s array and hash literals?

While the values used inside square bracket array literals are typically hard-coded, provided by a variable, computed from an inline expression or generated by a method, any valid Ruby statement can be used. The same is true for both keys and values used in hash literal key => value pairs. Continue reading

RSpec: be true & be_true Are Different!

, , ,

RSpec’s be true and be_true look deceptively similar. In fact, their naming suggests that they might be synonyms for the same assertion. Can the two clauses be used interchangeably to produce the same effect? No!

Both check trueness but from different perspectives. be true checks whether the compared-against value is true: “Does the value literally equal true?” be_true asserts that the test value evaluates to true: “Is the value truthy?” be false and be_false are the respective inverse match clauses. Continue reading

Let It Quack!

, ,

Duck Crossing Warning SignAn entire day passed. The repugnant lines sat festering. Finally, their odious stench wafted strong enough to give me a start. What had I done?!

The situation started simply enough. I realized several kinds of transactions shared common logic. Despising duplication as a good programmer should, I placed this shared behavior in a base class which the various kinds of transactions would subclass. Continue reading

Perusing Prolog (Part 2)

In interview style, here’s the conclusion of my reflections after studying Prolog for two months. If you’d like, read Part 1 first.

What did you find unique about the language?

Unification! Prolog works by trying to make terms equal one another. In most languages, the statement “Cost = 100” sets the variable “Cost” to a value of 100. In Prolog, “Cost = 100” means (in effect): “can Cost and 100 be unified?” During execution, Prolog takes into account the entire set of logical rules that have been defined to figure out if Cost and 100 are allowed to equal the same value. While possible, the need for statements manipulating variables’ values within an operation occurs far less frequently in Prolog than in the languages I’m used to. Continue reading

Perusing Prolog (Part 1)

Reading my way through Seven Languages in Seven Weeks this past fall, Prolog caught my attention. The language worked so differently than any I’d used. It offered to solve problems challenging to code in the languages I was familiar with. Intrigued, I started setting aside an hour each workday to study Prolog. Learn Prolog Now! served as my primary tutorial. In interview-style, here are my thoughts after two months of exploring Prolog. Continue reading

Ruby: Case Testing Against Arrays of Values


Did you know that a when clause in a Ruby case statement can test against each item in an array? If any item in the array matches the case statement’s comparison (target) value, the when clause will evaluate to true.

In the below example, :express_truck will be returned if country matches any of the truckable_countries.

truckable_countries = ['United States', 'Canada', 'Mexico']

ship_via = case country
           when *truckable_countries

Continue reading

Refactoring Reflections

In Don’t Make Me Think, Steve Krug presents the premise that the better a web site’s usability, the more brain cycles the visitor is able to focus on the substance (or intention) of the site. Said another way, the less brain cycles a visitor spends figuring out how a site works (e.g. how to navigate around), the more brain cycles he has available to concentrate on site’s substance. Don’t Make Me Think’s goal is to help the reader refine his web site’s usability to the point that visitors don’t need to think about how to use the site and so can focus all their attention on the information the site was built to convey.

While working through a recent refactoring project, it occurred to me that Don’t Make Me Think’s premise closely parallels one of the main motivations behind refactoring. The better the code base’s quality, the more mental energy the code reader can focus on the intention of the program. The less brain cycles a developer spends figuring out how a bit of code does what it does, the more brain cycles he can spend focusing on what the code does. Continue reading