Kinda verbose, ain't it? Just speaking from my own personal experience, usually when I resort to print-debugging I'm already pretty punchy and more likely to use a quick "ASDFASD" or similar.
I worked on a codebase that had a special logging function with a name like NoPushLog that was just a direct wrapper of the base log function. A githook checked that this string was not in pushed code.
This solves many of the concerns raised in this thread about readability, automation, avoiding typos in the magic string.
The tricky thing you have to solve is how to push the code that defines the custom logging function, but there are solutions.
Because of you made a typo, you're more likely to notice than in a comment or string, because it will fail, even at build time if you're using a compiled language
Right, but the whole point of DO NOT SUBMIT is that it doesn’t need to be in the compilation step. It can be in data files, comments, etc.
You can change your syntax highlighting theme to spot the typos x (I added them with a keyboard shortcut anyways)
I use the strings "XXX" and "999" for this (the latter because you sometimes need a dummy value in a numeric context), and have a global git hook which stops me committing a changeset which includes them.
I occasionally need to override the hook, for example when using mktemp -t, or when some floating-point data actually contains a run of 9s. But mostly, it is quite specific at catching stuff that shouldn't be checked in.
I always used the word "doberman" for this purpose. I've never written code for a project that legitimately included the name of a dog variety. A simple grep for "doberman" in the production release CI pipeline catches it. If one ever did slip thru I figured it wouldn't be too offensive to anybody.
Related in terms of being easy to search for, I use the abbreviation "TK" as a placeholder for text or incomplete code. Took this from the publishing industry (my partner worked in magazines) -- it's a combination that does not appear in regular English and so is easy to both see and to use search tools for.
TK is a semi-well known widget toolkit/GUI toolkit which came from TCL and today it's the default toolkit for Python. Nothing fancy, just basic menues/buttons and widgets, but they get the job done in a hurry.
XXX is already highlighted by most editors by default (or at least mine) and seems suitable. Any comment to be committed to a shared branch should probably contain more specifics and not contain that, if you wanted to institute a policy.
It's about writing code that your peers can read. "DO NOT SUBMIT" is clear as day. "ASDFASD" probably does not mean "this is a debugging string" to most people.
Not really? it’s close to the minimum string you’d be okay with never actually wanting to commit. Never had a problem with it in logs, but it could be in a comment next to the log if you did. Easy enough to add a shortcut for if you really have a problem typing it out, but at my typing speed my brain has always been the bottleneck, not the number of characters.
[PSA] Firefox has this built in already: Hold Shift while right-clicking. Been a while since I tested on a fresh profile, but I don’t believe this requires any preference tweaking or about:config stuff.
There's a about:config setting called dom.event.contextmenu.enabled defaulting to true, when you change to false you don't need to hold shift, it will always open the browser context menu (and in most cases still do the page behavior of showing the web app context menu or whatever, you can then press esc to close the browser's menu but it may also close the page menu depending on how they implemented it).
Then there's a second option called dom.event.contextmenu.shift_suppresses_event which defaults to true and does what you said: Simple right click opens the page menu and shift + right click don't send the page the event at all and instead opens the browser's menu.
I'm right there with you. I write short and medium form articles for my personal site (link in bio, follow it or don't, the world keeps spinning either way). I will never use AI as part of this craft. If that hampers my output, or puts me at a disadvantage compared to the competition, or changes the opinion others have of me, I really don't care.
Not that long ago I was tasked with cleaning up a Git repo, created on a case-sensitive Mac, that had multiple files with names that collided when checked out on a case-insensitive Mac. That ordeal made me want to hang up my keyboard, move to the country, and spend the rest of my days fixing power lawn equipment.
yuck, I had to deal with something similar once, made double fun by the code being a hot mess of JavaScript dung... original dev was on Windows, new one was on Mac and let's just say it was "fun" tracing through all the upper/lowercase nonsense that wasn't consistent anywhere. PHP can fall into similar traps and I think Java as well...
And sometimes they rip the display cable while they’re trying to swap out the battery, and you end up with an entirely new SE2 in the end. Happened to us about 1-2 months ago.
You can absolutely scan the QR code with multiple authenticator apps (or copy paste the seed value into them) and they will all produce the same codes in the same order going forward.
I can only speak for myself, and some of the reasons why K8s has left a bad taste in my mouth:
- It can be complex depending on the third-party controllers and operators in use. If you're not anticipating how they're going to make your resources behave differently than the documentation examples suggest they will, it can be exhausting to trace down what's making them act that way.
- The cluster owners encounter forced software updates that seem to come at the most inopportune times. Yes, staying fresh and new is important, but we have other actual business goals we have to achieve at the same time and -- especially with the current cost-cutting climate -- care and feeding of K8s is never an organizational priority.
- A bunch of the controllers we relied on felt like alpha grade toy software. We went into each control plane update (see previous point) expecting some damn thing to break and require more time investment to get the cluster simply working like it was before.
- While we (cluster owners) begrudgingly updated, software teams that used the cluster absolutely did not. Countless support requests for broken deployments, which were all resolved by hand-holding the team through a Helm chart update that we advised them they'd need to do months earlier.
- It's really not cheaper than e.g. ECS, again, in my experience.
- Maybe this has/will change with time, but I really didn't see the "onboarding talent is easier because they already know it." They absolutely did not. If you're coming from a shop that used Istio/Argo and move to a Linkerd/Flux shop, congratulations, now there's a bunch to unlearn and relearn.
- K8s is the first environment where I palpably felt like we as an industry reached a point where there were so many layers and layers on top of abstractions of abstractions that it became un-debuggable in practice. This is points #1-3 coming together to manifest as weird latency spikes, scaling runaways, and oncall runbooks that were tantamount to "turn it off and back on."
Were some of these problems organizational? Almost certainly. But K8s had always been sold as this miracle technology that would relieve so many pain points that we would be better off than we had been. In my experience, it did not do that.
Truthfully, I don't know. But I suspect I'm not the only one who feels a kind of debilitating ennui about the way things have gone and how they continue to go.
Up until not long ago, you could get away with this test: "Do I, as the driver, have to stop, think, and make some choice to command the car to change some setting that governs whether or not I get across this patch of terrain?" The 'stop' step is important; certain classical 4WD shifts require the vehicle to be stationary. The automatic-ness of the AWD systems -- no pesky second shifter -- was the differentiator.
Now that we have knobs for different "driving modes," the the ability to slam it into whatever position whenever we want while an ECU figures out how to keep a gearbox from exploding, it's genuinely hard. Still, the presentation of a setting like "lock/unlock" and "two/four" and "high/low" is the standard I still go by (right or wrong).
Kinda verbose, ain't it? Just speaking from my own personal experience, usually when I resort to print-debugging I'm already pretty punchy and more likely to use a quick "ASDFASD" or similar.
reply