Programming

Like ngl the kernel lies to everyone. The memory is faked, the file system is faked, etc. Its all abstractions after abstractions. Each process thinks its alone and has the cpu and memory to itself while the kernel is saying "sure you do buddy" to each of those poor processes. The user that uses the file system asks the disk where his homework folder is and the disk has no clue what they're talking about since the disk isn't aware about the concept of files and filepaths. That's all faked and abstracted away by the kernel. This whole time the kernel has been part of one big lie and decieved all of us.

I gathered this data from the two most comprehensive sources out there:  and .

Here's a quick summary of the findings below:

• There are 29.5% more tech job openings today than the low hit last March, and this positive trend has been largely steady

• The YoY number of average daily tech layoffs has declined by roughly 20%

Notes on the stats below: the difference in total numbers is due to TrueUp's much larger dataset (it tracks more startups & non-US markets). Both still show a nice improvement --- the decline in average daily layoffs is around 24% on TrueUp and 14% on . Also, I rounded the figures to the nearest 1K.

• There are 211K open tech jobs today; there were 163K at the March 3, 2023 low. That said, the peak was 478K in April '22

• In 2023, there were 429K people laid off by 2,001 tech companies (an average of 1,175 people/day)

• So far in 2014, there have been 118K people laid off by 540 tech companies (an average of 891 people/day)

• In 2023, there were 263K people laid off by 1,191 tech companies (an average of 721 people/day)

• So far in 2014, there have been 81K people laid off by 287 tech companies (an average of 619 people/day)

If it doesn't feel like it's improving, hang in there. No market moves in a straight line...but at least the bumpy ride appears to be on the right track!

So we have a fairly new CTO thats pushing for various different process changes in dev teams.

Two of these is trunk based development and full time pair programming to enable CI/CD.

For context my team looks after a critical area of our platforms (the type where if we screw up serious money can be lost and we'll have regulators to answer to). We commit to repos that are contributed to by multiple teams and basically use a simplified version of Gitflow with feature branches merging into master only when fully reviewed & tested and considered prod ready. Once merged to master the change is released to prod.

From time to time we do pair programming but tend to only do it when it's crunch time where necessary. The new process basically wants this full time. Devs have trialed this and feel burned out doing the pair programming all day everyday.

Basically I ran my team on the idea of trunk based development and they're heavily against it including the senior devs (one of whom called it 'madness').

The main issue from their perspective is they consider it risky and few others don't think it will actually improve anything. I'm not entirely clued up on where manual QA testing fits into the process either but what I've read suggests this takes place after merge to master & even release which is a big concern for the team. Devs know that manual QA's capture important bugs via non-happy paths despite having a lot of automated tests and 100% code coverage. We already use feature flags for our projects so that we only expose this to clients when ready but devs know this isn't full proof.

We've spoken about perhaps trialing this with older non-critical apps (which didn't get much buy in) and changes are rarely needed on these apps so I don't see us actually being able to do this any time soon whereas the CTO (and leadership below) is very keen for all teams to take this all on by this summer.

With the newest set of bugfixes, the experimental is coming closer and closer to being usable!

The std built by the project is now functional enough to handle things like creating/writing to files, and writing to stdout / stderr.

This small snippet of Rust code:

use std::io::Write;
fn main(){
    println!("Hello from Rust to .NET!");
    std::fs::File::create("/tmp/rust_on_dotnet.txt").unwrap().write_all(b"Hi from Rust, .NET").unwrap();
    eprintln!("We are writing to stderr!");
}

Can now run without issues within the .NET runtime!

While this week has been a bit busy for me (first 3 final exams), I still made some progress in other areas too.

Besides this, I have also eliminated 2 memory corruption errors (one related to closures, one related to small constant values). Those issues were found using valgrind - a memory debuting tool, which I now use to verify the Rust code compiled for .NET behaves correctly (the runtime can run under valgrind, if the right flags are set).

I have also finished a round of extensive fuzzing (46 434 773 LOC of MIR test programs), which allowed me to find and patch many other issues (mostly related to floating-point numbers).

Some issues still remain (13 out of 10 000 generated tests still fail, and the fuzzing tool I use does not check for every kind of bug), but a lot more Rust code should now compile properly.

There is still a lot of work to do, but I wanted to share some of the progress.

Also, the project has reached 1024(2^10) stars on GitHub! So, I would like to thank people for the amazing reception my project has had!

If you have any questions/suggestions/whatever, feel free to ask.

On Twitter, there is a going on:
Pick any constant in your game code, multiply by 1000, and post the results.

I had fun making my entry! . Somehow, my photon-mapper still managed to produce recognizable results.

I guess most x1000 constants would totally break a game, but I was rather pleased with my experiment. The game felt like wandering the wastelands during a hydrogen bomb detonation. Interesting visuals!

Did you participate in the challenge? If so, let's share on this subreddit too!

• What My Project Does

This is a music video of the output of a Python program:

I'm the author of Automate the Boring Stuff with Python and I teach people to code. As part of that, I created something I call "scroll art". Scroll art is a program that prints text from a loop, eventually filling the screen and causing the text to scroll up. (Something like those BASIC programs that are 10 PRINT "HELLO"; 20 GOTO 10)

Once printed, text cannot be erased, it can only be scrolled up. It's an easy and artistic way for beginners to get into coding, but it's surprising how sophisticated they can become.

The source code for this animation is here: (read the comments at the top to figure out how to run it with the forbiddenzonecontrol.py program which is also in that repo)

The output text is procedurally generated from random numbers, so like a lava lamp, it is unpredictable and never exactly the same twice.

This video is a collection of scroll art to the music of "The Forbidden Zone," which was released in 1980 by the band Oingo Boingo, led by Danny Elfman (known for composing the theme song to The Simpsons.) It was used in a cult classic movie of the same name, but also the intro for the short-run Dilbert animated series.

• Target Audience

Anyone (including beginners) who wants ideas for creating generative art without needing to know a ton of math or graphics concepts. You can make scroll art with print() and loops and random numbers. But there's a surprising amount of sophistication you can put into these programs as well.

• Comparison

Because it's just text, scroll art doesn't have such a high barrier to entry compared with many computer graphics and generative artwork. The constraints lower expectations and encourage creativity within a simple context.

I've produced scroll art examples on

I also gave a talk on scroll art at PyTexas 2024:

I know everyone is different but im curious when Godot started to click for you. How often did you study it? What did you want to use it for? I just want to make silly games i can screen record and put into my animations. Any advice for someone who is still teaching themselves Blender everyday?

Any 2023 graduates who still haven't found a tech job? What are you guys up to?