We deployed a client software in a Docker container on Windows 10. It could not connect to the backend, even though we saw SYN packages originating from it.So, we ran WireShark on the Windows host and saw that the SYN-ACK packages from the backend were arriving there, too, but no ACK came through to complete the TCP handshake.
Eventually, we rolled out a network debugging container on that Windows host and then could see in the tcpdump, that the SYN-ACK packages, which arrived on the Windows host, just did not show up in the container. Hyper-V or something was quietly dropping them.
Other network connections were working fine, just the SYN-ACK from our backend triggered this.
Might have to go back to the cookbook concept of yore.
So, either buy a physical, reputable cookbook and then try the recipes in there. Or just go to known-good recipe webpages and go through their recipes.
But yeah, just thinking "I'd like to make Venezuelan vuvuzela vegetables", then typing that into a search engine and cooking whatever's the first result, that won't be possible anymore...
Yeah, I virtually only use --force for moving tags around (which one could definitely argue isn't really a thing you should be doing regularly either)...
Yeah, we always try to automate as much as possible with generic language build tooling and scripts, so that ideally the call in the runner is just a single command, which can also be triggered locally.
Unfortunately, if you want to be able to re-run intermediate steps, then you do need to inform the runner of what you're doing and deal with the whole complexity of up-/downloading intermediate results.
I have caught myself genuinely thinking that management needs to unearth more budget, if they so desperately want us to use these AI tools, so that we can onboard another person to compensate for the productivity hit.
Unfortunately, they believe the opposite to be true, that we just need to use AI tools and then our productivity will be through the roof...
I also always find that outsourcing is risky, whether it's to other devs or to some AI, because it requires that you understand the problem in whole upfront. In 99% of cases, when I'm implementing something myself, I will run into some edge case I had not considered before and where an important decision has to be made. And well, a junior or LLM is unlikely to see all these edge cases and to make larger decisions, that might affect the whole codebase.
I can try to spend more time upfront to come up with all these corner cases without starting on the implementation, but that quickly stops being economic, because it takes me more time than when I can look at the code.
It's like those headlines "bicyclist hit by car" or similar, where you might think the car developed a mind of its own. I guess, we are on our way there, though, with self-driving cars and such...
In my corner of the embedded world, it feels like everyone is practically jumping to integrate Rust. In the sense that vendors which haven't had to innovate for 10+ years will suddenly publish a Rust API out of the blue. And I'm saying "out of the blue", but I do also regularly hear from other devs, that they've been pestering the vendors to provide a Rust API or even started writing own wrappers for their C APIs.
And while it's certainly a factor that Rust is good, in my experience they generally just want to get away from C. Even our management is well aware that C is a liability.
I guess, I should add that while I say "jumping", this is the embedded world where everything moves extremely slowly, so we're talking about a multi-year jump. In our field, you need to get certifications for your toolchain and code quality, for example, so lots of work is necessary to formalize all of that.
Yeah, particularly the broadcasting really irks me.That is an opinion you can hold for yourself and then make compromises as you encounter reality. I do expect programmers to hold strong opinions.
But when you broadcast it, you strip yourself of the option to make compromises. You're just saying something which is going to be wrong in one way or another in most situations. I do expect programmers to be smarter than that.
Like, I understand that brains are supposed to be wrinkly and there's an actual disorder where the brain doesn't have those wrinkles, which leads to developmental delays: https://en.wikipedia.org/wiki/Lissencephaly
But it still sounds to me like you're just calling them "smooth" as in "cool".
I mean, for me, it's also mostly a matter of us doing embedded(-adjacent) software dev. So far, my company would hardly ever choose one stack over another for performance/efficiency reasons. But yeah, maybe that is going to change in the future.
Large shared codebases never reflect a single design, but are always in some intermediate state between different software designs. How the codebase will hang together after an individual change is thus way more important than what ideal “north star” you’re driving towards.
Yeah, learned this the hard way. Came up with an architecture to strive for 1½ years ago. We shipped the last remaining refactorings two weeks ago. It has been a ride. Mostly a ride of perpetually being low-priority, because refactorings always are.
In retrospect, it would've likely been better to go for a half-assed architecture that requires less of a diff, while still enabling us to ship similar features. It's not like the new architecture is a flawless fit either, after 1½ years of evolving requirements.
And ultimately, architecture needs to serve the team. What does not serve the team is 1½ years of architectural limbo.