What is the Ruby Legacy?
The world is changed, I feel it in the water, I feel it in the earth. I smell it in the air.
—Galadriel
The Well in the Field
When I was a child, I lived with my parents in the woods. We had an old-fashioned hand-dug well, the kind from storybooks that looks like a big hole in the ground lined with stacked stones. In summer, if there was a drought, the well would sometimes run dry.
SIGAVDI #82: Broccoli Rabe Edition
Hello friends,
It’s been another couple weeks of hunkering down with Jess & family in St. Louis. It turns out the way I deal with social distancing is to buckle down and work really hard. When all this is over I may need to impose periodic “productivity quarantines” on myself to match this level of output.
Reproducibly Setting Production Environment Variables for AWS Lambda Apps
The problem with infinitely flexible building blocks is that there are always a half-dozen well-documented ways to do things wrong.
I wanted my AWS Lambda app (I refuse to call it a “function” because it isn’t) to get the third-party API keys it needs from environment variables. Not from hardcoded strings or config files.
The most immediately accessible way to set up env vars for a Lambda is via the AWS console. But that’s not a reproducible, versionable workflow I can capture in my project.
Searching for info on setting up environment variables in a SAM-based AWS Lambda app turns up a lot of results. It seems you can set variables in the SAM config in template.yaml.
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: hello_world/
Handler: app.lambda_handler
Runtime: python3.7
Environment:
Variables:
API_KEY: 12345...
More usefully, you can define env vars that apply to all of your functions by putting them in the globals section that normally lives at the top of template.yaml
Globals:
Function:
# ...
Environment:
Variables:
API_KEY: 12345...
Which is all great, except that I explicitly don’t want these variable values to apply universally, and I don’t want them to be checked-in to my repo. I just want to set them for my production deployment.
My searching next took me down the rabbit hole of AWS Systems Manager Parameter Store. But that’s way too heavyweight a solution for what I want to do.
Finally, I realized that I could probably set env vars via the aws CLI (not sam). Like everything to do with AWS, the command isn’t particularly intuitive, but here’s what I cam up with:
aws --region us-east-1 lambda update-function-configuration \
--function-name myapp-MyFunction-1234ABCD \
--environment "Variables={API_KEY=12345}"
Some points to note:
- Nothing worked until I explicitly set the
–region - Environment variables are part of a “function configuration”
- The function name for a SAM-managed app is the full name that SAM invents, including the app name, the function name, and some ID garbage at the end.
- You can’t just set environment variables directly; that would be too easy. You need to pass
Variables={...}, where the contents of the curly braces arekey=valuepairs delimited by commas.
This gives me a documentable, reproducible template for setting API key environment variables in just the production deployment. Which is what I wanted.
AWS SAM in a Docker Dev Container
When you look up AWS Lambda tutorials they usually walk you through using the web console to roll out a function-as-a-service. This is a nice parlor trick, but it doesn't help you do real work on Lambda because it's not reproducible. Until Github Actions can include “click 150 different things on console.aws.amazon.com”, reproducible builds means writing code on a developer machine, and making use of code-as-config and command-line tools to build and deploy.
So yesterday I took another crack at learning AWS SAM (Serverless Application Model), which is a command-line-and-config-files abstraction layer on top of AWS CloudFormation.
Edsger Dijkstra and the TSA school of software correctness
Joseph Goguen authored Algabraic Semantics of Imperative Programs, and was professor of computing systems at Oxford. Given those credentials, one might expect him to have been firmly on the “formal methods” side of programming language research. But in an essay in Software Development and Reality Construction entitled “Denial of Error“, he wrote this:
SIGAVDI #81: Mustard Greens Edition
Hello friends,
It’s been a weird week for all of us, I think. I don’t have a lot more to say about that, so I’m just going to proceed forward as usual.
I'll Trade Ya!
Hey there! Archived SIGAVDI letters are for newsletter subscribers only. All it costs to join (and unlock this post) is an email address! I'll write to you weekly-ish with a few interesting links, some updates, and some reflections on the intersection of software and life. And I'll respond to your replies! Whattya say?
What’s Good
- Dorian Taylor says that “Agile as Trauma”. This is a deftly written article on how Agile, like so many movements, is a reaction to what came before.
- Martin Fowler wrote a 2003 article that defines the role of “architect” better than any other source I’ve seen.
- Alice Goldfuss on surviving the sudden transition to remote work.
- GeePaw Hill has a nifty Twitter thread on higher-level refactorings.
- Pat Helland’s classic paper on life beyond distributed transactions.
What’s New
- Since so many people are experiencing a sudden shift to remote work, Chelsea Troy and I thought we’d kick off a newsletter with some tips and encouragement for newly remote developers. Sign up for it here!
- This also seems like an opportune time to mention that ages ago, I hosted a podcast all about remote work and dispersed teams. I stopped producing it in 2013, but all 103 episodes are still available! I took some time this week to update the site’s software and spruce it up with a more modern theme.
- New RubyTapas freebie! Much like a vestigial tail, Ruby has a character literal syntax which is funny-looking and largely useless. In this very early (and boy it shows 😅) RubyTapas episode, we'll use the excuse of completeness to find an excuse to use it anyway!
- Inspired by my and Jess’ keynote at CodeBEAM SF, I published a RubyTapas episode on how temporal modeling can help us design our code, by making aggregates easier to see.
- Also new on RubyTapas: let’s do function pipelining a la functional programming languages… in Ruby! We’ll explore what facilities Ruby already has out-of-box to accomplish this, and then tinker with some light language modification.
- The other day I “sat down” virtually with Eric Normand of LispCast.tv and PurelyFunctional.tv to discuss the developer education business. We talked about business models, subscription vs. product pricing, courseware software, and a lot more.
Where to find me
- April 27-May 1: Rather than cancelling, GOTO Chicago has opted to go online and “redefine what it means to host a virtual conference”. Come join me, won’t you?
- Today-???: Hunkering down, waiting for COVID-19 to blow over.
Toss a coin to your SIGer
And now a word from our sponsor: me! Do you like SIGAVDI? Do you enjoy my other publications like that video with Eric Normand? Consider tossing a buck or two my way on Patreon. Thanks! 🙏
What to write of my life in these strange days? As a programmer, my life is your life is our life now: sequestered in our houses, adjusting to a world in which work-from-home is no longer a perk but a mandate.
One minor-but-real risk we confront almost immediately is the mushing-together of time: what is to differentiate the days when our surroundings are the same 24/7? A first line of defense: a new appreciation for, and dedication to, the seasonal holidays. Sláinte, friends.
In The Closed World, author Paul Edwards says that there are “two major genres of historiography” when it comes to the computing revolution, but that:
…the tropes and plotlines of both genres impose requirements that lead authors to ignore or downplay phenomena outside the laboratory in the mind of the scientist. Both versions of the story explain developments in a given field solely from the perspective of actors within it. As Mahoney puts it, the authors of this “insider history… take as givens… what a more critical, outside viewer might see as choices”. There is little place in such accounts for the influence of ideologies, intersections with popular culture, or political power. Stories based on the tropes of progress and revolution are often incompatible with these more contingent forms of history.
This puts me in mind of The Californian Ideology:
Because these core workers are both a privileged part of the labour force and heirs of the radical ideas of the community media activists, the Californian Ideology simultaneously reflects the disciplines of market economics and the freedoms of hippie artisanship. This bizarre hybrid is only made possible through a nearly universal belief in technological determinism.
(Emphasis mine).
The common theme here is the belief that technological progression—and the resulting business, economic, societal, and political upheavals stemming from it—flow out more or less inevitably and mechanically from technical advances. But what if we have more agency in this process than we imagine? More importantly: who benefits from us, the technologists, adhering to this deterministic view of blind, inevitable change?
What’s next
Priority one is still finding a new gig. I’m also taking advantage of the enforced down-time to up my rate of publishing, do more collaborations, and tackle a bunch of unshaven yaks on my websites.
Last week(s):
- ✔ Find someone for whom to do some short-term billable work. The next round of funding for a video project I’ve been consulting on came through, so that’s going to be a priority this week.
- ❌ Do some actual billable work. But soon…
- ✔ Get through one more (ugh) job search hoop.
- ✔ Narrow down a longer term consulting client on the cautious assumption that the preceding item won’t go anywhere.
- ✔ Catch up on mail etc.
- ✔ Make at least one quickie RubyTapas episode.
- ✔ Come up with next tasks for the guest episodes that are now stalled because I have less organizational help.
- ✔ Stream something educational. Not technically streamed, but I’m counting that Eric Normand interview.
Bonus points:
- ✔ Kick off a new remote work newsletter collaboration.
- ✔ Revamp the Wide Teams website in support of the above.
- ✔ Update subscription forms etc. to reflect the BRUNCH/SIGAVDI merge.
- ✔ Study Dark a bit more.
- ✔ Free up a RubyTapas episode
- ✔ Send out a new “RubyTapas from the Freezer” email after a long hiatus
This week:
- Work on $corporate_video_project
- Spend a couple hours on one of my WIP courses.
- Stream with Jess
- Write for The Wide Teams Almanac
- RubyTapas
Threat board:
- GOTO talk prep – gotta get ready for a very different format.
- Becoming revenue-positive.
- WIP.
- Fixing my house.
WIP:
No movement this week.
- Client Video Project: ~85% .
- Robust Ruby: 25%.
- MOOM: 91%
- The Rake Field Manual: 10%.
- AsyncJS Course: ~50%.
- Patreon improvements.
That’s it for this week. Thanks for reading, and as always, feel free to write back!
Cheers,
Avdi
Eric & Avdi Talk About the Developer Education Business
Eric Normand (of LispCast and PurelyFunctional.tv) and I have been trading notes about the developer education business for years. The other day we caught up and talked about business models, subscription vs. product pricing, courseware software, and a lot more. We recorded it in hopes it might be helpful to anyone else who is in, or considering jumping into, this line of work.
The Cache Flush: 008 Reconstituted sophisticated opinions
Thoughts on strong opinions and terms for complexity; some booknotes from Reactive Design Patterns and Domain-Driven Design; notes from Jessica Kerr.
A Tool for Choosing a Tech Stack
OK so I understand you think teams should stick to the tech stack they have the most familiarity with.
Yes, under most circumstances.
Riddle me this though: I have a freshly-assembled team. One dev is fresh off a Rails bootcamp. One is a veteran Java developer. One has spent most of their time with PHP and Laravel. And the last one is a Node/Express fan.