The Weekly Top 7 DEV Articles You Should Read
Unix on the Path of BSD, Enhancements of Netflix TV-UI Deployment, Devs Use Closed Software, Code that Doesn't Rot, When to follow TDD, The True Way to Software Mastery.
1- Unix: On the Path of BSD
It’s incredible how Unix became portable and reliable thanks to the work of millions of developers in the world. This article talks about how Unix became a Berkeley Software Distribution (BSD). (10/02/2022)
The long path of Unix started in a room, on the sixth floor of Building Two at Bell Labs, where many important names of the programming world like K. Thompson and D. Ritchie spent a lot of time working on the first version of the operating system.
The first edition of Unix (1971), was rewritten from PDP-7 for PDP-11, adding features such as a hierarchical file system. Migrating Unix to a new architecture was a really hard job at that time because there was a lot of assembly code with just the Fortran compiler. For this reason, Ken Thompson decided that a new more feasible language was needed in the Unix system. Shortly after, the C language saw the light.
The first time that Unix was exposed to the outside world was in a paper written by Thompson and Ritchie. From that moment Unix improved until it reached the seventh edition.
Ken Thompson worked as a visiting professor at the University of California at Berkeley. While there, he introduced Unix and worked together with students to create new tools for the OS. In the end, BSD would grow on its own and overshadow its progenitor.
Check out the complete article if you want to read much more about the history of Unix and the birth of the BSD.
2- Modernizing the Netflix TV UI Deployment Process
Netflix had a revamp of the UI delivery process to help them achieve the best experience for the users. (11/02/2022)
Netflix assigns a different Electronic Serial Number (ESN) for each device that uses the TV UI. The Canary build deployment process was set up based on this number. This process had several problems.
First of all, if a customer turned on their TV when the canary deployment is in progress, they might get served the canary build on one device and the baseline or regular build on another.
In addition, as the ESN is always the same, always the same devices received the canary build. In this way, together with having a poor user experience, Netflix tested his canary deployment always on the same devices, reducing the variance of the test environments and decreasing the quality of the user experience.
The great solution adopted by Netflix was to rely on AB-Test-Based canaries and differentiate USERS accounts instead of devices. This means that the same user will receive on different devices the same build.
In addition, as A-B groups are populated using a random assignment, it will be assured that the two groups are similar in terms of their device representation.
3- Code that Doesn’t Rot
Maxime Chevalier-Boisvert writes about how is possible to write code that it's more resilient to change and works for longer (11/02/2022).
Breaking changes into codebases is often caused by third-party dependencies, some of which are easy to fix, others are not. For example, the strict dependency between PyTorch and a specific Nvidia GPU driver causes lots of problems. In addition, installing specific Nvidia Drivers is a long and tedious process.
Code rot is a problem that we ought to try to fix or at least alleviate. One of the ways we could avoid it is to statistically link libraries used. In the Python world, this is possible by specifying the exact number of the dependency. This fix comes with a cost: it's impossible with Pip to have two different versions of the same library in the same application. In addition, the FFI (foreign function interface) is a trap door not controlled by the package manager at all.
The root cause of code rot is change. One of the ways we can minimize it in the software world is by building it on more stable foundations. The idea of virtual machines, firstly brought to life by Java, aimed initially at providing a not-changing infrastructure to run the software.
Generally speaking, the correct approach and the most practical solution is to take a conservative stance. Minimize dependencies where possible. Pick only dependencies that have a long history of being stable and well-maintained.
4- Thousands of npm accounts use email addresses with expired domains
In the world of third-party software and the progressive healing from the Not Invented Here syndrome, thousands of NPM packages have been found vulnerable once again. (11/02/2022)
Academic research analyzed the metadata of 1,630,101 libraries and found that 2818 NPM accounts were related to emails with expired domains, leaving projects exposed to easy hijacks.
The hijacks could be easy. An attacker could buy these domains, re-create the mail, and have full access to the NPM packages once resetting the maintainer's account password.
Teorycally, these attacks could be spotted by account owners. The problem is that 44.3% of NPM packages are left abandoned and 58,7% are unmaintained. This means that no one could spot any attack going on.
This attack has been feasible because the npm portal does not use two-factor authentication (2FA) for packages owners. However, npm announced plans to start enforcing 2FA, starting from the top 100 maintainer accounts of the platform.
Additional details on the study are available in the “What are Weak Links in the npm Supply Chain?” research paper.
5- Devs Use Closed Software
An insightful article uncovering the real issue when choosing open or closed source software development. By Kyle E. Mitchell (12/02/2022)
Developers use software in various shades of "closed" very often. It's not hard to find proprietary tools, libraries, and frameworks for sales on Google. College students, hobbyists, and startups who don't spend any money on proprietary software represent a small portion of the population.
As there is too much stuff to consider for complete vertical integration, the Not Invented Here syndrome is not viable even for companies in the top tier.
In addition, the existence of open-source software does not mean there can’t be any other kind. Usually, it's a closed source software that feeds open, by giving it something to clone. When the advantage of sharing maintenance outweighs the competitive edge of closed source, open source will prevail, fostered by companies themselves.
No one the author knows with broad experience in the industry thinks making an impactful activist project racking up GitHub stars.
In conclusion, what is the point of providing open-source software? The problem is considering open-source as the main focus. The main focus should instead be serving other people. Open-source is just a tool.
6- When I do TDD and when I don’t
In this article, Jason Swett presents his reasoning on TDD. In which cases driving code with tests is going to be purposeful? (14/02/2022)
When developing a new feature, Jason (and many other developers like him) relies on a "feedback loop" by manually testing the behavior of his code and then editing it if something does not work.
TDD it's just the automated version of the manual testing he was going to do anyway. TDD works better when the requirements are known and specified.
Comparing coding to playing the piano, sometimes we have pieces of music already written in our heads. Other times we mess around to find new music worth recording.
Developers also do not work always with clearly defined requisites. For example, they could be programming under the "spike" incentive. A "spike" it's a time slot used to gain technical or functional knowledge for projects development.
In this sense, code it's not only used to create a work product. It could be used as a medium for thinking also. The benefits of TDD in this case do not apply.
7- The True Way to Software Mastery
An insightful article by Justin Coulston about what it takes to gain mastery over software. This reading is necessary to acquire the necessary wisdom to follow the path of the best. (14/02/2020)
Programming is not truly a skill. You can master a specific programming language through formal training and practice. However, we need a lot more to master programming than language mastery.
Programming mastery requires a lot of other skills; Skills that some programmers may balk at having to learn. For example, it requires a deeper understanding of the hardware, operating systems, and overall philosophy of software.
Furthermore, mastery is a form of subjectiveness that is bestowed upon yourself from others. Taking as examples Linus Torvalds or Robert C. Martin, what did they to do become considered "masters" in their craft? They experimented, never accepted rules, studied hard, challenged each other, never considered impossibilities, built wisdom with humility.
The fundamental takeover of this article is simple enough: never stop learning. To be considered a master, never stop at the surface of what you are studying neither.
"The point is, the more you understand at the fundamental levels, the more chances of your ability to innovate in the field of computer science. You’ll realize that assumptions are made in lower-level frameworks; Decisions that, if recalculated, may produce a unique result. It’s this type of innovation that the masters perform."