Practical Data Coercion with Prismatic/schema

If you follow me on Twitter, you probably know I’m a big fan of Prismatic’s schema library, which gives us a convenient way to validate and enforce the format of data in our Clojure applications. I use schema extensively both to provide some of the comfort / confirmation of a static type system, and to enforce run-time contracts for data coming off the wire.

But a problem quickly arises when we’re enforcing contracts over data drawn from an external format like JSON: the range of types available in JSON is limited compared to what we’re used to in Clojure, and might not include some of the types we’ve used in our schemas, leaving our schemas impossible to satisfy. Note that I’m not necessarily talking about anything exotic—simple things like sets, keywords, and dates are missing. The situation is even worse if we’re talking about validating command line parameters, where everything is a string regardless of if it logically represents a number, an enumeration value, or a URL.

What are we to do? Try to walk this data of unknown format, which is perhaps nested with optional components, transforming certain bits, and then running the result through our schema validation? That sounds ugly. And what do those error messages look like when it doesn’t match? Or we could validate that our (say) “date” parameters are present and are strings in a format that looks like we could parse it, then transform the data (which is at least in a known format now), and then validate it again? Obviously that’s less than ideal. And we’re going to end up with a proliferation of schemas which differ only in predictable ways—e.g. “params come in as a hash of two date-like strings, then get transformed to a hash of two dates”.

Dasherize HoneySQL Columns

Well…Korma didn’t work out… There are lots of things to like about it, but I honestly can’t deal with the fact that when you join on a belongs-to relationship, it simply merges all of columns into a single map (:id-2?).

Anyway, I’ve moved on to HoneySQL for now. Which still features the_kind_of_attribute_names only a database could love. Let’s kick that to the curb.

Dasherize Korma Columns

A quick tip for the Korma SQL library for Clojure:

By default, Korma will return column names with underscores (e.g. :this_kind, unmodified from the database convention), while Clojurists are likely more comfortable with :this-kind of dash-separated keyword. (Some people call this “kebab-case” vs. “snake-case”). To wit:

(defentity locations
  (belongs-to user))

(select locations)
; => ({:user_id 1, :latitude 30.02, :longitude -116.992})

We can convince Korma to automatically translate these names using Korma’s own prepare and transform functions, which are given the chance to mutate attribute names and values on the way to / from the database, as Conan Cook points out in his Tasty Korma Recipes post. But it gets a bit cumbersome to inline this code in every entity definition.

Talking Atheism on the Nerd Absurd Podcast

The lovely folks from the Nerd Absurd podcast had me on their show a couple months back1, along with my coworker Aaron, to discuss atheism and what it’s like growing up as an atheist in America. I founded–and for several years ran–The Atheists and Freethinkers Society at UT Dallas, an experience which left me with no lack of stories (both entertaining and infuriating) about growing up as part of America’s most-hated minority.

The Parable of the Starchart

In my sophomore year of college I lived on campus with two roommates. Like so many other college roommates, we had a bit of a problem keeping the kitchen clean.

We weren’t especially messy people on our own, but there’s something unfortunate that happens in shared spaces where responsibility is divided. Tasks without a single, clear owner tend to get ignored while everyone waits to see if the others will tackle it. Questions about fairness arise, and perceived slights set off chain reactions of retribution.

At some point I decided we needed a way to track our individual contributions. I wrote our names across the top of a piece of paper and picked up some gold star stickers (childhood nostalgia, anyone?). The starchart was born.

Private Ruby Gem Versioning

TLDR Don’t use version specifiers when referencing gems from git in your Gemfile. Use tags or refs instead. Most of the time when declaring our Ruby projects’ dependencies via a Gemfile, we pull our gems from a source like RubyGems.org: source 'https://rubygems.org' gem 'rails', '4.1.0' In this case you nearly always want to specify a version number for each gem to keep bundle update sane and safe. But when you have your own branch of a public gem, or an internal project that can’t live on the public web, the typical solution is to pull it from git via a :git or :github specification:

Automatically Installing Your Emacs Packages

The interactive list-packages command in modern Emacsen is handy for finding and trying out new packages, but once we’ve found packages we want to use, how can we have them automatically installed on all machines where we use Emacs? There’s a decent Stack Overflow question on the topic, but I want to dig into the various answers a bit and provide a slightly cleaner (IMHO) code snippet. First let’s define that list of packages we want installed by adding a defvar form to our .

Switching to MELPA Stable: Why, How, What I Learned

Background

Writing my first Emacs package a couple months ago left me more cognizant of how Emacs’ packaging system is put together and raised questions about how I use its capabilities. I had been installing all of my packages from MELPA, but now, as a fancy-schmancy package author I’d become intensely aware that MELPA builds its packages based on the latest commit in a project’s repository1. Suddenly I’d become paranoid about exactly what I pushed to the master branch of my project and worried about leaving things in a broken state.

Generally speaking, I keep the master branch on my projects in a functional state, and–yes–I could adopt a development methodology whereby work is always done on a development or feature branch and QA’d before being merged into master. But even if I have the inclination and discipline to manage my projects this way, all of my other Emacs packages are getting built from whatever happened to be pushed to master in their own project when the MELPA bot decided to make the rounds. I’ve run my fair share of beta software, but I don’t need every commit as it happens (cutting vs. bleeding edge).

As it turns out, there’s a new kid on the block–MELPA Stable–and she’s come to solve this exact problem.

Goal Refactoring Insights

In IOI#1 I mentioned “goal factoring”. In a nut, the idea is to apply a consistent, rational process to the goals you’re thinking of setting for yourself to ensure they’re appropriately sized, likely to succeed, and the best path to the underlying thing that you want to accomplish.

I’m currently working on my own goal definition / factoring process, but I wanted to offer a tip of the hat towards these two templates which I’ve repeatedly pored over:

Résistez à la Résistance

I awoke this morning to a text message from an old friend with a rather sharp tongue:

Lol. You’ve gotta stop it with these Facebook posts.

I knew exactly what it meant. It stung a bit because it was precisely what I worry about: I have a tenuous relationship with Facebook because there’s a disconnect between the I people know & consider (Internet) friends, and the interests I have. I vacillate between thinking I should post content I’m interested in (and let the audience self-select) and thinking that I should tailor my posts to my audience.