Husband, father, kabab lover, history buff, chess fan and software engineer. Believes creating software must resemble art: intuitive creation and joyful discovery.

🌎 linktr.ee/bahmanm

Views are my own.

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

help-circle





  • Good question!

    IMO a good way to help a FOSS maintainer is to actually use the software (esp pre-release) and report bugs instead of working around them. Besides helping the project quality, I’d find it very heart-warming to receive feedback from users; it means people out there are actually not only using the software but care enough for it to take their time, report bugs and test patches.







  • To be precise, it’s not 4 requests to the same endpoint.

    lemmy-meter probes 4 endpoints each once per minute:

    • The landing page
    • api.getPosts (limit=1)
    • api.getComments (limit=1)
    • api.getCommunities (limit=1)

    That’s b/c I’ve frequently experienced cases when the landing page works but some mobile APIs don’t and vice versa.

    Hope that makes sense.


    As I said, if after some time you feel like this is too much load, reach out to me and I can easily configure lemmy-meter to probe less frequently.









  • I didn’t like the capitalised names so configured xdg to use all lowercase letters. That’s why ~/opt fits in pretty nicely.

    You’ve got a point re ~/.local/opt but I personally like the idea of having the important bits right in my home dir. Here’s my layout (which I’m quite used to now after all these years):

    $ ls ~
    bin  
    desktop  
    doc  
    downloads  
    mnt  
    music  
    opt 
    pictures  
    public  
    src  
    templates  
    tmp  
    videos  
    workspace
    

    where

    • bin is just a bunch of symlinks to frequently used apps from opt
    • src is where i keep clones of repos (but I don’t do work in src)
    • workspace is a where I do my work on git worktrees (based off src)







  • RE Go: Others have already mentioned the right way, thought I’d personally prefer ~/opt/go over what was suggested.


    RE Perl: To instruct Perl to install to another directory, for example to ~/opt/perl5, put the following lines somewhere in your bash init files.

    export PERL5LIB="$HOME/opt/perl5/lib/perl5${PERL5LIB:+:${PERL5LIB}}"
    export PERL_LOCAL_LIB_ROOT="$HOME/opt/perl5${PERL_LOCAL_LIB_ROOT:+:${PERL_LOCAL_LIB_ROOT}}"
    export PERL_MB_OPT="--install_base \"$HOME/opt/perl5\""
    export PERL_MM_OPT="INSTALL_BASE=$HOME/opt/perl5"
    export PATH="$HOME/opt/perl5/bin${PATH:+:${PATH}}"
    

    Though you need to re-install the Perl packages you had previously installed.


  • First off, I was ready to close the tab at the slightest suggestion of using Velocity as a metric. That didn’t happen 🙂


    I like the idea that metrics should be contained and sustainable. Though I don’t agree w/ the suggested metrics.

    In general, it seems they are all designed around the process and not the product. In particular, there’s no mention of the “value unlocked” in each sprint: it’s an important one for an Agile team as it holds Product accountable to understanding of what is the $$$ value of the team’s effort.

    The suggested set, to my mind, is formed around the idea of a feature factory line and its efficiency (assuming it is measurable.) It leaves out the “meaning” of what the team achieve w/ that efficiency.

    My 2 cents.


    Good read nonetheless 👍 Got me thinking about this intriguing topic after a few years.