DEV Community: mveillon

Create a starter kit that fits your needs.

mveillon — Fri, 28 May 2021 15:15:56 +0000

I work in a french company called theTribe where our typical projects are 3 to 6 month long, generally web or mobile app.

We usually end up choosing a mix of JS / Python or PHP for our web based project and React Native or Flutter for our mobile projects.

This means a lot of projects, with different needs but also a lot of common tasks we need to solve each time. (think linting, continuous integration, deployment and provision automation, DB setup, Test setup, authentication etc)

the painpoints

A typical bootstrap takes roughly between 3 to 10 days depending on the specificity of the project.

Historically we had different starter kits, for mobile, php and javascript projects. Each of them relying on different patterns, and since they were scattered it was difficult to maintain them and/or promote their use.

Therefore we decided to tackle this painpoint by creating a new generator which would aim :

to centralize our needs.
allow the dev to choose between the different main tech we use at theTribe
allow a better maintenance of the project

the solution

We ended up choosing Yeoman which allow us to provide a CLI experience with prompts where the dev will be asked a few questions to choose the stack he/she wants to use and some variables for the project identity

The current MVP covers the most used technologies which are:

Front-End Architecture : you can choose between Create React App and NextJs as a boilerplate app
Backend-End Architecture : you can choose between Node and Symfony (Node backend comes with Express and TypeORM)
Containerization In dev environment with docker-compose
Provision/Deployment automation with Ansible
Instance Management with Terraform
Continuous Integration with CircleCI

All this comes with the appropriate file structure and allow each dev to kickstart their project easily

We just have open-sourced it on https://github.com/thetribeio/generator-project and we would appreciate any feedback,

In parallel we also have uploaded it on a the Fast Modular Project which is a platform which aims to reference different starter kits from different companies and individuals.

Do not hesitate to pin and like if you appreciated the article ❤️

Continuous integration and deployment workflow with Vercel, Firebase and CircleCI

mveillon — Wed, 03 Mar 2021 06:51:07 +0000

I've recently set up the whole CI/CD workflow for a project at work, this was the first time I was really diving into CI configuration and automated deployment with this stack. With the combination of the tools below, I feel we have achieved the right mix of confidence / automation for our current needs.

Tools and their responsibilities

CI : We use CircleCI for running all our tests / linting / type checking for both front end and backend. It also orchestrates backend deployment for Firebase function
Vercel : We use Vercel to deploy our front end. It is linked to our github repo to automatically deploy the front-end.
Firebase : We use Firebase for the backend (serverless functions as well as database and authentication). Generally we'll use one project for development and one project for prod.

Overview

Front-End

Our client is basically a NextJs React app. It pairs really well with Vercel since they are the ones behind NextJs, the integration / tooling is really fluid.

To get started you'll need to:

Have 2 branches on github (usually I go with develop and master)
Register your prod and dev domains on Vercel
Link your 2 domains to the right github branch

This should be enough to get you started and being able to deploy automatically whenever you merge on your configured branch on vercel.

If you need to customize the build-step, whereas it is the command or the output folder, you can follow their documentation

Environment variable

All your environment variables can be set up directly on Vercel

If you need to provide different values in your codebase based on the branch you're on (and therefore whether you target your staging or prod domain) you can rely on the System Env Variables

export const getEnvVar = (key: string): string => {
    const isProd = process.env.NEXT_PUBLIC_VERCEL_GITHUB_COMMIT_REF === 'master';

    switch (key) {
        case 'NEXT_PUBLIC_FIREBASE_API_KEY':
            return isProd
                ? process.env.NEXT_PUBLIC_PROD_FIREBASE_API_KEY
                : process.env.NEXT_PUBLIC_FIREBASE_API_KEY;
        default:
            throw new Error(`key ${key} is not recognized `);
    }
}

Note on firebase hosting :
To deploy it we were initially using firebase hosting, but it was rather slow as you need to rely on a serverless function from firebase to serve the server side content.

If you want to use Firebase Hosting you would be limited to a function in us-central1. This is a known limitation and for the meantime if you want to serve dynamic content you would have to configure Google Cloud Run instead

Back end - firebase serverless functions

This part is a bit trickier between local and prod setup. There are a few firebase key concepts behind it.

Firebase project : usually you use a firebase project for your prod, and one for your staging. Meaning that you will need to switch between project whenever you want to deploy code on staging or on prod. This will be automated through CI.
Service account : This is one of the way to authenticate yourself as an admin of a firebase project. Your service account can be generated in the firebase console
RuntimeConfig : this is the config you can set up through firebase CLI usually to add env variables associated to your firebase project.
Firebase CLI : The command line tool which allow you to perform several tasks on firebase like :
login into your firebase project.
adding/selecting the project you're currently working on
adding env variable to your project
generate the firebaseToken needed to deploy through the CI

We'll go through each of them in the setup below, don't worry (I'm mostly speaking to myself for the next time I need to configure this 😄)

Setup commmon to both local and staging/prod

Firebase Project Configuration :

You'll therefore first need access to one or two firebase projects. This setup will mostly walkthrough having 2 firebase projects (staging and prod) with each their own authentication and database. Just log on firebase and follow the steps
Install firebase-cli

npm install -g firebase-tools

firebase login

Once you're logged in you'll be able to add different firebase projects to your current configuration by :

firebase use --add

This should result in .firebaserc file in your project where you'll have a list of your projects. This is important as we'll rely on those aliases to target the right project to deploy based on the branch later on. Would you have any issue you can refer to firebase-cli documentation which rather good.

Environment variable :

For your env variables you can add them directly to your firebase project through firebase CLI :

firebase functions:config:set someservice.id="THE CLIENT ID"

You can later on access it through :

const functions = require('firebase-functions');
...
const id = functions.config().someservice.id,

Note :
Those environment variables are stored directly in your project on firebase and as such you don't need them locally. Usually you download them locally to verify a value manually. Might be a good idea to gitignore them, just in case.

Initialize admin SDK :

To configure and add your firebase-admin sdk, you'll need to add a service account.

This will result in a local .json file, that you will place under a specific gitignore folder on your machine.

Firebase then recommends putting the path of the file in an environment variable (previous section) - you can refer to the firebase docs if needed

import * as admin from 'firebase-admin';
...
const config = functions.config();

const app = admin.initializeApp({
            credential: admin.credential.cert(config.credentials.google_application),
            databaseURL: `https://${config.credentials.project_id}.firebaseio.com`
        });

Local Setup

To develop locally, usually I end up using the staging project for database/auth and serverless function. This can be achieved by :

select your firebase project manually through firebase CLI with firebase --use XXX

Note :
Pay attention to which project you're currently using, sometimes you want to run a script against prod and you end up using firebase --use master which will be the selected project untill you reselect staging / your test env

We want to avoid deploying the serverless functions manually at this stage and want to pass this responsibility to the CI

CI Setup

The CI will be responsible for deploying our functions to firebase.

There is obviously some constraints :

you don't want to expose your serviceAccount in your repo
you need to switch the project used to deploy based on the branch

To achieve those goals we have to configure a few things :

take the path to where your service account is supposed to be stored and save it as an env variable on CircleCI.
take your local serviceAccount and encode it to base64 to save it as an env variable on circleCI. This allows CircleCI to store complex structure as a string.
a good practice is to add BASE_64 at the end of your variable name. Usually I end up with 2 var in circleCI, something like : FUNCTION_PROD_SERVICE_ACCOUNT_BASE64 and FUNCTION_STAGING_SERVICE_ACCOUNT_BASE64
take the serviceAccount from circleCI and decode/copy it through the CI to your build folder :

command: echo << parameters.key_env_name >> | base64 -di > ./keys/<< parameters.key_path >>

Now your code should be ready to be deployed, but you still need to make sure you have the token to allow your CI to handle the deployment. This can be done with the firebase token. This is done only once - you don't need to do it each time you switch the project you're using.
From there you should be able to deploy your serverless functions based on your branch like so :

command: ./node_modules/.bin/firebase deploy --token "$FIREBASE_TOKEN" -P << parameters.environment >> --only functions:hubspot,functions:users

This can only be triggered based on the branch you're running the merge against. Like so

- functions_deploy:
    requires:
      - functions-build
    environment: staging
    key_path: $STAGING_SERVICE_ACCOUNT_PATH
    key_env_name: $FUNCTION_STAGING_SERVICE_ACCOUNT_BASE64
    filters:
      branches:
        only: develop

- functions_deploy:
    requires:
      - functions-build
    environment: prod
    key_path: $PROD_SERVICE_ACCOUNT_PATH
    key_env_name: $FUNCTION_PROD_SERVICE_ACCOUNT_BASE64
    filters:
      branches:
        only: master

functions_deploy:
  executor: node
  parameters:
    environment:
      type: string
    key_path:
      type: string
    key_env_name:
      type: string
  working_directory: ~/project/app/functions
  steps:
  - checkout:
      path: ~/project
  - attach_workspace:
      at: ~/project
  - run:
      name: add service account
      command: echo << parameters.key_env_name >> | base64 -di > ./keys/<< parameters.key_path >>
  - run:
      name: Firebase Deploy
      command: ./node_modules/.bin/firebase deploy --token "$FIREBASE_TOKEN" -P << parameters.environment >> --only functions:hubspot,functions:users

That should be it and you should now have a fully automated deployment with Vercel and Firebase for both the front end and backend on your staging and prod environment.

I hope this has been helpful to you and that you learned a few things along the way, I surely did !

How to not learn Javascript

mveillon — Mon, 25 Jan 2021 05:28:58 +0000

When I was preparing for my bootcamp a year and half ago I was trying to figure out the best way to learn. (still figuring...). What I learnt finally over the last year, is not what is the best way to learn Javascript, but rather what doesn't work for me.

So instead of recommending you what to do, I'm going to focus on what failed for me.

Resources overload
Not knowing how to learn
Too many topics at the same time (following my first job as a dev I had to learn Redux, c#, SQL, RxJs. Mixing all those together was a bad idea)
Not Planning and Chunking
Too much screen time
Comparing to other too much
Not being indulgent with yourself

Resources overload

What should I learn and what are the best resources to learn out there ? Those were the first questions I asked. And Google served me well there,
with a lot of good resources and opinionated learning roadmap.

I was literally trying to read too much. Anytime I was seeing a good article, or a link recommended by someone it was ending on a todo list somewhere.

If you've been there, you might recognise you in the situation below :

- List of paid course on Udemy that you haven't even started (I'm talking about those 2yrs old course which are now outdated)

- Trello backlog full of articles links that never shortens.

- Medium bookmark section that is not even scrollable anymore.

Bookmarking good content in itself is not a bad habit, but I felt like I would never catch up on my plan, which is kind of depressing.
I'm still kind of there, but I decided to not bookmark medium articles neither buying udemy course anymore, unless I'm doing them right away.

Not knowing how to learn

Before switching career, I did some Coursera/PMP certifications, but there were short bursts, and the main objective was to get the certification - I was not paying attention on how I achieved this goal.
When I entered the more technical field of web dev, it felt like a new world to me, where I would need to learn differently.

At first my learning practice consisted mainly in reading article on a topic (according my never ending trello backlog), and then try to apply the learning in a side project.
This was at first intuitive to me, but while I was learning Redux, it was dissatisfying.

First because, there were always some more resources or links to go through. I kinda felt depressed to find Mark Erikson awesome list or resources. as I felt like I should go through it .
Secondly because, I was trying to learn everything upfront at the same time. (redux, redux thunk, redux-connect, rxJs)
Finally, because after a while I thought I was forgetting my previous learning.

After I took a step back - I decided to make some corrections in my approach :

Focus my learning on specific platforms/authors.
Chunking and Planning
Learning by repetition

I have a few authors who are my go-to mentors because I like the way they teach.
When I can't find what I'm looking through them, then I go in the wild - not before.

Chunking and planning is discussed just below.

As regards for repetition, I remember when I was at school preparing for some exams, I created those flashCard - they were a pain to make,
but by the process of making them and having them around allowed me to get the best marks I ever got and still remember them. Fast-forward 15 years later, I thought I could use some of this wisdom,
by creating Cards on different learning topics. This works pretty well at least for high-lvl concepts, for example when you approach a new topic.

Not Planning and Chunking

My main objective for 2018 was to learn Redux, GraphQL and Advanced React Internals while working on a side project. I haven't touched GraphQL, very few of React internals, and my side project has seen a few commits but way less than I would have expected.

The culprit ? The preceding points for sure, but also the way I was planning my learning journey.
Learning Redux is a big bold statement, but it didn't serve me well as I didn't feel I was making progress towards the overall goal.

I should have before chunked Redux in some smaller part would have been preferable and more digest to learn.

For 2019, I have some similar main goals (JS fundamentals - again..., GraphQL, Node) but in a way more specific manner. I try to chunk those big topic in weekly learning chunks, that I can apply in my side project.

Too much screen Time

I try to pay attention to my screen time - coming from project management world where meetings were the norm (for bad or for good),
switching to dev was a huge increase into my computer hours. I feel it painful sometimes to go back at home to practice/learn to code in front of my computer.

That's where I like flashcards and books. Not all resources are equals, and some books are more helpful to sleep than to learn.
Adjust accordingly to your energy level.

Comparing to other too much

We're getting personal here, but during the bootcamp and through my first job year, I realized that I compared myself to my co-workers. A lot.
Doing so prevented me to learn from my environment as much as I could as I felt diminished when I wasn't performing enough.

It takes a lot of energy to manage this kind of emotion. This is a net loss that you cannot put in good use to learn from your coworkers or peers.

I don't have the answer yet to this, but paying attention to this emotion and pattern allow me to avoid getting caught in too much.
Knowing that my interest lies in welcoming learning opportunities rather than feeling diminished by them helps.

Not being indulgent/empathic with yourself

This is kind of linked to the previous point. I have moment in my journey where I mostly focus on what I'm lacking or not doing well enough.

When this happens I try to take a step back.

Learning to Code is hard.

Switching Career is hard.

It's a long journey, and I should already be proud of where I am. So should you.

First Job as a junior dev - find a place where you can build confidence

mveillon — Mon, 18 Jan 2021 06:25:33 +0000

I switched career at 33 through a bootcamp. A lot of us do it at various ages, some younger, some later on. I globally really enjoyed the ride and learning experience.

During the bootcamp we were exposed to the concept of growth vs fixed mindset, at this stage the concept seemed to click - it was feeling comfortable, I was confident in my ability to learn and proud of my capacity to pivot.

And then it happened after the first few months at my first dev job - I realised the hardest thing for me was to embrace being a beginner once again.

I don't consider myself having a big ego (but who does ? 🤔 ), nevertheless it became a hindrance after a few months when I was often comparing myself to other devs, most of them senior, all of them having a more valuable contribution to the company than me.

I believe this feeling came from 2 main dimensions :

my own mental capacity to cope with the career switch / impostor syndrome
the job environment

Impostor Syndrome / Self Doubts

There is a lot of good advices on how to cope with impostor syndrome over the internet.
Impostor syndrome is mostly self doubts and as such can be difficult to handle.
I don't have much more advices to share on the way to handle it from within yourself, but rather I want to focus on the second point where I might have a bit more concrete advices : picking a healthy job environment.

Job Environment

During my first job hunt as a dev I tried to get the job with the best learning environment.

Naively I thought that a company with a lot of senior dev + "standard best practices" would be the best to learn from.

I was wrong.

I ended up in a company which had a lot of senior devs, some of them being really impressive in their technical knowledge and problem solving skills. I still learned a lot from them, but while months were going on I began to realize that the place was not feeling safe.

We're not talking about physical integrity but rather about an environment where it feels safe to learn / grow / fail. There is an interesting study on google teams or the well known book : 5 dysfunctions of a team which explains how this can be impacting.

It's kind of difficult when you begin your dev career, to differentiate the impostor syndrome and its consequences (lack of confidence etc) versus a more rooted issue from the environment itself.

The question always comes up as a personal issue till you're able to articulate it with other colleagues and you realise that the feelings are shared.

Concretely here are some symptoms we were experiencing :

Lack of encouragement
Code review feedback lacked empathy
We didn't feel our work was valuable to the company
Subtle but constant pressure about our capacity to match senior output

Those are mostly perception related things and it could vary from one individual to another - but when they stack, they definitely create a non productive environment for those who are not confident enough by themselves.

It often leads you to doubt about your skills, your learning abilities etc. When you switch career and don't have much experience to compare with, you can even doubt about your initial move of becoming a developer.
This level of self-doubts affects obviously your personal life.

This should be a red flag about the company and the environment, if you see it not only as a punctual feeling/experience you have, but rather a trend/direction.

With some perspective now I feel there were several root causes :

company capacity to make junior dev grow
cultural misfit

My first company, and I cannot blame them for that, was not used to recruit junior dev. They had a strong stable and trusted team for a long-lived product for which they were only recruiting seniors. It's difficult to be good at something you don't practice.

Cultural fit is to me how you share values and you can relate to your colleagues. When difficult times arise (as it will), you will rely on this fundamental aspect to be able to communicate/articulate the issue. As those topics are already difficult to share, when you feel out of place, it will be all the more difficult to share and address them.

In all honesty when we talk with my ex colleagues, we're still grateful for the experience as we learned a lot by just being in contact of great knowledgeable developers.

But having now experienced others working environments - I think as a first job, the best learning environment is a place where it can feel safe to grow. I don't say it has to be all comfortable and indulging (quite the opposite in fact) but rather an environment where you feel you can tackle challenge and you can go out of your comfort zone while being supported.

That's why I think it's an important skill to be able to assess those aspects early on in the recruiting process.

Get a first job where you can build confidence in your skill

I understand that the situation is not identical for all students / junior dev and that we cannot always "choose" our first job - that being said, knowing how to assess your future job environment is a skill in itself, and that will be useful for all your other jobs.

Company capacity to make junior dev grow :

In my opinion, you can have a good idea of the company capacity to support the growth of junior dev by looking at :

onboarding process
junior dev turnover / frequency of hiring junior
collaboration process

Most of those aspects can be assessed fairly well during the recruiting process, by asking questions such as :

What is the process to onboard new team members ?
What are the expectations for a junior dev at 3 months, 6 months, a year ?
Do you often onboard junior dev
Do you have a Career Framework ?
What are the values important to your team to ensure a good collaboration ?
What space/trust/ownership has a developer to explore some feature/aspect/optimization ?

Special mention about the Career Framework - This is usually something which comes up when you have more than XX devs - therefore the lack of it might not be a red flag in itself.

Cultural fit :

This can be trickier I feel to assess as there is a lot of "marketing" these days around it with culture books and shiny endeavour which do not always guarantee a concrete translation in a day to day work.

I think this is best assessed by meeting team members and asking questions about their own journey / struggles and how you can relate to those.

Meeting people that went through the same path/steps as you do will prove useful and will facilitate meaningful support when needed.

Conclusion :

As previously mentioned, and I want to reiterate, I'm still grateful for all my previous experiences and all the learnings that came out of it (technical or non technical related).

That being said, we as fresh bootcamp student (or fresh graduates in general) tend to rush to accept the first offer. Despite the urge and pressure of doing that, we should be able to gauge a company environment in term of learning expectations not only through the tech stack but also through team dynamics, process and values.

Genuinely foster a learning environment for all is a difficult task, and we also have a responsibility as junior dev and future seniors to be a part of improving/creating it.

Some resources to go beyond this post and inspire a broader perspective on the question

🎥 a talk of Sarah May about power dynamic in agile teams
📖 swyx excellent book on the coding career. There are specific chapters around the career guides section.