I assume you’re referring to this blog series: https://medium.com/prospa-technology/emerging-vs-intentional-architecture-385071ae5d75 ? I wasn’t aware of it, and it seems to have some insightful observations! There’s definitely some overlap, but by the looks of it, I think I will diverge quite a bit with my next post. I think I’m pretty aligned on the “One-Way Decisions” vs “Two-Way Decisions” part. A One-Way decision in my mind would be, which programming language or framework do we use? Do we use REST or GraphQL?

But it doesn’t really go into how to deal with Two-Way decisions, apart from saying to trust your developers. And I think it kinda glosses over the part that things that may appear to be Two-Way decisions initially may actually be closer to One-Way decisions if you continue to build on them. So where that blog still focuses quite a bit on the process, I think I want to shift the focus a bit more to the technical side (so far I’ve mostly laid down the values that inform the technical direction), especially when it comes to Two-Way decisions. I wasn’t thinking about covering One-Way decisions much, but rather on how to shape everyday coding to be more in alignment with Post/Emerging architecture so that you can avoid the Two-Way decisions that in retrospect aren’t as much of a Two-Way decision as you’d hope.

Hope that makes sense :D

Thanks! This mirrors quite some experiences I’ve had over the years indeed. And for what it’s worth, I think the way you’re handling that is not bad at all.

As someone else mentioned in the comments on Mastodon, one of the hardest things about mentoring is articulating the lessons you may not even realize you’ve learned. I don’t think anyone can be blamed for failing to teach or convince someone else, since people are simply too different to be able to teach and convince them all. As you say, you have to pick your battles, and as long as you let your teammates do their work respectfully in their own way, that alone is a great achievement!

For a little bit I thought this library might be a subtle joke, seeing the #define _SHITPRESS_H at the start. That combined with the compress() and decompress() not taking any arguments and not having a return value, I thought we were being played. Not to mention the library appears to be plain C rather than C++… surely the author should know the difference?

Then I saw how the interface actually works:

// interface for the library user, implement these in your program:
unsigned int SPR_in(); // Return next byte from input or value > 255 on EOF.
void SPR_out(unsigned char); // Output byte.

This seems extremely poorly thought out. Calling into global functions for input and output means that your library will be a pain to use in any program that has to (de)compress anything more than a single input.

Essentially, but it doesn’t roll off the tongue as nicely 😅

I can’t say for sure we won’t need to revisit this again as we learn more about the nature of what data is missing and whether with more context we can automatically triage and notify the right people, but for now it feels like the cost / benefit ratio of “talking versus doing” is about right.

This was a nice post, and I agree people should think a bit about how to name things, because getting it wrong can lead to others making wrong assumptions, which ends up wasting a lot of time.

That said, I would get pretty annoyed if a PR I’m involved with ended up with this level of bike-shedding over a function name. If the end goal is to avoid wasting people’s time, bringing out the big guns and making three attempts, with three rounds of review, to get the name of such a trivial function right is surely throwing out the cost / benefit ratio right upfront.

It’s a bit arguing about semantics really. But Rust and Haskell are merely the first ones with patches out. The issue affects other languages as well, including Java, Node.js, Python and seemingly every language with Windows support. I think it’s fair to call it a Windows problem, since it affects everyone there.

But languages like Rust and Haskell are promising their users that they are protected from this kind of behavior, which is why they want to patch it quickly. Some of the others merely updated the documentation, effectively saying yeah it’s a risk. Java went as far as saying they won’t fix the issue.

That’s certainly not the case, because that’s like saying the issue is with Rust’s string slices. I think you may have missed the part of the issue where batch scripts require additional escaping due to Windows’ command handling. It’s a ridiculous design of the Windows API system, which is also why (almost?) every language they tested was vulnerable, so it would be actually very outstanding if Qt prevented this.

For C++ devs not using Qt it’s just another footgun they’ll likely keep introducing security issues with as well. But if you do use Qt, I think it’s better to double-check since it may also require a patch.

What are the chances Qt is affected by this issue too?

MSFT is known for changing names a lot, but not for killing technologies.

Silverlight would like a word ;)