221 results for "":
color npm package compromised
On September 8 2025, around 13:00 UTC, someone compromised Josh Junon’s npm account (qix) and started publishing backdoored versions of his package.
Someone noticed and let Josh know:
Josh confirmed he’d gotten pwned by a fake 2FA (two-factor authentication) reset e-mail:
The phishing e-mail came from npmsj.help (registered 3 days prior) and claimed
users had to reset their 2FA:
Twitch fell behind
So you want to do live streams. Are you sure? Okay. Let’s talk about it.
Let’s talk numbers
Being a “content creator” (sorry for those who hate that term) is a job, for sure, and many people do it, successfully, full-time, they pay rent with it etc.
Platforms like Twitch & YouTube would have you think that, if you put in enough effort, you can grow your channel from nothing to 🎉 profitable ✨ in just a few short years.
FFI-safe types in Rust, newtypes and MaybeUninit
sam, homebrew-mingw, etc.
I want to write blog posts, but right now I have too much to do.
So instead, here are bullet points:
I wrote an ooc tool named sam, which helps you keep your git repos up-to-date, and helps to remind you what to push when switching workstations. It’s pretty neat, and portable.
A while ago, I started working on homebrew for Windows, or rather, for MinGW+MSYS. Provided you have msysgit and Ruby in your PATH, it’ll let you brew install most packages. I’ve tested a few dozen, send in your pull requests anytime.
Day 15 (Advent of Code 2022)
The day 15 puzzle falls into the “math puzzle” territory more than “let’s learn something new about Rust”, but since several folks asked if I was going to continue… let’s continue.
The sample input is as follows:
Sensor at x=2, y=18: closest beacon is at x=-2, y=15
Sensor at x=9, y=16: closest beacon is at x=10, y=16
Sensor at x=13, y=2: closest beacon is at x=15, y=3
Sensor at x=12, y=14: closest beacon is at x=10, y=16
Sensor at x=10, y=20: closest beacon is at x=10, y=16
Sensor at x=14, y=17: closest beacon is at x=10, y=16
Sensor at x=8, y=7: closest beacon is at x=2, y=10
Sensor at x=2, y=0: closest beacon is at x=2, y=10
Sensor at x=0, y=11: closest beacon is at x=2, y=10
Sensor at x=20, y=14: closest beacon is at x=25, y=17
Sensor at x=17, y=20: closest beacon is at x=21, y=22
Sensor at x=16, y=7: closest beacon is at x=15, y=3
Sensor at x=14, y=3: closest beacon is at x=15, y=3
Sensor at x=20, y=1: closest beacon is at x=15, y=3
Designing and implementing a safer API on top of LoadLibrary
It’s refactor time!
Our complete program is now about a hundred lines, counting blank lines (see the end of part 3 for a complete listing).
While this is pretty good for a zero-dependency project (save for
pretty-hex), we can do better.
First off, concerns are mixed up. In the same file, we:
- Expose
LoadLibraryA/GetProcAddress - Expose the Win32 ICMP API
Day 10 (Advent of Code 2020)
Day, 10! Day, 10!
Okay, Day 10.
Again, the problem statement is very confusing - but what it all boils down to is this. We have a list of numbers:
16
10
15
5
1
11
7
19
6
12
4
To which we need to add 0 and whatever the maximum was, plus three:
16
10
15
5
1
11
7
19
6
12
4
0
22
From there on, if we take them in order, we’ll have gaps of 1 and gaps of 3:
Next power of two
While looking to write a pure ooc version of ftgl, I was reading the source of ftgl-gl3 and I stumbled upon this piece of code:
static inline GLuint NextPowerOf2 (GLuint in )
{
in -= 1 ;
in |= in >> 16 ;
in |= in >> 8 ;
in |= in >> 4 ;
in |= in >> 2 ;
in |= in >> 1 ;
return in + 1 ;
}
This is needed because dealing with power-of-two textures (32x32, 64x64, 128x128, etc.) is more efficient with OpenGL (some implementations don’t even support non-power-of-two textures!).
Day 4 (Advent of Code 2022)
Part 1
Let’s tackle the day 4 challenge!
In this one, we get an input like this:
2-4,6-8
2-3,4-5
5-7,7-9
2-8,3-7
6-6,4-6
2-6,4-8
Each line has two ranges: the first line has ranges containing 2, 3, 4, and 6, 7, 8. We must count how many pairs have ranges where one fully contains the other.
In Rust, we can express this with “inclusive ranges”
(std::ops::RangeInclusive),
and those implement Iterator, so we can do:
Abstracting away correctness
I’ve been banging the same drum for years: APIs must be carefully designed.
This statement doesn’t resonate the same way with everyone. In order to really understand what I mean by “careful API design”, one has to have experienced both ends of the spectrum.
But there is a silver lining - once you have experienced “good design”, it’s really hard to go back to the other kind. Even after acknowledging that “good design” inevitably comes at a cost, whether it’s cognitive load, compile times, making hiring more challenging, etc.