Forem: Audrey Mengue

Le boiler plate HTML

Audrey Mengue — Mon, 23 Sep 2024 06:15:00 +0000

Le boiler plate HTML est le code basique HTML que nous devons non seulement connaître, mais surtout comprendre pour développer des sites ou des applications web de qualité. Celui-ci est donc composé de 2 principaux éléments à savoir le <DOCTYPE! html> et le html.

Le !DOCTYPE html est une déclaration qui indique au navigateur le type de document et la version de HTML utilisée car si aujourd’hui nous sommes à la version 5 du HTML, cela signifie qu'il y a eu des versions antérieures. Ces versions antérieures impliquent donc des déclarations antérieures mais cela fera parti d'un autre article. Cette déclaration doit être la première car elle permet au navigateur d'afficher la page convenablement.

la balise html lang='en' quand à elle est la balise racine à laquelle appartiendront toutes les autres balises. L'attribut 'lang' permet de spécifier la langue ce qui est très importante pour l'accessibilité car cela permettra aux lecteurs d'écran de correctement prononcer les mots.

À quoi resemble le HTML boilerplate (passe-partout)?

Ci-dessous nous avons le boilerplate html.

Nous pouvons aussi le représenter de cette façon.

Maintenant que nous connaissons les premiers éléments du boiler plate, il est temps d'aller un peu plus en profondeur.
Comme nous pouvons le voir ce le schémas et le code, la balise html en elle-même contient deux balises essentielles head et body.

La balise `head`

Contient toutes les informations dont les navigateurs et les moteurs de recherche ont besoin pour comprendre l’intérêt du site et le proposer à l'audience appropriée.

La balise meta charset='UTF-8': contient deux éléments très importants pour notre navigateur car ceux-ci vont l'aider à afficher le texte comme il faut. Ces éléments sont le charset et le UTF-8.
Le charset informe le navigateur sur la norme de codage des caractères ce qui permet à celui-ci de correctement interpréter la page.
Le UTF-8 est une codage de caractères qui contient quasiment tous les symboles utilisés dans les langue humaines.

La balise meta name="viewport" content="with=device-with", initial-scale="1.0" cette balise est tout aussi importante car elle permet d'adapter la page selon la taille de l'écran. Ces ajustements sont possible grâce aux différents attributs ci-dessous:
name='viewport: qui fait référence à la fenêtre d'affichage de l'écran selon l'appareil utilisé.
content="with=device-with": qui permet d'adapter le rendu de la page à la taille de l'écran de l'appareil.
initial-scale="1.0": qui permet d'afficher la page par défaut sans zoom.

La balise <meta http-equiv="X-UA-Compatible", content="ie=edge"> nous rassure d'afficher avec la plus récente version d'Internet Explorer de Microsoft.
http-equiv="X-UA-Compatible" permet d'émuler l'entête du mode rendu dans Internet Explorer.
content="ie=edge" permet d'assurer le rendu de la page avec la version la plus récente du moteur de rendu de Microsoft.

La balise <titre>My first boilerplate</titre> est l'une des balises visible contenue dans head car comme la balise, elle affiche le titre de la page actuelle sur le navigateur. Cette balise est d'une importance capitale car elle permet de nous retrouver lorsqu'on a. une navigateur qui a plusieurs fenêtres ouvertes. La balise nous permet de facilement retrouver nos pages et donc facilite notre expérience.

La balise `body`

Tout a long du développement de notre site ou application web, cette balise s'agrandira pour abriter tout le code qui va s'afficher sur notre navigateur. Une élaboration de ce qui doit contenu dans cette balise se fera dans nos prochain articles. Ce que nous pouvons retenir de cette balise c'est que si vous voulez que quelque chose s'affiche dans votre navigateur, insérez-le dans la balise body.

Pour conclure, nous avons vu les balises fondamentales de html. Mais il est néanmoins important de souligner que ces balises peuvent contenir plus d’éléments que ceux mentionnés ici. Restez câblé pour plus d'articles de ce genre.

The HTML tags I use the most in my projects.

Audrey Mengue — Mon, 08 Jul 2024 22:55:39 +0000

If you are interested in learning about web development, the first topic you will probably come across will be HTML. When it is presented to you in the first place, it might look like a lot to learn and it's normal, there is always a lot to learn in the tech industry. The hard truth is that you cannot be in tech without growing or learning but, the most important is what you learn and how you learn it.

There is a trinity raining on the Web kingdom, and they are HTML, CSS and JavaScript. And, you will almost always learn them in that order. In today's topic, let's learn about HTML.

What is HTML?

It stands for HyperText Markup Language. It is the language used to create documents on the Web.

What does it provide?

The reason why we cannot talk about building for the Web without talking about HTML is for the following reasons:

Web pages: HTML is the foundation you need in order to create web pages. And if you can create one page then why not a website which is a collection of web pages.
Structure: HTML will give a structure to your content by the use of semantic tags such as links, paragraphs, navigation etc.
Easy to understand: HTML's tags are basic English. It's almost easy to guess the tags and the syntax too is pretty easy to understand.
Navigation: with HTML, we can create hyperlinks which will help us navigate amongst our web pages.

The tags I use the most.

There are so many tags available to learn, but as humans, we cannot learn all. Here are the little tags I am using almost on daily basis:

Headings: They vary from <h1> to <h6> and they are used as section's titles and subtitles. <h1> being the biggest, it's advisable to only use one <h1> per page for the main title.
Paragraphs (<p></p>): It's one of the most used one. I mean, who builds a site or a web app without a text content? Paragraphs

will hold the text I need to display on the page.
Buttons (<button></button>): whether I want to navigate to another section of the page or a new page altogether or even trigger actions (like submitting a form), clicking a button is probably what I will do. They are very important tags.
Ul (<ul></ul>) and li(<li></li>): Navigation bars are mostly done with these elements. All I need is to style them to fit my needs in terms of design.
Anchor <a></a>: typically used to navigate from one page or resource to another. They are usually designed like buttons but they are not.
Division <div></div>: a very popular tag of mine too is the division tag. It is a box that gives so much flexibility in terms of what it can hold. We can group so many other tags in a div and style or manipulate that group the way we need.
Image <img/>: this tag holds images in many formats. It is used a lot for logos or pictures.
Input <input/>: this tag is used to help users interact with the page. This tag had different types which allow people to enter data such as numbers, texts, emails etc.
Form <form></form>: Last but not least on our post is the form tag. This tag is used to collect and submit the data collected to a server. Whether you are building a website or a web app, you will probably need it to collect data.

We are through with this post, but it's important to understand that there are so many other essential tags to know out there. You can share the tags you use the most in your project in the comment section and I will be happy to learn new things.

All you need to get started with web development.

Audrey Mengue — Sun, 26 May 2024 16:15:22 +0000

Getting started with web development can be overwhelming sometimes especially for those who transition into tech or have never been exposed to it. I am writing this article to simplify your journey by highlighting what you really need to get started with web development. The basics consist of three main things. A web browser, a code editor and programming skills.

A web browser

A web browser is a piece of software that allows us to interact with resources on the web. The resources include websites, web applications, cloud ecosystem etc. In short, a web browser is the place where web applications are accessed. Even though we need web browsers to access our web resources, modern web browsers do a lot more than that with developer tools. The developer tools are very necessary as they help debug errors, inspect code, analyse performance of the application. Some of the most recommended web browsers include Google Chrome, FireFox etc.

A text editor

The next thing you will need is a text editor. It's a software in which we will write the code for our application. Some code editor are already included in the operating system. We have TextEdit for Mac OS and Notepad for Windows PCs. The advantage is that they are very simple to use but the limitations are also important to notice. For example, we do not have text formatting, text or code completion is these editors. It's plain text. And that is why most tutorials will recommend more advanced editor like Visual Studio Code, Atom or Sublime Text. They offer better visual when writing code.

Programming skills

Last but not least, programming skills. Even though some languages are cross platform, it is very important to understand that the Web has its standards and they are HTML, CSS and JavaScript. Yep, you will need to know them in order to build for the Web.

- HTML: will provide the structure of the page;
- CSS: will allow us to style our Web pages;
- JavaScript: will make our pages dynamic;

In my experience, these are the main things you need in order to get started in web development. The first two items (Web browser and text editor) are generally installed the same day. The programming skill on the other side will definitely take longer but; do not worry just watch out for this space for more in-depth articles on each technology mentioned here. I cannot leave without asking you what you think can be added to this list to make learning Web development less stressful.

3 small projects to help you build big applications.

Audrey Mengue — Tue, 21 May 2024 21:39:20 +0000

Remember the days we all started to learn how to code and we were always told to learn the basics first? Well turns out our teachers and YouTube instructors were right, it's important to master the basics but "how to master the basics" is the question we need to ask ourselves. And in this article, I will try my best to give a response to the why.
Honestly, coding only starts to make sense when you practice; and here are three small projects that will help you solidify your basics and, give you the ability to code more complex applications.

To-Do list App

I like to call it "the almighty To-Do list App". This is by far one of the most popular applications you will be asked to build as a beginner and it makes sense trust me.

Context:
This application will require you to create, read, update and delete your To-Dos or tasks.
What you learn:
How to manipulate the DOM, how to handle events and use localStorage for data persistance.
The stacks:
HTML, CSS and JavaScript for beginners or React and Express for more advanced developers who want to build a more complex App.
Bigger Apps inspired by it:
Ok, this is where I get very creative but when I look at project management tools, I can't help but to see that even though they are very complex, the principle remains the same. Even though they organise work very well, they are all about creating, reading, updating and deleting tasks. To me, they are very big To-Dos Applications.

Weather App

Yep, this is another star of the show in the developer community. If you just learn JavaScript, you've got to know how to work with API an display the data very well.

Context:
This application will show us how to consume API in other words, it will help us use the data someone has made available to us to use via a program that they have written. We could go deeper in defining what APIs are but that is besides the point. All we know here is that there is data somewhere and we want to display it in our App.
What you learn:
How to use the Fetch API from JavaScript, how to work with endpoints, understanding HTTP Methods, handling errors and much more.
The stacks:
HTML, CSS, JavaScript for a start and add frameworks of our choice for more complex applications.
Bigger Apps inspired by it:
Honestly, all weather Apps are the same. One of the big difference is that most of the biggest Apps can do forecast. But yes, once you have learned to do a small weather app, you can do more complex ones.

Chat App

Last but not least, we have the chat app aka the most complex amongst all. This application consists of sending and receiving messages in real time and to do that, we will need to learn more than we already know.

Context:
Allow you and your friends to exchange messages instantly.
What you will learn:
How to manage user sessions, webSockets, servers, user interface and this is valid for a simple application. It can get more complex.
The stacks:
HTML, CSS, JavaScript, NodeJS etc.
Bigger Apps inspired by it:
No matter what messaging platform you want to use, it will always be the same principle. We would want to see how many users we can chat with, we would want to see our past conversation so we can follow the conversation. This application can even be part of a bigger application as a functionality. So it's a very important app to build at the beginning of our career.

That is it mates for the post. I know we have all had advices on what to build when we get started with in tech as a developer so share below some applications you found useful to learn when you got started. Watch out for this place as we will build these projects here on this platform.

Vos commandes Git quotidiennes

Audrey Mengue — Wed, 15 May 2024 07:21:08 +0000

Que vous travailliez seul ou en équipe, Git est un outil essentiel. Les développeurs l'utiliseront pour les aider à suivre les changements dans leur base de code au fil du temps. Il est parfois appelé une machine à voyager dans le temps mais nous ne voyageons qu'au passé. Il est important de comprendre que vous n'avez pas toujours besoin de GitHub pour travailler avec Git, vous pouvez initialiser Git dans votre projet et commencer à suivre votre code mais pour cet article, nous supposerons que le code principal est dans le cloud (GitHub). Il y a beaucoup de commandes que nous utilisons lorsque nous travaillons avec Git. Mais pour votre travail quotidien en tant que développeur ou développeuse junior par exemple, vous aurez juste besoin de quelques-unes d'entre elles.

git clone

Un clone est une copie ou une réplique de quelque chose. Cette commande est de loin l'une des plus auto-descriptives de toutes. Oui, vous l'avez deviné, c'est une commande qui nous obtient une copie du dépôt, aussi appelé projet, que nous avons dans le cloud sur notre machine locale. Pour exécuter le code, ouvrez votre terminal à l'endroit où vous souhaitez enregistrer la copie du projet et saisissez la commande suivante :
git clone <url of your project on GitHub>

git branch

Après avoir cloné le dépôt, nous sommes sur la branche principale. Lorsque vous travaillez sur un projet, il n'est pas conseillé de travailler sur la branche principale (anciennement appelée "master") car elle est destinée à contenir le code final. Le code final est considéré comme le code sans bugs en production. En d'autres termes, personne ne touche à la branche principale, c'est pourquoi nous créons de nouvelles branches. Une nouvelle branche porte le nom de son objectif pour la traçabilité ; certaines branches sont appelées "test", "release", "dev", etc. La convention de nomenclature dépend vraiment de l'équipe. Pour ma part, la branche porte le nom du ticket sur l'outil de gestion de projet (Taiga par example). Pour créer une branche, exécutez cette commande dans votre terminal :
git branch <nom choisi ou nom de ticket>

git pull

Pour obtenir toutes les modifications sur une branche particulière, nous devons les récupérer. Cette commande nous aidera à obtenir toutes les modifications présentes sur la branche distante et à les fusionner dans la branche locale. Avec cette commande, les branches locale et distante ont les mêmes informations. Une chose à remarquer avec cette commande est que si deux développeurs ont apporté des modifications sur la même ligne de code, un conflit de fusion peut survenir et comment le résoudre seul est un autre sujet. Exécutez la commande suivante pour récupérer toutes les modifications de votre branche distante dans votre branche locale :
git pull

git checkout

Créer une branche est une partie cruciale du suivi de votre projet avec git mais ce n'est pas tout. Nous devons y travailler et pour ce faire, nous devons quitter (checkout) la branche actuelle sur laquelle nous sommes pour passer à la nouvelle branche que nous avons créée et commencer à y faire des modifications. Comme nous le constatons, c'est un anglais simple. En fait, la langue est tellement intuitive qu'il est presque impossible de rater le point. Pour passer à une nouvelle branche ou à une branche existante, ouvrez votre terminal et exécutez la commande suivante :
git checkout <nom de la branche>

git status

De loin l'une des commandes git les plus utilisées. Cette commande est destinée à donner le statut de la branche actuelle sur laquelle nous sommes. Si la branche a été modifiée, elle vous donnera le nom des fichiers qui ont été modifiés avec leur emplacement. Cela nous permettra de faire une dernière vérification sur les modifications qui ont été apportées et de voir si elles nous conviennent. Si la branche n'a pas de modifications, lorsque nous exécutons la commande, nous verrons un message comme "Déjà à jour". En résumé, cette commande nous aide à voir les fichiers qui ont été modifiés et sont prêts à être ajoutés à notre prochain commit, les fichiers qui ont été modifiés mais pas mis en scène (sauvegardés) et les nouveaux fichiers qui n'ont pas encore été suivis par Git. Pour vérifier le statut de votre branche actuelle, exécutez la commande suivante dans votre terminal:
git status

git add

Après avoir modifié le statut d'un fichier ou créé un nouveau fichier dans la branche actuelle, il est tout naturel de le mettre en scène ou le sauvegarder afin de pouvoir l'inclure dans notre prochain commit, et c'est le rôle de cette commande. Avec cette commande, nous indiquons essentiellement à git d'enregistrer une copie du fichier actuel tel qu'il est avant de le committer. Il est important de comprendre que cette commande ne commit pas les changements, mais conserve plutôt une version du fichier que nous allons commit ultérieurement. Pour mettre en scène vos modifications, exécutez la commande suivante :
git add <nom du fichier>
git add . mets en scène ou sauvegarde tous les fichiers.

git commit

Cette commande vise pour moi à sceller le sort d'un ou plusieurs fichiers. En d'autres termes, nous disons à Git que nous sommes d'accord avec toutes les modifications que nous avons apportées à ce moment précis, donc gardez-en une copie permanente. Pour une meilleure compréhension et traçabilité, nous devons ajouter un message à notre commit, donc le drapeau "-m". Le message de commit doit être clair et concis afin que les autres développeurs (ou nous-mêmes) travaillant sur le projet puissent comprendre de quoi il s'agit. Pour commettre vos modifications, exécutez la commande suivante :
git commit -m "message"

git push

La dernière mais non la moindre commande utilisée doit être "git push". Elle transfère les modifications locales vers le dépôt distant (GitHub dans notre contexte). Mais pour pousser ces changements, elle doit d'abord vérifier si la branche pointe vers sa branche distante avec le même nom. Si la branche distante n'existe pas, Git fournira une commande qui configurera une branche amont avec le même nom. La commande ressemblera à ceci : git push --set-upstream origin . Je ne tape jamais cette commande car elle est toujours fournie par Git. D'autre part, si la branche locale a un homologue distant et est à jour, alors nous pouvons simplement pousser les changements en exécutant la commande suivante :
git push

Comme mentionné quelque part dans ce post, Git a beaucoup plus de commandes utilisées pour effectuer des tâches spécifiques. Mais celles-ci sont celles que j'utilise le plus dans mon travail quotidien. Quelles commandes ajouterez-vous à cette liste comme votre commande Git la plus utilisée au quotidien ?

Your daily Git commands

Audrey Mengue — Wed, 15 May 2024 06:47:28 +0000

Whether you work alone or in a team, Git is an essential tool. Developers will use Git to help them track the changes in their code base overtime. It is sometimes referred to as a time travel machine but we only travel in the past. It is important to understand that you do not always need GitHub to work with Git, you can initialize Git in your project and start tracking your code but for this post, we will assume that the main code is in the cloud (GitHub).
There are a lot of commands we use when working with Git. But for your day-to-day job as a junior developer for example, you will need just few of them.

git clone

A clone is a copy or a replica of something. This command is by far one of the most self-descriptive of all. Yep, you guested, it is a command that gets us a copy of the repository aka project we have in the cloud into our local machine. To run the code, open your terminal where you want to save the copy of the project and type the following command:
git clone <url of your project on GitHub>

git branch

After cloning the repository, we are on the main branch. When working on a project, it is not advised to work on the main (formerly master) branch since it is a meant to contain the final code. The final code is considered as the bug-free code in production. In other words, nobody touches main that is why we create new branches. A new branch bears the name of its purpose for traceability some branches are called "test", "release", "dev" etc. The naming convention really depends on the team. For my part, the branch bears the name of the ticket on the project management tool (Taiga). To create a branch, run this command in your terminal:
git branch <chosen name or ticket's name>

git pull

To get all the changes on a particular branch, we need to pull them. This command will help us get all the changes present on the remote branch and merge them into the local branch. With this command, both the local and the remote branches have the same information. One thing we have to notice with this command is that if two developers have been making changes on the same line of code, a merge conflict can occur and how to fix it alone is another topic. Run the following command to pull all the changes from your remote branch into your local branch:
git pull

git checkout

Creating a branch is a crucial part in tracking your project with git but that is not all. We must work on it and to do so, we have to leave (checkout) the current branch we are on to the new branch we created and start working on it. As we realize, it is simple English. In fact the language is so intuitive that it is almost impossible to miss the point. To move to a branch new or existing, open your terminal and run the following command:
git checkout <branch's name>

git status

By far one of the most used git commands. This command is meant to give the status of the current branch we are on. If the branch has been modified, it will git you the name of the files that have been subject to modification with their location. This will allow us to make a last check on the modifications that have been made and see if they suit us. If the branch has no modifications, when we run the command, we will see a message like "Already up to date". In summary, this command helps us see files that have been modified and are ready to be added to our next commit, files that have been modified but not staged and new files that have not yet been tracked by Git. To check the status of your current branch, run the following command in your terminal:
git status

git add

After modifying the status of a file or creating a new file in the current branch, it is just natural to stage it so we can include it in our next commit and that is the role of this command. With this command, we are basically telling git to record a copy of the current file as it is before we commit it. It is important to understand that this command does not commit the changes, rather keeps a version of the file that we will commit later on. To stage your changes, run the following command:
git add <file name> to stage a single file
git add . to stage all the modified files

git commit

This command to me aims at sealing the faith of a one or many files. In other terms, we are telling Git that we are ok with all the changes we made at this particular moment so keep a permanent copy of it. For better understanding and traceability, we must add a message to our commit therefore the "-m" flag. The commit message must be clear and concise so other developers (or ourselves) working on the projet can understand what the modifications are about. To commit your changes run the following command:
git commit -m "<message>"

git push

The last but not the least command used has to be "git push". It transfers the local changes to the remote repository (GitHub in our context). But to push those changes, it has to first check if the branch points to its remote branch with the same name. If the remote one does not exist, Git will provide a command that will set up an upstream with the same name. The command will look like this: git push --set-upstream origin <local branch's name>. I never type this command since it is always provided by Git. On the other hand, if the local branch has a remote peer and is up to date then, we can simply push the changes by running the following command:
git push

As mentioned somewhere in this post, Git has a lot more commands used to perform specific tasks. But these are the ones I use the most in my day-to-day job. What command will you add to this list as your day-to-day most used Git command?

The key phases of software development (simply put).

Audrey Mengue — Sun, 12 May 2024 23:39:24 +0000

Simply put, software development is the process of creating a software product. As someone with three years of experience in the industry, I can say it consists of three main parts.

Understanding the problem
Developing the solution
Deploying the solution

After listing the phases, it is important to understand that even if each phases have their own actors and deliverables, they very much depend on each other. We cannot build a solution that we do not understand and we cannot deploy a product that does not exist.

Now that we have clearly identify the different phases, let's dive in details into each one.

I. Understanding the problem

This phase consists of clarifying any sort of doubts related to the problem we want to solve. In other words, we have a lot of questions to ask and have as much meetings as we need to make sure we solve the problem the best way possible. In this phase, we need to come to an agreement before proceeding because we do not want to build a solution that doesn't solve the problem or solves it partially. In this phase, the deliverables for this phase are usually the following:

A user requirements list (functional and non functional).
A list of features
A backlog of tasks
A prototype
A contract to seal the deal (if applicable).

The team in this phase is made of the product owner, team lead, project manager, the client or their representatives.

The deliverables of this phase much teach us everything need to build a solution that will actually be used. It is the only way to make sure that we get into the second phase with much assurance that we will be developing a solution not just another application.

II. Developing the solution

As we said in the introduction, the phases depend on one another. Imagine how confused one can be if we were just asked to build a solution without being allowed to ask questions. In this phase, we assume that the solution is clear to every stakeholders because all questions have been asked and rightly answered in the previous phase. In the agile methodology, it is during this phase that the product comes to life. The deliverable for this phase consists of the following:

The working solution

The different profiles involve are usually the scrum master, the developers, the testers and the client.

The only outcome expected from this phase is a working solution. But, it is very important to understand that this solution can be broken into modules that are ready to be used because we are in continuous development. And only this phase can take us to the deployment of the solution.

III. Deploying the solution

From my experience, this phase is by far the most tricky one because it can last long or short or put the entire project in danger if not handled correctly. Testing the application in local environment is totally safe but on the internet, we are exposed to all sort of dangers. The outcomes for this phase include:

A CICD setup for the application/solution
A working solution deployed on the internet
Proper detailed documentation

The core team in this phase includes devOps, system administrators, trainers in case the solution targets a specific set of users and clients.

In my opinion, the making of a software solution depends a lot on these phases as they give us a clear understanding of what the solution is, how to develop it and finally, how to deploy it. Although these phases help me a lot, it's important to find a system that suits your use case better. After all, this field is all about creativity so it's important to not restrict ourselves but to continue exploring till we find what works best for us.

Comment développer une extension Google Chrome.

Audrey Mengue — Sat, 22 Apr 2023 18:53:27 +0000

L'une des découvertes dont le monde bénéficie le plus aujourd'hui est sans aucun doute celle d'Internet. Par exemple, cet article ne vous sera accessible que si vous disposez d'un navigateur. Mais savions-nous qu'un navigateur peut faire bien plus que nous permettre d'accéder à des pages Web ? La réponse est oui et les extensions ne sont qu'un exemple. Et dans cet article, nous allons apprendre à développer une extension.
Alors si vous êtes débutant, cet article est fait pour vous.

Qu'est-ce qu'une extension?

Une extension pour moi est une application qui ajoute des fonctionnalités à notre navigateur. Par exemple, des extensions telles que Ad-Block transforment notre expérience en bloquant les publicités dans notre navigateur.

Ce que nous allons développer.

Une extension qui nous montre des blagues à chaque fois que nous cliquons dessus - les blagues sont en anglais et pas toujours drôles.

Conditions préalables

Les bases de JavaScript comme les fonctions
HTML
CSS ( optionel )
Manifest
Le navigateur Google Chrome
Le DOM
Fetch
Editeur ( VS Code )
Bootstrap CDN

Créons l'extension

Créons un dossier du nom de jokesextesion
Ouvrons-le dans VS code et créons trois fichiers index.js, index.html et manifest.json

Dans le fichier index.html, nous avons un document de base qui contient un titre, un paragraphe dans lequel notre blague apparaîtra et un lien qui mène au script. Notre fichier ressemble à ceci :

Dans le fichier index.js, utilisons le fetch pour accéder aux ressources de jokesapi et manipulons le DOM pour afficher la blague dans une balise de paragraphe. Le fichier index.js ressemblera à ceci :

Le fichier Manifest
Ce fichier est certainement le plus important de tous. En effet, c'est lui qui contient toutes les informations dont notre navigateur a besoin pour enregistrer notre application en tant qu'extension. Nous pouvons créer ce fichier en premier ou en dernier, l'essentiel est qu'il soit présent dans le dossier qui contient tous les autres fichiers .js, .html et qu'il soit enregistré avec l'extension .json. Voici a quoi resemble notre fichier Manifest:

nom/name: C'est le nom qui apparaîtra lorsque nous plaçons notre curseur sur l'icône de notre extension.
version: Ceci est la version de notre application que nous offrons.
description: Consiste à donner des informations sur ce que fait notre extension.
manifest_version: Est déterminée par Google
auteur/author: Le createur/trice de l'extension
default_popup: C'est le contenu de ce fichier qui sera affiché lorsque nous activerons notre extension.

Téléchargeons notre fichier dans Chrome

Localisons les settings/paramètres dans notre navigateur puis appuyons sur extensions.

Assurons-nous que le mode développeur est activé

Cliquons sur load unpacked et localisons notre projet

Dès que vous voyez le chargement du projet, vous verrez un toast avec le message "extension ajoutée" et l'extension est prête à être utilisée. Vous pouvez l'épingler et le tester.

Alors, prêt à développer une extension ? Voici quelques liens utiles :
Jokes API: https://sv443.net/jokeapi/v2/
Source code: https://github.com/audreymengue/jokesextension
Guide de Google: https://developer.chrome.com/docs/extensions/mv3/getstarted/development-basics/

Building a simple Chrome extension with JS

Audrey Mengue — Tue, 28 Mar 2023 22:34:27 +0000

What is it and why do we need it?

As web developers, we spend the majority of our time - if not our time - in the browser. In short, we build stuff that runs in the browser so while we are here, why don’t we just get the best experience out of it. A browser extension isn’t just a program that works in the browser but, it’s a program that enhances our browser’s capacities. From ad blocking to visualization, there is a browser extension for everything and in this tutorial, we are going to learn how to make one.

What we are building and prerequisites.

We are going to build an extension that will display a joke any time we click on it. This can be helpful for anyone feeling down when facing a bug. We will need a basic understanding of:

JavaScript
HTML
CSS (optional)
DOM
Fetch
A web browser ( Google Chrome )
A code editor ( VS Code )

The manifest file

This is the file that will be uploaded to our browser in order for our extension to work. The manifest file is a JSON file that contains metadata about our application such as the name, the version, the icons etc. This file can become really complex depending on what we want our extension to achieve.

Let's build the extension

Create a folder and give it a name. I will call mine “jokesextension”
Open your folder in the code editor and create 3 files, index.js, index.html and manifest.json

In the index.html, create a basic document and in our body, let’s have a div in which we will display the title of the extension as well as the joke itself. The index.js will look like this:

In the index.js file, let’s use the fetch to access resources from the jokesapi and manipulate the DOM to display the joke in a paragraph tag. The index.js will look like this:

In the manifest file, we have the following:

“Name” this will be the name of our extension
“Version” the version of the extension
“Description” a brief description of our application
“Manifest version” the API that will determine how the browser will interact with the extension
“Author” the creator of the extension
“Default_popup” refers to the html content that will be displayed when the user clicks on the extension

Upload the folder to the Chrome browser Navigate to your extension tag in the browser

Make sure your developer mode is toggled on

click on load unpacked and locate your project

As soon as you see the load the project, you will see a toast with the message "extension added" and the extension is ready to be used.

Thanks for making it this far. I hope this will help getting started with building browser extensions.

Additional resources:

Jokes API: https://sv443.net/jokeapi/v2/
Source code: https://github.com/audreymengue/jokesextension

The importance of having a side gig as a Software Engineer.

Audrey Mengue — Fri, 06 Jan 2023 20:57:41 +0000

Photo by Glenn Carstens-Peters on Unsplash

Side gigs are referred to as side hustle in Software Engineering. To be honest, I don’t know if it’s called that in every profession but you will hear that expression a lot when you start working as a Software Engineer. So why don’t we just discuss a few points that might be helpful in case you hear of it.

Side gigs are not only about money.

The primary reason someone would take on side gigs should not be because of money only but for growth. Don’t get me wrong, you should be paid to work but think about it this way. You have a job in which you do really great but most of the time you already know what you are going to do for the entire day. Like we will mostly say, you sleep, eat code and repeat. That routine is ok but it can get really boring at some point and that’s when side gigs can come in handy. With a side gig you can work on something completely different from what you do at your 9 to 5. You could work with different tools and technologies, and solve different problems all together. I hope you can feel the excitement in this article that will help you take on side gigs more often to spice up your life when the routine becomes boring.

Side gigs for growth.

Alright, that heading reads more like a commercial ad but it is the truth. Side gigs help us grow in terms of skillset, let me explain. All tutorials for beginners out there will teach you how to work and build applications that the entire world has already built, from the almighty JavaScript Clock to the unbeaten Todo List application in JavaScript. But side gigs on the other end are usually applications that people use, in other terms you are literally applying your problem solving skills and that is the way you improve on the job. The tech industry is a never ending learning field - that’s how I call it - but it is also very necessary to understand that the best way to learn is by doing. So having to work on side gigs is by far the best way to learn and master your craft.

Side gigs help you have leverage.

Now imagine having two aspiring developers who graduated the same year and applying for an entry level position at the same company. They both took that tutorial online that has lots of stars and they finished all the capstone projects, exercises and eventually got their certificates. But one of them decides to also start freelancing without charging their clients and add these projects to their portfolio. Now, the other one decides to just apply with the projects they built from the tutorial and not freelancing. Who do you think can easily land that job knowing that the interview is based on portfolio projects? I bet it’s the one with side gigs added to their portfolio. They stand a high chance because they went the extra mile with the little they knew, to any interviewer, they wanted more than what a tutorial had to offer and therefore stand out from the crowd.

I understand side gigs are hard to come by so there is only one thing I can advise you to do, be authentic, by that I mean build applications that reflect who you are or the kind of engineer you aspire to be. Do you and good luck on your journey.

Mistakes to avoid when working in a fast-paced environment.

Audrey Mengue — Thu, 05 Jan 2023 20:52:58 +0000

Photo by charlesdeluvio on Unsplash

It’s good to be passionate about what we do but unfortunately, it’s not the only thing we need in order to make it to the next day. Let’s develop resilience together with these few points.

Not having an updated version of the codebase.

Being part of a team means expecting to be working on a codebase that constantly changes. Pulling from the changes that have been merged can help one stay up to date and discover bugs as soon as possible. What happens is that we usually have a branch called develop - depending on your naming convention - this is where all the code will be pushed to in order to be tested. Then we have the almighty main branch which is usually the one that contains the clean code or production-ready code - an advice, leave main alone. Last but not least, we have the individual branches from everyone on the team. Each dev will have their code up there and raise pull requests against develop. And create branches from develop too so it’s very important to keep it up to date. The reason why you should have it up to date is to make sure to be able to do an end-to-end testing of the entire application locally as a backup. So always keep your code up-to-date.

Not owning the project you are working on.

Having a sense of ownership is very key to the success of an application or a project. It’s important to look at it in a way that your code is going to be used by many people. Your Code. Owning a project means that you will give it your all and above all so you can proudly say you contributed. We own the project because as engineers, our biggest pride is our job and the impact it has on solving the issues that our world faces. That sense of ownership got people sleeping in garages for years and then coming out with the biggest brands we know today. If we keep that attitude, we may be able to face any bug and fix it and go to bed with a great sense of satisfaction. A sense of ownership makes us good programmers who care about the the users, the product, and the company.

Not curious about what others are working on.

Being part of a team means working together, not freelancing but together. Being curious about what others are working on is a bonus point because it allows us to not only network within the company but most importantly learning from each other. Let’s make what I say a bit practical. A team has everything we need from the technical skills to the non-technical ones. If you are a frontend developer and maybe considering moving to backend and eventually becoming a fullstack, attending meetings from the backend engineers will help you get an idea of what they are doing there. Even if you do not code, you know what is going on and can understand the communication between the two ends and therefore facilitate your transition later on. The point is, curiosity does not hurt anyone, rather, it makes everybody knowledgeable about the topic.

These are the few points I wanted to make. What about you, can you share? Leave a comment below and let's learn from each other.

Things that will make you hate being a Software Engineer... Sometimes!

Audrey Mengue — Wed, 04 Jan 2023 22:13:48 +0000

Photo by Sasha Freemind on Unsplash

There are a lot of them. Let me just highlight a few…

You can be slow.

Yes, you can be slow and by slow I mean a lot of jiras behind your teammates and this isn’t a funny situation to be in. But it’s going to happen at least once in your project. It might not be because you are sick or had an emergency but simply because you do not know everything. For instance, in that new task/project, you might need to learn a new language or framework and it is going to be challenging for the first time no matter who you are. So whenever the imposter syndrome kicks in, just remember that you can be slow sometimes and it’s perfectly ok. You will get faster with experience.

People are busy.

People will often say that in our software engineering field you cannot do the work alone and it is true but, the reality is that you won’t always find the help you need when you need it. People are just busy working on their tasks or fixing their own bugs. Trust me, the reality in this field is far away from your regular “ A day in the life of a Software Engineer ” video on YouTube. It can take long before someone decides to look into what you are doing and offer to help. The solution to that is to develop resilience and knowing how to work as a freelancer within a team - at least that’s how I can label it - the less you ask for help or need help, the better off you are. Don’t get me wrong though. Ask questions for clarifications but don’t ask people to do your job for you.

Unconsciously seek validation.

When you are just getting started working on a new project, you will be tempted to show to your team what you are capable of and it’s good. But what if it fails, what if it takes longer? What if you actually need a lot of help to come through? And so many other things that can fail. My advice is to step into the job and impress yourself by giving your best. Look at the task, analyze it and ask for clarifications as many times as you need to get the job done. Think of it this way. After being assigned a task, set a goal for yourself like how long will it take you to raise your first Pull Request and after the PR has been reviewed, take note and improve upon it. As time goes on, try to reduce the time and raise more PR and above all, do not forget to document it.

I hope this post will not give you a reason to quit but rather an exposure to what can be your reality. If you are lucky, you may not even feel that way at all then know that you have hit the jackpot which is a company with an amazing culture. My advice is that you stick around for as long as you can.

Forem: Audrey Mengue

Le boiler plate HTML

À quoi resemble le HTML boilerplate (passe-partout)?

La balise head

La balise body

The HTML tags I use the most in my projects.

What is HTML?

What does it provide?

The tags I use the most.

All you need to get started with web development.

A web browser

A text editor

Programming skills

3 small projects to help you build big applications.

To-Do list App

Weather App

Chat App

Vos commandes Git quotidiennes

git clone

git branch

git pull

git checkout

git status

git add

git commit

git push

Your daily Git commands

git clone

git branch

git pull

git checkout

git status

git add

git commit

git push

The key phases of software development (simply put).

I. Understanding the problem

II. Developing the solution

III. Deploying the solution

Comment développer une extension Google Chrome.

Qu'est-ce qu'une extension?

Ce que nous allons développer.

Conditions préalables

Créons l'extension

Téléchargeons notre fichier dans Chrome

Building a simple Chrome extension with JS

What is it and why do we need it?

What we are building and prerequisites.

The manifest file

Let's build the extension

Additional resources:

The importance of having a side gig as a Software Engineer.

Side gigs are not only about money.

Side gigs for growth.

Side gigs help you have leverage.

Mistakes to avoid when working in a fast-paced environment.

Not having an updated version of the codebase.

Not owning the project you are working on.

Not curious about what others are working on.

Things that will make you hate being a Software Engineer... Sometimes!

You can be slow.

People are busy.

Unconsciously seek validation.

La balise `head`

La balise `body`