By any scientific metric, the risk of COVID-19 infection is greater than it’s ever been, while mitigation efforts have regressed to a shrugging emoji. Being offered an alcohol wipe by a smiling, unmasked flight attendant before spending hours breathing other people’s air in a narrow metal tube is panglossian, to say the least.
After using certain Websites, my question is no longer "should designers learn to code" but "do developers know how to code"
— Pavel A. Samsonov (@PavelASamsonov) August 8, 2021 I could have picked a million other tweets to pivot off of, but I’m choosing this one because it’s the one I saw most recently. I wrote a post a little while ago about how SRE is really just sneaky anarchism, and this is somewhat of a followup.
Consider this an open letter.
A lot of people will tell you that a “developer advocate” is a lot of different things. Teacher, tutor, comedian, mediator, marketer, support person, and more. None of those are wrong, per se. I don’t see it that way, however, as a matter of course. Developer advocates, and indeed, the entire field of developer relations, in my mind is about celebrity. Why wouldn’t it be? The only metric we have that matters is, indeed, noteworthiness.
The Legend of Zelda: Breath of the Wild is Nintendo’s most recent main-line game in the long-running Legend of Zelda series, launched on the Nintendo Entertainment System in 1986. To say that it’s a departure from the norm for the series is somewhat of an understatement – in lieu of a crafted series of puzzle dungeons that require specific tools, techniques, and resources presented in a fairly linear fashion, it instead offers an open world after a short introductory section, allowing for massive amounts of freedom and flexibility in exactly how players choose to engage with the game. As you may expect, this has lead to several unintended side-effects.
“We are uncovering better ways of developing
software by doing it and helping others do it.”
The Agile Manifesto, 2001.
It’s been quipped more than once that most amazing Silicon Valley innovations are simply a bunch of nerds poorly recreating a service that already exists, but with an app. While I find this to be in some ways a truism (after all, there is nothing new under the sun), it’s a fairly trite observation. What’s far more interesting is how the organizations that build and deliver these ‘innovations’ themselves develop, and the process of that development is especially interesting due to the pressure-cooker of free money and labor elasticity that has characterized the ‘startup economy’ over the past twenty years or so. What’s any of this have to do with DevOps, you may ask? Simply this – DevOps is a reaction to the commodification of Agile, and the rise of SRE is a reaction to the commodification of DevOps. To reduce the thesis further, many of the trends you see in software development and delivery can be understood as a cyclical reaction to anarchists running headlong into the invisible backhand of the free market.
We’re often told that age brings wisdom, but I’ve often found that to be bullshit. The wisdom of age mostly appears to consist of submission to the inorexable weight of the world pressing on your spine until it snaps like a twig. Indeed, this wisdom asks us to make a simple bargain with the devil - evaluate the unknowable and infinite possibility of now arrayed against the volumes of human history and experience, and find that the now will always pale in comparison to the then.
In my experience, it’s the ideas that you don’t expect to work that really take off. When I registered a domain name a month ago for Deserted Island DevOps, I can say pretty confidently that I didn’t expect it to turn into an event with over 8500 viewers. Now that we’re on the other side of it, I figured I should write the story about how it came to be, how I produced it, and talk about some things that went well and some things we could have done better.
You might have heard about observability and wondered what’s up with it – it’s a pretty complex topic! I helped put together a guide to it over at LightStep - be sure to check it out! Here’s the overview.
Preface - I really like what Microsoft is doing with .NET Core and ASP.NET Core.
However, the horror they’ve unleashed upon the world in the form of ASP.NET MVC and WebAPI is a sin that will take more than a few moons to wash away. That said, quite a few people are still building software using this stuff and I got curious how you’d do instrumentation of it via OpenTracing. This post is the result of several hours of hacking towards that end.
It’s never been a better time to write cross-platform .NET, that’s for sure. I’m 100% MacOS using Rider and Visual Studio Code these days, and things work generally pretty OK. Obviously you’re going to run into trouble if you’re trying to touch any Windows-specific frameworks or libraries, but for the sort of backend and instrumentation focused code I’m writing these days, it’s not that big of a problem.
However, there’s still some rough edges when it comes to running cross-platform projects in a CI system, especially if you’re using something that doesn’t have prebaked images.
Do you use RethinkDB? Do you have a cluster set up? Do you want to stop crushing a random cluster node with database connections? Do you wish someone had written some simple steps on “Hey, how can I set up an ELB on AWS to load balance my client connections to my RethinkDB cluster”? Wonder no more!
Setting up a load balancer for your Rethink cluster is pretty straightforward - here’s how to set it up on Amazon Web Services.
Hey, I’m Austin. I’m a human on the internet, and I blog about software, devops, and some other stuff.
This is my Twitter account.
This is my GitHub.
This site runs using Hugo with a modified version of the Hyde theme.
Jira - love it, hate it, begrudgingly accept it - it’s a fact of life for many of us in the software world. One thing that particularly sucks about Jira to me is that there appears to be an eternal tension regarding process.
You’ve probably got a boatload of various processes that you’d like to be somewhat repeatable and easy to discover. In my career, I’ve seen these processes be documented in a variety of places.
Since I joined the Apprenda team, the ritual of daily R&D team standups have been a pretty constant companion. Being able to to get a ten-thousand foot view of our progress helps keep everyone on the same page, even as our team has grown over the years. One of the rituals of our morning standups has been the deployment report, where we’re updated on how nightly tests and deployments of the Apprenda Cloud Platform have fared.
