Project: SendGrid for Clojure
TLDR: If you need to send emails via SendGrid from a Clojure application, check out the sendgrid library I just released, it’s pretty swell.
TLDR: If you need to send emails via SendGrid from a Clojure application, check out the sendgrid library I just released, it’s pretty swell.
Whenever you look around, you know what you should be doing: creating and launching and selling a product, bootstrapping a business on the side. You’re smart. You’re capable. You’ve got the skills to make stuff […] why can’t you just make this happen? […] We’ll teach you 21 principles for getting off your butt and finally shipping. (official site)
Part of my 2016 reading list.
This is a soup-to-nuts guide to the human aspects of shipping a side project. It’s not going to teach you how to design a logo or a code a website, but if what’s holding you back from completing your dream is lack of confidence, disorganization, over-ambition, etc., then this could be the book for you.
There’s nothing tremendously groundbreaking here, but it’s compact and won’t waste your time (as I’ve come to expect from Amy Hoy).
Meditations…is a series of personal writings by Marcus Aurelius, Roman Emperor from 161 to 180 AD, recording his private notes to himself and ideas on Stoic philosophy. Marcus Aurelius wrote the 12 books of the Meditations…as a source for his own guidance and self-improvement. (Wikipedia)
Part of my 2016 reading list.
Definitely a worthwhile read. I read the (recent) Hays translation as I heard it continually recommended. These are private notes on life from a great man, and one of the great charms of this book is that it’s not dressed up in hopes of impressing anyone–it’s practical and direct. He probably never expected anyone else to read it.
2015 was a haphazard reading year for me, with a number of partially-read books at the beginning of the year, squeezing in a few pages in my tent while roadtripping across the western U.S., and then finally powering through a few more books once life settled down a bit. Eleven books finished in total, assuming I’m not missing anything.
This year I’m going to try being a bit more structured (in the spirit of Mark Zuckerberg), and lay out a schedule of what I will definitely be reading. With my current workload that’s going to be a modest one-book-per-month pace, but additional reading is of course welcome. A schedule will allow me to clear my plate of a few lingering items, establish some higher-level reading themes, and have some idea of when I’ll actually get to one book or another.
TLDR: I’ve just released a pair of libraries which I believe constitute the best way to use the Honeybadger exception reporting service from Clojure–camdez/honeybadger and camdez/ring-honeybadger.
I’ve been using weavejester’s ring-honeybadger in my projects, and while it has served me well, I end up rewriting the Ring integration every time because it’s not particularly open for extension. I also feel that Honeybadger has a lot of utility beyond just reporting exceptions from web servers, and towards that end I wanted to write one library that encapsulates all of the features of Honeybadger, atop which something like a Ring reporter could be written. I’ve tried to consider what the appropriate extension points are, and how to make common things easy.
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”.
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:
(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.
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.
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.