A good place to start with kids that age is Scratch: https://scratch.mit.edu/
The visual programming style may turn off experienced programmers, but it's a full game engine, there is a big community of other kids out there, and at this stage, programming is about basic concepts like variables, conditions, loops and functions, which are all represented here. And of course, game development is about more than code: Scratch also lets you add sound and graphics, and has an easy to use actor model.
There's also a neat voxel-based RPG engine called RPG in a Box (https://rpginabox.com/).
For Python, there's pygame, which requires a lot more code, but let's you make sprite-based games in a "real" programming language, if that's more your speed. Python also has classic turtle graphics, but that doesn't usually get you very far for making games.
Finally: I've used all of these (and other) tools with kids in that age group, as a mentor at events like Hack The Future (https://hackthefuture.org/) and Hour of Code (https://hourofcode.com/). Look for an event like this in your area, they are really fun to attend!
What the article proposes is an extreme position, and while I don't agree that the entire web can work this way, a lot of it can. Look at the page you're currently viewing (hacker news): It's by no means a terrible experience, and yet it manages to check all the boxes: it has no javascript necessary for viewing (there is one function for voting, but that is non-essential), no proprietary plugins, no ads, no visual clutter, doesn't download fonts, no tracking, and if I just want to read content, no account is required.
So we see that it's not impossible to make sites that follow the goals of this "manifesto", and I would say that all of these non-features speaks in favor of the quality of HN.
Clearly, there are sites that do not follow these guidelines, and their business model makes it impossible for them to do so (Facebook, anyone?). As a consumer, which one of those would I rather use?
I believe the point was that you probably don't need the user to make an account. If they don't need an account, they have no password, and you need no email address, unless your true goal is to put as many people as possible on your mailing list and spam them.
This is a point that should have been made in the author's article. As it is, it presents a poorly defined problem without offering solutions (other than "be afraid").
Incidentally, this is where the idea of writing a journal paid of, because even though keys were getting corrupted in memory, the journal was fine, and after the bugfix, read back nicely and recreated the keys.
Don't you love it when you announce your project to the world, only to spot a massive bug immediately after? Let me reiterate everything I already said about people not using this for critical data, because it's apparently losing keys from time to time.
The source code is there for anyone to do whatever they like with it. Of course you could use this in-process and strip away the server logic, it's even split into source files to make that easy (nosql.[hc] are the files that implement the key-value store, everything else handles the fcgi requests).
It all depends on your stack. I think of a full-stack programmer as someone who can dive into any level of the application to fix something. If you have a classic app that is javascript in the front, PHP in the back, then he will need to be familiar with at least those two technologies.
If you are building on external technologies, like a classic LAMP stack, then it helps to know a bit about those, too. Because software has bugs, and sometimes that bug is in apache, in PHP itself, in the PHP memcache library, or in MySQL. And woe be unto you if you are the first person to run into that bug, because congratulations, now you get to diagnose and fix it. Especially if it's open source. If it's proprietary code, you're in a whole other terrible mess.
The more complex the technology stack that you are building on, the more likely that it has crippling bugs, and the less likely that you're still able to figure them out. So in some sense, there is a rationale for building my own NoSQL store: I understand every part of my stack, and I know how to debug it if it should go wrong.
It's a Raspberry 1 Model B, the 512 MB version. So with any luck, I will see how this code performs once it runs out of memory? https://imgur.com/gallery/XI3Rul6
I've got a RPi 2B sitting here that I want to fail over to sometime this weekend, which gives me an opportunity to think about that process, and how EnnoDB could make it easier. My current thinking is: switch to read-only mode, rsync the database to the new host, spin up another process there, then flip the IP address on the router. Probably going to need an admin interface for that. Fun!
This reminds me, I should probably write the database log to the SSD, not the SD card. The new Pi's root filesystem only has 2GB, I was running out of media.
Thanks for the upvote and the compliment! There isn't all that much code, just enough for a toy project, and what there is, is written with maintainability in mind.
Not sure what kind of tutorial I could have read. I've seen two key-value store implementations before, memcache and openkeyval. The memcache code is a nightmare to follow, and openkeyval is written in PHP, so neither of them is what I'd call either a tutorial or instructive.
Other than that, I read a book about C twenty years ago, but I'm completely self-taught ever since. I obviously read djb's paper on critbit trees before implementing them. The rest is from man pages and code. I had never used libfcgi for anything big before embarking on this, so that was a new thing. It's also my first time using mmap, and the Windows equivalent. Configuring nginx just right may have been the hardest part of it all.
I think the code is pretty clean, although it could use a few more tests. Mocking out libfcgi is a bit of a chore that I didn't want to go into right now, and it has already bitten me in the ass once.
There's also a neat voxel-based RPG engine called RPG in a Box (https://rpginabox.com/).
For Python, there's pygame, which requires a lot more code, but let's you make sprite-based games in a "real" programming language, if that's more your speed. Python also has classic turtle graphics, but that doesn't usually get you very far for making games.
Finally: I've used all of these (and other) tools with kids in that age group, as a mentor at events like Hack The Future (https://hackthefuture.org/) and Hour of Code (https://hourofcode.com/). Look for an event like this in your area, they are really fun to attend!