Forem: Chad R. Stewart

Compile a single executable from your Node app with Node.js 20 and ESBuild

Chad R. Stewart — Mon, 01 May 2023 16:46:46 +0000

Introduction

Node.js 20 was released very recently. Along with several other features, you can now compile your Node.js project into a single executable that can be run in environments without Node.js installed. It’s important to note that this is still experimental and may not be suitable for use in production.

Node.js has instructions on how to set up these single executables: https://nodejs.org/api/single-executable-applications.html

Unfortunately, when compiling the executable, you will not compile dependencies into your executable. To solve this problem, we will leverage a JavaScript bundler to bundle our dependencies into one file before compiling it into our single executable.

Prerequisites:

Node.js 20

Please note: While TypeScript is used in this article, it is not necessary.

Putting Together our Project

First, we need a project that we will build into our executable.

We’ll first define our server.

server.ts

import express from "express";
import https from "https";
import fs from "fs";
import path from "path";

export const app = express();

//Initialize Request Data Type
app.use(express.json({ limit: "10mb" }));

app.get("/", (req, res) => res.send("Hello World!!"));

const port = 3000;
app.listen(port, () => {
    console.log(`Server is live on ${port}`);
});

We define our package.json next:

package.json

{
  "name": "node-executable-example",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "build": "esbuild server.ts --bundle --platform=node --outfile=server-out.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "esbuild": "0.17.17",
    "express": "^4.18.2"
  },
  "devDependencies": {
    "@types/express": "^4.17.17",
    "@types/node": "^18.15.7",
    "typescript": "^5.0.2"
  }
}

Please note the build script. Esbuild will take our .ts file and bundle it with our dependencies into a single .js file server-out.js. You can actually run this file once it is created using node server-out.js to check if the bundling was done correctly.

We then define our tsconfig.json

tsconfig.json

{
  "compilerOptions": {
    "target": "es2022",
    "lib": ["es2022"],
    "module": "commonjs",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "skipLibCheck": true
  }
}

We now define our sea-config.json file.

This is a configuration file building a blob that can be injected into the single executable application (see Generating single executable preparation blobs for details)

sea-config.json

{
  "main": "server-out.js",
  "output": "sea-prep.blob"
}

Now that we have everything we need, we can begin putting together our single executable.

Creating the Single Binary File

Begin by installing all the dependencies we’ll need by running this command:

npm install

Once npm install is completed, we run the command:

npm run build

This will create our server-out.js which will be our bundled file we will make into an executable.

Note: If you rather, you can follow the instructions from the Node.js guide starting from step 3 as the following steps will be exactly the same, located here: https://nodejs.org/api/single-executable-applications.html

Generate the blob to be injected:

node --experimental-sea-config sea-config.json

Create a copy of the node executable and name it according to your needs:

cp $(command -v node) server

Note: If you are on a Linux Distro (such as Ubuntu), you can skip the next steps and move straight to running the binary.

Remove the signature of the binary:

On macOS:

codesign --remove-signature server

On Windows (optional):
signtool can be used from the installed Windows SDK. If this step is skipped, ignore any signature-related warning from postject.

signtool remove /s server

Inject the blob into the copied binary by running postject with the following options:

server - The name of the copy of the node executable created in step 2.
NODE_SEA_BLOB - The name of the resource / note / section in the binary where the contents of the blob will be stored. sea-prep.blob - The name of the blob created in step 1.
--sentinel-fuse NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2 - The fuse used by the Node.js project to detect if a file has been injected.
--macho-segment-name NODE_SEA (only needed on macOS) - The name of the segment in the binary where the contents of the blob will be stored.

To summarize, here is the required command for each platform:

On systems other than macOS:

npx postject server NODE_SEA_BLOB sea-prep.blob \
    --sentinel-fuse NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2

On macOS:

npx postject server NODE_SEA_BLOB sea-prep.blob \
    --sentinel-fuse NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2 \
    --macho-segment-name NODE_SEA

Sign the binary:

On macOS:

codesign --sign - server

On Windows (optional):
A certificate needs to be present for this to work. However, the unsigned binary would still be runnable.

signtool sign /fd SHA256 server

Run the binary:

./server

You should now have a running Node server similar if you just ran node server-out.js

If you wanted to see a completed example, go here: https://github.com/chadstewart/ts-node-executable-article-example

If you found this article interesting, please feel free to heart this article!
If you’re interested in learning more about Front-End Engineering, follow me here on Dev.to and Twitter
If you’re looking for jobs, I’d highly recommend checking out @TechIsHiring on Twitter, LinkedIn or TechIsHiring's website https://www.TechIsHiring.com/ for posted jobs and other resources!
Want to check out a curated list of jobs, job seekers and resources from TechIsHiring? Check out TechIsHiring's Newsletter

Prioritization while making progress

Chad R. Stewart — Fri, 25 Nov 2022 00:38:43 +0000

Introduction

I wanted to quickly follow up on the making progress article because I realized recently that there was something missing from my approach.

So I mentioned how to make tasks that will help you reach your goals but I didn’t say how to prioritize them. Effectively, all the tasks you come up with would have equal weight and it would be expected that you complete as many of them as you can each week. This doesn’t take into account their importance or their likeliness to move you towards your goals. So I wanted to talk about this quickly as supplemental information.

What is Prioritization

So prioritization is the act of identifying what are the most impactful things you could do with the time you have. For example, you have a list of tasks as a Software Developer. You could fix a bug that could potentially cause an outage or you could work on a new feature. You are confident the feature can add new users to your software but you’ve identified that the likelihood of the bug to occur is pretty high. So you decide to immediately work on fixing the bug. Situations may not be as straight-forward as this example but this gives you an idea of what this would look like.

How to Prioritize

So how do you prioritize your tasks? Honestly, I’m pretty new to doing this myself so I’m primarily going to defer to Kun The Engineer who created a video on this topic:

How to do Prioritization as a Software Engineer (From L8 SWE at Microsoft)

In this video, Kun talks about the importance of prioritization as an Engineering Leader and then gives a process on how to prioritize tasks. To give a quick synopsis of the video, he proposes using a system which he mentioned has been battle-tested by several teams and has been shown to be very effective. The system is Priority = Impact x Confidence / Cost. Impact here being the value of the activity being successful, Confidence is how confident you are in being able to accomplish the task and Cost being the estimated amount of time (this example is in days) it would take to attempt to complete the task. I don’t want to take too much away from the video, I highly recommend watching it as he does a great job of explaining the system by going through an example.

He also has a worksheet that he shares in his blog on this topic which you can find here.

Image of worksheet in action calculating a priority after describing a cost, impact and confidence

The reason why I wanted to point this out is I realized that this process works very nicely with the habits I talk about in planning for your week in the previous article. While the example he works on is more long-term, it can be used for more short-term goals. The main strength here is the addition of data. Personally I make a list every week to say what I need to do each week and I’ll be adding the work I did to come up with my prioritization. While the data is far from precise, it’ll give me an idea of the types of tasks I’m taking on in terms of impact and this’ll give me an idea if I need to switch my focus to something else.

Conclusion

So I just wanted to touch on this quickly cause I think this would be a great addition to what I had talked about earlier. I am still learning myself but this is definitely an important skill to point out and so I wanted to share this with everyone as well!

If you found this article interesting, please feel free to heart this article!
If you’re interested in learning more about Front-End Engineering, follow me here on Dev.to and Twitter.
If you’re looking for jobs, I’d highly recommend checking out @TechIsHiring on Twitter, LinkedIn or TechIsHiring's new website https://www.TechIsHiring.com/ for posted jobs and other resources!

Making Progress: How I've learned to move towards my goals

Chad R. Stewart — Fri, 18 Nov 2022 01:11:56 +0000

Introduction

Sometimes you have plans that you want to move towards, long term career goals, short term career goals but you can’t seem to make progress on them. I was definitely in that position for years honestly. It really took a lot of understanding my pitfalls and setbacks then having a lot of revelation moments to get to a point where I can consistently make progress. I don’t want to say my system is a magic bullet, in fact, my system likely won’t completely work for you. What I want to do here is talk about the insights I came across as I finally came to something that worked for me. Hopefully those insights and examples of me leveraging them will help you start to make progress consistently.

So the key things I find useful are:

Having a long-term goal, a vision of your perfect future
Knowing what you want to achieve in the short-term to move towards your long term goal
Planning your weekly to help facilitate your short-term goals
Building the habit of executing day to day

This is skipping a few steps forward but the most important insight I came across is that you don’t need to spend your entire day grinding. Want to know why or know more about how you structure your day so you don’t have to grind? Keep reading to find out!

Have a Long Term Vision

Having a long-term vision is very important to making progress towards something. How do you know if you’ve made progress if you don’t have a clear idea of what the end is? Cal Newport, author of ‘So good they can’t ignore you’, talks about the idea of envisioning a lifestyle that you want. What do you want your future to look like? Live in the city, go out and take in the city’s culture? Live out in the country-side? Be with nature? Figure that out and then work backwards to find the things that you need to do to achieve that.

This isn’t meant to say that the above is exactly how you should make your long-term goal, but stressing that you have one and the benefits is just like the above says. It gives you an idea of how to work towards them just by having them. This doesn’t mean they won’t change but having a North Star helps you make progress towards it. So when should you revisit your goals? There isn’t a set time frame but it shouldn’t be regularly. Maybe every few months or so as life happens. Things will come up or you’ll change and maybe your vision you made no longer serves you. That’s okay, make changes if you need to. It’s there to be a guide, rather than be an anchor so treat it as such.

My long-term plans:

This is my long-term plan which I keep in a document under career vision:

Primary Career Vision: To gain the freedom to work on whatever projects I want
Secondary Vision: Move to the US to build large software systems and join a strong dev community

If you’ve been to my Twitter profile, you’d likely have seen a tweet saying that I’ll move to the US this year. As of the time of this writing, that’s likely not gonna happen but it guides me to make decisions towards that goal. I honestly revise this plan more often than I should but it gives me a great idea of what I should be focusing on.

Have Short Term Goals that support your vision

A long-term plan is usually that, long-term. It could be years before you’re in the position to achieve that goal, even if it’s more modest. It’s easy to fantasize about our goal and think we’re working towards it but rarely make any real progress. We need something to keep us more accountable towards our long-term goals. This is where short-term goals come in.

Short-Term goals are what we want to achieve in a given time period. Where long-term goals tell us why we want to win the war, short-term goals are the strategy of how we will go about winning it. Let’s take some of my examples above and expand on them. Want to live in a big city? You’ll need a well paying job to live comfortably there. Software Engineering is a well-paying job. I guess that means you’ll need to learn to code. Well I think I can feel comfortable writing code in 3 months so let’s go with that. There might be some exaggeration or missing nuance here but that’s the basic idea. From your long-term goal, you can see where you are now and what you’ll need to make progress. You don’t need an entire road map, you just need something you can realistically achieve in a time period you’re comfortable with.

My Short-Term Goals (Quarterly):

I try to set a theme for my Quarterly Goals so that they’re easier to reason about:

Theme: Optimize for building lasting relationships: “It’s not who you know, it’s who knows you.”

I heard the saying from Brian Douglas (@bdougieyo) and have decided to structure my quarter around it. So the idea is to build stronger relationships in the tech community. I do have a fair amount of relationships currently but I feel they aren’t as strong as I’d like them to be. I’m not very good at managing relationships honestly and so I want to put more effort into that.

Have a Weekly Plan

Okay, so let’s continue leveraging our Software Engineer example. We decided we can get comfortable coding in 3 months but how do we plan to do that? I have no clue how to code now! Okay, I looked around and there are some pretty cheap courses on Udemy. I’ll buy the most popular and go with that. Okay, bought it! I’ll just try to go through these videos until I finish it!

So using the example above (as an example as I’m sure people will find flaws in learning coding this way), we’ve come to the conclusion that going through videos until we finish is a sound strategy. If this wasn’t a Udemy course that tracks your progress, you’ll need a way to know what you’re doing and what you’ve done. This is where a weekly plan comes in. Idea here is to capture everything you need to do for the week and keep it top of mind so that you can remember to accomplish it. In our above example, we can add the specific videos we want to go through to our weekly plan and check them off as we complete them. The weekly plan is also really flexible too so as the week goes on and things come up, you can add them there as well.

A key thing to do with your weekly plan is to make sure you’re checking things off as you complete them. This does two things: First, you’re getting a dopamine hit every time you check off a task and you’ll build the habit and the craving of that dopamine hit for checking tasks off your plan. This is critical to building up the habit of wanting to accomplish tasks. Second, if you miss any tasks, they can be easily tracked and transferred over to the next week. You can even over time see what type of tasks tend to get carried over and you can make adjustments there.

So in previous sections, I tried to keep the terms from being time-specific. I honestly don’t have a better name for this section because I personally use a weekly plan. The main idea here is to be able to take your short-term goals and split them into ACTIONABLE things you can do during the week. Where the short-term plans are your strategy for winning the war, your weekly plan (and the next section about your day to day) will make up your tactics and things you repeat to win the war. I’m sure there are other systems out there that accomplish the same thing but the spirit is that you just need a way to generate actionable things from your quarterly plan that you can complete, feel good about it and move to the next one.

My Weekly Plan (Nov 14 - Nov 18, 2022):

Plans for this week:

Begin practicing DSA Interviews
Update Twitter bot with v2 stream ✔
Work on Accessibility issues on TechIsHiring ✔

Plans for next week:
Update Design System to show more interactions for components

The above isn’t my complete plan for this week but it’ll do great as an example. Also missing is I try to keep the theme for the quarter in my weekly plan doc so that I know if I’m working towards my goals or not. While there isn’t anything specific here that goes towards my quarterly goals, practicing DSA will help with long-term goals as I’ll likely be doing DSA interviews to get into companies that’ll offer H1-B support. Notice I have a section for next week as well just so I can capture things I need to do but I don’t need to think about working on them now. Also notice the ticks for completed tasks. Especially when you’re just starting, you’ll feel great adding those ticks to things so don’t neglect it!

Build a Day to Day Habit of Execution

So remember at the beginning of this article, I said the most important insight I came across is that you don’t need to grind every day? Well let me explain.

You only really need 1 - 2 hours of focused uninterrupted effort each day on the most important things to make significant progress on your goals.

I can only give you anecdotal evidence but I’ve been leveraging this mindset for the last few months and have made so much progress towards my goals! So the main idea for having a small amount of time of focused effort is to favor consistency over speed. 1 - 2 hours is much more doable long-term by a lot of people rather than potentially 5 - 6 hours daily. Finding 5 - 6 hours a day, even broken up is very difficult especially for those with responsibilities. Then there’s the actual mental strain of maintaining focus over such a long time, even broken up. It’s usually not sustainable. This isn’t to say “DO NOT DO THIS!” but letting people know that it’s okay to put in 1 - 2 hours on your most important tasks because over a long period of time, it’ll definitely compound!

I want to stress that the time should be UNINTERRUPTED. This is very important because the effort to context switch from one task to another will steal time away from what you’ve allocated and you’ll end up getting less work done overall. This means you’ll need to find some time during the day where you can sit down for long periods of time without an issue. For most people with obligations, this usually means early in the morning when you wake up or late at night right before going to bed. Also important is to reduce the amount of things that can also interrupt you. Working at 9 pm for 2 hours is no good if your phone is constantly ringing and interrupting you. Silence your phone and close whatever apps and windows that’ll buzz you while you work. You want to be closed off from the world virtually for this time period.

So say you can find 2 hours of uninterrupted time during your day, you now want to structure your tasks throughout the week to fit within this window. Using our Udemy example, we would want to go through videos for up to 2 hours per day. The reason for this is that you want to be able to add that check to your tasks at the end of each 2 hour period per day. Spend 2 hours working, add check, get dopamine reward. This cycle will drive you to getting work done and eventually taking on more and more ambitious tasks. Just remember though, you want to make progress so you can add that check. If a task is too large, break it down into smaller tasks that are accomplishable in the 2 hour period so you can add your check.

Quick note, if adding a check isn’t enough of a reward to motivate you to continue, feel free to do something else. Reward yourself with watching TV, playing video games, ice cream, whatever your fun activity of choice is. The most important thing is that you put in focus effort and your brain recognizes that it’ll be rewarded for doing that.

One other note. This does not mean you ONLY work during your 2 hour time period. That period is for focused work on your most important tasks. You’ll likely have a lot of administrative and small tasks you need to accomplish as well (hopefully captured in your weekly plan). The important thing here is that the things that add the most value for you should be worked on during your focused period because they are important. All the mundane things can be worked on throughout the rest of your day. Hopefully those things aren’t too extensive but you may have a fair amount of day left outside of your other obligations to complete these other things.

My Day to Day:

So I referenced 2 hours quite often in this section so it’s safe to assume that I spend 2 hours each day of focused effort and you’d be right. I prefer earlier in the morning to do my work so I tend to start my work at 8 am. I don’t have too many obligations so that’s a reasonable time for me but I’ve definitely found myself waking up at 4:30 am to start my personal work at 5 am.

This is a typical day on my calendar:

I call my periods of focus ‘Deep Work’ from Cal Newport’s books and the idea is that I work on the most important things to me in that period. You’ll notice that I have two periods, one called ‘Logical Work’ and another called ‘Insight Work’. The idea is as a Software Engineer, I primarily do my coding during the ‘Logical period’. I’ll do my writing, such as this article, during my ‘Insight period’. Technically means I do 3 hours of focused work but I’m more lenient on skipping writing. I also have a tendency to go more than the time I allotted because I don’t have the restraint of other responsibilities to attend to. For instance, I have written most of this article in one sitting which took me about 2 and a half hours. Regardless, it’s the spirit of the system rather than the system itself. It’s there to make executing more consistently over a long period of time easier.

Conclusion

So let’s recap. You have a long-term vision that you want to strive towards. That long-term vision informs what you need to do in the short-term to move towards that vision. You then use your short-term goals to help determine what to accomplish for the week and you spend 2 hours of focused uninterrupted time each day trying to accomplish your major tasks and you fit in the other tasks where you can.

I might not have mentioned this but the most important part of this is the day to day and identifying your tasks each week. It’s the habit of getting up and making progress each day and having a consistent flow of relevant things to accomplish that’ll get you towards your goal.

One other thing, none of specific tips are set in stone. A lot of these came from my own reading and what worked for me. The most important takeaway from this is the general idea of the overall system, how they feed into each other and how you can build something similar yourself with the same ideas.

Adapt these ideas to what best fits you!

If you found this article interesting, please feel free to heart this article!
If you’re interested in learning more about Front-End Engineering, follow me here on Dev.to and Twitter.
If you’re looking for jobs, I’d highly recommend checking out @TechIsHiring on Twitter, LinkedIn or TechIsHiring's new website https://www.TechIsHiring.com/ for posted jobs and other resources!

Setup a CI / CD process to automatically deploy Storybook in your project to Vercel

Chad R. Stewart — Tue, 08 Nov 2022 23:09:34 +0000

So you’ve set up a project, deployed it on Vervel, installed Storybook and have been writing stories for your components. Great job! You've taken a huge step forward in creating and documenting your design system! But what if you want to deploy it on Vercel alongside your project? You'll learn to do that here.

Prerequisites:

Have a project set up with Storybook
Pushed that project to a GitHub repo
That GitHub repo can use GitHub actions
Have a Vercel account already deploying the project

Outline

Setup Storybook Vercel deployment branch
Create a new domain to the Storybook deployment
Set up GitHub actions to automatically merge to Storybook branch

Setup Storybook Vercel deployment branch

Vercel by default will automatically deploy a project when a new commit is pushed to the branch it's watching. We plan to leverage that behavior to update Storybook when new changes are made.

First, from the main branch of your project, create a new branch called 'storybook-deploy". In that branch, you want to insert this file:

vercel.json



{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "buildCommand": "npm run build-storybook",
  "devCommand": "npm run storybook",
  "installCommand": "npm ci",
  "framework": null,
  "outputDirectory": "./storybook-static"
}

The above file will override the default deployment process and deploy Storybook when it sees this file. The storybook-deploy branch is now ready!

Point a domain to the Storybook branch

Now go to your Vercel account and point a domain to the storybook-deploy branch that was created on GitHub. Here's an example below:

Set up GitHub actions to automatically merge to Storybook branch

We will now need to leverage GitHub Actions to automatically push code to the storybook-deploy branch whenever new code is committed which will cause Vercel to auto deploy it. Going back to the main branch of the project, add this file to the root directory of your project:

.github/workflows/storybook.yml



name: Build and Deploy Storybook
on: 
  push:
    branches:
      - 'dev' # Trigger the action only pushed to a specific branch
      - '!main' # Ignore if pushed to a specific branch
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout 🛎️
        uses: actions/checkout@v2.3.1

      - name: Merge dev -> storybook-deploy 🚀
        uses: devmasx/merge-branch@1.4.0
        with:
          type: now
          from_branch: dev
          target_branch: storybook-deploy
          github_token: ${{ github.token }}

The above file will automatically merge the main branch into the storybook-deploy. This will then trigger a deploy from Vercel with the deployment configuration that was applied. Now that this is added to your project, push your code to your main branch. The GitHub action should now push it the branch to storybook-deploy and Vercel will now trigger a deploy. Please note that deploying a Storybook can take a few minutes.

Now you've set up automatic deployment of your Storybook whenever a push is made to your main branch!

If you found this article interesting, please feel free to heart this article!
If you’re interested in learning more about Front-End Engineering, follow me here on Dev.to and Twitter.
If you’re looking for jobs, I’d highly recommend checking out @TechIsHiring on Twitter, LinkedIn or TechIsHiring's new website https://www.TechIsHiring.com/ for posted jobs and other resources!

The lessons learned: The Story of #TechIsHiring part 3

Chad R. Stewart — Mon, 07 Nov 2022 23:10:00 +0000

Introduction

In the last article, we talked about the work that went into building the current value of TechIsHiring and a few hurdles that comes from running a hashtag.

Lessons Learned

Despite any problems with running TechIsHiring, running and maintaining this has been one of the best decisions I’ve made for my career. I’ve met so many people through maintaining this and have been asked to speak on several topics because of my association with the hashtag. And it all really stemmed from being willing to spend some time to go out and help people find opportunity, even if that just meant poking around Twitter and finding tweets and just retweeting them.

I think there are a few key lessons I took from TechIsHiring and it’s maintenance that is very applicable to others trying to break into the Tech Industry:

Give Back: One of the things TechIsHiring has really taught me that one of the best ways to build your career is to give back to the Tech Community. Giving back to the community helps put your name out there and does so in a way that’s positive. People will see that and will be more interested in reaching out and offering your opportunities. I’ve definitely been offered much more opportunities than I think I really deserved honestly. One caveat though, you need to be giving back in public. You can’t be in a corner working on ‘the next big thing’ and then expect all of this great stuff to happen once you release it. People respond to the journey more than the destination so let others follow you along on that journey. You’ll be so glad you did!
You don’t have to start big: TechIsHiring started as a Twitter hashtag, nothing more. There was no account or newsletter or anything. I just had my phone and I retweeted jobs I found. I still do this today. How you give back doesn’t need to be elaborate or needs to be this great big thing. Do something that people find beneficial and you’ll be surprised how much people will react positively to you!
Seek feedback: A quick follow up to the previous point is actively for feedback. As you’re working, reach out to people and get their opinion on what you’re doing and how you could be doing better. TechIsHiring wouldn’t be the way it is today without the feedback of several people who were only interested in helping me do better. If you’ve been doing something for a while, people will be much more willing to give you some feedback and help you along, if only to be able to say they were a part of your journey!
Don’t underestimate the technical need for what you pursue: This advice is specifically for those in or are seeking Engineering roles. I’ve said this a few times before but TechIsHiring was just a hashtag starting out. Since then, I’ve built a Twitter bot which I had to update and built a website for TechIsHiring. All of these solutions needed to be deployed on some form of infrastructure to keep them running. A concern I had as I worked on TechIsHiring is that there wasn’t much of a technical need since I was just retweeting with a hashtag. I’ve since had to bring a fair amount of my Software Engineering skills and experience to solve some of the technical problems TechIsHiring has faced. Don’t underestimate the technical need for whatever you decide to pursue. There are many stories of someone solving a particular problem with a weekend project that turned into their day job or even their life’s work. You’d be surprised how something so simple as, “I need a website,” can balloon to interesting and engaging technical solutions! Just remember to do this work in public!
Be persistent: The most important thing that TechIsHiring has taught me was the value of being persistent. Showing up every day, regardless of the quality of the work done, is significantly better than showing up and doing your absolute best work ONLY ONCE! This has been a slow grind and continues to be a slow grind but being persistent definitely pays off. Set yourself up to be able to put in some form of work consistently and over time that work will compound on itself. If you take nothing away from this, please take that!

Conclusion

And that’s really it. That’s the story of how I came to let everyone know that TechIsHiring! It’s been an interesting journey and I honestly did not think I would have ended up being a part of something like this. But I really am enjoying the ride and looking forward to seeing what this journey brings!

If you found this article interesting, please feel free to heart this article!
If you’re interested in learning more about Front-End Engineering, follow me here on Dev.to and Twitter.
If you’re looking for jobs, I’d highly recommend checking out @TechIsHiring on Twitter, LinkedIn or TechIsHiring's new website https://www.TechIsHiring.com/ for posted jobs and other resources!

Building value in TechIsHiring: The story of #TechIsHiring part 2

Chad R. Stewart — Thu, 03 Nov 2022 22:08:36 +0000

Introduction

When we last left off, I had just founded TechIsHiring and now had to figure out how to get TechIsHiring into a state where people would be interested in using it.

Construction starts

So there were two main concerns I had early on. Outside of the few people who may have voted on the poll or had seen my tweet about the hashtag, no one knew what TechIsHiring was. The second concern was the value of the hashtag itself. The hashtag had no more or less nothing in it so why would anyone want to check it consistently much less contribute to it? While adoption was a problem (and one I continue to struggle with), I felt increasing the value proposition of the hashtag was the best thing for me to do.

So how do I do that? Well just go find job seeker tweets and job tweets and quote-tweet them with #TechIsHiring. I would do this at least once, Monday thru Friday for the next 8 months.

Very early on in TechIsHiring’s life, I made the conscious decision to refrain from retweeting tweets I didn’t have permission to do, something I continue to try to do to this day. If anyone follows me has seen this from me AT LEAST ONCE:

At this point, it might as well make a business card out of it, it’s probably more recognizable than I am. I’ve definitely received a few criticisms for this though nothing really malicious. For me, even though it’s technically public domain, it’s really about respecting other people’s space, virtual or otherwise. This is just an attempt to uphold that philosophy as best as I can.

The actual TechIsHiring account came a few months after I started posting the hashtag regularly. I knew I needed an account for the hashtag to be more effective and a bot to consistently retweet the hashtag but honestly was dragging my feet on it. It wasn’t until John Croston really pressured me into creating the account did I really go and do it. The bot came quickly after, mostly because I didn’t want to have to retweet everything myself. I ended up poking through a few bots that were already implemented and just adapted one I was satisfied with to retweet the hashtag. Learned a fair amount about Twitter’s API playing around with it and about Heroku when I finally got it deployed. The early version wasn’t great but the cobbled together code did what it needed to do so I didn’t complain too much. Here's a link to the repo of the first TechIsHiring Twitter bot: https://github.com/chadstewart/Tech-Is-Hiring-Twitter-Bot

So now I had a place where people’s tweets would live. It wasn’t branded at all and wasn’t pretty but at least it was something.

Gaining momentum

Once the TechIsHiring account got made and the bot was actively retweeting posts, it was significantly easier to see how the hashtag was growing. Growth was slow but steady, fueled mainly through my consistent posting to the hashtag with valuable posts. Growth stayed this way for a few months until close to the end of the year 2021.

It started with me initially hosting a Twitter Space to ask about what TechIsHiring could do to better serve the community. Twitter Spaces had been open to the public for maybe a month or so and I felt it was an active way for me to engage with the community and get feedback. Ironically, I didn’t get too much feedback to push the hashtag forward but I ended up realizing that Twitter Spaces might be a great way of engaging with the community in general. So I started hosting Twitter Spaces more regularly, focusing on topics that I thought people would be interested in talking about. More and more people would come into the Twitter Space and we’d have great discussions on these topics. Then other people started reaching out to me.

The first was Brian Douglas of Open Sauced and GitHub. He had reached out to request that I come to speak in some of the Twitter Spaces he wanted to host. Not only would he host the Twitter Space, he also agreed to put up the TechIsHiring hashtag in the space. Why this was important was because when Twitter Spaces are shared, the hashtags in them are automatically added to the tweet they are shared in. This was the first time I really learned of the power of being tied to a strong event. Both TechIsHiring’s engagement and my own engagement grew as a result of these Twitter Spaces.

The second was actually a few months later with Sham and Temz of Tech__UK. They came from Clubhouse to host job hunting Twitter Spaces like they had done previously. Sham actually was the person who reached out to me mainly to leverage the TechIsHiring hashtag. They began hosting the same type of job searching Twitter Spaces like they did in Clubhouse but they were now added the #TechIsHiring hashtag to their space. That each time that space would happen, it would get retweeted constantly and each retweet would have the TechIsHiring hashtag. It technically was kind of spammy but it was extremely effective in getting engagement for the hashtag. So much so that there was a point where TechIsHiring was trending on Twitter. It was absolutely amazing!

These were some of the things that really grew the hashtag to what it was today. While these events were important, I think the most important attribute was just my own dedication to the hashtag and to trying to get valuable posts into it.

While not directly related to the hashtag’s growth, TechIsHiring started releasing a newsletter every week. This newsletter focused on promoting interesting jobs, job seekers and other interesting advice and information from the hashtag for that week. The idea actually came from Veni from Diversity Tech when I reached out to her on how to grow TechIsHiring.

Growing pains

So while TechIsHiring has experienced a fair amount of growth, that growth has come with some challenges as well. One of the main challenges of running a hashtag, especially one that is being powered by a Twitter bot that is indiscriminate about what it retweets, is spam. Early in TechIsHiring’s life, spam was simply not a problem though that was also because engagement was still low. As the hashtag’s popularity grew, the tendency for spam did too. For the hashtag itself, it wasn’t too much of a problem and honestly is something that can’t really be solved but for the account that is actively retweeting #TechIsHiring tweets, it was problematic but also solvable. From a technical perspective, what needed to happen was to have some form of banned or restricted list and those on that list would not get retweeted. The initial version was crude and was a pain to manage but got the job done initially. That was eventually updated to be significantly more manageable. If you’re interested in a deep dive of how the TechIsHiring Twitter bot got updated, check out this article: https://dev.to/chad_r_stewart/migrating-the-techishiring-twitter-bot-42fm.

Next time, we wrap up and talk about the continued success of TechIsHiring and some of the things I've learned from this experience!

If you found this article interesting, please feel free to heart this article!
If you’re interested in learning more about Front-End Engineering, follow me here on Dev.to and Twitter.
If you’re looking for jobs, I’d highly recommend checking out @TechIsHiring on Twitter, LinkedIn or TechIsHiring's new website https://www.TechIsHiring.com/ for posted jobs and other resources!

From job seeker to building bridges for other job seekers: The story of #TechIsHiring Part 1

Chad R. Stewart — Mon, 31 Oct 2022 22:36:12 +0000

Introduction

As of this writing, TechIsHiring is a year and a half old. It currently has 11,000+ followers on Twitter, a little over 1,000 followers on LinkedIn and has a newsletter with 750+ subscribers. This is probably the most impactful thing I’ve ever done and most certainly the most impactful thing I currently maintain. As Nerando said in the image above, I managed to turn my job search into a product.

And it was a happy accident!

TechIsHiring was born from a question I randomly asked #TechTwitter one day almost two years ago and after some minor encouragement, I decided that I’d try to put this thing together. A lot of the ideas that make up TechIsHiring currently weren’t even mine honestly. The newsletter came from Veni Kunche, the account itself and the bot was something I dragged my feet on until John Croston pushed me to do so. The branding that exists today only came to be because Brian Douglas insisted that I fix the account page. All I did was come up with the name, and ironically #TechTwitter rejected it in a poll. A collection of happy accidents and good luck makes TechIsHiring what it is today.

Want to hear how these came to be? Okay, let’s start at what started all this. My pandemic job search.

Job Searching is Tough

In February 2020, I had left a previous role and took some time off before going back out on the grind. After my break, I had initially planned to travel to New York and spend some time with the Dev Community there (I didn’t know about TechTwitter at the time). I had family in New York I could stay with to make it affordable for myself and had saved up enough money to not die of hunger during my stay.

Little did I know that a global pandemic was getting ramped up.

By March of 2020, my plans were officially dashed as Jamaica entered lockdown. No flights were coming in and out the island and an island-wide curfew was in effect which would last the next 2 years. By this time, the US was well into its own lockdown process and I didn’t feel comfortable flying there anyhow. It was during this time I learned of @BekahHW and @VirtualCoffeeIO (before it got its official name). I spent a lot of time hanging out with a lot of the members there and attending events. A lot of the conversations were about job searching and trying to find a job as a beginner. This really pushed me to really start my job search again and after polishing up my resume and a quick review, off I went.

Summer 2020 felt like THE WORST time to job search as a foreign worker presenting themselves with only a year of experience (which is a whole other story(link to resume article)). I spent the better part of the year getting rejected from every company imaginable. Even companies that I had a connection with that worked there had absolutely no interest in me. It was a tough time and the only thing I could really think of doing was reworking my resume cause maybe I could spruce it up to make it better.

It was during this time that I noticed people making tweets about their job search. And so I tried to do the same as well and my tweet did well. I had a lot of people retweeting and liking my tweet and I had a few people reach out that were interested because of it. While I was unable to leverage the opportunities that I got, it did show me I could really leverage Twitter as a mechanism to find great opportunities.

My own job search had its highs and lows but I kept as best as I could.

Is there a space for job searching tweets?

Fast-forward to around April 2021. My job search hadn’t really improved but I kept at it, leveraging the new resource of people making job searching tweets to try and help my own search. It was then when I asked this question which changed my life:

To be 100% honest with you, I might not have followed up on this if it weren’t for someone reaching out and urging me to push forward with the idea. That person was @SpencerGTyson who decided that this was a great idea and that I should seriously pursue this. The poll to decide the original name was his idea:

As you probably noticed, TechIsHiring actually didn’t win that poll. So wha’ ha’ happen was, when I checked out #TechHireHere, I noticed there was a company using it. It was irregular but it was enough to deter me from the name. Also honestly, I liked #TechIsHiring more. And so after a bit of grumbling, I decided that I’d stake a claim to my new piece of digital land:

And that’s how TechIsHiring was born. Now the real challenge was to begin. How the hell was I going to get people to use this thing?

In the next article, I'll talk about actually attempting the grow the hashtag!

If you found this article interesting, please feel free to heart this article!
If you’re interested in learning more about Front-End Engineering, follow me here on Dev.to and Twitter.
If you’re looking for jobs, I’d highly recommend checking out @TechIsHiring on Twitter, LinkedIn or TechIsHiring's new website https://www.TechIsHiring.com/ for posted jobs and other resources!

Build Resilient UIs: Frontend Architecture that doesn't suck!

Chad R. Stewart — Tue, 25 Oct 2022 00:21:54 +0000

Introduction

Frontend code can get really complex really quickly. This comes from how we naturally tend to build webpages and how we tend to write CSS. Web Pages tend to be built from the top down where we define and style the page, then sections we want to work on, then the individual pieces of that section and so on. It’s easy to forgo good engineering practices and then end up building highly coupled components.

How can we deal with this in our frontend code and keep it more resilient? We can make strong architectural decisions early on in the project that benefit us as the project evolves.

OutLine

Benefits of thinking about Architecture early
Tools and methodologies I found beneficial
Loose Coupling
Component Driven Design
Atomic Design
Storybook
TypeScript
Tailwind CSS
Conclusion

Benefits of thinking about Architecture early

In most codebases the primary reason for the codebase becoming difficult to work with is the haphazard nature of writing frontend code. You start a project with the intention of solving a problem or getting a design on the page. You spend most of your time focusing on what renders in the browser that it’s very easy to forget to manage the codebase as well. I’ve seen greenfield projects become difficult to work on within a matter of a few weeks.

CSS also has the ability to add to significant coupling of our components by unintentionally applying CSS rules to components through poor selectors. Naming and selecting components is extremely important when writing good CSS. It’s very easy to write poor selectors that work for your particular use case and then when needing to extend your frontend code and its CSS, you find you have to code around your previous selectors. This quickly devolves into CSS spaghetti and you now spend more time trying to properly select your components in CSS than writing code that adds value. Even with component-based frameworks like React and Vue, this is how frontend codebases tend to evolve without proper care.

These types of problems can be avoided by making architectural decisions about your frontend code early in the project and sticking to them throughout its lifespan. Here’s an example of a project that made architectural decisions early on:

Quite early on a recent project I worked on, we started having discussions of the architecture of the frontend codebase. We decided to go with Atomic Design for how we created components and eventually we’d start to practice Component-Driven Development when writing components, building components in isolation using Storybook before putting them on the page. Within a month after setting up all the necessary infrastructure and getting used to our development process, development moved extremely quickly as we were leveraging the previously built components in our design system to move forward.
We eventually took on more work than we could really handle and we needed to bring on someone for help. This is generally a no-no in project management as it usually takes new people a long time to get ramped up and be productive on a project. In this circumstance though, the ramp up time for bringing on the new person was extremely small for two reasons:

The new person needed to build new frontend components but we built components in isolation before putting them on the page so they didn’t need to know the codebase well to add to it.
Because of Atomic Design and building components using Storybook, the components remained relatively isolated even in production and so even when putting them on the page, you didn’t need to interact with the rest of the codebase outside of the work you needed to do.

A few other people had contributed to the codebase as well with similar results, some of which were much junior in their coding experience but were able to contribute because of how the architecture made the codebase very approachable.

Tools and methodologies that I found beneficial

So I’d like to give you some concrete tools and ideas you can use to accomplish this. Here are some of the things that allowed the codebase in my story to be as resilient as it was:

Loose Coupling

A major architectural concept in software engineering. Loose coupling is a concept where the dependencies between different components are low. The benefit of this is if there is a change that needs to be made in a component, few other components would need to be changed as well. This helps isolate your components from each other, allowing changes to components as they need to be expanded upon to be much more frictionless. This also allows you to work on them in parallel without worrying about the implementation details of another developer’s work.

Every other concept or tool that I talk about will contribute to this and is the main philosophy why they were so effective.

Component Driven Design

An important frontend development concept. Frontend development tends to be top-down where we define the page first and then the elements within it. Component-Driven Design turns that idea on its head by focusing on working on the components (starting with the smallest) first and then putting the page together as the final step. This works particularly well because the smallest component such as buttons and text tends to get repeated when building top down. Building those first allows you to use them throughout the application without redefining them.

Where loose coupling is a rule we follow in architecture to keep our codebase resilient, Component-Driven Design helps enforce that rule as developing this way naturally leads to less coupled components.

Atomic Design

Atomic Design is a component design pattern by Brad Frost defined in the early 2010s. The concept is each component falls into the categories of atoms, the smallest components, molecules, made up of multiple atoms, organisms, made up of atoms and molecules and pages which are made up of the 3 previously described categories.

Image from Brad Frost's blog post on Atomic Design, illustrating how the different components relate to each other

Where Component-Driven Design tells us how we construct pages, Atomic Design tells us how components relate to one another.

Folder Structure of an Atomic Design Project

This and Component-Driven Design are what we will mainly use to keep our frontend codebase loosely coupled,making it extremely resilient.

Storybook

Storybook is a tool used to document Design Systems, each instance of a frontend component and the varying states it can be in being called stories. Storybook focuses mainly on the visual aspect of frontend components, allowing you to see how components are rendered and see their different states and what actions they have.

Screenshot of Storybook

The three previous concepts we talk about, the frontend code itself and other tools necessary to run that code will come together to form a Design System which can be documented in Storybook. While documenting the Design System is important and should be done, the power of Storybook for our purposes is that you can develop components in isolation of the rest of the system. This helps enforce the loose coupling throughout the codebase by forcing Developers to put together components that do not need to rely on the rest of the system to run. The second benefit is you are automatically documenting, at minimum, a new component in the Design System as you develop new components.

TypeScript

TypeScript is a language built on top of JavaScript, built with the intention of adding static-types to JavaScript. While not 100% necessary, for larger projects or projects you expect to grow large, TypeScript becomes invaluable especially paired with Atomic Design and Component-Driven Design. As you build out components, these components may need specific data. With a large enough set of components of various uses, it's easy to forget something the component needs or accidentally add something the component wasn't expecting.

TypeScript does a great job of eliminating that particular issue by enforcing what a component expects when properly typed. Secondly, TypeScript also doubles as the first layer of documentation for your components. When leveraging your component, TypeScript will tell your IDE what your component expects which makes using components significantly easier.

Tailwind CSS

Tailwind CSS is a library that allows you to add prebuilt CSS rules by adding Tailwind classes to your markup. With this you no longer have to write CSS yourself, you just use a combination of Tailwind classes to get the styling you want.

Tailwind is likely the most controversial topic here but allow me to explain. CSS, when written poorly, tends to lead to more tightly coupled components in unexpected ways. It is also quite easy to write CSS poorly and to have that coupling make itself known when you least expect it. This is mainly through the selection of HTML elements to add styling rules to. Tailwind effectively eliminates that by forcing a Developer to leverage predetermined styling rules which are applied by adding classes. Because of this, there is rarely any need to attempt to select HTML elements to apply styling and thus you don’t write poorly written CSS selectors.

Additionally, this now keeps all your presentation logic in a single file, leading to high cohesion, where related items are packaged together which in this case would be the presentation logic.

Screenshot of code using traditional CSS showing a CSS file in the component folder

Screenshot of CSS file found in above image

Versus...

Screenshot of code using Tailwind CSS showing component folder without a CSS file

*Note: If you rather not use Tailwind there are two alternatives that come to mind in terms of this idea. The first is leveraging Styled Components. You get to write CSS rules but you still avoid writing CSS Selectors. This I feel is an acceptable middleground. The second is simply learning to write better CSS and in turn writing better CSS Selectors.

One other thing I want to briefly touch on is keeping your presentation logic and business logic separate. My experience is mainly with React but how this manifested in my work was putting as much of the business logic in React Hooks and separate utils as possible. I’d also try to integrate hooks into the highest level component that needed the data. Such as if the highest level component was an organism, then the hook would output the data there and the organism would be responsible for distributing the data to the relevant components. While important, I feel this deserves its own article to expand on this further.

Conclusion

I have to openly admit that I stumbled across this entirely by accident. All I knew was the pain I suffered throughout previous codebases I worked in and these ideas I came across throughout my Front End Engineering career. Even then, I accidentally implemented them in one project and was self-aware enough to notice these benefits, only really defining how they worked together in writing this article. While all the tools described above will lead to a better codebase and a better developer experience, the main thing I want Engineers to take away from this is the concept of loosely coupled components and directly enforcing that through the choice of tools and development practices you decide to implement. I’m sure there are other ways to achieve this with tools and techniques I haven’t come across.

This article is inspired from the experience I wrote about here: Built a full feature in 6 hours: My experience on how the right tooling can improve your development velocity

Two talks I watched really help inform me on some of the concepts I speak about here:

If you found this article interesting, please feel free to heart this article!
If you’re interested in learning more about Front-End Engineering, follow me here on Dev.to and Twitter.
If you’re looking for jobs, I’d highly recommend checking out @TechIsHiring on Twitter or LinkedIn for posted jobs and other resources!

Access to UI Library props or hard-coded options in a Design System?

Chad R. Stewart — Tue, 18 Oct 2022 19:04:06 +0000

Quick Question: Would you rather have access to the props of a UI Library or have a dev hard-code options you select from when using components in a Design System?

So recently, I wrote an article about adding a wrapper around components from a UI library so you get access to the props from the UI library but you can customize the component before displaying it on the page. At the time, I thought this was the ultimate in component management. The more I think about it though, the more that might not be the best or simply not other Engineers' preference. So I wanted to post the question to everyone.

Please comment here or in the Twitter thread that this will appear in. Thanks so very much!

Migrating The TechIsHiring Twitter Bot to Twitter API v2

Chad R. Stewart — Mon, 17 Oct 2022 21:28:04 +0000

Introduction

TechIsHiring is a pretty lightweight organization and it doesn’t have much infrastructure. It does have one main thing though that is crucial to its operation, the TechIsHiring Twitter bot. The TechIsHiring Twitter bot retweets any tweet containing the string ‘#TechIsHiring’, which in turn makes the TechIsHiring Twitter account the main source of information on the hashtag. Our newsletter is also indirectly powered by the Twitter bot because it allows me to easily go through and find tweets using the Twitter account to put in the newsletter.

The TechIsHiring Twitter bot is easily the main reason for TechIsHiring going from nothing to over 10,000 followers on Twitter and having over 700 subscribers on our newsletter.

Outline

Why migrate the Twitter bot?
Updating the Twitter bot
Migration and Deployment
Conclusion

Why migrate the Twitter bot?

The TechIsHiring Twitter bot was initially deployed on Heroku Dynos on their free tier and has been in production for over a year and a half. In that time, not much has really changed from its original inception, really only needing to be updated as a few new problems came up as more eyes saw the hashtag and the Twitter account.

Unfortunately, Heroku has decided to end its free tier for Dynos and this pushed me to consider migrating the Twitter bot. Also with the consideration of migration, I felt updating the bot was also a good idea. I had grown significantly as a developer since its original development and there were some features that I wanted to add to handle some minor administration issues with the Twitter account.

So with that, I set out to update the Twitter bot and move it to a new home.

Updating the Twitter Bot

There are a few main technology changes made to the Twitter bot in it’s update:

Adding TypeScript
Moving from twit to twitter-api-v2
Updating how banning accounts work

The change of updating to TypeScript was one of the major changes the bot went through. At the time I had developed the original Twitter bot, it was written in JavaScript because I grabbed another project (this is the original project I leveraged: https://github.com/mayeedwin/twitterbot) and I honestly didn’t know any TypeScript at the time. While TypeScript didn’t provide too many advantages over JavaScript for this project, it made the migration from twit to twitter-api-v2 significantly easier.

The original project I used leveraged twit to bootstrap leveraging the Twitter API. While twit is a pretty good package, my main concern was that it hadn’t been updated in over 4 years as of the time of this writing and I was having a difficulty trying to figure out how to upgrade the bot’s ability to keep certain accounts from being retweeted using it so I felt the need to migrate away. After a bit of searching, I came across twitter-api-v2 which was the second go-to Twitter API package on npm so I felt this would work out. While it didn’t work exactly how I thought it would, it worked in the way I needed and I really appreciate using this package.

Let’s quickly circle back to a time during the original Twitter’s bot’s deployment. A few months into the bot being brought online, the TechIsHiring hashtag started to gain traction with several notable people starting to use it. The one of the more notable at the time (and whom I am eternally grateful for) is @Tech__UK. @Tech__UK was run at the time by @real_temz and @Sham_jab and they started hosting Twitter Spaces that would last several hours long. They would be so gratuitous to add the hashtag to their Twitter Spaces and several people would tweet the space to share it with their community. At the time, I had set notifications for the TechIsHiring account and for several hours I’d get notifications of people sharing the space, having 20 or 30 notifications by the time their space ended. There were so many people posting to the hashtag that it was trending on Twitter a few times. So you’d think the issue would be the bot tweeting so many notifications and having a problem with that? While there were minor issues there, the main issue and the thing I tried to actively solve for was spam.

With people seeing #TechIsHiring, a few people decided that it would be a good hashtag to start spamming. There were a few spam accounts that would send tweets about winning or entering a particular contest or something and they’d send that tweet several times, almost 20 or 30 times. This was a problem for a few weeks as I’d sit there and have to painstakingly unlike and unretweet each tweet by hand only to have them send even more a few minutes later. I initially tried to use some Twitter features to either block or report them but nothing seemed to help. They’d just keep on spamming the hashtag. I eventually decided that I’d have to update the bot to ignore these spam accounts. What I ended up doing was hardcoding a list of Twitter IDs that I would ignore to keep the account from being spammed. It's funny because in trying to implement that solution, I actually learned that I had to figure out if the tweet was just a regular tweet or a retweet so that I could properly check each ID and see if they were on the ban list. The implementation wasn’t the best but it worked for now. Its main failing is that to update the list, I would have to manually add a new Twitter ID to the list and redeploy the bot.

Now coming back to updating the Twitter bot, I wanted to also update the banning mechanism. After poking around, I realized that Twitter had an endpoint that would return a list of Twitter IDs based on accounts that were muted. Originally, I wanted to block the accounts and get a list of IDs from there but this turns out to be a better solution. They can still view the account but when they tweet, it wouldn’t show up. Twitter-api-v2 also made it easy to implement because they had a function that handled sending the request and getting the data back so there wasn’t much work needed from my end. The only other implementation detail that needed to be made was the actual check itself. Originally, I used the includes function in JavaScript arrays to check the IDs before posting. While the list is fairly small, I felt that was slow and could potentially be a performance issue if the list got much larger (though I don’t expect it to). I decided this time around I would put the array in a JavaScript set and use the has function for JavaScript sets which was a much faster lookup.

And with that I had updated the Twitter bot and had added the functionality of using the mute function of Twitter as a ban list I could leverage from Twitter’s UI.

Migration and Deployment

Now with the Twitter bot actually updated, I now needed to find a new place to run the bot. Heroku Dynos was free and I enjoyed not having to pay or really need to think about the bot for a year and a half so my initial requirements was that it was free. I also wanted to keep deployment and maintenance fairly simple as my infrastructure knowledge wasn’t particularly strong so my search started with ‘Heroku alternatives’. There were a few main options I explored:

Render
DigitalOcean
Fly.io
Railway
Staying on Heroku
AWS

I experimented with some of the above options, even getting as far as deploying on them before running into problems. This is when I learned the difference between ‘Web Service’ and ‘Background Worker’. You see I had deployed the bot as a worker on Heroku but didn’t realize what that meant. So several of the free tiers for the above services allowed you to run static sites or web services for free but they wouldn’t allow you to run a background worker for free which is what I needed to run the bot. I learned this fact trying to deploy to Render, seeing the app run and seeing it fail after a few moments of running. After some quick research, I learned the difference and what my needs were. I resigned myself to needing to pay for a service to run a background worker to run the Twitter bot.

I ultimately decided on DigitalOcean as out of all the options because they were my initial choice before finding out that I couldn’t run a service for free. I figured if I was going to pay for a bot, I’d do it with a more well-known service so it could pump up my resume a bit. I also had some previous experience with them and thought they would be a good fit. After a bit of messing around (the process was surprisingly simple), I deployed the bot and today it’s running on a DigitalOcean Droplet.

Conclusion

And that’s my journey to updating and Migrating the TechIsHiring Twitter bot. If you’re interested in viewing my work, check out the repo here:

https://github.com/TechIsHiring/techishiring-twitter-bot-v2

Feel free to critique my work or suggest changes. While the bot is currently meeting my needs, I wouldn’t mind playing around with things to update the bot though I don’t have any ideas. If you want to suggest ideas, please feel free to do so in this article or in the issues of the repo.

If you found this article interesting, please feel free to heart this article!
If you’re interested in learning more about Front-End Engineering, follow me here on Dev.to and Twitter.
If you’re looking for jobs, I’d highly recommend checking out @TechIsHiring on Twitter or LinkedIn for posted jobs and other resources!

Built a full feature in 6 hours: My experience on how the right tooling can improve your development velocity

Chad R. Stewart — Tue, 20 Sep 2022 00:24:09 +0000

Introduction

I’ve been a Front-End Engineer for several years now and have built a wide range of components for a variety of projects. In these various projects, I used different tooling to build components ranging from just having raw HTML, CSS and JavaScript to more modern tooling like React.js and the overall JavaScript ecosystem. Despite this, my development experience remained relatively the same while what mainly grew was the complexity of what I could build. That was until I built onboarding experiences for two different projects in the same year.

Here’s how tooling vastly changed my development experience and velocity.

Building the app.opensauced.pizza onboarding experience

For the first project’s onboarding experience, I was tasked to build something to replace the previous onboarding. The previous experience felt more disjointed and it was very easy for users to get lost and so another experience was designed and given to me to implement. A lot of the work was developing around the original page as I needed to insert the new experience into the previous page. The hardest part of delivering this project was working with the styling because of how the component was built initially and the general structure of the project. Styles were not packaged together with components and so understanding which style went with which component and adding new styles took a bit of time. It took me a few days and most of the time I spent wrestling with the CSS to get things just right.

Tools used for app.opensauced.pizza project:

Styled Components:

CSS was written in Styled Components. CSS can be tricky to work with including Styled Components because CSS tends to be written in a separate file than the markup you intend to use it in. This increases the cognitive load on the developer by forcing them to understand which CSS rules are applied to which component. If you were writing raw CSS then selecting the correct HTML element would be required and can also be painful but Styled Components allowed us to create the component with the Styles and just leverage it directly so we don’t have to deal with that.

React.js:

Want to note that this is a React 17 project. This doesn’t affect the experience directly as the other project I describe also leverages React 17, I wanted to bring this up for full transparency.

My overall experience working on app.opensauced.pizza:

This wasn’t that bad of an experience at all, just a standard Front-End development experience. The biggest difficulty was working with the CSS, using Styled Components and the locations of the styling. Outside of that, I’d say the experience was okay but uneventful.

Building the OpenSauced Insights Platform onboarding experience

For the second project, I was building an onboarding feature for a much more greenfield project. In this case, I was implementing an onboarding feature which was brand-new and was independent of any other design for the rest of the project so I had to spin up a new page to build it and so I got to work. Started a new page and quickly got to work styling the page. The interesting part of this onboarding experience was that the page was split into two where one half would track your progress in onboarding and the other half would change based on which step you were on. I remember starting the page at around 12 pm and working through it, quickly solving any problem that came up and progressing. A few hours later the page was completed. A few more hours of tweaking brought the total dev time to around 6 hours.

Tools used for OpenSauced Insights Platform project:

Component-Driven Design:

For this project we practiced Component-Driven Design. A quick synopsis would be that instead of building a page from top-level down, we build the components that make up the page first and then put them together like Legos. Component-Driven Design is best paired with a Design System that gives you a selection of components that you can use to put together pages quickly and make changes quickly.

Atomic Design Design System

To effectively leverage Component-Driven Design, we used the Atomic Design Design System to break up our components into atoms, molecules and organisms allowing us to get the Lego-feel of building components and ultimately assembling pages brick by brick.

Storybook:

To document our design system, we leverage Storybook in our project. This allows us to quickly look at what is available in our design system, assess what we need and put together components and ultimately pages quickly and easily. What we also do with Storybook is that the Storybook environment allows us to build components in isolation. Using Storybook, we can build components without interfering with the rest of the project and potentially introduce bugs or issues. Once we are confident in our components, we place them on the page where we need them and add the necessary data to power them.

Tailwind CSS:

Tailwind CSS makes styling a page quick and easy. Just apply the css class that you need and Tailwind classes will take care of the rest. Another key part of the benefit of Tailwind CSS is that it keeps your css isolated in the component that relies on it. This relieves one of the biggest pain points of CSS, accurately selecting and styling ONLY the classes YOU WANT. This is especially handy when you are building components in isolation in Storybook and having confidence your CSS won’t mess with the rest of the project once implemented.

TypeScript:

TypeScript and the intellisense that it gives through the proper use of types is probably the most valuable tools a developer could have when building a project with a very established design system. If a component is properly built, the component effectively documents itself and (depending on your IDE of choice) presents that documentation at the most crucial part of development, when you are actually implementing the component. This saves hours of development time in making sure you’re using the component correctly and reducing errors in implementation before it can get to production.

Next.js:

Our project is built with Next.js, which allows us to put together a Single-Page application quickly with all the tooling needed to make that application functional. While this has been invaluable in building the overall project quickly, it wasn’t a direct benefit in building this particular feature. For full transparency, our Next project leveraged React 17.

My overall experience working on the Insights Platform:

This was a far better Front-End development experience, from the time it took for me to complete this to its readability and maintainability. While this was a far more complex onboarding experience, the amount of code to make it work was comparable. It was 100 more lines of code than the previous experience but it was to build a completely new web page from scratch! Unlike the previous experience, styling wasn’t a pain point at all and honestly, I can’t think of any real pain points on this project. Probably the reason why I flew through it so quickly

Conclusion:

Overall, I love the dev experience with working with the tooling I am working with currently. I do feel I should bring up some caveats that I didn’t not cover in this post. While the new code I wrote was 100 more lines of code than my previous project, there was a lot more knowledge and infrastructure being brought to bear to complete this task that existed previously. Setting up that infrastructure and then getting used to that workflow takes time but let this story be an example of what you can accomplish and how quickly you can accomplish it with the right tools in place.

If you found this article interesting, please feel free to heart this article!
If you’re interested in learning more about Front-End Engineering, follow me here on Dev.to and Twitter.
If you’re interested in learning more about OpenSauced, follow OpenSauced here on Dev.to and on Twitter.

Set up a Next.js project with TypeScript, Tailwind and Storybook

Chad R. Stewart — Wed, 07 Sep 2022 19:14:50 +0000

Next.js is a popular framework built on top of React that allows users to build React applications quickly and easily. At OpenSauced, we are working on a new project that leverages Next.js and Tailwind CSS. For this project we also wanted to build a design system to support this project and, potentially in the future, other OpenSauced projects.

To that end, we also decided to leverage Storybook to document our design system. Unfortunately, setting up Storybook with Next.js and Tailwind is not trivial and it took us some time to get things working properly. This article is for those looking to stand up a similar project and need help setting things up.

Outline

Setting up the Next Tailwind CSS project
Installing Storybook
Configuring Storybook to use Tailwind
Configuring Storybook to use Next

Setting up the Next Tailwind CSS project

Thankfully this part is fairly simple. To stand up a new Next.js project with Tailwind, run this command:

npx create-next-app -e with-tailwindcss next-tailwind-storybook-example

Note: The last keyword will be the name of your project.

Create-next-app will stand up a new Next.js project in TypeScript with Tailwind already pre-installed. Once the setup is completed, you can navigate to the folder where your Next.js project has been set up and run the command npm run dev to start the Next.js dev server.

cd next-tailwind-storybook-example
npm run dev

This will let you view the project at localhost:3000 which will give you Next.js’s starter screen.

Installing Storybook

To set up Storybook within the Next.js project, run this command:

npx -y sb init --builder webpack5

This will initialize a new Storybook installation. It will automatically detect which type of application you are working on (in this case React) and install the necessary dependencies to get Storybook up and running.

Note: If you are using a version of npm above npm7, Storybook will ask if you would like to run the npm7 migration. Press ‘y’ to answer yes to run the migration. If you do not do this, you will have issues installing the other packages needed to continue this set up. If you skip this step by accident, run npx storybook@next automigrate to run the migration.

After the installation, you will be able to run Storybook. To run Storybook, use the command npm run storybook and open localhost:6006.

npm run storybook

Outside of necessary config files, Storybook gives you starter stories to give you an idea of how to use it. Unfortunately, Storybook is not configured to use Tailwind out of the box and so we have to manually set that up ourselves.

Configuring Storybook to use Tailwind

To use Tailwind in Storybook, you’ll need to install an addon so that Storybook knows how to use Tailwind. First, run this command to download the addon to your project:

npm i -D @storybook/addon-postcss

Once the download is completed, open .storybook/main.js in your Next.js project folder. This is a config file for Storybook and where you can install new addons to your project. In the addons array, add @storybook/addon-postcss:

// .storybook/main.js

module.exports = {
  "stories": [
    "../stories/**/*.stories.mdx",
    "../stories/**/*.stories.@(js|jsx|ts|tsx)"
  ],
  "addons": [
    "@storybook/addon-links",
    "@storybook/addon-essentials",
    "@storybook/addon-interactions",
    "@storybook/addon-postcss",
  ],
  "framework": "@storybook/react",
  "core": {
    "builder": "@storybook/builder-webpack5"
  }
}

This will allow Storybook to use this addon. Now open .storybook/preview.js in your Next.js project folder. At the beginning of the file, add import "../styles/globals.css":

// .storybook/preview.js

import "../styles/globals.css"

export const parameters = {
  actions: { argTypesRegex: "^on[A-Z].*" },
  controls: {
    matchers: {
      color: /(background|color)$/i,
      date: /Date$/,
    },
  },
}

Note: globals.css is a CSS file for Tailwind. If you have another file or have moved this file to a new location, you’ll need to import that file from the location you’ve moved it to.

Now you can run Storybook and you’ll be able to render components with Tailwind classes.

Configuring Storybook to use Next

Out of the box, Storybook will not be able to use Next-specific components and features, making the components work incorrectly when you try to view them in Storybook.

Fortunately, Storybook has provided an addon that allows us to use Next.js features within Storybook. First, you’ll need to download the addon. Run this command:

npm i storybook-addon-next

Once it is completed, return to .storybook/main.js in your Next.js project. In the addons array, similar to where you installed the previous addon, add storybook-addon-next:

// .storybook/main.js

module.exports = {
  "stories": [
    "../stories/**/*.stories.mdx",
    "../stories/**/*.stories.@(js|jsx|ts|tsx)"
  ],
  "addons": [
    "@storybook/addon-links",
    "@storybook/addon-essentials",
    "@storybook/addon-interactions",
    "@storybook/addon-postcss",
    "storybook-addon-next",
  ],
  "framework": "@storybook/react",
  "core": {
    "builder": "@storybook/builder-webpack5"
  }
}

Now if you were to run Storybook with npm run storybook, you’d get an error from TypeScript saying that baseUrl is missing from tsconfig.json.

Found no baseUrl in tsconfig.json, not applying tsconfig-paths-webpack-plugin

This line was not automatically added to the tsconfig.json file when the project was first stood up. Since it needs to be added manually, open tsconfig.json and add "baseUrl": "./", under compilerOptions:

{
  "compilerOptions": {
    "baseUrl": "./",
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "incremental": true
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx"],
  "exclude": ["node_modules"]
}

That’s it! You’ve now completed setting up a new Next.js project with Tailwind and Storybook! If you have any trouble, you can check out this repo to see a completed Next.js Tailwind Storybook set up here:

Completed Next.js TypeScript Tailwind CSS Storybook Example Repo

If you found this article helpful, please feel free to heart this article!

If you’re interested in learning more about Front-End Engineering, follow me here on Dev.to and Twitter.
If you’re interested in learning more about OpenSauced, follow OpenSauced here on Dev.to and on Twitter.