Despite some (already mentioned) shortcomings, I like it: it provides a simplified "real life" big picture of the whole process with sample tools; a thing that (in my experience) every other "getting started" guide seems to miss (most of them just mentions what is a makefile).
I also like the overall format of the website and the radio feature is a nice touch. I'll visit it again in the future, out of curiosity.
A follow-up article may extend it with collaboration (git) or may delve in either Unix-like (e.g. with the GNU utils etc) or Windows, or both. But the author should first address the highlighted shortcomings...
I'm using Postgres FDW at my current work and, while it has its advantages and use cases, JOIN operations can be terribly slow. Also, good luck (not) working with remote sequences.
Common things are simply by category and subcategories starting from the media/file "type" (e.g. books, photos, etc).
Projects are created in a ~/playground directory and are eventually moved to a ~/projects one (but sometimes they just stay in a RAM-disk; i.e. experiments).
Within coding projects I usually have /src, /doc (by category and subcategories) and /utils (with utility scripts, Docker-related files, etc) sub-directories.
PDF et similia that don't fit within a specific project typically are generic enough to be placed somewhere under ~/books.
The main issue with this system is that there could be work-related things under distinct paths (e.g. ~/documents/work/<org> and ~/projects/<name>), but those may be archived together...
IIRC you should strive to never reach the extremes; i.e. keep in the 20–80% range in order to maximize its lifespan.
Another tip was to avoid rapid energy consumption (such as from intensive use of CPU or discrete GPU usage) while on battery.
My main issue is that whenever you plug an external monitor, this automatically trigger the discrete GPU, and I'm using an external monitor for working from home (due to the cervical), so I'm mostly using the charger.
I expect it to be a little better trade-off given the following points:
1. JS is kept for what it's meant to be and do; nothing more.
2. A WebKit webview is probably lighter than Chromium + NodeJS.
3. The whole thing should be managed to be linked as a shared library, avoiding many pitfalls of Electron's applications (by means of a semantic-versioned library).
4. The whole solution is really language-agnostic, despite my efforts with Go.
I've just started designing something very similar in my free time, but for Go (golang): interface around native GUI + WebKit webview + React + bindings.
I'm glad that we are slipping away from Electron...
For the readers, I'll add a gently remainder that this is about Canada whose southern border is located at about 50°N. That means that the shift in daylight that they experience during the year is quite amplified.
Beside that, the article is quite poorly written and misleading! Do not assume that everything said apply for the rest of the world.
> Changing our clocks twice a year has little benefit, economic or otherwise, so isn’t it time to stop this antiquated practice?
Yeah, thanks for such a scientific sentence with no explanations, no data, not even an introduction to the topic. Next time maybe also ask some astronomers…
> As experts on biological rhythms, we support the switch to a permanent time.
That's perfectly fine, but at least explain why… and provide advice for the current practice (e.g. for the Spring change, move up your daily routine/schedule by 3 minutes every day for the 20 days before the change, so it will occur smoothly).
> People on the western edge are forced to get up an hour earlier than people on the east, according to sun time.
What ?! Not in standard time-zones. That can happen only in countries which span across different time zones and decides to keep a single "official" time.
> Analysis of health data from millions of people shows that […]
No source at all; that seems more a supposition from a USA article. They see sunrise/sunset 19 minutes early (depends on the latitude), but that doesn't mean that they sleep less. All the rest is just bullshit.
> Permanent DST would make sunrise even later for everyone, while permanent ST would make sunrise closer to body time.
In the northern emisphere permanent DST would make sunrise later in the Winter; permanent ST would keep the sunrise to the current optimum (for the Winter; during the Summer we already wake up with the Sun).
I'm a big supporter of 2D-defined time-zones, but not for what your're saying.
The overall debate revolve around daylight which change in function of one's latitude.
With an internationally agreed grid (e.g. current longitude division plus steps of 15° of latitude), we may solve those problems easily for everyone, wherever they lives.
I'm going to write a couple of things about the first point.
Several years ago, a knowledgable guy told me that the most compelling reason for choosing between PostgreSQL and MySQL was the expected I/O: "for read-intensive workloads (e.g. blogs), choose MySQL; for mixed workloads (e.g. forums), choose PostgreSQL".
But I honestly don't know if that may still be valid as of today.
Nowadays, I think that for basic things, it doesn't really matter; but for peculiar things, Postgres may have some advantages (both technically and not). Also keep in mind that, for some popular scopes, SQLite is likely everything you really need.