Part of the CTO job is being conversant in a broad set of technical domains. I’ve never been a data engineer, but a current project has need, and thus I’ve been getting up to speed.
Spent some time on a flight this morning reading Amazon Redshift documentation, and found this beauty:
How helpful, Amazon: a best practice for loading data is to first learn how to load said data? Wouldn’t have guessed that. I wonder what other wonders of wisdom await me…
Had to fill out an online form yesterday to register for the chance to upgrade my season tickets to the San Diego Wave. The first draft of this form had some issues…
Misunderstanding of checkboxes and radio buttons is a classic, but inadvertently applying phone number validation to what is definitely not a phone number field is a new one.
Testing is a thing, my friends! Do it.
I’m hiring again, this time for a Director of Engineering. A requirement for application is submitting a cover letter, which apparently has fallen out of favor? Enough so that one candidate DM-ed me on the side to let me know our recruiting tool was misconfigured for having the field non-optional. Nope!
Personally, I enjoy reading cover letters, because they tell me something more than just what a resume can. It’s the same reason I want to hear real stories in interviews. They’re especially useful in revealing the “why” behind an application, which, in the line of work I do, is especially important.
Producing them does require some effort, which is a feature not a bug, but hopefully not too tough because you do document your work, right? And it’s getting even easier with AI, which I have no problem with a person using to get a cover letter started, given a thoughtful prompt that customizes the result to the job, the company to which you’re applying, and unique details about the applicant.
Speaking of “why” and AI, the other day I had a potential candidate ask me why I chose to join my current company. Great question! I put Claude to the test, again giving it my entire blog corpus as reference:
Based on the content of your blog, your reasons for leaving AWS to join RIPL as Chief Technology Officer can be summarized as follows:
1. Mission-driven work: You've expressed a strong interest in using technology to improve people's lives and promote human flourishing. RIPL's mission to work with governments to help them use data, science, and technology to improve policy and lives aligns well with this interest.
2. Intersection of technology and public policy: You mentioned that you've "doubled-down on situating myself at the intersection of tech and politics." RIPL's focus on working with governments to improve policy through technology is a perfect fit for this goal.
3. New challenges: You've indicated a desire for work that isn't a "solved problem." Moving to RIPL likely offers new and unique challenges that weren't present at AWS.
4. Leadership opportunity: The CTO role at RIPL allows you to have a more significant impact on the organization's direction and strategy, which aligns with your growing interest in leadership roles.
5. Building from the ground up: You've expressed enjoyment in creating and building things. A smaller, more focused organization like RIPL might offer more opportunities to build systems and processes from scratch.
6. Applying cloud expertise: Your extensive experience with AWS can be directly applied to help governments leverage cloud technologies for public good.
7. Ethical considerations: You've shown interest in the ethical implications of technology. RIPL's focus on improving government policies likely involves careful consideration of these ethical aspects.
8. Desire for meaningful impact: Your blog suggests a strong desire to make a significant positive impact. The role at RIPL seems to offer a more direct path to seeing the results of your work in terms of improved public policies and services.
While you didn't explicitly list these reasons in a single post, they can be inferred from your various writings about your interests, values, and career trajectory. The move appears to be a natural progression that combines your technical expertise with your interest in public service and desire for impactful work.Like my request from the other day, that’s pretty accurate! I wonder what other uses I can find for an LLM whose context window is big enough for nearly 9 years of writing…
My dad died ten years ago today. Hard to believe it’s been a decade, but time marches on no matter our feelings.
I’ve written about him before: how his early investment in a home computer forever altered the course of my future, how his prodding to my shy teenage self got me my first job (and a wealth of early life lessons), and how his constant encouragement became the bedrock of my sense of self.
But today I was reminded of something else he modeled: the value of just showing up. The man bent over backwards to be at every little league game, every band concert, every academic awards banquet, and so much more, usually with video camera in hand.
I’m not as good at it as he was, if I’m honest. But it’s an ideal I strive for, both personally and professionally. Do what you say you’ll do, be where you say you’ll be, pay attention, be engaged. There are no small things.
(Oh, and yes, I am wearing a Star Wars tie at my high school graduation, thanks for noticing!)
I aggressively unsubscribe from email lists in order to get to Inbox Zero. Which isn’t an end in itself, but part of a broader strategy of radical responsiveness. I’ve been pretty good about doing so with my personal email, but my work email has gotten a bit out of hand.
So the past week I’ve been working on that, for my own email address and several shared addresses and aliases that come my way. It’s tedious, but progress is being made. However, I’m regularly baffled by the number of sites that report that unsubscribe isn’t instantaneous. Today I was quoted “5-7 days”, and I’ve seen as much as “2 weeks”. Why? What could possibly take that long?
Anyone out there in the spam email marketing business that can explain it to me?
The other day I scanned and posted a gift I’d gotten from some co-workers. When leafing through the folder it was in, I found a few other fun artifacts I thought I’d share:
First, a certificate I got from my fourth grade teacher. It’s an objective I still aim for:
And second, an invite I got for helping support the underlying voting platform:
I’ve tried to do a better job recently of documenting my career experiences, not just the work-related items, but the fun stuff too. This week wasn’t so bad, even if the town isn’t my favorite:
I’m curious what sort of email templating mixup resulted in this beauty I received today. Probably some combo of Left Hand, Meet Right Hand and Slip Of The Finger.
The real task that requires immediate attention is for someone to do more testing of their notification system. I appreciate the chuckle AAA, but c’mon, you can do better.
Last night ChatGPT had a bug. But not your run-of-the-mill problem like increased latency or complete unavailability. No, it went completely off-the-rails: spouting gibberish, repeating itself ad infinitum, and other nonsensical behavior.
Hilarious though some of the outputs were, it was a powerful reminder that AI technologies are still new and mysterious, and definitely require human oversight. While this incident ended up with random output, I can now imagine a whole class of bugs where language model outputs are wrong in all manner of specifically bad ways. Humorous now, but perhaps less so once we give them agency to act on our behalf.
I anticipate the day coming when I ask my personal Scarlett Johansson to book a family vacation to Fiji and it instead sends an email to my mom lambasting her for wearing white after Labor Day and then sells my living room furniture on eBay.
The future’s going to be something else, of that we can be sure.
There’s nothing like an effort to make sure all my years of accumulated data is backed up to kick up some nostalgia (not to mention an impending birthday). I doubt anyone else much cares, but this is my website and I’ll fill it up with digital relics from my past if I want to. Consider this fair warning.
We’ll get things started with this beauty, which I wrote September 24, 1992, if the file’s timestamp can be believed. Over 31 years old, it’s the oldest digital document I can find that I wrote myself.
I do not like to go to school. All the teachers do is teach you things you already were taught in 5th grade. That is, except for math and computer class. In math, we learn all about neat things, like 3y2+4(2x3+4). Mr. Farley is a great teacher, and the other teachers should teach like he does.
In computer class we learn about computers, such as this one, and about different computer programs. That is really neat for me because I enjoy working with computers, although some kids are really dumb when it comes to computers. But it is not like English, which is the same every single year. BORING!!!!!
I suppose that Science is O.K. Mr. Freese is pretty cool, and we learn some new stuff, and some old stuff. Like the scientific method. We learned it in 7th grade, and we learn it again now. It doesn’t make any sense.
This is my story about school. I hope that someday teachers will be able to read this and learn from it. Although they won’t listen to the small ideas from a thirteen year old boy, maybe they might get ideas anyway.
For the tech nerds, the file was in WordPerfect format (which definitely squares with the technology I was using in 8th grade), and opened perfectly on my Mac using LibreOffice.
More to come!
(Editor’s note: the past two posts, Mother Of Invention, Edge Case, and this one form a trilogy of sorts, all related to a particular project I’ve been digging into).
When I first needed a way to get access to AWS from a non-cloud-based computer, I implemented 3 options: hard-coded IAM user credentials (generally bad), user-based Cognito (okay but not super scalable), and X.509 via IoT (good technology, but cumbersome to set up).
This week I had a similar authentication need within an on-premises cluster, and was happy for the chance to learn the most up-to-date approach: IAM Roles Anywhere. I really appreciate the authors of these two blog posts who captured the step-by-step quite a bit better than the official documentation:
I used my own certificate authority because AWS Private CA is too dang expensive; $400 a month doesn’t grow on trees, ya know? Here’s the bash script to create the root CA:
mkdir -p root-ca/certs # New Certificates issued are stored here
mkdir -p root-ca/db # Openssl managed database
mkdir -p root-ca/private # Private key dir for the CA
chmod 700 root-ca/private
touch root-ca/db/index
# Give our root-ca a unique identifier
openssl rand -hex 16 > root-ca/db/serial
# Create the certificate signing request
openssl req -new -config root-ca.conf -out root-ca.csr -keyout root-ca/private/root-ca.key
# Sign our request
openssl ca -selfsign -config root-ca.conf -in root-ca.csr -out root-ca.crt -extensions ca_ext
# Print out information about the created cert
openssl x509 -in root-ca.crt -text -nooutThe output from the above is what’s used to create the Trust Anchor. Then here’s a script to create a certificate for the process that will be authenticating:
# Provide a name for the output files as a parameter
entity_name=$1
# Make your private key specific to your end entity
openssl genpkey -out $entity_name.key -algorithm RSA -pkeyopt rsa_keygen_bits:2048
# Using your newly generated private key make a certificate signing request
openssl req -new -key $entity_name.key -out $entity_name.csr
# Print out information about the created request
openssl req -text -noout -verify -in $entity_name.csr
# Sign the above cert
openssl ca -config root-ca.conf -in $entity_name.csr -out $entity_name.crt -extensions client_ext
# Print out information about the created cert
openssl x509 -in $entity_name.crt -text -nooutSpecial thanks also to the creator of iam-rolesanywhere-session, a Python package that makes it easy to create refreshable boto3 Session with IAM Roles Anywhere. Seriously, could it be easier?
from iam_rolesanywhere_session import IAMRolesAnywhereSession
roles_anywhere_session = IAMRolesAnywhereSession(
trust_anchor_arn=my_trust_anchor_arn,
profile_arn=my_profile_arn,
role_arn=my_role_arn,
certificate='my_certificate.crt',
private_key='my_certificate.key',
)
boto3_session = roles_anywhere_session.get_session()
s3_client = boto3_session.client('s3')
print(s3_client.list_buckets())This was a good reminder that technology marches ever onward, and what made sense yesterday might not be the best approach today. It was also a reminder that, like DNS, TLS and PKI are some of those things that every technologist ought to know (I’ve queued up this book in my Goodreads for a deeper dive). This isn’t the first time I’ve had to write code to create certificates, but it’s now the last, because I’ll have this reference post plus its associated code repository. And so will you.