DEV Community: Leny

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!

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!

Do you even alias, bro?

Leny — Sat, 12 Oct 2019 15:26:49 +0000

I'm proud of the pun in the title. Sorry not sorry ;)

It's a fact, we live in the command-line.

There was a time (and I don't regret that) where using the command line for web development was a "strange thing"; the console was for the sysadmins.

But the times are a changin', and between git, npm, webpack and all that marvellous tools, we live in the command line.

There's plenty tools to help you take the better of your terminal, such as a better shell than bash, like zsh or fish, multiplexers, like tmux, and even complete frameworks to enhance your experience.

But the most useful feature of a terminal, hands down, are the aliases.

An alias is as simple as it sounds: it's a command you type as a shortcut for a longer command. Like typing l for ls -FalH, or .. for cd ...

Creating aliases is easy: for bash, zsh or fish.

I can't recommend you enough to create your own aliases, since they tend to be personal, but when you take a look at dotfiles, you'll see many common aliases.

Here's a list of some of my favorite aliases. You can find a complete list in my dotfiles repository.

Navigation & listing

.. = cd ..
... = cd - (jumping back to the previous directory you visited)
c = clear
cat = bat (a better cat)
ll = ls -FalH
l = exa (a modern replacement for ls)

Git aliases

git = hub (not really an alias, but if you work with GitHub a lot, it's wonderful)
gs = git status -sb
gap = git add -p (git add with patch mode)
grhh = git reset HEAD --hard
gcdf = git clean -fd (clean untracked files)
cdg = cd $(git rev-parse --show-toplevel) (cd to the root of the repository)

npm aliases

ni = npm install
nid = npm install --only=dev (only devDepencies)
nip = npm install --only=prod (only dependencies)
nis = npm install --save
nisd = npm install --save-dev
nci = npm ci

misc

ping = prettyping

I hope some of these can be as useful to you that they are for me.

Don't hesitate to submit your favorite aliases here or in an article on your own! It's always interesting to see what are the best shortcuts of others!

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.