DEV Community: jck

Simple Quiz Game using Open Trivia Database API

jck — Sun, 27 Apr 2025 16:28:50 +0000

A quick project: a JavaScript quiz that fetches questions from the Open Trivia Database.

Becoming a Senior Developer - Tips from Clean Code

jck — Mon, 10 Feb 2025 23:48:00 +0000

If you aspire to become a senior developer, work remotely, travel, or start freelancing, there's one essential book to read: "Clean Code" by Robert C. Martin. This book is a must-read for any developer aiming to excel in their field. Here, I'll share the top five insights I gained from the first chapter of this book. Rather than skimming through the entire book, I've chosen to focus on these insights to delve deeper into their significance and impact.

The "What the Fuck" (WTF) Metric

The first piece of advice, and perhaps the most memorable, is the concept of "What the Fuck" (WTF) per minute. This idea suggests that code quality can be measured by how often a developer asks "What the Fuck?" while reading the code. High-quality code has a low WTF rate. For example, a 1000-line file with a 10% WTF rate is much more understandable than one with a 50% rate.

Although subjective, this metric is a crucial indicator of code clarity and maintainability. To objectively evaluate your code, it's recommended to revisit it after some time or have it reviewed by other developers. Code reviews and pair programming are effective practices for reducing the WTF rate.

The Importance of Experience

The second insight emphasizes the importance of experience in software development. The software industry is often managed by young developers, which can lead to long-term maintainability issues. The book stresses that code should be designed to last for years, not just to work immediately.

Defining Clean Code

The third lesson addresses what constitutes clean code. While definitions vary, most experts agree on three essential pillars: maintainability, flexibility, and testability. Clean code is easy to maintain, allows for the addition of new features without significant constraints, and can be tested effectively.

Optimizing for the Reader

The fourth lesson recommends optimizing code for the reader rather than the author. Since most time is spent reading code rather than writing it, it's crucial to make the code as understandable as possible. This includes using clear variable names and avoiding obscure abbreviations.

Example of Clean Code

Non-Refactored Messy Code:

function checkResponseInfo(data) {
    let result = [];
    for (let i = 0; i < data.length; i++) {
        if (data[i].status === 'active') {
            let info = data[i].inf
                for (let j = 0; j < info.length; j++) {
                    if (info[j].value > 10) {
                        result.push(info[j]);
                    }
                }
            }
        }
    return result;
}

Refactored Clean Code:

function checkResponseInfo(data) {
    return data
        .filter(item => item.status === 'active')
        .flatMap(item => item.info)
        .filter(info => info.value > 10);
}

This example demonstrates how code can be refactored to be more readable and maintainable.

The Boy Scout Rule

Finally, the fifth lesson is the Boy Scout Rule: leave the code cleaner than you found it. This means that every time you work on a file, you should take the time to refactor and improve the existing code. This practice helps maintain code quality over the long term and prevents the accumulation of technical debt.

Conclusion

These five lessons from the first chapter of "Clean Code" are essential for any developer looking to improve their skills. While reading this book won't make you a senior developer overnight, it will provide valuable insights to enhance your coding practices and approach to development.

For more insights and tips on becoming a proficient developer, stay tuned for more articles and resources. This article was generated by the video from the French YouTube channel of Simon Dieny, Codeur Senior. Subscribe to stay updated on the latest in software development!

Linux file system

jck — Mon, 10 Feb 2025 21:36:20 +0000

Introduction to Linux Directory Structure

Most Linux users have seen the root directory (/), but not everyone understands the purpose of the various directories it contains. For a user coming from Windows, exploring the file manager in Linux might seem familiar at first: you'll find folders like "Documents", "Downloads", "Pictures", and "Videos". However, this familiarity quickly fades when you start looking for directories like "Program Files" or the C drive, which are ubiquitous in Windows.

Different Evolution of Windows and Linux

To understand why Linux is structured differently, it's helpful to look back at the history of operating systems.

MS-DOS and the Early Days of Windows

MS-DOS: Initially, there was MS-DOS, a command-line operating system. You could run programs, games, and software like WordPerfect on it. MS-DOS used letters to designate drives: A and B for floppy disks, and C for the primary hard drive.
Windows: Windows was layered on top of MS-DOS. To start Windows, you had to type win in the MS-DOS command-line interface. Over time, Microsoft made Windows increasingly independent of MS-DOS, until it could boot without it.

Linux Directory Structure

Linux, on the other hand, follows UNIX traditions, which explains several fundamental differences from Windows:

Use of the Slash (/) : Unlike Windows, which uses the backslash (\), Linux uses the slash to separate directories.
Case Sensitivity: Linux is case-sensitive, meaning that "file", "File", and "FILE" are considered different files.
No "Program Files" Directory: In Linux, applications are not all installed in a centralized directory like "Program Files". Instead, they are distributed across various directories based on their nature and usage.

Main Directories in Linux

The structure of directories in Linux is defined by the Filesystem Hierarchy Standard (FHS), although not all distributions adhere strictly to this standard. Here is a detailed description of the main directories:

/bin
Contains essential binary executables needed by all users. Examples include commands like ls, cat, cp, and mv.

/sbin
Contains system binaries, used mainly by the system administrator for maintenance and repair tasks. Examples include ifconfig and reboot.

/boot
Contains files needed for the system to boot, such as the bootloader (GRUB) and the Linux kernel.

/dev
Contains device files. In Linux, everything is considered a file, including hardware devices. For example, /dev/sda represents the first hard drive.

/etc
Contains system configuration files. Examples include network service configurations and package manager source lists.

/home
The personal directory for users, where each user has their own subdirectory to store personal files and settings.

/lib, /lib32, /lib64
Contain shared libraries needed by the binaries in /bin and /sbin.

/media and /mnt
Mount points for removable devices. /media is often used for automatic mounting, while /mnt is used for manual mounts.

/opt
Contains optional software, often manually installed or from third-party vendors.

/proc
A virtual filesystem containing information about running processes and system resources. For example, /proc/cpuinfo contains information about the CPU.

/root
The personal directory for the root user, the system administrator.

/run
A temporary filesystem in RAM, used to store runtime information for processes started early in the boot process.

/snap
Contains Snap packages, a self-contained package format used primarily by Ubuntu.

/srv
Contains data for services, such as files for a web or FTP server.

/sys
An interface with the kernel for information about hardware and devices. For example, information about connected USB devices.

/tmp
A temporary directory for files used during a session. Files in /tmp are usually deleted upon reboot.

/usr
Contains user applications and libraries. For example, /usr/bin contains user binary executables.

/var
Contains variable files, such as system logs, databases, and print queues.

Conclusion

While the directory structure in Linux may seem complex at first, it allows for efficient management of resources and applications. Package managers, like apt for Debian/Ubuntu or yum for Fedora, facilitate the installation, updating, and removal of software by following these conventions.

If you found this information useful, feel free to share it and subscribe for more content.