DEV Community: Tracy Adams

How To Setup Shopify Slate on Ubuntu

Tracy Adams — Fri, 03 Jan 2020 00:00:00 +0000

So recently, I've started to make the move off MacOS as my daily work driver and was trying to work solely on my Windows 10 Laptop (Razer Blade). Well, it was all fine and dandy with my sweet WSL2 setup, until I encountered an issue. There's no official instructions on how to use Shopify Slate properly on Linux.

In this post, I'd like to document my steps taken to properly get a local SSL setup while still following Shopify Slate's instructions with their ssl-check shell function they provide you.

Note: I've made a PR with documentation updates to the Shopify Slate repo!

Follow all the Shopify Slate instructions up to the "Create a self-signed SSL certificate" step
Once at this step, do the following:

Install mkcert by following these instructions from the official mkcert repo

Add the following function to your shell profile (.bash_profile, .zshrc, .bashrc, etc...)

     function ssl-check() {
         f=~/.localhost_ssl;
         ssl_crt=$f/server.crt
         ssl_key=$f/server.key
         b=$(tput bold)
         c=$(tput sgr0)

         local_ip=$(hostname -I | cut -d' ' -f1)
         # local_ip=999.999.999 # (uncomment for testing)

         domains=(
             "localhost"
             "$local_ip"
         )

         if [[ ! -f $ssl_crt ]]; then
             echo -e "\n🛑  ${b}Couldn't find a Slate SSL certificate:${c}"
             make_key=true
         elif [[ ! $(openssl x509 -noout -text -in $ssl_crt | grep $local_ip) ]]; then
             echo -e "\n🛑  ${b}Your IP Address has changed:${c}"
             make_key=true
         else
             echo -e "\n✅  ${b}Your IP address is still the same.${c}"
         fi

         if [[ $make_key == true ]]; then
             echo -e "Generating a new Slate SSL certificate...\n"
             count=$(( ${#domains[@]} - 1))
             mkcert ${domains[@]}

             # Create Slate's default certificate directory, if it doesn't exist
             test ! -d $f && mkdir $f

             # It appears mkcert bases its filenames off the number of domains passed after the first one.
             # This script predicts that filename, so it can copy it to Slate's default location.
             if [[ $count = 0 ]]; then
                 mv ./localhost.pem $ssl_crt
                 mv ./localhost-key.pem $ssl_key
             else
                 mv ./localhost+$count.pem $ssl_crt
                 mv ./localhost+$count-key.pem $ssl_key
             fi
         fi
     }

The biggest difference with this script is the local_ip assignment. The one that is in the official Slate Documentation only handles for MacOS. This should work for most Linux environments (tested on Ubuntu 16.04 - 19.10)

Restart your terminal or run source <location of your shell profile>
Run ssl-check and then run mkcert -install
You will need to restart your currently open browsers for these changes to take effect

You should now have a functioning local SSL setup for Shopify Slate. You can yarn start your heart out!

Adventures of Building A Startup - Part 1

Tracy Adams — Sun, 15 Dec 2019 00:00:00 +0000

As promised in my last post, I will be writing about my experience with building a startup!

In this initial part, I'd like to discuss the idea, the tech stack, and what I've got at this point in time.

The idea

My idea is to build a startup that revoles around servicing eCommerce stores. Since my day-to-day work involves working on Shopify Sites, I'll be building a Shopify App, to be specific.

This app will be free on the Shopify App Store, at least for the initial launch 😉. My reasoning behind releasing an initially free app is to

Gain some initial traction
Provide value up front
Have a great resource of users to test new features
Have a backlog of features that I consider "premium" to release in the future under paid plans

With this plan of attack, I'd like to dive into the actual Shopify App idea.

The app

The main issue I run into on a day-to-day basis with most of my Shopify Stores is that I don't have a great solution for managing and scheduling promotional prices for products.

There are some apps that do this somewhat okay-ish, but I need something that's tailored to my specific needs:

Uses Shopify's Polaris UI
Can select all products, an entire collection of products, an individual product, or an invidivual variant of a product to schedule/set a sale price
Can schedule at least 1 promo at a time
Can view past, view/edit current, and view/edit future promotions

These needs are individually met by certain apps, but there isn't a singular app that does all of them well.

The tech stack

I will be building this app in a full JavaScript-based environment

NextJS for the front end
NodeJS/JavaScript + Prisma for the back end & datastore

I picked this stack as I'm most familiar with JavaScript tech, and I want to get to know the NextJS ecosystem a bit more. We'll be utilizing Zeit's Now for our hosting needs outside of the datastore. For our datastore, we're going to start out with our own Postgres server with DigitalOcean paired with a GraphQL API. If need be, we'll move to using RDS or DynamoDB, but a self-hosted solution will be more than enough to begin with.

The design

I'll be using Shopify's Polaris to get the actual UI off the ground. Luckily, that means my app will fit right in with the standard Shopify Admin UI and will have some sweet premade components to go along with it.

To start with, I've created some basic outlines of what the UI will look like with Whimsical. I use Whimsical for most of my wireframing once I actually have an idea, as it's easy to get basic layouts from hy head/from paper and onto my computer.

Next steps

So this is where I'm at

Getting basic wireframes fleshed out
Describing the MVP requirements
Figuring out the tech stack

With those pieces laid out, I will be getting started on building out the initial interactivity portions of this app

Basic front end with Authentication
Storing credentials to our datastore
Reauthenticating sessions
Backend lambda functions for the following actions
- Workers to consume tasks from a queue
- Task queue for scheduled changes to be made

Once that is complete, I'll be back for another writeup and a potential quick sneak peak of the app in action 🚀

Where did my October go?

Tracy Adams — Sun, 10 Nov 2019 00:00:00 +0000

Wow... how in the hell did it already get to be November? I guess I should recap what has been going on.

I spent a lot of my October getting things prepped and ready to go for Black Friday/Cyber Monday at my day job. This included things like building out new product launchs, preparing new site features to drive higher conversion rates, and scheduling the obvious price discounts across our websites.

To give some insights on what I've been working on, here's a glimpse into the specifics:

Increased performance by over 20% (real-world load times reduced by ~3-4s on average)
New checkout options to reduce stress of pricing
New landing pages (always gotta build dem landing pages)
Some secret projects I'm unfortunately not able to discuss publicly (yet)

Along with that, I've taken on some contracting work in the Shopify world. This is awesome because I'm working with up-and-coming tech to build futuristic Ecommerce stores. With the knowledge from Web Dev Twitter, Shopify's GraphQL API Documentation, and my own trial-and-error, I've started work on a few Headless Shopify websites that'll be really nifty! When these projects are done, I'll do a writeup of the tech stacks used, performance vs. the old client websites, and reasons for why I did headless for these use cases.

ALONG with the Shopify contract work, I've started work on my first SaaS/Startup as well! 🎉🎉🎉

This will be a service for Ecommerce businesses to better manage their customer service processes. I'm not gonna get into the nitty-gritty of this, because I don't want to give away my product just yet, but just know that the product already exists, and I've done extensive research and have definite validation for what I'm building out.

I'm giving myself a deadline of 10 weeks to get this launched in the Beta phase to start testing with a few select customers. At the end of each week, I'll be posting a review of my week to hold myself accountable to the public. I'm dedicated to releasing this product, as I want to help reduce friction in the Ecommerce space with specific products that I've been experiencing for years.

If you're interested in working with me on this project, I am looking for partners/contributors. Please feel free to DM me on Twitter or email me at tracy@tracycodes.com.

Coding practices you should learn now, and utilize forever

Tracy Adams — Mon, 23 Sep 2019 03:41:46 +0000

Here are 5 coding practices I’ve come to know and love over the last few years that I thank myself for every day.

1. Standard code formatting

Most codebases are ready more than written. A codebase with consistent formatting is a lot easier to read vs code with varying styles from numerous contributors on a team. Standardized formatting brings about being able to easily scan through code and pick out the bits you need without bashing your head against your desk. Prettier + ESLint + a popular linting config can do all the heavy lifting for you. Do you have a team member who absolutely refuses to use semicolons in their JavaScript? That’s fine! Just have them use Prettier ESLint with a predetermined config, this will return errors if they don’t follow the code guidelines. When we implemented this exact setup in our codebase, we ended a lot of discussions/heated debate during code reviews and QA.

2. Don’t code DRY if it doesn’t make sense

The DRY (Don’t Repeat Yourself) principle is almost a mantra (and sometimes a great interview question) among developers. But, if it’s applied without knowing why, then it will lead to some abstract code that is simply too hard to read and understand.

For me and my team, we stick to a “2-copy maximum” rule. This means any function/code can be copied two times in a codebase. If it needs to be copied any more than twice, then we refactor so that the code is completely reusable within the rest of the application without having to copy+paste code constantly. This keeps us from assuming two problems should be solved the same way, at first glance.

3. Debug code via logging

You should practice debugging code in your local environment via logs instead of a debugger. For us, we use Sentry.io for our logger/debugger in production. Because of this, we’re charged “per event”, which means logging and events are very precious.

Since we treat logging and events as such, we do debugging on our local machines first to ensure that logs are added in the right place. This, in turn, makes it so that if an exception is handled via Sentry, it is super easy to track down since we don’t have a crazy clutter of logging.

Remember, too much logging === not logging at all

4. Don’t add complication early on

Don’t complicate your codebase with features that no user or stakeholder has asked for. This is a problem you need to especially avoid in early product lifecycles. I struggled with this when I first joined my new team. I tried to come out the gate swinging and going above and beyond expectations. Do you know what this did? It added more questions, more tickets, and even more work on my team’s plate.

This is an anti-pattern. Adding unnecessary features makes your codebase harder to read and debug. When you onboard new developers, they will find it difficult to differentiate between important features and ones that were added at 4am and were backed by a caffeine overdose.

5. Setup a CI/CD pipeline early in your project’s lifecycle

I can’t say this enough. Even if you’re on your own with a project, a CI/CD pipeline will reduce the overhead of remembering (and doing) the build and deployment of your codebase.

A common misconception is that CI/CD pipelines are important only for teams that push/deploy a lot of code to production every day. From my experience, even if you’re pushing to production once a week, it can save hours. Recently, I introduced a CI/CD pipeline for our main project (deployment used to take several hours as a lot of it was copy+pasting code or uploading code to servers and replacing old files via diffing). After introducing CI/CD, we can run a full production deployment in under 5 minutes and can rollback in seconds if there’s an error.

P.S. Having a CI/CD pipeline usually results in having an exact deployment history, linking it to a specific commit. This has helped us during postmortems to find the root cause for an incident.

Hello World

Tracy Adams — Tue, 03 Sep 2019 20:48:58 +0000

How exciting! This is my very first blog post (ever). Don’t try Googling it, because it’s definitely true.

You’re probably thinking, “what’s this blog about?“. To that, I’d like to respond with the following:

I’m primarily starting this blog so I can share the knowledge I’ve amassed over the last 4 years of professional web and software development. I’ve built distributed applications with both Go and Node.js, complete desktop apps, warehouse management solutions, and more.

Over the last 4 years, I’ve spent my time at

Agencies
Full time freelancing
Running an E-Commerce business
Working full time as a lead developer for one company

Along with technical know-how, based on my success in the freelancing world, I have gained a lot of knowledge with respect to being successful in the shark-infested waters that is freelance web development and software engineering.

If you’re curious, I’m branching out and have rebuilt my entire website using GatsbyJS and plan to do some pretty neat things once I get out of this boilerplate stage.

I hope you follow along on Twitter and Instagram as I’ll be posting updates there when I push a new post live 🤓

As a parting _gif_t, I’ll leave you with this… an accurate representation of me last week while on vacation in another state after deploying a broken branch to production…