DEV Community: Damien Cosset

Understanding Javascript's Proxies and Reflect API

Damien Cosset — Mon, 07 Oct 2024 06:59:03 +0000

Introduction

In Javascript, Proxies enables you to trap specific object operations and customize them. The Proxy acts as an intermediary between the object and the "real world". Thus, you can enhance an object basic operations to implement more complex logic or redefine fundamental operations to fit your needs.

Use cases includes:

log property accesses, useful for debugging
validate any interaction with an object (such as form validation)
helps enforcing consistent formatting for

Proxy takes two parameters:

target: which is the original object you want to proxy
handler: an object that defines the operations you will intercept and how you will redefine said operations

Basic example

const target = {
    greeting1: "Hello",
    greeting2: "Good morning"
}

const handler = {
    get(target, prop, receiver) {
        return target[prop] + " friends!"
    }
}

const proxy = new Proxy(target, handler)

console.log(proxy.greeting1) // Hello friends!
console.log(proxy.greeting2) // Good morning friends!

In this example, we define a Proxy. The target object has two properties. We define a handler that provides an implementation of the get() handler. The get trap intercepts the access to any property on the target object, and within it, we can modify the behavior as needed.

With this setup, it means that every time we are going to access properties in the target object, the handler intercepts it, and runs the code we implemented. In our case, it just takes the property value and adds friends!.

Reflect

Often times, Proxies are used with the Reflect API. Reflect provides methods with the sames names as the Proxy traps. Like its name indicates, it reflects the semantics for invoking the corresponding object internal methods.

const target = {
    greeting1: "Hello",
    greeting2: "Good morning"
}

const handler = {
    get(target, prop, receiver) {
        return Reflect.get(...arguments) + " friends!"
    }
}

const proxy = new Proxy(target, handler)

console.log(proxy.greeting1) // Hello friends!
console.log(proxy.greeting2) // Good morning friends!

Reflect is not required to use Proxies but using Reflect allows us to be sure that the behavior matches the native Javascript engine operations. It also ensure compatibility with future updates, prevents unintended side effects and simplifies code. Without it, the developer would have to re-implement behavior like property access, assignment, deletion... which can be error-prone and inconsistent with Javascript's native behavior.

Examples

Let's build some examples to explore what we can do with Proxy.

Logging

In our first example, let's say we wish to log which actions are taken on a object. Whenever we get, set or delete a property, I want to be print out to the console. This could be useful for debugging purposes.

const target = {
    name: "Damien",
    age: 32,
    status: "WRITING"
}

const loggerHandler = {
    get(target, prop, receiver) {
        if (prop in target) {
            console.log(`[LOG] Accessing property ${prop}. Current value is ${target[prop]}`)
            return Reflect.get(...arguments)
        } else {
            console.error(`[LOG] Error accessing non-existent property ${prop}`)
        }

    },

    set(target, key, value) {
        console.log(`[LOG] Setting property ${key}. New value: ${value}`)
        return Reflect.set(...arguments)
    },

    deleteProperty(target, prop) {
        console.warn(`[LOG] Deleting property: ${prop}`)
        return Reflect.deleteProperty(...arguments)
    }
}

const proxy = new Proxy(target, loggerHandler)

proxy.name // [LOG] Accessing property name. Current value is Damien
proxy.status // [LOG] Accessing property status. Current value is WRITING

proxy.name = "Bob" // [LOG] Setting property name. New value: Bob
proxy.status = "NAPPING" // [LOG] Setting property status. New value: NAPPING

proxy.job = "Developer" // [LOG] Setting property job. New value: Developer

delete proxy.job // [LOG] Deleting property: job

proxy.job // [LOG] Error accessing non-existent property job

We defined a loggerHandler that redefines 3 fundamentals operations: get, set and delete. For each action, we log something to the console describing what is happening. The beauty of the Proxy, we don't need to write the console statement everytime. We interact with our object like we always do, and the proxy takes care of the logging behavior. Pretty cool no?

Input validations

In our second example, we will use a proxy to perform input validations for form data.

const validationRules = {
    name: value => value.length >= 3 || "Name must be at least 3 characters long",
    age: value => Number.isInteger(value) || "Age must be a number",
    email: value => value.includes('@') || "Enter a valid email"
}

let formData = {
    name: "",
    age: null,
    email: ""
}

const formHandler = {
    set(target, key, value) {
        if (typeof value === "string") {
            value = value.trim()
        }
        const validationResult = validationRules[key](value)
        if (validationResult !== true) {
            console.error(`Validation failed for property ${key}: ${validationResult}`)
            return false;
        }

        return Reflect.set(...arguments)
    }
}

const formProxy = new Proxy(formData, formHandler)

formProxy.age = "32 years old" // Validation failed for property age: Age must be a number
formProxy.name = "Da" // Validation failed for property name: Name must be at least 3 characters long
formProxy.email = "damcoss mail.com" // Validation failed for property email: Enter a valid email

formProxy.age = 32 // OK
formProxy.name = "Damien" // OK
formProxy.email = "damcoss@mail.com" // OK

We define here an object with different methods used to validate whether or not the values are valid. Then, we use the same logic. We have our target object formData that we want to proxy. In the formHandler, we redefine the set() method to apply our validation rules on the inputs values.

Conclusion

Proxies, combined with the Reflect API, are flexible and powerful tools to intercept and customize operations on objects. Using them, you can enhance and control behavior dynamically. By using the Reflect API, you also make sure that the behavior is consistent with the Javascript engine.

Proxies are often used in libraries and frameworks to enable advanced behabior like reactive programming, API wrappers and property observation.

Have fun ❤️

Adding Uniqrate to Your Hugo Website: A Step-by-Step Guide

Damien Cosset — Thu, 03 Oct 2024 10:16:44 +0000

Introduction

Uniqrate is a powerful tool designed for blogs and documentation, allowing readers to engage with your content through voting and comments. The voting widget—referred to as an island—helps you gain insights into what your readers enjoy, while also gathering analytics to enhance your understanding of user preferences.

Hugo, one of the most popular open-source static site generators, is written in Go and optimized for speed, flexibility, and ease of use. In this guide, we’ll walk through how to seamlessly integrate Uniqrate into a Hugo-powered website, giving you a simple way to gather user feedback and improve your content.

In this article, we'll see how you can add Uniqrate to a Hugo powered website.

Getting the Uniqrate script

After signing up for Uniqrate and selecting your plan, navigate to the Settings tab to customize the appearance and text of your voting island. Once you're satisfied with your configuration, go to the Setup drawer to copy the code snippet by clicking on Copy to clipboard.

Awesome! Now, we can move on the next step!

Adding it to Hugo

For my example, I will use the PaperMod template but the logic will be more or less the same of any Hugo templates you use.

If you need help to setup a Hugo website, don't hesitate to check out the documentation.

Override your template's defaults

Your theme will have a folder called layouts/, located in themes/. For example, the PaperMod theme has this structure once added to your website.

To override or extend your theme’s default templates, place your custom content in your own layouts/ folder. Hugo will prioritize these over the theme's default settings when rendering the site.

You have to choose which file you need to override, copy it in your layouts/ folder and add the code you want.

So the plan is:

Identify the correct file to override.
Copy it to your layouts/ folder.
Add the Uniqrate script to the copied file.
Profit!

Adding our Uniqrate script to Hugo

This is where you'll need to know what files your template is using. Make sure to check the documentation of your template if it exists. In the case of PaperMod, there is a file called extend_head.html, it's located in the layouts/themes/partials/ folder.

The PaperMod developers added in the file a comment to tell us what this file does:

{{- /* Head custom content area start */ -}}
{{- /*     Insert any custom code (web-analytics, resources, etc.) - it will appear in the <head></head> section of every page. */ -}}
{{- /*     Can be overwritten by partial with the same name in the global layouts. */ -}}
{{- /* Head custom content area end */ -}}

This is perfect! We want our Uniqrate script to be added to the

section of every page.

So, we copy this file and paste it in our layouts/partials/ folder. Notice that we need to keep the subfolders structure, so we need the partials subfolder here.

Finally, in our extend_head.html we just copied, let's add our script:

{{ if eq hugo.Environment "production" }}
<script>(function (r, a, t, e) { r._rmc = r._rmc || {}, r._rmc.settings = { apiKey: "YOUR_API_KEY", apiUrl: "API_URL", loaderVersion: "1", server: t }, r._rmc.queue = r._rmc.queue || [], r.rmc = r.rmc || function () { let args = []; for (e = 0; e < arguments.length; e++)args.push(arguments[e]); r._rmc.queue.push(args) }; var x = a.getElementsByTagName("head")[0], r = a.createElement("script"); r.async = !0, r.src = t + e, x.appendChild(r) })(window, document, "ISLAND_URL", "/widget.js");
</script>
{{ end }}

Obviously, the script you copied from Uniqrate will have your personal values.

The condition {{ if eq hugo.Environment "production" }} ensures that the Uniqrate script is only included when the site is live in a production environment, helping you avoid loading the script during local testing or development. If you want to test the Uniqrate island locally, you can temporarily remove this condition 😉

Congratulations! You’ve successfully integrated Uniqrate into your Hugo-powered website. By adding this user-friendly voting widget, you’re giving your readers an easy way to provide feedback while collecting valuable analytics to enhance your content. Whether you're running a blog or managing documentation, this integration helps you stay connected with your audience.

Have fun ❤️

Launching our very first product: Uniqrate

Damien Cosset — Sat, 28 Sep 2024 23:29:27 +0000

Introduction

About three months ago, two of my colleagues and I joined forces with a common goal: to build and launch products. We enjoy working with each other daily, so we decided to test our collaboration by building something together.

With two developers and one designer, we feel like our skill sets complement each other well, along with our personalities. Although we have big plans and aspirations, we decided to give this partnership a "test run" by creating what we thought would be a relatively small project.

Uniqrate

The result of this collaboration is Uniqrate.

Uniqrate is an analytics and reader feedback tool for blogs and documentation. We wanted to create an easy way for readers to give their feedback and comment on the content they are reading.

The concept is relatively straightforward: we provide you with a piece of code that displays a visually appealing widget on your website. The widget allows readers to vote and comment on the page's content. Additionally, you can choose to ask for their email addresses to engage with your readers later on.

We aimed to create a lightweight widget that seamlessly integrates with a webpage's content. Using Preact, we were able to develop a compact, efficient solution that doesn’t affect website performance. We also believe the design is visually appealing without distracting from the rest of the content.

Our goal was to develop a feedback tool specifically tailored for blogs and documentation. In the age of AI, we believe it's crucial for bloggers and documentation writers to collect reader data to enhance content accuracy. With Uniqrate, we hope to help achieve that.

You also have access to a dashboard that displays all the ratings and comments left by your users. We provide some analytics, such as time spent on pages, which pages get the best ratings, and more.

Feel free to explore and give us your feedback! :)

The experience of building and launching of project

On a personal level, I've always wanted to build cool things. That's why I started programming in the first place! But working alone, I always felt something was missing: motivation, vision, time, skills, ideas... It felt like I could never finish anything.

Being part of a team

That has been a game changer for me. A team of three, each with specific skill sets. I no longer have to take on the role of a designer and risk producing something subpar—we have a skilled designer for that. It's a real relief!

Being part of a team also helps with motivation. We have our daily jobs, which take up a good chunk of time, and we all have lives outside of work too. So, finding the time and motivation to work on the project can be tricky at times. We've had our ups and downs, but being part of a team means we can help each other during tough times. Seeing my teammates diligently producing great code and designs motivated me to do the same and contribute my best work.

Ship it

When do you ship? When do you actually launch your product? We decided on a roadmap, what we thought were the minimum features needed for the product to be put out there. We sticked to it, ran into some troubles, fixed some of them, compromised on others, and decided on a deadline to let the project fly.

The last few days were a bit hectic. We oscillated between the excitement of seeing our work pay off, the disappointment of it not being perfect, and the anxiety of potentially creating something ineffective. It was a whirlwind of emotions, but an incredible experience nonetheless.

Let's Do It Again!

It feels amazing to be part of a project like this. Being able to actually create something, see it come to life, and not just store it away in a dark corner feels great. Perhaps it won’t succeed, and maybe we didn’t create something that resonates with users. If that’s the case, it will certainly be a tough lesson, but I’m incredibly proud of what we’ve accomplished.

No matter what happens, we’ve built the foundation of our partnership to keep creating, keep having fun, and keep shipping new projects.

For our first attempt, we created Uniqrate. I hope you’ll take a peek, and I’ll see you at the next launch!

Have fun ❤️

Ownership in Rust

Damien Cosset — Thu, 13 Jun 2024 14:04:21 +0000

Introduction

All programs have to manage the way they use the computer's memory while they run. Rust is obviously no different. In this article, I'll try to understand how it works.

Rust uses something that they call Ownership. Ownership is a set of rules that define how a Rust program manages memory. If you violate one of these rules, ~~you die~~your code won't compile. The rules are as follow:

Each value in Rust has an owner.
There can only be one owner at a time.
When the owner goes out of scope, the value will be dropped.

Let's dive into it.

Stack and Heap

First, we need to touch on the stack and the heap. The stack and the heap are two parts of memory available to you at runtime, but they are not structured in the same way.

The stack is organized like a stack of newspapers. Last in, first out. If you put a newspaper at the top of the pile, that newspaper is the first one that gets picked. It's fast and it's efficient. All the variables we store in the stack have a known, fixed size.

The heap is less organized. This is where we store variables where the size is not fixed. The memory allocator finds an empty spot and returns a pointer. Because the pointer has a fixed size, that is stored in the stack. As long as you need only the reference of a variable stored in the heap, we can use the pointer stored in the stack. But if you need to access the value, we have to go in the heap and retrieve the value associated to the pointer. As you can imagine, storing data in the heap takes more time (having to look for an empty space vs always storing at the top) and retrieving data also takes more time because you have to follow a pointer to get there.

Variables scope

Let's consider this code:

{ // The scope begins, greeting is not valid yet because not declared
    let mut greeting = String::from("Good "); // greeting becomes valid here
    greeting.push_str("morning"); // we do stuff with greeting
    println!("{greeting}");
} // Our scope ends, greeting is no longer valid

So, a variable becomes valid when it comes into the scope ( not when the scope begins). When the scope ends, the variable is no longer valid. In other words, it's no longer valid when the variable goes out of scope. But what happens behind the scenes?

Allocating memory

Two things need to happen:

We request the memory from the memory allocator at runtime
We return the memory to the allocator when we are done with our variable

The first part is done when we do let mut greeting = String::from("Good "); and it's quite universal across programming languages.

But how do we return the memory to the allocator when we are done with the variable?

There are 3 ways:

Languages with a garbage collector ( like Java ) do that for you. Garbage collectors keep track of what isn't used anymore and cleans up.
If there is no garbage collector? In most cases, it's the developer's responsability to identify when memory is no longer being used and explicitly free it ( like we explicitly requested memory earlier ). This is a difficult thing to do correctly, because you need to do it at the right time, and only once per memory allocation...
Rust does this in a third way: it automatically returns the memory once the variable that owns it is out of scope.

If we take a look at our code again:

{ // The scope begins, greeting is not valid yet because not declared
    let mut greeting = String::from("Good "); // greeting becomes valid here
    greeting.push_str("morning"); // we do stuff with greeting
    println!("{greeting}");
} // We are done with greeting => Rust frees the memory associated with greeting

Rust will automatically return the memory when the scope ends, because greeting is no longer valid. The variable greeting owns a chunk of memory, therefore it is returned to the memory allocator.

To return the memory to the allocator, Rust calls a special function called drop(). Rust does it automatically for us at the closing curly bracket.

Special Case:

Consider the following code:

let hello = String::from("Hello");
let hello_again = hello.clone();

println!("{hello}, world!");

Now, if we keep the same logic as before, you could say: both hello and hello_again are valid variables at the same time after we declare hello_again. But it's not the case, this won't compile. Why?

Remember earlier when we said that the pointer is stored in the stack and the variable's value is stored in the heap? Well, when we do hello_again = hello, we copy the pointer ( and other things stored in the stack ). But that's all we copy, Rust do not copy the values stored in the heap. Rust does this because it would be too expensive memory wise to copy the data stored in the heap.

So, what you would expect to happen is this:

But what actually happens is this:

So, we have 2 pointers that refers to the same value on the heap? What happens if both variables go out of scope? Rust will call drop() twice, trying to free the same memory twice? Doing this would obviously lead to problems, this is called a double free error.

To prevent this, Rust considers the hello variable as no longer valid after let hello_again = hello;. So, when hello goes out of scope, Rust doesn't need to free any memory.

This is not a shallow copy because Rust invalidates the first variable, we refer to this as a move. We moved hello into hello_again.
This means that Rust will never automatically create "deep" copies of your data.

So what if I truly want to deeply copy?

We have a clone() method that also copies the heap data, making it a real deep copy.

let hello = String::from("Hello");
let hello_again = hello.clone();

println!("{hello}, world!");

And this is valid Rust code. Because we do have the following this time:

Remember that clone() is a more expensive operation though.

Note that:

let x = 5;
let y = x;

works fine because we have integers variables here. Integers are fixed sized variables, meaning that we do not store anything in the heap, everything is in the stack. So, in this case, there is no difference between shallow or deep copying, calling clone() wouldn't do anything different here. Rust has therefore no reason to consider the x variable invalid when we do let y = x.

Rust has a special Copy trait that is implemented on types that are exclusively stored on the stack. When a type is annotated with Copy, it means that variables don't move, they are just copied ( like integers ). Rust has another annotation called Drop that is implemented by types that are stored on the heap. A type cannot implement both Copy and Drop traits. If you try to add the Copy trait to a type that can be moved ( like strings ), you'll get an error.

Here are some of the types that implement Copy:

All the integer types, such as u32.
The Boolean type, bool, with values true and false.
All the floating-point types, such as f64.
The character type, char.
Tuples, if they only contain types that also implement Copy. For example, (i32, i32) implements Copy, but (i32, String) does not.

Functions and returning values

When it comes to passing values to functions, the mechanics are the same than when we assign values to variables. For example:

fn main(){
    let greeting = String::from("Good morning"); // greeting comes into scope

    has_new_owner(greeting); // greeting moves into the function
                            // greeting is no longer valid here

    let i32_int = 32; // i32_int comes into scope

    just_copy(i32_int); // i32_int moves into the function
                        // But it implements Copy, so it's still okay to use it afterwards

} // i32_int goes out of scope, then greeting. Nothing happens because greeting's value has been move earlier

fn has_new_owner(a_string: String){ // a_string comes into scope
    println!("{a_string}")
} // a_string goes out of scope, 'drop' is called and the memory is returned

fn just_copy(an_int: i32) { // an_int comes into scope
    println!("{an_int}")
}// an_int goes out of scope, nothing special happens

Returning values also transfer ownership. Take the following code:

fn main(){

    let give_me = i_give_you_ownership(); // i_give_you_ownership moves its return value to give_me

    let greeting = String::from("Hello World!"); // greeting comes into scope

    let i_received = i_take_and_i_give_back(greeting); // greeting is moved to 
                                                    // i_take_and_i_give_back and moves its return value to 
                                                    // i_received
} // i_received goes out of scope and is dropped. greeting was moved so nothing happens give_me goes out of 
// scope and is dropped.

fn i_give_you_ownership() -> String {
    let a_string = String::from("What's up?"); // a_string comes into scope
    a_string // a_string is returned and is moved to the calling function
}

fn i_take_and_i_give_back(some_string: String) -> String { // some_string comes into scope
    some_string // some_string is returned and is moved to the calling function
}

Once you understand the principle, the same pattern is repeated all the time. But, it's a bit tedious to pass ownership around like this. If I give ownership, I need something in return to be able to use it again... It means that if I pass a variable to a function, I would need to make that function return the variable everytime if I want to use it again later?

Fear not, there is a way for us to use values without transferring ownership. We will see that in another article about References and Borrowing. Hope it was useful!

Have fun ❤️

Créer une application en ligne de commande avec Rust

Damien Cosset — Thu, 06 Jun 2024 17:52:04 +0000

Introduction

Dans cet article, nous allons construire ensemble une application en ligne de commande toute simple avec Rust. Le but du programme sera très basique. L'utilisateur nous donnera un nom de dossier et nous créerons un nouveau dossier avec ce nom. Plutôt facile non? Allons-y!

Setup

Si vous n'avez pas encore installé Rust, vous pouvez consulter la documentation officielle, il ya beaucoup d'infos utile!

Commençons par créer notre nouveau projet Rust. Pour ça, on peut lancer la commande suivante:

cargo new new_dir_cmd

Ceci va créer un nouveau dossier appelé new_dir_cmd. Bien sûr, vous pouvez remplacer ce nom par ce que vous voulez.

Si on jette un oeil à l'intérieur de notre nouveau dossier, on peut voir ceci:

Si on lance direct cargo run à l'intérieur de ce dossier, on va se retrouver avec notre bon vieux "Hello World!".

Génial, on est prêt à coder!

Créer un nouveau dossier

Première étape, on va créer un nouveau dossier. On améliorera notre programme petit à petit.

Mettons le code suivant dans notre main.rs:

use std::fs;

fn main() -> std::io::Result<()> {
    fs::create_dir_all("/Users/damiencosset/Desktop/rust/new_dir_cmd/awesome_new_dir")?;
    Ok(())
}

On utilise le module fs qui vient du crate std. Crates ( caisses en Français ), dans le contexte de Rust, sont similaires aux packages dans d'autres languages. Si vous voulez plus d'informations sur les crates, vous pouvez consulter la documentation

On utilise la fonction create_dir_all exportée par le module. Elle prend un chemin (path) comme argument. Pour l'instant, je lui donne un nom de chemin en dur.

Enfin, cette fonction retourne un type std::io::Result. Donc, notre fonction main doit retourner ce type. On ajoute donc -> std::io::Result<()>. Après avoir créer un nouveau dossier, on renvoie simplement le Ok variant qui indique que tout est ok et qu'aucune erreur n'a été rencontré.

Note: Le caractère ? est utilisé dans Rust pour la propagation d'erreur. Si nous rencontrons une erreur pendant la création de notre dossier, nous retournerons un Err(error), Err étant le deuxième variant que peut prendre Result après Ok.

Lançons ce code et voyons ce que ça donne:

Ca marche! On vient de créer notre premier nouveau dossier avec Rust!

Ajouter des arguments à notre ligne de commande

Eviddemment, ce programme n'est pas très utile. Le but est que l'utilisateur puisse donner un nom de dossier via la ligne de commande. Mettons cela en place.

Ajout du crate clap

Pour lire des arguments de notre ligne de commande, on va utiliser le crate clap. Pour consulter les crates qui ont été ajoutés à notre projet, on peut ouvrir le fichier Cargo.toml et voir ce qui se trouve après:

[dependencies]

Tout les crates qui auront été rajoutés se trouveront ici.

Ajoutons clap avec la commande suivante:

cargo add clap --features derive

Le flag features nous permet d'utiliser des fonctionnalités optionnel du crate. Ici, on veut utilise la feature appelé derive. Pour avoir plus d'informations sur ce crate, vous pouvez consulter sa documentation. Et si nous jettons un oeil à notre Cargo.toml, nous avons à présent une nouvelle ligne:

[dependencies]
clap = { version = "4.5.4", features = ["derive"] }

Définir nos arguments

Remplaçons notre code existant avec ceci:

use clap::Parser;
//use std::fs;

#[derive(Parser)]
struct Cli {
    directory_name: String,
}

fn main() -> std::io::Result<()> {
    let args = Cli::parse();
    println!("{}", args.directory_name);
    // fs::create_dir_all("/Users/damiencosset/Desktop/rust/new_dir_cmd/awesome_new_dir")?;
    Ok(())
}

J'ai mis en commentaire la création de dossier pour le moment
#[derive(Parser)] indique que nous utilisons une macro personnalisée qui implémente le trait Parser. Plus simplement, un trait définit un ensemble de méthodes (ou fonctions). Ici, nous implémentons un ensemble de méthodes (ou fonctions) définit dans Parser dans notre Cli structure. Donc, notre structure Cli est capable d'appeler les méthodes implémentées, comme parse().

Avec ce code, et le pouvoir de clap, nous pouvons lire les arguments de notre ligne de commande. Lançons à nouveau notre application et donnons lui un argument:

Parfait! Nous avons réussi à afficher notre argument. On peut à présent lire notre nom de dossier depuis la ligne de commande.

Récupérer le dossier actuel

Maintenant, nous avons un léger soucis. On ne va pas donner le chemin entier du dossier dans notre ligne de commande. On ne va donner que le nom du dossier que l'on souhaite créer.Donc, notre programme a besoin de savoir ou créer notre dossier. Pour garder les choses simples, nous allons prendre le dossier dans lequel nous sommes actuellement, puis y ajouter le nom du dossier que l'on vient de récupérer de la ligne de commande.

On a besoin de:

récupérer le chemin du dossier actuel
ajouter le nom du dossier à ce chemin

Pour récupérer le chemin du dossoer actuel, on peut ajouter ces 2 lignes de code:

// Import 
use std::env;

// Inside the main function
let mut path = env::current_dir()?;

Notez que l'on utilise le mot clé mut. Cela signifie que la variable que nous venons de définir est mutable. Les variables de Rust sont par défaut immuable. En ajoutant le mot clé mut, on peut modifier notre variable pour y ajouter le nom du dossier que l'on veut créer.

En combinant tout cela, notre programme complet ressemble à ça:

use clap::Parser;
use std::env;
use std::fs;

#[derive(Parser)]
struct Cli {
    directory_name: String,
}

fn main() -> std::io::Result<()> {
    let args = Cli::parse();
    let mut path = env::current_dir()?;
    path.push(args.directory_name);
    fs::create_dir_all(path)?;
    Ok(())
}

En utilisant push(), on peut ajouter notre nom de dossier au chemin du dossir actuel. Voyons si tout fonctionne!

Wooo! Ca marche!

Et just comme ça, nous avons créé un programme très simple avec Rust qui nous permet de créer des nouveaux dossiers.

En espérant que vous avez trouvé cela intéressant!

Have fun ❤

Build a password manager with Rust - Part 2

Damien Cosset — Sat, 01 Jun 2024 16:53:44 +0000

Introduction

After our first article, we have a simple command line application that can display the contents of a file where we store our passwords. We can also add a new password to that file through the command line.

In this article, we'll add some functionalities:

Possibility to generate a new password automatically
Add a password by getting the user's clipboard content
Keep the possibility to type the password in
Alert the user if the password is considered too weak

Let's go!

First step: Improving the command line arguments

In order to handle different ways to add a password, we need to change the command line arguments. We are going to configure some flags for our application:

one for the password generation
one to get the password from the clipboard
one to allow the user to write a password

We still keep the service and username arguments. The new command line arguments configuration can look like this:

#[derive(Parser)]
struct Cli {
    #[command(subcommand)]
    cmd: Commands,
}

#[derive(Subcommand)]
enum Commands {
    List,
    Add {
        #[arg(short, long)]
        service: String,
        #[arg(short, long)]
        username: String,
        #[arg(short, long, default_missing_value("true"))]
        clipboard: bool, // copy from clipboard
        #[arg(short, long, default_missing_value("true"))]
        generate: bool, // generate new password
        #[arg(short, long, default_missing_value("true"))]
        write: bool, // type new password
    },
}

Now, we can take three arguments: clipboard, generate and write. Each of them take default_missing_value as true so we do not have to add anything behind the flag.

Let's update our main function to test it out:

fn main() -> std::io::Result<()> {
    let args = Cli::parse();
    match args.cmd {
        Commands::List => display_passwords()?,
        Commands::Add {
            service,
            username,
            clipboard,
            generate,
            write,
        } => {
            println!(
                "{}, {}, clipboard: {}, generate: {}, write: {}",
                service, username, clipboard, generate, write
            )
        }
    }
    Ok(())
}

Now let's run it. Thanks to the advice from Vladimir Ignatev, I discovered that you can run your application through the build output in target/... folder, it makes it a little bit cleaner 😉. For me, it's in the target/debug folder. So after running cargo build, we can run our application with:
./target/debug/password_manager add -u toto -s serv -c

Note: password_manager is the name of my application, yours might be different.

This command above gives us:

It works! Now let's test out our other 2 flags to make sure everything is in order:

Perfect!

Second step: Generate a password for the user

Now that we have different options to save a new password. We need to implement the logic for each. We'll start by generating a new password. Now, there are several ways to do this. You could use a existing crate that do it for you or build something yourself. I chose to use the rand crate. This is crate is a general-purpose random number generator. It will give us the foundation to randomly generate a password. I'd like to keep some freedom to custom the functionality later on, instead of relying on an existing crate. But feel free to use an existing crate 😉

First, let's add our crate with cargo add rand
Then, let's add the following code to generate a password:

// All our imports
use clap::{Parser, Subcommand};
use rand::distributions::Uniform;
use rand::{thread_rng, Rng};
use std::io::Write;
use std::{
    fs::{self, OpenOptions},
    iter,
    path::Path,
};

// More code...

fn main() -> std::io::Result<()> {
    let args = Cli::parse();
    match args.cmd {
        Commands::List => display_passwords()?,
        Commands::Add {
            service,
            username,
            clipboard,
            generate,
            write,
        } => {
            println!(
                "{}, {}, clipboard: {}, generate: {}, write: {}",
                service, username, clipboard, generate, write
            );
            if generate {
                let password = generate_password();
                println!("{}", password)
            }
        }
    }
    Ok(())
}

fn generate_password() -> String {
    let charset: &[u8] = b"ABCDEFGHIJKLMNOPQRSTUVWXYZ\
                           abcdefghijklmnopqrstuvwxyz\
                           0123456789\
                           !@#$%^&*()_-+=[{]}\\;:'\",<.>/?";
    let mut rng = thread_rng();
    let password: String = iter::repeat_with(|| {
        let idx = rng.sample(Uniform::from(0..charset.len()));
        charset[idx] as char
    })
    .take(16)
    .collect();
    password
}

// rest of the code...

The idea is that we create a charset variable that holds all the possible characters our password can contain. The list here is a completely arbitrary choice. You could choose to use the Alphanumerical distribution provided by the rand crate for example if you wanted. After that, we use the thread_rng function provided by the rand crate. With an iterator and repeat_with, we randomly select one character from the charset. The .take(16) indicates that we want this function to run 16 times. Again, this is an arbitrary choice I'm making for now. After that, we collect the result of the iterator into a collection ( so a collection of chars is a String ) and return our password.

Let's test it! Let's run cargo build and generate our password:

Awesome! Now we can successfully generate random strong passwords of 16 characters.

Third step: Getting a password from the clipboard

Let's move on to our second use-case: getting the clipboard's content to serve as our password. It's not uncommon to fetch a password from somewhere and copying it to save it. To have access to the clipboard, we'll use the copypasta crate to make sure we have something that works accross all operating systems. Let's add the crate with cargo add copypasta and add the following code:

// Import
use copypasta::{ClipboardContext, ClipboardProvider};

fn main() -> std::io::Result<()> {
    let args = Cli::parse();
    match args.cmd {
        Commands::List => display_passwords()?,
        Commands::Add {
            service,
            username,
            clipboard,
            generate,
            write,
        } => {
            println!(
                "{}, {}, clipboard: {}, generate: {}, write: {}",
                service, username, clipboard, generate, write
            );
            if generate {
                let password = generate_password();
                println!("{}", password)
            }

            if clipboard {
                let password = get_clipboard_password();
                println!("{}", password)
            }
        }
    }
    Ok(())
}

fn get_clipboard_password() -> String {
    let mut ctx = ClipboardContext::new().unwrap();
    return ctx.get_contents().unwrap();
}

There, in two lines of code, we're able to get the clipboard content! Let's try it out. I'll just copy that last line.

Nice!

Fourth step: Making the user write the password

Finally, let's implement the last use case. We need to handle our user's input.

fn main() -> std::io::Result<()> {
    let args = Cli::parse();
    match args.cmd {
        Commands::List => display_passwords()?,
        Commands::Add {
            service,
            username,
            clipboard,
            generate,
            write,
        } => {
            println!(
                "{}, {}, clipboard: {}, generate: {}, write: {}",
                service, username, clipboard, generate, write
            );
            if generate {
                let password = generate_password();
                println!("{}", password)
            }

            if clipboard {
                let password = get_clipboard_password();
                println!("{}", password)
            }

            if write {
                let password = get_user_input();
                println!("You typed: {}", password.unwrap())
            }
        }
    }
    Ok(())
}

fn get_user_input() -> io::Result<String> {
    println!("Write it down the press Enter!");
    let mut input = String::new();
    match io::stdin().read_line(&mut input) {
        Ok(n) => return Ok(input.trim().to_string()),
        Err(error) => Err(error),
    }
}

We're using the read_line function from the Stdin struct. This means that the user can type what he wants until Enter is pressed. Let's run the app after cargo build:

Awesome! We now have our 3 ways to create a new password.

Fifth step: Scoring passwords

For our last functionality in this article, we are going to alert the user if a password is considered too weak ( when we get it from the clipboard or the user types it in ).

To give a password a score, we are going to use the passwords crate. Let's add it: cargo add passwords.

The process will look like this:

we get a password from the user's input or the clipboard
we use the passwords crate to check that password score
if the score is too low ( weak password ), we print out an alert to the user asking him to confirm that she's ok with the weak password.

I'm going to anticipate a "problem" we are going to encounter. For my use case, I would like the user to press Q or Enter to confirm or not that she wants to save a weak password. From what I understood, it's not straightforward to do this with the same io::stdin we used before because of the line-buffered nature of most terminals. Meaning, we have to wait for the user to press Enter to read the input. So, we are going to use the crossterm crate that allow us to read single chars from user's input. We can add it with: cargo add crossterm

Let's write some code:

use crossterm::event::{read, Event, KeyCode};
use crossterm::execute;
use crossterm::style::{Attribute, Color, Print, ResetColor, SetAttribute, SetForegroundColor};
use crossterm::terminal::{disable_raw_mode, enable_raw_mode};
use passwords::analyzer;
use passwords::scorer;

#[derive(PartialEq)]
enum WeakPasswordChoice {
    ABORT,
    CONTINUE,
}


fn should_save_password(password: &str) -> bool {
    if is_password_weak(password) {
        print_alert(password);
        if let Ok(choice) = read_next_char() {
            return choice == WeakPasswordChoice::CONTINUE;
        } else {
            return false;
        }
    } else {
        return true;
    }
}

fn is_password_weak(password: &str) -> bool {
    let score = scorer::score(&analyzer::analyze(password));
    return score < 80.0;
}

fn print_alert(password: &str) {
    let alert = format!(
        "{} is a weak password. Press Enter to continue anyway. Press Q to abort and try again!",
        password
    );
    execute!(
        io::stdout(),
        SetForegroundColor(Color::Red),
        SetAttribute(Attribute::Bold),
        Print(alert),
        ResetColor,
        SetAttribute(Attribute::Reset)
    )
    .unwrap();
}


fn read_next_char() -> io::Result<WeakPasswordChoice> {
    enable_raw_mode()?;
    let result = loop {
        match read()? {
            Event::Key(event) => {
                match event.code {
                    KeyCode::Char('q') | KeyCode::Char('Q') => {
                        break Ok(WeakPasswordChoice::ABORT);
                    }
                    KeyCode::Enter => {
                        break Ok(WeakPasswordChoice::CONTINUE);
                    }
                    _ => {}
                }
            }
            _ => {}
        }
    };

    disable_raw_mode()?;
    result
}

We added a lot of things here:

The should_save_password function takes the password and returns a boolean. It tells us whether or not the password can be saved in our file.
To achieve this, we first create a is_password_weak function. This function uses the analyzer and scorer from the passwords crate. By getting a score for our password, we are able to determine if it is weak or not. I chose to consider 80 or less as a weak score. To get more information, you can check the crate's docs.
If the password is considered weak. We print an alert to the user. We use the crossterm crate to style the output in the print_alert function.
The read_next_char function checks the next character the user will enter. To do this, we use crossterm's functionalities to make it easier. If it's a Q or q, we will abort. If it's enter, we will continue the process of saving a password.
To express those two choices, I created an enum WeakPasswordChoice. Notice that nothing happens if the user presses any other keys.

Note: The #[derive(PartialEq)] on the enum allows us to do comparison like this: choice == WeakPasswordChoice::CONTINUE;

Let's test it out by adding our should_save_password function in our clipboard and write use case:

  if clipboard {
        let password = get_clipboard_password();
        println!("{}", password);
        should_save_password(&password);
    }

    if write {
        let password = get_user_input().unwrap();
        println!("You typed: {}", password);
        should_save_password(&password);
    }

Let's run cargo build && ./target/debug/password_manager add -u myUsername -s aService -w:

Or: ./target/debug/password_manager add -u myUsername -s aService -c

Amazing! Now for the final step! We just need to connect the existing functionality of saving password to the code we just wrote.

Here's the full code for the end of our part 2:

use clap::{Parser, Subcommand};
use copypasta::{ClipboardContext, ClipboardProvider};
use rand::distributions::Uniform;
use rand::{thread_rng, Rng};
use std::io;
use std::io::Write;
use std::{
    fs::{self, OpenOptions},
    iter,
    path::Path,
};

use crossterm::event::{read, Event, KeyCode};
use crossterm::execute;
use crossterm::style::{Attribute, Color, Print, ResetColor, SetAttribute, SetForegroundColor};

use crossterm::terminal::{disable_raw_mode, enable_raw_mode};
use passwords::analyzer;
use passwords::scorer;

#[derive(PartialEq)]
enum WeakPasswordChoice {
    ABORT,
    CONTINUE,
}

#[derive(Parser)]
struct Cli {
    #[command(subcommand)]
    cmd: Commands,
}

#[derive(Subcommand)]
enum Commands {
    List,
    Add {
        #[arg(short, long)]
        service: String,
        #[arg(short, long)]
        username: String,
        #[arg(short, long, default_missing_value("true"))]
        clipboard: bool, // copy from clipboard
        #[arg(short, long, default_missing_value("true"))]
        generate: bool, // generate new password
        #[arg(short, long, default_missing_value("true"))]
        write: bool, // type new password
    },
}

fn main() -> std::io::Result<()> {
    let args = Cli::parse();
    match args.cmd {
        Commands::List => display_passwords()?,
        Commands::Add {
            service,
            username,
            clipboard,
            generate,
            write,
        } => {
            if generate {
                let password = generate_password();
                println!("{}", password);
                let _ = add_new_password(&service, &username, &password);
            }

            if clipboard {
                let password = get_clipboard_password();
                println!("{}", password);
                if should_save_password(&password) {
                    let _ = add_new_password(&service, &username, &password);
                }
            }

            if write {
                let password = get_user_input().unwrap();
                if should_save_password(&password) {
                    let _ = add_new_password(&service, &username, &password);
                }
            }
        }
    }
    Ok(())
}

fn get_user_input() -> io::Result<String> {
    println!("Write it down the press Enter!");
    let mut input = String::new();
    match io::stdin().read_line(&mut input) {
        Ok(n) => return Ok(input.trim().to_string()),
        Err(error) => Err(error),
    }
}

fn get_clipboard_password() -> String {
    let mut ctx = ClipboardContext::new().unwrap();
    return ctx.get_contents().unwrap();
}

fn generate_password() -> String {
    let charset: &[u8] = b"ABCDEFGHIJKLMNOPQRSTUVWXYZ\
                           abcdefghijklmnopqrstuvwxyz\
                           0123456789\
                           !@#$%^&*()_-+=[{]}\\;:'\",<.>/?";
    let mut rng = thread_rng();
    let password: String = iter::repeat_with(|| {
        let idx = rng.sample(Uniform::from(0..charset.len()));
        charset[idx] as char
    })
    .take(16)
    .collect();
    password
}

fn should_save_password(password: &str) -> bool {
    if is_password_weak(password) {
        print_alert(password);
        if let Ok(choice) = read_next_char() {
            return choice == WeakPasswordChoice::CONTINUE;
        } else {
            return false;
        }
    } else {
        return true;
    }
}

fn print_alert(password: &str) {
    let alert = format!(
        "{} is a weak password. Press Enter to continue anyway. Press Q to abort and try again!",
        password
    );
    execute!(
        io::stdout(),
        SetForegroundColor(Color::Red),
        SetAttribute(Attribute::Bold),
        Print(alert),
        ResetColor,
        SetAttribute(Attribute::Reset)
    )
    .unwrap();
}

fn is_password_weak(password: &str) -> bool {
    let score = scorer::score(&analyzer::analyze(password));
    return score < 80.0;
}

fn read_next_char() -> io::Result<WeakPasswordChoice> {
    enable_raw_mode()?;
    let result = loop {
        match read()? {
            Event::Key(event) => match event.code {
                KeyCode::Char('q') | KeyCode::Char('Q') => {
                    break Ok(WeakPasswordChoice::ABORT);
                }
                KeyCode::Enter => {
                    break Ok(WeakPasswordChoice::CONTINUE);
                }
                _ => {}
            },
            _ => {}
        }
    };

    disable_raw_mode()?;
    result
}

fn display_passwords() -> std::io::Result<()> {
    let path = Path::new("./passwords.txt");
    let contents = fs::read_to_string(path).expect("Could not read the passwords file");

    println!("{}", contents);
    Ok(())
}

fn add_new_password(service: &str, username: &str, password: &str) -> std::io::Result<()> {
    let path = Path::new("./passwords.txt");
    let password_infos = format!("{}|{}|{}\n", service, username, password);

    let mut file = OpenOptions::new().append(true).open(path)?;

    file.write_all(password_infos.as_bytes())?;

    Ok(())
}

Let's make sure everything works as it should:

And check the list in our file:

Yayyy!

Conclusion

In this article, we added quite a lot of functionality for our little application. We can now add passwords in three different ways and alert our user if their password is too weak. As always, feel free to tell me if some of this code could be improved, or if you would like to see some functionalities for this password manager. The full code can be found on github

Have fun ❤️!

Build a password manager with Rust - Part 1

Damien Cosset — Tue, 21 May 2024 17:59:54 +0000

Introduction

To learn a new language, I find it quite interesting to build something. Having simple features at first to get the hang of the language, then adding more stuff to it, making it more complex, faster, cleaner...

So this is what we'll try to do together in this series. We will build a password manager in Rust. The first article will start with simple features. By the end, we'll have a command line application with:

a way to display our passwords
a way to save a new password

No encryption, password generations, user interfaces... These will come later. Ok, let's go!

First step: The command line

For this project, we will use the Clap crate to interact easily with the command line. We already used it in this article.

So, let's recap what we want from our command line arguments:

an argument to list our existing passwords
an argument to save a new password

Here's how we can do it:

use clap::{Parser, Subcommand};

#[derive(Parser)]
struct Cli {
    #[command(subcommand)]
    cmd: Commands,
}

#[derive(Subcommand)]
enum Commands {
    List,
    Add {
        service: String,
        username: String,
        password: String,
    },
}

What's going on here? Using Clap, we define a Cli structure with a cmd. This can take two values, List or Add (in our enum Commands). Note that the #[derive(...)] syntax tells Rust that we want our enum or struc to implement certains traits. In our case, we want our enum Commands to implement the Subcommand trait from Clap.

Our List subcommand doesn't take any arguments. But our Add subcommand will take three, the name of the service, a username and a password.

Great! Let's add some code in our main function to see how we interact with all of this:

use clap::{Parser, Subcommand};

#[derive(Parser)]
struct Cli {
    #[command(subcommand)]
    cmd: Commands,
}

#[derive(Subcommand)]
enum Commands {
    List,
    Add {
        service: String,
        username: String,
        password: String,
    },
}

fn main() -> std::io::Result<()> {
    let args = Cli::parse();
    match args.cmd {
        Commands::List => display_passwords(),
        Commands::Add {
            service,
            username,
            password,
        } => add_new_password(service, username, password),
    }
    Ok(())
}

fn display_passwords() {
    println!("Will display passwords")
}

fn add_new_password(service: String, username: String, password: String) {
    println!("Will add new password.");
    println!("Service:{}", service);
    println!("Username:{}", username);
    println!("Password:{}", password);
}

We add a match in the main function to handle the different commands we can handle. We add two functions that will only print out something for now. Let's run it!

Cargo run list:

Cargo run add command:

What happens if we run the add command without the correct number of arguments?

It's another nice thing about Clap, it gives us helpful information about the arguments we can use. It also gives us the help command by default:

Step 2: Having a way to store our passwords

So, this works great, but our functions don't do anything yet. We need to decide how we are going to store our passwords. For now, we are simply going to have a .txt file. So, at the root of our project, we are going to add a passwords.txt file. We'll define some rules for our very simple implementation:

each password will have its own line in the file
on each line, we'll separate the service, username and password with a special character

This is obviously far from being perfect, but it will do the job in our quest to learn the language. Let's do it!

Our passwords.txt will have some entries already for testing purposes:

dev.to|Damien|my dev password
twitter|Bobby|123Awesome456

Our List command will read from this file and display its contents. Let's update our display_passwords function:

//All our imports
use clap::{Parser, Subcommand};
use std::{
    fs::{self},
    path::Path,
};

// Rest of the code ...

fn display_passwords() {
    let path = Path::new("./passwords.txt");
    let contents = fs::read_to_string(path).expect("Could not read the passwords file");

    println!("{}", contents)
}

We create a new Path with our relative file path and we pass it to the read_to_string function provided by the fs module.
Note: If you put the txt file in the src folder, your relative path will be ./src/passwords.txt.

The .expect() will print out the message we provided if we encounter an error. Let's check the results:

Nice! On to the next step.

Step 3: Adding a new password to our file

We're almost there! Now, we need to implement our add_new_password function.

Step 4:

Writing to the new file

fn add_new_password(service: String, username: String, password: String) -> std::io::Result<()> {
    let path = Path::new("./passwords.txt");
    let password_infos = format!("{}|{}|{}\n", service, username, password);

    let mut file = OpenOptions::new().append(true).open(path)?;

    file.write_all(password_infos.as_bytes())?;

    Ok(())
}

After creating our Path, we use format! to format our String we want to append to our passwords.txt file. Then, we use OpenOptions. Provided by the fs module, it defines how we want to open a file. In our case, we want to append data to the contents, so we use append(true). Notice that we use the mut keyword, to tell Rust that this variable is mutable.

Then, we use the write_all function to append our password informations. Careful, the write_all function expects a u8 primitive type for its argument. That's why we use as_bytes().

Finally, we return Ok(()).

And we should be done! Our full code looks like this:

use clap::{Parser, Subcommand};
use std::io::Write;
use std::{
    fs::{self, OpenOptions},
    path::Path,
};

#[derive(Parser)]
struct Cli {
    #[command(subcommand)]
    cmd: Commands,
}

#[derive(Subcommand)]
enum Commands {
    List,
    Add {
        service: String,
        username: String,
        password: String,
    },
}

fn main() -> std::io::Result<()> {
    let args = Cli::parse();
    match args.cmd {
        Commands::List => display_passwords(),
        Commands::Add {
            service,
            username,
            password,
        } => add_new_password(service, username, password)?,
    }
    Ok(())
}

fn display_passwords() {
    let path = Path::new(".passwords.txt");
    let contents = fs::read_to_string(path).expect("Could not read the passwords file");

    println!("{}", contents);
}

fn add_new_password(service: String, username: String, password: String) -> std::io::Result<()> {
    let path = Path::new("./passwords.txt");
    let password_infos = format!("{}|{}|{}\n", service, username, password);

    let mut file = OpenOptions::new().append(true).open(path)?;

    file.write_all(password_infos.as_bytes())?;

    Ok(())
}

Time to run this and test it out!

Adding a new password:

Listing our passwords list:

Yay! It works! Congratulations!

In this article, we explored a bit deeper the Clap crate to create subcommands. Then, we learned how to interact with files thanks to the fs module. In the next articles, we'll keep making this little project better. You can find the code here

Have fun ❤️

Create a command line application with Rust

Damien Cosset — Mon, 13 May 2024 21:52:14 +0000

Introduction

In this little post, we'll build together a very simple command line application using Rust. The goal of the program will be straightforward. We'll give it a directory name, and it will create a directory with that name. Easy enough right? Let's jump into it.

Setup

If you haven't set up Rust yet, do not hesitate to check out the official docs, there are a lot of great informations there.

Now, let's create our new Rust project. To do this, we can run the following command:

cargo new new_dir_cmd

This will create a new directory call new_dir_cmd. Of course, you can replace that name with whatever you want.

If you peek inside the newly created directory, you'll see the following:

Out of the box, if you run cargo run inside this directory. It will print out the good old "Hello World!"

Awesome, we're ready to go!

Creating a folder

First step, we're going to create a folder. We will improve our program step by step.

Let's put this inside our main.rs:

use std::fs;

fn main() -> std::io::Result<()> {
    fs::create_dir_all("/Users/damiencosset/Desktop/rust/new_dir_cmd/awesome_new_dir")?;
    Ok(())
}

We use the fs module from the std crate. Crates, in Rust, are similar to packages in other languages. If you want more informations about crates in Rust, you can check the docs.

We use the create_dir_all function from the module. It takes a path as an argument. For now, I'm giving it a hardcoded path.

Finally, this function returns a std::io::Result type. So we make our main function return that by adding -> std::io::Result<()>. After creating our new directory, we simply use the Ok variant that indicates that everything is fine.

Note: The ? character is used in Rust for error propagation. If we encounter a error during the directory creation it would return an Err(error), Err being the second variant that Result can take after Ok.

Let's run this code and check what we have:

It works! We have created our first new directory with Rust!

Adding the command line arguments

Obviously, this program isn't very useful. The goal is to give the directory name we want to create via a command line. Let's set this up.

Adding the clap crate

To parse command line arguments, we will use the clap crate. To add a crate, we go into our Cargo.toml file. You have a line that says:

[dependencies]

This is where we add the crates we want to use in our program.

Let's add clap by running the following command:

cargo add clap --features derive

The features flag allows us to use optional features in the crate. Here, we want to use the derive feature. To get more information about this crate, you can check the docs. And if you check our Cargo.toml, we now have a new line:

[dependencies]
clap = { version = "4.5.4", features = ["derive"] }

Defining our command line arguments

Let's replace our existing code with this:

use clap::Parser;
//use std::fs;

#[derive(Parser)]
struct Cli {
    directory_name: String,
}

fn main() -> std::io::Result<()> {
    let args = Cli::parse();
    println!("{}", args.directory_name);
    // fs::create_dir_all("/Users/damiencosset/Desktop/rust/new_dir_cmd/awesome_new_dir")?;
    Ok(())
}

We commented out the directory creation for now.
#[derive(Parser)] means that we are using a custom macro that implements the Parser trait. Simply put, a trait defines a set of methods. Here, we implement the set of of methods defined in Parser to our Cli structure. So our structure is able to call said methods, like parse().

With this code right there and the power of clap, we can parse command line applications. Let's run our code and give it an argument:

Nice! We successfully printed our argument. We can now parse the directory name from the command line.

Getting the current directory

Now, we have a little issue. We are not going to give the full path in our argument. We only give the directory name we wish to create. Therefore, our program needs to know where to create this directory. We'll do something simple, we'll take the current directory we are in, and append the directory name we put as an argument.

So we need to:

get the current directory's path
append the directory name to that path

To get the current directory's path, we can add these two lines of code:

// Import 
use std::env;

// Inside the main function
let mut path = env::current_dir()?;

Notice that we use the keyword mut. This means that the variable we just defined is mutable. Variables in Rust are by default immutable. By adding the keyword mut, we can modify it to append the directory name we wish to create.

By combining all of this, our completed program looks like this:

use clap::Parser;
use std::env;
use std::fs;

#[derive(Parser)]
struct Cli {
    directory_name: String,
}

fn main() -> std::io::Result<()> {
    let args = Cli::parse();
    let mut path = env::current_dir()?;
    path.push(args.directory_name);
    fs::create_dir_all(path)?;
    Ok(())
}

By using push(), we can append our directory name to the current directory's path. Let's see if it works!

Yay! It works!

And just like that, we build a very simple program in Rust that allows us to create new directories!

Hope you found it interesting!
Have fun ❤

Design Patterns: Observer

Damien Cosset — Sat, 11 Feb 2023 12:54:05 +0000

Observer pattern

Third stop on my journey: the Observer pattern.

The problem

Let's consider the following example. You run a company that sells video games. Some of your customers want to be notified when you receive the game they want to buy. Or maybe they'll want to receive an alert when a game of certain genre is for sale in your store.

We don't want the customer to check in with your store every day until what they want is available. We also don't want to send an alert to every single customer every time a new game comes out. Only certain types of customers are interested in certain types of games. We can't spam them all!

Here's the sort of problems that the Observer pattern allows us to solve. How?

Solving the problem

In the Observer pattern, we define two sorts of objects: the Publisher and the Subscriber.

The Publisher, also called Subject, is the object that holds interesting state. In our case, the Publisher would be our video game store. The Publisher knows which objects are subscribed to it.

The Subscribers, like the name indicates, are the objects subscribing to the Publisher. The subscribers can subscribe/unsubscribe to the Publisher object when they want to. The subscribers will then receive notifications from the Publisher when the Publisher state changes.

Class diagram

Let's look at a class diagram to see how the objects would interact with one another.

Our VideoGameStore is the client that creates our Publisher and Subscriber objects.

The Publisher holds a state. In this case, we called it videoGamesOfInterest, which would be the list of video games that our subscribers want to be notified about. Publishers have a subscription infrastructure that allows new subscribers to join the list, and actual subscribers to unsubscribe. The list of subscribers is not set in stone when we create our Publisher. Finally, our Publisher triggers events when its state changes. Theses events notify each Subscriber in the list.

The Subscriber object declares the notification interface. We have here an update method that can take a context so that the Publisher can pass along some details about the events.

Finally, our Client objects are the concrete Subscribers. They implement the Subscriber interface and will receive the events from the Publisher class. When the Subscriber receive the notification, it will usually perform some actions, that's why it's useful to send a context with the notification to help with that.

The code

Now that we have a structure in mind, let's see how that would be implemented directly in code.

Let's first create our VideoGameStore


public class VideoGameStore {

    List<VideoGame> listOfVideoGames = new ArrayList<>();
    public Publisher RTSPublisher;
    public Publisher FPSPublisher;

    public VideoGameStore(){
        VideoGame SC2 = new VideoGame("Starcraft 2", "RTS");
        VideoGame CallOfDuty = new VideoGame("Call of Duty", "FPS");
        this.listOfVideoGames.add(SC2);
        this.listOfVideoGames.add(CallOfDuty);
        RTSPublisher = new Publisher(SC2);
        FPSPublisher = new Publisher(CallOfDuty);
    }
    public void sellVideoGame(VideoGame videoGame){
        System.out.println("Selling " + videoGame.name);
    }
}

class VideoGame{
    String name;
    String type;
    public VideoGame(String name, String type){
        this.name = name;
        this.type = type;
    }

}

Our VideoGameStore holds a list of VideoGame. Each VideoGame has a name and a type. We then create 2 Publishers, one for the video game Starcraft 2, and another for the video game Call of Duty. Our Publisher code looks like this:

public class Publisher {

    List<Subscriber> subscribers = new ArrayList<>();
    private final VideoGame videoGameOfInterest;

    public Publisher(VideoGame videoGame){
        this.videoGameOfInterest = videoGame;
    }
    public void subscribe(Subscriber subscriber){
        this.subscribers.add(subscriber);
    }

    public void unsubscribe(Subscriber subscriber){
        this.subscribers.remove(subscriber);
    }

    public void notifySubscribers(){
        System.out.println(this.videoGameOfInterest.name + " has arrived!!");
        for(Subscriber subscriber: subscribers){
            subscriber.update( this.videoGameOfInterest.name + " has arrived!!");
        }
    }
}

Like we mentionned before, the Publisher holds a state. In our case, this is the video game of interest. The Publisher also has a list of subscribers. This would be the list of clients we need to notify when we get an update for our video game of interest. We can also subscribe or unsubscribe clients to this Publisher. Finally, the notifySubscribers function will send an update to each subscriber.

Each Client implements the Subscriber interface.

public interface Subscriber {
    void update(String context);
}

public class Client implements Subscriber{
    String name;
    public Client(String name){
        this.name = name;
    }
    @Override
    public void update(String context) {
        goToStore();
    }

    private void goToStore(){
        System.out.println(this.name + " is going to the store!");
    }
}

We keep things simple here. We pass a context to the update method, so our Client knows what happens. Then, when our Client receives the notification, we trigger a goToStore function. We could of course have more complicated logic in there.

Let's test it out:

public static void main(String[] args){

        VideoGameStore videoGameStore = new VideoGameStore();

        Client John = new Client("John");
        Client Sarah = new Client("Sarah");
        Client Paul = new Client("Paul");

        videoGameStore.FPSPublisher.subscribe(John);
        videoGameStore.FPSPublisher.subscribe(Sarah);

        videoGameStore.RTSPublisher.subscribe(Sarah);

        // We receive the new RTS game
    videoGameStore.RTSPublisher.notifySubscribers();

    // We receive the new FPS game
    videoGameStore.FPSPublisher.notifySubscribers();

}

After creating our VideoGameStore, we create 3 clients, John, Sarah and Paul. John is interested in the new FPS game, Call of Duty, so we subscribe him to the FPSPublisher we have, so he can be notified when the store has something new.

Meanwhile, Sarah is also interested in the Call of Duty game, but she's also interested in RTS games, so we subscribe her to our RTSPublisher.

Finally, Paul is not interested is neither FPS or RTS games, so we do not subscribe him to any of the Publishers.

The goal is to send updates to the clients that are interested in specific games, nothing more. Paul should not receive any updates.

Let's run this code:

Starcraft 2 has arrived!!
Sarah is going to the store!
Call of Duty has arrived!!
John is going to the store!
Sarah is going to the store!

First, we trigger our RTSPublisher notify function for the game Starcraft 2. Sarah is the only client subscribed to this publisher, so she goes to the store. As expected, nothing is sent to Paul and John because they don't care.

Then, we trigger our FPSPublisher notify function for the Call of Duty game. Sarah and John go to the store because they both subscribed to the Publisher. As expected, Paul didn't receive anything.

And that, in a nutshell, is how the Observer pattern works.

We could imagine a different Publisher for MOBA games, that Paul would be interested in for example. We could also imagine that Paul become interested in FPS games in the future and decides to subscribe to the FPSPublisher to get updates from now on.

What is important to realize is that this system is dynamic, the list of subscribers is not set in stone and can evolve over time.

Have fun <3

Design Patterns: Factory Method

Damien Cosset — Sat, 04 Feb 2023 17:47:14 +0000

Factory method

Second stop in my journey through the design patterns: the Factory Method.

The Factory Method Pattern defines an interface for creating an object, but lets subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Now, that might not be very clear so consider this diagram.

As you can see, we have a Creator class that declares a factory method, called createProduct. We can declare it as an abstract method, to force the all subclasses to implement their own createProduct logic.

The Product is an interface that is common to all subclasses and the creator. Concrete Products are different implementations of the Product interface.

This all sounds very generic, so maybe we can try a more "real-world" example.

Coffee Shop Empire

To illustrate a factory, we'll imagine ourselves running a coffee shop chain.

Below is a class diagram describing how things would be organized.

We have our Coffee Shop class that defines an abstract method orderCoffee. This is our factory method. Each coffee shop will implement their version of the orderCoffee method.

The goal of the factory design pattern is to let the subclasses decide which products they want to create. Let's look at the code.

public abstract class CoffeeShop {
    abstract Coffee orderCoffee(String type);
    abstract void openShop();
    abstract void closeShop();
    abstract void cleanTables();

}

This is our abstract class CoffeeShop. That's our creator class that every CoffeeShop will inherit. But, because it's an abstract class, it's up to the individual coffee shops to implement these methods.

Now, let's create two coffee shops, one in Paris, another one in New York.

public class ParisCoffeeShop extends CoffeeShop{
    @Override
    public Coffee orderCoffee(String type){
        Coffee coffee = null;
        if(Objects.equals(type, "Espresso")){
            coffee = new Espresso();
        } else if(Objects.equals(type, "Café au lait")) {
            coffee = new CafeAuLait();
        }

        coffee.brew();
        return coffee;
    }

    @Override
    public void openShop() {
        System.out.println("It's 10 AM!");
        System.out.println("Opening the Coffee Shop in Paris. Un petit café?");
    }

    @Override
    public void closeShop() {
        System.out.println("It's 4 PM!");
        System.out.println("Closing the Coffee Shop in Paris. A demain!");
    }

    @Override
    public void cleanTables() {
        System.out.println("Cleaning is occuring here...");
    }
}

public class NYCoffeeShop extends CoffeeShop{

    @Override
    public Coffee orderCoffee(String type){
        Coffee coffee = null;
        if(Objects.equals(type, "Espresso")){
            coffee = new Espresso();
        } else if(Objects.equals(type, "Cappuccino")) {
            coffee = new Cappuccino();
        }

        coffee.brew();
        return coffee;
    }

    @Override
    public void openShop() {
        System.out.println("It's 9 AM!");
        System.out.println("Opening the Coffee Shop in New York! Come in!");
    }

    @Override
    public void closeShop() {
        System.out.println("It's 6 PM!");
        System.out.println("Closing the Coffee Shop in New York! See you tomorrow!");
    }

    @Override
    public void cleanTables() {
        System.out.println("Cleaning in progress....");
    }
}

We can see here that each coffee shop determines at their subclass level which Coffee they need to make. The coffee shop in Paris doesn't need Cappuccino for example, so it doesn't even know the product's existence. However, their clients love some "Café au lait", so they added it to their menu.

In the same way, the coffee shop in New York added a Cappuccino to their menu. But, the "Café au lait" is nowhere to be found because their customers don't want that product.

Each coffee shop knows and instantiate only the products they need. What is interesting about this approach is that whenever we need to remove or add a product to a coffee shop, we only need to touch the coffee shop in question. The other coffee shops are totally independent from this implementation.

So, what about our products?

public interface Coffee {
    void brew();
}

public class Espresso implements Coffee{
    @Override
    public void brew() {
        System.out.println("Brewing Espresso!");
    }
}


public class CafeAuLait implements Coffee{
    @Override
    public void brew() {
        System.out.println("Brewing a Café au Lait");
    }
}

public class Cappuccino implements Coffee{
    @Override
    public void brew() {
        System.out.println("Brewing Cappuccino");
    }
}

We have a Coffee interface that declares a brew method. Then, every coffee type implements our interface and decide what they want to do in the brew method. The Coffee interface is common to all sub-products and coffee shops.

We are ready to open up our coffee shop chain! Let's run some code!

public static void main(String[] args){


        ParisCoffeeShop parisCoffeeShop = new ParisCoffeeShop();
        NYCoffeeShop nyCoffeeShop = new NYCoffeeShop();

        nyCoffeeShop.openShop();
        parisCoffeeShop.openShop();


        parisCoffeeShop.orderCoffee("Café au lait");
        parisCoffeeShop.orderCoffee("Espresso");

        nyCoffeeShop.orderCoffee("Espresso");
        nyCoffeeShop.orderCoffee("Cappuccino");
}

This code will log out:

It's 9 AM!
Opening the Coffee Shop in New York! Come in!
It's 10 AM!
Opening the Coffee Shop in Paris. Un petit café?
Brewing a Café au Lait
Brewing Espresso!
Brewing Espresso!
Brewing Cappuccino

Nice!

Now, what happens if we actually need to change some things? Few weeks after the opening, we realise that the customers needs are not what we thought they were!

In Paris, turns out the Espresso doesn't really work out, but the Cappuccino is in high demand! Meanwhile, in New York, clients are demanding a new product: Iced Coffee.

How do we handle this? Well, first step: creating our Iced Coffee product:

public class IcedCoffee implements Coffee{
    @Override
    public void brew() {
        System.out.println("Brewing a Iced Coffee!");
    }
}

Perfect! Now, let's got to Paris. We need to update the menu to remove the Espresso and add the Cappuccino. Easy fix in our orderCoffee method:

    public Coffee orderCoffee(String type){
        Coffee coffee = null;
        if(Objects.equals(type, "Cappuccino")){
            coffee = new Cappuccino();
        } else if(Objects.equals(type, "Café au lait")) {
            coffee = new CafeAuLait();
        }

        coffee.brew();
        return coffee;
    }

That's taken care of, let's update the New York coffee shop menu:

 public Coffee orderCoffee(String type){
        Coffee coffee = null;
        if(Objects.equals(type, "Espresso")){
            coffee = new Espresso();
        } else if(Objects.equals(type, "Cappuccino")) {
            coffee = new Cappuccino();
        } else if(Objects.equals(type, "Iced Coffee")) {
            coffee = new IcedCoffee();
        }

        coffee.brew();
        return coffee;
    }

There we go! Menus updated! Customers happy! And each coffee shop is able to update its products without all the different shops ever knowing about it!

Hopefully, that was an helpful explanation on the factory design pattern.

Have fun <3

Design Patterns: Singleton

Damien Cosset — Sun, 15 Jan 2023 11:07:45 +0000

Why Design Patterns

I'm at a moment in my developer journey where knowing design patterns is important. Understanding exisiting code, making sure to write new clean code, being able to communicate with more senior developers...

As a self-taught developer, I never really went deep into those subjects. I heard some of the patterns names, used it a couple of times but that's it. So, now that I decided to learn them properly, I'll share my journey with blog posts like these. Maybe you'll find them of some use, or you might even correct me if there are some mistakes ;)

Note: Code examples will be in Java because that's what I'm using in my work, and what my learning material uses.

Singleton

The concept

A Singleton Pattern ensures a class has only one instance, and provides a gloabl point of access to it.

A Singleton, like its name indicates, is an object for which there is only one instance. It's purpose is to make sure that there is only one instance of a object running at all time.

It's an important concept because some objects (like objects that handle logging or thread pools or caches for example) only need to be instantiated once. If you have more than one instance, it could create issues (logging the same things several times) and consume a lot of resources. On top of that, we have to make sure that our object is created only when we need it. There would be no point in creating an instance if the object is not used right away. This is one of the differences with a simple global variable.

Question is, how do we do that?

How

The Singleton class is the only class that can instantiate itself because the Singleton class constructor is private.
The Singleton class, therefore, is the only one that manages its instance.
Other classes can't create an instance of a Singleton. They only call the Singleton class. The Singleton class creates the instance (or returns the existing one).

Let's look at a code example:

public class Logging {
    private static Logging instance;

    private Logging(){}

    public static Logging getInstance(){
        if(instance == null) {
            instance = new Logging();
        }
        return instance;
    }

    // Other Logging methods...
}

Here is a Logging class. For my purposes, I only want one instance of this class running at all time.

You can note that the constructor private Logging(){} is indeed private. This class can't be instantiated from outside the class.

The getInstance method is static, meaning it's a class function and can get called anywhere with Logging.getInstance(). This is the method other classes will use to retrieve the Logging instance.

public class Main {

    public static void main(String[] args) {
        Logging LoggingInstance = Logging.getInstance();
        // This next line will fail! Constructor is private!
        Logging PleaseCreateInstance = new Logging();
    }
}

And that's how things would work. You would call the getInstance method to get the Logging instance to call other useful Logging methods. The new keyword would throw an error because the constructor is private! Awesome.

Multithreading

But what about multithreading? What if two differents threads access the Logging.getInstance() method at the same time? If both threads do not find an existing instance, they will each create a new instance. Therefore, you end up with two different instances of the Logging object... So much for being a Singleton huh...

You have a few options.

synchronized keyword

Java allows us to make synchronized methods by using the synchronized keyword, like so:

public static synchronized Logging getInstance(){
        if(instance == null) {
            instance = new Logging();
        }
        return instance;
    }

This will make sure that every thread will wait for its turn before entering the method. So, if two threads want to access getInstance at the same time, we won't create two different instances.

One problem with this approach: it's fairly expensive to synchronize the getInstance() method. Because every thread has to wait its turn, it creates a bottleneck when threads (or even a single thread) have to access the method. Plus, you really only need to synchronize the getInstance method at the creation of the Singleton, not once the instance has already been created.

Create the instance when the class is loaded

Another approach you could take is to eagerly create the instance. Actually, our code lazily creates the instance. We wait for the method to be called to create the instance for the first time.

We could modify the code like so:

public class Logging {
    /* Create our instance, now it doesn't matter 
if we have several threads calling the getInstance 
method at the same time */
    private static Logging instance = new Logging();

    private Logging(){}

    public static Logging getInstance(){
/* We always have an instance now, so we just return it right away! */
        return instance;
    }

    // Other Logging methods...
}

With this approach, this is the JVM that creates the instance when the class is loaded, and before any thread can access the method.

Use double-checked locking

Double-checked locking fixes the problem mentionned earlier by the synchronized keyword. It allows us to synchronize the method only if no instance has been created.

public class Logging {
    private volatile static Logging instance;

    private Logging(){}

    public static Logging getInstance(){
        if(instance == null) {
            synchronized (Logging.class) {
                if(instance == null) {
                    instance = new Logging();
                }
            }
        }
        return instance;
    }

    // Other Logging methods...
}

First, notice the volatile keyword for our Logging variable. This keyword makes sure that multiple thread handle the instance variable correctly when it's being initialized in the Logging instance.

Then, in the getInstance method, we synchronize only if we do not have an instance. In other words, we are able to synchronize the first time through the method only. So, if we already have an instance created, we do not get inside the first if block, and we do not get to the synchronized code, saving us from the bottleneck problem.

Note: This method will not work for Java 1.4 or earlier.

Conclusion

Despite its apparent simplicity, the Singleton's implementation can be tricky and we must be aware of the details. Things like multithreaded applications, the JVM version, the resource constraints or the number of class loaders can impact the way you implement this pattern.

Have fun <3

First step in management

Damien Cosset — Wed, 30 Nov 2022 20:28:15 +0000

New job, new me

It's been a while since a write something in here... Life gets in the way. I've been lucky enough to land a new gig, as a freelancer, and I have been tasked with managing a team.

It's been 3 months now that I took on a manager role, on top of the developer role and I thought it would be a good idea to write down this part of my journey. Not to teach, because I really don't know what I'm doing, but to record my experiences, organize my thoughts and perhaps learn from them.

The context

Quick word about the context. I have never been, in my 7 years as a freelancer, part of a team of developers. I have always been the only developer. Being part of a team is really something I've come to enjoy. This feeling of belonging to a group, working towards the same goal, speaking the same developer language has been a breath of fresh air.

The company recruited some new people, and I'm now managing 2 other developers, who are juniors. I consider myself to be an intermediate level, but I love the idea of spreading the little knowledge and experience I have to help others.

First steps

The first few weeks have been complicated. Obviously, when you don't know how to manage a team or a project, you have to make mistakes. I'm lucky to have a CTO that is always available to help, answer questions and provida guidance. In that regard, the environment is absolutely perfect.

There are, I believe, 3 things that went wrong for me at the beginning:

Not using all the resources at my disposal
Not understanding the bigger picture of the project
Not trusting my coworkers enough

I'll touch on the first one here.

To manage efficiently, I must understand what resources I can use. Resources can take different forms, but for example:

my team of developers
the CTO willing to help me
the company financial backing if I need tools
the product owners knowledge ...

Because of my career being the story of a lonely developer doing everything by himself, I didn't realise that I should use all of this to achieve our goals. I tried to do too many things by myself, where other people had the knowledge to tell me what should be done, or how it should be done, or even better, if it should be done al all...

So, the first few weeks became a one man show. One manager trying to do everything, because he didn't understand that the manager's job is to correctly use the resources at his disposal. To be efficient. We ended up meeting goals for the first month, but it was a grind, that ended with a few 12 hours work days for me and my team.

So that was my first lesson. Understand that I have a whole bunch of different tools at my disposal, and that I can be creative in the way I use them to achieve the goals I've been set.

Many more to come.

See you soon <3