And for anyone interested in a template:

  • ChickenLadyLovesLife@lemmy.worldEnglish
    4·
    58 minutes ago

    I briefly wrote Blackberry apps circa 2010 (yes, I knew RIM was dying a quick death). The development process was insane: any module from the framework that you incorporated into your app had to be digitally signed by RIM servers every time you tried to compile your app and deploy it to a device, even if you had only made a one-line change to the code. On good days, this would make the compilation take 5-10 minutes; on bad days it would be upwards of an hour or never happen at all. Some wags had even set up a special website that would tell you whether the RIM servers were down or not (long gone now, of course). I got in the habit of making a large number of code changes before attempting to run and test stuff, which is obviously not the ideal way to do things but it certainly teaches you to be careful. It also make me think long and hard before including a new module into my code. As one example, for my GUI I needed to use trigonometry functions which were naturally (lol) part of one of the cryptography modules which took an especially long time to get signed. I ended up writing my own sin() function in Java just to avoid the hit of including that module.

    The great part of this was that I always had a ready-made excuse whenever I felt like taking a long lunch or going shopping or going home early. “Sorry boss, the signing server is down” and I made damn sure they never knew about isthesigningserverdown.com. It also helped that it was Blackberry circa 2010 and it didn’t make a shit bit of difference whether I got the app done or not.

  • sik0fewl@piefed.caEnglish
    85·
    24 hours ago

    What we need is some sort of distributed version control system.

    I’m not quite sure how it will work yet, but it would have the entire codebase and its history mirrored onto every developer’s computer. Instead of requiring a central repository, developers could share their changes directly with each other.

      • sik0fewl@piefed.caEnglish
        21·
        17 hours ago

        It was mostly a joke/irony.

        Git is already a “distributed version control system” that does exactly what I’ve described. On the other hand, relying on centralized systems such as GitHub means that the “distributed” nature of it doesn’t make it any more resilient to failure.

    • dan@upvote.au
      511·
      24 hours ago

      Linus Torvalds is probably clever enough to create something like that. The Linux kernel sure could take advantage of it.

      • Eager Eagle@lemmy.worldEnglish
        10·
        15 hours ago

        git itself is really not far from a blockhain. Blockchain is fine, it only has a bad rep because of ponzi schemes that use it to create crypto, but the technology and trustless consensus mechanisms are interesting.

    • mmmac@lemmy.zip
      43·
      11 hours ago

      Don’t be a trachers pet lol, let us enjoy a lil time off thanks to github

    • Eager Eagle@lemmy.worldEnglish
      26·
      23 hours ago

      but seriously, we need project management features that are decentralized: issue tracking, kanban, code reviews w/ comments, and ways to extend functionality without relying on a git forge.

      • hoppolito@mander.xyzEnglish
        1·
        11 hours ago

        For issues tracking there’s the venerable git-bug, although development has sadly slowed way down in the last years.

        And I am always jealous of the way fossil repositories just have a complete front-end and wiki baked in, would love something like that for git.

      • sik0fewl@piefed.caEnglish
        12·
        23 hours ago

        Would be cool to see those as extensions to Git. Surely they could just be more Git objects?

          • Flipper@feddit.org
            1·
            11 hours ago

            Based in activitypub. You should be able to follow a repo with mastodon or Lemmy and then see ticket updates for example.

            But it’s far in the fuyure

      • waldfee@feddit.org
        5·
        21 hours ago

        You could create a git branch with an unrelated history to store this type of data; either as plaintext, md or something more sophisticated for dedicated tools. The biggest hurdle would probably be to define and agree on a standardized format

        • azertyfun@sh.itjust.works
          7·
          17 hours ago

          The last thing I want is merge conflicts in my issue tracker. The git data model is simply not right for conversational histories.

          ActivityPub is the obvious solution to decentralize public communication. We’re using it right now and AFAIK Forgejo is working to implement it for their issue tracker.

    • Ethan@programming.devEnglish
      5·
      23 hours ago

      We need better distributed connectivity. It wouldn’t be that hard to build a project management system (issues, etc) on top of Git, but DVCS only gets you so far without a way to connect directly to the other contributors.