One of the coolest things I've seen in a while: "From Silicon to Darude Sand-storm: breaking famous synthesizer DSPs", reverse-engineering and emulating *the* synth that shaped late 90s/early 00s EDM. Bridging #hardware, #DSP, some #maths, #programming and, of course, #music.
Advice to young engineers: Read a lot of code. Several more times than you write. Ideally not the code internal to company. Go find where the state of the art is, study it.
Having worked in the docker codebase early in my career gave me a lot of skill boost long-term.
UK online stores don't want me to buy things from them because I have no UK phone number (yet). Even Vodafone won't sell me a mobile subscription without providing them with a valid UK phone number. Get it?
Hey @Eurostar! Not sure how the My Thalys World to Eurostar conversion went, but... I had Club level until 31/01/24 and amassed 3308 status points already (likely more, since last rides weren't processed yet). (1/2)
Now I have the Carte Blanche level (cool!), which would've "cost" only 2900 points on 31/01/24. However, the level will now expire on 01/10/24 instead, and my status points are reset to 0. That can't be right, isn't it?! (2/2)
Coincidentally, I've been experimenting recently booting a #RaspberryPi 2 using UEFI with systemd-boot on #Debian#Linux (armhf) using the very same approach.
Why do #Linux distributions insist on using an initrd to boot, while 80 % of machines out there (not even counting embedded/Android) don't need it to boot at all, assuming some drivers (nvme, ahci, maybe some others) were compiled in?
If you like making #music, spend some time with the Bespoke #synth, a DAW quite unlike the traditional ones. With some good samples and VST/LV2 plugins, lots of fun to create patches! #Free#software, runs on #Linux. See bespokesynth.com
Using #Jekyll as a #blog engine, and writing about #Haskell? With some simple steps, you can run and test the code in your articles to make sure everything works. See nicolast.be/various/jekyll-l… for a walkthrough!
#Haskell tip: if you have a data-type with `TVar`s inside, parametrize it over a `cell` type, e.g., `data T' cell = T' { t :: cell Int }`. Now `type T = T' TVar` and `type FrozenT = T' Identity` allows to write `snapshot :: T -> STM FrozenT` which is quite useful in tests.
"Pas in het afvalverwerkingsbedrijf, waar de inhoud van de zakken verder gescheiden wordt, wordt het gescand. Het #statiegeld van elk herkend blikje of flesje wordt dan teruggestort op de rekening van de koper."
Dus blikjes mogen niet meer platgedrukt worden? 😬
If you use the #Haskell `ReaderT Env IO` pattern with some STM variables in your `Env`, here's a trick to simplify writing transactions across them: discourse.haskell.org/t/stm-…
It relies on some combinators to access the vars, and hoisting `ReaderT Env STM` into `ReaderT Env IO`
Hey @GitHub, I'm getting messages in Discussions that are clearly written by something GPT (content is fine,in a way,but doesn't contribute to the conversation and just states some obvious facts). All accounts look very similar (joined last month, 2 repos). What to do about this?
100x this:
- There may be no "community" (yet?), but there *will* be new team members who need to get acquainted with the project.
- Design and code quality *does* matter so write as if the whole world is watching.
- VCS hygiene *is* important, your future self will thank you.
ALT # The "open source native" principle for software design
This post summarizes a software design principle I call the "open source native" principle which I've invoked a few times as a technical lead. I wanted to write this down so that I could easily reference this post in the future.
The "open source native" principle is simple to state:
> design proprietary software as if you intended to open source that software, regardless of whether you will open source that software
I call this the "open source native" principle because you design your software as if it were a "native" member of the open source ecosystem. In other words, your software is spiritually "born" open source, aspirationally written from the beginning to be a good open source citizen, even if you never actually end up open sourcing that software.
You can't always adhere to this principle, but I still use this as a general design guideline.
Many #opensource/free #software projects deliver high-quality software (maybe not products, but that's another matter), so yeah, maybe there's something to learn/adopt in your org? I've been advocating "#innersource" development throughout my career, with very positive outcomes.