Life online, one post at a time
Dustin's avatar

Dustin Boston is a developer at NASA Jet Propulsion Laboratory and lives in Pasadena, CA. Web developer, internet defender, writer, and open source advocate.
About | Github

Watched Sense8 season 2 finale (good), Primer (ok), Marjorie Prime (ok), and Valerian and the City of a Thousand Planets (ok). I think maybe I’m getting hard to please in the sci-fi department.

Go vegan, save the earth

By on

I’ve written about the ethics of going vegan but this article on The Guardian gets at the environmental impact of the vegan lifestyle.

…according to the scientists behind the most comprehensive analysis to date of the damage farming does to the planet…a vegan diet is probably the single biggest way to reduce your impact on planet Earth, not just greenhouse gases, but global acidification, eutrophication, land use and water use

There are some really interesting findings here. For example, the ratio of calories and protein to farmland usage:

…analysis shows that while meat and dairy provide just 18% of calories and 37% of protein, it uses the vast majority – 83% – of farmland and produces 60% of agriculture’s greenhouse gas emissions.

That’s nuts! And speaking of nuts, they only produce 2.5kg of greenhouse gasses per 100g, while beef ends up in about 105kg. Shit! Literally!

Learning a programming language

The best way to learn a new programming langage is to get hand-on, and get in the zone. It's also the most fun.

By on

In the paper Teaching Programming Languages by Experimental and Adversarial Thinking, an approach to teaching programming languages is outlined that reflects a more natural approach to learning:

…a programming language is less a purely mathematical object and more like an object found in nature. In addition to any formal interfaces it may present, we should – and do – also view it as a target for experimentation. We subject it to a variety of tests. Most of all, we follow a loose version of the scientific method: we form a hypothesis about the language’s behavior; we construct tests (example programs and their expected outputs) consistent with the hypothesis; if the tests pass, we reinforce the hypothesis, otherwise we find it falsified; we use the falsification to generate a new hypothesis, which results in new tests. When we have exhausted our ability (or energy) to falsify, we accept our hypothesis as a tentative truth about the language, and use it to construct actual programs (whose behavior may – after painful debugging sessions – again falsify our understanding).

Basically, we learn a new programming language best by just jumping in and trying stuff.

This is super validating because it often feels like The Right Way to learn is a task list of the most boring words you have ever heard, including but not limited to:1 data types, variables, expressions, operators, classes, inheritance, structs, interfaces, enums, events, enumeration, standard libs, special language features, concurrency, I/O, networking, serialization, and on and on. I just fell asleep writing that.

The better way, in this case, is also the most fun: copy/paste something that looks interesting to you; change some stuff around; when something doesn’t work out, head over to Stack Overflow, check out the documenation, or ask questions on the language’s public chat; then change some more stuff and do it all again.


To learn a skill efficiently you need to get in the zone with some deep, deliberate “practice.”

The Importance of Deep Work & The 30-Hour Method for Learning a New Skill takes an interesting approach—divide your learning into seven or eight, four hour blocks of learning over the course of a few weeks and dive deep.

I like this informal structure because it gives you some bare-bones guidelines for what you need: time to get into the flow, some consistency to build up some working knowledge, and a timeframe for which you can expect to have a basic understanding of the subject matter.

The article gives a sample of how you might break it down. Something specific to learning a programming language might look something more like this:[^rusty]

  • Session 1: Read some posts about the language, watch some videos, etc.
  • Session 2: Install the language, go through the Getting Started
  • Session 3: Do a small project, something you are interested in
  • Session 4: Start a larger, more advanced project that will stretch you
  • Session 5: Wrap-up the larger project from Session 4
  • Session 6: Pick up a book, skim it, refactor based on your learning
  • Session 7: Implement more advanced functionality, or start a new project

But I think it’s important not to systematize this too much. If it’s not fun, it won’t get done.2


Anecdotally, I have been using a loose version of this to learn Rust, and it has been a breeze. It feels like all the pressure and drudgery of learning a new language has been replaced with fun and excitement, which I think is exactly what one would want.


  1. If you remember the Micro Machines commercials, read this in that voice [return]
  2. I just made that up right now and I think it’s pretty clever3 [return]
  3. But I’m sure it’s already been said by a million moms and teachers around the world [return]

Innovation thrives in broad networks

By on

In Where Good Ideas Come From, Steven Johnson points out that the most innovative people have broad social networks:

What Ruef discovered was a ringing endorsement of the coffeehouse model of social networking: the most creative individuals in Ruef’s survey consistently had broad social networks that extended outside their organization and involved people from diverse fields of expertise. Diverse, horizontal social networks, in Ruef’s analysis, were three times more innovative than uniform, vertical networks. In groups united by shared values and long-term familiarity, conformity and convention tended to dampen any potential creative sparks. The limited reach of the network meant that interesting concepts from the outside rarely entered the entrepreneur’s consciousness. But the entrepreneurs who built bridges outside their “islands,” as Ruef called them, were able to borrow or co-opt new ideas from these external environments and put them to use in a new context.

A large, open network is the best predictor of success

By on

The No. 1 Predictor Of Career Success According To Network Science:

The bottom line? According to multiple, peer-reviewed studies, simply being in an open network instead of a closed one is the best predictor of career success.

Festivals are run by conglomerates

By on

Music festivals are the corporate dystopia we deserve:

It was also in ‘99 that Coachella began. Heralded as the “anti-Woodstock 99”, it was formed as an indie alternative to a touring circuit dominated by Ticketmaster. Only 25,000 people attended, and the promoters took a huge loss. Five years later, it swelled to a sellout crowd of 110,000 and was purchased by a conglomerate called AEG Live, which owns several major arenas. Coachella could now afford to book much bigger names, at the expense of its independent spirit.

Over the next decade, festivals boomed, from Bonnaroo to Sasquatch to Lollapalooza. Live Nation, another conglomerate, now owns all of these and more, over 60 festivals in total. Consolidation has led to standardization. Instead of local flair and flavor, festivals from coast to coast now have similar line-ups and sponsors. To maximize profit and minimize risk, security grows ever tighter.

It seems like corporations somehow get their hands on everything eventually.

No DACA, no bueno

By on

Caltech and a bunch of other prestigious universities filed an amicus curiae with the US Court of Appeals, which makes a powerful statement about DACA:

Indeed, ending DACA forces future scholars, innovators, and leaders to choose between withdrawing to the margins of our society and national economy or returning to countries that they have never called home. Whatever they choose, their gifts and education are lost to this nation.

Going gray(scale)

I recently switched my phone into grayscale mode in an effort to reduce the compulsive desire to check it throughout the day. So far, it's working.

By on

Within the first 10 minutes of the first class of the first semester of tech school, my professor said something to my class that I will never forget:

Unchecked technology is ultimately dehumanizing.

Boy is that ever true now. From political hacking1, to doxxing2, humans have found a way to make technology do the worst things possible.

One particularly insidious form of this grew up within the context of our present day “attention economy”—our phones. Now, it’s not that our phones are bad, it’s just that they are designed to keep our attention.

According to Dr. Thomas Ramsoy3, an expert in Neuroscience and a critic of “Neuromarketing” practices common today, one trick used to keep us glued to our phones is color. It can be used to induce “subconcious decisions.” Ever wonder why the notification badges on your phone are red? It’s because they draw your attention.

Tristan Harris, who used to work at Google as their Design Ethicist equates this phone douchbaggery to a slot machine.4 When you pick up your phone you’re pulling the handle. If you get a text message you win, if you get nothing you lose, but the dopamine hit is enough to keep you coming back.

And that’s how the entire world got a legitimate phone addiction.


The Center for Human Technology (Harris’ new gig) has a list of tips for combatting phone addiction. One novel idea is to put your phone in grayscale mode. This basically disables mind-control.

For the last week I have “gone gray”, disabled all notifications except for text-messages, and removed all social media from my phone5, and I can tell you that it reduced my compulsive behavior by at least 80%.

So I don’t know if I’m cured, or even if I want to be cured but I definitely feel more in control of my phone than I have in some time. And that’s the point isn’t it? To put tech in check. Hey I like the sound of that.

Rsync Deployment with GitLab CI/CD

By on

I had a thought about blogging while cruising Adactio: if it takes more than 30 seconds to make a finished post live, it’s probably not going to get published. I have this problem.

After I write something, I build my site with Hugo, and then rsync it up to the server. But there’s no reason for me to do that manually anymore since it can be automated with GitLab. Using SSH keys with GitLab CI/CD and CI rsync Deployment had everything I needed to get it done.

How to Meditate

This is a simple ten minute mediation that I learned from Headspace. It focuses on breathing and mindfulness. There are other types of meditation exercises that you can do too, but this is the one I use every day.

By on
  1. With eyes open, take deep, audible breaths. In from the nose out through the mouth. 30 seconds.
  2. Gently closing the eyes, listen to the sounds around you, feel your feet on the floor, hands on your lap.
  3. Quickly scan your body from head to feet and back up. Note how the body feels but don’t dwell on it.
  4. Briefly remind yourself of why you are doing this.
  5. Locate your diaphragm. Feel it rise and fall for a few moments, without changing your breathing patterns. Just observe.
  6. Continuing to observe, begin to count your breaths. Inhale 1, exhale 2, inhale 3, etc. Up to a count of 10, then start again.
  7. After several minutes, allow your mind to be free and do whatever it wants. 30 seconds.
  8. Reconnect with your surroundings, sounds and sensations. Gently open your eyes.
  9. Reflect on how it feels to have taken time to yourself
  10. Consider what you will do next, and smoothly transition into that. Bringing your sense of calm with you.