The Weekly Top 7 DEV Articles You Should Read (13/01 - 20/01)
Good Error Messages, Google Analytics OS Alternatives, Safari Security Leaks, QUERTY Layout, Open-Source Software Pyramid, Static/Dynamic Websites, and RETRO Protocols.
1- What's in a Good Error Message?
In this article Gunnar Morling (Red Hat open-source developer) talks about what sets apart a good error message from a bad one. (13/01/2022)
Firstly we need to clarify that the readers of those well-formatted error messages are the developers. Those presented are not guidelines for end-user client messages, but for library or framework errors, which are going to be logged or thrown as exceptions.
Those kinds of errors should provide three pieces of information:
Context (what is causing the error)
The error (what is failing)
Mitigation (how to overcome the error)
1 - The Context should give the reader pieces of information about what the code was trying to do when it failed. Another good practice is to use structured log statements for information about the context. In this way, consumers of the log files could easily filter relevant information with simple queries.
2- The error message should precisely and with fewer words possible describe what is failing. It’s possible to provide two different messages for the same error, one more detailed than the other. The longer version of the error should be provided only if “verbosity” is increased.
3- The mitigation of the error should always be provided in the message, if available. There are several ways to detail messages with mitigation actions. The key concept is: never leave the user in front of a closed-door without giving him a bunch of keys to try.
Additional best practices when it comes to error messages:
Uniform voice and style (be style consistent)
One concept, one term (be semantically consistent)
Don’t localize error messages (use only English)
Don’t make error messages an API contract (do not rely on error messages to implement business logic)
Be cautious about exposing sensitive data (take in good care who have access to those logs)
Either raise an exception OR log an error, but not both (double the log, double the confusion)
Fail early (the earlier, the better)
2- Open-Source Alternatives for Google Analytics
Alex Ivanovs, experienced web project manager, confronts various open-source analytics software with the well-known google analytics. (14/01/2022)
Google website analytics is in the top list when searching google for “free website analytics” and that’s no surprise. The main advice is to go past the first three results and consider some alternatives. Let’s see why.
Other disadvantages of the GA, includes the fact that it’s a huge script (~45kb) and some browser like Firefox directly block those scripts. And lastly, the GA dashboard it’s painfully slow.
Now regarding open-source analytics software, the author goes straight to the point: does open-source mean free? Simply said, no. And the reason is that you need to host and manage the solution, which involves also paying for the server cost together with keeping it updated to the latest version. Another solution would be to pay a small subscription fee to use the SaaS provided by the various software houses.
Lastly, the article contains an extensive comparison with the strengths and weaknesses of various open-source tracking solutions like Plausible, Matomo, PostHog, and others.
3- Exploiting IndexedDB API information leaks in Safari 15
An IndexedDB API made any website capable of tracking your internet activity and revealing your identity. By Martin Bajanik, Software Engineer. (14/01/2022)
IndexedDB is a browser API to store data on web clients. Each major browsers have its implementation and great amounts of popular websites rely on this protocol to store user information (among the others: youtube, google calendar, google keep). Each website uses a specific IndexedDB database identified by its name.
The problem with Safari 15 is that every time a website interacts with this API, a new database with the same name is created in all frames tabs and windows within the same browser session. This means that a malicious website can learn what website the user visits in different tabs or windows. It should be enough to poll the indexedDB.databases() API to check for changes.
Fingerprint.js created a demo page that demonstrates how a website can learn the Google account identity of any visitor by exploiting this vulnerability. You can test it out at: https://safarileaks.com
The only action the user can take to protect himself from this leak is not to use Safari until the issue is resolved. (It seems that the bug is fixed, but the malfunction will continue to exist until the new Safari release)
4- How Bad Is QWERTY, Really? A Review of the Literature, such as It Is
Confronting QUERTY keyboard layout with other standards. Have you have considered a transaction to be something better? A well evidenced, complete, and accurate comparison of ergonomics and productivity differences, by Erich Grunewald. (15/01/2022)
Due to a bad case of RSI (Repetitive Strain Injury), the author switched from typing on QUERTY to Colemak. In this article, he analyzes the theory and scientific evidence about better ergonomics and productivity in different keyboard layouts, with a specific look at what keyboard layout may cause more injuries when used.
Generally speaking, starting from defining quantitative models when measuring the typing effort of a key layout, Carpalx’s project states that, QWERTY is bad, though better than the average random key layout. Dvorak does better, and Colemak is better still.
Regarding ergonomics and risk of injury, the evidence is weak: there are no scientific studies that state that Bad key layouts could be a major part of the RSI cause.
Talking about productivity, two different studies (Liebowitz, S. J., & Margolis, S. E. (1990). The fable of the keys / Cho, H. (2014). Comparing QWERTY and Dvorak Keyboard Speed: a Pilot Study) state that there is a 5% typing speed advantage for Dvorak over Querty. However, considering also the cost of the familiarization with a different keyboard layout, which may be high (2 to 24 days), the choice to switch is not so trivial.
5- Enforcing the Pyramid of Open Source
Daniel Stenberg describes the world of software and open source as a pyramid. (17/01/2022)
Upper layers are built using lower layers. The more we go up in the scheme, the more software usually uses open source components. Is there any interest, for large companies on the extreme top (which usually makes lots of money) to support open-source software of the lower layers?
Top layers should always support the open-source components that they are using. Morality is not important in this case. Supporting open source does have a positive impact. For example, a company could decide to prevent vulnerabilities instead of waiting for the next log4j flaws, through caring about lower layers. It’s impossible to build a skyscraper without considering how to improve bricks.
6- There is no such thing as a static website
Does the division between static and dynamic websites still make any sense? An interesting article by Wesley Aptekar-Cassels. (13/01/2022)
We use static and dynamic keywords when referring to a website for several reasons.
First of all for simplicity of maintenance. HTTP server software is very robust and easy to maintain, whereas application servers tend to break more frequently. In addition, it’s very easy to outsource the maintenance of static websites for free (see GitHub Pages for example).
Another reason which makes this taxonomy someway relevant is the operational complexity. But consider, as an example, that static websites have to handle the HTTPS certificate, or an HTTP Basic Authentication, which makes them in some ways dynamic. Furthermore, when the static/dynamic divide was created, working isolation primitives didn't exist. Right now it’s way too easy to rely on stable dynamic computation, for example with serverless programming.
The more those dynamic computations become solid and stable (like the file system API which serves static files) the more the distinction between dynamic and static should be irrelevant. Our aim as developers should be to make it easy to deploy dynamic applications as it is for static websites. To build “software is stable and simple” … “which fades into the background and becomes infrastructure”
7- Tired of the Modern Web? Discover some ‘Retro’ protocols you still can use today
It could be tiring to follow all kinds of new standards and protocols when it comes to web development. In this article, Dimitrii Eliuseev (Python and IoT Developer) brings us back in history. With a slight touch of nostalgia. (15/01/2022)
The first specification of FTP was published on 16 April 1971, that’s 51 years ago. It’s surprising how it is still in use to the current day. https://www.mmnt.net/ contains a list of public FTP clients still maintained and available, some of which with very interesting content.
BBS (Bulletin Board System) was the first rudimentary way of connecting two hosts to exchange data. First modems accomplished this using audio frequencies with a standard phone handset! Also in this case there are still some BSS operating today, mostly maintained by tech enthusiasts.
Gopher was a protocol ahead of his times. Born for the need to search and read data in specific ways (which was not possible with simple FTP). Even if Gopher had a short lifespan, due to his license (not free) and some technical issues, there are still passionate hobbyists maintaining active gopher-based servers.
Check out the complete article if you want to deepen your knowledge or read about other ancient protocols like IRC or Usenet.
Thanks for an enjoyable inaugural edition of DevGenius. I look forward to future issues.