Forem: BeCode

You should never use sudo (while coding)!

Leny — Tue, 14 Jan 2020 13:49:02 +0000

Yeah, I know, bold move.

As a coder, I read a lot of great articles on DEV, Medium, any-other-place on the internet. Those articles are filled with commands to type to "solve problem" (cargo cult, yeay!).

As a bootcamp coach, I see a lot of my learners typing those commands "because you know, it can't be worse" (cargo cult, yeay!).

And most of those commands begin with sudo. Or, worse, I often hear this: "it didn't work without sudo, so... let's try to add it".

It's never a good idea. Like, never, never.

I will focus on two common missuses of sudo when coding that you should avoid (and are easy to fix).

Usecase one: npm (`npm install -g any-global-package`)

Most of those packages don't need the admin rights. But, by default, your system try to write the global npm package into a folder that requires admin right to be written. So... sudo it is. NO!

You're lucky, you have two solutions for that.

The first one is to use npx, which will download and add to cache the latest version of the tool you need and then execute it. No need for admin rights. BONUS MOVE, npx will firstly look inside the current project and use the local version of the tool if it's installed. Damn, I love npx (thanks, Kat Marchán).

The second one, but you should use npx, is to indicate to npm to store the global package in your home folder. Just follow the steps in this article, and you will never need to type sudo before an npm install -g command.

Usecase two: docker (`docker run --way --too --many --options wonderful-image`)

I know, docker is all about isolating things. And it's great. And since it's so great, why should we give it admin rights? You don't need to.

When you install docker, the best way to try if your install is right, is to use this command:

docker run hello-world

And then it didn't work, and you type sudo docker run hello-world, and you're happy. And somewhere, someone kills a baby koala. And you should be ashamed.

Because you know what? It's in the freakin' documentation! You know, the stuff we didn't read?! (Yeah, me too).

In the install procedure of docker, they ask you to type this command:

sudo usermod -a -G docker $USER

This adds your user in the docker group, allowing you to use the docker command without admin rights. Which is, yeah... right what we wanted.

It's two simple examples. And I know, I shouldn't be ~~so melodramatic~~ such a diva. But, hey, I do what I want, and you shouldn't use sudo on daily basis.

Except if you are really sure of what you're doing.

It's probably the only thing you need to remember from this article:

If you don't know why you need sudo to run a command... don't do it. Or do it, break stuffs, learn things. YOLO!

Gamifying a coding bootcamp: the BeCode LUX

Alexandre Plennevaux — Mon, 16 Dec 2019 20:16:25 +0000

Learning to code is fun (most of the time). Learning to code with the added goal of landing a first job as a Junior Developer after just 7 months of training can be daunting. Gamification is a great way to build self-confidence through this intensive learning period.

At BeCode (the largest network of inclusive coding bootcamps in Belgium), we may have found a way to both gamify our trainings and improve the job marketability of our learners at the same time.

It did not happen overnight. All the pieces fell into place recently, while working on our latest advanced training: DevSecOps. This article explains how we gradually came to design the BeCode Learning User Experience (or LUX, as in Light in Latin).

The bits and pieces of our gamification system

Here is more or less chronologically how the pieces started stacking up, through good old trial and error and iterations over almost 3 years.

0. The ground floor

When we launched BeCode in 2017 we did not want to create just another school. We wanted learning to be fun, collective, positive, healing. We wanted to surround our learners with the comfort, structure, autonomy and kindness needed to dare take risks and embrace failure. After all, learning is about searching and experimenting "until it works". Inspired by Simplon (a huge network of inclusive coding bootcamps in France), we replaced the teachers by coaches and chose active learning techniques, where the learner is in charge and controls its learning experience. We unleashed the beast in 2017 and since then, boy have we experimented.

1. Project-based learning

We organize project-based learning using two types of challenges:

Learning challenges are great to explore, try, experiment. They usually involve a lot of googling, discussing and sharing, trying and failing... When the deadline is reached, what sits on the learner's hard drive is most probably buggy, dirty, dysfunctioning, or completely broken. But they have learned.
Consolidation challenges come after a few learning challenges to re-invest what has been learned/ explored previously. This type of challenges focuses on the quality of result. It can be used to assess whether the target skills involved in the challenge have reached a professional level.

You can find more about our project-based approach on this Slide Deck BeCode LUX: the Learning User Experience.

2. Informal learning is hard to certify

BeCode basically provides the conditions of learning. Trainers do not teach but stimulate learning via group dynamics, individual coaching, instilling into the group a "failing forward" approach to mistakes and of course, real-life challenges. According to European education administration, the type of learning we offer sits somewhere between experiential and non-formal learning, which by definition happens while working on real-life projects. There are no clear, unified certification system for that. And that’s okay… until you need to reassure companies that you are worth being hired, with no diploma to show for it. This has been an ongoing question for us to solve: how to certify skills in a non-formal learning environment ?

3. Open Badges FTW!

In the meanwhile, and pretty much since the first day of the first training, we have been playing around with the Open Badges technology. It's important for the learner's self-confidence to receive gratifications for their achievements, big or small. Positive reinforcement is key to learning and badges felt like a good way to do that.

We started creating and granting badges for every technology we use during the training.

4. How to assess Tech Skills ?

The point of these challenges is to grow the skills enabling the learner to enter the job market, bringing value to companies.

Of course, various degrees of craftsmanship are possible. Again, we need something as simple as possible and easy to understand to maximise adoption by everyone - learners and companies. Through various iterations, we came up with this 4-level grid:

Level 0: Skill is non-existent
Level 1: Skill has been explored - the candidate has interest and motivation to grow the skill.
Level 2: The candidate has been able to use that skill on a professional level.
Level 3: The candidate has acquired enough knowledge and experience and has the teaching skills required to be able to train people on that technical skill
Level 4: The candidate has contributed to the technology source code, aka "Godmode" - it is of course very rare that someone reach that level. We consider this level to be the ceiling.

Practically it means that learners having finished a learning challenge and shown genuine interest and motivation could claim the Technology’s level 1 badge. When finishing a consolidation challenge, they could get the technology’s level 2 badge. If they give a hands-on workshop on the technology, they could claim to have reached level 3. If Linus Torvald ever comes to BeCode (you never know…) we would grant him Linux’s Level 4 badge. (I'm sure he'd be thrilled!)

From a business point of view, a level 1 badge certifies that the candidate has "some exploratory" knowledge and is interested to master that skill but is not autonomous yet nor able to use the technology in a real-life professional scenario - some senior mentoring would be required.

5. LinkedIn <3 open badges !

An important benefit of Open Badges is the fact that they can be embedded on the Learner's LinkedIn profile (here is how). The potential employer, reviewing the profile, can click on the badges and check what it means and more importantly, how it was obtained. In that regard, open badges are much more transparent than diplomas and classic certificates.

They are also very relevant: since every learner is different, the set of badges acquired can more closely represent the strengths of each profile. This is a great way to improve the marketability of our learners and move beyond the "informal" aspect of their training, indeed giving it a recognizable form.

6. Soft skills badges

In the summer of 2019, we undertook an important work synthesizing what soft skills we can observe (and thus certify) during the seven months of the bootcamps. Through a couple of co-creation workshops involving smart people from various disciplines (management, previous learners, trainers, marketing people and an external HR expert) we came up with a vocabulary of 10 Soft Skills badges that enable everyone at BeCode speak the same language about the behaviours expected in a professional environment.

When we introduced the soft skill badges to the learners and fellow trainers from Simplon (our French partner), it brought a lot of enthusiasm as it gamifies the acquisition of soft skills, whereas soft skill training is usually experienced as "condescending" and is generally a hard to tame beast, since it is so subjective. Unwillingly, we had created the embryo of a gamification system.

7. Career paths

Ultimately, badges are a mean to an end: finding a job, starting a career path.

Well, in essence, a career path is a set of tech skills and soft skills to acquire.

If we can describe a career path through the necessary combination of level 1-4 badges, we have a clear way to describe to the learner what path they need to take to achieve their goals. That's exactly what we did, involving company experts in the process of content creation.

To certify that a learner has acquired all the required badges, we need another badge, representing the career: we called them "meta badges". Here is an example of the Secure Developer metabadge, and the badges necessary to earn it.

Conclusion: the LUX

The gamification of the Learning User Experience at BeCode essentially means acquiring skills through challenges, deciding which career path to pursue and when learning goals are achieved, certifying them using open badges. The goal of the game is by the end of the training to obtain the meta badge corresponding to the learner's desired career path. That badge certifies that the learner has the soft and technical skills required to enter the job market in that career, and with enough self-confidence to grow into the position autonomously.

What are the next steps ? Our next trainings will implement it from the starting day. It will be a real life pilot from which I expect to discover a lot of opportunities for improvement. We also need to update our Junior Web Developer training to match this structured gamification approach.

Also, I am eager to see how “open minded” will companies be about these badges as a way to assess a candidate’s skills. They make a lot of sense to us, trainers, but time will tell if it is actually effective in “landing that first job in IT” – the hardest one.

Introducing Oto, the man in the middle.

Leny — Sat, 12 Oct 2019 21:37:12 +0000

☝️ NOTE: this article is an revised version of one of my previous article on Medium.

As a developer, I love to use APIs.

Moreover, I love to use others’ APIs, and integrate them in my apps.

Like getting stuffs from GitHub, LinkedIN, allowing my users to see their data in my tools.

But I don’t want to ask my users their credentials for these services (and they wouldn’t probably give them!).

So, I have to use the OAuth2 protocol.

OAuth2 is a tool used by services to allow third-party apps’ developers (like me! I’m a third-party developer! Woot!) to access the services’ data of users, with their approval.

I will not describe OAuth2 in depth, but here’s the big picture: when you create an app, you need to register it on the service you want to use the API.

They will give you two important things: a public access id, which is not secret and can be stored in your code ; and a private access key, which is, huh, secret, and can’t be shared.

When one of your user needs to use the API in your app, they will be redirected on a login page outside your site, on the original service (the login page of GitHub, for instance). The user log himself, and the service redirect him on your app, with a unique code.

Then, your app will contact the service, with the unique code, your public access id and your private access key. The service know that everything’s okay, and will respond you with a token, that you will use for any request to the API.

And that’s all. It sounds complicated, but it’s quite easy.

But there’s a small problem: OAuth2 is not really designed to be used on client-side only apps, like SPA.

As I said, the private access key needs to stay… huh, private.

So… we need a server. But we don’t really want one, since we would like to have static apps.

That’s a tough one.

But what if I told you we can have a server… without a server?

We can use a serverless platform, like AWS Lambda: it’s basically a simple piece of code (a function), bound to an URL, that will be executed when the URL is touched. Simple as f*%.

And then, we can have a small piece of code that will know our private access key for OAuth2, and will make the last step of the challenge.
Let me introduce you oto, the man in the middle, the little piece of code to run that.

For now, it supports GitHub & LinkedIn, but I will add more services in the future.
You can run it locally, or simple use the serverless framework to deploy it on your AWS account.

And, last but not least, its able to handle multiple services and keys at once, simplifying your workflow!

Collecting squares together!

Leny — Thu, 12 Sep 2019 06:11:17 +0000

☝️ NOTE: this article is an updated version of one of my previous article on Medium, augmented with some updates. Also my first post on dev.to!

I love gamification. Really. Collecting achievement just for the sake of it, as any rpg-player.
It’s why I really love the green squares of the contribution graph on GitHub profiles.

But the green squares are personal by essence: it’s your commits, your activity on GitHub. There’s no data for teams or organisation.

At BeCode, we work as a team, we live as a team. Everything we do, we do as a team!

It’s why I wanted to create a contribution graph with informations of all the BeCodians.

Using green squares felt a bit wrong, so I use the blue tones of BeCode’s identity, and created Kareble.

Fetching the data

I already known about the GraphQL API of GitHub

Did I tell you that I really love GraphQL? I love GraphQL. So much. For real. It’s the future, deal with it.

But unfortunately, the information are deeply hidden in all the data that GitHub serves. And fetching all the data I needed is very slow, so I can’t do it in real time.

The idea is to create a script to fetch the data, and running it once a week.

After some tests, I ended with this graphql query:

It gives me all the contributions from the last year, by weeks, for 25 users of our organization. Then, I created a small script to fetch the data of all our users, 10 at a time (I don't care about the time it takes, it's all automated on a CI, will talk about it later).

The script also assemble and clean the data, then set the color of each day, regarding of the quantity of contributions.

It finally writes all the data in a JSON that will be used by our website.

At the time of the redaction (september 2019), the script fetches the data in 74 batches of 10 users, performing all its tasks in about 2min 30s.

Displaying the data

For this little project, I wanted to change my habits.

I could have done it with React or VueJS, but I wanted to use this project as a good pretext to test and discover something I never used before.

My choice went on Svelte. The version 3 was quite new when I started working on kareble and some podcasters I listen made very enthusiastic episodes about it.

Svelte is a very great tool, similar to React or VueJS (working with components), but also quite different - the creator of Svelte describe it as a disappearing framework: when compiled, the code doesn’t need to include a runtime like React or Vue.

Svelte is also constructed around HTML: you defined components by their markup (svelte components are like small HTML fragments), and a small chunk of scripts to operate with them.

Svelte is really fast and easy to use, and for small projects, it’s a very good surprise.

The coding part was really straightforward, you can dig around the code on the repository.

If you’ve already played with a modern front-end framework like React, you’ll see that Svelte is really easy to understand.

Build & deploy

Compiling Svelte is really easy, thanks to rollup.

To host and deploy, since we can’t fetch the data in real time, we can host the website on any static platform, like netlify or github-pages. For Kareble, I use github-pages.

At the moment of releasing Kareble, the only missing part was automation - I needed to run three npm scripts to fetch, build and deploy the website each week. A strange sunday morning routine, but, hey... 😋

I really wanted to use GitHub Actions, which I was testing in beta on my personal GitHub account, but didn't had the beta access on the BeCode organisation... until this september.

With the newly introduced syntax, I came out with this workflow:

Thanks to the cron syntax, this runs every sunday at 8am (while I hope my son let me sleep a little longer), prepare a node environment, install dependencies (the npm ci is a better/faster npm install alternative in this case), then publish the result of the build on the gh-pages branch.

It was a really nice and fun little project to code.

You can see the result on kareble.becode.xyz, and dig in the code on the GitHub repository.

Automate deployment using GitHub hooks

Alexandre Plennevaux — Tue, 13 Aug 2019 15:08:29 +0000

The first time I witnessed the cleverness of the deployment using git strategy was with GitHub Pages: simply git push to the master branch of your repository and your static web page is updated. As simple as that.

I wanted to be able to deploy with the same elegance on my own servers and for more complex applications. I thought I understood how it worked but not how to automate it. So I would manually ssh into the server, cd my way into the project folder, then git pull. Every. time. Not really convenient.

When I discovered Trellis I learned to use ansible to be able to deploy by using a oneliner: ./deploy.sh production domain.com)...

But then Ansible is a power tool, which does a lot of other things than just deploy. And I learned the hard way that I should not update my local Ansible version otherwise... All hell break loose.
Also, I would still have to git push to the remote prior to launching the deployment.

One line to rule them all

Working at BeCode is cool because you get to meet dozen of fellow developers, craving to learn and explore. One of our learners pointed me in the direction of using a GitHub Post-Receive hook, thanks to which deployment is a simple : git push production master. The hook launches a local script that git checkout the master branch on the production server, then runs any other custom operations you want (such as composer update for example).

Let's see how to set it up.

1. Setup a bare Git repository on production server

First, create a "bare" repository – one that does not contain the working copy files. It basically is the content of the .git repository folder in a normal working copy. Name it whatever you like (you could also omit the .git part from project.git but I find it best to keep it):

cd /path/to/project/folder/
mkdir project-name.git
cd project-name.git
git init --bare

2. Configure the GitHub hook

Create a post-receive hook at /path/to/project/folder/project-name.git/hooks/post-receive

touch hooks/post-receive

Fill it with your version of the following code (use your specific folder paths) :

#!/bin/sh
NOW=$(date +'%d-%m-%Y_%T')
# check out master branch
GIT_WORK_TREE=/path/to/destination/folder/htdocs git checkout -f master

# custom steps for deployment
# For example, let's execute composer to refresh our dependencies : 
cd /path/to/destination/folder/htdocs
composer update
# backup current version, in case we need to do a rollback
cp -R /path/to/destination/folder/htdocs/. /backups/project-name/$NOW/

Make sure it is executable:

chmod +x post-receive

3. Add the remote-repository to your local system

Let's now add a reference to this bare repository to our local system, as a remote location. Let's call this remote "production". (It could also be called "staging" or "live" or "test"... should you want to deploy to a different system or to multiple systems.)

cd ~/path/to/working-copy/
$ git remote add production ssh://username@myserver.com:22/path/to/project/folder/project-name.git

Check that your new remote is now available, and all the existing ones:

git remote -v

And... that's it!

You can now deploy using this beautiful one liner :

git push production master

Going beyond ? TDD !!

With this, I have the raw basis of a deployment pipeline. The next step would be to add code testing to make sure code updates do not introduce bugs or break anything (regression testing). I assume I should look at how to use Ansible for that.

Since I don't know how to do that yet, I'll leave you to ~~google~~ dev.to/search your way around that one !

The easy way to turn a website into a Progressive Web App

Alexandre Plennevaux — Tue, 21 Nov 2017 09:26:41 +0000

What is a Progressive Web App?

Basically, a PWA is a website that can be saved on the user's device (desktop, tablet or smartphone) and thus feels and behaves much like a Native application: loading screen, removing the browser's interface clutter to enhance user focus, and, should the connection drop, it still displays (cached) content, enabling the user to continue working offline.

Why is it important?

It tends to boost user engagement: if Android's Chrome browser (not sure about other mobile browsers) detects that the website is a PWA, it prompts the user to save it on its device's homescreen using the icon of your choice.

Compared to a mobile application, it simplifies the end-user setup process, breaking free from app stores.

PWA are good for your client's business. Alibaba, the Chinese Amazon, notices a 48% increase in user engagement thanks to the browser's prompt to "install" the website (source).

This makes the effort totally worth fighting for!

This bounty is possible thanks to a technology called Service Workers that allows you to save static assets in the user system (html, css, javascript, json...), alongside a manifest.json that specifies how the website should behave as an installed application. Service workers can do much much more, like polling user actions while offline, and syncing them in the background when back online.

Examples

Famous PWAs are Slack, Spotify, Starbucks, the NY Times, and many more...

Here are a couple PWAs made by myself using the same technique described here.

plancomptablebelge.be (a single-page website)
mathr.app (a game to practice calculous, made using Sveltekit)

Setup

Turning a website into a PWA may sound complicated (Service workers whaaaat ?), but it's not that difficult. Follow my lead and you'll have one by the end of this article !

1. requirement: https instead of http

PWA only work on a website running on a secure domain (behind https:// instead of http://).
These are usually very hard to set up manually, but thanksfully, if you have your own server, you can use letsencrypt to make that super easy and automatic. And... FREE.

2. Tools

2.1 lighthouse test

the lighthouse test is an automated test created and maintained by Google that test websites against three criteria : Progressive, Performance, Accessibility. It gives a score in percent for each, and advises on how to solve each issue. It's a great learning tool.
realfavicongenerator.net
the UpUp.js library

2.2 realfavicongenerator.net

realfavicongenerator.net takes care of the visual layer of your PWA. It generates the manifest.json file mentioned above, alongside all the versions of your icons necessary when saving the website onto any mobile device, and an html snippet to add to your page's <head> tag.

2.3 service workers, via upup.js

Service Workers is a javascript technology. I found it hard to grasp for my tired and impatient brain, but luckily, a smart girl from Germany pointed me to a javascript library by Tal Atler, that makes it über easy to make your website behave nicely when the connexion drops. danke schön, Ola Gasidlo !

Just do the quick UpUp tutorial and you're good to go.

2.4 The Manifest

Edit the manifest.json file that RFG generated for you. It should contain at minimum these entries: "scope", "start_url", "short_name", "display". Here is a working sample:

{
    "name": "My PWA Sample App",
    "short_name" : "PWA",
    "start_url": "index.html?utm_source=homescreen",
    "scope" : "./",
    "icons": [
        {
            "src": "./android-chrome-192x192.png",
            "sizes": "192x192",
            "type": "image/png"
        },
        {
            "src": "./android-chrome-512x512.png",
            "sizes": "512x512",
            "type": "image/png"
        }
    ],
    "theme_color": "#ffee00",
    "background_color": "#ffee00",
    "display": "standalone"
}

More information is available at developers.google.com.

3. Methodology

Use Realfavicongenerator and generate the html and image code. Add them to your website code.
Publish on your https domain.
Do the lighthouse test.
Analyse results.
Fix each issue one by one.
Go back to 3, rince and repeat.
Iterate until you get as close to 100 everywhere, and 100 in "Progressive".
Test on your mobile phone and see what happens. With chance, on Android you'll see a popup at the bottom, inviting you to save the website onto your phone homescreen!

Deeper into the rabbit hole...

Here is a sample PWA project I made using a Github Page, live coded for my juniors at BeCode : visit its Github Page with your mobile phone to test it. Visit its repository to inspect the code.

You can find all the information you need on PWA in this book:

That's it! Happy PWA-ing!

Your PWA is ready: how about you learn how to automate its deployment using Git ?