Strange Loop 2017

On October 9, 2017October 9, 2017 By Adam KeysIn Code

I was lucky enough to attend Strange Loop this year. I described the conference to friends as a gathering of minds interested in programming esoterica. The talks I attended were appropriately varied: from very academic slides to illustrated hero’s journeys, from using decomposed mushrooms to create materials to programming GPUs, from JavaScript to Ruby. Gotcha, that last one was not particularly varied.

In short, most of the language-centric conferences I’ve been to in the past were about “hey look at what I did with this library or weird corner of the language”, though the most recent Ruby/Rails conference are more varied than this. By comparison, Strange Loop was more about “I did this thing that I’m excited about and its a little brainy but not intimidating and also I’m really excited about it.”

Elm Conf 2017

I started the weekend off checking out the Elm community. I already think pretty highly of the language. I would certainly use it for a green-field project.

Size, excitement, and employment-wise, Elm is about where Ruby was when I joined the community in 2005. Lots of excited folks, a smattering of employed folks, and a good technical/social setup for growth.

A nice thing about the community is that there is no “other” that Elm is set against. Elm code often needs to interface with JavaScript to get at functionality like location or databases, so they don’t turn their nose up at it. It’s a symbiotic relationship. Further, most Elm developers are probably coming from JavaScript, so its a pretty friendly relationship. This is nice shift from the tribalism of yore.

It’s also exciting that Elm is already more diverse than Ruby was at the same point in its growth/inflection curve. Fewer dudes, more beginners, and none of the “pure Ruby” sort of condescension towards Rails and web development.

Favorite talks:

“Teaching Elm to Beginners” (no talk video), Richard Feldman. Using Elm at work requires teaching Elm to beginners. Teaching is a totally different skill set, disjoint from programming. When answering a question, introduce as few new concepts as possible. Find the most direct path to helping someone understand. It’s unimportant to be precise, include lots of details, or being entertaining when teaching. You can avoid types and still help students build a substantial Elm program.
If Coco Chanel Reviewed Elm, Tereza Sokol: Elm as seen through the lens of high and low fashion. Elm is a carefully curated, slow releasing collection of parts ala Coco Chanel. It is not the hectic variety of an H&M store.
Accessibility with Elm, Tessa Kelly: Make accessible applications by enforcing view/DOM helpers with functional encapsulation and types. Your program won’t compile if you forget an accessibility annotation. A pretty good idea!
Mogee, or how we fit Elm in a 64×64 grid”, Andrew Kuzmin: A postmortem on building games with Elm. Key insight: work on the game, not on the code or engine. Don’t frivolously polish code. Use entity-component-system modeling. Build sprite/bitmap graphics in WebGL by making one pixel out of two triangles.

The majority of the talks referenced Elm creator Evan Czaplicki’s approach to designing APIs. He is humble enough that I don’t think this will backlash like it did with DHH’s opinions did with Rails.

By far the biggest corporate footprint in the community and talks was NoRedInk. Nearly half of the talks were by someone at the company.

Most practical talks from StrangeLoop

Types for Ruby: it seems like they’ve implemented a full-blown type system for Ruby. It’s got all the gizmos and gadgets you might expect: unions, generics, gradual typing. It applies all its checks at runtime though, and they didn’t say if it does exhaustive checking, so I’m not sure how handy it would be in the way that e.g. Elm or Flow are. On my list of things to check out later.

Level up your concurrency skills with Rust. Learning Rust’s concepts for memory and concurrency safety, i.e. resources, ownerships, and lifetimes, can help you program in any language. Putting concurrency into a system is refactoring for out-of-orderness and most likely a retrofit of the underlying structure. Rust models memory like a resource, ala file handles or network sockets are modeled by the operating system. Rust resource borrowing in summary: if you can read it, no one else can write it; if you can write it, no one else can read or write it; borrows are checked at compile time so there is no runtime overhead/cost.

GPGPU programming with Metal. Your processor core has a medium sized arithmetic logic unit and a giant control unit (plus as much memory/cache as they can spare). A GPU is thousands of arithmetic logic units. Besides drawing amazing pictures, you can use all those arithmetic logic units to train/implement a neural network, do machine vision or image processing, run machine learning algorithms, and any kind of linear algebra or vector calculus. Work is sent to the GPU by loading data/state into buffers, converting math instructions to GPU code and load that into GPU buffers, and then let the GPU go wild executing it.

Seeking a better culture and organization of open source maintainership (no talk video). Projects are getting smaller, more fragmented, and attracting no community (ed. the unintended consequence of extreme modularity?) Bitcoin and Ethereum have very little backing despite the astronomical amounts of money in the ecosystem. We need a new perspective on funding open source work. Consumption of open source has won, but production of open source is still in a pretty bad place.

How to be a compiler. Knitting is programming; you can even compile between knitting description pseudo-languages. Implemented Design by Numbers, a Processing predecessor, as transpiler to SVG.

Random cool things people are really doing

Measuring and optimizing tail latency. Activating instrumentation and “slow-path” techniques on live web requests that run so long they will fall into the 99th percentile. Switch processor voltage to “power up” a processor that’s running a slow request so it will finish faster, e.g. switch a core from low power/500MHz mode to high power/2GHz mode.

Really using functional ideas of composition and state in production, consumer-facing applications (e.g. the NY Times) and using ML-style type checkers with JavaScript (e.g. Flow and Elm).

My two favorite talks by far: Making digital art with JavaScript, WebGL, vdom and immutability. Scraping/querying/aggregating image data from various space missions (e.g. Jupiter and Pluto flybys).

Facebook stopped using datacenter routers and started building their own servers that program the networking chips a router would use from CentOS, basically giving them programmable routers that deploy like you would update infrastructure like Nginx or memcached. I wonder when/if treating network devices as software will scale down to your typical large company?

Strange Loop takeaways

a conference of diverse backgrounds and experiences is a better one
my favorite talks told a hero’s journey story through illustrations
folks in this sphere of technology are taking privacy and security very seriously, but the politics of code, e.g. user safety and information war, were not particularly up there in the talks I went to (probably by self-selection)
way more people are doing machine learning applications than I’d realized; someone said off-hand that we’d “emerged from the AI winter in 2012” and that struck me as pretty accurate
everyone gets the impostor syndrome, even conference speakers and wildly successful special effects and TV personalities like Adam Savage

If you get the chance, you should go to Strange Loop!

Here’s a thing, October 05, 2017

On October 5, 2017 By Adam KeysIn Expanded ideas

As I endeavor to re-establish writing here as a regular and consistent project, I’m reminding myself of two things that helped me in the past.

First and foremost, it’s about the writing and the finished product over the page views and vanity metrics. No one’s biography or Wikipedia page says “and lo they were followed by many social media influencers and gathered many thousands of impressions!”

Second, no weblog is better than the one you already have. Resist the urge to roll your own tools and just write.

By virtue of Apple Music’s “For You” tab, I came upon the musical landscape of Tim Heckler. If wooshy, atmospheric ambient experimental/electronic music is your thing, you should check it out.

Also, you should listen to lots of Nina Simone.

exa in 30 seconds

On October 5, 2017October 4, 2017 By Adam KeysIn Code

What is it? exa is ls reimagined for modern times, in Rust. And more colorfully. It is nifty, but not life-changing. I mostly still use ls, because muscle memory is strong and its basically the only mildly friendly thing about Unix.

How do I do boring old ls things?

Spoiler alert: basically the same.

ls -a: exa -a
ls -l: exa -l
ls -lR: exa -lR

How do I do things I rarely had the gumption to do with ls?

exa -rs created: simple listing, sort files reverse by created time. Other options: name, extension, size, type, modified, accessed, created, inode
exa -hl: show a long listing with headers for each column
exa -T: recurse into directories ala tree
exa -l --git: show git metadata alongside file info

Generalization and specialization: more of column A, a little less of column B

On October 5, 2017October 1, 2017 By Adam KeysIn Code

Now, I attempt to write in the style of a tweetstorm. But about code. For my website. Not for tweets.
For a long time, we have been embracing specialization. It’s taken for granted even more than capitalism. But maybe not as much as the sun rising in the morning
From specialization comes modularization, inheritance, microservices, pizza teams, Conway’s Law, and lots of other things we sometimes consider as righteous as apple pie.
Specialization comes at a cost though. Because a specialized entity is specific, it is useless out of context. It cannot exist except for the support of other specialized things.
Interconnectedness is the unintended consequence of specialization. Little things depend on other things.
Those dependencies may prove surprising, fragile, unstable, chaotic, or create a bottleneck.
Specialization also requires some level of infrastructure to even get started. You can’t share code in a library until you have the infrastructure to import it at runtime (dynamic linking) or resolve the library’s dependencies (package managers).
The expensive open secret of microservices and disposable infrastructure is that you need a high level of operational acumen to even consider starting down the road.
You’re either going to buy this as a service, buy it as software you host, or build it yourself. Either way, you’re going to pay for this decision right in the budget.
On the flip side is generalization. The grand vision of interchangeable cogs that can work any project.
A year ago I would have thought this was as foolish as microservices. But the ecosystems and tooling are getting really good. And, JavaScript is getting good enough and continues to have the most amazing reach across platforms and devices.
A year ago I would have told you generalization is the foolish dream of the capitalist who wants to drive down his costs by treating every person as a commodity. I suspect this exists in parts of our trade, but developers are generally rare enough that finding a good one is difficult enough, let alone a good one that knows your ecosystem and domain already.
Generalization gives you a cushion when you need help a short handed team get something out the door. You can shift a generalist over to take care of the dozen detail things so the existing team can stay focused on the core, important things. Shifting a generalist over for a day doesn’t get you 8 developer hours, but it might get you 4 when you really need it.
Generalization means more people can help each other. Anyone can grab anyone else and ask to pair, for a code review, for a sanity check, etc.
When we speak of increasing our team’s bus number, we are talking about generalizing along some axis. Ecosystem generalists, domain knowledge generalists, operational generalists, etc.
On balance, I still want to make myself a T-shaped person. But, I think the top of the T is fatter than people think. Or, it’s wider than it is tall, by a factor of one or two.
Organizationally, I think we should choose what the tools and processes we use carefully so that we don’t end up where only one or two people do something. That’s creating fragility and overhead where it doesn’t yield any benefit.

The notes, October 04, 2017

On October 4, 2017October 5, 2017 By Adam KeysIn Expanded ideas, Uncategorized

I’m intrigued by folks having luck building virtualized development environments for localhost setups. It sounds like fun to work in this kind of workflow. I never want to do the legwork to make this work, though.

I did the preliminaries for this last year and ended up turning back from it. I understand Docker and virtualization superficially at best. I don’t want to impose it on teammates. It’s still too hard to search for Unix-y error messages and fix your development environment. Trying to figure out if your host Unix, Docker, or a virtualized Unix are the problem is not something I wanted to do to someone else.

Is Amazon Lightsail a move by AWS into the space occupied by Linode, Digital Ocean, etc.? Related to virtualized localhost setups: someone write me a thing to drop my dotfiles from macOS onto a Digital Ocean, AWS, etc. instance and do development from an iPad, keyboard, and SSH client.

Hammerspoon is a really cool to do all-the-things with your keyboard and some Lua. I use it to launch/switch to my most frequent dozen apps and some light Markdown helpers. But, something about it is correspondingly creepy. It can, theoretically, scoop up every keystroke. (Which probably every bit of open source I install via Homebrew could, to be honest) But maybe I could replace it with a clever bit of Alfred workflow and scripting. Catch a triggering keystroke and then give me a constrained list of apps to switch to. Yes, this is a very strange way to hit Command-Tab! I wonder how well a few custom Alfred workflows fit into a dotfiles repo.

Not-a-Science Science

On October 4, 2017October 1, 2017 By Adam KeysIn The System

Any field with the word “science” in its name is guaranteed not to be a science.

— Gerald Weinberg, An Introduction to General Systems Thinking

Afternoon notes, October 03, 2017

On October 3, 2017October 5, 2017 By Adam KeysIn Expanded ideas, Uncategorized

Someone will always have a slicker Git workflow than you. For example,Auto-squashing Git Commits for clever rebasing.

The passage of time is weird, lately. Nonetheless, it’s surprising that the Dynamo white paper is ten years old. Ten years of NoSQL hype. Even from a naive yours truly.

I’ve been using the fish shell for about five months and it is pretty great. A shell with human affordances! It has very good guesses about what I want to do (completions) and what I want it to remember (history). You can configure it with a web interface or regular-old dotfiles. It doesn’t do anything bizarrely different from your typical Unix-style shell, namely bash, so there’s not much new to learn and when I SSH to a server, I don’t wonder what kind of weird contraption I’m interacting with. I haven’t bothered to learn its scripting language because I’ve decided no one should learn those anymore and they should use Ruby, Python, Go, etc. for that kind of thing.

The loungification of luxury cars

On October 3, 2017October 1, 2017 By Adam KeysIn Cars

High-end luxury cars are starting to resemble first-class airport lounges and it’s bothering me.

The Porsche Panamera has a dang tray table. Just about every German luxury car has the option to put an LCD screen on the back of the front seats, for entertainment. Who puts $100k+ down on a car so that someone else can drive you around? The seats recline, have tablets to control their massage and scent-control functions. Of course they’re heated and ventilated.

I’m fine with cars as things that merely get you from point A to point B, and I’m fine with rich people buying extravagant cars, but I’m not okay with this airport lounge stuff. No one likes airports! They’re miserable! Stop designing things to resemble airports!

Categorizing and understanding magical code

On October 2, 2017April 7, 2018 By Adam KeysIn Code

Sometimes, programmers like to disparage “magical code”. They say magical code is causing their bugs, magical code is offensive to use, magical code is harder to understand, we should try to write “less magical” code.

“Wait, what’s magic?”, I hear you say. That’s what I’m here to talk about! (Warning: this post contains an above-average density of “air quotes”, ask your doctor if your heart is strong enough for “humorous quoting”.)

Magic is code I have yet to understand

It’s not inscrutable code. It’s not bad code. It doesn’t intentionally defy understanding, like an obfuscated code contest or code golfing.

I can start to understand why a big of code is frustratingly magical to me by categorizing it. (Hi, I’m Adam, I love categorizing things, it’s awful.)

“Mathemagical” code escapes my understanding due to its foundation in math and my lack of understanding therein. I recently read Purely Functional Data Structures, which is a great book, but the parts on proving e.g. worst-case cost for amortized operations on data structures are completely beyond my patience or confidence in math. Once Greek symbols enter the text, my brain kinda “nope!”s out.

“Metamagic” is hard to understand due to use of metaprogramming. Code that generates code inside code is a) really cool and b) a bit of a mind exploder at first. When it works, its glorious and not “magical”. When it falls short, it’s a mess of violated expectations and complaints about magic. PSA: don’t metaprogram when you can program.

“Sleight of hand” makes it harder for me to understand code because I don’t know where the control flow or logic goes. Combining inheritance and mixins when using Ruby is a good example of control flow sleight-of-hand. If a class extends Foo, includes Bar, and all three define a method do_the_thing, which one gets called (trick question: all of them, trick follow-up question: in what order!)? The Rails router is a good example of logical sleight-of-hand. If I’m wondering how root to: "some_controller/index" works and I have only the Rails sources on me, where would I start looking to find that logic? For the first few years of Rails, I’d dig around in various files before I found the trail to that answer.

“Multi-level magic schemes” is my new tongue-in-cheek way to explain a tool like tmux. It’s a wonderful tool for those of us who prefer to work in (several) shells all day. I’m terrified of when things go wrong with it, though. To multiplex several shells into one process while persisting that state across user sessions requires tmux to operate at the intersection of Unix shells, process trees, and redrawing interfaces to a terminal emulator. I understand the first two in isolation, but when you put it all together, my brain again “nope!”s out of trying to solve any problems that arise. Other multi-level magic schemes include object-relational mappers, game engines, operating system containers, and datacenter networking.

I can understand magic and so can you!

I’m writing this because I often see ineffective reactions to “magical” code. Namely, 1) identify code that is frustrating, 2) complain on Twitter or Slack, 3) there is no step 3. Getting frustrated is okay and normal! Contributing only negative energy to the situation is not.

Instead, once I find a thing frustrating, I try to step back and figure out what’s going on. How does this bit of code or tool work? Am I doing something that it recommends against or doesn’t expect? Can I get back on the “golden path” the code is built for? Can I find the code and understand what’s going on by reading it? Often some combination of these side quests puts me back on my way an out of frustration’s way.

Other times, I don’t have time for a side quest of understanding. If that’s the case, I make a mental note that “here be dragons” and try to work around it until I’m done with my main quest. Next time I come across that mental map and remember “oh, there were dragons here!”, I try to understand the situation a little better.

For example, I have a “barely tolerating” relationship with webpack. I’m glad it exists, it mostly works well, but I feel its human factors leave a lot to be desired. It took a few dives into how it works and how to configure it before I started to develop a mental model for what’s going on such that I didn’t feel like it was constantly burning me. I probably even complained about this in the confidence of friends, but for my own personal assurances, attached the caveat of “this is magical because it’s unfamiliar to me.”

Which brings me to my last caveat: all this advice works for me because I’ve been programming for quite a while. I have tons of knowledge, the kind anyone can read and the kind you have to win by experience, to draw upon. If you’re still in your first decade of programming, nearly everything will seem like magic. Worse, it’s hard to tell what’s useful magic, what’s virtuous magic, and what’s plain-old mediocre code. In that case: when you’re confronted with magic, consult me or your nearest Adam-like collaborator.