Put the knife down and take a green herb, dude.
One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com
Using 89% of the same design the blog had in 2001.
FOR ENTERTAINMENT PURPOSES ONLY!!!
Back-up your data and, when you bike, always wear white.
As an Amazon Associate, I earn from qualifying purchases. Affiliate links in green.
MarkUpDown is the best Markdown editor for professionals on Windows 10.
It includes two-pane live preview, in-app uploads to imgur for image hosting, and MultiMarkdown table support.
Features you won't find anywhere else include...
You've wasted more than $15 of your time looking for a great Markdown editor.
Stop looking. MarkUpDown is the app you're looking for.
|Friday, July 09, 2021|
You should not have a giant, monolithic application. Monolithic codebases are the mind-killers. They are the little-deaths that bring total obliteration.
Face your monolith. Allow it to pass over you and through you...
... into a well-modularized codebase.
But here's the corollary nobody links to this practice:
The best modularization requires smart denormalization and repetition.
You catch some of this when you hear about microservices, which hold down the other end of the spectrum from monoliths. I think it's largely because of their association with NoSQL, where being comfortable with denormalizing schemas is absolutely essential.
I don't want to get too deep into NoSQL right now, but the concept is the same: To be most nimble in a modularized codebase requires that you -- and it's nearly against my programming north star to admit it -- Repeat Yourself.
And that's okay. If you have one service that calls another, and you need to massage your payload, you may have to change it two places, the caller and the server.
THIS IS FINE, NO MEME-MIC DOG & FIRE SHOW REQUIRED.
Because you know what's worse than changing a model two places? Changing it three places.
Those last two are too often nontrivial. Perhaps they should be trivial, but in practice they almost never are. There's always some argument that 1. requires a breaking change to the shared library, which requires we up its major version, and 2. & 3. are set to update automatically on minor changes, but not major changes, and now we have to redeploy in just the right order so that the other apps that depend on the library in 1. aren't brought down when we... I see you over there. You get it. This has happened to you too.
What were we hoping to save ourselves from again? Exactly this sort of tedium. Except now it's even worse than it was before in the monolith!
Look, you should be coding the caller and server defensively anyhow, as independent services. The payloads for both, once serialized, are probably coming across the wire as XML or JSON (please JSON) anyhow, so it's not like these model abstractions are necessary beasts. Why do we have to point them both to the same library to have a source of truth? We're comfortable consuming third party apps without sharing model definitions, and that's [at least partially] the setup you chose when you went to modular services.
Treat each app as an independent development and change the model twice -- or, when appropriate, add a new model to one with a new API endpoint to maintain backwards compatibility with other consumers. Denormalization between apps at the point of the interface is a-ok.
I'm requesting foo. You're sending foo. Having two copies of foo, one for me and one for you, is fine. Even having a slightly different foo for each is often fine as long as the middle of the Venn is what the transaction in question is worried about.
No, for real. It's okay. Really. You'll thank me later.
posted by ruffin at 7/09/2021 05:03:00 PM
|Tuesday, June 15, 2021|
Why don't we just use XMLHttpRequest? Then our services, which are often fairly UI-templating-agnostic already, can live anywhere we want.
There are at least two good reasons... The first is to handle JSONP. I'm ignoring that for now.
The second is to handle async code in a manner that's conventional for each templating engine.
For the most part, however, you can pass the data event back into the templating system's change detection scheme fairly easily.
So I wanted to write a quick
I'll try to edit this as I make changes. Comments welcome.
The bottom line, though, is that this is not difficult code. Why we thought we needed wrappers to make AJAX calls I'll never know. The longer you can resist context-specific code, like library-specific wrappers, the longer your original code can live.
Yes, this is, in contrast to my original goals, in TypeScript. It's a pretty easy port. But seriously, you should be using TypeScript.
posted by ruffin at 6/15/2021 10:30:00 AM
|Thursday, June 10, 2021|
I love stuff like illegal opcodes. As the page's author says, "Someone in Apple's silicon design team made a boo-boo. It happens. Engineers are human." Every chip has mistakes. As long as it's not damaging, and this one doesn't seem to be, what's most interesting to me is how skillfully humans are able to find them. Easter egg hunting redux.
posted by Jalindrine at 6/10/2021 09:20:00 AM
I was following a video from Pinal Dave called "Who Dropped Your Table?" and was getting a message that, "Currently, this report does not have any data to show, because default trace does not contain relevant information."
I googled for the reason why and guess what? The first hit (and answer) was on sqlauthority.com:
And now I too can tell who dropped tables on my database.
(I do worry a little that enabling this might be a significant performance hit, but I just set it on my local dev machine for now. The answer to who messed things up will, here at least, always be me. Hopefully!)
posted by ruffin at 6/10/2021 09:13:00 AM
|Friday, June 04, 2021|
Here's a post I put onto the story posted at StackOverflow regarding its sale to Prosus. As of this morning, it's been a day or two and it still hasn't passed moderation. I mean, that's their right, but let's say it doesn't speak well for their willingness to listen. Makes you wonder how many more critical comments are in moderation limbo.
posted by ruffin at 6/04/2021 01:21:00 PM
|Friday, May 28, 2021|
There is no world where this is a good thing.
Before you ask, no, I have turned off autocorrect in the Keyboard preferences pane.
I hate this OS. QA is nonexistent. Maybe this isn't a native dialog and it'll end up being a Sublime Text bug, but the autocorrect is so over-pervasive and unwieldy for someone who wants to keep their hands on the keyboard with a minimum of presses -- no, you know, the real issue is that this is an iOS "feature" that's made its way, half-baked, to my desktop OS. Let. Me. Turn. It. Off. Freakin' @#$@^#$%@#$. I hate you, macOS.
ARGH. I hate this OS.
EDIT (20210610): Turns out there was an entry in the Shortcuts tab to autocorrect txt to text. I don't remember adding it, and there is at least one that Apple adds by default (omw == On my way!) but let's say I did, b/c I must have, right?
Guess where I would've added that typing shortcut? On my iPhone; that's right.
Why would Apple think that I automatically wanted all my thumb-typing shortcuts copied over to my Mac that has a real, full-sized keyboard?
Insane. Though this time I should apologize to QA and go after product management instead. Wow.
posted by ruffin at 5/28/2021 11:09:00 AM
|Thursday, May 27, 2021|
I wanted to diff two files on my Mac. I can do this in BBEdit, but it’s not super easy. You can open one, then the other, then highlight both and diff, or ch… oh, you get it.
But there’s a command line version of BBEdit’s diff tool,
But how do you get the daggum full path to the files in the Finder?
Seems like it might've used to do this by default, but the Finder can be set to show the path to the file you've got selected in a footer.
And here's the extra trick: Right click the file in that bar and select Copy [filename] as Pathname and POOF, you've got the full path in your clipboard.