The key to making the right decision lies in understanding the goal of your application. Perhaps it’s a simple website, a one-page app, or it requires serverless or cloud functions. Having clarity about these aspects will significantly ease the deployment process.

In this article, we will look at a few popular methods for deploying your application that will help tackle these challenges.

What we'll cover:

1. What to consider when deploying a hosting platform

2. How to deploy a website or app with Render

3. How to deploy a website or app with Surge

4. How to deploy a website or app with Vercel

5. How to deploy a website or app with GitHub Pages

6. How to deploy a website or app with Netlify

7. Conclusion

What to Consider when Deploying to a Hosting Platform

There are several factors to take into account when selecting a hosting platform:

1. Purpose: Before you host your application, consider the technologies you used to build it and how much storage the platform can handle.

2. Interface: A good interface is essential for a hosting platform. Look for a control panel or dashboard that allows you to easily administer your website.

3. Reviews: Look at the hosting service's reviews and read what other clients have to say.

4. Security: To safeguard your website and data, it is essential to have the right security measures in place.

5. Support: You should always have someone there to help you out when you need it.

Why is Deploying an Application Important?

If you've built an app, there are various reasons you may want or need to deploy it, such as:

1. It showcases professionalism and credibility to users.

2. It increases the accessibility of the application to a broader audience.

3. It enables user interaction and feedback.

4. It facilitates data analysis and provides insights for informed decision-making.

5. It identifies areas for improvement in the application.

What's the Benefit of Choosing a User-Friendly Deployment Method?

Opting for a more approachable deployment method brings significant advantages:

1. Collaboration: When working together as a team, it’s useful to have straightforward methods to deploy your application. This makes collaboration and teamwork easy. These will encourage cooperation throughout the deployment process.

2. Efficiency: A user-friendly deployment method simplifies the process.

3. Simplicity: Choosing a hosting platform that is easy to understand will benefit everyone involved.

4. Reliability: easy to use deployment methods ensure a more reliable application and minimise potential disruptions.

How to Deploy a Website or App with Render

Render provides an interface for quick and straightforward publishing of static web content. Let's now go through how to deploy an app to Render step by step.

Step 1: First, ensure you have deployed your work or code from your editor to your GitHub account.

Step 2: Open a new browser tab and navigate to the Render website.

Render website

Step 3: Select the “GET STARTED” button on Render's home page to get going.

• You can use your GitHub, GitLab, or Bitbucket account when signing up. Choose the GitHub option and follow the steps to grant Render access to your GitHub account.

• If you already have a Render account, click the “Sign in” button to be redirected to the Sign-in page. You can sign in via email and authenticate using your Google account or your GitHub account.

Sign in page

Step 4: Once you access the dashboard, click the “New” button.

Dashboard of Render

Step 5: Upon doing so, a drop-down menu will appear. It'll show you a comprehensive list of services provided by Render.

List of Services offered by render

Step 6: Clicking “Static Site” from the drop-down menu will lead you to the “Create a New Static Site” page. From there, you can select the repository you wish to host.

Create a New Static Site

Step 7: After selecting the repository you wish to host, you will be directed to the deployment platform. There, you can provide the necessary information to host the application and click the “Create Static Site” button for it to deploy.

Deploying the app using Render

Here's what the final output should look like:

Hosted application

Pros of Deploying With Render

• Render has a free tier for hosting basic static websites.

• It provides a flexible price structure that ensures transparency and cost-effectiveness.

• It makes deployment easy. They provide an interface and connection with standard development tools and platforms. It also supports a wide range of programming languages, frameworks, and databases.

• It delivers a variety of integrated features that improve the hosting experience.

• It has good customer service support.

Cons of Deploying With Render

• Render specializes in static websites, Docker containers, and serverless functions.

• For more complex/bigger applications, there's a paid plan. You'll need to go through their price structure and understand the charges related to your usage.

• There is a learning curve, especially for newcomers to the platform.

How to Deploy a Website or App with Surge

This friendly platform and tool make it quick and easy to deploy static websites online.

Deploying your static files to surge.sh is easy using the command-line interface (CLI).

This command-line interface (CLI) streamlines the process of hosting and distributing your online projects.

Surge website

Steps to Deploy Your Site Using Surge

First, in the terminal of your project, type the command npm i -g surge.

Then type the command surge.

And that's it! You can deploy your app without logging in into your GitHub account.

To see what you have deployed, first copy the successful link in the terminal. Then paste it into your browser. You should see something like this:

Hosted site with Surge

Like I mentioned before, Surge doesn't need extra code. You can easily deploy your app right from your editor's terminal by typing the command surge.

Pros of Deploying with Surge

• Easy to Use: Surge provides a simple deployment for static websites.

• Fast Deployment: It has a quick deployment time.

• Custom Domains: It allows you to use your domain name for your website.

• SSL Support: It provides free SSL certificates.

• Support for Single-Page Applications (SPAs): It's well-suited for deploying single-page applications.

Cons of Deploying with Surge

• Limited Functions: Surge is designed for static websites.

• No Custom Server Configurations: It streamlines the deployment process by abstracting away server configurations.

• Premium Features: This platform offers free hosting for basic usage, but you'll have to pay for more features.

How to Deploy a Website or App with Vercel

Vercel is a hosting and deployment platform that specializes in modern web applications.

It is particularly well-suited for single-page applications, serverless operations, and static websites. It integrates with popular frameworks like Next.js and Gatsby.js, making deployments fast and simple.

Steps to Deploy Your Site Using Vercel

First, ensure that you have deployed your work or code from your editor to your GitHub account.

Then open a new browser tab and navigate to Vercel’s website.

Vercel website

Head to the Vercel website and click the “Sign up” button on the homepage.

• Sign up using your GitHub account and follow the steps to grant Vercel access to your GitHub account. If you already have a Vercel account, click the “Login” button and enter your login information.

• After signing up or logging in, Vercel will request access to specific information from your GitHub account. Review the required permissions and permit Vercel to proceed.

Next, click on “Add New…” on the Vercel dashboard. This action will reveal a drop-down menu. From the menu, select “Project,” which will navigate you to the next page.

Add New Project

On the next page, you will import your repository for deployment.

Vercel Deployment

Here's what the final output should look like:

Hosted site

When deploying your application to Vercel, you may encounter some errors, often caused by routing issues.

To fix this:

• Create a file under the root of your application called vercel.json.

• Inside the file, write the following code:

vercel.json

{ "rewrites": [{ "source": "/(.*)", "destination": "/" }] }

Inside your editor

Pros of Deploying With Vercel

• Collaboration: Vercel offers tools for effective teamwork, access control, and cooperative deployments.

• Simple Deployment: it simplifies delivering your web apps with ease.

• Preview Deployments: it allows you to share and review changes before they go live. This promotes collaboration and ensures a smooth and efficient workflow.

• Scalability and Performance: It still guarantees great performance even with a large number of people using it.

• Git Integration: it makes Git integration easy.

Cons of Deploying With Vercel

• If you are new to Vercel, you must understand how to deploy and configure your application. Reading Vercel’s documentation can help you get up to speed.

• Vercel is great for small to medium-sized projects, but it may not be the best fit for large-scale applications with complex backend needs. In such cases, developers may need a hosting solution that offers more customization and scalability.

How to Deploy a Website or App with GitHub Pages

GitHub Pages is a straightforward and cost-free hosting service. You can use it to host static web pages or documentation.

You can publish your site using GitHub Pages by submitting your code to a GitHub account and setting up a repository. Let's go through the process now.

Steps to Deploy Your Site Using GitHub Pages

To use GitHub Pages to host your website, follow these simple steps:

First, go to GitHub's website.

Github website

Then create a GitHub repository. If you don’t have a GitHub account, you'll need to click on “sign up”, or just click “sign in” if you already have an account.

Github sign in button and sign up buttons

Create a new repository by clicking the New button in the upper-right corner of your GitHub profile.

Creating a new repository

Give your repository a name that reflects your website.

Repository name

Once you have finished the previous step, go back to your Editor. Copy the generated code and paste it into your editor.

Code generated from new repository

The code in the image above is generated when creating a new repository.

Go to the settings page of the newly created repository.

Clicking on settings

Click on the settings option to redirect to the settings section. Locate and click on “Pages” in the left-hand side menu.

GitHub pages section on the settings page

To access GitHub Pages, click on the “Pages” section. Once you’re on the GitHub Pages section, click in the drop-down menu and choose either the “master” or “main” branch. Remember to save your selection.

Enabling GitHub Pages to host your site

Refresh the page to find the link leading to your published website.

Seeing your hosted site

Pros of Deploying With GitHub Pages

• GitHub Pages are simple to set up – and you can build your website there.

• It's free.

• GitHub’s version control system makes it simple to keep track of changes and work with others.

• GitHub Pages updates your website’s code whenever you make changes to it.

• It offers collaboration on projects with other developers.

• It ensures your website is safe through HTTPS (Hyper Text Transfer Protocol) encryption.

Cons of Deploying With GitHub Pages

While GitHub Pages offer many advantages, there are a few considerations to keep in mind:

• If your website becomes too large due to file size, this can cause some performance issues.

• GitHub Pages may only support simple functions.

• Understanding Git, the version control system used by GitHub, is essential for managing your website’s code.

How to Deploy a Website or App with Netlify

Netlify integrates with Git repositories and works well with static web pages and single-page apps.

Steps to Deploy Your Site Using Netlify

First, you'll need to make sure that you have deployed your work or code from your editor to your GitHub account.

Then, open a new browser tab and navigate to the Netlify website.

Netlify website

Head to the Netlify website and click the “Sign up” button on the homepage.

• Create an account by signing up with your GitHub, GitLab, or Bitbucket credentials.

• Select the GitHub option and follow the steps to grant Netlify access to your GitHub account.

• If you already have a Netlify account, click the “Login” button and enter your login information. After signing up or logging in, Netlify will request access to specific information from your GitHub account. Review the required permissions and permit Netlify to proceed.

Once you have finished registering, go to the dashboard where you will host your repository.

Netlify has two ways to host your project:

1. Drag-n-drop

2. Importing the source code from your repository to the site.

Using the Drag-n-Drop feature:

Once you have logged in, navigate to the left-hand side of the dashboard and select the “site” option.

Netlify dashboard

Before deploying your project, it’s important to include an “index.html” file. Netlify recognizes this file as the main folder for hosting your project.

Root index.html file

Go back to the website click on “site” and scroll down, you will see the drag-n-drop zone where you can drag and drop your file or you upload the folder.

Netlify drag and drop

By using this feature your project will be deployed.

Importing the source code from your repository to the site:

First, upload your code to GitHub.

Then access the Netlify dashboard.

To access the option (drop-down) menu, click on “Add New Site”. Select “Import existing project.”

Import existing project

When you click on “Import existing project,” the system will direct you to a new page. Then you can import your repository from your GitHub account or any other storage account where you stored your source code.

Connect to Git provider

When you click on this button, it will navigate you to the next page where you can choose the desired repository from the available options.

Choosing repository from Netlify

After selecting the repository, the next step is configuring and deploying your site.

Deploying from Netlify

Here's the result:

Hosted App

When deploying your application to Netlify, you may encounter errors, often caused by routing issues.

To fix this:

Create a file called _redirects, and inside write the following code:

_redirect file

/* /index.html 200

Example

Encounter error during deployment which is caused by routing issue

Pros of Deploying with Netlify

• Form handling capabilities: Netlify makes handling forms on your websites easy. It has a simple API that allows you to collect and process form submissions. It also integrates with popular form providers like Zapier, Mailchimp, and Slack.

• It’s easy to configure custom domains for your websites: it makes it simple to manage your website’s domain and security. It also ensures that your websites are secure with HTTPS.

• Web Hosting: Netlify helps you host your websites and applications. It offers static site hosting, allowing you to deploy HTML, CSS, and JavaScript files straight from a Git repository or by drag-and-drop.

• Simple Deployment: it makes deploying your website or web app straightforward. When you connect your repository, it will deploy any changes you make.

• Continuous Deployment: When you make updates to your source code, Netlify builds and publishes your website for you. This ensures that your website always reflects the latest changes you’ve made.

Cons of Deploying With Netlify

• Project size: This hosting platform is an excellent choice for small to medium-sized projects. But you should explore other hosting and deployment options as your website or app grows.

• Limited Backend Capabilities: Netlify prioritizes front-end development and static websites. Although it does have some backend functions, it may not be the best option for projects that need complex server-side processing.

Conclusion

In conclusion, deploying an application is crucial so that users can access it and others can see your work. User-friendly deployment methods offer significant benefits, including collaboration, efficiency, simplicity, and reliability.

Here's a quick review of what we've covered here:

• Render offers a simple interface, affordable pricing, and built-in features.

• Surge offers fast deployment speeds, making deploying static websites a breeze.

• Vercel is an expert in creating cutting-edge web apps with scalability and preview deployments.

• If you’re looking for an easy-to-use option, consider GitHub Pages. It provides several advantages, including simplicity, free hosting, version control, and HTTPS encryption. But, it has limited functionality and technological limitations for more sophisticated applications.

• Netlify is a user-friendly platform that's great for quickly deploying static websites and web apps. It's perfect for projects that want easy setup, automatic deployment, and modern development features

What you choose will depend on the particular needs and objectives of your application and the technical know-how of the developers working on it.

And if you want to improve your Git skills, you can read this Git Command article.

If you found this tutorial helpful, please share it with fellow developers who may also find it interesting. You can also stay updated on my latest projects by following me on Twitter and LinkedIn.

In this article, I will provide you with a list of four free website builders you can choose from when creating your websites.

Here is the complete list. If you find an option you like, then click on the link and it will take you to that section of the article.

1. Wix
2. Weebly
3. SITE123
4. Carrd

Wix

Wix was founded in 2006, and it is a very popular free drag and drop website builder.

The free version comes with the following options:

• Up to 500 MB (megabytes) of storage and bandwidth
• Assigned URL: accountname.wixsite.com/siteaddress
• Wix ads appearing on every page

You can sign up using an email address and password or with Facebook, Google or Apple.

If you want to create a new website, you will be walked through a questionnaire to create the basic setup.

You have the option to design your website choosing from 100's of templates and drag and drop features. Or you can choose the [Wix Artificial Design Intelligence](https://support.wix.com/en/article/about-wix-adi#:~:text=Wix%20Artificial%20Design%20Intelligence%20(ADI,a%20stunning%20site%20for%20you!&text=From%20billions%20of%20combinations%20including,%2Da%2Dkind%20free%20site!) which will create a website for you.

If you choose the [Wix Artificial Design Intelligence](https://support.wix.com/en/article/about-wix-adi#:~:text=Wix%20Artificial%20Design%20Intelligence%20(ADI,a%20stunning%20site%20for%20you!&text=From%20billions%20of%20combinations%20including,%2Da%2Dkind%20free%20site!) option, then you will be asked a series of questions on what kinds of design themes and features you are interested in.

Once you choose your templates, then the Wix ADI will create your basic website where you can customize the pages.

You can also see what these sites would look like on mobile devices.

If you choose to use the template editor, you can browse through hundreds of free templates and customize them to your liking. You can also add your own media including videos and images.

When you are finished creating your site, click on Publish in the upper right hand corner of the page.

It is easy to get your website up and running using clean, professional designs and there is no coding knowledge necessary.

Weebly

Weebly was founded in 2006 and it is a free website builder that makes it easy to build blogs, online stores, and personal sites using customizable templates.

The free account will provide the following options:

• SSL security
• Access to the community forum
• Access to dozens of website templates
• Chat and Email support

You can create your own account using a username and password or you can login with Facebook, Google, or Square.

Once you are signed in, then you can choose between a business website or personal.

There are dozens of themes to choose from that you can customize to your liking.

In the Weebly editor, you can add media like videos, images, files and more. You can also add features like social icons, search boxes and forms.

Once you are done customizing your website, then you click on Publish located in the upper right hand corner.

SITE123

SITE123 was founded in 2015 and is a free website builder that gives you access to dozens of templates and layouts to choose from.

The free version comes with the following features:

• 250 MB Storage
• 250 MB Bandwidth
• 24/7 Live chat support

To get started, you can choose what kind of website you want to build.

You can choose your website name.

You can sign up with an email and password or with Facebook or Google. Once you are signed in then you can customize your website.

You can also preview what it would look like in desktop, tablet, or mobile view.

Once you are done editing your website, then you can publish it by clicking on the green publish button in the upper right hand corner.

If you are interested in adding a custom domain for your site, then you will need to pay for that.

Carrd

Carrd is a free website builder where you can browser through dozens of templates and create one-page websites.

You can create a free account by using your name, email, and password.

Once you are signed in, then you can choose from dozens of templates.

You can then modify the template by changing colors, fonts, and adding images.

When you are done editing your page, click on the publish option located in the upper right hand corner.

If you are interested in having custom domains, Google analytics, and custom forms, then you can sign up for the pro version.

I hope you enjoyed this article on free Website builders.

As someone who offers a service as a freelancer, you have a major say in how you price a website project.

But how do you go about charging for a website project?

Sure, you can bill by the hour, but is there a better way?

In this article, we are going to do an analysis of the different pricing options available to you as a developer to see which option is best for you.

But before we go over the different ways to charge for a website project, let's take a look at the factors that can help you decide how you price your web design services.

Here's a 20-min video if you'd like to get an overview:

What to Consider When Pricing your Website Project

Skills and Experience

The more skills and experience you have, the more clients are willing to pay.

I don't mind paying a few more bucks if I know that this individual or company produces world-class results.

Why settle for something cheap when you can go with a reasonable option because it would be of the best quality?

It might be true that some website projects can be done in a week or two, but it doesn't mean it's of any less value than those that take a month or more.

Remember that clients are paying for your skills and years of experience, not the amount of time the project takes to be built (more on this later).

Type and Complexity of Website

Your pricing depends on the type and complexity of websites you create.

Whether it's a personal blog, an e-commerce website, small or big business website, it requires time and effort.

Complex websites require more work and maintenance to keep them online.

Scope and Size

There are times when a project stretches beyond the initial timeframe required. In those cases, you might want to plan for this outcome or try to avoid such a situation.

Now let's move on to a few advantages and disadvantages to help you make a better informed decision on the pricing strategy you choose.

Hourly-Based Pricing

Hourly-based pricing is the most popular pricing method and the easiest to understand and start with.

I'm going to discuss the disadvantages of using an hourly-based pricing approach before I present its advantages and what I believe is a better method.

Hourly Billing Can be Harmful to Your Client Relationship

Billing by the hour has the potential to be harmful to your client relationship.

Why?

The longer a project takes, the better it is for you and the worse it is for your client.

If your estimates are inaccurate, this causes trust problems that weaken the relationship over time.

This can happen in a variety of ways, but it's amplified when the client doesn't realize how long it'll take to implement a feature or change, leading them to believe you're working slowly on purpose.

Another way this can happen is if the project takes longer than expected, because your client might feel that you're exploiting them. Your client will begin to evaluate the timesheets you supplied them in search of inconsistencies, and trust will be weakened.

Plus, it also produces so many issues.

Even if you can prove X task took 4 hours, they can dispute it and say it should have taken 1 hour.

Hourly Billing Discourages Efficiency and Innovation

You don't get rewarded for finding time-efficient ways to finish a project. If anything, you're getting financially punished.

Some websites can be completed in a few hours or a few days if you know what you're doing. If you're charging by the hour, what incentive do you have to find a way to complete the project in the shortest amount of time?

If you price your projects by the hour, you will, as a more experienced developer, get projects done sooner meaning you earn less per project.

So you think you make up for this by charging more per hour?

Well, this might only serve to scare your future (or even current) clients off to another developer who charges less per hour.

If anything, even if you don't do it intentionally, your work rate and efficiency will not be something you're too concerned about optimizing.

Besides, hourly work normally requires time and screen trackers.

Example:

Imagine you're working on a project that has similarities to a previous project you worked on or maybe there's a plugin or template you can use to cut your time spent on the project by half.

But by doing so, you'd cut down the number of hours you'd spend on your current project.

In this way, you've directly lowered your income because of a better, more efficient way to build a website.

Your Income is Capped

Hourly billing places an artificial limit on your income!

Let me explain.

There are only so many hours you can work in a year.

By providing a price per hour, you're limiting how much you're practically able to earn each year.

If you suddenly decided to increase your hourly rate because you'd like to start earning more as a freelancer, your existing clients will often not understand.

"Why," they ask, "are you suddenly valuing your services so much higher for the same work?"

Even before you explain whatever your reasoning is, you're entering the conversation with them on the back foot – they're feeling an inkling of mistrust.

Potential new clients will simply turn away and look for another freelancer who can offer them the same service at a lower hourly rate.

If you think you can just earn more by working more, ask yourself:

Is that sustainable? If so, do it.

But know that there will come a point where there are simply not more hours in the day to get more work done.

The other thing to consider is what if you're ill for 2 weeks?

What if you want to go on vacation for another 2 weeks of the year?

That's a whole month you just earned $0.

Sure, if you're charging massive hourly rates and you can save and make up for this loss, that's perfectly fine, but for the majority of 'hourly-billers', this can be a major problem.

Now before we on, let's go over some advantages of hourly pricing first so you can still weigh your options.

Being paid hourly is a benefit itself

The hourly wage rate has the advantage of paying an individual for the hours they work. If you work for 8 hours a day, for example, you will be paid for the entire 8 hours, and if you work overtime, you will be paid more and get additional income.

Work and life balance

Since you have a set amount of time to work in a day, you are able to maintain the balance between your work and life activities. Once the working hours are over, you're free to do anything and even jump on another project (if you can still manage your time).

Long-term projects and clients

Rather than short, intermittent employment, hourly rates are better for long-term projects and clientele. Hourly billing also makes it simple to account for project variations and adjustments.

Transitioning from hourly billing to value pricing is tricky (but worth it) and takes time if you're used to an hourly-based approach.

It requires a change in thinking, but, once you realize how ineffective it is to trade your time for money, you will find your profitability increasing.

Value-Based Pricing

The key takeaways about the difference between value-based and hourly-based pricing are these:

• In hourly-based pricing, you sell your time.
• In value-based pricing, you sell results.
• In hourly-based pricing, you ask what they want to be built.
• In value-based pricing, you ask why they want something built.

This makes all the difference and can be a real game-changer if you're switching from hourly-based pricing.

With the focus on results, there are a lot more advantages for you and the client.

When you and your client understand the "why" (the value gained), value-based price will make perfect sense.

Before we get into that, let's look at how value-based pricing works:

1. Find the potential value of a project to a client over a year.
2. Base your price off of those returns.

Example:

Let's say a business sells an average of ten 3D printers at an average of $2,000 each per month ($20k sales per month). Then, after calculating that, I could potentially increase sales by 30% month after month (based on experience or CRO knowledge). This would equal an extra three sales per month (or $6,000).

Even if we work on just 2 extra sales per month, it adds up to an extra $48,000 per year in additional revenue just by the changes and improvements I will be doing.

Therefore, charging $5,000 once-off for the website to potentially increase sales by almost $50,000 in one year is a no-brainer.

Let's look into the advantages of this approach:

Freedom To Make Great Websites

You can focus on creating something great without worrying about going over the client's budget or counting every hour.

This means you're not tied with any hourly work, trying to get over a day being productive when you're not really in the right mind to do the project, but you have to do something productive because your time is being tracked. It's also a common thing these days that your screen is being tracked, too.

Incentivized Learning

Not only does this approach encourage you to find the most optimal solution, but it also incentivizes you to stay up to date with the latest technologies and tools that make your workflow easier and more productive.

No Hidden Costs for the Client

Since you've agreed on the price upfront, you take on all the risk. This means the client will have no financial surprises down the line which helps facilitate trust. In other words, the client experiences less risk. And this often leads to fewer arguments.

Work with Clients That You Enjoy

The nature of value-based pricing means that you will likely be earning significantly more. You can now start working with fewer clients and provide a much better service while earning the same or more than you did while using hourly-based pricing.

Scope Creep Insurance

Once a project has been defined in terms of the business outcomes (for example, increased traffic, more sales) instead of deliverables (like change the font size of the navigation bar items, the password reset form needs ReCAPTCHA) it’s fairly easy to control scope. This is because business needs don’t change that often, and random requests from the client can be judged against the desired outcome.

The crucial factor with value-based pricing is this: It is up to you to make the business see your services as a necessary investment and not a cost.

You need to show them that you are the right person by explaining how both of you benefit from the pricing approach you're taking.

Bring their focus to the importance of results and what value the project will bring them.

Ultimately, this approach takes a lot of trial and error but trust the process and your future self will be thanking you.

By basing your value-based price on the client’s perceived value of the project outcome instead of your estimated labor, you can set your fees significantly higher, deliver more effective results, increase client satisfaction, and more.

Win-win.

Disadvantages of Value-Based Pricing

Well, there's only one, to be honest. That is the difference between you and your client.

It's not easy to communicate this pricing method because the value in your mind might be different from the value your client sees. There are even some instances where your client might feel that they didn't get the right result for the price they paid.

It might be challenging to apply this method at first, but you do get better the more you do it.

Remember:

You want to charge for your head, not your hands.

Smarts, not labor.

Results, not deliverables.

Outcomes, not activities.

Other Pricing Methods

Monthly Retainer

In a monthly retainer arrangement, the client pays you a set monthly price regardless of the quantity of work you complete in a month.

A lot of clients like retainers because they make budgeting easier for them. They know what they will get each month in exchange for a certain payment because the focus is on work and not hours.

Fixed Fee

A fixed-fee pricing strategy establishes a single price for all services. You can also create two or more fixed pricing options for your clients to choose from. There is a specified scope of work you will and will not complete.

Performance-Based Pricing

Performance-based pricing (also known as results-based pricing) is a sort of value-based pricing in which the price is determined by real performance measurements.

So, Which Pricing Method Should You Use?

The method you choose is up to you and, for many people, hourly-based pricing works perfectly fine. But for me, it's value-based pricing.

If you do choose to switch to a value-based approach, remember that this new approach will take some getting used to but it will certainly be worth it in the long run.

Try experimenting on your own and combine a few methods to determine the right pricing for your freelancing services.

I hope you found value from this article.

Until next time,

Kyle

“So can you distinguish between a static web page and a dynamic web page?”

What would your reaction be?

If you don’t know the answer to that question, or are struggling to think it up, then this article is for you.

If you're a beginner coder, you might have heard of the terms “static web pages” and “dynamic web pages” – but you might not know what they mean.

You might wonder what makes a web page static and what makes a web page dynamic.

In this article, I am going to tell you all you need to know – and why it's important. And, as usual, I will be doing so in plain English.

What is a Web Page?

First, we need to understand what a web page and a web site are and how they differ. To do that, let’s consider an encyclopedia.

An encyclopedia (like Wikipedia, for example) consists of many pages. Each page has its own content: A header, paragraph, images, diagrams, bullet points, lists, and of course, the definitions of the terms you're looking up.

It is very common in an encyclopedia to find words on the page which refer (or link) to another page for additional information.

This is very similar to web pages and web sites.

A web page is a single document which can contain text, images, hypertext, or any other elements. We create web pages using a markup language such as HyperText Markup Language – more commonly known as HTML.

HyperText is any web document which contains hyperlinks. A hyperlink is any element in the web page which, when you click on it, links to another web page.

These interconnected web pages forms an organised network of web pages, which we then call a website.

Every web page accessible on the internet must have its own URL. Here’s a typical URL of a web page:

www.freecodecamp.org/news

N/B: In case you are wondering, the page that the above URL returns is a dynamic page. Don’t worry, we will find out what that means very shortly.

Now, I have a simple test for you:

Open your web browser. Navigate to the address bar and type in (or select) any random but valid URL you know. Hit enter and wait. A web page will be rendered on your browser window. Take a snapshot of the current state of the web page and close it.

Wait for some time, and then visit that URL again. Then answer the following questions:

• If you compare the current state of the page to its previous state, are there any differences in its content?

• Does the page’s URL ends with a document extension /.html for example) or did it end with an endpoint? /profile for example)

• Assuming you change your browser settings (like clearing cookies, for example), does hitting the same URL returns a different page?

• Are you prompted to submit a form before having the page rendered on your browser?

How you answer these questions (and a couple more I will ask below) will determine whether the page is a static one or a dynamic one.

What is a Static Page?

A static page has the following characteristics:

• The page is already present even before a user requests it. A static page must be already physically present and hydrated (i.e with content) by the time a user makes a request for it. If it is not present, then it is not static.

• The page generally maintains the same content every time the user requests it. If hitting the same URL returns different content, then that page is not static at all. This is not to say static pages cannot be modified. But the only way to change a static page for the creator to manually edit the content (like an HTML document)

Here's an example of a static page:

www.example.com/about.html

What is a Dynamic Page?

A dynamic page has the following characteristics:

• The page is not physically present on the server when the user makes a request for it

• Instead, when a user makes a request a script or program runs and ultimately cooks up a web page. It does this by interacting with a database to retrieve data which it packages and sends over as a page.

• On every request, every new page created may be different from the last.

This is because the page created is dependent on the user's information and the program. The creator does not have to manually edit the content, as with Static Web Pages.

So, for example, if a different user requests the same page, different content is returned.

Or maybe when a user changes a setting, a new page is returned.

Or maybe when the time changes, different content is returned.

To illustrate this in a more intuitive way, let’s take a look at two scenarios in a Restaurant:

You are hungry, so you decide to go to a restaurant to eat. You order a plate of Jollof Rice (a Nigerian food). Through the transparent glass window into the kitchen, you can see that the food is already cooked. All the waiter has to do is to go over there, get the meal, and bring it to you.

Now let's say that you order a plate of suya (Nigerian meat). Typically, the meat is not already available and has to be prepared for you on the spot. With the information you supply to the waiter (your budget, how many onions you want, etc) the cook puts together your portion for you.

The first scenario illustrates how a static page is rendered. The second scenario illustrates how a dynamic page is rendered.

Here's an example of a dynamic page:

www.example.com/courses

The /course URL is not a document extension, but rather it's an endpoint.

Making requests to that endpoint will trigger a program which will use the supplied user data (such as username and password) and probably some external variables (such as the time and date) to interact with database and ultimately create and return a newly formed web page.

This is also why I earlier said that freeCodeCamp's news page is dynamic – because the content changes as new articles are published.

That page never existed as a file on the server. Instead, it was created by the script that ran when the user requested it.

Wrapping Up

A web page is a single document which contains text, images, hypertext and other elements.

A hypertext is a web document which contains hyperlinks. A hyperlink links one web page with another.

A network of organized webpages that link to each other is called a website.

For a website to be considered static, every call to the same URL returns the same web page.

One the other hand, if the content changes a lot, then that web page is dynamic. A dynamic page also ends with an endpoint, not a filepath.

So that's it. Hopefully now you can distinguish between a static web page and a dynamic web page. I really hope you got something useful from this article.

If you want more, I recently started a weekly coding challenge series aimed at teaching beginners how to program in JavaScript. Check it out on my blog.

Thank you for reading and see you soon.

P/S: If you are learning JavaScript, I created an eBook which teaches 50 topics in JavaScript with hand-drawn digital notes. Check it out here.

Lighthouse is an open-source project from the Google Chrome team. It's used to analyze web page quality based on a set of modern, "user-centric" metrics.

When supporting websites that rely on organic search results for revenue, quality is critical. Performance, accessibility and general SEO best practices are major factors in search engine rankings.

Lighthouse provides a granular set of metrics that represent these factors and suggestions of improvement in reporting.

There are many ways of running Lighthouse, but in the real world you may want to compare reports regularly, especially in continuous change workflows. With that said, you might be wondering - how can I keep track of SEO, performance, and accessibility changes over time?

This post covers how to use Automated Lighthouse Check to analyze website quality over time. But keep in mind that there are many other Lighthouse integrations to choose from.

Saving Reports and Viewing Results in a Timeline

Lighthouse scoring is an interesting aspect of the tool that may feel a little dirty at first. Still, it can be a very useful point of comparison when looking at historical data.

The performance category in particular is quite complicated in its calculation of score and you can find a lot of great reading about the topic among others on web.dev.

Automated Lighthouse Check provides a means of manually triggering audits or establishing a schedule in which they run automatically throughout the day. These audits are saved in a database so you can visualize and analyze results at a historical level. You can actually drill into any report in time to see full details (see an example here).

For a guide to getting started with Automated Lighthouse Check, see the documentation.

Timeline view of Lighthouse scores

A historical list of Lighthouse audits

Lighthouse Automation in DevOps

Not only are there many useful cloud-based Lighthouse tools, but there are also many open-source projects that can be implemented in a variety of DevOps workflows. Some of these solutions support persistence of data in one form or another, to track historically.

Below are a few examples that I've contributed to.

• This post covers how to use Lighthouse in CircleCI. You can save reports as "artifacts" in CircleCI or upload to AWS S3 automatically.
• This post covers how to use Lighthouse in GitHub Actions. This solution also provides a way to save reports as "artifacts" (in GitHub) or upload to AWS S3 automatically.
• Lighthouse Persist is an NPM package that exposes the native Lighthouse API with additional options to set AWS S3 credentials so it can be used to upload reports automatically.

A few friends - Octocat, Jenkins, CircleCI

Conclusion

I hope this post was helpful in providing solutions for analyzing website quality historically. Help support your local developers by purchasing their software ?

But in all seriousness, I'd love any feedback about Automated Lighthouse Check... comments, suggestions, feature requests, etc. It's about a year old at the time of this writing and has recently been migrated to Kubernetes for high availability.

Automated Lighthouse Check provides free and premium plans.

I recently took on the task of creating a documentation site theme for two projects. Both projects needed the same basic features, but one uses Jekyll while the other uses Hugo.

In typical developer rationality, there was clearly only one option. I decided to create the same theme in both frameworks, and to give you, dear reader, a side-by-side comparison.

This post isn’t a comprehensive theme-building guide, but is rather intended to familiarize you with the process of building a theme in either generator. Here's what we'll cover:

• How theme files are organized
• Where to put content
• How templating works
• Creating a top-level menu with the pages object
• Creating a menu with nested links from a data list
• Putting the template together
• Creating styles
• How to configure and deploy to GitHub Pages

Here’s a crappy wireframe of the theme I’m going to create.

If you’re planning to build-along, it may be helpful to serve the theme locally as you build it – and both generators offer this functionality. For Jekyll, run jekyll serve, and for Hugo, hugo serve.

There are two main elements: the main content area, and the all-important sidebar menu. To create them, you’ll need template files that tell the site generator how to generate the HTML page. To organize theme template files in a sensible way, you first need to know what directory structure the site generator expects.

How theme files are organized

Jekyll supports gem-based themes, which users can install like any other Ruby gems. This method hides theme files in the gem, so for the purposes of this comparison, we aren’t using gem-based themes.

When you run jekyll new-theme <name>, Jekyll will scaffold a new theme for you. Here’s what those files look like:

.
├── assets
├── Gemfile
├── _includes
├── _layouts
│   ├── default.html
│   ├── page.html
│   └── post.html
├── LICENSE.txt
├── README.md
├── _sass
└── <name>.gemspec

The directory names are appropriately descriptive. The _includes directory is for small bits of code that you reuse in different places, in much the same way you’d put butter on everything. (Just me?)

The _layouts directory contains templates for different types of pages on your site. The _sass folder is for Sass files used to build your site’s stylesheet.

You can scaffold a new Hugo theme by running hugo new theme <name>. It has these files:

.
├── archetypes
│   └── default.md
├── layouts
│   ├── 404.html
│   ├── _default
│   │   ├── baseof.html
│   │   ├── list.html
│   │   └── single.html
│   ├── index.html
│   └── partials
│       ├── footer.html
│       ├── header.html
│       └── head.html
├── LICENSE
├── static
│   ├── css
│   └── js
└── theme.toml

You can see some similarities. Hugo’s page template files are tucked into layouts/. Note that the _default page type has files for a list.html and a single.html.

Unlike Jekyll, Hugo uses these specific file names to distinguish between list pages (like a page with links to all your blog posts on it) and single pages (like one of your blog posts). The layouts/partials/ directory contains the buttery reusable bits, and stylesheet files have a spot picked out in static/css/.

These directory structures aren’t set in stone, as both site generators allow some measure of customization. For example, Jekyll lets you define collections, and Hugo makes use of page bundles. These features let you organize your content multiple ways, but for now, let's look at where to put some simple pages.

Where to put content

To create a site menu that looks like this:

Introduction
    Getting Started
    Configuration
    Deploying
Advanced Usage
    All Configuration Settings
    Customizing
    Help and Support

You’ll need two sections (“Introduction” and “Advanced Usage”) containing their respective subsections.

Jekyll isn’t strict with its content location. It expects pages in the root of your site, and will build whatever’s there. Here’s how you might organize these pages in your Jekyll site root:

.
├── 404.html
├── assets
├── Gemfile
├── _includes
├── index.markdown
├── intro
│   ├── config.md
│   ├── deploy.md
│   ├── index.md
│   └── quickstart.md
├── _layouts
│   ├── default.html
│   ├── page.html
│   └── post.html
├── LICENSE.txt
├── README.md
├── _sass
├── <name>.gemspec
└── usage
    ├── customizing.md
    ├── index.md
    ├── settings.md
    └── support.md

You can change the location of the site source in your Jekyll configuration.

In Hugo, all rendered content is expected in the content/ folder. This prevents Hugo from trying to render pages you don’t want, such as 404.html, as site content. Here’s how you might organize your content/ directory in Hugo:

.
├── _index.md
├── intro
│   ├── config.md
│   ├── deploy.md
│   ├── _index.md
│   └── quickstart.md
└── usage
    ├── customizing.md
    ├── _index.md
    ├── settings.md
    └── support.md

To Hugo, _index.md and index.md mean different things. It can be helpful to know what kind of Page Bundle you want for each section: Leaf, which has no children, or Branch.

Now that you have some idea of where to put things, let’s look at how to build a page template.

How templating works

Jekyll page templates are built with the Liquid templating language. It uses braces to output variable content to a page, such as the page’s title: {{ page.title }}.

Hugo’s templates also use braces, but they’re built with Go Templates. The syntax is similar, but different: {{ .Title }}.

Both Liquid and Go Templates can handle logic. Liquid uses tags syntax to denote logic operations:

{% if user %}
  Hello {{ user.name }}!
{% endif %}

And Go Templates places its functions and arguments in its braces syntax:

{{ if .User }}
    Hello {{ .User }}!
{{ end }}

Templating languages allow you to build one skeleton HTML page, then tell the site generator to put variable content in areas you define. Let’s compare two possible default page templates for Jekyll and Hugo.

Jekyll’s scaffold default theme is bare, so we’ll look at their starter theme Minima. Here’s _layouts/default.html in Jekyll (Liquid):

<!DOCTYPE html>
<html lang="{{ page.lang | default: site.lang | default: "en" }}">

  {%- include head.html -%}

  <body>

    {%- include header.html -%}

    <main class="page-content" aria-label="Content">
      <div class="wrapper">
        {{ content }}
      </div>
    </main>

    {%- include footer.html -%}

  </body>

</html>

Here’s Hugo’s scaffold theme layouts/_default/baseof.html (Go Templates):

<!DOCTYPE html>
<html>
    {{- partial "head.html" . -}}
    <body>
        {{- partial "header.html" . -}}
        <div id="content">
        {{- block "main" . }}{{- end }}
        </div>
        {{- partial "footer.html" . -}}
    </body>
</html>

Different syntax, same idea. Both templates pull in reusable bits for head.html, header.html, and footer.html. These show up on a lot of pages, so it makes sense not to have to repeat yourself.

Both templates also have a spot for the main content, though the Jekyll template uses a variable ({{ content }}) while Hugo uses a block ({{- block "main" . }}{{- end }}). Blocks are just another way Hugo lets you define reusable bits.

Now that you know how templating works, you can build the sidebar menu for the theme.

Creating a top-level menu with the pages object

You can programmatically create a top-level menu from your pages. It will look like this:

Introduction
Advanced Usage

Let’s start with Jekyll. You can display links to site pages in your Liquid template by iterating through the site.pages object that Jekyll provides and building a list:

<ul>
    {% for page in site.pages %}
    <li><a href="{{ page.url | absolute_url }}">{{ page.title }}</a></li>
    {% endfor %}
</ul>

This returns all of the site’s pages, including all the ones that you might not want, like 404.html. You can filter for the pages you actually want with a couple more tags, such as conditionally including pages if they have a section: true parameter set:

<ul>
    {% for page in site.pages %}
    {%- if page.section -%}
    <li><a href="{{ page.url | absolute_url }}">{{ page.title }}</a></li>
    {%- endif -%}
    {% endfor %}
</ul>

You can achieve the same effect with slightly less code in Hugo. Loop through Hugo’s .Pages object using Go Template’s range action:

<ul>
{{ range .Pages }}
    <li>
        <a href="{{.Permalink}}">{{.Title}}</a>
    </li>
{{ end }}
</ul>

This template uses the .Pages object to return all the top-level pages in content/ of your Hugo site. Since Hugo uses a specific folder for the site content you want rendered, there’s no additional filtering necessary to build a simple menu of site pages.

Creating a menu with nested links from a data list

Both site generators can use a separately defined data list of links to render a menu in your template. This is more suitable for creating nested links, like this:

Introduction
    Getting Started
    Configuration
    Deploying
Advanced Usage
    All Configuration Settings
    Customizing
    Help and Support

Jekyll supports data files in a few formats, including YAML. Here’s the definition for the menu above in _data/menu.yml:

section:
  - page: Introduction
    url: /intro
    subsection:
      - page: Getting Started
        url: /intro/quickstart
      - page: Configuration
        url: /intro/config
      - page: Deploying
        url: /intro/deploy
  - page: Advanced Usage
    url: /usage
    subsection:
      - page: Customizing
        url: /usage/customizing
      - page: All Configuration Settings
        url: /usage/settings
      - page: Help and Support
        url: /usage/support

Here’s how to render the data in the sidebar template:

{% for a in site.data.menu.section %}
<a href="{{ a.url }}">{{ a.page }}</a>
<ul>
    {% for b in a.subsection %}
    <li><a href="{{ b.url }}">{{ b.page }}</a></li>
    {% endfor %}
</ul>
{% endfor %}

This method allows you to build a custom menu, two nesting levels deep. The nesting levels are limited by the for loops in the template. For a recursive version that handles further levels of nesting, see Nested tree navigation with recursion.

Hugo does something similar with its menu templates. You can define menu links in your Hugo site config, and even add useful properties that Hugo understands, like weighting. Here’s a definition of the menu above in config.yaml:

sectionPagesMenu: main

menu:  
  main:
    - identifier: intro
      name: Introduction
      url: /intro/
      weight: 1
    - name: Getting Started
      parent: intro
      url: /intro/quickstart/
      weight: 1
    - name: Configuration
      parent: intro
      url: /intro/config/
      weight: 2
    - name: Deploying
      parent: intro
      url: /intro/deploy/
      weight: 3
    - identifier: usage
      name: Advanced Usage
      url: /usage/
    - name: Customizing
      parent: usage
      url: /usage/customizing/
      weight: 2
    - name: All Configuration Settings
      parent: usage
      url: /usage/settings/
      weight: 1
    - name: Help and Support
      parent: usage
      url: /usage/support/
      weight: 3

Hugo uses the identifier, which must match the section name, along with the parent variable to handle nesting. Here’s how to render the menu in the sidebar template:

<ul>
    {{ range .Site.Menus.main }}
    {{ if .HasChildren }}
    <li>
        <a href="{{ .URL }}">{{ .Name }}</a>
    </li>
    <ul class="sub-menu">
        {{ range .Children }}
        <li>
            <a href="{{ .URL }}">{{ .Name }}</a>
        </li>
        {{ end }}
    </ul>
    {{ else }}
    <li>
        <a href="{{ .URL }}">{{ .Name }}</a>
    </li>
    {{ end }}
    {{ end }}
</ul>

The range function iterates over the menu data, and Hugo’s .Children variable handles nested pages for you.

Putting the template together

With your menu in your reusable sidebar bit (_includes/sidebar.html for Jekyll and partials/sidebar.html for Hugo), you can add it to the default.html template.

In Jekyll:

<!DOCTYPE html>
<html lang="{{ page.lang | default: site.lang | default: "en" }}">

{%- include head.html -%}

<body>
    {%- include sidebar.html -%}

    {%- include header.html -%}

    <div id="content" class="page-content" aria-label="Content">
        {{ content }}
    </div>

    {%- include footer.html -%}

</body>

</html>

In Hugo:

<!DOCTYPE html>
<html>
{{- partial "head.html" . -}}

<body>
    {{- partial "sidebar.html" . -}}

    {{- partial "header.html" . -}}
    <div id="content" class="page-content" aria-label="Content">
        {{- block "main" . }}{{- end }}
    </div>
    {{- partial "footer.html" . -}}
</body>

</html>

When the site is generated, each page will contain all the code from your sidebar.html.

Create a stylesheet

Both site generators accept Sass for creating CSS stylesheets. Jekyll has Sass processing built in, and Hugo uses Hugo Pipes. Both options have some quirks.

Sass and CSS in Jekyll

To process a Sass file in Jekyll, create your style definitions in the _sass directory. For example, in a file at _sass/style-definitions.scss:

$background-color: #eef !default;
$text-color: #111 !default;

body {
  background-color: $background-color;
  color: $text-color;
}

Jekyll won’t generate this file directly, as it only processes files with front matter. To create the end-result filepath for your site’s stylesheet, use a placeholder with empty front matter where you want the .css file to appear. For example, assets/css/style.scss. In this file, simply import your styles:

---
---

@import "style-definitions";

This rather hackish configuration has an upside: you can use Liquid template tags and variables in your placeholder file. This is a nice way to allow users to set variables from the site _config.yml, for example.

The resulting CSS stylesheet in your generated site has the path /assets/css/style.css. You can link to it in your site’s head.html using:

<link rel="stylesheet" href="{{ "/assets/css/style.css" | relative_url }}" media="screen">

Sass and Hugo Pipes in Hugo

Hugo uses Hugo Pipes to process Sass to CSS. You can achieve this by using Hugo’s asset processing function, resources.ToCSS, which expects a source in the assets/ directory. It takes the SCSS file as an argument.

With your style definitions in a Sass file at assets/sass/style.scss, here’s how to get, process, and link your Sass in your theme’s head.html:

{{ $style := resources.Get "/sass/style.scss" | resources.ToCSS }}
<link rel="stylesheet" href="{{ $style.RelPermalink }}" media="screen">

Hugo asset processing requires extended Hugo, which you may not have by default. You can get extended Hugo from the releases page.

Configure and deploy to GitHub Pages

Before your site generator can build your site, it needs a configuration file to set some necessary parameters. Configuration files live in the site root directory. Among other settings, you can declare the name of the theme to use when building the site.

Configure Jekyll

Here’s a minimal _config.yml for Jekyll:

title: Your awesome title
description: >- # this means to ignore newlines until "baseurl:"
  Write an awesome description for your new site here. You can edit this
  line in _config.yml. It will appear in your document head meta (for
  Google search results) and in your feed.xml site description.
baseurl: "" # the subpath of your site, e.g. /blog
url: "" # the base hostname & protocol for your site, e.g. http://example.com
theme: # for gem-based themes
remote_theme: # for themes hosted on GitHub, when used with GitHub Pages

With remote_theme, any Jekyll theme hosted on GitHub can be used with sites hosted on GitHub Pages.

Jekyll has a default configuration, so any parameters added to your configuration file will override the defaults. Here are additional configuration settings.

Configure Hugo

Here’s a minimal example of Hugo’s config.yml:

baseURL: https://example.com/ # The full domain your site will live at
languageCode: en-us
title: Hugo Docs Site
theme: # theme name

Hugo makes no assumptions, so if a necessary parameter is missing, you’ll see a warning when building or serving your site. Here are all configuration settings for Hugo.

Deploy to GitHub Pages

Both generators build your site with a command.

For Jekyll, use jekyll build. See further build options here.

For Hugo, use hugo. You can run hugo help or see further build options here.

You’ll have to choose the source for your GitHub Pages site. Once done, your site will update each time you push a new build. Of course, you can also automate your GitHub Pages build using GitHub Actions. Here’s one for building and deploying with Hugo, and one for building and deploying Jekyll.

Showtime!

All the substantial differences between these two generators are under the hood. All the same, let’s take a look at the finished themes, in two color variations.

Here’s Hugo:

Here's Jekyll:

Wait who won?

?

Both Hugo and Jekyll have their quirks and conveniences.

From this developer’s perspective, Jekyll is a workable choice for simple sites without complicated organizational needs. If you’re looking to render some one-page posts in an available theme and host with GitHub Pages, Jekyll will get you up and running fairly quickly.

Personally, I use Hugo. I like the organizational capabilities of its Page Bundles, and it’s backed by a dedicated and conscientious team that really seems to strive to facilitate convenience for their users. This is evident in Hugo’s many functions, and handy tricks like Image Processing and Shortcodes. They seem to release new fixes and versions about as often as I make a new cup of coffee - which, depending on your use case, may be fantastic, or annoying.

If you still can’t decide, don’t worry. The OpenGitDocs documentation theme I created is available for both Hugo and Jekyll. Start with one, switch later if you want. That’s the benefit of having options.

Are you doing this Node thing right on production? Let's see some common mistakes people make running Node on production (coming straight from my own projects - like codedamn) and how they can be mitigated.

You can use this as your checklist on production when you're deploying Node apps. Since this is a production-ready-practices article, a lot of them won't apply when you're developing apps on your local system.

Run node in cluster mode/separate node processes

Remember that Node is single threaded. It can delegate a lot of things (like HTTP requests and filesystem read/writes) to the OS which handles it in a multithreaded environment. But still, the code YOU write, the application logic, always runs in a single thread.

By running in a single thread, your Node process is always limited to only a single core on your machine. So if you have a server with multiple cores, you're wasting computation power running Node just once on your server.

What does "running Node just once" mean? You see, operating systems have a scheduler built into them which is responsible for how the execution of processes is distributed across the CPUs of the machine. When you run only 2 processes on a 2-core machine, the OS determines it is best to run both of the processes on separate cores to squeeze out maximum performance.

A similar thing needs to be done with Node. You have two options at this point:

1. Run Node in cluster mode - Cluster mode is an architecture which comes baked into Node itself. In simple words, Node forks more processes of its own and distributes load through a single master process.
2. Run Node processes independently - This option is slightly different from the above in the sense that you now do not have a master process controlling the child Node processes. This means that when you spawn different Node processes, they'll run completely independent of each other. No shared memory, no IPC, no communication, nada.

According to a stackoverflow answer, the latter (point 2) performs far better than the former (point 1) but is a little tricker to setup.

Why? Because in a Node app, not only is there application logic, but almost always when you're setting up servers in Node code you need to bind ports. And a single application codebase cannot bind the same port twice on the same OS.

This problem is, however, easily fixable. Environment variables, Docker containers, NGiNX frontend proxy, and so on are some of the solutions for this.

Rate Limiting your endpoints

Let's face it. Not everybody in the world has best intentions for your architecture. Sure, attacks like DDoS are simply very complicated to mitigate, and even giants like GitHub go down when something like that happens.

But the least you can do is prevent a script-kiddie from taking down your server just because you have an expensive API endpoint exposed from your server without any rate-limiting in place.

If you use Express with Node, there are 2 beautiful packages which work seamlessly together to rate limit traffic on Layer 7:

1. Express Rate Limit - https://www.npmjs.com/package/express-rate-limit
2. Express Slow Down - https://www.npmjs.com/package/express-slow-down

Express Slow Down actually adds incremental delay to your requests instead of dropping them. This way legit users, if they DDoS by accident (super activity of clicking buttons here and there), are simply slowed down and are not rate limited.

On the other hand, if there's a script-kiddie running scripts to take down the server, Express rate limiter monitors and rate limits that particular user, depending on the user IP, user account, or anything else you want.

Rate limiting could (should!) be applied on Layer 4 as well (Layer 4 means blocking traffic before discovering the contents of it - HTTP) through IP address. If you want, you can setup an NGiNX rule which blocks traffic on layer 4 and rejects the flood of traffic coming from a single IP, thus saving your server processes from overwhelming.

Use a frontend server for SSL termination

Node provides out of the box support for SSL handshakes with the browser using the https server module combined with the required SSL certs.

But let's be honest here, your application should not be concerned with SSL in the first place anyway. This is not something the application logic should do. Your Node code should only be responsible for what happens with the request, not the pre-processing and post-processing of data coming in and out of your server.

SSL termination refers to converting traffic from HTTPS to HTTP. And there are much better tools available than Node for that. I recommend NGiNX or HAProxy for it. Both have free versions available which get the job done and offload SSL termination from Node.

Use a frontend server for static file serving

Again, instead of using built in methods like express.static to serve static files, use frontend reverse proxy servers like NGiNX to serve static files from disk.

First of all, NGiNX can do that faster than Node (because it is built from scratch down to do only that). But it also offloads file serving from a single-threaded Node process which could use its clock cycles on something better.

Not only this – frontend proxy servers like NGiNX can also help you deliver content faster using GZIP compression. You can also set expiry headers, cache data, and much more, which is not something we should expect Node to do (however, Node can still do it).

Configure error handling

Proper error handling can save you from hours of debugging and trying to reproduce difficult bugs. On server, it is especially easy to setup architecture for error handling because you're the one running it. I recommend tools like Sentry with Node which records, reports, and emails you whenever the server crashes due to an error in the source code.

Once that is in place, now it is time to restart the server when it crashes so the whole site doesn't just go down for hours until you manually take it up again.

For this, you can use a process manager like PM2. Or even better, use a dockerized container environment with policies like restart: always with proper memory and disk limits setup.

Docker setup ensures that even if your container runs in OME, the process spins up again (which might not happen on a PM2 environment, as the OS might kill PM2 if there's a memory leak somewhere in a running process).

Configure logs properly

All the answers lie in logs. Server hacks, server crashes, suspicious user behavior, etc. For that, you have to make sure that:

1. Each and every request attempt is logged with the IP address/method of request/path accessed, basically as much information as you can log (except for private information like passwords and credit card information, of course)
2. This can be achieved through the morgan package
3. Setup file stream logs on production instead of console output. This is faster, easier to see and allows you to export logs to online log viewing services.
4. Not all log messages have equal weight. Some logs are just there for debugging, while if some are present, it might indicate a pants-on-fire situation (like a server hack or unauthorized access). Use winston-logger for logging different levels of logs.
5. Setup log rotation so that you don't get a log size in GBs after a month or so, when you see the server.
6. GZIP your log files after rotation. Text is cheap, and is highly compressible and easy to store. You should never face problem with text logs as long as they are compressed and you're running a server with a decent disk space (25GB+).

Conclusion

It is easy to take note of a few practices in production which could save you tears and hours of debugging later on. Make sure you follow these best practices and let me know what you think by saying Hi on my twitter handle.

If you liked this article, let's meet on social media. Here's my Instagram and Twitter. I'm super active, and would love to have a chat! Let's connect.

Peace!
Mehul

If you're hosting a static website in an S3 bucket and it's your first time buying a domain name, this simple guide is for you.

Summary - What You Need

Amazon S3

• Have an S3 bucket with the same name as your domain name
• Upload your website's code
• Allow public access
• Add a policy to enable S3 GetObject
• Enable static website hosting

Domain Name provider

• In your domain name's DNS Zone settings, delete all A records
• In DNS Zone settings, add www to subdomain and the S3 endpoint in hostname for CNAME records

Let's go through these steps one by one.

Step 1: Create an S3 bucket

Create an S3 bucket to host your files for your website

First you need to create a bucket for your website. The name for your bucket must be the same as your domain name. Let's say we bought the domain name www.clarkngo.net. Then my S3 bucket's name should be www.clarkngo.net as well.

After configuration, my endpoint should look similar to this:

http://www.clarkngo.net.s3-website-us-west-2.amazonaws.com

Go to your AWS console and login. Choose S3.

1. Click Buckets
2. Click Create bucket

3. Add your domain name in the bucket name

4. You may choose any Region

Creating the S3 bucket and general configuration

Follow the checkboxes below and click Create Bucket.

Only tick the following:

• Block public access to bucket and objects granted through new access control lists (ACLs)
• Block public access to bucket and objects granted through any access control lists (ACLs)

Uploading files to the S3 Bucket

1. Click Overview and Upload.

2. Upload your website files in Select Files

3. For Set permissions, hit Next.

4. For Set properties, hit Next. (The default is Standard S3.)

5. For Review, hit Upload.

Editing the Bucket Policy

1. Click Permissions, then Bucket Policy.

2. Add the policy. (Note: For your website you'll change arn:aws::s3:::www.clarkngo.net/*)

{
    "Version": "2012-10-17",
    "Id": "Policy1548223592786",
    "Statement": [
        {
            "Sid": "Stmt1548223591553",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::www.clarkngo.net/*"
        }
    ]
}

3. Hit Save.

Static website hosting

1. Click Properties, then Static website hosting.

2. Choose Use this bucket to host a website.

3. For Index document, type index.html.

4. For Error document, type index.html.

5. Hit Save.

Step 2: Add the S3 Endpoint to your Domain

Editing your DNS Zone

1. Login to your domain provider.
2. In this example, choose Name Servers/DNS, then Modify DNS Zone (or the equivalent).

3. Remove all A records in your domain. Usually it will have a default IP address for a 404 Not Found page.

4. Add a CNAME to point to the S3 Bucket:

5. add www for the Subdomain.

6. add www.clarkngo.net.s3-website-us-west-2.amazonaws.com (the S3 Endpoint) to the Hostname.

And you're done! Note that it might take a while for your new settings take effect.

Connect with me in LinkedIn here.

Sketch has long been the application of choice for UX and UI designers. But in the last four years, we have seen many new contenders for Sketch’s crown. Three of them that have made the biggest strides are Figma, Adobe XD, and InVision Studio.

These four tools have many pros in common but there are some differences too. For example, the first comparison, Adobe XD vs Sketch, makes sense especially since both have a similar interface which is user-friendly and has a minimalistic style.

In this article, I analyze how the most used design apps compete and what their unique features are using my experience acquired while working at Creative Tim.

Adobe XD

Adobe XD was developed and published by Adobe Inc. XD, released on 18 October 2017. It is a vector-based user experience design tool for web apps, mobile apps, and voice apps available for macOS and Windows. There are versions for iOS and Android as well that help you preview the result of your work directly on mobile devices.

XD also support website wireframing and creating simple interactive click-through prototypes. With the character and layout tools of Adobe XD, Elements can be easily created and individual objects can be exported.

The interface is kept relatively simple, with a toolbar that is aligned at the side, as well as the large artboard area.

Comparing Adobe XD vs Sketch makes sense especially because of this similar interface which is user-friendly and has a minimalistic style.

Sketch

Sketch is a vector graphics editor, developed by the Dutch company Bohemian Coding. Sketch was first released on 7 September 2010 for macOS. It won an Apple Design Award in 2012.

A key difference between Sketch and other vector graphics editors is that Sketch does not include print design features. Sketch is only available on macOS. This problem is partially solved by third party and handoff tools.

When Sketch first came out it completely disrupted the interface design space, but Adobe XD and Figma have recently come forward as new challengers. They offer unique functionality like prototyping and live collaboration.

I’ve recently been researching these tools for my side project, uxtools.co, and wanted to share what I believe the be the most noteworthy decision points. Also, from my point of view, learning to sketch is very useful and it does not take to much to become a Pro.

Figma

Figma came to the stage in 2016 with initial funding of $14M.

With its seamless user interface and sleek feature palette, the tool quickly became a notorious competitor to similar solutions in the field.

Designers from brands like Twitter, Microsoft, GitHub, and Dropbox swear by Figma as the ultimate UI design tool.

InVision Studio

InVision Studio is a new piece of software, released in 2019, that allows designers to build more advanced animation and micro-interactions. Studio also integrated with InVision’s link to Sketch via its Craft plugin.

InVision Studio has got a nice dark UI by default, that helps developers focus on the work to be done in the evening. However, with macOS Mojave, every app can look like this quite easily. When they created it, they were inspired by another design tool - I am thinking about the Sketch app.

Apps Comparison

1. Pricing

Budget can be a big deal when you’re working with your own resources. Some of these licenses have educational and promotional pricing (often 50% off), so don’t miss that part. For example, Figma will get you there for free as long as you're not working on a team.

• Figma: Free for individuals! You can have 3 projects for free, or you can upgrade to unlimited projects and team functionality for $12/month (billed annually).

• Sketch: $99 per license that gets you the Mac App for life and access to the next production versions of the app.

• Adobe XD: It offers free and paid plans, depending on an individual's or team's needs. Paid plans start at $9.99/month.

• InVision Studio: Free right now.

2. Platform

Though Sketch has been immensely popular, it forces designers to only use Mac, which alienates developers from accessing design files.

• Figma: Browser! Figma recently released a Mac app and Windows app (not offline-capable, though).

• Sketch: Mac only.

• Adobe XD: Mac and Windows. Subject to the same limitations as the CC suite.

• InVision Studio: Mac and Windows.

3. Live Collaboration

Nobody likes to send at the end of the day “version 3.0”, “version3.0.final”, “version3.0.final.final”. Live Collaboration can help us, especially live comments.

I imagine these were the same concerns that surrounded the release of the highly innovative Google Docs suite. Google Docs, however, turned the Microsoft Suite on its head with live collaboration, and now Figma is seeking to do the same thing with UI design.

• Figma: Yes! Not to mention being browser-based, it allows Windows and even Linux users to have a very polished design tool.

• Sketch: Not natively, but a plugin, Picnic, is looking to change that. Also, they have Sketch for Teams.

• Adobe XD: It offers real-time Coediting, launched at Adobe MAX 2019.

• InVision Studio: Not currently possible, but can generate share links.

Image: Figma - Argon Design System Pro

4. Handoff

Recently a few apps have been developed specifically to deliver specs (sizing, spacing, color) to developers, but design tools are starting to integrate this functionality natively.

• Figma: Because of live collaboration, developers can easily jump in (regardless of OS) and access the designs. Figma now neatly prints the handoff code for CSS, iOS, or Android in the right panel.

• Sketch: They've recently launched their own native developer handoff feature — Cloud Inspector. There’s even an entirely free alternative called Sketch measure that works just as well.

• Adobe XD: It offers design specs that allow a designer to create a shared link that contains measurements, assets, and automatically-generated CSS code snippets.

• InVision Studio: They have “Inspect Now”.

Image: Figma - Argon Design System Pro

5. Offline

This is so important. Some online apps can protect your information when Wifi goes down, but you need full access to open, use, and save from the app offline.

• Figma: No, in an AMA they stated they don't have any current plans to add it.

• Sketch: Sure.

• Adobe XD: Yep.

• InVision Studio: Yes.

Image: AdobeXD - Argon Dashboard Free

6. Prototyping

There are literally dozens of these apps nowadays, but they might become extinct as Adobe XD brings prototyping directly to the design tool. Keep your eye on these.

• Figma: Yes! It's very basic but feels like Adobe XD without the transitions. Also, there's a nice Framer integration.

• Sketch: Yes!

• Adobe XD: Yes, native prototyping within the app. Adobe XD also supports voice prototyping and keyboard/gamepad support.

• InVision Studio: Yes, you can create prototypes and animations.

Image: InVision Studio - Argon React Native

7. Symbols

Symbols can make your work easier. These have completely changed the design process. Forget building and duplicating list items over and over, let symbols do the work for you.

• Figma: Good to go. Symbols now have states, constraints, and overrides.

• Sketch: The symbol functionality in Sketch is very impressive, and continues to improve. Symbols can be updated across entire documents and can resize responsively (that means less work for you when changing screen sizes).

• Adobe XD: It offers components that can be used throughout a document as well as linked across documents. It also allows designers to create variations of a component for different interactions, known as component states.

• InVision Studio: they have components that are a close approximation to the symbol conventions found in other applications. Components in their final form will honor a broad, scalable hierarchy that allows designers to quickly build-up, mix, and match components intelligently across their designs.

Image: Sketch - Material Kit Pro

Conclusion

Sketch has a big disadvantage here because it is only available for Mac users. And as such, it lets tools like Figma and Adobe XD innovate beyond the basic necessities.

Also, in terms of design tools, Adobe XD provides a robust set of responsive while the Sketch doesn’t have this feature built-in (but it has many plugins). If your tool does something better than the other, it is often enough of a reason to switch over. The browser-based approach that Figma has taken is also something to behold.

When talking about Adobe XD vs Sketch, the first one’s future is looking very bright and will win over many Sketch users. InVision’s change of focus may ensure its survival but one thing is for certain - Adobe XD is here to stay. The Adobe powerhouse is strong, and smaller companies like InVision and Sketch will have to work hard to stay relevant in the future.

People usually prefer to design and work in just one place. If you’re a part of a team, then Figma is undoubtedly for you.

After all of that: first is Figma, second is Sketch, third is Adobe XD and fourth is InVision Studio.

Overall, when talking about the best design software, these four tools are extremely well-suited for modern designer needs.

Try all four out to see which one is better for your use cases. I hope this comparison - Adobe XD vs Sketch vs Figma vs InVision - helped you decide which design tool is better for you.

Resources:

https://www.figma.com/figma-vs-sketch/

https://uxtools.co/blog/sketch-vs-adobe-xd-vs-figma/

https://www.codeinwp.com/blog/figma-vs-sketch-vs-adobe-xd/

https://support.invisionapp.com/hc/en-us/sections/360004450191-Studio

https://helpx.adobe.com/ro/xd/help/components.html

https://www.sketch.com/docs/

Sandy wrangling

What is Google Tag Manager?

If you’ve ever worked with any kind of analytics software, or you have worked with a marketing team before, you’ve probably heard the word pixel thrown around. A pixel is literally what it sounds like: a 1x1 image that sends information to a server through an image request.

Google Analytics pixel request

Though pixels are still common, many teams have moved towards small javascript snippets that sit right along side the rest of your HTML. They will allow software like Google Analytics to run their own scripts on your page, sometimes even with a pixel backup, in the event that a browser doesn't run JavaScript.

Crazy Egg snippet

These pixels and snippets work great. But when you’re dealing with a bunch of them and they all use the same data, it might seem like you’re just adding to an unmanageable mess of single use code snippets that never feel like they’re in the right place.

Google Tag Manager, or GTM, is a software solution to manage these pixels and snippets for you. To start, GTM works pretty much like any of those other code snippets, as it’s a code snippet itself. But where it shines is that you get to manage the rest of those pixels and snippets along with the flow of data inside GTM, leaving it to be the only snippet to manage within your code.

Why do I want to use it?

Fewer code changes, Fewer deploys

Most of the time, if you’re managing these snippets in your code, each change will require another merge request and another deploy to get the changes out. Not only does this add more risk, as you need to make yet another change to the code, but this is additional time spent dealing with your deploy pipeline and making sure everything is working as it should be.

GTM allows you to break outside of that flow, giving you more flexibility to get changes out that could give some needed insight into fixing some UI errors or could add a few bucks to the bottom line.

More manageable data flow

Wrangling all the different variables throughout your application, making sure they’re all available in the right spot, and keeping up with avoiding breaking any changes can prove to be challenging. This also makes your code more fragile and prone to breaking.

Google Tag Manager utilizes what they call a dataLayer, which essentially functions like an array of events that it listens to. This allows you to push or seed new data to make available within GTM itself. And it means you’re funneling all of your variables to one spot in the code. This lets whoever manages GTM do the rest – they can use that data with peace of mind, knowing that your data flow won’t break after forgetting to update 1 out of 10 spots.

Ability to give marketers a little more access

This is an opportunity to free up some of your time by letting the marketing team deal with tag changes themselves rather than you being the middle man for them. Perhaps they need to adjust the ID for your analytics software or maybe they want to add Crazy Egg. With the right permissions (explained later), they can do all of the work and send the changes to you for review before publishing them.

How does this relate to Google Analytics?

There is no direct relation. But along with Google Analytics, GTM is another tool in the Google Marketing Platform and gives you the immediate ability to more easily manage your Google Analytics installation. GA comes with prebuilt tags inside GTM that make it a breeze to set up.

What else can I use this for?

Google Analytics is just one of many code snippets this can be used for. Ideally, you’re not going to write your entire site here. But you have the ability to pretty much do whatever you want on your own site as long as Google doesn’t deem it malware.

Some other use cases include:

• Traffic visualization with Crazy Egg or Hot Jar
• Conversion and remarketing pixels with Google Ads
• A/B Testing with Google Optimize or AB Tasty
• Client side error tracking (and logging them)
• GDPR compliance management

There are many baked-in like the examples above, meaning you don’t even need to mess with code. Just add the IDs or settings and go. But for whatever custom solution or tag you need, you can always set up the HTML manually.

Anything I need to know before jumping in?

Before jumping right in, let’s familiarize ourselves with a few key terms that will make this ride a little easier.

Tags

Tags in GTM are your pixels or code snippets. A tag includes a single instance of a contained piece of code that is used for one function.

Example: your Google Analytics snippet will be one tag and if you add Crazy Egg, that will be another tag.

Variables

A variable is a name that you give a predetermined or dynamic value. The variable can be based on a variety of different things, hence the name “variable”. But it will function as a single name that you can give and reference that will never change when using it.

Example: we’ll set up your Google Analytics ID as a variable, meaning you’ll use that variable within the GA tag itself. If you ever need to update that ID, you won’t need to modify the tag or any other tags that use the variable – you’ll only need to update the variable itself.

Triggers

Triggers are the event or action that make your tag fire or load. This can happen in a variety of ways, such as when all or a specific page loads, when something is clicked, or when you have a completely custom event you fire with Javascript.

Example: when we set up Google Analytics, our trigger will be when any page loads.

Container

GTM allows you to manage multiple “containers” or groups of tags within your organization. This is helpful when you have one company with a few different website properties.

Example: you’re a small company under a parent company. The parent company wants to maintain one organization, but each smaller company gets their own container, as they have their individual needs for tags and code snippets.

How do I get set up?

Getting your account set up

The first thing you’ll need to do is get your account set up. After getting to the tag manager homepage, you’ll probably want to use your preexisting Google account. If you’re in an organization setting it up for the organization, you most likely want to use your business email, otherwise your personal account works okay too.

Next, create a new GTM account:

Google Tag Manager new account

Once there, fill out the form appropriately. The Account Name should represent the top level of your hierarchy and the container name should represent the specific installation instance.

Google Tag Manager new account container

As for the target platform, choose whichever makes sense. If it’s a website or web app, Web makes the most sense here.

Finding and installing your snippet

As soon as you accept the terms and hit create, you’ll be presented with a snippet in a little modal. You'll want to do exactly what it says and install the snippets per the instructions.

Google Tag Manager install snippet

Didn’t get the screen or accidentally exited out? You can find your snippet again by navigating to Admin in the top navbar and then click Install Google Tag Manager under Container to the right.

Testing that it’s working

To make sure it’s working, let’s verify a few things:

• We created our account
• We created our container
• We installed the Google Tag Manager snippets on our page and the change are live

Once all of those things are true, go ahead and click the Preview button in the top right of the page.

Google Tag Manager preview

If successful, you’ll now see an orange banner at the top of the page that says you’re in Preview Mode:

Google Tag Manager preview mode

Now wander over to the website that you installed GTM on and you should now see a banner at the bottom of the page. This will serve as your Debugger for working with GTM’s Preview.

Google Tag Manager debugger

You should see something similar to that, which means it worked! ?

Note: if you have an ad blocker on, similar to GA, you may need to disable it on the page you’re installing on in order to see it working.

Cool, it’s working, what about Google Analytics?

Now that we have a basic installation of GTM working, let’s set up Google Analytics. First we'll want to do some prep, so let's jump back over to the Tag Manager dashboard.

Create a settings variable

Navigate to Variables in the left sidebar and then click New beside User-Defined Variables.

Google Tag Manager new variable

For the name, enter “GA Settings” and under Variable Type, click through and select Google Analytics Settings. Enter your Google Analytics Tracking ID (or Property ID) in the appropriate field, and finally click Save, at which point you have your new settings variable.

Create a new GA tag

Navigate to Tags in the left sidebar and then click New beside Tags.

Google Tag Manager new tag

For the name, enter “GA - All Pages”. Under Tag Type, click and select Google Analytics: Universal Analytics in the panel that pops out from the right.

After selecting the tag type, under Google Analytics Settings, select your variable from the previous step, which if you followed along will be called “GA Settings”.

Next, click in the middle of the Triggering box, which should open a new UI to select a trigger.

Google Tag Manager trigger

Select All Pages, which should be the only Trigger there if you’re in a new account. It will take you back to the New Tag UI with your newly selected trigger.

Once the above is done, click Save in the top right of the UI which will then save and create your new Google Analytics tag.

Test that GTM is working

Similar to when we installed GTM to begin with, let’s go back to the Workspace home by clicking Overview in the left sidebar. Then click Preview at the top right.

Google Tag Manager debugger with Google Analytics

Open up your page GTM is installed on and you should once again see your Debugger, but this time with the Google Analytics Tag loading.

Are we done yet?

Not quite. Although we have GA working, we need to tweak the configuration to make sure GA and GTM work correctly together.

Updating the page snippet

Let’s dig into the code one more time to update our Google Analytics and Google Tag Manager snippets.

The issue with the installation that we set up here is that we installed GA through the GA instructions and GA inside GTM. This means we have GA installed twice. In practice, GA may send 1 pageview from your default installation and then another via GTM. To avoid this, we want to remove the pageview from the default GA snippet.

If you just have a super basic default installation, I did the work for you and you can go ahead and copy the snippet below. Replace [YOUR GA PROPERTY ID] with your GA Property ID and [YOUR GTM CONTAINER ID] with your GTM Container ID, and swap it out for your existing GA and GTM installation on your page.

<script>
// Set up an initial dataLayer configuration
window.dataLayer = window.dataLayer || [{
  "gaPropertyId": "[YOUR GA PROPERTY ID]"
}];

// Configure gtag and your GA ID
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', '[YOUR GA PROPERTY ID]');

// Google Tag Manager snippet
(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl+'&gtm_cookies_win=x';f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer', '[YOUR GTM CONTAINER ID]');
</script>

This should REPLACE your current Google Analytics snippet if you have one. If you don't, this should go as far in the top of your <head> tag as you can, but under the charset meta tag.

For more advanced users, just make sure you’re not sending duplicate pageviews or duplicate events between the page snippet and any GTM tag you create.

Test that GA is working

Follow the steps above to make sure GA is showing up with the debugger.

The final thing you’ll want to do is make sure your installation is working using Google’s Tag Assistant extension. Once you install the extension, go back to your page and click Enable in the Extension’s UI.

Google Tag Assistant enable recording

Refresh the page and you should see 2 tags, GA and GTM.

Google Tag Assistant results

If you notice, my GA tag is blue and yours may be too. Click in to Google Analytics for more info.

Google Tag Assistant non-standard implementation

As you can see, we have a healthy 1 Pageview Request and a note that says Non-standard implementation (hence the blue) This is because we installed it with GTM instead of the default on page.

Publish and Deploy!

We’re there! Last step is to Publish your Container and make the changes live.

Google Tag Manager submit version

Click Submit in the Overview UI, enter a name and description.

Google Tag Manager version configuration

Finally click Publish and your changes will be live on your site!

What else do I need to know?

There’s plenty more to talk through, but that’s for a different day. There are a ton of resources online to get you started with adding your own new tags and exploring the capabilities of Google Analytics, but here are a few points to keep in mind with GTM.

Permissions

You most likely don’t want every marketer on your 1,000 person team to have publish access to your GTM container. It’s best to have one or a few people responsible for managing the container, reviewing, and publishing while keeping everyone else to a lower access role. This will help prevent accidental changes or abuse within a bigger team.

Security

Permissions are your first step towards maintaining a secure installation. But Google takes this an extra step and performs some actions for you, such as checking for code errors and scanning for malware. While this is great, it’s still important to keep an active review cycle of tags getting published, just like any other pieces of code, to make sure the site integrity and health remain in tact.

Conventions

I highly recommend starting early with naming conventions and best practices when configuring your tags, variables, triggers, and really anything within GTM. The different ways to name things can spiral out of control really quickly, depending on how many people are working in there. This will make your work difficult to find, so it’s best to agree with the team on a convention to use early and get off on the right foot.

Single Page Apps

This doesn’t account for the impact single page apps have on a GTM and GA setup. The trigger we set up here will fire when any page loads, which is defined by a new page load by the browser. Single page apps don’t actually load a new page – rather, the JavaScript within the app makes it appear that a new page loads, so the trigger here will only fire the first pageview. Though it doesn’t include information directly usable in GTM, the GA documentation has some good information about tracking these types of apps.

GDPR

While GTM alone does not (currently) violate GDPR, you still need to be cognizant of how any of the tags you use impact your standing. This guide doesn’t touch this, so please make sure to do your homework.

Exiting out of Debugger

Stuck? One way is to clear your cookies, but you should always be able to go to the GTM Overview page and hit "Leave Preview Mode” right under the orange Preview Mode banner at the top of the page.

What's next?

From here, you can start managing your tags and pixels through GTM, which allows you to have a single source of consistent data flow into those tags. Experiment and use the debugger to play around, as it opens the door for a lot of new ways to work with the marketing side of things.

Originally published at https://www.colbyfayock.com/2019/11/how-to-use-google-tag-manager-to-maintain-google-analytics-and-other-marketing-tags

How I Learned to Code and Got My First Job

My coding journey began about two and a half years ago, and I started working my first full-time developer job recently (wooo!). This might seem like a long time for some of you, but I didn't rush it and wasn't trying to find work until two months ago. Many people have done it more quickly and I was probably ready for a while. So I've decided to share my story, my resources, and what worked for me when learning web development.

How I got interested in coding

I was living in Thailand, training and fighting Muay Thai while working about 10 hours a week as a social media manager. I wasn't really enjoying marketing as a career and it wasn't as flexible as I wished, since I needed to be active at certain hours of the day.

Luckily I had the time to learn something new. I'd looked at a few things online which sounded like good skills to have that were flexible and that could be done remotely. But it wasn't until I met a guy traveling through Vietnam, who was working as a web developer, that I was intrigued and started to play around a little bit with coding.

Where To Learn?

At first, I was jumping around trying out different sites such as Codecademy, freeCodeCamp, and others I can't recall. I never really got anywhere with these to start with but they got me interested.

After researching, I decided to take CS50 - Introduction To Computer Science, a famous Harvard course run by David Malan. It teaches the real basics of computer science such as data structures, algorithms, and the relevant workings of a computer. This is all done in C but the basics you learn and the confidence you build apply to every language.

Once I completed CS50 I started on freeCodeCamp. What I loved about freeCodeCamp most was the projects. They give you great ideas to practice and test your skills as you are learning. Once I got through the first couple of sections on HTML/CSS/JavaScript and onto more advanced topics, I didn't find the lessons thorough enough. So I ditched them for Udemy courses which went more in depth on a topic. Then I could go back and build the freeCodeCamp projects for practice.

I used this combination of Udemy and freeCodeCamp until I had a solid grasp of HTML, CSS, JavaScript, Node, React, and Redux. I also completed all of the projects on freeCodeCamp except for the data visualisation section using D3.js, as I didn't find this skill in demand when looking at jobs.

What Next?

Although I was confident in these skills, I still hadn't gotten involved in open source except for a couple of tiny pull requests. I simply didn't know where to get started. Every time I looked at issues I couldn't see anything interesting. Or those that were interesting had already been claimed by someone else.

Eventually, I got involved with freeCodeCamp as a contributor. I would recommend just making a habit of checking the issues once a week or so to see if there's something that you want to help with.

Along with my work with open source, I also got an internship as a front-end developer focused on React. It wasn't the ideal internship but it was remote and I learned a lot by working on a codebase someone else had built. I was the only dev on the front-end. This presented it's own challenges, like being given a problem and being responsible for researching and solving it. In this time, I learned about and implemented internationalisation as well as React Native.

Getting the Job

I had a strong mix of skills, projects and experience to show off, my résumé in hand, and a portfolio site promoting my work. I was ready!

Getting the job was mostly a game of patience. All together it took me 2 months of searching and applying every day to jobs. Most of the time I didn't hear back. I applied for a lot of jobs which were looking for mid level developers or more experience than I had, which didn't work out. Most of the jobs I found on job boards were advertised by recruiters and I found these the most fruitful. I often received a call and meeting with recruiters who were impressed by my résumé and skills and were looking for junior roles for me.

I was also attending meetups to network and look for jobs. I didn't find any roles directly, as the companies weren't looking for juniors. However, I did meet a recruiter at a React meetup whom I grabbed coffee with the next week. He had a role from a company that was open to juniors and this is where I ended up accepting a position.

The hiring process for this position consisted of a tech test (https://github.com/GlynL/tech-test-prendi), and then an interview where I was actually offered the job at the end. It's a great small company where I'm working with the senior developer and can bounce ideas and get help when I need it. It's a full-stack job, I get to use React daily, and I will get the chance to work with a lot of technologies as projects require them.

When I was interviewing, the thing that people appreciated most was that I had worked on a real application in an internship. Even if I could have done everything in a personal project it proved that I could work on a real world application with other people. I would certainly recommend seeking out internships as this will look great on your résumé and will be a talking point during interviews.

What would I do differently?

If I were to do it all over again, there's a couple of things I would do differently.

For starters, I would get more involved with open source projects much earlier on. There's always something you can contribute to a project even if you are still learning HTML and CSS. You may have to be more particular about the issues you pick up but you can definitely help! The skills you gain in navigating a large codebase and working with others are invaluable. And as you learn more you can pick more complex issues to match your skills.

Secondly, I would also start networking earlier as this might've led to securing internships and/or junior positions. If people know you are searching for an opportunity then they will think of you when they have something. Or it'll at least give you an advantage in the application process as they will know who you are and that you have a genuine interest in the field.

Please feel free to let me know if you have any questions or would like me to elaborate on any of the points. I'd be happy to help!

You can contact and connect with me on Twitter @glynwebdev.

Fun fact: I first launched my GitHub Pages site 1,018 days ago.

Since then, we’ve grown together. From early cringe-worthy commit messages, through eighty-six versions of Hugo, and up until last week, a less-than-streamlined multi-app continuous integration and deployment (CI/CD) workflow.

If you know me at all, you know I love to automate things. I’ve been using a combination of AWS Lambda, Netlify, and Travis CI to automatically build and publish this site. My workflow for the task includes:

• Build with Hugo on push to master, and on a schedule (Netlify and Lambda);
• Optimize and resize images (Netlify);
• Test with HTMLProofer (Travis CI); and
• Deploy to my separate, public, GitHub Pages repository (Netlify).

Thanks to the introduction of GitHub Actions, I’m able to do all the above with just one portable Makefile.

Next week I’ll cover my Actions set up; today, I’ll take you through the nitty-gritty of my Makefile so you can write your own.

Makefile portability

POSIX-standard-flavour Make runs on every Unix-like system out there. Make derivatives, such as GNU Make and several flavours of BSD Make also run on Unix-like systems, though their particular use requires installing the respective program. To write a truly portable Makefile, mine follows the POSIX standard. (For a more thorough summation of POSIX-compatible Makefiles, I found this article helpful: A Tutorial on Portable Makefiles.) I run Ubuntu, so I’ve tested the portability aspect using the BSD Make programs bmake, pmake, and fmake. Compatibility with non-Unix-like systems is a little more complicated, since shell commands differ. With derivatives such as Nmake, it’s better to write a separate Makefile with appropriate Windows commands.

While much of my particular use case could be achieved with shell scripting, I find Make offers some worthwhile advantages. I enjoy the ease of using variables and macros, and the modularity of rules when it comes to organizing my steps.

The writing of rules mostly comes down to shell commands, which is the main reason Makefiles are as portable as they are. The best part is that you can do pretty much anything in a terminal, and certainly handle all the workflow steps listed above.

My continuous deployment Makefile

Here’s the portable Makefile that handles my workflow. Yes, I put emojis in there. I’m a monster.

.POSIX:
DESTDIR=public
HUGO_VERSION=0.58.3

OPTIMIZE = find $(DESTDIR) -not -path "*/static/*" \( -name '*.png' -o -name '*.jpg' -o -name '*.jpeg' \) -print0 | \
xargs -0 -P8 -n2 mogrify -strip -thumbnail '1000>'

.PHONY: all
all: get_repository clean get build test deploy

.PHONY: get_repository
get_repository:
    @echo "? Getting Pages repository"
    git clone https://github.com/victoriadrake/victoriadrake.github.io.git $(DESTDIR)

.PHONY: clean
clean:
    @echo "? Cleaning old build"
    cd $(DESTDIR) && rm -rf *

.PHONY: get
get:
    @echo "❓ Checking for hugo"
    @if ! [ -x "$$(command -v hugo)" ]; then\
        echo "? Getting Hugo";\
        wget -q -P tmp/ https://github.com/gohugoio/hugo/releases/download/v$(HUGO_VERSION)/hugo_extended_$(HUGO_VERSION)_Linux-64bit.tar.gz;\
        tar xf tmp/hugo_extended_$(HUGO_VERSION)_Linux-64bit.tar.gz -C tmp/;\
        sudo mv -f tmp/hugo /usr/bin/;\
        rm -rf tmp/;\
        hugo version;\
    fi

.PHONY: build
build:
    @echo "? Generating site"
    hugo --gc --minify -d $(DESTDIR)

    @echo "? Optimizing images"
    $(OPTIMIZE)

.PHONY: test
test:
    @echo "? Testing HTML"
    docker run -v $(GITHUB_WORKSPACE)/$(DESTDIR)/:/mnt 18fgsa/html-proofer mnt --disable-external

.PHONY: deploy
deploy:
    @echo "? Preparing commit"
    @cd $(DESTDIR) \
    && git config user.email "hello@victoria.dev" \
    && git config user.name "Victoria via GitHub Actions" \
    && git add . \
    && git status \
    && git commit -m "? CD bot is helping" \
    && git push -f -q https://$(TOKEN)@github.com/victoriadrake/victoriadrake.github.io.git master
    @echo "? Site is deployed!"

Sequentially, this workflow:

1. Clones the public Pages repository;
2. Cleans (deletes) the previous build files;
3. Downloads and installs the specified version of Hugo, if Hugo is not already present;
4. Builds the site;
5. Optimizes images;
6. Tests the built site with HTMLProofer, and
7. Prepares a new commit and pushes to the public Pages repository.

If you’re familiar with command line, most of this may look familiar. Here are a couple bits that might warrant a little explanation.

Checking if a program is already installed

I think this bit is pretty tidy:

if ! [ -x "$$(command -v hugo)" ]; then\
...
fi

I use a negated if conditional in conjunction with command -v to check if an executable (-x) called hugo exists. If one is not present, the script gets the specified version of Hugo and installs it. This Stack Overflow answer has a nice summation of why command -v is a more portable choice than which.

Image optimization

My Makefile uses mogrify to batch resize and compress images in particular folders. It finds them automatically using the file extension, and only modifies images that are larger than the target size of 1000px in any dimension. I wrote more about the batch-processing one-liner in this post.

There are a few different ways to achieve this same task, one of which, theoretically, is to take advantage of Make’s suffix rules to run commands only on image files. I find the shell script to be more readable.

Using Dockerized HTMLProofer

HTMLProofer is installed with gem, and uses Ruby and Nokogiri, which adds up to a lot of installation time for a CI workflow. Thankfully, 18F has a Dockerized version that is much faster to implement. Its usage requires starting the container with the built site directory mounted as a data volume, which is easily achieved by appending to the docker run command.

docker run -v /absolute/path/to/site/:/mounted-site 18fgsa/html-proofer /mounted-site

In my Makefile, I specify the absolute site path using the default environment variable GITHUB_WORKSPACE. I’ll dive into this and other GitHub Actions features in the next post.

In the meantime, happy Making!

I’m going to cover a few things here. If you’re already familiar with the basics, feel free to skip around:

• What is Google Analytics? (A quick overview)
• Okay, so where do I start? (Quick start install guide)
• What are some quick insights? (Basic out of the box reports)
• Bonus: Advanced Insights (Custom Dimensions)

So let’s start from the top.

What is Google Analytics?

Google Analytics gives you the tools you need to better understand your customers. You can then use those business insights to take action, such as improving your website, creating tailored audience lists, and more. - Google's official documentation

More simply put, Google Analytics (GA) is a web analytics service provided by Google on the Google Marketing Platform. It allows you to track and measure your website’s traffic with powerful insights and reports.

GA can work a few different ways, but the most common is using a quick drop-in JavaScript snippet that goes on every page of your website (typically the <head>).

Google Analytics lets you measure user interaction with websites.

The base version of Google Analytics is free. You have the option of upgrading to the 360 suite, which will open up some feature limits, but most of you probably don’t need this as it is more geared towards high traffic websites.

Why do I need Google Analytics?

You don’t need it. But you can get an incredible amount of insight from GA with even a basic out of the box setup.

GA is helpful if you're a developer trying to get more traffic out of your blog, or a business trying to optimize your sales funnel.

GA helps you answer simple questions like:

• Where is my traffic coming from?
• What pages get the most traffic?
• What are the most popular devices people visit on?

Not only can this help you make better-educated decisions with your website. It can also help you unveil user experience concerns, or save money due to site issues by keeping an eye on traffic trends and user interactions.

Okay, so where do I start?

Google makes it’s fairly easy for any developer to jump in and get started. The only real prerequisite is that you set up an account. Google themselves offers a great step-by-step and constantly updated guide, so I’ll leave it to them.

Getting the tag on your page

Once you’re logged into the Google Analytics Dashboard, go to the Admin section, which you can find on the left hand side of the page:

Admin link in the Google Analytics Dashboard

Once in the admin section, you can navigate to Tracking Info then Tracking code under the property you want to track.

Tracking code link in the Google Analytics Admin

Finally, you can find the JavaScript snippet that you can throw in the head of your website. Remember, this should be on ALL pages.

Google Analytic tracking code snippet

Let the traffic flow

From here you just have to give it time. Google Analytics won’t have historical data, it will only have the the new traffic that hit your page once the snippet was installed.

You can check it’s working by visiting the Realtime Report and either hitting the page in another tab or seeing your visitors hit the page.

Google Analytics Realtime Report

More settings, more configuration

Google Analytics is a complex machine and can do a lot. Start slow and try to understand what’s happening before moving too fast turning every different switch.

Once you're comfortable, there are a lot of great guides out there for beginners and advanced users alike to unleash the full power of your reporting capabilities.

Goku going Super Saiyan

What are some quick insights?

Cool, so you have GA installed, you see your traffic, and you’re ready to get started looking at your reports, but where to begin?

What pages get the most traffic?

Let’s start with a simple one. Which pages of my website are getting the most traffic? To find this out we’ll want to view the Behavior Overview, which we can find by visiting Behavior then Overview.

Finding top page on Google Analytics Behavior Overview Report

Above we’re looking at the full month of August, which you can change with the date picker in the top right of the report. We can see overall, we had 3,853,265 total pageviews and 121,187 of them were to /news, the freeCodeCamp News homepage, which was our most popular page of the month.

Where is my traffic coming from?

A common question is: “where are people coming from?” How are people actually finding my website? This is a 2 parter, let’s start with overall traffic.

A good way to start is by finding the Acquisition Overview page. You can navigate there by selecting Acquisition than Overview.

Finding top traffic source on Google Analytics Acquisition Overview Report

Shown above, the majority of traffic comes from organic searches on Google, a little over 75% in fact. That’s some good SEO!

Outstanding Move

But what if we wanted to see how people are getting to a particular post? This involves a little more work, but let’s dive in.

Let’s go back to Behavior in the sidebar, then Site Content, and finally Landing Pages. Once there, you can use the search to find your post as shown below and select it.

Searching for a page on the Google Analytics Landing Page Report

After you found your post, we’re going to add a Secondary dimension. In particular, we’ll want to find and select “Source / Medium” in the Secondary dimension dropdown.

Adding a Secondary dimension on the Google Analytics Landing Page Report

Finally we’ll have an idea of where people are coming from to visit our post.

Finding the top Source / Medium on the Google Analytics Landing Page Report

It seems like this is following the trend of great Organic SEO. If you notice though, we have “(direct) / (none)” as the second highest source / medium.

Unfortunately, it’s not always that easy. And if Google Analytics can’t figure out where the user came from, it will mark it as “(direct) / (none)”. While that’s solvable, and sometimes actually means something, we can see the majority comes from simple searches on Google itself.

What are the most popular devices people visit on?

Understanding what devices your visitors are using is an incredibly helpful tool for optimizing User Experience, as well as maximizing potential revenue by making sure your site works.

In a perfect world, your website would work in all browsers. But we may be able to safely rule out certain older browsers.

Internet Explorer behind a tree

To get started, find your way to Audience then Overview. Once there, select Browsers in the list as shown below.

Finding the top browser in the Google Analytics Acquisition Report

We can see that luckily, our top browsers are dominated by modern ones, with Chrome carrying a cool 76.42%.

But wait, Internet Explorer is pulling 1.06% or 22,499, which isn’t something to bat an eye at. So let’s dig in a little more by clicking on Internet Explorer.

Finding the traffic for Internet Explorer versions in the Google Analytics Acquisition Browser Report

Phew, I think we’re safe. Now we can see how many people visit each version of Internet Explorer and luckily almost 99% of THAT traffic is IE9 or above. While we should be as inclusive as we can, this can help us determine priority and make decisions on what browser versions to officially support.

Real talk: 5 people on IE5? ?

Bonus: Advanced Insights

Out of the box, Google Analytics is powerful, but with some customization and deeper integration with your web data, you can give your analytics dashboard extra superpowers.

Darkwing Duck Let's Get Dangerous

Custom Dimensions

Custom Dimensions are what Google specifies as “non-standard data.” Really, they’re just additional data points that we can configure to get a better understanding of what makes our website unique.

For the sake of this article (maybe a later one), I’m not going to go into how to add Custom Dimensions, but Google provides a great guide to get an in depth understanding and a developer guide to go with it. What I’ll go over here is how to explore our reports once some Custom Dimensions are already set up.

What are our Custom Dimensions?

To start, we’ll talk about 2 specific Custom Dimensions: Author and Page Category.

Author is what it sounds like, it’s the person who wrote the article. Page Category in our case is the primary, top-level category that represents the post.

On freeCodeCamp News, you can specify as many categories as you want (do so responsibly), but the first one in the list is consider your “primary” category and is used when you see your post in listing views such as the homepage.

Post on freeCodeCamp News Homepage

What can we do with these?

The great thing is when we set these up, we attribute them to a page view. Once that page view is collected by Google Analytics, we can use it to search on, which is really what makes it powerful. Let’s start with Author.

Finding all posts from a specific Author

If we wanted to search for any post written by Quincy Larson, we’ll want to navigate back to Behavior, then Site Content, and finally All Pages.

Once there, we’ll want to add a Secondary dimension, similar when we added Source / medium, but now we’ll want to search for and select Author, which you’ll also find nested under the Custom Dimensions heading of that dropdown.

Selecting Author as a Secondary dimension on the Google Analytics Behavior Report

From there, we’ll want to select Advanced on the right (highlighted below), add our author’s name, and finally hit the Apply button.

Searching for an Author in Advanced Search of Google Analytics Behavior Report

After hitting apply, we now have all the stats we could ever dream of for the articles written by our author, Quincy Larson.

All posts from an Author in Google Analytics Behavior Report

You can also just type a query into the Google Analytics Search Bar.

Google Analytics has a search bar at the top, and you can just type natural language queries like this one:

The results of a query for "articles by quincy larson past 30 days" shows the number of views each of Quincy's articles has gotten over the past 30 days.

Which categories are doing the best?

This is a trickier one. There are a lot of questions we may be able to answer with the basic reports like we did with Author, such as “out of all of the JavaScript posts, what has the most traffic?”, but maybe we want to know generally what category is the most popular on the site.

To do this we need to get our hands dirty with Custom Reports. This is too advanced to try to tackle in this post, but Google does a great job at outlining it in detail.

For now, I’ve done you a favor and set up a report that you can easily import to your account and use right away. So first thing’s first, let’s import the report: https://analytics.google.com/analytics/web/template?uid=4fHol2S_TZqcQACAwfcmfg

Importing a Custom Report in Google Analytics

Here you should see a screen like the above that asks us 2 things: where should we apply the report and what do we want to call it? If you’re an author of freecodecamp.org with access to GA and want to view this, you would select the All Web Site Data view under the freeCodeCamp News property.

Selecting a Property and View when importing a Custom Report in Google Analytics

Once selected, name the report what you’d like, such as “Top Primary Categories”, and click Create.

Custom Report showing top Primary Categories in Google Analytics

After it’s done, you’ll then land on the newly imported custom report where you can immediately see the most popular categories on the site, which for August is JavaScript!

Breakdown

This was a lot!

Alan Rickman in Galaxy Quest sinking in chair

But this is just the tip of the data iceberg. Even with just the above, you can see there’s a lot going on and a lot of configuration to make the most out of Google Analytics for your specific needs.

If this interests you, I encourage you to do some research on your own, add a new view (particularly a Test View to play around with), and get your hands dirty poking around the different reports. Otherwise, keep an eye out for more of my GA posts covering advanced installation and deeper insights.

Originally published at https://www.colbyfayock.com/2019/09/making-sense-of-google-analytics-and-the-traffic-to-your-website

Do you know that nearly 200 websites are pushed out every minute? Sounds astonishing right? But it is a fact and that’s why it is important that every entrepreneur and developer know about the current web development trends.

There are a total of 200 million active websites present out there, while the combined count of total inactive and active sites will be ten times more…