• 0 Posts
  • 23 Comments
Joined 1 year ago
cake
Cake day: June 18th, 2023

help-circle

  • My experience with maintaining open source projects (though mine are very much smaller) is that it’s quite similar to a business: you just have to deal with stakeholders and people who think they are stakeholders.

    I had all the same experience at work:

    • Some unknown person from an unrelated team contacted me because something that my team does not manage broke. I tried to help a few times and I suddenly became their personal IT support team.

    • Another time someone not even working at my company demanded that I drop everything and fix their problem, because my name appeared in 3rd parties libraries.

    It’s sad that open source authors don’t always receive the recognition that they deserve.





  • RoR is too much magic for me. Getting started with any new code base is such a pain that I never want to do again. As a manager, I’ll avoid any job post that mentions Ruby. I have maintained projects written in Delphi, Centura, Java, C#, PHP and none of them even come close to the pain of RoR. Java and C# are notorious for ceremonial interfaces but that’s nothing compared to trying to figure out RoR automagics.


  • tvbusy@lemmy.dbzer0.comtoGames@lemmy.worldWhat's up with Epic Games?
    link
    fedilink
    English
    arrow-up
    25
    arrow-down
    2
    ·
    6 months ago

    Epic wanted exclusives by pulling games from other platforms. I will never spend a single cent on Epic Games. I’m happy to spend it on Steam, especially games that I have pirated before (Commandos series for example) or indie games (Banished anyone?).

    For bigger games such as Civilians, I’ll purchase it on Steam and then pirate so I don’t need to run Steam. I am a big fan of patches to remove the intro screen.









  • After many failed attempts at TDD, I realized/settled on test driven design, which is as simple as making sure what you’re writing can be tested. I don’t see writing the test first as a must, only good to have, but testable code is definitely a must.

    This approach is so much easier and useful in real situations, which is anything more complicated than foo/bar. Most of the time, just asking an engineer how they plan to test it will make all the difference. I don’t have to enforce my preference on anyone. I’m not restricting the team. I’m not creating a knowledge vacuum where only the seniors know how yo code and the juniors feel like they know nothing.

    Just think how you plan to test it, anyone can do that.