Notices by Vertigo (vertigo@mastodon.social), page 15

@Shamar @bronco And AmigaOS, GEM, GEOS/64, and PC/GEOS?

@Mrfroglegs Can confirm: hovering ominously is a great way to rise up above the crowd.

@cstanhope Looks like a good use-case to refresh my knowledge of Rust. It's been a while.

@cstanhope It looks like I'm going to have to make my own file transfer protocol that works in units of 1KiB blocks back and forth. The idea is basically the same as a network test tool, except instead of sending out random bits, the bits are taken from the file that I want to copy. Arrange for both sides to keep track of metrics (e.g., number of bit errors discovered). Continuously re-send the same 1KiB block until it's received, stored, sync'ed, and XOR-verified.

@cstanhope No, I'm so far not able to retrieve the file. memtest86+ won't run on this computer, and memtester (a user-space memory tester for Linux) shows memory as good. Repeated uses of "rsync -av --inplace" also fail. It *never* gets a consistent image of the file from the server.

@enkiv2 Yeah, been there before. Eventually, one of two things would happen: either I push back against the perfectionism with "NO! I'm done playing this game" type messages, or I make good on my word and leave. That has driven me to clinical levels of burn-out before, even to the point of being borderline suicidal.

Never. Again. It's just not worth it.

#Python and #Database #DB peeps -- What would you recommend for supporting database migrations **without** depending on an ORM?

Our application does not make use of an ORM, and we would strongly prefer to keep it that way. However, we are finding a need for supporting migrations in a more structured manner in our CI pipeline.

Would love your input. Please re-toot. Thanks!

@seanl I worked through this issue by deleting my code and rewriting from scratch. Same code, but more granular testing in between saves. Turns out the issue was I had duplicately named methods in my test case, and the test runner was selecting between them at random (probably because Py2 randomizes dictionaries). Whoops.

Renaming the methods so they're unique solved the apparent non-determinism.

Looks like it's time to rig the code with a linter now. :/ Uugh.

@seanl I *thought* AGPL already covered that case. Am I mistaken?

@janellecshane I sure wish my computer had hubcaps. Spinners would be nice. Maybe some nice hydraulics to go with them...

@seanl If I had complete and total control over everything everywhere, ... I might consider it.

I'm running into a problem where my ugly hack, with the exact same inputs under unit test conditions is returning inconsistent results. So, *something* is going on behind the scenes in the library, which I'm none too happy about.

Just about to walk away from this project before I throw the computer through the damn window.

@seanl In principle, I agree; however, my boss doesn't care about the diplomacy of cooperating dependencies. ;) I'm forced to use ugly hacks to work around an incomplete API.

@seanl I was careful to specify abstract data types; I agree with you when it comes to procedures that affects state in the real-world. But, abstract data types almost always have an algebraic-like nature to them that makes them amenable to reasoning in a functional, state-free manner.

Datetimes are perfect examples. I can convert a Unix timestamp into a datetime via fromtimestamp() method. But, there exists no converse in Python 2, only ugly hacks as work-arounds.

@seanl I'd like to see some evidence in support of this, because this has not been my experience. Instead, I find libraries with under-specified, incomplete APIs are inextricably linked with extremely bloated applications with loooooong, lengthy chains of conversion function after conversion function after conversion function so that data type A can be used in context B or vice versa in the same application.

Did it never occur to someone that this should be a bidirectional relationship?

Here's a helpful hint: CRUD. Create / Read / Update / Delete. If you're maintaining a standard library with abstract data types, and their API isn't CRUDy, there is a *very* high probability it's *incomplete* and *broken*.

YAGNI does not apply to libraries; it applies to application functionality. For libraries, YJMNI -- You Just Might Need It. Probably, sooner than you think.

I truly appreciate, and even encourage, consideration of YAGNI when writing software. However, I think it must be made clear that YAGNI was conceived in the context of an end-user application.

If you're going to write/maintain a standard library, YAGNI no longer applies. Case in point, in Python 2, there is exactly *ZERO* ways of converting a datetime object into a timestamp; however, there exist several ways of converting a timestamp into a datetime object.