Among other technologies, I'm getting up to speed with the latest and greatest of React. Although nowadays most official webpages have incredible tutorials (e.g. Typescript, React or Jest), I both consume a decent amount of audio content and like to have multiple sources of information, so I asked some friends, did some searches and checked some recommendations. As happens a lot lately, sometimes it's hard to distinguish commercial interest or pure feature bloating from real requirements for building Javascript apps, and it happens even more so with React. I'm sometimes overflowing with do many theoretical frameworks and libraries and tools and "extensions" and whatnot, all of them according to some sources you should learn and use. But I need to allocate time for other stuff, so is not always easy to identify and select what you feel will provide you with most value for the time invested (and sometimes money, but that's irrelevant if the content is good).
That said, my tiny list of 3rd party resources that I currently read/listen/watch and would recommend related with React (and I could also say "Javascript") is:
I follow a few more blogs and podcasts, but haven't yet made my mind about if they are great so as to keep following or just good, but I'd appreciate suggestions of any other resources to learn React and modern Javascript you think are good. So if you have any, please write them to me!
Title: Stairway to Badass: The Making and Remaking of Doom
Author(s): David L. Craddock
In theory, half of this book is about Doom, and half about Doom 2016. In reality, you first have to remove the trailing 20% that is just dull content to fill pages (a preview from Rocket jump Quake book and a "making of" of this book?!). Then, Doom 2016 gets around 1/3 of the pages, and half of those are "not bad but not incredibly interesting" interviews, including one with a speedrunner. What remains covers classic Doom, but so much of it relates to modding, map making and speedrunning, that if you really want to know anything relevant about how the game was built, you're better off with alternatives like Masters of Doom or the Black Book about Doom.
I have really enjoyed reading other books from this author, but this title feels mediocre. An interview or two with people creating content for the original game so many years later is interesting, but when it makes not only most of the content but most of the actual interesting or fresh content, there's something amiss. Another example is the heavy presence of John Romero's Sigil expansion for classic Doom: Sure it's cool (I played it and the maps are great and well done), but one chapter about explaining what it is, another in the form of an interview with Romero, another with the playtester, and another with the company building the physical version?
There's some tiny highlights here and there, but throwing a complex technical sentence in the middle of pages of undesired content doesn't makes a book deep or interesting, and overall it's simply not worth reading through. If this was a book about Doom's community and modding, it'd be fine, but the title is totally misleading.
I really didn't knew what to expect before starting reading this book, but disappointment wasn't in the list.
As I now have access to LinkedIn Learning full catalog, I'm going to use it alongside other resources so expect more course reviews in the upcoming months.
Node.js Essential Training takes around 2 hours to complete, and includes the basics of Node, I/O (interacting with the terminal and with the filesystem), eventEmitter, exports and modules, and executing & spawning child processes.
The code examples are simple but very effective. Oh, and the examples are built first using callbacks, but in the sixth chapter are also shown with streams. Sadly there is no promises version, but still not bad for such a compact course.
Recommended, and I'm going to actually take other courses from the author, Alex Banks, as I like how he explains each topic.
I recently migrated my server to a new, newer instance, and decided to do some housekeeping and rethinking of the stuff I had running on it. One of the things that I had was a subdomain to store very basic visits stats, a tiny Python website done using Flask. Other than some small data formatting, it really wasn't doing anything else, so I thought: "If I'm using nginx and really don't need to format the data on save, why using anything else? why not reducing it to the bare minimum?".
After checking the documentation and some basic experiments, indeed for simple logging you don't really need anything else than filtering by the subdomain and an extra logger with a custom format.
I'll first show how to do it, then briefly explain the results:
On the specific stats.mydomain.test
nginx configuration, inside the server
block:
# server name must match with the one defined at `nginx.conf`
server_name stats.mydomain.test;
location / {
# allow GETs from Javascript calls
if ($request_method = 'GET') {
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Methods' 'GET';
}
add_header 'Cache-Control' 'no-store';
# As there's nothing to return, better 204 than 200
return 204;
}
And on the general nginx.conf
file, inside the http
block:
# desired format, e.g. resembling a double-quoted fields CSV (without headers)
log_format statsformat '"$time_iso8601","$request_uri","$http_referer","$http_user_agent"';
# conditional mapping...
map $server_name $isstats {
stats.mydomain.test 1;
default 0;
}
# ... allows to do conditional logging
access_log /some/path/my_stats.log statsformat if=$isstats;
With just those lines, what you get is that any GET
call to stats.mydomain.test
will append a line to my_stats.log
in the web server, but won't mess with calls to mydomain.test
, somewhere.mydomain.test
or any other subdomain on your server.
Logs allow for different configurations, like different buffer sizes (or no buffer at all) or compression. Check the official docs for more info.
I love the concept of an open, accessible and interlinked world wide web, but I think that we're slowly going more and more inside a walled gardens model, where your data, your content and even fragments of your online persona (of your digital self) is contained inside fortified silos like social networks. That's the main reason why I've kept this dumb blog for more than 15 years (at the time of writing this post), and will keep doing so for as long as I can.
When recently Davidfq wrote me and told me that he liked my blog and "all the IndieWeb thingy" I wondered what was that indie web movement. I won't go into what's about, so go check indieweb.org and come back once you've read the basics.
I already have some microformats setup for my blog posts, but I wasn't using the h-card anywhere, so following the getting started guide I've now fixed both my landing page and both posts and pages from this blog.
I think the IndieWeb is a great initiative, and everything is decided openly, so if you keep a personal blog I encourage you to give it a try.