Disclaimer: Don't run scripts offered to you by randos unless you trust them or review it yourself

I use this constantly, it just plays music by file name, specifically matching *NAME* with case-insensitivity. Requires bash 4.something.

# play -ln SONGS ...
# -l don't shuffle
# -n dry run
mpv_args="--no-audio-display --no-resume-playback \
          --msg-level=all=status --term-osd-bar"
shopt -s globstar nullglob nocaseglob

shuffle=true
dry=false
while [[ "$1" == -* ]]; do
    if [[ "$1" == "-l" ]]; then 
        shuffle=false
    elif [[ "$1" == "-n" ]]; then
        dry=true
    fi

    shift 1
done

if [[ "$shuffle" == true ]]; then
    mpv_args="--shuffle $mpv_args"
fi

songs=()
while [[ "$#" != 0 ]]; do
    songs+=( ~/music/**/**/*"$1"*.* ) # change this to match your music directory layout
    shift 1                                               # could probably use find instead
done

if [[ "$dry" == true ]]; then
    if [[ "$shuffle" == true ]]; then
        printf "Shuffle mode is on\n"
    fi

    for song in "${songs[@]}"; do
        printf "$song\n"
    done
  
    exit
fi

if [[ ${#songs[@]} != 0 ]]; then
    mpv $mpv_args "${songs[@]}"
fi

I make no claims to the quality of this but it works!

I myself am a very, very competitive person. Because of this, I play almost exclusively competitive titles that feature a ranked ladder and esports. I find that even on a game that takes care to be competitive, there are still plenty (read: the vast majority) of people that don't seem to care for playing to win, or that don't make any sincere effort to ever improve. There's a guy called Labor on a game I play who plays hundreds and hundreds of ranked matches per season, but plays exactly the same today as he did a year or two ago. He's totally average, stagnant in rank, but keeps playing. Are any of you like Labor? If you are, what do you look for in a game? Even if you aren't, I'm curious. What kinds of games do you play? What types of experiences are you looking for? Why do you look for those experiences?

I have poor vision and I rely heavily on a Firefox plugin called Stylus to make websites readable - in particular the trend for low contrast and small text. That includes Tildes.

I updated it to v1.5.0 and now the styles I set for Tlldes no longer work - most other sites still appear to work but I've not checked them exhaustively.

I immediately tried rolling back a release or two (1.4.23 and 1.4.22) but those versions no longer work for any site. I tried randomly downgrading to even older versions but the same result. I think I'm stuck with the latest version..

I notice in the browser console there are 2 errors reported on Tildes e.g. on this page I see:

Content Security Policy: The page's settings blocked the loading of a resource at inline ("script-src"). new_topic:1:1
Content Security Policy: The page's settings blocked the loading of a resource at inline ("style-src"). new_topic:1:1

Using the Firefox Developer tools Inspector - I see my style settings for Tildes injected by Styuls (after the body) but they do not work any more.

Since only Tildes so far is not working with my Stylus settings I guess there is also a recent change to Tildes that is causing Stylus to fail.

This is a rather serious issue for me as all the colour options in the setting are low contrast and cause eye strain which becomes painful without the Stylus settings.

Thanks for any help you can offer.

Mostly the title. I have experience with Python, and I was thinking of learning more about data compression. How should I proceed? And what are some good books I could read, both about specifics and abstracts of data compression, data management, data in general.

Some people have mentioned they'd like to have some sort of weekly track-sharing thread, so let's have a little fun and find some good music in the process.

Everybody's got that playlist somewhere with all of your favorite earworms - the songs you put on repeat to the point where you annoy the hell out of everyone else in the room because you love them so much. Let's collect some of those earworms here and see what we can come up with.

In particular, let's go for the uplifting kind - feel good music. When the thread settles down I'll pull these all together in a nice playlist and share that here as a separate link submission.

Any time period, any genre, any style, popular, obscure, or even your own music, it's all good - just as long as it's positive energy and you can't stop spinning it. If you're on mobile, don't worry about making it into links, others can linkify it for you (and eventually, Tildes can do that automatically to make this all easier in the future). Share as many as you've got. If you've already got a playlist like this for yourself, you can share that too. ;)

Oh, and don't worry about nebulous 'standards' or if people will like it. If you like it, that's all that matters. Don't overthink it!

Edit: Almost forgot, feel free to make suggestions for the topics of upcoming share threads in the next few weeks!

Preface

Different projects have different use cases that can ultimately result in common solutions not suiting your particular needs. Today I'm going to diverging a bit from my more abstract, generalized topics on code quality and instead focus on a specific project structure example that I encountered.

Background

For a while now, I've found myself being continually frustrated with the state of my project configuration management. I had a single configuration file that would contain all of the configuration options for the various tools I've been using--database, API credentials, etc.--and I kept running into the problem of wanting to test these tools locally while not inadvertently committing and pushing sensitive credentials upstream. For me, part of my security process is ensuring that sensitive access credentials never make it into the repository and to limit access to these credentials to only people who need to be able to access them.

Monolithic Files Cause Monolithic Pain

The first thing I realized was that having a single monolithic configuration file was just terrible practice. There are going to be common configuration options that I want to have in there with default values, such as local database configuration pointing to a database instance running on the same VM as the application. These should always be in the repo, otherwise any dev who spins up an instance of the VM will need to manually tread documentation and copy-paste the missing options into the configuration. This would be incredibly time-consuming, inefficient, and stupid.

I also use different tools which have different configuration options associated with them. Having to dig through a single file containing configuration options for all of these tools to find the ones I need to modify is cumbersome at best. On top of that, having those common configuration options living in the same place that sensitive access credentials do is just asking for a rogue git commit -A to violate the aforementioned security protocol.

Same Problem, Different Structure

My first approach to resolving this problem was breaking the configuration out into separate files, one for each distinct tool. In each file, a "skeleton" config was generated, i.e. each option was given a default empty value. The main config would then only contain config options that are common and shared across the application. To avoid having the sensitive credentials leaked, I then created rules in the .gitignore to exclude these files.

This is where I ran into problem #2. I learned that this just doesn't work. You can either have a file in your repo and have all changes to that file tracked, have the file in your repo and make a local-only change to prevent changes from being tracked, or leave the file out of the repo completely. In my use case, I wanted to be able to leave the file in the repo, treat it as ignored by everyone, and only commit changes to that file when there was a new configuration option I wanted added to it. Git doesn't support this use case whatsoever.

This problem turned out to be really common, but the solution suggested is to have two separate versions of your configuration--one for dev, and one for production--and to have a flag to switch between the two. Given the breaking up of my configuration, I would then need twice as many files to do this, and given my security practices, this would violate the no-upstream rule for sensitive credentials. Worse still, if I had several different kinds of environments with different configuration--local dev, staging, beta, production--then for m such environments and n configuration files, I would need to maintain n*m separate files for configuration alone. Finally, I would need to remember to include a prefix or postfix to each file name any time I needed to retrieve values from a new config file, which is itself an error-prone requirement. Overall, there would be a substantial increase in technical debt. In other words, this approach would not only not help, it would make matters worse!

Borrowing From Linux

After a lot of thought, an idea occurred to me: within Linux systems, there's an /etc/skel/ directory that contains common files that are copied into a new user's home directory when that user is created, e.g. .bashrc and .profile. You can make changes to these files and have them propagate to new users, or you can modify your own personal copy and leave all other new users unaffected. This sounds exactly like the kind of behavior I want to emulate!

Following their example, I took my $APPHOME/config/ directory and placed a skel/ subdirectory inside, which then contained all of the config files with the empty default values within. My .gitignore then looked something like this:

$APPHOME/config/*
!$APPHOME/config/main.php
!$APPHOME/config/skel/
!$APPHOME/config/skel/*
# This last one might not be necessary, but I don't care enough to test it without.

Finally, on deploying my local environment, I simply include a snippet in my script that enters the new skel/ directory and copies any files inside into config/, as long as it doesn't already exist:

cd $APPHOME/config/skel/
for filename in *; do
    if [ ! -f "$APPHOME/config/$filename" ]; then
        cp "$filename" "$APPHOME/config/$filename"
    fi
done

(Note: production environments have a slightly different deployment procedure, as local copies of these config files are saved within a shared directory for all releases to point to via symlink.)

All of these changes ensure that only config/main.php and the files contained within config/skel/ are whitelisted, while all others are ignored, i.e. our local copies that get stored within config/ won't be inadvertently committed and pushed upstream!

Final Thoughts

Common solutions to problems are typically common for a good reason. They're tested, proven, and predictable. But sometimes you find yourself running into cases where the common, well-accepted solution to the problem doesn't work for you. Standards exist to solve a certain class of problems, and sometimes your problem is just different enough for it to matter and for those standards to not apply. Standards are created to address most cases, but edge cases will always exist. In other words, standards are guidelines, not concrete rules.

Sometimes you need to stop thinking about the problem in terms of the standard approach to solving it, and instead break it down into its most abstract, basic form and look for parallels in other solved problems for inspiration. Odds are the problem you're trying to solve isn't as novel as you think it is, and that someone has probably already solved a similar problem before. Parallels, in my experience, are usually a pretty good indicator that you're on the right track.

More importantly, there's a delicate line to tread between needing to use a different approach to solving an edge case problem you have, and needing to restructure your project to eliminate the edge case and allow the standard solution to work. Being able to decide which is more appropriate can have long-lasting repercussions on your ability to manage technical debt.