• 0 Posts
  • 96 Comments
Joined 1 year ago
cake
Cake day: November 13th, 2023

help-circle


  • There’s just so much in IT that fits this format.

    • Every Terraform project
    • Using Nix tooling inside of Ubuntu
    • WSL
    • Proton/WINE
    • Containers on ECS, EKS, or whatever container runtime you hate this week.
    • Every custom C++ program that uses glibc, SDL, openssl, or whatever lib that has it’s act together.
    • Python using numpy
    • Remediating a security hole in a legacy enterprise program


  • Story takes place in a whole-ass galaxy. Everyone winds up back on Tatooine for some stupid reason; the planet with barely one ecosystem, practically zero vegetation, no economy that matters, yet populated with two (?) cities. Other planets also have exactly one ecosystem, culture, and one optional urban center1. There’s also only 12 or so planets that matter, yet half of everyone you meet are from all the other ones. You may not like what you see, but this is peak sci-fi writing performance, right here. /s

    This story could take place in a diverse corner of a single Earth-like planet and it wouldn’t be all that different.


    1 - Meanwhile planet Coruscant is an urban center where the ecosystem can best be described as “traffic” and the culture is “city folk that inexplicably eat at 1950’s-style diners”.




  • Ideally yes. This is me and Mrs. Warp Core and I wouldn’t change it for the world.

    However…

    Well, let me put it this way. Ever have a best friend that, after spending a lot of time around, you find out that you actually can’t stand more than a few hours at time? That is absolutely a possibility here. Only now their stuff is in your house (or vice-versa), and/or they’re on the same lease.

    $0.02: It may not always be advisable, but absolutely benchmark the practical aspects of your romance long before tying the knot. Long-term co-habitation is not the only route here. Consider other ways to rack up large blocks of time: getaway vacations, long weekends, or even just “play house” for a few days at a time. You’d be amazed at what horrible, terrible, filthy, obnoxious habits your partner has when “at home.” The reality is that everyone is a bit (more) of a mess in private, and the only real question you have to answer is: “what am I willing to put up with?”



  • I was in the “gifted/advanced” track too. Teachers saw this one of two ways. Half of them got the memo: you got extra interesting stuff to noodle through because we’re all under-stimulated in a typical class. The others decided to just double your homework load and call it a day. At least the teachers in the first group had some interesting takes on brain teasers and reading material.

    And on that note: I must have thought about Flowers for Algernon every week since I read it. Since the 90’s. I’m tired, boss.


  • Sometimes teachers field stories like this to foster critical thought and encourage insightful book reports. It’s stimulating material even with a flawed premise, and that’s the point.

    My teachers always seemed to be the type that had these stories in the curriculum, but weren’t the type to follow up with the thinky-thinky bits. This had rather predictable results.



  • Honestly, this is why I tell developers that work with/for me to build in logging, day one. Not only will you always have clarity in every environment, but you won’t run into cases where adding logging later makes races/deadlocks “go away mysteriously.” A lot of the time, attaching a debugger to stuff in production isn’t going to fly, so “printf debugging” like this is truly your best bet.

    To do this right, look into logging modules/libraries that support filtering, lazy evaluation, contexts, and JSON output for perfect SEIM compatibility (enterprise stuff like Splunk or ELK).



  • Last time I did anything on the job with C++ was about 8 years ago. Here’s what I learned. It may still be relevant.

    • C++14 was alright, but still wasn’t everything you need. The language has improved a lot since, so take this with a grain of salt. We had to use Boost to really make the most of things and avoid stupid memory management problems through use of smart (ref-counted) pointers. The overhead was worth it.
    • C++ relies heavily on idioms for good code quality that can only be learned from a book and/or the community. “RAII” is a good example here. The language itself is simply too flexible and low-level to force that kind of behavior on you. To make matters worse, idiomatic practices wind up adding substantial weight to manual code review, since there’s no other way to enforce them or check for their absence.
    • I wound up writing a post-processor to make sense of template errors since it had a habit of completely exploding any template use to the fullest possible expression expansion; it was like typedefs didn’t exist. My tool replaced common patterns with expressions that more closely resembled our sourcecode1. This helped a lot with understanding what was actually going wrong. At the same time, it was ridiculous that was even necessary.
    • A team style guide is a hard must with C++. The language spec is so mindbogglingly huge that no two “C++ programmers” possess the same experience with the language. Yes, their skillsets will overlap, but the non-overlapping areas can be quite large and have profound ramifications on coding preferences. This is why my team got into serious disagreements with style and approach without one: there was no tie-breaker to end disagreement. We eventually adopted one after a lot of lost effort and hurt feelings.
    • Coding C++ is less like having a conversation with the target CPU and more like a conversation with the compiler. Templates, const, constexpr, inline, volatile, are all about steering the compiler to generate the code you want. As a consequence, you spend a lot more of your time troubleshooting code generation and compilation errors than with other languages.
    • At some point you will need valgrind or at least a really good IDE that’s dialed in for your process and target platform. Letting the rest of the team get away without these tools will negatively impact the team’s ability to fix serious problems.
    • C++ assumes that CPU performance and memory management are your biggest problems. You absolutely have to be aware of stack allocation, heap allocation, copies, copy-free, references, pointers, and v-tables, which are needed to navigate the nuances of code generation and how it impacts run-time and memory.
    • Multithreading in C++14 was made approachable through Boost and some primitives built on top of pthreads. Deadlocks and races were a programmer problem; the language has nothing to help you here. My recommendation: take a page from Go’s book. Use a really good threadsafe mutable queue, copy (no references/pointers) everything into it, and use it for moving mutable state between threads until performance benchmarks tell you to do otherwise.
    • Test-driven design and DevOps best-practice is needed to make any C++ project of scale manageable. I cannot stress this enough. Use every automated quality gate you can to catch errors before live/integration testing, as using valgrind and other in-situ tools can be painful (if not impossible).

    1 - I borrowed this idea from working on J2EE apps, of all places, where stack traces get so huge/deep that there are plugins designed to filter out method calls (sometimes, entire libraries) that are just noise. The idea of post-processing errors just kind of stuck after that - it’s just more data, after all.