retrodaredevil

Good stuff! I'm excited to check it out. I see a lot of other comments here wondering if others still use this... I like MusicBrainz Picard because it makes it really easy to see everything that's going on at once. View the tags, see changes that will be applied, easily switch between configuration profiles, and easily browse to the recording or release page in MusicBrainz.

The manual workflow might not be for everyone, but it's a fantastic GUI application.

I mean, I guess you could say stuff like get(Object) and contains(Object) aren't type safe, but I've never seen that as an issue in practice. Plus there are some ErrorProne checks that'll tell you if you're doing something wrong in regards to calling contains(Object) with the wrong type.

NullAway with JSpecify annotations are a really good way to add null safety to Java applications. Even enforces nullability at the generic level.

Oh yeah, I agree with you on all those points. I guess what I'm trying to say is I feel like modern Java pushes you towards writing null-safer code than something like Go. I don't see the same push in modern Go.

This blog post is a great reference for "when to actually handle the nil case in Go" (and I think these ideas can even be applied to other languages), but there's nothing pushing anyone towards doing it the correct way in Go other than a documented team coding standard or an AGENTS.md/SKILL.md file.

In older Java applications there's also nothing pushing developers towards "correct null handling." A legacy Java application has a bunch of POJOs with getters and setters where all the fields start as null. That's why I think using records+JSpecify+NullAway is incredibly powerful in a Java project. NullAway really forces you to correctly and fully null annotate your code.

Self-discipline is great but static analysis tools actually enforce doing something "the right way." Things slip through code review, but a failing pipeline has to be fixed before the merge can happen.

The design of error handling in Go is interesting because they wanted to force people to actually handle errors by returning them as values, but then you as the programmer have to decide whether an error should be returned or a panic should be used.

It reminds me of the original intention of checked exceptions in Java: checked exceptions are for things you force the caller to handle, unchecked exceptions are for "you the programmer messed up". In reality checked exceptions are pretty unpopular and can't be used in many situations, so people fall back to unchecked exceptions.

If we equate unchecked exceptions with panics in Go, falling back to panics would be an anti-pattern in many cases.

NPEs in Java have become rarer and rarer recently with the introduction of records (to easily create immutable classes, which are easier to validate for null against). Plus JSpecify annotations get you null denotation that's almost as good as Kotlin's. Combine that with NullAway are you have compile time null safety. Go has nilaway [0]. One interesting thing about nilaway is that you don't null-annotate your code, it just detects nilness when you run nilaway. That makes nilaway a decent tool to get feedback right away, but it doesn't force you to document the intention behind parameters and fields for whether they are nullable or not, which I would argue is one of the advantages to null-annotating Java code with JSpecify.

[0] https://github.com/uber-go/nilaway

The thing is, the EU needs to be able to not only sell that the regulation they propose is good to the public, but also not piss off the US administration.

Most people are too non-technical to understand why this is a bad thing even when it's explained to them. Plus, whatever administration is in power in the US has a lot of influence.

Trump has already said that he wouldn't tolerate regulation that affects American companies [1], painting regulation that happens in another country as something that will affect US citizens. (I mean if you use the GDPR as an example, it's not wrong. Think of cookie pop ups while browsing the web in the US)

I would like the the EU would go harder with their regulations, because it usually results in other countries or states following their lead, but I dont see that happening. Regulation has been painted as "bad", and we have at least 3 more years until that changes.

[1] https://www.cnn.com/2026/01/12/tech/us-eu-tech-regulation-fi...

Adding null checks where they aren't needed means adding branching complexity. It means handling cases that may never need to be handled. Doing all that makes it harder to understand "could this variable ever be null?" If you can't answer that question, it is now harder to write code in the future, often leading to even more unnecessary null checks.

I've seen legacy code bases during code review where someone will ask "should we have a null check there?" and often no-one knows the answer. The solution is to use nullability annotations IMO.

It's easy to just say "oh this is just something a junior would say", but come on, have an actual discussion about it rather than implying anyone who has that opinion is inexperienced.

The big news here is that you now need a premium subscription to use any of Spotify's APIs. This means that if you wish to use Spotify's APIs to more easily share music with others, you must have a premium subscription.

What's gross to me is the language:

> all newly created Development Mode Client IDs will be created under the updated Development Mode rules and will have the following restrictions applied by default > Development Mode use will require a Spotify Premium account

The language acts as if it's possible to have some sort of non-development mode application. If you look further, you'll see that a non-development mode application must be owned by an organization with more than 250k users.

This is a well put together list. One thing that frustrates me is that not all tooling respects mailmap. IntelliJ has an open feature/bug request for integrating mailmap into its git functionality. Additionally, the .git-blame-ignore-revs is more of a convention because you still have to manually configure that to be the file name to use.

Yeah I've noticed the IDEs have this ability, but I think tooling outside of IDEs that can be applied in a repeatable way is much better than doing a bunch of mouse clicks in an IDE to change something.

I think the two things that make this a big deal are: callable from the command line (which means it can integrate with CI/CD or AI tools) and like I mentioned, the fact this is built into Go itself.

I think tooling that can modify your source code to make it more modern is really cool stuff. OpenRewrite comes to mind for Java, but nothing comes to the top of my mind for other languages. And heck, I into recently learned about OpenRewrite and I've been writing Java for a long time.

Even though I don't like Go, I acknowledge that tooling like this built right into the language is a huge deal for language popularity and maturity. Other languages just aren't this opinionated about build tools, testing frameworks, etc.

I suspect that as newer languages emerge over the years, they'll take notes from Go and how well it integrates stuff like this.

I work full time as a software engineer, and I also spend time writing code on side projects. I love working on my side projects because it means I get to spend a bunch of time learning the quirks of whatever tooling and frameworks I decide to use. I often develop opinions and personal standards that I bring with me to future side projects (and sometimes $dayjob), although I've never quite stood up all the components of one of my projects "quickly". I'll always find something to tinker with and learn about, which I think is acceptable for my personal projects, desirable even.

As I get more personal projects under my belt, I believe I'll be able to stand up projects more and more quickly, although it's never perfect. Even though I've been using a similar stack among my side projects for a couple of years now, dependencies get outdated. Sometimes you gotta jump to a new major version. Sometimes you wanna try out the "new way".

I like the idea of building up my own personal stack of tooling, frameworks, and patterns that I use, and could even encourage the use of at $dayjob, but for the reasons outlined above, I agree with the conclusion of the article, which is that an "IKEA of software" doesn't exist currently.

For now I'll keep happily tinkering in my side projects. This article was a good read.

That's simply not true. If you scratch a vinyl record, you've introduced a defect to it. If you scratch a CD, it's probably fine. Some CD players don't like scratched CDs, but for the most part CDs are very durable.

Plus if you damage a CD, simply rip it and burn it to a CDr. (did I mention that ripping a damaged CD usually works?)

You are right about vinyl sleeves being more attractive, though. I think that's its main selling point.

I don't really like that "enshittified" is being used here. You could argue that Plex, MinIO or Mattermost is being enshittified, but definitely not self hosting as a whole.

Enshittification also usually implies that switching to an alternative is difficult (usually because creating a competing service is near impossible because you'd have to get users on it). That flaw doesn't really apply to self hosting like it does with centralized social media. You can just switch to Jellyfin or Garage or Zulip. Migration might be a pain, but it's doable.

You can't as easily stop using LinkedIn or GitHub or Facebook, etc.

There are a lot of incentives to lock people up. Cheap labor is one of them. We should support incentives such as "keeping society safe", but incentives such as "profits and cheap labor" are incentives that may actually incentivize locking up innocent people.

So it's not about which one is worse, it's about not supporting something that could lead to corruption or an unfair system.

I'm building an application that can communicate with my Plex server, and also communicate with APIs like MusicBrainz and Spotify. From there I want to be able to track my Plex music rating history, and export playlists on Plex to Spotify for easier sharing with others.

There don't seem to be many automated tools out there that fit my need for this, so building out my own solution I have complete control over makes sense. It's a lot of fun to build this out exactly as I want to, rather than trying to configure a bunch of tools that I'm not familiar with and that don't meet my needs exactly.

The tooling I'm building up around this should hopefully make it easier for myself to get my playlists and track ratings off of Plex if I ever decide to abandon it for music listening.

Raspberry Pi is a bad choice for any application that frequently writes data to disk. Most Home Assistant setups will often have historical tracking of at least one data point, which means that it would be constantly writing to disk.

If you get a high quality SD card with more storage than you'll ever need (64GB, 128GB), you can have a stable system for a while until the SD card becomes corrupt. The larger SD cards help with longevity because it means the SD card can spread writes out over a larger area, which means it'll take longer for the SD card to go bad.

Make sure to always have RAM logging enabled on your Pi! DietPi defaults to RAM logging.

I agree with you, however convincing an entire team of devs to explicitly separate the interface of impure parts of code is very difficult.

If you introduce a mocking library to the test portion of the codebase, most developers will start to use it as a way to shortcut any refactoring they don't want to do. I think articles like this that try to explain how to better use mocks in tests are useful, although I wish they weren't necessary.

I have written production Java code, but no production Go code. I think you skipped over the commenter's main point while replying to them: you need to be able to have a good mental model of the code.

A few well defined interfaces have the advantage of being easy to understand and see usages around the codebase without the overhead of many different variants of an interface. This is extremely important if you are not familiar with a given codebase.

I'm not against segregated interfaces, but I feel like over abstracting can result in code that's harder to understand. There's a balance to be had and thought should go into introducing new interfaces, especially when working on a project with many other devs contributing.

I'm a Java dev, so I'm biased. I love being to easily understand and reason about the type system. I understand that an interface is about a set of behaviors, but when I've worked with Go code I've found it much more difficult to get my IDE to point out all the different ways some interface could be implemented. I see the advantages that Go style interfaces bring, but I personally find it harder to keep a mental model when working with Go.

Checked exceptions you cannot handle in Java are designed to be caught and rethrown (usually wrapped in your own specific checked exception or some runtime exception).

Proper exception handling in Java can feel verbose. In general you should not be adding checked exceptions to method signatures to make the compiler happy. You should be catching them and rethrowing if you cannot handle them.

Mostly I just use Picard it for initial tagging, which usually only needs to happen once. Sometimes Picard has changes it wants to do such as updating to a higher resolution cover art, or to refer to a different MBID after a merge.

Yeah, not much to maintain, but Picard does keep my tags up to date if necessary.

A maintain my own digital music collection. The only two tools I use for maintaining the CD portion of my collection are k3b and MusicBrainz Picard. k3b can rip to flac and it will on embed metadata present on the CD itself. Then after I rip it, I add it to Picard.

I use the "lookup CD" feature in Picard, which gives me a selection of releases to choose from. Among the choices, I usually see a release matching the catalog number on my CD's case. When I don't see a matching release, I will typically add the disc ID to an existing release, or I will create a new release, or sometimes even creating a new release + new release group and add the necessary metadata to MusicBrainz.

I haven't tried any automatic tagging process like the ripping program the article talks about does, mostly because I want to use Picard to make sure the metadata is correct or contribute to MusicBrainz if it isn't.

I like MusicBrainz a lot because applications like Plex use it very well to group release groups together and will (usually) deduplicate identical recordings so that identical tracks can share a rating. It's a really great database and is kept up to date pretty well.

It seems that the list of destination IPs would then be determined by whatever the domains listed resolve to (I assume). Since it's trivial to update DNS records, I wonder if they could lead to automated blocking of whatever IP those domains point to.

With that in place, I wonder if that could ever be abused by these pirate sites. Imagine temporarily pointing your pirate site domain name at a valid IP address. When you do that, in theory ISPs (and now VPNs) would automatically block perfectly valid IPs.

This would only happen if the owners of the pirate site domains actually try to do something malicious like that, but I know there are instances in the past of ISPs blocking cloudflare IPs (which is a separate issue, but the scenario I just made up reminds me of it).

When these VPN providers comply with these court orders, do they only implement blocking at the DNS level? Couldn't you still use these VPNs, but use a DNS provider that isn't censored?

I've started to exclusively install DietPi on all my Raspberry Pi devices. It has great defaults including RAM log. Additionally, it's not limited to Raspberry Pis, it can be installed on a range of SBCs.

I have a Makefile that runs certain stow commands depending on the hostname of whatever machine I'm on. I keep machine specific files in their own directory, and I also have a shared directory for shared dotfiles. It works well for my needs.

I'd agree that when CDs get scratched there will be parts of the CD that some players can no longer handle. The great thing is that when your CD gets scratched to where your old CD player can no longer play it, there's a good chance your computer can rip the CD without issue so you can burn it to a CD-r.

It's not a perfect solution, but in most cases, the raw data on the CD stays intact in one way or another.

As a Plex and Plexamp user, I'm curious about a few features: mobile support doesn't seem to be mentioned. Is there a mobile app? Are smart playlists a feature? What about gapless playback? Can you elaborate on the 5 star system for rating tracks, albums and artists?

Overall the feature set really speaks to me, as I have a bunch of CD rips tagged using MusicBrainz Picard with a couple of deluxe and non-deluxe versions thrown in of the same album. I think I'll have to give it a try either way because you're touching on a niche Plex just doesn't seem to care about.

What's the size of your array?

I've been giving this a try for the past day and thought I'd talk about my experience setting it up in IntelliJ's terminal.

First, if you're going to use this in the IntelliJ terminal, make sure to use the dark-mode flag. Honestly the IntelliJ terminal doesn't do the best at rendering Aider's output because IntelliJ's terminal doesn't really like things that update frequently. It still works pretty well and Aider has nicely formatted output in general.

Using llama3.1 8B locally is OK at best, and makes incorrect changes at worst (the 8B model isn't really recommended in Aider's documentation, anyway). I only have 8GB of vram, so I can't really run any better models locally. I gave gpt-4o a try and it works pretty well at editing code. I probably won't pay for OpenAI access forever, though. https://aider.chat/docs/llms.html says that Gemini 1.5 Pro can be accessed for free and works decently, so maybe I'll give that a try next.

The git integration is useful, but I don't really like that Aider will commit to my current branch to make it easy to undo its changes. I like changes being easy to undo, but I don't really want to have to squash these changes before pushing. I disabled the auto commits, and now I just have to make sure that I don't let Aider run wild on any file with a bunch of changes on it.

Maybe the automatic commits work for others' workflow, but it won't work for mine. I'll keep playing with this because it seems really cool.