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.

One thing (amongst many) that always bothered me in my 6+ years of using Reddit was their lax rules about posting clickbait articles and straight up misinformation. In my opinion this was something that contributed to the rise of radical communities and echochambers in the website.

In this post I'll talk about Clickbait, Unreliable studies, and Misinformation. I'll give examples for each one and suggest a way to deal with it.

Clickbait-

Let's start with the most benign one. These days most big websites use clickbait and hyperbole to gain more traffic. It's something that they have to do in order to survive in today's media climate and I sort of understand. But I think that as a community in Tildes we should raise our standards and avoid posting any article that uses clickbait, instead directly link to the source that the article cites.

An example would be: An article titled "Life on Mars found: Scientists claim that they have found traces of life on the red planet".

But when you read the original source it only states that "Mars rover Curiosity has identified a variety of organic molecules" and that "These results do not give us any evidence of life,".
(This may be a bad/exaggrated example but I think it gets my point across.)

On Reddit the mods give these kinds of posts a "Misleading" tag. But the damage is already done, most of the users won't read the entire article or even the source, and instead will make comments based on the headline.
I personally think that these kinds of posts should be deleted even if they get a discussion going in the comments.

Unreliable studies-

This is a bit more serious than clickbait. It's something that I see the most in subjects of psychology, social science and futurism.
These are basically articles about studies that conclude a very interesting result, but when you dig a bit you find that the methodologies used to conduct the study were flawed and that the results are inconclusive.

An (real) example would be: "A new study finds that cutting your time on social media to 30 minutes a day reduces your risk of depression and loneliness"
Link: https://www.businessinsider.com/facebook-instagram-snapchat-social-media-well-being-2018-11

At first glance this looks legit, I even agree with the results. But lets see how this study was conducted:

In the study, 143 undergraduate students were tested over the course of two semesters.

After three weeks, the students were asked questions to assess their mental health across seven different areas

Basically, their test group was 143 students, The test was only conducted for 6 months, and the results were self-reported.

Clearly, this is junk. This study doesn't show anything reliable. Yet still, it received a lot of upvotes on Reddit and there was a lot of discussion going. I only spotted 2-3 comments (at the bottom) mentioning that the study is unreliable.

Again, I think that posts with studies like this should be deleted regardless if there is a discussion going in the comments or not.

Misinformation-

This is in my opinion the biggest offender and the most dangerous one. It's something that I see in political subreddits (even the big ones like /r/politics and /r/worldnews). It's when an article straight up spreads misinformation both in the headline and in the content in order to incite outrage or paint a narrative.

Note: I will give an example that bashes a "left-leaning" article that is against Trump. I'm only doing this because I only read left-leaning to neutral articles and don't go near anything that is right-leaning. Because of this I don't have any examples of a right-leaning article spreading misinformation (I'm sure that there are a lot).

An example would be this article: "ADMINISTRATION ADMITS BORDER DEPLOYMENT WAS A $200 MILLION ELECTION STUNT"
Link: https://www.vanityfair.com/news/2018/11/trump-troops-border-caravan-stunt

There are two lies here:

1. Trump administration did not admit to anything. (The article's use of the word 'Admit' is supposedly justified with 'They indirectly admitted to it'. I personally think this is a bad excuse.)
2. Most importantly, the 200 million figure is pure speculation. If you go to the older article that this article cites, the 200m figure comes from a speculation that the operation could cost up to 200m if the number of troops sent to the border is 15,000 and they stay there for more than 2 months.
   In reality the number of troops sent was 8,500 and they stayed for only a few days/weeks.

A few days after this article was published it turned out that the operation costed 70 million. Still a big sum, still ridiculous. But it's almost a third of what the article claimed.

The misinformation in this example is fairly benign. But I've seen countless other articles with even more outrageous claims that force a certain narrative. This is done by both sides of the political spectrum.

Not only do I think that we should delete these kinds of posts in Tildes, in my opinion we should black list websites that are frequent offenders of spreading misinformation.
Examples off the top of my head would be: Vanity Fair, Salon.com, of course far right websites like Fox News, Info Wars and Breitbart.
A good rule in my opinion would be: If three posts from a certain website get deleted for spreading misinformation, that website should be blacklisted from Tildes.

In conclusion:
I think we should set some rules against these problems while our community is still in the early stages. Right now I don't see any of these 3 problems on Tildes. But if we don't enforce rules against them, they will start to pop up the more users we gain.

I'll be happy to know your opinions and suggestions on the matter!