• Head admin @ lemm.ee, a general-purpose Lemmy instance
  • Creator of lemmy-ui-next, an alternative Lemmy frontend
  • Lemmy contributor

ko-fi

  • 37 Posts
  • 273 Comments
Joined 1 year ago
cake
Cake day: June 9th, 2023

help-circle
  • I use SwiftKey and I hate it, but I haven’t found anything better

    I’m in exactly the same boat. 😅

    I don’t understand how it has been broken for years. I wonder if none of the engineers working on it actually use it themselves? Deleting all of your local data makes it stop crashing for a few weeks, but then you of course also lose all the learned predictions, and eventually it just gets to a point where it just crashes more and more often and you have to delete all the local data again. It sucks.

    If only the default Apple keyboard had support for my language, I would ditch SwiftKey forever.




  • I think there are two separate things I want to address here:

    First, agile isn’t a project management methodology, it’s just a set of 4 abstract priorities and 12 abstract principles. It’s very short, you can check it out here:

    https://agilemanifesto.org/

    Nothing here says that you’re not allowed to write documentation, write down requirements, etc. In fact, the principles encourage you yourself as a software team to create the exact processes and documentation that you need in order to meet your goals.

    “Working software over comprehensive documentation” does not mean you aren’t allowed to have documentation, it just means that you should only write documentation if it helps you build working software, rather than writing documentation for the sake of bureaucracy.

    “Individuals and interactions over processes and tools” does not mean that you should have no processes, it just means that the individuals in your team should be empowered to collaboratively create whatever processes you need to deliver good software.

    Secondly, in terms of practical advice:

    1. Talk about this problem with your team. Is it hard for others to figure out where requirements came from? Maybe they already have a good method and can share it with you. If it’s hard for everybody, then propose improvements to your process, for example, propose some type of design document process as part of building any new features
    2. There are no perfect answers to the question of “how do I safely make non-trivial changes to systems”, but the general approach is to ensure that:

    a. You have metrics about how your system is used.

    b. You have automated tests covering any requirements, so that you can feel confident when making changes to one part of the system that it isn’t violating any unrelated requirements.

    c. You actually document any confusing parts in the code itself using comments. The most important thing to cover in comments is “why is this logic necessary?” - whenever something is confusing, you need to answer this question with a comment. Otherwise, the system becomes very annoying to change later on.

    If you are missing any of the above, then propose to your team that you start doing it ASAP

    1. At the end of the day, somebody is responsible for making product decisions. Is it your team? Or maybe some separate product owner? Sometimes, you just need to communicate with whoever is responsible to figure out if any requirements are still relevant, or if they are now safe to change.





  • I have identified two reasons for broken thumbnails right now:

    1. For some, the source website is simply not allowing our server to download the image (mostly due to server issues on the remote side)
    2. For others, it seems that some types of URLs are breaking thumbnail generation. I think I found the bug here and will try to submit a fix soon.


  • Basically, yes!

    For the backend: our traffic is load balanced between multiple servers, so I can just spin up a new server with the latest version of Lemmy, add it to the load balancer, and then start taking down the servers with older versions. That way, there is no disruption at all for users, because there is always a server available to handle incoming traffic. The only requirement for this is that the new version of Lemmy can’t have database migrations which break the old running servers.

    For lemmy-ui: it’s a bit more complicated, because even with a load balancer, it’s still possible that one user making multiple sequential requests can end up getting responses from different servers. This is problematic, because during an upgrade, files from the new version are not available on the old servers, and vice versa. Fortunately, there are many ways to solve this problem, for lemm.ee, the solution I use is to just always serve lemmy-ui files from object storage, for all versions. In other words, after I upload lemmy-ui files for a new version, these will immediately also be available on old servers.







  • Well, one advantage we have over commercial social media is that they need to pay people to write code and maintain the infrastructure, but a lot of work on Lemmy is volunteer-based.

    Many admins for bigger instances are basically on-call the whole year for free, open source contributors provide code for free, etc. Even the core maintainers are effectively losing money by working on Lemmy, because while they are getting some income, the sum of money they are getting from working on Lemmy is way smaller than what they would get if they worked typical software engineering jobs.

    Basically, if any non-volunteer organization wanted to replicate Lemmy, it would cost them quite a bit more in terms of payroll alone.

    Another aspect is scale - Lemmy is able to spread the costs between different instances, and while growth of the network can generally increase costs for individual nodes, they will still end up paying less compared to if they were hosting the entire social network in a centralized way.