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.
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:
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.
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.
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.
This was my first podcast appearance, so thanks a ton to Nick and
Virginia for taking a chance on me! We had a lot of fun doing it and
ended up running long enough to make a double episode.
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.
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:
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:
# my (fictitious) fork of railsgem'rails','4.1.0',git:'https://github.com/camdez/rails.git'
Now, one would probably think that both of these Gemfiles precisely
reference a single release of the rails gem (for their respective
sources), but there turns out to be a nasty catch:
The RubyGems version always refers to the version of rails pushed
as 4.1.0, but the GitHub version refers to the latest commit
containing a Gemspec declaring version 4.1.0.
If you’re like most people, happily developing on master, and you’ve
released version 4.1.0 of your gem and now you’re pushing changes
which will eventually become 4.1.1, 4.2.0, or even 5.0.0 (you’ll
decide later), all of those commits are getting pulled into projects
where devs have referenced version 4.1.0 of your project via git,
every time they bundle.
I nearly got burned by this because I was about to (unknowingly) push
a pre-release version of a gem into production, but I happened to
notice a difference in gem SHAs in the Gemfile.lock for two branches
with the same Gemfile, making it clear that I didn’t have an
immutable reference to a release.
So, what can you do? Well, first of all, stop using version
specifications on your gems pulled via git. They’re misleading.
Next, you could go full paranoia and start referencing particular git
commits via the :ref specifier. Another approach would be to change
your development workflow and only merge releases into master1, but
I find that to be a lot of ceremony for simple projects, and it could
still support the bad habit of using unsafe version specifiers.
Personally, I think the best approach is to tag all of your releases
and reference them via their tags:
# my (fictitious) fork of railsgem'rails',git:'https://github.com/camdez/rails.git',tag:'v4.1.0'
This still gives you the ability to modify what commit is considered
to be the release2, but affords dramatically more stability than
the moving target that a version specification provides.
Probably best done with git merge --no-ff so that there are never any non-release-ready commits on the branch.↩
Obviously this should be used sparingly (if ever), like git push --force.↩
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 .emacs:
Now, the obvious part of this problem is using package-installed-p
to check if each named package is installed and then installing the
missing ones. The less obvious part is that we may need to call
package-refresh-contents to get the package repository data
(especially on the first load) or else we’ll get errors. High-level,
there are four ways I know of to approach this problem:
Always call package-refresh-contents.
Check if package-archive-contents is non-nil.
Test if package-user-dir exists.
Refresh if any packages are missing.
Number one works buts is extremely inefficient—I don’t want to wait
for a package repo fetch every time I start Emacs.
Two and three have a fatal flaw: just because we have some package
data doesn’t mean that we have the latest data. So it’s entirely
possible that we don’t know about a recent package that the user wants
to install—errors again.
The fourth method is the way to go. Surprising no one1,
@bbatsov shows up with the right answer.
But I do think this code could be a hair cleaner, so here’s my take:
(require'cl-lib)(defunmy/install-packages()"Ensure the packages I use are installed. See `my/packages'."(interactive)(let((missing-packages(cl-remove-if#'package-installed-pmy/packages)))(whenmissing-packages(message"Installing %d missing package(s)"(lengthmissing-packages))(package-refresh-contents)(mapc#'package-installmissing-packages))))(my/install-packages)
The function2 exists so that you can invoke it manually (M-x
my/install-packages RET) if you’ve changed my/packages at
Keep in mind that re-evaluating my/packages after changing it will
not do anything because that’s how defvar works. Temporarily change
defvar to setq and you’ll be good to go.
cl-lib is required for cl-remove-if. How Elisp has made it this
far without a filter function, I don’t know.
I’m not entirely sure if nil punning is idiomatic elisp or if
there’s a more appropriate way to check for empty lists. Anyone
Bozhidar Batsov is killing it in the Emacs community right now and you should probably be following him.↩
Rather than including what is currently the function body at the top level of the .emacs file.↩
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
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:
After defining a goal, ask yourself, “How surprised would I be if I
failed to achieve this?” If you’d be shocked, you’re done. If not,
refine your plan by asking yourself how you’re most likely to fail,
and then reworking your goal to prune that particular vector of
failure. You should repeat this process until you’re confident that
you’ll achieve your goal.
This doesn’t mean that you have to write less ambitious goals, only
that when you have ambitious goals you have to lay out the process
by which you’ll get there.
“[F]or each goal, brainstorm some other ways of achieving it. Try
to find a better plan than the one you currently have.”
I really like this idea and I think I’d prefer to amend it to say
“write down three different ways of achieving the same goal” to
force our hand to actually run through this exercise and not
dismiss it assuming we’ve already chosen the best path. Playing
this antagonistic role to yourself (i.e. trying to beat your own
idea) is a great way of breaking out of optimistic biases, and
helps us to avoid false dichotomies (well,
If this topic interests you, stay tuned. I’m working on coalescing
everything I know about goal setting into one handy dandy template. I
think it’ll be good. ;)
I don’t know exactly where template came from (or even how I found it), but I know it—like the other template—connects back to CFAR, so there are probably some shared influences.↩
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.
I’m currently in the first mode. I share what I like, and hopefully
I’m opening the door to new connections—maybe I’m entirely wrong in my
assumptions of what people like! At least for me, it’s better this
way. But I can’t pretend that I’m not a bit self-conscious about what
I put out. I fixate on how it must be uninteresting to the majority of
people, how boring (not to mention uncool) tech can seem from the
outside, and how my interest in the process of self-improvement can
seem awfully self-centered.
—and suddenly my alarm went off. 7AM. It slowly dawned on me that
there never was a text message from my sharp-tongued friend.
It seems so incredibly devious that my mind would latch onto a
pre-existing concern, then take a jab an me in the guise of an
individual whose words it knew would sting. And I don’t tend to be an
undermining person. The unconscious brain is quite a thing…
I couldn’t help but think of Steven Pressfield’s book
The War of Art1, which discusses and personifies the
(internal) forces which hold us back from doing the things we want to
do with our lives:
RESISTANCE IS INTERNAL
Resistance seems to come from outside ourselves. We locate it in
spouses, jobs, bosses, kids. “Peripheral opponents,” as Pat Riley
used to say when he coached the Los Angeles Lakers.
Resistance is not a peripheral opponent. Resistance arises from
within. It is self-generated and self-perpetuated. Resistance is the
RESISTANCE IS INSIDIOUS
Resistance will tell you anything to keep you from doing your
work. It will perjure, fabricate, falsify; seduce, bully,
cajole. Resistance is protean. It will assume any form, if that’s
what it takes to deceive you. It will reason with you like a lawyer
and then jam a nine-millimeter in your face like a stickup
man. Resistance has no conscience. It will pledge anything to get a
deal, then double-cross you as soon as your back is turned. If you
take Resistance at its word, you deserve everything you
get. Resistance is always lying and always full of shit.
I wish I could recommend this book wholeheartedly but I can’t. The beginning sections are great, but near the end of the book it really goes off the rails with odd ideas regarding the artist’s connection to the gods, or some such garbage. I’d probably tear off the back half before offering it to a friend. I can, however, wholeheartedly recommend the book that led me to Pressfield in the first place: David Mack’s amazing hand-painted / collage / decoupage / strange loop comic masterpiece, Kabuki: The Alchemy, which holds a special place in my collection of books.↩
Lessig interviews Jack Abramoff – direct questions and answers
with America’s most infamous political lobbyist who “pleaded guilty
in 2006 to charges of fraud, tax evasion, and conspiracy to bribe
public officials”. Every American should listen to this interview to
understand the reality of American politics, straight from the
Rubocop – a fantastic static code analyzer for Ruby which will
help you catch common errors and style guide violations. If you
write Ruby, you should be using this. If you use Emacs, run it via
A Radical View – a neat graphical layout of Chinese characters