royjacobs

They didn't make them themselves, but they are newly manufactured keycaps, yes.

There's nothing that makes you feel old more quickly than seeing someone trying to rebuild the sort of technology you implemented in the era that they were actually modern.

I'm not sure I agree with the article. It seems to argue against the point of having a message queue and suggests doing a bespoke reimplementation of a queue using a database.

However, all of the things listed in the explicit work queue section can be done using regular message queues as well, so...why bother reimplementing it yourself?

It can be useful to distinguish between domain objects and objects that you use at the edge of your service, like on the API. They might have different annotations or you might want to evolve them differently, e.g. your domain objects might change while you want to keep your API the same so as not to break your consumers. Things like that.

I've never really understood the use case for these mapping generators. Every time I've seen them used (MapStruct in Java, AutoMapper in C#) the mapping configuration eventually ends up being so complex that just manually writing out the mapping would've been just as simple and arguably simpler to understand.

That's so cool! One of the ways I learnt programming in BASIC was by studying the program outputs next to the listings in those Creative Computing books. ELIZA was one my favourites, so thanks for doing the port all that time ago.

These devices are really fun. I used to have a Snoopy, which I played to death. Tried it recently and it still works absolutely fine.

I fondly remember playing this game. I think I got it off one of those CP Verlag magazines-on-disk.

Watching the YouTube video the sound effects immediately trigger a bunch of nostalgia, whereas the random particles that kill you trigger a bunch of frustration :)

"Haven't needed to try the WiFi on it yet. Only use one screen, not sure why I'd need two."

If you never use WiFi or two screens then maybe you shouldn't dismiss other people's issues with Linux as being unusual.

Perhaps you could provide some initial arguments why they should?

I didn't realise I was not allowed to set my own bars, though :)

There is a distinction between 'working code' and 'working code that runs at interactive frame rates in a severely memory-constrained environment'.

Let's not underhype it, either: It seems you are underestimating the impact that Doom had on PC gaming when it came out. Using BSP trees to perform zero overdraw rendering definitely was not something that had been done before on consumer level hardware and it can definitely be argued that applying them this way for Doom was a stroke of genius.

Other charging options are allowed, it's just that there should _also_ be a USB-C option.

At least you don't have to write your own DOS extenders nowadays :)

This is extremely convenient and I'll be sure to add an SX-64 to my keychain.

I tried using that a few years ago but kept running into miscompiled code. Has it improved since then?

What does this comment mean?

This is a super fun project to play around with. I'm currently trying to build a C64 sprite multiplexer in mostly straight C++ using LLVM-MOS and while it's definitely not going to be the most optimized multiplexer out there, I'm finding it mostly adequate performance-wise.

Whereas it's probably a long way away from being able to use this for democoding due to the mostly cycle-accurate nature of the effects, for creating homebrew games and utilities this is really quite suitable: write high-level logic in C or C++ (or any language supported by LLVM really) and sprinkle in some inline assembly here and there for the really performance critical parts.

The code that is being generated is already quite good and (on first glance) looks better than what's coming out of cc65, for instance.

There's also rust-mos which uses LLVM-MOS to compile Rust code. It unfortunately still has some issues (e.g. [1]) but that is looking really promising as well.

Kudos to all involved :)

[1] https://github.com/mrk-its/rust-mos/issues/16

Right, I think your assumption is correct - it just happens to align. Kudos for organising your collection so well, though :)

Are these folders actual folders on your disk, though? Last time I checked I could use Navidrome to browse folders, but it would actually be browsing through albums instead.

Ah, very interesting to read about Subsonic being used here. I was in the market for a similar setup a while ago and tried a bunch of different servers. Navidrome was clearly one of the better ones but didn't seem to support folder-based navigation, which I want to use (since most of my music is not structured as album-per-folder but rather as playlist-per-folder).

Like a good HN user I ended up writing my own Subsonic compatible server [0]. It also does things mentioned in this blog post series, like automatically grab cover art and metadata from Musicbrainz/CoverArtArchive, Discogs and last.fm. I haven't officially released it yet since it's missing a few features (most notably transcoding, documentation and support for deleting files) but looks like it might be worthwhile to spend that effort. If you're feeling brave, you can compile it from source or grab the Docker edge image[1].

It looks like I missed evaluating https://github.com/sentriz/gonic though, so I might give that a go as well.

[0] https://github.com/datatrash/beatlocker [1] https://hub.docker.com/r/datatrash/beatlocker-server

I mean, a GAT is just a monoid in the category of endofunctors, after all.

You might also enjoy llvm-mos, which allows you to use very decent versions of clang on the 6502!

https://llvm-mos.org/wiki/Welcome

I use JetBrains products seriously and have been quite enjoying the new UI. Would you care to explain why everything is now fucked up according to "everyone"?

You say this is a trend in modern day blogging yet the article is from 2011. Also, I'm not sure Hanselman needs to brag to build his brand, it's pretty well established I'd say.

You might also enjoy the country version, done by the original artist: https://m.soundcloud.com/jugi/onward-giddy-up-by-yzi

If you want to go a bit more hardcore (no AMOS-shaming btw), there's also an excellent Amiga VSCode extension written by Bartman/Abyss. [0] It has full debugging, profiling, etc. It's quite insane.

And it's probably a good time to also plug my 6502 assembler again, which has really decent VSCode support as well. [1]

[0] https://github.com/BartmanAbyss/vscode-amiga-debug

[1] https://mos.datatra.sh

The programming model reminds me of Rob Eisenberg's older attempts at building UI toolkits ([0]). I don't recall if that was fully async or 'just' using a coroutine/generator-style approach, but it feels similar.

I'm not sure the complexity of doing everything using async constructs is worth it, though. Large-scale UI's built in Qt or Javascript are mostly single threaded anyway, but it's still worthwhile to explore so kudos for that. Looking forward to seeing how far you get.

[0] https://github.com/Caliburn-Micro/Caliburn.Micro

No, there's no requirement for any kind of source control at all. If you do have source control in your company (and, if so, welcome to the 1990s!) you can set it up in such a way that all your repos get scanned for metadata that gets ingested into the software catalog. There's implementations for GitHub and Gitlab (I built that one at $PREV_JOB) and others. Also, other kind of metadata, like user and group information, can come from sources like LDAP, Azure AD, etc.

To be clear, Backstage is not an alternative to Gitea, Github or anything like that. It's not a source code repository hosting tool.