TheJach.com

Jach's personal blog

(Largely containing a mind-dump to myselves: past, present, and future)
Current favorite quote: "Supposedly smart people are weirdly ignorant of Bayes' Rule." William B Vogt, 2010

Technical Debt is just messiness

It's the time of year for people to share their reframings of technical debt.

Yossi Kreinin has two takes I like, from https://twitter.com/YossiKreinin/status/1431748651571896320 and https://twitter.com/YossiKreinin/status/1341741855214546949 respectively.

Much of "technical debt" isn't - it wasn't done to ship quickly at the cost of more work in the future. It was just a shitty job that you're now stuck with, that never helped ship anything quickly. If programmers were plumbers, we'd spill shit all over your room & call it "debt"

See Full Post and Comments

Fixed an embarrassing security bug...

Earlier tonight I started getting some error emails as a result of some requests from 5.188.62.214 who started POSTing to /admin/post/new, which as revealed in my notes is the URL this blog uses when I submit a new post. I knew I had to deal with this immediately because the error message was PHP aborting because of an undefined index in a map -- the bot using that IP wasn't sending the expected new post form parameters.

This is odd to me since the HTML form is part of the response payload and all the needed inputs are in there, including one that the bot did send. That one ended up being the only type="hidden" one, too, which makes it more bizarre. It reminds me of some people filtering requests from dumb bots by setting a hidden input and then setting it to something else with JS, or unsetting it, and catching bots that aren't JS-aware. Apparently many still aren't. The bot also sent some parameters from other forms on the page, like the hidden sitesearch param for the google search box, and the pw param for the login form, with guesses as brilliant as 123456, admin, admin123, and gw44444 (what's that from? too many 4s...) -- with variants gw111111 and gw66666666.

But all that's beside the point, because what is an unauthenticated request doing getting this far into the handler of an admin page, which is supposed to be restricted to admin users (i.e. me)? And after a bit of investigation I found to my horror that a plain curl on that URL would serve the form...

See Full Post and Comments

What is customer trust?

My last job often championed "trust" as its number one value, though sometimes it was a bit nebulous about what was meant by it. Having not worked there for over a year, even I have started to forget what exactly is meant by it. But thinking about it again, it's actually really simple, and the company says as much in various places if you look.

Trust is simply whether people trust you or not, and maybe how much. Trust you with what? With anything they possibly could. If you're a business, and you want trust, you typically want to be trusted to do the right thing, to have a product that does something useful in a good way and in line with customer expectations, to be upfront and honest and transparent about your mistakes instead of burying them (and try hard not to make mistakes). This trust extends beyond your customers and includes your employees, too. Part of why I left was a loss of trust between myself and the company -- so many pieces of information were learned via public news instead of an internal announcement, for instance. Trust, once broken, is really hard to re-establish.

Another thing about trust is that what people do or do not trust you in changes from person to person, which is why it can be a bit nebulous. Is it reasonable for me, a simple IC, to expect that the details of firing a security pair moments after giving a talk at Defcon would be provided in news articles and public forums and totally ignored internally and talked around when brought up in a company all-hands? Maybe, maybe not, but that was an early loss-of-trust moment for me, and even a rage-quit-in-solidarity moment if I was part of the security team.

See Full Post and Comments

It's hard to write with no audience

This blog has long been for my own benefit, and that's not really about to change soon... but I'm also reflecting a bit on why I started blogging in the first place. Part of it was a desire to become better at writing.

But, like I tried to say in my last post about programming, just doing a lot of something doesn't necessarily make you better at it. I still have this idea that when I've written one million words on this blog, I'll "archive" everything so links still work but otherwise fundamentally redesign the site so that it's just a categorized collection of stuff, like Gwern's site, and maybe some old stuff can be salvaged or lightly rewritten as "best hits". I'm currently at only ~400k words, though.

But if you include my Hacker News comments, plus my private journal, I'm at ~900k words! So surely I've long passed the "million words" point as far as lifetime output is concerned. So as far as redesigning this blog goes, part of it's just laziness. Besides, I'm not looking for a job right now, so I don't need to be overly concerned about easy-to-find cringe (which this blog is full of).

See Full Post and Comments

An interesting question

From this, which I didn't find interesting overall, I still found interesting for the question it asks at the start: "what are some things that you used to strongly believe but have now changed your mind about?" This is mainly in the context of coding, though it can be fun to answer that question for other things too.

First I'll touch on the areas that post touches on, then highlight a few others that are even more minor changes. You might want to skim that post first.

First, on Everyone is doing it wrong.

See Full Post and Comments

Sephira Su Archives



It's been many months since セフィラ・スゥ retired, but she's not forgotten. This is a good time to re-post some archives that fans have made, and hopefully boost future searchability...

The video above links to this archive which is mostly complete, it's missing member videos. On youtube there's a mostly-complete archive channel here, with videos hidden in playlists, and a playlist of off-channel collabs here. Lastly, there's a complete archive + non-video stuff available as a torrent, here (magnet). There are a few seeds, but if no one is seeding leave a comment here and I'll get a notification.

See Full Post and Comments

Reasons I dislike semver

  • If the MAJOR changes, you know something intentionally broke, but you don't know what
  • You can figure out what broke by seeing your own code break, or perhaps ahead of time by reading the release notes.
    • Frequently in practice there are no useful release notes about the breakage, though. If they're following semver strictly, you can maybe find details in documentation, and review changes to documentation when there are no useful release notes. You could also step through all the commits -- but we're trying to avoid that effort, no?
  • This leads to interpreting a version number as maybe-care.don't-care.don't-care
  • And so the only possible benefit is increased laziness by ignoring the don't-cares, because the intent is that you can upgrade freely until the MAJOR changes
    • But this laziness is bad, and in practice doesn't turn out so nicely, because changing the MAJOR only captures intentional breaking changes, and not the very common unintentional breaking changes
    • That is, if your goal is just to prevent breaking, intentional or not, you can't even trust a PATCH change, because bugs happen
    • Plus, you might actually care about the smaller bug fixes and new features! You should really spend effort to see what changed and consider updating, when there's an update. It might even be critical to your program's security. Sorry, you can't be lazy without consequence.
    • Additionally semver makes no requirements on granularity. Change one thing that breaks? Update the MAJOR. Change many things completely (version 2.0 baby!) in a way that requires most everyone to do a rewrite? Update the MAJOR. Which one of those is this update? You have to look to find out.
    • Not everyone uses semver, and nor will they ever thankfully, but this means you can't be lazy for everything. Because of scale, it's less effort to be consistent with how you handle updates for all your dependencies, rather than dividing processes and trying to be lazier for semver'd libraries.
    • So even with some semver, you need to have automated builds and tests at a minimum, this lets you try every new version regardless of whether the MAJOR changed or not, regardless if the library is semver'd or not, and see if it breaks you in a way you can easily detect
  • In practice, when breaking changes happen, the response of the project is one of three not very helpful options, the second being the best but you still experienced breakage
    1. It was intentional, revert or deal with it
    2. It was unintentional, revert or wait until we push a new patch to restore behavior
    3. It was unintentional, but we like it, so we'll bump the MAJOR and re-release, revert or deal with it
  • If it does break, most people don't care whether that break was intentional or not, they're mad that they need to work around it. Those three responses aren't helpful.

Summarizing: I find semver useless (it saves no effort or frustration in practice) and even harmful (it condones making breaking changes without recognizing that people don't like breakages, intentional or not), and so is not worth standardizing on.

The better thing to do as a library author is to not break APIs! When you have this attitude it's very possible to have non-breaking APIs for a long time, much like when you embrace an immutable-by-default language you learn that you don't need as much mutation as you thought.

One way to do it is to maintain multiple versions of your API within the same program, and support all versions indefinitely. It's not as bad as it sounds, and in many cases might just mean exporting a "myFunc2" and updating documentation that users should really use that one. You can even add instrumentation to discover usage, and consider removing if you find no one really is using the disfavored entry point, but it's better to just not break things ever.

See Full Post and Comments