Unittest, You.com, MSL, M365, IPC, Docker, H3

1. Found Python's unittest.mock (@ docs.python.org) useful for some case, especially testing some hard to reproduce exceptions and error conditions. Yet in general, I like keeping unit tests as clean as possible as well as running proper integration tests as deeply through the real stack as possible. Ie. Testing the complete workflow, including the database interactions, using minimal test client code. Even if there's desired to skip some tests asking why it would ever fail.

2. You.com AI image generation. Broken, but a there's work-a-round ... If I ask you.com to generate image, it replies "Unable to render image"... But, then you'll click the button "copy answer" and paste it, and the turns out to contain the url to the rendered image. But why it doesn't show it to the user and just shows an error instead of the image which was successfully generated. I could use several derogatory words to describe their so called developers, and how "very complex and technical issue" like that takes several weeks to fix. It's nice to see how users have to work out and figure the work-a-round solutions, when the experts dealing with this stuff can't get their bleeping S straight in the porcelain bowl. Maybe someday they can hire someone who isn't absolutely and totally incompetent.

3. RFC9420 - Messaging Layer Security (MLS) (@ rfc-editor.org) - Good stuff. Tree stuff, and initial parts, like user identity weren't that interesting. But then we started talking, I especially liked concepts like the reuse guard, providing additional security for key / nonce reuse. PSK stuff, depending on app implementation that could be usability nightmare providing terrible UX. But of course that's not protocol level issue. But what I really loved was Exporters, allowing export epoch / group / usage specific shared secret for group members from MLS. Good thinking! Epoch Authenticator is also nice method, of verifying a contact in a group. Deletion Schedule, this is one of the things I also like. Some protocols handle it perfectly, and some others save secrets indefinitely, like the Matrix. Uh oh. What else could I say, GREASE! Padding, good! About Appendix C. I like Array-Based Trees, it's a very nice simplification over the link based one.

4. I don't know where Microsoft finds these developers. M365 (@ Wikipedia) Chat is ok-ish. Now it doesn't cut the responses anymore randomly. But as example new chat doesn't work. I don't know what's causing the issue that 'New chat button' doesn't work, yet of course reloading the URL without parameters leads to the same result. It's amazing how bad UX and code they can produce, even for simple things. If feels like they're serving a platform developed by a single developer pushing untested commits into production. I guess it takes weeks or months, until it's slightly improved again in the next iteration. It's also hard to kind of know, if the copilot or M365 or whatever is even right URL for the service. - It's a complete mess with domains as well.

5. Wonderful conflicts. Some libraries are available as 32 bit versions only, and some other libraries are available as 64 bit versions only. I've been dealing with this issue for quite a while. But now I got sick'n'tired for it. I wrote a wrapper server, which wraps the 32 libraries with 32 bit launcher, and then provides universal serialized IPC (@ Wikipedia) (pickle over named pipe), so I can access the libraries from 64 bit code. Kind of annoying "solution", but it works fine and practically solves the initial problem.

6. Docker (@ Wikipedia) fun, had one image, which dockerfile was a total mess. I spent hours fixing the image (not docker file) so that everything would work. Then several colleagues also wanted to use it, because it was finally working. It seems that docker save and docker load aren't that widely used, yet in some specific cases those are very very handy, like in this case. I just saved the working image and distributed it to the peers needing a working version.

7. HTTP/3 (@ Wikipedia) didn't ship with 22.04 LTS Ubuntu's  nginx/1.24.0 version which doesn't support HTTP/3, so it seems that HTTP/3 usage takes at least two years to be available. Some people claim a year is a long time, but few years is nothing, nothing at all. Also checked latest cURL and same situation. Well, no rush. It'll be some day. Just like IPv6 is everywhere "soon".

2025-05-04