DEV Community: crisarji

5 tips for interviewing peer-ple in technology

crisarji — Thu, 21 Apr 2022 01:25:13 +0000

5 tips for interviewing peer-ple in technology

Hello developer pal!, glad to see you here.

Interviewing people is always a challenge, you never know who is joining in person or in a call with you, it is a lottery!

Perhaps you are interviewing the next Steve J, the next Mark Z, or the next... You!

Some time(or long time) ago, someone gave you the opportunity to start working as an intern, as a fix term, as a freelancer, whatever the job was, you had the chance to start a career because someone wanted to!; maybe this person saw something in you that outstand from others?, perhaps you used the right words or coded the right challenge?, anyway you had this chance and I'm pretty sure you were happy when you received the news that you were selected!

After all this epilogue, do you remember how it was?, what were the steps the person from technology followed for that interview?, you were prepared for sure, but how about the interviewer?, well in case you don't recall, and if you are in this situation where you will evaluate candidates, maybe this tips could fit you!

Show Me The Topics

The topics to be focused on are:

Introduction
Set the Rules
Ice Breakers
Interview
Closing Time

Disclaimer: This post comes from my own experience interviewing candidates for different roles, not saying this is the best way to go, nor the worst, any contribution is more than welcome in the threads below!

Introduction

What's the very first thing you should do when driving an interview?, either way in person or virtually: it could sound too obvious, but you do need to introduce yourself.

Aside being polite, you would be evaluating a peer, a person who has(at least in paper before the interview) the same skills, maybe more maybe less, than you.

For properly introduce yourself, let the candidate to know:

Your Name: this is a most!, the candidate needs to know your name, when some questions arise it could be awkward to hear them say hey dude, hey you or something like that just because we forgot to give it a the very beginning.
Role that you have: you can be flexible with this!, which of the two scenarios below could sound better when you are interviewing, for instance, a Junior?:

Hi, my name is Shanks, I am a Senior Full-Stack Cloud Architect Scrum Master pleased to meet you!

Unless you are interviewing another Senior Full-Stack Cloud Architect Scrum Master, you can expect this reaction:

The other scenario instead:

Hi, my name is Shanks, I am a Senior dev in here, pleased to meet you!

See the difference?, the first one could sound a bit intimidating for most of the people, and so far it is very possible that only 5 seconds have passed(Jojo's pun intended)!

The time frame for the interview: time is precious, for you, for me, for everybody, so let the candidate know the time frame you could be using for the interview(by the way, thanks for taking some of your time for reading this!)

Set the Rules

As an interviewer, you should be in control of the interview, this include the times for questions, comments, suggestions, so let the candidate know about this since the very beginning.

If you determine that it could be a heavy interview, let the candidate know when there could be a break, for how long is gonna be that break, and in what part of the interview you would place the time for questions.

This is useful and allows you to hurry or slow down the main points you want to evaluate.

Ice Breakers

Well, so far you have only done 2 things introduce yourself and set the rules, now it is time to listen the person in front of you!

You have two options:

Go straightforward to the interview topics; start with all the questions right away, and evaluate in an atomic way: answer correct?: Yes/No.

Let's add up:
```
➕ No introduction

➕ No idea where the interview is going

➕ No sure whether questions are allowed or no
```
```
    Recipe for disaster ✅
```

Start in a nicer way, and let the candidate to feel comfortable.
A technique that I apply is the use of ice breakers, in particular:

🧊 How do you define yourself?

❄️ What are you doing right now in your current project?

♨️ Could you give me a brief introduction about yourself?

🔥 What's your favorite tech stack?

-Note: try to emphasize that it is a brief introduction, from 3 to 5min of the interview should be more than enough.

Interview

Now it comes the showtime!

By the time being, the candidate hopefully should feel more comfortable, you had the chance to talk, the candidate had the chance to talk, 5min is not enough for feeling familiar with someone, but 5 is greater than absolute Zero.

In this sections there are no restrictions, every interview is different for a thousand reasons, so follow the documents, templates, situations, or whatever resource you have for leading the interview in the way you feel it more natural.

As suggestions, try to keep a casual conversation with the candidate, you already set the mood, try to keep it simple, you are in front of a peer, cover all the areas you need to without applying extra pressure(for sure the candidate already has a lot of it).

Try to start with the easy topics and let the interview flows, according to the performance of the person, you would have an idea whether you would need to shrink or stretch the times, and cover or not some extra topics.

Closing Time

Last but not least, the Closing Time section, where Q/A can happen.

Perhaps the candidate did not have any questions at the very beginning, or in the middle(if you set some time in the middle for it), so you could give it a last try.

It is also a good opportunity for you to ask for comments or suggestions that the person could have for you, maybe you have some improvements areas that you don't even know yet and having the insight of different persons for free could worth a lot!

Conclusion

When you interview peers you most be prepared for the best interview in your life or the worst!; maybe you could have another thoughts, let's discuss in a thread below!

Thanks for reading!

5 tips for dealing with tough conversations in agile teams

crisarji — Mon, 17 Jan 2022 14:50:44 +0000

5 tips for dealing with tough conversations in agile

Hello developer pal!, glad to see you here.

Have you ever been working in a team, and suddenly a tough conversation with your team mate(s) is around the corner?, if you have, welcome to the team!, if you have not, be patient!, it is waiting for you!

One of these days, I was listening to a podcast, and I bumped into this topic, Dealing with tough conversations; I heard it and it caught my attention the fact that most of the items mentioned by the speaker match in agile teams, therefore I wanted to shared the episode, some principles and the similarities that came to my mind.

Show Me The Topics

The topics to be focused on are:

Podcast Episode
Principles
Similarities

Disclaimer: In this post, I share my thoughts and make a summary down to 5 main points, not looking for a transcription from the episode, instead I unified some of the bullets which I think should be together for agile teams purposes.

Podcast Episode

You can find a direct link clicking in the link below:

Spotify: John C. Maxwell

Note: Not sponsoring this podcast, just wanted to share the episode in case you want to hear it before reading along.

Principles

Whether you heard the episode aforementioned or not, let me summarize it in 2 words: Care and Candor

In agile teams, the relation with your teammates could be established with these 2 principles in mind

Care: values the person; he/she is not only a team member, is a valuable person, someone you could end up interacting with on a daily basis even more than you do with your family and friends, and guess what?, it goes also the other way around, so let's value our teammates in the same way we want them to value us.
Candor: values the persons potential; aside of value your teammates for what they currently are, let's value them for what they could become, as a team, we all have a big responsibility, to reach our clients expectations, and after reaching them, go beyond!, alone we are not enough, but as a team we are, we can grow, learn more, expand hard/soft skills.

Similarities

I found these next 5 points as the more important ones when working on agile teams:

Meet privately...NOW!

In agile teams time is everything!, time for plannings, time for understand the business expectations, time for developing, time for testing, etc. When having a disagreement, discrepancy, misunderstanding, the best time to aboard it is NOW.

The golden rule is to reach the other person(s) out ASAP in private, doing so, the scope of the conversation will be open for discussion between the parts of interest and close for outsiders.

Assume Good Motives

Giving the benefit of doubt is a MUST, when you are reached by a teammate, have a good attitude, it is good to remember that your teammates are a very important part of your life now, sometimes you interact with them even more than with your own family!, so it is better off to think that there are good reasons behind a meeting, a call, a chat message.

Offer-Receive specific and tangible observations explaining the consequences of certain things for the team

This is a tricky one, when you are the one reaching, keep in mind what is it that you have observed that could impact the team, and the negative impact of keeping that along; for instance, you schedule planning sessions, though you notice that your teammates are not participating, what could it be an approach?:

Observations =>

Lack of participation of a key member(s) during the planning session
Lack of opinions in topics related to certain critical functionality
Committing to a delivery with some gaps not discussed
Business thinking everything is "crystal clear"

Negative impact =>

Blurry requirements when starting the design/dev/qa phase
Misunderstandings since the creation of User Stories
Unplanned calls/meetings for clarifying requirements
Pressure on all areas right before end of sprint
Client upset for not reaching the commitments

This could be the hardest part of the conversation, some people or even you could not like that much to me questioned about your work, just keep in mind that feedback is an improvement opportunity, good or bad, no harsh feelings!

Look for common ground

I really like this sentence, look for common ground.

It seems like just words, but think about it, look for something, for what?, common ground, it means, let's look where we are more equals and less different, lets look for a common goal, for something beneficial for both or all of us.

Think it this way, we are a team, we are on a boat, as long as this boat keeps floating, we all keep floating, when it sinks, we all sink!, so let's leave aside our differences, let's wear each others shoes, be emphatic, and now let's look together for a target, a way to not repeat the same behavior and grow up as professionals.

Let's size us up and give our help accordingly

The more worth I see in you, the more help I express, and vice versa.

This is tricky, but see that the previous steps are a block-chain(pun intended) for end up in here:

if we talk as soon as a difference arise, it is because we care
if we assume good motives from each other, is because we care
if we flag each others points of improvement, is because we care
if we look for common ground instead of looking for who is right and who is wrong, it is because we care
then we can say we value the teammates(Care) and what they can become(Candor)

Conclusion

When treating another teammates as we expect to be treated, the tough conversation is less tough and more a conversation; maybe you could have another thoughts, let's discuss in a thread below!

Thanks for reading!

Lessons Learned of Connect Tech 2021

crisarji — Sun, 28 Nov 2021 22:24:15 +0000

Lessons Learned: Connect Tech 2021

Hello developer pal!, glad to see you here.

In this post, I'll share my lessons learned after Connect.Tech version 2021, and the best of all: it was BACK IN PERSON!.

Disclaimer: This post comes from my own experience after evaluating the most important aspects of the conference, there were remarkable talks about React, Angular, Vue and others, this includes no code at all, I'd rather mention some other aspects, more soft-skills-driven instead, though any contribution is more than welcome in the threads below!

Hook the Audience

Something I noticed in this conference, is the way that the speakers kept the audience hooked since the very beginning of the talk.

One speaker asked to everybody to stand up and start stretching!, another one asked to stay sit and warm up from there!, another one played the the trailer of an upcoming movie, I wont say what it was, maybe just a hint but gave all the people goosebumps and received an immediate reaction!

This seems to be something silly, but definitely it is not; having most of the people paying attention to you before start speaking is something hard to accomplish; there are a looot of distractions, top-1: the electronic devices, so it was interesting to see the different nets displayed to fish in the see of "skeptical".

Be Reactive with the Audience

Imagine you planned your talk for weeks; you did your research, found a topic, polished your weak spots, mounted a presentation, hooked the audience, and at the very beginning of you talk a cellphone's ringtone goes off!, what would you do?

Well, according to the physics:

For every action, there is an equal and opposite reaction...

Source: Third Law of Motion, Sir Isaac Newton

The natural behavior would be to be mad at the person, before starting the talk the speakers always ask for turning off the devices, or at least set them on vibrating mode, how is it that someone could not follow such a simple request?, well that happens, and a lot!

I saw that during one of the talks, but the speaker instead of yelling or being mad, had a very different reaction, he just stared at the person and said: "Hey, put the speaker on, so everybody can say hello!", everybody laugh about it, it was so natural that nobody got mad, right after that, the talk resumed and everything just went as expected.

Accessibility in the Presentations

We give for granted some stuff, and we forget that not everybody feels, sees or perceives the world in the same way we do.

In one of the talks, it caught my attention the fact that the presentation, which included some live coding, had a light background!, I couldn't help but to ask the speaker the reason why.

Well, he kindly gave an answer: it turned out that having a dark background(what is so normal to me) in a presentation could affect some people, not only in their eyes but their comprehension!

I read a little about it to understand and it makes sense, you can find a brief in this postpost

Color scheme, font size, animations, etc, among the key points for making the presentation remarkable, some other bullets can be found in this article

Make the Talk Interactive: Complete/Incomplete Source Code

It is said that time is money, in this case time is knowledge(which can be turned into money later, anyway).

When dealing with dozens of persons at the same time, ensure that all are working along with you is virtually impossible; some people has the tools, but not the knowledge, or have the knowledge but not the tools, they need to catch up their envs with everybody else's, but some have Linux, some other Windows, some other Mac, this could be a mess. A nice workaround I saw and I have always agreed to is having 2 versions of the code you are working:

Incomplete: allows the participants to feel like they are getting their hands dirt, the feeling of ownership of the code, and the satisfaction to move along during the session.
Complete: sometimes sh*t happens, so allowing the participant to have a final version of an executable code could let them keep the attention during the rest of the session.

In some of the talks this aforementioned approach was the one to follow, you can later double check or triple check the source code, and compare the pushed commits with your own notes, that could make it easier to understand.

Resources Links

It is said also that Sharing is Caring, agree!, even more when talking about code resources.

There are so many websites you can visit, posts, video tutorials, platform's courses; you don't even know where to start from.

When you assist to a conference like Connect.Tech, you notice that the speakers did their work; they do research, they create the exercises, they care about their presentation, and they share where to find this and other resources used.

There was this workshop where the speaker even created a channel with all of us, a whole bunch of strangers, and shared relevant info related to the topics.

Be Ready for Anything

It's better to be a warrior in a garden than a gardener in war...

Source: Japanese saying

Nice saying!, and so true.

During the conference, there was this session where the speaker was doing his best even when his machine kept failing and failing, till the point where he just quit using his machine and he resume a capella. It is better to be prepare for anything that could happen, than thinking that everything will go smoothly, also remember Murphy's Law.

Networking

My favorite bullet for sure, after all this time in the pandemic, we have been put through several restrictions, enclosed for several months and a bit afraid to interact with others face to face.

Of course there are plenty of web platforms for making this sort of events virtually; audio, video, recordings, side notes, and all of that is awesome!, but there is a human factor involved with the networking.

During the conference, we were able to interact with people from different places of the world, leading in all kind of companies, some of them world wide known, some others domestics; what all they shared was the importance they have in their own field.

It is something easy to accomplish in person; you can go for a drink or a snack, start a conversation with some other people, exchange points of view in technologies, approaches, platforms, finish your snack and move along to the next talk, maybe you can talk with the same persons later and learn a little more from each other!, but, how do we do it virtually?

It could be a little harder to interact with people other than the speaker when you joined a call; it is not like you can just ping someone out of the blue and ask him/her to join you in a private room, do you see my point?

Moving along with the New Normal

Till two years ago, having conferences was the rule every single year, right now it is the exception.

The changes during the pandemic are HUGE, passing from hundreds of attenders to ZERO to a few dozens in conferences, after almost 2 years, we are having a break therefore it is possible to plan and attend to an event like this, the sanitary protocols, the response of the people, and the commitment of everybody to make the things right are remarkable, not a single problem in 3 days in a row, we can still have hope to see more conferences in the upcoming year.

The face-to-face interaction is in the human nature, and it is nice to know that little by little is possible to do it again.

Conclusion

After seeing that the event was a success, some other conferences could try the same approach, follow the same directives and get the same success, thus I can foresight new conferences and in-person web tech events in the horizon!; maybe you have second thoughts, or you even attended and have a different point of view, let's discuss in a thread below!

Thanks for reading!

Spooky Dev Stories

crisarji — Sun, 31 Oct 2021 13:38:49 +0000

Hello developer pal!, glad to see you here.

What about sharing one spooky story from your life as dev?, me first!

When I started to work, it was as a Jr BE dev, using C# and Visual Source Safe, there was this delivery we needed to accomplish in one week, so I started coding on Monday, Tuesday, I made a couple initial commits, the CI/CD we had that time took the changes, created an artifact minimized and optimized, deployed it to QA and that was all, everything was running smoothly.

Next 3 days, I was so focused in my work that I completely forgot to commit, 3 days in a row without committing, on Friday afternoon, I finally did, and guess what?, the panic.

Something happened that I lost all my changes, I tried to recover it in any possible way, unsuccessfully. After spending a couple hours, I went to my boss, sure that I was gonna get fired, explained the whole situation, and instead of asking me for a card box, he sat at my desk, helped me to track down the latest deploy(from 3 days ago), disassembled some minimized files(function names as i, return values as x, etc), stand up from my desk and just said Good luck during the weekend, then left.

After spending the whole weekend decoding and remembering what a function with signature (a,b,c) with a return z could be, and not sleeping at all, I was able to deliver by Monday.

Moral: always commit!

Thanks for reading!

The Whats & Whys in a FE Senior position

crisarji — Mon, 30 Aug 2021 04:34:25 +0000

Tech Skills: The Whats & Whys in a FE Senior position

Hello developer pal!, glad to see you here.

Most of the time, we heard that some knowledge is required for certain position, usually we heard What is required, but what about the Why is it required?.
In this post, I'll share my thoughts in the reasons why some tech skills are mandatory when being/opting-in for a Frontend Senior position, I'll leave aside the must of HTML, CSS, GIT(or some other version control tools).

Show Me The Topics

The topics to be focused on are:

Programming Languages & Web Frameworks
CSS Frameworks & Preprocessors
Design Systems
Testing/Debugging
DevOps/Automation
State Managers
SPA/SSR/SSG
Rest/Graphql
Build Process: under the hood

Disclaimer: This post comes from my own experience and what I have seen so far in the area, not saying this is the best way to go, nor the worst, any contribution is more than welcome in the threads below!

Programming Languages & Web Frameworks

Want to know What to learn in this 2021?, take a look:

Source: Most Popular Languages 2021

As a FE dev, having Javascript or Python is a must, the most used languages worldwide now.

Why should you learn either or both of them? because they are the core for the main Web Frameworks out there, for sure you have heard about these:

Angular
Django
React
Flask
Vue

The list of web frameworks aforementioned is built on top of either, Javascript or Python. Having a robust base will help you to understand how to tackle an obstacle, or at least will give you a hunch, also will allow you to move from one framework to another easier.

CSS Frameworks & Preprocessors

What can I find when starting in a new project?

CSS Frameworks:
CSS Preprocessors:
- Sass
- Less

Nice!, all the heavy lifting related to the styling ready to be used!

Why should I care when it is only plug & play?

Well, because you do need to know the small hacks that could spare some precious time for you and your team!; for instance how to declare a variable, a mixin, the corresponding breakpoints, even adding a media query changes a little depending on the framework. Also, you need to know your preprocessor for avoiding duplication of classes, how to apply specificity(in the right way), writing less and getting more.

Design Systems

What is a design system?, well as I exposed in a previous post, this is a converging point for different areas, which has 3 fundamental goals:

UI/UX does not repeat itself

WebDev has one-and-only-one source of truth

QA can evacuate questions on its own

Source: My Vue Experience after 3 projects in 1.5 years

Why should I remotely care about other areas such as UI/UX?

Because nothing last forever, you could be so comfortable in your current project, with a design system already defined that you just use, and tomorrow you loose the client, the account is abruptly finished, you had a discussion with a stakeholder and you are expelled, then you move to another project, and you are asked to start working from scratch.

Wouldn't it be better to start fresh with some knowledge than with no knowledge at all?, well you should care about this point since it is easier to talk with the UI/UX person in charge of defining the Design System when both understand what's going on, the pros and cons, the different approaches, the changes, discussions, and agreements are easier when both areas are on the same page.

TIP: Among the best tools for accomplishing this sync up is Storybook, if you are not familiar yet, you could give it a try, thanks me later.

Testing/Debugging

What are the unit testing tools you are more familiar with?, let me guess:

Mocha
Chai
Jest
Karma
Jasmine

Why all his hype with the unit testing when you know you did it in the right way?

Easy!, it is our responsibility to ensure that new components, services, changes on the state of the application does not break higher environments, and does not break other pieces of the application added by other people.

A well performed unit testing is a relief, and can help to have a high coverage, also help the next dev to understand faster and better, even you can understand better the code when writing the unit tests.

TIP: Maybe you would like to take a look at Husky, this little fellow has some awesome features, for instance, you can set the rules for writing the commits your historical will have, also you can run all the tests before committing, when all tests success it allows the addition, otherwise it does not commit.

DevOps/Automation

What are some of the responsibilities DevOps and Automation people have in your project?:

Responsible of CI/CD
Create environments
Check Pipes and Jobs statuses
Run the automation alongside the Jobs
Create, check, correct and fix test suites

Why is it important to know about these processes when there is a person in charge of it?

Because sometimes the DevOps, Automation and Dev are the same, it is a bad practice(from my perspective), but how could you be sure this is not gonna happen to you sooner or later?, if so you better rise the flag, but some other times you could be unblocking your own team, let me elaborate.

DevOps and Automation Testers are human beings too, these persons can have PTOs, sick days, appointments, capacitations, for any number of reasons can be out of work, in case of issues, what would it happen?, is your team ok with the fact to wait from 1 to several days before a fix is done in pipes or releases?, knowing about devops and automation processes can help to unblock not only your team, also others(in case you do have granted permissions, otherwise, you'll have some free time to read a book or take a couple courses)

TIP: there are plenty of platforms for working and understanding CI/CD, you can check for instance GitHubActions, TravisCI, CircleCI before jumping to Azure, AWS or Jenkins

State Managers

What are those libs, patterns or packages you have heard of?:

Redux
RxJS
React/Redux
NgRx
Vuex

Why should I know any of those when http, services and local storage are available?

Well, because sometimes you will not be handling small apps/sites, when starting a client project, or even one on your own, keep in mind always the scalability of the project; local storage and its derivatives are an option, but a state manager for a SPA could be a better option. Adding new features involves add new setters, getters, actions, services interacting to each other, the final goal is to keep up to date the state for as long as the user has a session, hit the DB as few as possible and display required info in the fastest way.

SPA, SSR, SSG

Why should I know something other than SPA?, What could they aport to my experience?

Maybe you are used to write a SPA for every single scenario, but what if I told you that there are some other valid approaches for fulfilling a client expectations?

Not everyone needs a SPA, maybe the client needs a particular feature for holding a blog post, or a wiki, which changes every once in a while, or barely changes at all, would not it be better a Static Site?, maybe a Server Side Generator does the job with a better performance, Gastby?, VuePress? those are valid options!

Or even better, the users need to interact with the page, and needs a better SEO positioning, what about a Server Side Rendering?, Nuxt or Next could be a better approach(yes, we'll always have WordPress, up to you)!

Perhaps you cant decide the right approach because you dont know the difference between them, well for being/opting to a Senior position you should, this is part of the tech conversations you could be holding with a stakeholder, a Product Owner, or some other peers when deciding what's the best for business. You can read a bit more bout the differences here

Rest, Graphql

Why is Rest always on the table?, What is this trend for Graphql when I already master Rest?

The only constant is the change, even more in technology; some years ago, there was something called SOAP, the most used way to interact with http request/responses in xml format; later we had(and still have) Rest has been hanging around for a while, the days of interacting with XMLs are over(for most of the devs out there), plenty of services rely on Rest now; Graphql is the new member of the family, even though it is not a protocal, instead a query language, makes the API interaction cleaner, it is easy to learn and use, and has a lot of support, so better start learning now!

Build Process: Under the hood

Why should you know what happens in the backstage?, is not enough knowing What are the steps to follow?

Errors during the building phase of an application are not odd, in fact, several times they are expected, knowing about the process under the hood can give some guidance related to the issues and how to fix them; also what if the client complaints about a lot of console errors, the performance of the page is too low, the build takes a lot of time to get deployed, all of these could be part of a lack of knowledge in the process of building and deploying.
Required flags, changing the build environment, optimize the build, tree shaking the build, handling alerts on the build size, all of this needs to be covered; learning about Webpack and Rollup could have a big impact in your next deploy.

Conclusion

As shown above, there is a sort of gap between the what is required for being/opting-in for a Senior position and why it is required; it is not the fact to be an expert in all the areas, but reading and practicing a bit will help you to sharp the skills and when the time comes it gets easier to fit in in a project!

Thanks for reading!

How I met your...Scraper?

crisarji — Mon, 19 Jul 2021 04:57:26 +0000

How I met your... Scraper?

Hello developer pal!, glad to see you here.

In this post, I'll share my experience after running into a topic I had not met before... web scraping!.

Show Me The Topics

The topics to be focused on are:

Problem to solve: Booking a weekly service
Project dependencies
NodeJS folders structure
Express, Routing and Services
- Services Visualization
Puppeteer(Booking Service)
Nodemailer(Email Service)
Local use and remote Deploy
Bonus: Dealing with Captcha
Conclusion

Disclaimer: This post comes from a particular scenario I've been struggling with, I'm not preaching this is the best approach to follow for web scraping, nor the worst, any contribution is more than welcome in the threads below!

Note: There is available also a template project on GitHub in case it could be useful and save you some time.

Problem to solve: Booking a weekly service

A couple weeks ago, I got subscribed to a weekly delivery service, I am pretty happy with the service!, it is fast, efficient, always on time!, since day 1 the service has had no issues, not even delays, what's the only fallback I have found so far?, the booking process!

This could be a little picky from my end, I know, but see the steps I need to do every-single-day:

Open a website(only works on Chrome, no other browser)
Fill in my user/password
Move to Members path
Check my information and select the delivery address(displayed in a dropdown)
Move to the Next Step
Select the day of the week I want to book me the service(come on!, it is a week from today, as usual)
Move to the Next Step
Select the time of the day I want to book me the service on(it is the same time as every single day, dammit)
Finish the process
A "Thank you page is displayed"(without the result of the process I just did)
Move to Members path(again) and look for my upcoming bookings table result

These steps needs to be done every-single-day, and it is a pain in the back, cause if for some reason I forget to do it, my preferred time could have been taken, and I need to look for a different time, then I need to be aware of the delivery time(it would be different a week from today than the rest of the days); am I clear why this is a pain?, I hope so...

After a few days of missing the booking, I decided to automate the process with the help of some tools, I was not sure about how to start, so I research and gladly met web scrapping(don't get me wrong, I had heard about it, but there is a slightly difference between hearing and researching with a purpose, at least form my end 🤷).

So, what's the web scraping?, there are plenty of definitions out there on the Internet, the one that is more accurate for this post purposes is:

Web scraping is the process of using bots to extract content and data from a website.

Source: What is web scraping?

This is exactly what this post is about, create a sort of robot that will fill in information on my behalf in a site and later it will extract a result for me, and put it on my inbox.

Project dependencies

The tools used for accomplishing this enterprise are:

Main Dependencies

Dev Dependencies

Nodemon

package.json

"dependencies": {
    "express": "^4.17.1",
    "nodemailer": "^6.6.2",
    "puppeteer": "^10.1.0"
  },
  "devDependencies": {
    "eslint-config-prettier": "^8.3.0",
    "eslint-plugin-prettier": "^3.4.0",
    "nodemon": "^2.0.9",
    "prettier": "^2.3.2"
  }

Prettier and Nodemon come handy for having a nice experience, not mandatory though, fell free to use any other tool.

NodeJS folders structure

For this project, the structure is simple and set as follows:

scraper-template/
    ├── index.js
    ├── package.json
    └── routes/
      ├── booking.js
    └── screenshots/
      ├── home-page.png
    └── services/
      ├── bookingHandler.js
      ├── emailSender.js

There is one route for express to serve, two services for booking and emailing the results and a folder for screenshots, which only steps in development environment.

Express, Routing and Services

The index.js is a simple file with a 20 lines extension:

const express = require('express');
const app = express();
const port = process.env.PORT || 3000;
const booking = require('./routes/booking');

app.get('/', (req, res) => {
  res.json({ message: 'ok' });
});

app.use('/booking', booking);

/* Error handler middleware */
app.use((err, req, res, next) => {
  const statusCode = err.statusCode || 500;
  console.error(err.message, err.stack);
  res.status(statusCode).json({ message: err.message });
  return;
});

app.listen(port, '0.0.0.0', () => {
  console.log(`Scrapper app listening at http://localhost:${port}`);
});

The routes/booking.js includes the expressjs, services and config references, let's decompose it!:

express.js

The references to the packages used:

const express = require('express');
const router = express.Router();
...
...

services.js

The references to the defined services for handling the bookings and sending emails, a preview can be found below on Services Visualization

...
...
const emailSender = require('../services/emailSender');
const bookingHandler = require('../services/bookingHandler');
...
...

config.js

All the vales in here are process.env vars, these includes keys for login(webSiteUser, webSitePassword), email impersonation(authUser, appPassword) and email receivers(emailFrom, emailTo):

...
...
const {
  webSiteUser,
  webSitePassword,
  authUser,
  appPassword,
  emailFrom,
  emailTo,
  preferTime,
} = require('../config');

book-me endpoint

This route does the booking process for a user with a preferred time(if any):

router.get('/book-me', async function (req, res, next) {
  try {
    const bookMeResult = await bookingHandler.bookMe(
      webSiteUser,
      webSitePassword,
      preferTime
    );
    res.send(`The result of the booking was::${bookMeResult}`);
  } catch (err) {
    console.error(`Error while booking me for next week`, err.message);
    next(err);
  }
});
...
...

book-me endpoint

This route gets the bookings the user has set for the upcoming week:

...
...
router.get('/my-bookings', async function (req, res, next) {
  try {
    const bookingResult = await bookingHandler.myBookings(
      webSiteUser,
      webSitePassword
    );
    emailSender.sendEmail(bookingResult, {
      authUser,
      appPassword,
      emailFrom,
      emailTo,
    });
    res.format({
      html: () => res.send(bookingResult),
    });
  } catch (err) {
    console.error(`Error while getting the booking for this week`, err.message);
    next(err);
  }
});

Services Visualization

Service emailSender:

Service bookingHandler:

Puppeteer(Booking Service)

Here is where the magic begins!, only one reference for rule the whole process:

const puppeteer = require('puppeteer');

After this import, puppeteer is ready to roll!; there are plenty of examples on the internet, most of them apply all the concepts for web scraping in one single file, this is not the case.

This project applies some separations that, from my perspective, makes it easier to understand what's going on every step throughout the whole process, so let's dive into the sections:

-- Start the Browser --

The first interaction is starting the Browser. Puppeteer works perfectly with Chronium and Nightly, for this project the reference used is the default one, with Chrome(the web site to scrap only opens on Chrome), but if Firefox preferred, take a look at this thread on StackOverflow.

In the piece of code below, there is a var initialized for isProduction, this var is ready for being used when deployed on a web platform(Heroku we'll talk about it later), and another for isDev, I repeat, this is for explanation purposes, it is not required to have 2 when one of them can be denied and cause the same result.

When isProduction the launch is done headless by default, it means that the process is done in the background without any UI, also some args are included for a better performance, refer to the list of Chromium flags here.

When isDev, the headless is false, and args also include one for opening te dev tools after loading the browser.

const isProduction = process.env.NODE_ENV === 'production' ? true : false;
const isDev = !isProduction;
const authenticationError = 'Failed the authentication process';
const bookingError = 'Failed the booking process';

async function startBrowser() {
  let browser = null;
  let context = null;
  let page = null;
  if (isProduction) {
    browser = await puppeteer.launch({
      args: ['--no-sandbox', '--disable-setuid-sandbox', '--disable-dev-shm-usage'],
    });
    page = await browser.newPage();
  } else {
    browser = await puppeteer.launch({
      headless: false,
      defaultViewport: null,
      slowMo: 75,
      args: [
        '--auto-open-devtools-for-tabs',
        '--disable-web-security',
        '--disable-features=IsolateOrigins,site-per-process',
        '--flag-switches-begin --disable-site-isolation-trials --flag-switches-end',
      ],
    });
    context = await browser.createIncognitoBrowserContext();
    page = await context.newPage();
  }
  return { browser, page };
}

As seen above, the site is loaaded in Incognito, but can be opened in a regular tab.

-- Do Login --

For doing the login, some puppeteer features come in play:

goto: allows the navigation to a web site
type: types a value in an input field
click: allows clicking on buttons, table cells, submits
waitForSelector: recommended for allowing the page to recognize a particular selector before moving along
screenshot: takes a screenshot on demand, and store it in the app(it is possible to redirect the screenshots to remote services, in dev just place them in a root folder)

async function doLogIn(page, webSiteUser, webSitePassword) {
  await page.goto(constants.baseUrl + constants.loginEndpoint, {
    timeout: constants.timeOut,
    waitUntil: 'load',
  });
  isDev && console.log('Navigation to Landing Page Succeeded!!!');

  await page.type('#loginform-email', webSiteUser);
  await page.type('#loginform-password', webSitePassword);
  await page.click('button[type="submit"]');
  isDev && console.log('Login submitted');

  await page.waitForSelector('#sidebar');
  isDev && (await page.screenshot({ path: 'screenshots/home-page.png' }));

  return await findLink(page, constants.scheduleEndpoint);
}

Something to remark in the code above is that when dealing on development environment, the screenshots are taken, in production those are skipped(on purpose for the sake of the example)

-- Find a link --

This can change from page to page, but for this project, there is a link that was tracked down to the point that only loggedin members are able to see, for finding this or any other, a function is available, which receives as parameters the page instance and the endpoint to look for as an href:

async function findLink(page, endpoint) {
  const pageLinks = await page.evaluate(() =>
    Array.from(document.querySelectorAll('a[href]'), a => a.getAttribute('href')),
  );
  return pageLinks.includes(endpoint) || null;
}

-- Close the Browser --

Just pass the browser instance as parameter and close it.

async function closeBrowser(browser) {
  return browser.close();
}

Note: not going to elaborate on the details of the booking process, just take into account:

It is a wizard
The wizard has 3 steps, the final one is a submit
The name of the elements in the query selectors are tied to the site I'm scraping on, feel free to change them as much as you need
The idea is to share how to find elements, how to use query selectors, how to get the outerHtml on elements, wait for them to be available, all of this using Puppeteer

Nodemailer(Email Service)

Email service is contained in 30 lines of code, it is a define structure required by the import of nodemailer

Note: When using Gmail, it is mandatory to enable less secure apps, this will create a new password for just the particular application you are trying to link to, can read more here in nodemailer or in Google Support

const nodemailer = require('nodemailer');

async function sendEmail(weekBookings, { authUser, appPassword, emailFrom, emailTo }) {
  const mail = nodemailer.createTransport({
    service: 'gmail',
    auth: {
      user: authUser,
      pass: appPassword,
    },
  });

  const mailOptions = {
    from: emailFrom,
    to: emailTo,
    subject: 'Your bookings for this week',
    html: weekBookings,
  };

  mail.sendMail(mailOptions, (error, info) => {
    if (error) {
      console.log(error);
    } else {
      console.log('Email sent: ' + info.response);
    }
  });
}

module.exports = {
  sendEmail,
};

There is not too much complication in here, pass the authUser, appPassword, email from/to and the html to be send as email.

Local use and remote Deploy

How to be sure that everything is working as expected?, well two options:

-- Locally --

For running this locally Postman is the tool(don't judge me too much, I am used to it... used to Postman I meant, anyway)

  WEB_SITE_USER=YOUR_USER@YOUR_EMAIL_DOMAIN.com WEB_SITE_PASSWORD=YOUR_PASSWORD
  GMAIL_AUTH_USER=YOUR_USER@gmail.com GMAIL_APP_PASSWORD=YOUR_APP_PASSWORD
  GMAIL_EMAIL_FROM=YOUR_USER@gmail.com GMAIL_EMAIL_TO=YOUR_USER@gmail.com
  BOOKING_PREFER_TIME=06:55:00 npm run dev

This command will start the local server using nodemon setting all the expected process.env variables in port 3000 by default, so just use Postman for hitting http://localhost:3000/booking/book-me or http://localhost:3000/booking/my-bookings and a result will be retrieved.

-- Remote --

For deploying remotely the platform used id Heroku, not getting in details but found this helpful post in case you decide to follow that path(read carefully the Heroku's sections, and highly suggested to use Kaffeine).
All the process.env passed to the terminal when running locally are set as Heroku's environment variables, then the deploy is transparent.

Bonus: Dealing with Captcha

Sometimes the sites you try to scrap are sort of "protected" by Captcha, I say "sort of" cause there are ways to skip it, even some companies pay to regular users to help them to recognize captchas, you can read more over here.

The page scraped for this post behaves "interesting", sometimes the reCaptcha is ignored, some others appear right after submitting the login, so randomly fails; I opened an issue in puppeteer-extra, an npm lib extension for puppeteer which works hand-to-hand with 2captcha, I'm watching the issue closely, in case of getting a fix for the random issue I'll edit the post.

In case you were wondering, the hit of the endpoints after deployed to Heroku are done by a Cron-Job, it is fast and easy, and I received a custom email when the process randomly fails(the idea is to make it work permanently!).

Conclusion

As shown above, the web scraping is a great technique for making life easier, some hiccups could appear along the way(Captcha, Deploy servers restrictions or conditions) though some how it is possible to make it through!; maybe you could have a better way to do it, let's discuss in a thread below!

Thanks for reading!

My Vue Experience after 3 projects in 18 months

crisarji — Sun, 13 Jun 2021 23:52:08 +0000

My Vue Experience after 3 projects in 18 months

Hello developer pal!, glad to see you here.

In this post, I'll share my experience after 3 projects written/maintained in Vue 2.* during the last 18 months.

Show Me The Topics

The topics to be focused on are:

Agile Methodology and frameworks used
Design Systems
Infrastructure
Backend
State Management
Frontend

Disclaimer: This post comes from my own experience during this lapse, not saying this is the best way to go, nor the worst, any contribution is more than welcome in the threads below!

Agile Methodology and Frameworks used

Are you familiar with Agile Software Development?, cause I really am right now!, I really like this simple sentence as a summary:

Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment.

Source: What is Agile?

Nice, simple, straight to the point, isn't it?, during the last year and a half my teams passed over 3 different of its frameworks:

Scrum: from my perspective, the most interesting, this framework allowed our cross functional team to interact as a whole, splitting the work up in 2-weeks sprints, and constantly adjusting the business requirements, it is a quite nice experience!, highly recommended.
Kanban: my second favorite from top to bottom, a good option when the work to be done does not follow the same path, for instance working on different repos at the same time(MonoRepos, MFEs, Legacy Systems)l; when this happens perhaps Scrum is not enough cause the time-frames.
Extreme Programming (XP): required for an MVP one of my teams had, from my experience, the most risky one since you dynamically change requirements and some heavy lifting could magically appear/disappear down the road, highly not-recommended unless it is "Extreme"-ly necessary(pun intended), and please be "Extreme"-ly cautious(pun intended X2).

In case you want to read about the Agile Manifesto(the corner stone of the methodology) you can do it right here.

Design System

I learned that after defining the Methodology, it is good to have a robust Design System, you have 2 options: reuse an existing one or create one custom from scratch, either way the benefits are amazing!, when present it covers up 3 different areas:

UI/UX does not repeat itself
WebDev has one-and-only-one source of truth
QA can evacuate questions on its own

In case you want to have some existing guide lines, here you can find a list of available resources on the wild.

In the teams I was working on, those where custom, a recipe for success was:

A great strategy that we found was to create Vue components using Tailwind and creating its respectives stories on Storybook; I can say this is a great approach cause you can define your Design System in Storybook itself, and publish this to an accessible page for all your team members(under a VPN is even more secure), so it is available for everybody, they can see the components running in an isolated scope before even implementing it!

Infrastructure

Oh right, we had the Methodology and the Design System then what?

I learned that here it comes the Infrastructure, well the approaches we had the opportunity to work with where Jenkins, TravisCI and GitHub Actions.

For experience, in big projects, Jenkins is a great way to go, among all its pros, you can set it up for running on your behalf the unit testing and end-to-end testing before deploying!, in case of failure you are notified and a fix can be included.

In small projects, or side projects, you can use the TravisCI + GitHub Actions approach; GitHub already has some built-in options for setting up ymls and help you with Merge Requests and Deployments.

Note: TravisCI gives you 10,000 builds for free with your sign up, for small projects, proof of concepts or side projects it is a great deal!.

Backend

Also I learned for these projects, that a Backend on NodeJS and Firebase is easily handle.

NodeJS + Express give you the chance to handle the routing for CRUD operations, it is easy to handle the request/responses.

Firebase is ready to go as soon as you import it in your Vue project; with a few lines of code you are able to do a lot!; Authentication, Storage, Realtime DB, a whole bunch of options are available for you.

I wrote non-canonical series related to some Firebase features if you want to check them.

State Management

I learned about VueJS + Vuex. I'm used to Rxjs, NgRx but Vuex is from my experience the easiest; with a little of knowledge you are able to start creating on your own, the separation of concerns through modules, and the way to reference then is crystal clear:

store/
   ├── index.js
   └── modules/
       ├── module1.store.js
       ├── module2.store.js
       ├── module3.store.js
       ├── module4.store.js
       └── module5.store.js

Referencing the modules in the index.js make them importable through out your project, this includes State, Getters, Mutations, Actions; a new module is just the addition of a new entry in the index.js, a deprecated module is the removal of that entry(conditions may apply).

I also learned that you can namespace the modules!, then you can differentiate the elements by module instead of having dozens of lines with no context(trust me, with several modules this is amazing for debugging purposes, scalability and visual sake).

A clear example can be found below:

import { mapState, mapGetters, mapActions, mapMutations } from 'vuex';

export default {
  computed: {
    // Accessing root properties
    ...mapState('my_module', ['property']),
    // Accessing getters
    ...mapGetters('my_module', ['property']),
    // Accessing non-root properties
    ...mapState('my_module', {
      property: state => state.object.nested.property,
    }),
  },

  methods: {
    // Accessing actions
    ...mapActions('my_module', ['myAction']),
    // Accessing mutations
    ...mapMutations('my_module', ['myMutation']),
  },
};

It doesn't matter how small or how big is your project, it will be ready to scale, you can read here a bit more about Vuex and Namespaces.

Frontend

I learned that Vue has a smaller learning curve than Angular, and it is very similar to React(Note: assuming you have a strong base of Javascript, otherwise the curve is high on either of them).

As a dev who was mostly involved in Angular projects, understanding the core concepts and starting to be productive was easier than expected; I really think that the other way around must be harder, cause Angular has its own world.

Also learned about some core concepts that made my development faster and easier:

Atomic Design Pattern: structure your folders as =>
- Atoms: these are basic components, dummy ones; could be buttons, inputs, dropdowns, any imagiable component small enough to be functional and testable
- Molecules: a group of Atoms, at this level just a little logic included, it should not include communication with you state(if possible)
- Organisms: mixture!, can have Atoms and Molecules, at this tier communication with you State can be allowed; Mappers, Getters, here are accepted
- Templates: here you add together the aforementioned structures
- Pages: every page you add is an instance that can be accessed from your routing strategy

Vue Lazy Routing: it is trivially easy to lazy load the route components; after defining your routerOptions in 5 lines of code it is set and done.

import Vue from 'vue';
import Router from 'vue-router';

const routerOptions = [
  { path: '/', component: 'Home' },
  { path: '/home', component: 'Home' },
  { path: '/auth', component: 'Auth' },
  { path: '*', component: 'Auth' },
];

const routes = routerOptions.map(route => {
  return {
    ...route,
    component: () => import(/* webpackChunkName: "{{route.component}}" */ `../views/${route.component}.vue`),
  };
});

Vue.use(Router);

Vue Test Utils: Vue has its own utils for testing purposes, and it is quite easy to understand and use, let me show the most simple sample I found:

<template>
  <div class="modal" data-test="modal" aria-modal="true">
    <div class="modal-content">
      <slot></slot>
    </div>
  </div>
</template>

import { expect } from 'chai';
import { shallowMount } from '@vue/test-utils';
import BaseModal from '@/components/atoms/BaseModal.vue';

describe('BaseModal', () => {
  context('Template', () => {
    context('existence of the element', () => {
      it("should exist 'modal' element", () => {
        const wrapper = shallowMount(BaseModal);
        expect(wrapper.find("[data-test='modal']").exists()).to.equal(true);
      });
    });
  });
});

Global Registration of Components: There are components widely used, these are candidates to be registered globally so they can be referenced without importing them. An easy way to accomplished this is creating a _globals.js file and fill it in with:

// Globally register all base components for convenience, because they
// will be used very frequently. Components are registered using the
// PascalCased version of their file name.

import Vue from 'vue';

// https://webpack.js.org/guides/dependency-management/#require-context
const requireComponent = require.context(
  // Look for files in the current directory
  './atoms',
  // Do not look in subdirectories
  false,
  // Only include .vue files
  /[\w-]+\.vue$/,
);

// For each matching file name...
requireComponent.keys().forEach(fileName => {
  // Get the component config
  const componentConfig = requireComponent(fileName);
  // Get the PascalCase version of the component name
  const componentName = fileName
    // Remove the "./" from the beginning
    .replace(/^\.\//, '')
    // Remove the file extension from the end
    .replace(/\.\w+$/, '');
  Vue.component(componentName, componentConfig.default || componentConfig);
});

After that, just import that file in main.js file:

import '@/components/_globals';

Some other good practices can be found:

Conclusion

As shown above, I had a long way during the last 18 months, I'm giving my two cents in here in the way I understood the concepts, and what I think were the best practices applied; maybe you could have a better way to do it, let's discuss in a thread below!

Thanks for reading!

Vue Slots and Reusable components

crisarji — Sat, 08 May 2021 01:00:55 +0000

Vue Slots and Reusable components

Hello developer pal!, glad to see you here.

In this post, we will take a look at the way a simple feature as it is slot in vue could spare a lot of time and effort when having the same components displaying different data.

Sometimes, we need to replicate the same task with different data, for instance, you have a design system which determines that every single list element throughout the site needs to be consistent, this means having the same height, width, font, etc. Sounds fair!

For accomplishing this, there are 2 options:

Copy + Paste the same listing component in multiple places; the fallback of this approach comes when, for example, the font of the list item needs to be updated; if you, by chance, have in the project 1, 2 or 3 list items, you can manually make the change, all good!, but what happens when your project has a whole bunch of listing components?, it would be required go one by one and make the change; the effort on dev, qa, and the risk of letting one scenario out of the scope is high.
Create a Reusable Component, this will allow it to make the change in one only place and affect all of them at once!, here the slot concept comes handy, when using a slot, you can have the same look and feel, behavior, properties and others available for all the listing components.

Show Me The Code

The steps to be focused on are:

Having 1 reusable listing component
Having different view components, injected with different data
Having different view components, displaying different elements

Let me share to you the GitHub code here.

1. Having 1 reusable listing component

How would it look a slot for the example purposes?:

<template>
  <div>
    <ul>
      <li v-for="(element, index) in elements" :key="element.id">
        <slot name="element" v-bind:element="element" v-bind:index="index"></slot>
      </li>
    </ul>
  </div>
</template>

In the snippet above, there is a v-for directive which loops over the array in a property named elements; what it is happening is that every single element, and its index, are available to be part of the template, the slot has the option for binding values, these are available as soon as the slot is invoked.

This simple is to have a reusable component with slots!, the html elements can be modified as required: add css, new attributes, new binding props, everything will be ready to be used when invoked the component(check the GitHub repo for a nicer experience including Tailwind).

2. Having different view components, injected with different data

For the sake of the exercise, 3 different arrays are present for feeding the view components:

export const agents = [
  { id: '07531267-D', name: 'Remedios Carmona', calls: 12, deals: 5 },
  { id: '91958619', name: 'Dalal Heidema', calls: 20, deals: 12 },
  { id: 'NNaN31539321', name: 'Julien Legrand', calls: 25, deals: 17 },
  { id: '1NNaN60472038', name: 'Karina da Cunha', calls: 33, deals: 25 },
  { id: '060469-1435', name: 'Evelyn Scheerer', calls: 40, deals: 35 },
];

export const supervisors = [
  { id: '75687', name: 'Idelso Gonçalves', agents: 10, teams: 1, gender: 'male' },
  { id: '2NNaN64983816', name: 'Cassandra Leroy', agents: 20, teams: 2, gender: 'female' },
  { id: 'N901057Z', name: 'Arron Johnston', agents: 30, teams: 3, gender: 'male' },
  { id: '18066349671', name: 'Siham Reitan', agents: 40, teams: 4, gender: 'female' },
  { id: '48926083', name: 'Mariam Linde', agents: 50, teams: 5, gender: 'female' },
];

export const managers = [
  { id: 'NaNNA831undefined', name: 'Niilo Keranen', department: 'IT', gender: 'male' },
  { id: '2NNaN40789264', name: 'Leana Deschamps', department: 'Operations', gender: 'female' },
  { id: '283707860', name: 'Irma Boyd', department: 'HHRR', gender: 'female' },
  { id: '290471', name: 'Nicole Oehme', department: 'ACC', gender: 'female' },
  { id: '1NNaN44873525', name: 'Antonin Rey', department: 'Facilities', gender: 'male' },
];

As you can notice, the views will be Agents, Supervisors and Managers; as aforementioned, this items must be listed up following a design system specifications(width, height, font, typo) for keeping the consistency.

Let's suppose that the design system ask for something like these:

Agents view:

Supervisors view:

Managers view:

After taking a look at the mocking data and the requirements, what is changing are the fields to display, the order, and the background, since the Copy+Paste approach is discarded, the other possible way to go is the Reusable Components.

3. Having different view components, displaying different elements

Let's dig a bit into the implementation of the Reusable Component and slots.

The very first view is the one for Agents, we need to import the reusable component, register it, add an input property for feeding the list of elements and render it out(skipped steps in here, you can check the source code for more info), let focus in the template

Agents view:

<template>
  <custom-list :listElements="listElements" itemStyling="justify-between bg-gray-300">
    <template v-slot:element="{ element }">
      <div class="flex w-1/5"></div>
      <div class="flex w-2/5"></div>
      <div class="flex w-2/5"></div>
    </template>
  </custom-list>
</template>

A couple of interesting things from above snippet:

custom-list(our reusable component) is expecting for the list of elements and an item styling, also, it is accessing the element binding, so the data to be display is dynamic.

What about the second view?

Supervisors view:

<template>
  <custom-list :listElements="listElements" itemStyling="justify-between bg-blue-300">
    <template v-slot:element="{ element }">
      <div class="flex w-2/5"></div>
      <div class="flex w-1/5"></div>
      <div class="flex justify-end w-2/5"></div>
    </template>
  </custom-list>
</template>

This is pretty similar to the previous one, the biggest difference is that a different color is send to affect the background(in case you are not familiar with Tailwind, it is this bg-blue-300), and the order of the divs(the avatar from the mocks will be placed at the center)

Last but not least:

Managers view:

<template>
  <custom-list :listElements="listElements" itemStyling="justify-between bg-green-300">
    <template v-slot:element="{ element, index }">
      <div class="flex w-2/5"></div>
      <div class="flex justify-center w-2/5"></div>
      <div class="flex w-1/5"></div>
    </template>
  </custom-list>
</template>

Also similar to the other 2(that's the idea), but changing the background color again, the order of the elements to be displayed(avatar at the end) and also including the other binding property declared in the reusable component, the index.

After all the steps above, this is the output:

Notes:

You can find the repo for Vue2 and Vue3
Feel free to fork it and/or import it in an online code editor(I tried but there seems to be a known error )

Challenge: The CustomList component could be register globally, in case you want to stop importing it throughout the site

Conclusion

As shown above, the slots could spare some precious development time, help with the scalability and be customized as required; maybe you could have a better way to do it, let's discuss in a thread below!

Thanks for reading!

3 steps for handling GitHub Workflow Secrets

crisarji — Tue, 06 Apr 2021 23:57:23 +0000

What's the matter with Secrets?

Hello developer pal!, glad to see you here.

Secrets(aka environment vars in other contexts out of GitHub) can be used in different ways, basically they are a key/value pairs which allow the interaction with your app, site, blog, etc.

For a Secret to work, you will always have visibility for the Key but the Value will remain hidden till the end of time(or till you update it manually, up to you)!

For this post, in 3 steps we gonna set up a GitHub Workflow(PullRequest and Merge) for accessing GitHub Secrets, and allowing the deploy of a site.

Show Me The Code

The steps to be focus on are:

Creating the Secrets on GitHub
Connecting the GitHub Secrets to local repo for testing
Connecting the GitHub Secrets to remote repo for GitHub Workflow to kick in

1. Creating the Secrets on GitHub

Maybe the "hardest" of the steps; you just need to navigate to the repo where you want to add the data, go to Settings, and look for the option Secrets

Tip: Though you can add whatever Name and Value you want to, it is better to add a relevant Name, since this is the Key, something meaningful is crucial.

Note: Remember that the Value is hidden right after you save the Secret and wont be accessible again!, you can edit but wont see it again, be careful.

For this post purposes, let's take a Vue app + Firebase project, these Secrets would look something like this:

2. Connecting the GitHub Secrets to local repo for testing

When looking for a consistent project, it is required to be sure that the values of the Secrets stored on GitHub are working in your app.

Look below that the Keys are exactly the same present in the step above, taking Firebase as an example here since it gives a set of values for identify the required project and it is easy to run and test, but the same logic should apply with keys of any other platform

# ----------------------------------------------------------
# .env file
# ----------------------------------------------------------
VUE_APP_FIREBASE_API_KEY='not-set-yet'
VUE_APP_FIREBASE_APP_ID='not-set-yet'
VUE_APP_FIREBASE_AUTH_DOMAIN='not-set-yet'
VUE_APP_FIREBASE_DATABASE_URL='not-set-yet'
VUE_APP_FIREBASE_MESSAGING_SENDER_ID='not-set-yet'
VUE_APP_FIREBASE_PROJECT_ID='not-set-yet'
VUE_APP_FIREBASE_STORAGE_BUCKET='not-set-yet'
# ----------------------------------------------------------

Running this project locally should work for you as expected, if so, you can be sure that the Secrets remotely are synced up with the local ones.

Note: If you are not familiar with the .env modes, maybe this reference could be helpful!

3. Connecting the GitHub Secrets to remote repo for GitHub Workflow to kick in

Now you could we wondering, how can I use those Secrets in my GitHub Workflow?, well it is quite easy to accomplish using GitHub Action; if you are not familiar with it, maybe you can take a look at this documentation, long story short, you just need to include a yaml to a .github/workflows folder in your root repo, and add the commands you want to affect the behavior of your app, for instance when pushing a new Pull Request or Merging to a specific branch.

For this post purposes, an action for a new Pull Request is triggered mimicking a Firebase hosted project, keep focus on env entry:

# This file was auto-generated by the Firebase CLI
# https://github.com/firebase/firebase-tools

name: Deploy to Firebase Hosting on PR
'on': pull_request
jobs:
  build_and_preview:
    env:
      VUE_APP_FIREBASE_API_KEY: ${{ secrets.VUE_APP_FIREBASE_API_KEY }}
      VUE_APP_FIREBASE_AUTH_DOMAIN: ${{ secrets.VUE_APP_FIREBASE_AUTH_DOMAIN }}
      VUE_APP_FIREBASE_DATABASE_URL: ${{ secrets.VUE_APP_FIREBASE_DATABASE_URL }}
      VUE_APP_FIREBASE_PROJECT_ID: ${{ secrets.VUE_APP_FIREBASE_PROJECT_ID }}
      VUE_APP_FIREBASE_STORAGE_BUCKET: ${{ secrets.VUE_APP_FIREBASE_STORAGE_BUCKET }}
      VUE_APP_FIREBASE_MESSAGING_SENDER_ID: ${{ secrets.VUE_APP_FIREBASE_MESSAGING_SENDER_ID }}
      VUE_APP_FIREBASE_APP_ID: ${{ secrets.VUE_APP_FIREBASE_APP_ID }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: npm ci && npm run build
      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: '${{ secrets.GITHUB_TOKEN }}'
          firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT }}'
          projectId: secret-project-test
        env:
          FIREBASE_CLI_PREVIEWS: hostingchannels

As shown above, before running the checkout/deploy steps, the env entry takes the wheel; what happens here is that the GitHub Workflow will declare and initialize on its scope the secrets already defined in the GitHub repo!, so everything is kept together through 3 different places!:

The Secrets you define on GitHub
The Key/Values you use locally(.env file recommended)
The GitHub Workflow used for the GH Action(PR, Merge, etc)

A change in the Secrets wont mess with the whole logic, editing a value, as long as it is a valid one, will run seamlessly for your devs and users, saving time and avoiding some headaches.

Note: you can find more info about the used steps actions here actions/checkout@v2 and here FirebaseExtended/action-hosting-deploy@v0

Conclusion

As shown above, keeping Secrets, or env variables is not so difficult when following the integration steps; maybe you could have a better way to do it, let's discuss in a thread below!

Thanks for reading!

Firebase: Firestore-Rules

crisarji — Mon, 22 Mar 2021 15:15:11 +0000

What's Firebase Firestore Rules?

Hello developer pal!, glad to see you here.

Rules, rules and rules, we always hear about rules to follow for interacting with databases, endpoints, programming languages, and well, Firebase Firestore is not the exception to the...Rule(dammit once again!).

Anyway, when you work with Firebase you see the features related to store some kind of information have their own Rules tab, this is the way you can declare for allowing/denying the access to certain resources based on the user who is trying the request.

A bad practice is to keep the resources open for everybody throughout the web, if so, anyone could perform CRUD operations on your site/app, modify assets, or even remove collections(and I am pretty sure you don't want that, do you?), you can read more information right here.

Show Me The Code

Disclaimer: For this post, a shallow explanation will be given related to Firestore ans Security Rules version 2, released on May 2019

The 3 main pieces to be focus on are:

Default versions for test and prod
Writing rules straight in console vs versioned file
Allow/Deny access according to auth states and functions

Default versions for test and prod

Whenever you start a new Firebase project, in the section Firestore/Rules, creating a new db project will present 2 options, you can opt any of those in, let's see the difference:

Mode Production

Under this mode, any access is explicitly denied, this forces the developer to add some logic for explicitly allowing users to access the resources.

The default schema for production mode looks like this:

  rules_version = '2';
  service cloud.firestore {
    match /databases/{database}/documents {
      match /{document=**} {
        allow read, write: if false;
      }
    }
  }

Something to remark is the fact that the rules keep the track on a historical, this means that is possible to activate a previous rule schema, compare a former version against the most recent one, and even delete unused schemas; this also helps to easily find bugs when adding new docs or collections.

Mode Test

Under this mode, any access is explicitly allowed to any user for the next whole month(by default through a timestamp). This will allow the developer to start the work right away, though, the idea is set the schema as soon as possible for allowing only expected users to consume resources.

The default schema for test mode looks like this:

  rules_version = '2';
  service cloud.firestore {
    match /databases/{database}/documents {
      match /{document=**} {
        allow read, write: if
            request.time < timestamp.date(2021, 4, 20);
      }
    }
  }

Just like in production mode, the rules keep the track on a historical, also, a few days before due date, the main email registered will start receiving notifications about the expiring access to the database collections and docs unless a new rule schema is applied.

Writing rules straight in console vs versioned file

Straight in Console

Writing straight to Firebase Console is an option, it is easy and fast.

One more feature with this approach, is the integration with an sort of built-in linter, it determines some syntax issues before publishing, in fact, it throws an error, and the changes wont be published till the issue is fixed.

Versioned File

A cleaner way to have the rules is through a versioned file, in your firebase.json file, you can add an entry for firestore/rules(and even indexes!).

  {
    "hosting": {
      ...
    },
    "firestore": {
      "rules": "firestore.rules",
      "indexes": "firestore.indexes.json"
    },
    "functions": {
      ...
    },
    "emulators": {
      ...
    }
  }

Then you can add the firestore.rules file and keep the versions in git or any other version handler

The flow goes as shown below, if more info required, take a look at the documentation right here.

  // Set up Firestore in your project directory, creates a .rules file
  firebase init firestore

  // Edit the generated .rules file to your desired security rules
  // ...

  // Deploy your .rules file
  firebase deploy --only firestore:rules

Allow/Deny access according to auth states and functions

Either way the writing of rules goes, the critical part is the access to docs and collections. It is possible to create js functions for avoid duplicating conditionals for every element, I wrote a post related to Adding roles to the authentication with Vue(x)+Firebase in case you want to check the use of claims and token additions.

So, for example, you could add a function for determining whether a request comes from an Admin or a Regular user profile, according to the resolution(handle by Firebase itself), the access to different resources is granted or not.

Take a look at the example below:

  rules_version = '2';

  service cloud.firestore {
    match /databases/{database}/documents {
      // true if the user is signed in and the claim is admin
      function isAdmin() {
        return request.auth.uid != null && request.auth.token.admin == true;
      }
      // true if the user is signed in and the claim is regular
      function isRegular() {
        return request.auth.uid != null && request.auth.token.regular == true;
      }

      // Shared collections
      match /settings/{doc} {
        allow read: if isAdmin() || isRegular();
        allow write: if isAdmin();
      }

      ...
      ...
      ...
    }
  }

What happened in the code above?:

The functions created always ask whether the request incoming is related to a user authenticated, otherwise, the access is invalid and the request is denied
The function isAdmin(), when is invoked by an authenticated user, it looks for a particular token, in this case, the admin token, if presented, the request is validated
The function isRegular(),just like isAdmin() looks for a particular token, in this case, the regular token, if presented, the request is validated
There is a collection of settings, when a request for reading comes, the fetching is available only for authenticated users with a role of admin or regular
In the same collection of settings, when a request for writing comes, the upsert is available only for authenticated users with a role of admin

This is useful since even when the APIkey of your app/site is available for third-parties, the requests wont do any operations to your data without an authenticated-and-roled user.

Sometimes read and write could be to macro, you can granulate them a bit more:
_read rule can be broken into get and list
_write rule can be broken into create, update, and delete

More info about this topic can be found right here

Conclusion

As shown above, Firebase Firestore rules are quite powerful, allowing even write some functions in the declared schema for avoid repeating the code over and over again; maybe you could have a better way to do it, let's discuss in a thread below!

Thanks for reading!

Tailwind Feature: animate-pulse

crisarji — Tue, 02 Feb 2021 13:12:35 +0000

What's animate-pulse in Tailwind?

Hello developer pal!, glad to see you here, have you ever been wandering on your social networks and suddenly you find a post which caught your attention, you want to see the comments, click in the link, and have the impression that a whole bunch of comments are coming cause you see a sort of template which fades in and out, and after a few milliseconds, it loads 1 comment, or sometimes 0!? it is a a mix of feelings, you are half happy/ half disappointed; well today we will be talking about this really cool feature, then you can pull the leg to your own users!.

For this endeavor, it is this reaaaally cool feature included in TailwindCss, the animate-pulse you can read more information right here.

Show Me The Code

Disclaimer: For this post, want to show 1 possible approach used in some other projects, maybe not the best way to do it, maybe not the worst, please feel free to start a thread in the comments section below in case of question, suggestions, improvements.

The 3 main pieces to be focus on are:

The use of Tailwind.
A practical example using VueJS.
The code posted in Stackblitz(so you can play around)

Let me share to you the Stackblitz code here.

Want some explanation? chop-chop!

The animate-pulse causes this fade in/out effect, it is a nice way for letting the user know that something is happening under the hood and keep them hooked!, let see step by step how to accomplish something like this.

Step 1

Set a list of elements

For example purposes, a employees.js file is being consumed, it has the elements to be used for loading the component; notice that this can be changed for an API response or any other resource invocation for feeding the component up.

Every element has a shared structure that will be important for the pulse effect a bit further.

  ...
  const employees = [
  {
    id: "Emp-001",
    name: "Yusha Beil",
    avatar: "https://i.pinimg.com/736x/3f/94/70/3f9470b34a8e3f526dbdb022f9f19cf7.jpg",
    isActive: true
  },
  {
    id: "Emp-002",
    name: "Fearne Greene",
    avatar: "https://i.pinimg.com/736x/3f/94/70/3f9470b34a8e3f526dbdb022f9f19cf7.jpg",
    isActive: true
  },
  {
    id: "Emp-003",
    name: "Keegan Cortes",
    avatar: "https://i.pinimg.com/736x/3f/94/70/3f9470b34a8e3f526dbdb022f9f19cf7.jpg",
    isActive: true
  },
  {
    id: "Emp-004",
    name: "Anton Chaney",
    avatar: "https://i.pinimg.com/736x/3f/94/70/3f9470b34a8e3f526dbdb022f9f19cf7.jpg",
    isActive: false
  },
  {
    id: "Emp-005",
    name: "Ruari Mellor",
    avatar: "https://i.pinimg.com/736x/3f/94/70/3f9470b34a8e3f526dbdb022f9f19cf7.jpg",
    isActive: false
  }
];

export default employees;

  ...

Step 2

Have some props ready to be filled

There are 2 important properties required when following this approach: 1 the listElements and 2 isLoading(or any other named flag for noticing when an operation still pending).

It is important to remark that as the listElements is faking an API call, the isLoading is mocking a state flag, this could be a flag shared in Vuex state manager for keeping the interaction up to date at any time.

  ...
  props: {
    listElements: {
      type: Array,
      default: () => [...employees] //Note: this employees comes from the imported file, in a real scenario the default would be `[]` and the prop will be feeded externally
    },
    isLoading: {
      type: Boolean,
      default: true
    }
  },
  ...

Note: For testing purposes, the isLoading flag is set after a setTimeout in the mounted hook, thus mimicking the state manager behavior as follows:

  mounted() {
    setTimeout(() => (this.isLoading = false), 3000); //Note: When interacting with a state manager(e.g. Vuex), remove this hook and let the flag to be filled from a state getter.
  }

Step 3

Have a data prop ready with a list of fake elements to be loop through

Here is where the tweaks start on!, handling this list of fake elements will allow the component to iterate over a ready-to-use list at any time

  ...
  data: {
    name: "Example List!",
    fakeElements: [1, 2, 3, 4, 5]
  },
  ...

You can add as many fake elements as you want; for not overwhelming the example only 5 are added here, it matches the number of entries to be added after flipping the flag isLoading.

Step 4

Let a computed property to determine which list to render

Another small tweak for switching between the fake list(always ready) and the real list of elements.

This way it is for sure that the html will have a list of elements at any time, the trick is just to flip between the real deal and the fake stuff, as easy as that!

  ...
  computed: {
    renderList() {
      return this.isLoading ? this.fakeElements : this.listElements;
    }
  }
  ...

Step 5

The component html

Vuejs allows to set classes to the html elements as expressions, that's the final piece of code, add the animate-pulse for the more relevant elements depending on the flag value isLoading.

Since the fake list is always ready to be looped, and it is composed of barely valid elements, none of the properties are shown, therefore the effect can be used as long as the flag does not change in all the desired elements.

<div>
  <h1>{{name}}</h1>
  <div class="w-screen bg-transparent flex items-center justify-around">
    <ul class="w-full max-w-md overflow-auto">
      <li
        v-for="element in renderList"
        :key="element.id"
        class="p-4 mb-3 flex items-center justify-between bg-white shadow rounded-lg cursor-move"
      >
        <template>
          <div class="flex items-center">
            <img
              class="w-10 h-10 rounded-full"
              :src="element.avatar"
              :alt="element.name"
              :class="{'animate-pulse bg-gray-400' : isLoading}"
            />
            <p
              class="ml-2 text-gray-700 font-semibold font-sans tracking-wide break-all md:break-words"
              :class="{'animate-pulse bg-gray-400 w-48 h-6' : isLoading}"
            >
              {{element.name}}
            </p>
          </div>
          <div class="flex items-center">
            <button
              class="btn mx-4 px-4 rounded"
              :class="[{'animate-pulse w-12 h-6' : isLoading}, element.isActive ? 'bg-green-400' : 'bg-red-400']"
              @click="editItem(element)"
            >
              <span class="capitalize text-white">{{isLoading ? '' : 'Edit'}}</span>
            </button>
          </div>
        </template>
      </li>
    </ul>
  </div>
</div>

In the code above, notice a few thing, for example, when loading the values, the animate-pulse is applied from 1 to N elements, this means that it is possible to include the animation on any html element depending on your own requirements, thus it is possible to match the styles even with no data available.

A good example is the button element, the width and height is given by the text content rendered on it; when loading, we don't want to show the label to be used, so there is no way to calculate that value, the easiest way to get rid off this issue is to assign a width and height as long as the real data is not available, and that's exactly what happens on
{'animate-pulse w-12 h-6' : isLoading}, the effect is active with a Tailwind height and width whilst processing the real data.

Conclusion

AS shown above, this Tailwind feature is pretty cool and can be integrated with api calls results and loading flags in the state manager to make the user feel more comfortable when interacting with your site/app; maybe you could have a better way to do it, let's discuss in a thread below!

Thanks for reading!

Adding roles to the authentication with Vue(x)+Firebase

crisarji — Sat, 05 Dec 2020 23:20:46 +0000

Greetings and Recap

Hello again developer pal!, if you have come across this repo on purpose great! thanks for reading, otherwise, maybe you want to take a look at its predecesor login-vuex-firebase.

Anyway, let me tell you that this repo is the next step to the authentication using Vuex and Firebase, yes, this is for the authorization; it is a simple one, using an assigned role for some users by email. I can bet that there are several ways to do it, I wont go too deep because:

These are my first posts so I am taking it easy.
Want to give you a sample, you are allowed to fork and reimplement as much as you want/require.
Any feedback is more than welcome as a PR or thread in this post.

If you checked my aforementioned code and post, you remember we ended up having a functional authentication like this:

So far so good!, but what would happen if you want to limitate the access to the users?, depending whether dealing with an admin or a player(yeap these are the couple roles we could have for this case), we want to have a way to allow certain views to the admin and some others to the player, something like this:

Admin

Allow the access as an administrator to a dashboard page, but forbid to access other users page

Player

Allow the access as a player to a landing page, but forbid to access admin pages

Too much text and gifs, let see the code!

Show Me The Code

Disclaimer: For the last post, I mentioned that there are plenty of posts related to Firebase and how to set it up, and that you should have a basic knowledge of the platform, at least have 1 project and the API Keys available. In this ocassion I'll be a bit more picky, it is imperative to have some knowledge of Firebase functions, in case you are not familiar you can read about it here.
Also, for running functions there are 2 main requirements: 1. node version when deploying must be 10 or above, 2. some interactions may require an upgrade from Spark to Blaze plan.

Let me share to you the Github code here, you can find the requirements for running the app locally, also a functions folder which is required for the roles implementation; since it is still in an early stage, no live demo yet.

Want some explanation? sure thing! keep reading below

As you already know, we are diving in a bay called Firebase, we'll interact a bit more with one of its islands the Firebase console, so please have an active project, that will make it easier for you to follow the explanations, I'll split them into steps for trying to make it easier to read.

Step 1

Roles collection on Firebase

Since the goal is give you an idea of what you can do with the platform roles collection only requires 2 properties: one for the email and one for the isAdmin, remember that you can make it suit your requirements whatever other way you want or need.

Now on, whenever a user with this email is created, Firebase on its own will turn it into an admin user, any other user will be treated as a player role, keep reading to see the how!

Step 2

Firebase and Custom Claims

First thing to know is the way the platform exposes the authorization interaction, this is through the use of Custom Claims and Security Rules; we are aboarding the first in here. According to the official documentation:

The Firebase Admin SDK supports defining custom attributes on user accounts. This provides the ability to implement various access control strategies, including role-based access control, in Firebase apps. These custom attributes can give users different levels of access (roles), which are enforced in an application's security rules.

What does that mean?, well in summay it means that after creating a new user, we can append some new attributes to the claims object present in the background, and we can take advantage of that behavior for handling roles, not too hard to follow right?

You can read much more about Claims here in case you are not convinced with my shallow explanation.

Step 3

Setting Custom Claims

For setting a custom claim is necessary to make a couple changes in the previous code we used for the login.

First of all, a small tweak needs to be done on signup action on store/modules/authentication.js; just flip the enable to false:

  ...
  async signup({ commit }, payload) {
    commit('setLoading', true);
    await fb.auth.createUserWithEmailAndPassword(payload.email, payload.password)
      .then(firebaseData => {
        fb.usersCollection.doc(firebaseData.user.uid).set({
          nickname: payload.nickname,
          name: payload.name,
          email: payload.email,
          enable: false // <= this from true to false
        })
          .then(_ => {
  ...
  ...
  ...

This will force every single created user to be flipped to enable = true manually or programatically.

You could ask yourself Why would I disable every new user?, well imagine that you have a selected group of users for your application, you dont want to control the signup but the signin, so you can filter who interacts with your before hand.

Important: take into account that what we just did was to disconnect the user created in our custom users collection, remember that this is an extension for the authorization user, this last is the one which possesses the claim that we need to modify for the role.

So, how can we add the claim for a brand new created user?, well with a predefined trigger background function of course!

Long story short => Firebase has some triggers to be used out of the box in cases of create, update, delete, etc a user; the trigger we do care in particular is onCreate.

After knowing this, in the root folder of the project, there is new folder called functions, it is a simple structure with an index.js, a package.json, and a few more required-but-simple files, take a look at the first:

index.js

const functions = require('firebase-functions');
const admin = require('firebase-admin');
admin.initializeApp();
exports.processSignUp = functions.auth.user().onCreate(async user => {
  if (user.email) {
    const adminUsers = admin.firestore().collection('adminUsers');
    const snapshot = await adminUsers.where('email', '==', user.email).get();
    const customClaims = snapshot.empty ? { player: true } : { admin: true };
    return admin
      .auth()
      .setCustomUserClaims(user.uid, customClaims)
      .then(_ => {
        if (!snapshot.empty) {
          const userUpdate = admin.firestore().collection('users');
          userUpdate.doc(user.uid).set({
            nickname: user.email,
            name: user.email,
            email: user.email,
            enable: true,
          });
          functions.logger.info(`User with email ${user.email} was added as admin and enabled!`);
        }
        const metadataRef = admin.database().ref('metadata/' + user.uid);
        return metadataRef.set({ refreshTime: new Date().getTime() });
      })
      .catch(error => {
        functions.logger.error(`There was an error whilst adding ${user.email} as admin`, error);
        return;
      });
  }
  functions.logger.console.warn(`There was no email supplied for user, no role added.`);
  return;
});

Saw that?, in only 32 lines of code(it could be even less) resides all the logic for checking the role, add it if required, modify the extended user and report the execution status of the function, let's split it bit by bit.

This code imports the required modules, initialize the app and registers the trigger for the OnCreate; therefore whenever a new user is added, via signUp or manually it will pass through this function.

const functions = require('firebase-functions');
const admin = require('firebase-admin');

admin.initializeApp();

exports.processSignUp = functions.auth.user().onCreate(async user => {
  ...
  ...
  ...

Next, if no email is registered for any reason, the logger exposed by firebase-functions writes in the web logs

if (user.email) {
  ...
  ...
  }
  functions.logger.console.warn(`There was no email supplied for user, no role added.`);
  return;
});

In case a valid email is in place(this should be almost always), the function will look for the roles collection, will execute a query where looking up for the email, in case of match, the snapshot will not be empty, thus the customClaim is set as admin, otherwise it will be dealing with a player

exports.processSignUp = functions.auth.user().onCreate(async user => {
  if (user.email) {
    const adminUsers = admin.firestore().collection('adminUsers');
    const snapshot = await adminUsers.where('email', '==', user.email).get();
    const customClaims = snapshot.empty ? { player: true } : { admin: true };
    return admin

The final step is setCustomUserClaims using the uid identifying the user and the customClaim which determines whether dealing with an admin or a player; also notice that in case the function is dealing with an admin it will add a new record in the extended users collection(pretty much what we do in the signup action in our authentication module).

const customClaims = snapshot.empty ? { player: true } : { admin: true };
return admin
  .auth()
  .setCustomUserClaims(user.uid, customClaims)
  .then(_ => {
    if (!snapshot.empty) {
      const userUpdate = admin.firestore().collection('users');
      userUpdate.doc(user.uid).set({
        nickname: user.email,
        name: user.email,
        email: user.email,
        enable: true,
      });
      functions.logger.info(`User with email ${user.email} was added as admin and enabled!`);
    }
    const metadataRef = admin.database().ref('metadata/' + user.uid);
    return metadataRef.set({ refreshTime: new Date().getTime() });
  })
  .catch(error => {
    functions.logger.error(`There was an error whilst adding ${user.email} as admin`, error);
    return;
  });

Look the code above, among the props notice the enable = true, this has a double purpose:

Enable the admin user immediately
Allows the creation of admin users directly from Firebase console instead of going through the whole signup process

So, something like this is possible, easier and more viable than running the whole signup:

In case you were wondering, yes, this user above is the same added in the Step 1.

Step 4

Deploying the processSignUp function

Hope you have followed the previous steps, may look a bit complicated, but after a couple more reads will be cristal clear!, so for the next step we need to deploy the processSignUp function, let's take a look at Firebase's console first:

In console, in Functions section, if no functions created a 2-steps wizard will appear

Step 1

Step 2

Final Panel

Now, how to deploy the function in Firebase?, it is an easy process(the followinf steps must be executed inside functions folder):

Connect your functions with your Firebase project executing:

  firebase use --add

Pick the project and an alias(this works better when multiple projects exist under the same instance)

Next, run the script:

  npm run deploy

After that, the deploy should be completed and successful

Now if you navigate to the Firebase functions console again, there must be a new entry for the just created function

And that's it! every time a matching-role user is added, an information message will be displayed in the records of the function

Step 5

New Routes to be validated

The routes are pretty much the same, just add the new views, add a meta attribute with the custom prop requiresAuth, and register them.

  ...
  const routerOptions = [
    { path: '/', component: 'Landing', meta: { requiresAuth: true } },
    { path: '/auth', component: 'Auth' },
    { path: '/landing', component: 'Landing', meta: { requiresAuth: true } },
    { path: '/dashboard', component: 'Dashboard', meta: { requiresAuth: true } },
    { path: '*', component: 'Auth' },
  ];

  const routes = routerOptions.map(route => {
    return {
      ...route,
      component: () => import(/* webpackChunkName: "{{route.component}}" */ `../views/${route.component}.vue`)
    };
  });

  Vue.use(Router);
  ...

Remember the method beforeEach? now is more important than before, the claims added in the processSignUp are checked before navigating to every single view; when an admin tries to navigate a player page, is inmediately redirected to its scope of enabled view(s) and vice versa; this way the app is ready to authenticate and authorize users(in a simple way)

  ...
  const router = new Router({
    mode: 'history',
    routes
  });
  router.beforeEach((to, from, next) => {
  auth.onAuthStateChanged(userAuth => {
    if (userAuth) {
      auth.currentUser.getIdTokenResult()
        .then(({claims}) => {
          if (claims.admin) {
            if (to.path !== '/dashboard')
              return next({
                path: '/dashboard',
              });
          }
          if (claims.player) {
            if (to.path !== '/landing')
              return next({
                path: '/landing',
              });
          }
        })
      }
      const requiresAuth = to.matched.some(record => record.meta.requiresAuth);
      const isAuthenticated = auth.currentUser;
      if (requiresAuth && !isAuthenticated) {
        next('/auth');
      } else {
        next();
      }
    })
    next();
  });
  ...

Conclusion

Protect the app views is possible using Firebase and Vue, it is a bit trickier than the simple login but not impossible; maybe you could have a better way to do it, let's discuss in a thread below!

Thanks for reading!