There’s a loose convention in Clojure of leaving top-level (comment ...)-style comments in source files to give examples of how a
particular piece of code works or to provide a convenient means of
invoking functionality contained in the file. You can even see this
in the source files to Clojure proper.
Even though leaving commented out code can seem a bit messy, it has
also saved me a ton of time relearning how to invoke something, so I
have somewhat mixed feelings about the practice. But, regardless of
the merits of using this in production code, it’s unarguably useful in
development, and I use it extensively as I work to test out function
invocations with different arguments, and to store little bits of test
Frustratingly, this form does not play nicely with CIDER’s C-M-x
(cider-eval-defun-at-point) and C-c M-;
(cider-eval-defun-to-comment) commands, which expect the target form
to be at the top-level of the file. The containing (comment ...)
form means that technically isn’t so, leading me to perpetually
evaluate the wrong form…
When working on CollBox, we have a handful of external services
the app depends on which we need to have running at development time.
I used to run these via Foreman, but somewhere along the way my
Ruby installation seems to have gotten borked (thanks, Catalina?)
and since then I’ve been running the services by hand. I always work
in a tmux session anyway, so I decided it was time to see
what it would look like to launch my window full of dependencies in
tmux from a script.
Last year I tried out making a reading list in
January, to keep myself reading at an acceptable pace, and to put a
bit more foresight into what I would be reading. This worked out
pretty well. Despite finishing a couple of my 2016 books in the first
days of 2017, I largely stuck to my schedule, and I finished
everything on my list, including a few rather lengthy items. I
actually didn’t read a whole lot more than I had listed (to my
surprise), which makes me even more confident that this is a good
idea, since it sets a minimum reading curriculum.
Again this year, I’ve tried to establish some common themes to allow
for comparative reading and amass some knowledge of a field. The
stronger themes are decision-making (four books) and creativity (four
books), and the remaining four books are loosely centered on
self-improvement, though that’s more of a coincidence than a plan.
I’m abstaining from buying anything today in protest of excessive consumerism. Make something instead!
And got a rather curious reply from a friend:
I wish I could make things
I mulled that over for quite a while. I struggled to put myself in the commenter’s shoes. It’s wildly foreign to me.
In my head, clearly creation is for everyone. It’s not the domain of some privileged class of individuals—it’s an essential act of being human. Everyone should—and can!—create. But I kept tugging at the thread because of a nagging suspicion that perhaps lots of people feel this way.
I just read David Bryant Copeland’s post
It’s not Naming That’s Hard—It’s Types which he wrote in
response to Katrina Owen’s
What’s in a Name? Anti-Patterns to a Hard Problem and I feel
compelled to say a few words. Katrina’s post provides some
suggestions around the perennial developer challenge of naming things
in code. Along the way she asserts that including the type of a
variable in its name is typically an antipattern, and “type
information is just not that compelling”–something David took great
David argues that the actual problem is we don’t have enough types:
“types are a better way to solve the problems Katrina identifies in
He then proceeds to turn Katrina’s perfectly reasonable bit of code…
subject != candidate && same_alphagram?(subject, candidate)
# ... (not provided, but I want to offer a fair comparison of length)end
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.
This is 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
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
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.