23 May 2017
I thought this presentation by Dan McKinley was really interesting and resonated heavily with my experience in helping to shepherd an organization that was pendulum swinging from everybody hacking production, to nobody getting to do releases until you filled out a form in triplicate, to an org that was doing 8–10 releases on most days.
We never got to continuous delivery (CD), for a bunch of reasons, but mostly:
- Cultural (it scares the crap out of the systems and support teams, even if it might be better for them)
- Technical (it requires good tests and good dev/beta systems, and we’ve always been underinvested in the resources to help there)
- Organizational (we’ve rarely settled into a structure that allowed our teams to develop the discipline)
But we did continually get better, and I’m guessing in another year or so, with the right people pushing, I don’t think a real CI (continuous integration)/CD pipeline is unreachable.
Some bits from the presentation that were particularly resonant with me …
Namely, we had a lot of process that was prophylactic. It was built with the intent of finding production problems before product
As your organization gets bigger (and not even, like, really big, but just bigger), there are lots of people who think their job is to protect the production org by creating all sorts of process to make it really hard to get something to production. In reality, all that process just makes people pay less attention, not more attention. There’s always somebody else who is more responsible for the code going live, being tested, being right. The further away you are from being on the hook, it’s natural that you pay less attention.
Which is why, smaller, more frequent releases, with less friction and less overhead, makes a lot of sense. It’s your responsibility to make sure you don’t break production, and if you’re going to be responsible, don’t you want to make smaller bets? That leads to this tenet …
Deploying code in smaller and smaller pieces is another way. In abstract, every single line of code you deploy has some probability of breaking the site. So if you deploy a lot of lines of code at once, you’re just going break the site.
And you stand a better chance of inspecting code for correctness the less of it there is.
There’s a lot of goodness in this presentation, resulting from the scars of helping to drag an engineering team into something that works, that has buy in, and increases the velocity and performance of the team (and helps keep everybody happy because they’re working on stuff that actually gets to production). There’s some bits towards the end of the presentation that make sense for one big team, but less sense for multiple teams. Multiple teams is a huge way to help solve this problem. If you can break up your application into smaller, separate applications, or services, or microservices, or trendy term du jour, then you can reduce your dependencies between teams.
That lets each team reduce it’s risk and some teams can ship 50 times a day, and some 10, and some 2. It increases a bit of coordination between teams, but with good documentation and smart API design (ideally with good versioning so that team releases don’t have to be coupled), you can get to a point where teams can all be really efficient and not beholden to the slowest of teams.
Anyway, it’s a long presentation, but I think it’s a really great, real world example of how to get a big challenging org into CD (or at least on the path to it).
19 May 2017
The JSON Feed format is a pragmatic syndication format, like RSS and Atom, but with one big difference: it’s JSON instead of XML.
For most developers, JSON is far easier to read and write than XML. Developers may groan at picking up an XML parser, but decoding JSON is often just a single line of code.
This is such a good, simple idea. In general, I hate dealing with XML (I actively bias against SOAP interfaces too). JSON isn’t more verbose than XML, but is decidedly easier to read, and far less fragile. I’ve added JSON feed to this very site.
08 May 2017
Really loved this little documentary on Virginia Tech softball’s no hitter over Team USA. Amazing numbers from that article:
It was the American team’s first loss in a pre-Olympic exhibition since May 3, 1996. During that span, the U.S. team outscored opponents 1,475–24.
Angela Tincher is one of VT’s greatest athletes (and she should have been pitching for Team USA …). I remember following the team intensely that season.
02 May 2017
01 May 2017
Random things that have been collecting in my brain the last few weeks:
- The last time I headed abroad, I realized AT&T had finally caught up to the competition and offered a reasonable international plan (use your data, $10/day).
- I also realized I didn’t want to waste my data on stupid things I could wait to pull over wifi, so I made it so a bunch of apps could only update over wifi (most notably, Facebook). A couple of months later, when only using Facebook over wifi, and only using it sparingly (I’m ready to be done with Facebook), I noticed I’m using about half as much cell data as I was before. Thanks, Facebook, for preloading all your shit content, and for your huge app updates.
- I traded in my hybrid for an electric Chevy Bolt. It’s been a pretty interesting experience (more on that in the future), but I did find one odd bug: plug in your iPhone (after using Carplay) before the car is turned on, and it doesn’t seem to be able to boot the Infotainment system. Unplug the phone, and life is back to normal (and then Carplay is usable again when you plug it back in).
- I’ve enjoyed listening to Crimetown, one of Gimlet’s many podcasts, but their production schedule just destroys my ability to remember what’s going on. Same goes for StartUp. Anything that’s sort of serialized just gets trounced by the seemingly random release schedule. I think the all-at-once-model (like for S-Town) is much better for stories that are serial. Or, at least be ready to release it every week. I probably should have just saved up all of Crimetown and binged it.
- I bought a Zelda-Mario Player. It’s really fun.
29 Mar 2017
The barrage of notifications for calendar invites that you’ve seen and dealt with on other devices when you unlock your phone for the first time in a while is so horribly annoying. It’s caused me to inadvertently decline invites when I’m trying to swipe the notification away.
The calendar knows I accepted the invite. Why is it giving me this blast of prompts? I think this started in iOS 10, but I hate it.
29 Mar 2017
I mean, everybody wants to make sure their ISPs can sell their data, right?
I was particularly saddened to see Rep. Massie on the list of those voting for this measure. Having worked for him (years ago), he is certainly smart enough to understand the technical implications here, but voted out of the idea that the free market was already doing a good enough job of this (i.e. Comcast won’t sell your data without your permission, for fear that you’ll leave for a competitor).
The problem is that, in great portions of this country, there’s no free market for ISPs. In most locations, it’s a local monopoly. I’m lucky: in my city, we have two cable providers, plus high speed fiber (fios). In the town I grew up in? One cable provider. And then DSL, if you live in the right spot. The house I grew up in? No DSL. No options.
Anyway, use a VPN. Most sites are using HTTPS these days, which is helpful, but your ISP will still know what name you looked up, what IP came back, and how long you were on the site. If you want to be careful, switch to an open DNS provider, and use a VPN. Most DNS providers will also use your data, but they will at least give you the option to opt-out. (As backwards as this sounds, I’d recommend Google Public DNS).
For VPN, both Cloak and TunnelBear are reasonably cheap (probably less than you pay for 1 month of internet) and easy. Or, if you’re so inclined, roll your own.
27 Mar 2017
It took about 4 months of back and forth and permitting. Two and a half days of actual work on the room. A couple of visits from a friendly inspector to make sure everything was kosher. And, finally, a 30 minute visit from a nice tech to setup the wifi.
In the end, we’ve got an array of 26 solar panels producing energy on our roof (and setup in a location that you don’t really see from the street).
Unfortunately, we’ve only had a couple of sunny days since then, but on a cold, but sunny, day in March, they produced about 40 kWh of power, which I think is more than what we’d use on a normal day. It’ll be interesting to see how we do in April and May. I’m optimistic this will have really nice returns for us.
So far the only real issue has been the monitoring software, Enlighten from Enphase. When working, it’s really nice. But, while my end is reporting pretty regularly, the website seems to go long whiles between updating. And, over the weekend, it just seemed flat out down. I’m hoping I can figure out a way to pull info from it. It looks like there’s an API, so I might be able to wire up a Homebridge plugin to pull data from it and then list usage on my HomeKit apps.
(And, no, Sun wasn’t one of Captain Planet’s people. Earth, Water, Wind, Fire, Heart. I guess maybe Fire counts?)
10 Mar 2017
Looks like Google has figured out how to use a “CAPTCHA” (those awful “what are these words”, “which ones are numbers” tests) without actually using one.
CAPTCHAs have always been a bad solution to a real problem. I’m assuming this new solution is some set of client-side/user-agent evaluation, IP reputation, and behavioral (i.e. how does the mouse move on the page). This is probably going to be a similar solution to what CloudFlare does, where they’ll let traffic through to your site automatically if they trust the reputation of your IP/browser, might delay you if they need more data, or ask you to fill in an old-school CAPTCHA if they can’t tell.
While CloudFlare got there first, Google’s reCAPTCHA is so much more widely used that it could greatly reduce how often those awful (but, often, necessary) CAPTCHAs show up.
(Via Ars Technica)
10 Mar 2017
After listening to Hrishi Hirway (and Josh Malina) on The West Wing Weekly podcast (which is just getting up to one of the best episodes in the series, so catch up now!), I finally listened to Hrishi’s other podcast, Song Exploder.
Man, it’s good.
Right now, while we’re in Peak Podcast, I’m finding myself gravitating to podcasts that are either less than 30 minutes, or are in the 45 minute range done by people that I can reasonably understand when I play the podcast at 1.5x speed.
Song Exploder is a music podcast, is almost always between 12 and 20 minutes, and is about one song per episode. There’s no continuity to worry about, so if I don’t like the song, I just skip the episode.
Frequently, though, it’s a song or band I’m already a fan of, or at least curious about. And listening to how a song gets created—either the incredible work that goes into it, layer by layer; or the random ebbs and flows of the universe—is pretty fantastic listening.
On top of that, you often hear the stems and tracks of a song as it was created. It’s pretty remarkable at times. For example, the Solange episode, where you can hear her voice isolated or the CHVRCHES episode when you hear the initial jibberish track and then the real vocal track.
Anyway. I’m late to the game, but you can catch up on this podcast over the course of a few hours, and you get to listen to some great music while doing it.