Whenever I have trouble with an Avro schema, a good way I’ve found to debug it is by trying to generate “random” example data using avro-tools.jar, like so:
java -jar avro-tools-1.8.2.jar random --schema-file TimeZone.avsc --count 1 -
Boston nerds: I’ll be presenting this Thursday at the Boston Clojure Group: Specifying Other People’s Data Structures with Spec: an Experience Report.
White Plains library:
…starting the first week of August, we will automatically renew your material before it becomes due.
— they also recently eliminated late fees for children’s materials. What a great library.
I just test drove a Tesla Model 3 (RWD, long-range, premium interior, 18” wheels+tires) — I only had 20 minutes, but it was fun and impressive. Very easy to drive; predictable, linear controls and handling; good ride. It’d be a pleasure to use as a daily driver.
Video of the talk I gave at @ClojureNYC last week has been posted!
Thanks to @andyparsons for organizing, recording, etc!
Wondering whether 1300 words is way too long for an Architecture Decision Record (ADR).
I have found the best giphy search.
I’m starting to think I might be practicing some mutant variant of literate programming wherein I change a few lines of code but write 200-plus-word commit messages.
This weekend I picked up some recent Batman comics from the Baltimore County Public Library in Towson, MD after reading this thoughtful review by Tim Carmody, and I was blown away by Tom King’s writing. Phenomenal!
Generative testing (property testing) with clojure.spec is kicking my ass. So exciting!
NYC geeks! I’m speaking next week at Clojure/NYC on “Specifying Other People’s Data Structures with Spec: an Experience Report” — would love to see you there. Tell me what I missed as I ramped up on clojure.spec!
RSVP here: www.meetup.com/Clojure-n…
I just installed the iOS 12 beta on my iPad and I’m glad to see that it unifies the quick-switching interactions of the iPad and iPhone X (maybe all iPhones, I don’t know). Using both devices with their inconsistent interactions on iOS 11 was consistently annoying.
Someone mentioned Groovy (the programming system) in my team’s chat channel today, and being the gray-neck-beard that I am, I waxed nostalgic:
I’m fond of Groovy, it was the little language that could … helped introduce me to some functional patterns, duck typing, more. Sort-of-maybe a predecessor to e.g. Kotlin in some ways… certainly helped prove the viability of alternate JVM languages, even if it’s since been eclipsed…
Interesting: Groovy had a bunch of early releases between 2004 and 2006, then 1.0 was released in January 2007. Clojure’s initial public release was October 2007. JetBrains started creating Kotlin in mid 2010 and announced it in mid 2011.
Not claiming any of these things are directly connected, but the broader timeline is still interesting.
In Oct 2016, Strachan [the creator of Groovy] stated “I still love groovy (jenkins pipelines are so groovy!), java, go, typescript and kotlin”. (Wikipedia)
Following up on my prior post, I just realized (while in a 1:1 with a friend) that this failure mode of mine really has two forms — and I stumble into both all too often.
Both forms involve omitting a crucial step when defining and pursuing a course of work/action.
The prior form omits the breaking of an ambitious, compelling vision into small, incremental, safe, achievable steps, and deploying them independently.
In the other form, I’ll propose or pursue a course of work comprising only small, incremental, safe, achievable steps, while omitting the crucial vision. This violates the adage “Make no little plans; they have no magic to stir men’s blood and probably will not themselves be realized.” (Daniel Burnham)
I wonder if the fundamental error in both cases is impatience.
Either way, I’m going to try hard to reduce the frequency of my failures in both forms of this mode.
Yet another painful reminder today that changes to complex systems — those made of code and those made of people — must be broken down into the smallest, most incremental steps possible, and deployed independently, or much pain will ensue.
I’ve been doing this work — designing, building, documenting, operating, and maintaining systems made out of code and/or people — for over 20 years now, and I have yet to learn this lesson deeply enough to have it be ingrained and automatic. I don’t know if I ever will. It’s clearly hard for me to resist the power and drama of big changes. I’m not going to give up though — not yet.
Update: I posted a follow-up about an hour later: Another form of the same failure mode