Draconian Overlord - Latest Comments

Re: Avoid Using External Files in Tests

shaberman — Tue, 04 Jul 2023 14:26:58 -0000

Hi Jay; I only just now noticed your comment, sorry about that! Not sure if I'm getting notifications for these comments or not... :-/ But thanks for the note, I just fixed the link.

Re: Avoid Using External Files in Tests

Jay — Wed, 10 Aug 2022 12:46:36 -0000

Broken link on:

And, granted, cross-system integration testing sucks

Re: First Principles

Jesse — Thu, 13 Jan 2022 18:58:57 -0000

Did you remove the first principles page? I had it bookmarked and just noticed it now returns a 404.

Re: If you cherry pick, your branch model is wrong

ZillaYT . — Fri, 11 Dec 2020 12:44:28 -0000

Where is the rebase before the merge? The picture looks simple for just the 1 commit, but if there are several hotfixes, the picture can be murky.

Re: First Principles

shaberman — Sun, 30 Aug 2020 19:09:32 -0000

"Where it feels right." :-)

Less tongue-in-cheek, I think the 80/20 principle is probably good, i.e. shoot for ~80% "perfect SOLID" and you'll get the most benefit, without being overly pedantic about the last 20% that returns less marginal utility.

Re: Why I’m a Static Typing Bigot

Adam — Sun, 30 Aug 2020 11:04:28 -0000

Another really good post from years ago. I mostly write ruby at the moment and I have very mixed feelings. I'm pretty certain you're right that for larger projects static typing is increasingly valuable. In terms of "most users of dynamic languages would, without realizing it, prefer a static language" I think that could be the case for overall experience at work. I don't have enough static experience to know for certain but when writing Go I enjoy so many of the benefits you mention and perhaps using a language with generics I'd even say I like it better at work than ruby overall.

There is a big stumbling block though: Joy. The greatest times spent programming, the ones spent hacking out an idea in a state of flow work well with having the minimum possible ceremony. Once I would begin a tricky task by writing out in english what the steps need to be, then it would turn to pseudocode, then I realise it's easier for me to just write ruby. When I alter my ideas of what needs passing where the changes are quicker to make. Bang, POC done in an hour. This shouldn't be pushed directly to production but honestly a little polish and some tests and often it's great. This isn't the how the majority of time at work is spent and I also get a kick out of careful code design plan coming together but those times are very sweet, they are the times when it most feels like a company is paying me to play.

Re: First Principles

Adam — Sun, 30 Aug 2020 09:35:20 -0000

This is a really damn good list. Out of interest, on a scale from the whole program is in one massive function through to 100% exam grade SOLID, where do you like to draw the line for abstraction?

Re: Always Separate User Intent

Joan Gamell — Mon, 30 Mar 2020 01:54:04 -0000

Nice insight! https://media0.giphy.com/me...

Re: GraphQL Typed Root Pattern

lookfirst — Mon, 13 Jan 2020 00:05:55 -0000

https://github.com/MichalLy...

Re: Toyota Katas Notes

shaberman — Sat, 03 Aug 2019 16:18:13 -0000

Yep, agreed. Two thoughts:

1) I'm also rereading Flow (The Principles of Product Development Flow), which is not really "port TPS to software" but "here is why [with lots of ~somewhat dry theroetical reasoning] TPS doesn't apply to software and what to do instead". I'll do a similar notes blog post if anything for my own synthesis and memory. But, yep, you've already hit on several of the key aspects (get rid of queues, short/fast iteration, less design-in-progress, etc.)

2) I'm also wondering about just removing queues all together (if/when possible). Like within engineering, we often have "the mobile engineer queue", "the frontend engineer queue", "the backend engineer queue", etc, each of which take turns being bottlenecks depending on the project/task/etc.

At my current gig, I'm on a "TypeScript everywhere!" kick (although I can't win the React Native battle yet :-)) primarily b/c I think having a common language enables breaking down some of these artificially-introduced queues and letting generalist engineers more freely flow to where the current work needs to be done (albeit probably still facilitated by platform specialists/owners who know the nitty-gritty details of each platform, like maybe an 80/20 ratio of generalists/fullstack to specialists).

Re: Toyota Katas Notes

Joan Gamell — Fri, 02 Aug 2019 10:50:29 -0000

The same part, on the same machine, multiple times per minute, for days and weeks. It’s just nothing like software development.

I think the "applicability" of these techniques to Software Development lays one layer above the actual writing of the code in the Software Development Life Cycle, i.e. in how all the actors and processes interact during the weeks-long or months-long building of a feature.

Thinking specifically of shortening the feedback loops between QA / Product / Engineering and short iterations (no inventory) , small deployments to production to de-risk, fixing-forward or fast-rollbacks, pushing the responsibility closer to whoever has the best knowledge (anyone can pull the red cord), etc. Those are mostly Continuous Development/Deployment practices which I think can be traced back to the Toyota

Re: What’s Wrong with a Schema?

Johann Eloff — Fri, 21 Jun 2019 23:52:43 -0000

There is no natural system that enforces a schema, universe would be chaos then, so why make an artificial one. Been running for more than 5 years in production with billions of records across multiple documents without schemas and never had 1 day of issues or downtime with it. Sorry but schemas are just here so that the structural minded old school paradigms don't get too lost in a dynamic world

Re: If you cherry pick, your branch model is wrong

moomistercowman — Mon, 22 Apr 2019 17:47:11 -0000

you're supposed to rebase *before* pushing to a public repo

Re: If you cherry pick, your branch model is wrong

Optimistic Owl — Mon, 15 Apr 2019 05:43:37 -0000

Rebasing public branches make me squirm. Wont the other devs now have to force pull because the dev branch history has diverged?

Re: If you cherry pick, your branch model is wrong

adam.conway — Thu, 14 Mar 2019 12:36:50 -0000

The point of cherry-pick is when you want a commit without _earlier_ commits from the develop branch. For the case you are describing you can rebase. it's not the case the article is talking about though

Re: Gmail Filter Tips

thehesiod — Thu, 17 Jan 2019 20:28:47 -0000

it appears editing filters no longer changes the order, at least on my gsuite account

Re: The One True Way Of Indentation

martinerburu — Thu, 03 Jan 2019 23:49:04 -0000

fabriciocucci already read

Re: Why No One Uses Scala's Structural Typing

Alex Mills — Fri, 21 Dec 2018 00:21:00 -0000

not necessarily, could be done at compile time, dunno

Re: The One True Way Of Indentation

D Draco — Mon, 10 Dec 2018 14:34:01 -0000

While I certainly think wrap-all is a good idea, I disagree quite strongly with your reasoning for always-indent-by-one. Here's why:

If "wasted" whitespace were really a significant downside, you wouldn't be advocating wrap-all without making any mention of it there. It's an irrelevance: if you're short enough on horizontal space that single arguments are crossing your line-length limit, which is the only time it should matter, then you're either nesting too deeply or using names that are too long, and a refactor is needed.

If you're changing your function or method names on a frequent enough basis for that to matter, you're probably doing something wrong - and if your tools don't "know" how to ignore whitespace changes in a diff, you need better tools, not to break useful semantic formatting so that you don't have to deal with them.

Your final "advantage" for indent-by-one is, frankly, nonsense. If you align arguments with their caller ("indent-on-column", as you call it), you always have to move your eye directly down from the method name, which you have to read *anyway* to know what the call *iss*. If, on the other hand, you indent by one (or two) then you have to scan *back* by an arbitrary amount, varying depending on the name of the method and, as in your second example, potentially an object with which it's associated.

Meanwhile, "indent-on-column" usefully aligns arguments and data with their associated structures, in a way that's immediately and obviously distinct from an extra indent-level as used for *code*.

Re: If you cherry pick, your branch model is wrong

Rick O'Shea — Sun, 21 Oct 2018 14:53:48 -0000

I agree with the premise of this article and looking forward to the next installment: "If you are manually copying edits from one branch to another in your text editor your branch model is wrong". This is the first I've heard of anybody using cherry-pick for anything other than selectively merging commits from another branch now and then, and it's absolutely invaluable for that.

Re: Why I’m a Static Typing Bigot

shaberman — Thu, 27 Sep 2018 16:06:13 -0000

LA LA LA LA. :-)

Re: Why I’m a Static Typing Bigot

Chad Crowe — Mon, 24 Sep 2018 12:06:36 -0000

You should ask Ian about the results of his thesis on static vs dynamic types.

Re: If you cherry pick, your branch model is wrong

Benjamin Vinicky — Wed, 19 Sep 2018 14:53:00 -0000

There is another solution to this:

>So you now have two physically distinct commits in your repository for the same logical change. And no metadata tying them together.

Take a look into the -x option when cherry-picking. It's not the most beautiful solution, but it adds the SHA-1 of the original commit to your new commit's message. [ (cherry picked from commit 1234abcd...) ]

If you want to locate the branch you could always just $ git branch --contains <sha-1>

Re: If you cherry pick, your branch model is wrong

Benjamin Vinicky — Wed, 19 Sep 2018 14:47:17 -0000

Thank you for this reply. This method really is the way to go when you have to use a cherry-pick!

Re: If you cherry pick, your branch model is wrong

Benjamin Vinicky — Wed, 19 Sep 2018 14:35:31 -0000

Common misconception... Git rebase does not break chronology. Each commit contains the author and commit date. You just have to look a little harder. If you don't feel like viewing the commit date for a commit, you could always --ignore-date, though you will lose the original author date.