magic_lobster_party

  • 0 Posts
  • 41 Comments
Joined 3 months ago
cake
Cake day: August 15th, 2024

help-circle

  • Now it was a few years ago I used it regularly last time, but moving to Slack was a huge relief.

    One thing I remember with teams is that sending files was always a hassle. Sometimes files didn’t arrive. Files couldn’t have the same name as other previously sent files (because everything was in a onedrive folder).

    Slack has much better search. It felt like I could finally find the messages I wanted to find. With teams it was a gamble.

    And then there’s much better bot integration. At my work we have multiple bots that send messages when there’s e.g. production errors. We can then start thread discussions directly on that posts about the error, or link it to other channels to escalate the issue. And with a working search engine we can easily find the conversation again as a reference.

    It got many small things that just adds value.







  • From the original document:

    Software manufacturers should build products in a manner that systematically prevents the introduction of memory safety vulnerabilities, such as by using a memory safe language or hardware capabilities that prevent memory safety vulnerabilities. Additionally, software manufacturers should publish a memory safety roadmap by January 1, 2026.

    My interpretation is that smart pointers are allowed, as long it’s systematically enforced. Switching to a memory safe language is just one example.






  • Mainstream statically-typed OOP allows straightforward backwards compatible evolution of types, while keeping them easy to compose. I consider this to be one of the killer features of mainstream statically-typed OOP, and I believe it is an essential feature for programming with many people, over long periods of time.

    I 100% agree with this. The strength of OOP comes with maintaining large programs over a long time. Usually with ever changing requirements.

    This is something that’s difficult to demonstrate with small toy examples, which gives OOP languages an unfair disadvantage. Yeah, it might be slower. Yeah, there might be more boilerplate to write. But how does the alternative solutions compare with regards to maintainability?

    The main problem with OOP is that maintainability doesn’t necessarily come naturally. It requires lots of experience and discipline to get it right. It’s easy to paint yourself in the corner if you don’t know what you’re doing.






  • Looks like it’s JavaScript, but in Java I would prefer to use the Stream API, something like this:

    return availableDrivers.stream()
        .filter(driver -> calculateDistance(rider, driver) < 5)
        .filter(driver -> isPreferredVehicle(rider, driver))
        .filter(driver -> meetsRiderPreferences(rider, driver))
        .findFirst()
        .orElse(null);
    

    Then we have:

    private boolean meetsRiderPreferences(Rider rider, Driver driver) {
        if (driver.rating >= 4.5) {
            if (rider.preferences.includes('Premium Driver')) {
                  return driver.isPremiumDriver;
            } else {
                  return true;
            }
        } else if (driver.rating >= 4.0) {
            return true;
        } else {
            return false;
        }
    }
    

    This increases the separation of concern in a neat way, and it becomes more clear what the for loop does at a glance (get the first driver satisfying a set of conditions). The more complicated logic is isolated in meetsRiderPreferences, which now only returns true or false. Reading the method is more about making a mental map of a truth table.

    It’s also easy to expand the logic (add more filter conditions, sort the drivers based on rating and distance, break out meetsRiderPreferences into smaller methods, etc.).

    Not sure how the equivalent in JavaScript would look like, but this is what I would do in Java.



  • I relate. Technical debt is by far the most common source of frustration in my career. It’s that code someone inexperienced wrote years ago that no one longer understands, but it still needs to be maintained. Often the code is also unnecessarily convoluted, so there’s a high risk of introducing new bugs when working with it.

    I’ve recently managed to refactor such code recently. No one could work with it with confidence, it was slow and it was buggy. A lot of the code was also completely unnecessary (like 100 line convoluted mess that could be done with 1 line of code).

    Now someone else in my team who has never worked with this code wrote a major addition to it without much assistance, so I take it as a sign that my refactor is a great improvement.