About "Good to know"
Each morning during my "coffee hour" I read a couple of IT related articles (and other topics) from various sources. (OK, I admit, usually it's a couple of hours...)
And each couple of weeks I intend to create a note of the most worthwhile articles or tools that I've encountered. So far it took more than a year since my previous issue... Hopefully I'll pick-up the pace in the future...
(Please note that I don't usually just copy-paste links I've found on Hacker News, although some of these links might have been found starting from such links.)
(for all humans)
The Command Line Programs for the Blind article -- written by Karl Dahlke, a blind software engineer that has created a console line-oriented web browser (and more) for blind users (and not only) -- describes his journey through the IT landscape of HMI (Human Machine Interaction) from punch-cards up to the recent day of the rich web.
The story is full of ups-and-downs, and as the technology advances, so his interaction became easier (early teleprompter days, early Web days) or harder (native graphical UI's, the current web apps).
I would say that every developer that works on frontends, and every UX expert, should at least think how his design or choices impacts not only blind users, but also visually impaired or other "non-mainstream" users.
For example, one of the main problem with screen-readers is the limited bandwidth used to convey the information to the user. (Try to imagine how quickly can you "listen" to some audio and still understand what it tries to convey; that limit is the bandwidth I'm speaking about.) Combine that low bandwidth with the amount of unrelated information clutter, and you'll get good picture of how friendly are our sites to this category of users...
Finally, I always read with much fondness articles talking about accessibility, of which I would also like to highlight the following:
- The unreasonable effectiveness of simple HTML that describes how some users need to use "broken" browsers to access critical web-based portals;
- How I fixed accessibility on my website and how you can fix yours that describes her experience trying to use various screen readers on her own site, and what she changed to make it more accessible;
- I wrote the book on user-friendly design, what I see today horrifies me;
- How Apple Is Giving Design A Bad Name;
(for the async backend developer)
Mike Bayer, Python's SQLAlchemy creator, discusses about asynchronous Python and databases and the (un-)suitability of asynchronous programming for general purpose use-cases.
Having tackled recently asynchronous programming myself in Rust, I can attest to his assessment: asynchronous programming is great for limited use-cases that fit the requirements and needs; but as a generic programming model it's far from a good approach.
(That doesn't apply to asynchronous programming in languages that are built from the ground-up with such a use-case, although they hide the asynchronous aspects behind the scenes. Here I talk about languages like Go or Erlang.)
(for the remote worker)
Here are a couple of links for those that have to communicate often via Slack, Google Meet / Hangouts, Zoom, Discord, Teams, Skype and other on-line conferencing software.
The bottom line: it's all about audio.
- Zoom Like You Mean It, Pt. I: Audio Gear -- a small introduction into microphone hardware, and a few "budget" suggestions;
- Zoom Like You Mean It, Pt. II: Audio Technique -- a follow-up describing how to actually use your microphone;
- NoiseTorch -- a Linux-only plugin to PulseAudio, that cleans-up my shitty microphone, and saves me from sounding like from the bottom of a barrel;
(for the open-source producer or consumer)
I was always fascinated by "lawyer talk", the obscure and obfuscated English of contracts and licenses...
Bellow one can find an extensive description of two common open-source licenses:
Even if you aren't strictly interested of these licenses, reading this series by Kyle Mitchell provides an insight into the various topics, for example:
- why all licenses include the "NO WARANTY" disclaimer, usually in upper-case;
- why all works include the "Copyright (c) " header;
- why the awkward words like "hereby" or "including without limitation";
- (and these were just a couple of items; the two articles are plenty of these insights;)