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

ko-fi

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

help-circle














  • Hey!

    Around June 9th I found that I could no longer display images in comments & posts. The specific problem seemed to stem from some broken code that was being auto-added

    This is most likely due to the imgur rate limiter which is blocking our server (Basically our server is trying to request too many images from imgur). I have a plan to bypass our image proxying for a handful of known image-hosts, such as imgur, but haven’t been able to implement this yet. But it’s coming soon!

    In general I intend to keep image proxying enabled for most other sites, though, because it allows protecting the privacy of lemm.ee users, as well as ensures slightly faster page load times compared to always making users fetch images directly from their original host.

    But sadly, there’s more. Namely, it seems that lemm.ee communities are no longer showing up in one of the significant FV search engines, i.e. “lemmyverse.net.”

    This requires fixing on the lemmyverse.net side - they currently only have support for older Lemmy versions, but I believe it’s only a matter of time before this gets fixed.



  • 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.