Forem: Andrew

Towards a Better Developer Experience

Andrew — Sun, 31 Jan 2021 14:48:18 +0000

Despite the many Twitter arguments that I've gotten into, many developers still feel that developer experience isn't important. Hell, that's probably the reason that PHP still exists in the wild. Cheap jabs at PHP aside, I feel that a good developer experience is important for a myriad of reasons.

Why does it matter?

To address this, I'd like to provide an example, and you'll hopefully see where I'm going with this:

Imagine you're working on a fairly large React project, and you have to update some styles for a component. Each change you make takes a second or two to update, but it's no problem for a 10x developer like yourself. You can just try to make large changes all at once and deal with it. Finally, you're ready to run a test build, and oh, wait for it... wait for it... it's still not done? You go and get yourself a cup of coffee and check in on it, and it's still going. You go take your dog for a walk, and... it's still going. You go walk your dog again (even your dog is tired of webpack at this point), and oh, wait, the process crashed. You then scream a variety of curse words while sipping cold coffee.

See, wasn't that a fun adventure? No? Did it hit a little too close to home? Here's a virtual tissue to wipe your tears. Although the example was a bit of an exaggeration, it wasn't too far off. So to give a serious point for once, developer experience affects productivity; happiness; and overall how much you enjoy working on something (crazy, right?). So, if there are simple ways to improve this experience, why not go for it?

Effect on new developers

I think it would be a good idea to take a moment to discuss the effect that developer experience can have on people who are just learning to write code. We've all been there at one time or another, and it can become really overwhelming (especially in the JavaScript ecosystem) to be bombarded by a million new tools, concepts, and technologies. A positive experience in the tooling department can really make all the difference in the world. No one wants to make a cup of coffee every time they add a new variable to their code (that would be a lot of coffee). I really do believe that a good developer experience can draw newcomers in, and a bad one can push them away.

What makes a good developer experience

I could list a million little regurgitated ideas of what makes a developer experience great, but let's be honest. I don't like writing enough to enjoy that, and you don't really want to read that. That would be a bad experience, which, as you've probably figured out, is a big no-no in this article. So to keep this short, a few things that make the developer experience better are:

Performance: Everyone loves snappy things. Well I mean languages like Python and Ruby are out there, so maybe not everyone. But most people like speed
Reliability: It can be really frustrating when a tool works one minute, but then refuses to work the next day because the lunar cycle changed. Tools should be reliable
Ease of use: While not everything has to be simple, a tool that makes things easier on developers is always appreciated - why do you think package managers exist?

This is, as always, not a complete list, but rather some of the main ideas. There's a lot more complexity here that I am neither qualified nor desiring to talk about. Note, these are the same principles for good UX (at least I think they are), and for good reason. At the simplest level, developers are users of tools and hence want those same things (although I doubt your average user could learn how to use VIM). If you take one thing away from this, let it be this:

Developer experience and user experience don't have to be mutually exclusive (that's a lie perpetrated by the dark forces of Stackoverflow)

An overview of some great tools

I was originally planning on making this whole post into a list of tools for a good developer experience, but:

That makes absolutely no sense without any context
I'm also not a fan of writing list articles (listicles) as they come off as low effort, and possibly boring if not executed right

So instead of giving you a laundry list of tools that you must use if you to want to be an ex-Google, ex-Facebook, ex-millionaire, ex-ecutioner, I'll showcase a few tools that really have changed my workflow for the better, as a way to exemplify what I'm talking about.

Two tools, in particular, came to mind (well really three, but you'll see what I mean)

Snowpack / ESBuild

I'm including these two together because I have yet to use esbuild on its own, however, it's an integral part of snowpack and what makes it great. I won't go into detail about snowpack - as their website does a much better job at it. However, I will say the techniques are genius and it results in ridiculously fast build times. Seriously, if you use React or Svelte (or even if you don't), give Snowpack a try!

`pnpm`

On the surface, pnpm is just a drop-in replacement for npm. However, in reality, it is... well yeah it's just another npm replacement. But it's a really fast npm replacement! That must get it to some level of coolness. pnpm uses a global cache of your node modules and uses smart directory structuring. In other words, it's like yarn, but better. Try it out here

Closing remarks

As is usual with my rather unprofessional writing, this post has a big fat /s attached to it. If I insulted your programming language of choice, then you might want to learn JavaScript or Rust instead. Seriously though, thanks for putting up with my bad jokes for long enough to get through the post. I figure there was a lot of "Just get on with it already"-ing, and I thank you for it.

I loved watching myself slowing losing my sanity, and this article going increasingly off the rails. Thanks for reading, and come back next time to see me complain some-more (shhh complaining == passion when type coercion is on)

Credits

Cover Photo by Bonneval Sebastien on Unsplash

One Bash Alias That Makes Life Easier

Andrew — Thu, 30 Apr 2020 22:08:09 +0000

Getting Started

To set environment variables persistently, you normally have to add it to your .bashrc or .profile. However, this can be annoying, and often more trouble than it's worth. An alternative is writing a function in your .bashrc that appends to a global .env file, and sourcing that file in your .bashrc. I'll show the code and then break it down

setenv() {
  FILE=$HOME/.env
  if [[ ! -f "$FILE" ]]; then
    touch $FILE
    source $FILE
  fi
  echo $1=$2 >> $FILE
  export $1=$2
}

[ -f $HOME/.env ] && source $HOME/.env

Code Breakdown

The first line of the function sets the file variable to a .env in the user's home directory. The if statement checks if the file doesn't exist, and if it doesn't, then it creates the file and sources it. The echo command appends to the .env file with the first and second arguments. The export command makes the environmental variable available right after running the command.

Finally, the last line sources the file, but only if it exists

Usage

You could then run something like this in your terminal (after reopening it)

setenv WORKING hopefully

This is the general syntax for the command

setenv <key> <value>

Note: If you refine a variable, like this,

setenv WORKING false
setenv WORKING true

the file will include both of these, but the first will be unused.

Wrapping things up

I use many other aliases and functions, but this is one that I recently thought of, and it is very useful.

Thanks for reading 🎉

My Results with 100 Days 100 Projects

Andrew — Tue, 07 Apr 2020 14:13:17 +0000

A few days ago, I finished the 100days100projects challenges, started by Florin Pop. I originally intended to do it for 30 days, but I just kept going.

Throughout the challenge, I drew some conclusions and found some resources that helped.

Some Conclusions

I found that when I was making projects, it was easier to either focus on a nice, clean UI or a functional project. Most times, it was either one or the other.

For most of them, I got right into the programming rather than designing them beforehand. This allowed me to quickly develop the site, instead of focusing on the design.

Finally, I found that I was able to do these projects fairly quickly when I focused on good design or good functionality.

Tips and Tricks

The most helpful tip I can give is making a boilerplate code snippet. Something that setups up your fonts, CSS variables (custom properties), and basic HTML structure. Here is an example

index.html -

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>Template</title>

    <link rel="stylesheet" href="style.css">
</head>
<body>
    <div class="content">
    </div>
</body>
<script src="index.js"></script>
</html>

style.scss -

*,
*::before,
*::after {
  box-sizing: border-box;
  padding: 0;
  margin: 0;
}

:root {
  --accent:#1187fc;
  --dark: #333;
  --neutral: #ddd;
  --light: #fff;
  --body: #151515;

  width: 100%;
  height: 100%;
}


body {
  font-family: sans-serif;
  min-height: 100vh;
  display: flex;
  justify-content: center;
  align-items: center;
  font-size: 1.125em;
  line-height: 1.6;
  color: var(--body);
  background: var(--neutral);
  overflow-x: hidden;
}

a { 
  color: var(--accent);
}

.content {
  background: var(--light);
  width: 70vw;
  padding: 3em;
  box-shadow: 0 0 3em rgba(0,0,0,.15);
}

This snipper generator should help you out with this

Setting up templates allows you to get out of the repetitive setup and into the actual programming

My second tip is to try to be distraction-free while working on the project. You will be much more focused if you are away from distractions.

Resources

All of these gave me inspiration on my journey. Later on in the challenge, one of the biggest bits of help was CollectUI's navigation section (the list of types of projects). It helped a lot when I was out of ideas.

Also, just looking up project ideas can sometimes yield great results. It just depends on what you search and how deeply you look.

What's Next

For me personally, I'm gonna take a 1-2 break from challenges. Afterward, I will probably try out 1 Product a Week or 12 Startups in 12 Months.

I'm going to continue programming every day that I can and working hard to improve my skills.

Wrapping Things Up

If you read this, thank you for your time ❤️. If you got to this point and you are debating whether you should try the challenge, try it. You can start with a shorter time and if you like it, extend it.

I hope you enjoyed reading this as much as I enjoy writing it. Please like and comment if you did enjoy, this article was 100 days in the making.

Social Media

My Take on Atomic Design in React

Andrew — Sat, 28 Mar 2020 23:14:35 +0000

For around a week, I have been working on a side project, and I am currently working on the frontend of it. I previously used Atomize as a UI framework, on other projects. But, I still prefer the freedom of creating my own components

One thing I did like about Atomize was that it employed Atomic Design, hence the name. If you don't know what Atomic Design is, here is a summary from their website

Atomic design is methodology for creating design systems. There are five distinct levels in atomic design:

Atoms

Molecules

Organisms

Templates

Pages

Fundamentally, as you go up this tree, the components get more complex. Molecules are made up of Atoms, Organisms are made up of Molecules and so on.

It's worth noting that for this project, I am using Next.js on top of React.

So for that reason, I will be focusing solely on the component directory and not involving other folders. This is to simplify it and make it more universal.

Here is what a normal React components folder may look like

- components
  - button.jsx
  - title.jsx

There would be more components, maybe they would be within their folders, but the point remains the same. The components are all together and not organized. That is okay as long as they are consistent.

However, "okay" doesn't have to be the standard. We can do better than "okay".

This is what a more complex file system looks like, using normal component structuring. After that, there is the same structure, but using Atomic Design.

// Normal
- components
  - Button
    - index.jsx
  - Title
    - index.jsx
  - Hero
    - index.jsx
  - Navbar
    - index.jsx
  - Dropdown
    - index.jsx

// Atomic
- components
  - atoms
    - Button
      - index.jsx
    - Title
      - index.jsx
  - molecules
    - Dropdown
      - index.jsx
  - organisms
    - Hero
      - index.jsx
    - Navbar
      - index.jsx

Now, at least to me, I like the extra organization of these components. But, there is more to Atomic Design then moving some folders. The meat and potatoes of this strategy is making modular components and having them depend on each other.

For example, instead of using an h1 element in your hero section, build a component for a Title and use it throughout your project. Components at higher levels should rely on lower components, whenever possible.

So, your Hero section might use a Title, a Body text, and a Button component.

One of the best benefits of using Atomic Design is that the site should consistent, with components remaining similar throughout the website. This is extremely important in larger projects, with multiple developers.

Another good thing about using this technique is that it is easier to get accommodated. If I am starting contributing to some open source project, it is much easier for me to understand it if the project includes a basic structure. I would almost have an entry point to the project, either by looking at the Atoms or the Pages. The Atoms show a lot of the underlying code, and the Pages offer a higher-level view of the project, from which I can dive into the components.

I think that Atomic Design is worth serious consideration, especially if the project has a scattered and inconsistent code-base.

What to take from this

I think that even if you don't implement Atomic Design (it's not for everyone), I think you should try to be aware of how you are structuring your components and keeping consistency, both within structure and design.

Thanks for reading ❤️. I hope you enjoyed it. I appreciate all feedback and suggestions. If you have any ideas for anything you think I should cover, feel free to let me know.

Social Media

User Authentication, In 2020

Andrew — Wed, 25 Mar 2020 15:55:28 +0000

In 2020, for many startups, side projects, and companies, using prebuilt authentication systems the likes of Firebase, Authpack, and Auth0 can be more secure and efficient than building out their own system.

And if you think about it, it makes sense. It's not like every company writes their own JavaScript framework. Why should companies reinvent the wheel?

With that said, in this article, we will be exploring a few different options and categories for authentication.

Prebuilt traditional authentication
- My recommendations
Password-less authentication
- My Recommendations
Social Login
- My recommendations
Implementing your own
- My recommendations

So without further ado, let's get started

Prebuilt traditional authentication

So this is the old-fashioned standard that most sites are using. The site usually requires a username or an email and a password.

While this is the most common setup, I would argue that it can lead to lower security compared to password-less standards.
A cryptographically secure randomly generated code is much harder to guess than your average password.

But, many users prefer this method because it is what they are used to. The most popular option isn't always the best, but traditional authentication has the advantage of being well-known and recognized. Everyone and their mother understands the concepts of it, mostly because it isn't rooted in a mysterious technology. Going the conventional route allows users to be accustomed to your platform from the beginning.

So, if you don't wanna spend one of your innovation tokens (read this) or prefer familiarity with your user base, then this may be the way to go.

My recommendations

Authpack: Extremely generous free tier with unlimited users. Great support and documentation. Stripe payments also integrated. Incredible user experience
Auth0: Has a more enterprise-focused angle. Free plan with 7000 active users
Firebase Auth: Part of Firebase. Includes many other options including anonymous, social login, and Phone Auth. Phone Auth limited to 10k for free

Password-less authentication

Recently, a few companies have begun offering password-less as a less risky alternative to traditional authentication.

These use public-private encryption algorithms to generate key pairs. The public key is saved to a database associated with another piece of data, often an email or phone number. Then, a “challenge” is sent, and the browser uses the private key to solve. The server sends a unique token to the browser and the transaction is over. Read about this more from one of the providers.

I reached out to DID.app for a one -sentence summary, and this is what they said.

DID.app is an Identity Provider, that authenticates users by verifying access to either an email address or securely stored private key.

Security is greatly improved by this process and the user experience may also be better, but only when they've gotten used to it. If you want to try a new, promising technology, password-less may be the route to go down.

My Recommendations

DID: 1,000 users. Unlimited applications. Reasonably priced and very open about the technology
Auth0: Enterprise-facing. Has support for password-less (obviously)

Social Login

This seems to be a perfect solution for both users and companies. Users get a much quicker registration process and companies barely have to manage their authentication or paying for it.

These usually rely on the 0Auth standard to authorize the Application

Social login can also end up allowing some great concoctions, such as SOA (Son of Anton)

You can implement these yourself fairly easily using passport (which is sponsored by Auth0) and Express or use one of these platforms. Implementing your own solution with passport is relatively safe, and gives you the flexibility of adding pretty much any social provider. If you need an integration with a lesser-known service, this may be your only feasible option.

My Recommendations

Authpack: Only four options currently (Google, Facebook, Slack, Github), but the creator is open to adding new ones upon request. Same features mentioned earlier
Firebase Auth: Many providers supported, but most likely harder to get one added
Auth0: Unclear what social login providers are supported. Sign in with Google supported

Implementing your own

Building your own authentication system for production is not recommended. There are many security risks involved in doing this. Let's just say it's not a task for the faint of heart.

If you do want to attempt this challenge, assume you will be hacked. It's not a matter of if, it is a matter of when and how.

A strong understanding of security on the web should be possessed if you are going down this route. Knowledge of hashing functions, encryption, SSL and TLS, Sessions, and much more is essential.

I recommend using Express as a server, passport and passport-local, and helmet for some added security.

My Recommendations

The definitive guide to form-based authentication

These OWASP cheat sheets should also help

Wrapping things up

My #1 recommendations for Auth are Authpack and DID.app. They both are extremely well-thought-out services that are quite useful within their categories.

I hope you enjoyed this article. I spend a lot of time writing it and I appreciate any feedback or suggestions. If you would like me to write an article about implementing any of these services, please let me know.

Thank you for reading, and remember, hash your passwords!

Updates

I just discovered Magic. It is a link-based password-less authentication service. It might be worth consideration.

Make a simple HTTP Server with Node in 6 Steps

Andrew — Thu, 05 Mar 2020 23:56:47 +0000

Note: This post was originally written for Twitter
^ You can find the original here

1. Initialize the project

Follow the prompts from this command

touch index.js

npm init

2. The basics

Here is the basic layout of the server

// Import the HTTP module
const http = require('http')

// Make our HTTP server
const server = http.createServer((req, res) => {
    res.write('hello world')
    res.end()
})

// Have the server listen on port 9000
server.listen(9000)

3. Routing

Routing can be done by importing the builtin URL Module and parsing the request URL. Then, we compare the request URL to the URL for the route

// Import the HTTP module
const http = require("http");
// Import the URL module
const url = require("url");

// Make our HTTP server
const server = http.createServer((req, res) => {
    // Parse the request url
    const reqUrl = url.parse(req.url).pathname
    if(reqUrl == "/") {
        res.write("you're boring")
        res.end()
    }
    else if(reqUrl == "/hello") {
        res.write("hello world")
        res.end()
    }
})
// Have the server listen on port 9000
server.listen(9000)

4. Methods

Similar to routes, we can check the method of the request and compare it the expected result

// Import the HTTP module
const http = require("http");
// Import the URL module
const url = require("url");

// Make our HTTP server
const server = http.createServer((req, res) => {
    // Parse the request url
    const reqUrl = url.parse(req.url).pathname
    // Compare our request method
    if (req.method == "GET") {
        if (reqUrl == "/") {
            res.write("you're boring")
            res.end()
        }
    } else if (req.method == "POST") {
        if (reqUrl == "/hello") {
            res.write("hello world")
            res.end()
        }
    }
})
// Have the server listen on port 9000
server.listen(9000)

5. Headers

We can set headers on the response pretty easily using res.setHeader()

// Import the HTTP module
const http = require("http");
// Import the URL module
const url = require("url");

// Make our HTTP server
const server = http.createServer((req, res) => {
    // Set our header
    res.setHeader("Access-Control-Allow-Origin", "*")
    // Parse the request url
    const reqUrl = url.parse(req.url).pathname
    // Compare our request method
    if (req.method == "GET") {
        if (reqUrl == "/") {
            res.write("you're boring")
            res.end()
        }
    } else if (req.method == "POST") {
        if (reqUrl == "/hello") {
            res.write("hello world")
            res.end()
        }
    }
})
// Have the server listen on port 9000
server.listen(9000)

6. Request Parameters

We can easily grab our URL based query strings with a little modification

// Import the HTTP module
const http = require("http");
// Import the URL module
const url = require("url");

// Make our HTTP server
const server = http.createServer((req, res) => {
    // Set our header
    res.setHeader("Access-Control-Allow-Origin", "*")
    // Parse the request url
    const parsed = url.parse(req.url, true)
    // Get the path from the parsed URL
    const reqUrl = parsed.pathname
    // Compare our request method
    if (req.method == "GET") {
        if (reqUrl == "/") {
            // Send a JSON version of our URL query
            res.write("Hello, you sent\n" +  JSON.stringify(parsed.query))
            res.end()
        }
    } else if (req.method == "POST") {
        if (reqUrl == "/hello") {
            res.write("hello world")
            res.end()
        }
    }
})
// Have the server listen on port 9000
server.listen(9000)

Wrapping things up

I hope you enjoyed the quick tutorial. I did most of the research for this while developing my own HTTP framework, called onlinx, built lightning fast and fully dependency-less. If you have any questions, feel free to comment them. If you are interested in onlinx please let me know. Thank you for reading and goodbye.

My Experience with Atomize and Next.js

Andrew — Mon, 24 Feb 2020 00:41:10 +0000

I started out on my journey to redesign my portfolio website a few months ago. I created many designs, just to question it and make another. Eventually, I hit the jackpot with a prototype and decided it was time to realize it.

After hearing great things about it, I also decided to host the website on Zeit.co. So, before I started coding, I was scrolling through Product Hunt and I saw Atomize React. It immediately intrigued me, so I went to their homepage and got more information.

"Atomize React is a UI framework that helps developers collaborate with designers and build consistent user interfaces effortlessly" - Atomize React

I went into the quick start and well, got started. After having to setup the Styletron engine for next.js (the framework I decided on), I was already a little worried. But my doubts quickly faded away as I used Atomize, or at least some of my doubts. For example, the framework itself worked well, but it felt difficult to get into the Atomic Design approach and they didn't really do too much to help. Also, the attributes to style the Components were so strange that I was pretty much glued to the documentation. There were a few other issues, but most of them are just little problems.

So, I built out the site, component by component, consulting the documentation regularly. This went fine and I published the site within 2 days of starting. However, after publishing the site, I realized a few issues that I hadn't thought of. One was the max width of the container. On different sizes, the <Container> element had a max width. This caused the container to be only half of my screen width. Another problem was that my row was configured strangely, so an <Image> and a <Text> tag weren't on the same line as they should've been.

My last big issue was kind of on me for bad implementation. After releasing the site and fixing everything else, I started working on adding a dark mode. At first, I passed the background and color of each component as a Stateful variable. Then, when I wanted to toggle dark mode, I could just change the state and it would update. However, it was extremely messy and dirty code. I also had trouble deploying the code, so I rolled back the commit and started again.

This time, however, it went much better. I took a different approach, utilizing the Styletron engine and the useState() hook, located in my index.js file. I then passed the variable to set the state to my App.js as a prop. The state variable was used to append custom colors to my Styletron Config. Basically, you can set custom colors and variables to use in the attributes of your components, and I changed the custom colors to match dark mode or light mode. This worked and resulted in much cleaner code.

Overall, my experience was pretty good. It had it's road bumps, but the issues were small and very manageable.

Ratings

Next.js - 8/10
Atomize React - 8/10
Zeit.co - 10/10

If you read all the way through this, thanks for reading.

Links

The final site
The Github

Updates

I rebuilt the site without using any component library, mostly because maintenance was extremely annoying