How To Use Github Actions To Auto Deploy Your Next.js App (Ubuntu)


Sometimes, SSH'ing into your server after every update for redeployment is
annoying.

Github has an amazing Continuous Integration (CI) and Continuous Deployment tool set via Github Actions.

## What Is A Github Action

A Github action is a script that executes in response to another event. For
example, an action can run when you commit to a specific repository.

Conveniently, there is a marketplace that have pre-build modules we can add to
our script. More on this later.

## Preparing The Workflow

Create a new directory in your project root called .github/workflows

`mkdir .github && mkdir .github/workflows`

Inside the workflows folder, create a file called `Deploy.yml`. You can name
this folder anything you want. Just make sure it's has a `.yml`.

## Finding The Right Github Action Plugin

Before we write the details of the `Deploy.yml` file, we need to find the pre build modules we intend to use. 

To deploy your application on your Ubuntu server, we need to allow gitbub to
login and execute commands. 

There is a module for this called [SSH Remote Commands](https://github.com/marketplace/actions/ssh-remote-commands). 

## Allowing for SSH

The final step before writing the script is to allow for SSH. 

Navigate to the repo on Github.com. Click on settings and on the left, click on
secrets and Variables, then actions.

In this section you want to add the following two repository secret:
- First Secret
    - Name: `USER`
    - Secret: `<The Username For Your Ubuntu Server>`
- Second Secret
    - Name: `KEY`
    - Secret: `<Copy Private SSH Key>`

It's important to follow the ssh instructions from Appleboy's documentation
[here](https://github.com/appleboy/ssh-action#setting-up-a-ssh-key). Otherwise, your action will fail.

## Writing The Script

Here is the script for the deploy action. 

Inside the Deploy.yml file: 

```yml
name: Deploy

on: 
  push:  # <-- Activate script on push
    branches: [ 'Branch Name' ] # Add name of branch here

jobs:
  deploy_job:
    name: Deploy
    runs-on: ubuntu-latest
    steps: 
    - name: deploying to ubuntu server
      uses: appleboy/ssh-action@v0.1.10 # Here is the appleboy module
      with:
        host: <ADD YOUR HOST IP>
        username: ${{ secrets.USER }} # Accesses USER secret automatically

        key: ${{ secrets.KEY }} # Accesses KEY secret automatically
        port: 22
        script: |    # <-- The steps to deploy
          cd kev-blog
          git pull
          npm run build
          pm2 reload 1
```
All this script is doing is:
- When a commit is pushed to the specified branch...
- Login to server at `~/`
- Find the `kev-blog` folder which is where this blog is
- Pull the changes from Github
- Rebuild the Next.js package
- Reload PM2 which serves the Next.js app

## Observing The Deployment

Inside your repo, you can go to the `Actions` tab to observe this happening
live. And success and failure messages.

That's it for now. 




Hexagonal Architecture With TypeScript


## Hexagonal Architecture Has Commercial Value 

For my project [ProjectSweet](https://kevinize.com/projects), I decided on using Hexagonal Architecture.

I had two massive issues with my previous business (Frosty Response App - sold) as a solo dev. 

Firstly, as the project grew with more features and components, it became a
complete mess. Everything took a long time. Or, longer than it should.

Second, everything with interlinked. Database calls and SQL were amoung business logic. Changing one line became a hoping and praying exersice that "nothing else was effected." 

What I described above is fine for startups who do not intend to be around for
a decade. The cost of rebuilding it properly will happen later.

However, I have changed my mind in that. I believe it's better to start a
project with good architecture.

Why did things change?

Because there is a business reason (and I am all about business!). The reason is
this: With the hexagonal Architecture, you can create re-usable elements that
can be used in other projects too.

This is huge. Because as a programmer, a hobbiest and entrepreneur, I am always
creating new things.

The more I invest in "hexagonal components" that are written in my style, that I can be reuse, 
the easier app building becomes.

It's like investing. 

## An Overview Of Hexagonal Architecture

Hexagonal Architecture takes two of the SOLID principles and uses them to create
an organised and easy to maintain software.  

The general idea is that we have the problem solving code (aka the domain logic) which solves the
customer problem. And we use ports and adaptors to communicate interact with external systems.

This means that the domain logic does not include any technology details or dependencies. 
The ports and adaptors handle that.

The domain code connects to ports, ports to adapters and finally adapters to
external systems.

The Hexagonal Architecture therefore has are 4 parts:
  * External Systems
  * Adapters
  * Ports
  * Domain Logic

I will breifly run through each one in the order you should think about them
while creating your application. All examples are in typeScript.

## Domain Logic

Solving the actual problem.

## Ports

Ports are part of the application layer. We create a port to define WHY we need
to interface with an external system.

We create a new port for every new reason why. For example, we will have one
port for adding a new user. And a different port for updating a user. An a
different port for deleting a user.

These ports are not implementations. They are only interfaces which defined what
the implementation should include.

Using Typescript, these are actual interfaces that map the functions and
variables for the implementation.

Let's see an example.

The port for "adding a new user" might be

```javascript
interface addNewUserPort {
  addUser(username: string, password: string, email: string): Promise<User>
}
```

Next, the adapors job is to implement this interface for whatever external
system.

## Adapters

Adapters form the adapter layer of the hexagon and sit outside of the
application. They hold the techincal implementation code for communicating 
with out application via the port. 

Using the addUserPort as an example, our adaptor will communicate with this port
to add the user based on the user input. 

We might be adding the user to postgreSQL, MongoDB or a filesyste JSON file. Either 
way, the port will stay the same. But each of these database implementations will 
have its own adaptor.

Therefore we could have:
  * addUserPSQLAdaptor
  * addUserMongoAdaptor
  * addUserJSONAdaptor

3 adaptors for adding a user. One port. However, you might decide to make God
Adapors which is one large adapter that manages everything to do with on
external system.

For example, you might have an adaptor called `UserAdapter` that includes all
the methods mentioned above. This adapter will connect to the various different
ports. (Unless, of course, you also have a God Port.)

What is important here is to split the adaptors between incoming actions and
outgoing actions.

A user creates incoming actions. Our app saving to the database is an outgoing
action. These shouldnt be within the same adaptor.

## External Systems

External systems, also called Actors, are anything external to our program that 
we have no control over. This includes REST APIs, Databases, GUI Interfaces, 
SPAs, Users, Commandline tools and the browser. 

External systems speak to adapters only.

That's it. Bye for now.


How To Edit A Colorbuddy Based Colortheme For Neovim


As programmers we often spend many hours on our computers. either inside a
terminal or a coding environment. It's important to build an environment that we
enjoy being in.

To that end, I like to play around with my color themes. Because it's fun?

I recently started using a colorbuddy based colortheme. Colorbuddy is a
framework you can use to easily create color themes with lua. 

Maybe you are not interested in creating a theme. Neither am I. But you can edit
an existing theme. Here is how:

## Disable Treesitter First

The first thing you need to do is disable treesitter for markdown files:

```lua
require 'nvim-treesitter.configs'.setup {
  ensure_installed = {
  -- other configs here
  highlight {
    enable = true,
    disable = {"markdown"} -- <-- this is key
  }
}
```

If you don't disable treesitter for markdown, none of the changes you make for markdown will take effect.

## Find the name of the group you wish to Change

Everything in neovim is a group. Prior to neovim v0.9, there is no easy way to discover the right highlight group you need to reference. 

For example the headline text color for H1 in markdown is `markdownH1`

I discovered this by looking at example color themes based on color buddy. To do this, go to the colorbuddy github repo and look inside:

colorbuddy/lua/colorbuddy/plugins/

Look for the markdown.lua file. Inside you will the the group name for header 1,2 and 3

For example, header 2 is call `markdownH2`

In neovim 0.9, you can put your cursor over the element you want to inspect and type `:Inspect`.

## Find the color theme you want to change on mac

Color themes are stored in .local/share/nvim/site/pack/packer/start/

Find the theme plugin and look for the lua file. 

These files are already setup. You do not need to create new variables or functions. Just use the conventions setup by the theme. 

## Add a new color

Using the neosolarized.lua theme as an example, to add a color, I did:

Color.new('lightBlue', "#ADD8E6")

## Assign the color to the highlight group

I wanted to change the headline color for markdown H2 

So I added the groups:

Group.new("markdownH2", colors.lightBlue, nil, opts)

Thats it. Bye for now.




A Decade Of Software Development - 2 Key Software Development Questions


When I started web development, I started with an advantage: 8 years of building finance based tools.

You see, software development has 3 parts major areas. And these 3 areas are consistent across all kinds of software:

- Deciding on the technology you will use (Strategic Tech Decisions)
- Designing the logic and algorithms to solve problems (Backend)
- Building the front end of your logic (frontend)

In my experience, the first and second point represent 80% of the "_build great software_" battle.

A year ago, I built a dashboard application with Next.js/React and Typescript for a client. The users for this app were able to calulate and visualise data without doing SQL.

7 years ago, I build a similar dashboard application in excel. The users were able to calulate and visualise data without doing SQL.

(Do you see where I am going with this?)

The logic was almost identical. The algothims were similar. The problems were the same. The only difference was the front end technology and user experience (which is also important by the way!).

Why is this important?

Becuase, over the years, your front end might change. But underlying logic and business logic can last for decades. It's VERY important that the software developer you bring in to help you is atune to the tradeoffs in the back end logic.

I want to give you 2 questions that you should ask every software developer who you decide to hire or outsource too. These questions are so fundamental to the _future_ success of your web project. 

Ready? Here we go...

*Question 1:* What are the different options for database (storage) technology, and which one should you use in this scenario? Why?

*Question 2* Should our application have a decoupled backend (API model)? If so, why? If not, why?

On the surface, these questions look basic and straight forward. But they open up the doors to future proofing and future scaling. 

The software you build today will need to be maintained and improved for years. Many startup founders make "quick decisions" on day one. And pay for it later. 

Don't be that guy or girl.




Building 10 Serious Projects In Next.js


## An End Of A Journey

On the 13th Feb 2023, I asked my investor to buy Frosty App. 

He could use it for his other companies. And I wanted out of service businesses.

When I started the company, I wasn't a software developer. Today, I write/build/refactor software all day.

I enjoy it so much, I want to pursue it as something I do everyday. I was already doing it all day. However, I also had the CEO job. Eventually, I had to pick one.

Going forward, I will focus on building 10 Serious Projects with Next.js to continously experiment.

## 10 Serious Projects

What is a serious project?

A serious project is defined by:

- An app that solves a real problem I have.
- It doesn't matter if the app exists. The building of the app for myself to hone my app dev skills is the point.
- They wont be small apps you can build through courses. 
- I will be building them from scratch

Further, I don't beleive in [portfolio projects](https://www.kevinize.com/articles/Teach-Programming-1), they are a waste of time. 

I want to build 10 sizable projects with Next.js. The purpose of these projects are two fold. Firstly, I want a playground to continously hone my development skills. Secondly, I will build things I actually need. 

And by doing so, mirror the production experience I had in Frosty Response.

[Check out project progress here](https://www.kevinize.com/projects)

## Technology Focus

When I started Frosty, I used many different languages while I [explored software engineering](https://www.kevinize.com/articles/Teach-Programming-0).

Today, I know the langauges and frameworks I want to focus on professionally. And as a hobby.

- Next.js/React/Node.js for professional, full-stack projects
- Common Lisp for hobby and [business logic exploration](https://www.kevinize.com/articles/common-lisp).





3 Great Decision I Made In My Second Year Of Teaching Myself Programming


Finding something you love to do for the sake of doing it, is true joy. 

I cannot stress this enough. Programming is the only thing I can do for 10 hours straight. In this second year of programming I expanded beyond Javascript and programming. 

Here are the three great decisions I made 

## Scratching My Curiosity Itch In All Things Programming

Software Engineering is not about writing code. 

There are many associated fields and disciplines. I was curious about all them. I wanted to know what they were and how to do them. Over the year I learned: 

1. A strong understanding of version control (Git and Github).
2. How to use, operate and deploy to a Linux Linux Tools server (and use Nginx) - more on this later.
3. How to create and organise config files
4. Vim (used for everything other than Common Lisp) and Emacs (Used for Common Lisp Dev)
5. How online Authentication works.
6. Build, setup and manage a PostgrSQL Database (I already know SQL from my Finance days.)
7. When to leverage immutable data structures & funcional programming
8. React/Next.js Frameworks

## Started To Learn Other Languages And Use Them In Production

I was also interested in other programming languages. If you remember, this is the Peter Norvig 10 Year Challenge. Learning many languages was part of that. So I:

1. `PHP` - Rebuilt frosty in PHP. This was quite easy. I didn't use it. I don't like PHP :)  
2. `C Programming` - Very basic but I learned how to create command line tools in C. C is a fabulous language.
3. `Common Lisp` - I went deep here. I spent 10 months writing Common Lisp. A very different language than C, PHP and Javascript. Common Lisp is my favorate language.

## Used An Ubuntu Computer As a Day To Day PC For 4 Months

I am a self proclaimed Extreme Learner. I cut myself off from using my Mac for 4 months.

Everything is different in linux. But Linux Linux Tools is important for web developers because we deploy with them. I needed to know how it works so I could be effective.

I also wanted to stay away from products like Heroku. My logic was simple, if I learn to do it at the source (the bare ubuntu server), then I can control the whole process.

After 4 months (Jan 22 - April 22), I switched back to Mac. But now I know how to use and configure Linux Linux Tools well.

### See other posts in this series

- Year 0: [The Peter Norvig Challenge - Year 0](https://www.kevinize.com/articles/Teach-Programming-0) 
- Year 1: [4 Great Decisions - Year 1](https://www.kevinize.com/articles/Teach-Programming-1) 
- Year 2: This Post

3 Reasons Why Leaning And Using Common Lisp Made Me A Better Programmer


I have spent the last 18 months learning and using Common Lisp. 

I replaced the backend of `Frosty App` with Common Lisp. The Front stayed as JavaScript/Next.js

In that time, I read a lot of conversations about why learning Common Lisp makes you a better programmer (probably because of Paul Graham?).

I cannot comment on that. However, I can share my experience as a JavaScript Web Developer.

## Closer to Programming Concepts 

I find it facinating when people ask why Common Lisp is not popular (as if popularity were a metric for being good).

The most common argument is that "they do not have many libraries". This is true if you compare the number of libraries to npm or Python. But I see this is a good thing. Libraries are amazing for moving fast. I use them all the time. 

But if your goal is to become a better programmer, then at some point you need to know how libraries work. Or how to implemented them.

With Common Lisp, I found myself writing functions for things I could find an `npm` package for.

Let's go through an example...

I deployed my company website as a common lisp app. I used a library for the server. But to deploy it, I needed to understand about `Sockets`, `Threads` and the difference between `Concurrency` and `Parallelism`.

These are concepts Id never have explored with JavaScript. I could write an app with Express and be done.

I am not suggesting that you need to learn Common Lisp to discover what a socket or a thread is. I am saying that Common Lisp allowed me to dig under the hood of how things worked. Because I had no choice.


## Building my "Figure It Out"

In Common Lisp, there are almost no answers to your questions online. (Relative to the amount of questions you will have).

The community is smaller than JavaScript. The language is large and deeper. There are only few good resources. Many good libraries have subpar documentation. And, if you have a question on StackOverflow, you might have to wait 24-48 hours.

What that means is, you have to figure it out. 

You need to put the pieces together yourself and find a solution. Will you quit or will you try to figure it out in?

Here is the important part: __Learning to figuring things out for yourself is a priceless programming skill__

Today, when I am writing Next.js applications, things break all the (damn) time. But guess what... I can figure it out ☺️

Finally, this more of a habit than a skill. 

Sometimes, there are no answers (ever had a hydration error with Next.js?). Usually, more experienced programmers have solved more problems than less experience programmers. But if you compare someone with 2 years experience who figured out lot's of things versus someone with 4 years experience that copy-pasted from StackOverflow... 

One learned. The other didn't.

## Exploratory Programming In The Lisp Repl

I don't believe I can live without a `Slime` repl to explore my ideas.

Exploratory programming is when you have a problem to solve with code but you don't know how to implement the solution. Or you want to translate a domain problem into code and you do not know how yet. In this phase, things change rapidly in a short period of time while you test ideas.

Even when I am writing business logic with JavaScript. The Common Lisp repl is my playground. I use it to explore ideas and test out if my ideas will work. Once I have explored it and it works, I can write the JavaScript equivalent. 

Why would I do that? Isn't it slower?

Good question. Let's explore.

The starting point of our example is "I want to do X, but I'm not sure how to implement it"

__In JavaScript__

I first need to create a new file. In that file I will write all my business logic. 

To see the effect of a change I would need to run the whole script with `node fileName.js`

This approach runs the whole script. But what if you are only exploring one function? 

You could split all functions into many files. But that isn't efficient if it's you are trying to solve a complex issue which might need many functions. 

When I am exploring, I want an easy way to the value of a variable or the outcome of a single function.

__Exploring In Common Lisp__

Create a new file, add all your business logic to the file.

Open a new repl with `M-x Slime`

```common-lisp
CL-USER> 
```

Now, you can run functions individually or see the values of variables inside the repl. 

This means that you can run each unit of code as an individual. If you have never used the Common Lisp repl, it's hard to describe how valuable this is.

That's it. Bye for now.


Vim Most Used Tips And Tricks


Over time the how we work evolves. There are a few things that haven't changed
in a while with vim. They are useful. I use them all the time. 

This list is an easy way for me to keep everything in one place.

## Window Split Keys

I have setup my Vim to open netrw for every new pane. 

```vimScript
"Open a new netrw window. Vertical split, to the right
<Leader>n  :Vex! 
" Open new netrw window. Horizontal split. Above
<Leader>s  :Vex! 
" Open netrw in current buffer
<Leader>e  :Vex! 
```

## Searching Keys

Using Telescope and ripgrep
```vimscript
" find files
<Leader>ff Telescope find_files

" Find matching text - grep
<Leader>fg Telescope live_grep

" Find File buffer
<Leader>fb Telescope buffers

<Leader>n  :Vex! 
```

## Netrw Keys

```vimscript
% create new file

d create new directory

D delete file or directory
```


## Programming Keys

Using Coc

```vimscript
gd :call CocActionAsync('jumpDefinition')<CR>

gr :call CocActionAsync('jumpReferences')<CR>

<leader>rn   :call CocActionAsync('rename')<CR>

K Coc hoover
```

## Useful functions

Find out what a key does
`:verbose imap <key>`

Very useful if you are coming from emacs.


How To Build A Frameworkless Authentication System For Next.js


I tend to stay away from frameworks, most of the time. 

That sounds weird because most of my JavaScript projects are in Next.js/React.js. As a developer, I am not always in charge of the architectural decisions. If the techlead or CEO wants to use a framework, then a framework we will use. 

When I was running Frosty Response, I often chose to not use frameworks because there are too many unknowns (things that I cannot be sure of) that happen in the background (ever had a hydration error?).

There is another issue with frameworks. That is when a framework requires another framework. This is something I call a multi-level frameworks issue. 

That is when a framework - like Next.js - have require another framework for something specific. In this specific case, Next_Auth is the authentication framework used by 90% of Next.js apps.

_NextAuth not fully support email and password authentication_. They make it intentionally difficult so that the user is shoe horned into using `OAuth 2.0`

As a user of tools, I understand opinionated software. As a developer, I do not understand opinionated development tools. I like to have the freedom to make micro changes should the need arise. 

So I developed a frameworkless system for authenticating users in Next.js, without nextauth.

> Note - This flow uses TypeScript.
> Note2 - I will ommit imports and exports from the examples
> Note3 - I am assuming you have a database with usernames and passwords already

## Contents 

- Setting Up The Application For Authentication
- Creating the Global State for Authentication with Context API
- Building the Sign In Form
- Creating the Verification API Route
- Important Connections Between These Files
- Creating the Protected Route
- Wrapping the Application with the Protected Route and Auth Contect Provider


> **_NOTE:_** Authentication is a complex topic. As I learn more about security and authentication best practice, this process will be updated.

## Setting Up The Application for Authentication

There are two main steps to setting up this authentication process.

Firstly, the packages. Secondly the types.

### Packages

When you install jsonwebtoken, you also need to install the types

```bash
project>$ npm install jsonwebtoken
```


```bash
project>$ npm install --save @types/jsonwebtoken
```

### Setting up types for the project

Let's create the types for the entire project in one file. We will be using these types throughout the script.

Create a file called `types.tsx`

```javascript
//for the Auth Context
export interface AuthContextInterface {
  token: string | null;
  isLoggedIn: boolean;
  login: (token: string) => void;
  logout: () => void;
}

//for wrapper components
export interface childrenProps {
  children: React.ReactNode
}

//For ProtectedRoute wrapper component
interface ProtectedRouteProps {
  children: React.ReactElement;
}

// for the submit form
export interface eventType {
  (e: React.FormEvent<HTMLFormElement>): void;
}

// for the login information sent from the signin form
export interface login {
  username: string;
  password: string;
}


```


## Creating the Global State for Authentication with Context API

Create a file called `AuthContext.tsx`. 

### InitialToken Variable

Firstly, we need to create a single variable to hold the state of our initial token value. This `initialToken` value will be passed into our state later.

```javascript
let initialToken: string | null
```

This must be a union type with null because `initialToken` will be getting its updated state from `localStorage.getitem()` function . Which could be null. More on this later.

### Create Context

In this file we will be creating the global state for authentication. This will include: 
- the jwt token
- the login boolean state
- the login function, and,
- the logout function.

For these variables,we need to create our initial values and pass them into the `createContext` function.

Create the `AuthContext` variable and assign it to the createContext function. This function takes an object which will be the initial values for the variables defined above:

```javascript
export const AuthContext = createContext<AuthInterface>({
  token: '',
  isLoggedIn: false,
  login: (token) => {},
  logout: () => {},
});
```

This should be exported because it will be used from outside of this file.

### The AuthContextProvider

Finally, we create the `AuthContextProvider` which will be used as a wrapper. This will wrap around our application in `_app.js`. More on that later.

I have marked up the code to explain each part:

```javascript

export const AuthContextProvider = (props: UserProviderProps) => {
  //our initial state using the initialToken variable created earlier
  const [token, setToken] = useState(initialToken);

  // a variable to define if the user is loggedin or not.
  // login is defined by having a present jwt token.
  // more on jwt later
  let userIsLoggedIn: boolean;

  // check if there is a token. return boolean value
  if (token) {
    userIsLoggedIn = true;
  } else {
    userIsLoggedIn = false;
  }

  useEffect(() => {
    // on load, check for a token in local storage
    initialToken = localStorage.getItem('token');
	// set the token to the value of the token
    setToken(initialToken);
	// run once on load
  }, []);

  const logoutHandler = () => {
    setToken(null);
    localStorage.removeItem('token');
  };

  //save the token to the local storage
  // we will use this function later in the login form
  const loginHandler = (token: string) => {
    // also update the state to the new token value
    setToken(token);
    localStorage.setItem('token', token);
  };

  // create context value object whose value is to be made available to all components using this context.
  const contextValue = {
    token: token,
    isLoggedIn: userIsLoggedIn,
    login: loginHandler,
    logout: logoutHandler,
  };

  return (
    <AuthContext.Provider value={contextValue}>
      {props.children}
    </AuthContext.Provider>
  );
};


export default AuthContext;

```

Our AuthContext is now ready to use. Next, we need our sign in form.


## Building a Sign In Form

The form I will be using is the is a standard form so I will not focus on that. Here, I will focus on the important parts: the `submitHandler` and `AuthContext.`

Create a file called `SignInForm.tsx`. This is a Next.js page route.

First, in our form page component, we use our `AuthContext` via `useContext`. This is the most important part that connects the Auth context to the sign in form:

```javascript
export default function SignInForm() {

...

 const authCtx = useContext(AuthContext);

...
}

```

We then add the state variables for the username and login:

```javascript
export default function SignInForm() {
  const [username, setUsername] = useState('');
  const [password, setPassword] = useState('');

...

  const authCtx = useContext(AuthContext);

...
}

```

We also need to use the `useRouter` to redirect the user to a page after login. 

Now, initialise the router: 

```javascript
export default function SignInForm() {
  const [username, setUsername] = useState('');
  const [password, setPassword] = useState('');
  const router = useRouter();


  const authCtx = useContext(AuthContext);

  // submit handler will be here
}

```

Now, we need to create the `submitHandler` function that triggers when the form is submitted. I have marked up the code to explain each step:

```javascript

const submitHandler: eventType = async function (e) {

  e.preventDefault();
  
  //create object for submited state.
  //this is updated by the form on submit.
  const loginDetails: login = {
    username,
    password,
  };

  // fetch - post username and password to api
  // we will look at the API in the next section
  await fetch('/api/SignIn', {
    method: 'post',
    headers: {
      Accept: 'application/json',
      'Content-Type': 'application/json',
    },
	//send the login info as a string to the api route
    body: JSON.stringify(loginDetails),
  })
    // convert response to JSON
    .then((data) => data.json())
	// use response
    .then((data) => {
      //run authcontext login function with the token send from the backend API
      authCtx.login(data.token);
      router.replace('/newuser');
      /* console.log(data); */
    });
  };

```

To summarise where we are so far:

- We have a global context called `AuthContext` that holds the login function and the current login state based on if we have a token or not.
- We have a sign in form that takes the username and password submitted by the user. This is sent to the backed API for verification. If verified, a token is sent back and saved to local storage

So, lets create the API route.

## Creating the Verification API Route

There are some benefits to frameworks. One of them is the `/api` folder in Next.js. It allows you to create api routes (Node.js) code directly inside the project. The routes created inside the api folder are instantly available depending on the name of the file.

If you notice, in the `SignInForm.tsx` (the previous step) we sent the post request to `/api/SignIn`. That is what we will create now.

In this example, create a file called `SignIn.tsx`.

The TypeScript function for the api handler is:

```javascript
export default async function Handler(
  req: NextApiRequest,
  res: NextApiResponse
) {
  try {
   if (req.method === 'POST') {

	// all code below will be inside here
  
    }
  } catch (err) {
	console.log(err)
  }


```


First we access the post request body that was sent in. And validate that the username or password are not empty:

```javascript
// Get user input with types
    const { username, password }: login = req.body;

    // Validate user input
    if (!(username && password)) {
     res.status(400).send('All input is required');
    }
```



Then, we use our database search function to get the user assigned to that username. Here, I am assuming you have your own function for this. This script is database agnostic. Whether you use PostgreSQL, a JSON file or MongoDB, it doesnt matter. Just search for a user and put that function here: 

```javascript
// Validate if user exist in our database
    const user = getOneUser(username);
```

If user not found, send error: 

```javascript
if (user === undefined) {
      res.status(400).json({ res: 'no user' });
    }
```

If a user is found, verify the password. This part is important. Password encryption (hashing) and verification is performed by a package called bcryptjs. I will write a seperate article about password encryption and verification. For now, assume this function returns a true or false depending of if the sent in password is matches the records:

```javascript
  const isValid = await verifyPassword(password, user.password);
```

Finally, if the token is value (true) then sign the token with jwt and add it to the user object. Then return the token in the response back to the post request:

```javascript
    if (isValid) {
      // Create token
      const token = sign(
        {
          username: username,
        },
        'SECRET_KEY'
      );
      //add token to user object
      user.token = token;
    }

      res.status(200).json({ token: user.token });

```

### What is happening here?

Our post API received the username and password (login details) from a post request. The login details is matched to the database to find a user. If a user is found, the password is verified. If the password is verified the token is signed (created) and sent back as a response to the post request.

## Important Connections Between These Files

Inside the SignInForm.tsx, we send a post request to the backend API.
Inside the second `then()` block of the post request, we use the `AuthCtx.login()` function. This function takes `data.token`. 

`data.token` comes from the key value pair sent back to the post request as a response:

```javascript
  //SignIn.tsx
  res.status(200).json({ token: user.token });
```

The `AuthCtx.login()` function then saves the token to localStorage:

```javascript
//AuthContext.tsx
  const loginHandler = (token: string) => {
    setToken(token);
    localStorage.setItem('token', token);
  };
```

When a page is loaded, the `useEffect()` function inside the `AuthContext.tsx` file runs. It sets the initialToken value to what is in the localStorage: 

```javascript
//AuthContext.tsx
useEffect(() => {
    initialToken = localStorage.getItem('token');
    setToken(initialToken);
  }, []);
```

When this runs, the initialToken variable is set to a new value. This updates the state.

The login state variable `userIsLoggedIn` value is then retested in the same file. Now that there is a token, it will be set to true:

```javascript
//AuthContext.tsx
  if (token) {
    userIsLoggedIn = true;
  } else {
    userIsLoggedIn = false;
  }
```


## Creating The Protected Route

The final file we need to create is a wrapper component that protects the entire application. This wrapper runs the authentication checks defined above for every component it wraps.


Created a file calleed `ProtectedRoute.tsx`

```javascript
export default function ProtectedRoute({ children }: ProtectedRouteProps) {
  const authCtx = useContext(AuthContext);
  const isLoggedIn = authCtx.isLoggedIn;

  if (isLoggedIn == false) {
    return (
      <>
        <div className="plain-page">
          <SignInForm />
        </div>
      </>
    );
  } else {
    return children;
  }
}
```

in this file, we are returning the sign up box if not loggedin, or the children components. This is a wrapper component, therefore the children will be based on the path we visit.


## Wrapping the Application with the Protected Route and Auth Contect Provider

Finally, We need to wrap `_app.js` (the entire app) with our `AuthContextProvider` and the `ProtectedRoute` wrapper component.


```javascript
export default function App({ Component, pageProps }: AppProps) {
  return (
    <AuthContextProvider>
      <ProtectedRoute>
          <Component {...pageProps} />
      </ProtectedRoute>
    </AuthContextProvider>
  );
}
```

And we are done. Frameworkless authentication is completed. We can use username and passwords to create authentication.

Bye for now.


Is There Profit In Creating Unit Tests?


Is there profit in creating unit tests? 

It depends.

## Early/Exploratory phase

The important lines of code in a project is the business logic. 

At the start of a new project when you are exploring this business logic, testing is not useful. This has been my experience. `Frosty App` is in it's very early stages. 4 weeks ago, the application was completely different than it was today. If I had written unit tests four weeks ago, they would be useless today. 

There is no value in writing unit tests too soon for startup/early stage projects. 

## Pre-launch

Before your customers uses the product, it's important that everything available works.

Writing tests for the most critical functions is a good idea. Automated tests allow you to test a wide range of functionality quickly. This is where testing is useful. It increases the speed of shipping features to customers.

If, for example, you only have 5 main features then you can test them manually. It's faster.


## What About TDD?

There is a concept called Test Driven Development. The programmer starts a new feature by writing a failing test. Then, they write the logic for the passing test. Finally, they refactor.

I do not use this process. What does TDD have to do with shipping useful things to customers? 

Nothing.



Use Markdown To Power Your Site Content With Next.js


For this website, I write all blog posts in markdown files. 

There are a few things required to make that happen. In this post I will focus on setting up and using the `react-markdown` library.

## Install React Markdown

Install react markdown with `npm i react-markdown`.

Install react-syntax-highlighter with `npm i react-syntax-highlighter`

The react-syntax-highlighter is used to add syntax highlighting to <code></code> blocks.

If you are using Typescript, you also need to `npm i --save-dev @types/react-syntax-highlighter`

## Extract Markdown from A Markdown File

There are many ways to extract markdown from a file saved on the file system. That is outside the scope of this aricle. In the below example, I am assuming the markdown has been extracted.

```javascript

import ReactMarkdown from "react-markdown";

export default function Page() {

const content = `
    
    #Headline 

    Paragraph content

    ```javascript

    const x = "Markdown"

    ```

}

```



## Wrap The Content In React Markdown

Return your JSX code

```javascript

return (

    <ReactMarkdown>{content}</ReactMarkdown>

  )
```

## Add Syntax Highlighting For Code Blocks 

So far, we have allowed Next.js to read markdown and convert it into JSX. However, the syntax highlighting isnt activated for code blocks.

We first need to inport the highlighter

```js
import { Prism as SyntaxHighlighter } from "react-syntax-highlighter";
import { darcula } from "react-syntax-highlighter/dist/cjs/styles/prism";

```

Finally, we need to add the syntax configuration. Change your `ReactMarkdown` code block to this:

```javascript
<ReactMarkdown
				components={{
					code({ node, inline, className, children, ref, ...props }) {
						const match = /language-(\w+)/.exec(className || "");

						return !inline && match ? (
							<SyntaxHighlighter style={darcula} language={match[1]} {...props}>
								{String(children).replace(/\n$/, "")}
							</SyntaxHighlighter>
						) : (
							<code className={className}>{children}</code>
						);
					},
				}}
			>

```



4 Command Line Tools I Install On Every Server


## FZF

Have you ever tried to remember a command (for the command line) that you wrote 12 days ago?

It's not uncommon to write hundreds of commands in a single day. It's not possible to remember all them. Enter FZF. fzf is a fuzzy search application for the command line.

With fzf, you can press `ctrl + r` and get a list of all your entered previous commands. You can search through them.

**Pro tip -** if you clear your command line history, you cannot search that history anymore. Don't clear it.

## ZSH shell

zsh shell isn't that special on it's own. I use it because of OH-MY-ZSH.
OH-MY-ZSH is a group of extensions, plugins and function that allow you to create a customised terminal experience.

Why is that important?

Because the tools we use to create software are as important as the code. Having a consistent experience means we can get to work without interruption.

## Tmux

Tmux is a "terminal multiplexer daemon".

It allows you to run many terminal sessions. And it keeps your running in the back ground. If your terminal app closes, you can reopen it and continue where you left off. It's also very useful for running local servers.

I do not know how I lived in the past without Tmux.

Before using Tmux, I didn't understand what it was or why it was valuable. There are many reasons for this. Too many to go over here. I will give you the immediate reason why I use it:

Tmux decouples the terminal process and the terminal application. If you close your terminal application, you can reconnect to tmux and continue where you left off.

## Tmuxinator

Overtime, you will build a workflow with Tmux.

You might have four different sessions for 4 different projects. Each project may have 5+ terminals windows. Each terminal window can will split inti 1-4 different panes running different processes.

That's over 40-100 different processes.
Tmux runs in the background but the background process will close if you restart your computer. Opening all these windows and panes would be hell.

Tmuxinator is a Tmux state saving manager. You can tell Tmuxinator the exact setup for one session. And in one command it will open the entire session with all it's windows and panes. You can even tell tmuxinator to execute shell commands in the panes.

Also couldn't live without it.


4 Great Decisions I made In The First Year Of Teaching Myself Programming

4 Decisions For Learning Programming Effectively


It's been 1 year in my Teaching Myself Programming In 10 Years Journey.

From day 1, I wrote code that has been going into production for my company. My company is not a SaaS or Software business. I create internal software to support the delivery and admin process.

Here are the 4 great decisions I made in the first year of teaching myself programming.

## Building Production Applications

Portfolio applications are a waste of time.

A portfolio app is a short way of saying __an application that doesn't do anything__ . Good software evolves over time. Real life software development is about adapting around the needs of the customer. And reworking (or creating new) features to support these needs.

For that reason, 100% of my code was for production applications. My customer was myself and my team.

## Taking Focused Coding Hours Seriously

Learning complicated things is simple. Sit down, shut up and execute for 4 - 8 hours.

But, simple is not easy. In a world of distraction, doing that is almost impossible. I have a curse though. I don't like social media. or notifications. I have almost zero apps on my phone. I prefer silence.

I value "owning" my own mind and thoughts.

What does any of this have to do with programming?

Programming is high input, high output. It requires many variables (no pun intended) to be correct.  This was the same as when I was an Excel Programmer. Focused time is the only time when I could get real work done.

For that reason, every day for the last 9 months, I would sit down at 5am for 3-4 hours to write software. 

## Becoming a "Full Time" Software Engineer

Overtime, as the production applications grew, I spent more time programming.

Software engineering became my full time work. I built more and more internal modules for the company. And strange thing started to happen... The total cost of freelancers dropped to almost zero. An army of machines could now do that work. 

## Focusing On One Language

Peter Norvig's advice is to learn many languages. To understand the different paradigms of software engineering.

That may be true but I do not think that is a good starting point. Understanding programming fundamentals (data structures, scope, closures etc) and good software design principles are more important. To support my learning of these fundamentals I stuck with one language:  JavaScript (Node.js).

This turned out to be a good decision. Coupled with my "full time" software job, I focused only on these fundamentals. (except that time where I joined the Emacs vs Vim holy war!)


### See other posts in this series

- Year 0: [The Peter Norvig Challenge - Year 0](https://www.kevinize.com/articles/Teach-Programming-0) 
- Year 1: This Post
- Year 2: [3 Great Decisions - Year 2](https://www.kevinize.com/articles/Teach-Programming-2) 

Six Reminders For Deploying Your Web App With Nginx

Remind yourself of the six most common things that can cause your nginx site to fail.


90% of the applications I deploy are on Ubuntu servers. 

Whether it's a Next.js app, Node.js server or a Common Lisp app, I use Nginx and the process is almost identical. However, setting up a new app on a new server is not something I do every day. It's easy to forget minor details that have big impacts.

Below is a list of reminders that, if not remembered, will cause the web app to fail.

If you are ever found asking __"why isn't this nginx site loading?"__, it's one of these six.

## 1. Use the root section in Nginx properly

Your web files do not need to be in `/var/www`. Where ever you decide to put your HTML/JS/CSS, make sure the root section inside the Nginx server block points there:

`root: /dir/of/public/folder`

## 2. If your site does load with nginx, it's most likely your firewall

9 times out of 10, I do everything right with server setup. But I still get that (blasted) 503 error. 

Use command `utf status` in the command line.

Check to see if your firewall has `Nginx HTTP` and `port 80`. 

## 3. Always reset nginx after changing a config file

Behind the scenes there are many things that can effect your Nginx configuration.

When you make major changes to _any_ config files, get in the habit of restarting nginx.

Run: `sudo systemctl restart nginx`

## 4. Server names help for multiple sites on the same server

Sometimes, you want to have more than one website on the same server. 

For that, a simple system name which points to the domain name will allow multiple domains to live behind port 80 or 443.

In the server block of the Nginx file, add:

```toml
server {
  server_name yourWebsite.com www.yourWebsite.com;
  
  ...   < --- other stuff in config  
}
```
## 5. Certbot for free ssl 

Remember to get ssl setup for your website

run the nginx setup wizard: ` sudo certbot --nginx`

## 6. Allow ssl port in your firewall

Secure website access (ssl) is under a different port. After installing Cerbot, you will need to allow `port 443/tcp` in your firewall.

run: `sudo ufw allow 443`


The Main Reason Why "Productivity" Doesn't Create Effectiveness At Work

Productivity Is Not The Same As Effectiveness


A few years ago, I was obsessed with __productivity__ and it made me less productive.

Today, I spend zero time on productivity. Yet, I am the most productive i've ever been. What changed?

The Truth about productivity is this: **I stopped investing time into TRYING to be more productive. And I put that time into the actual work.**

## Ineffective Programmers


This is similar to how software engineers focus 30% of their time playing with (and fixing) config files of their favorite editor in the name of working quickly. Instead of writing new features or refactoring the actual product.

One is work. One isn't.

## Ineffective Startup Founders

Or, the startup founder who invests weeks into getting Asana or clickup or basecamp to work. They already use one of them (not an issue), but they heard that the other one will make them more productive.

All the founders I spoke to that made this decision told me that it didn't work. To tool worked. But the productivity didn't increase.

They could have focused on sales or their clients instead.

One is work. One isn't.

## Are You Avoiding The Work?

If you are obsessed with productivity books, courses or tools... ask yourself this: __are you avoiding the work?__



Teaching Myself Programming In Ten Years - A Documented Journey (Year 0)

My journey learning how to program by building production applications for myself and clients.

Teaching Myself Programming In 10 Years - A Documented Journey


> Note: I am started programming with a bit of an ["advantage"](https://kevinize.com/articles/A%20Decade%20In%20Software%20Development), its not absolute zero. Sorry. Not sorry :) 

A Peter Norvig article changed my life.

Peter Norvig wrote a phenominal article article called ["Teach Yourself Programming In Ten Years"](https://norvig.com/21-days.html). He argued that programming one cannot learn programming in 30 days or 180 days. It takes 10 years to become good. I agreed because I once had a 7-year career as a Big Data Analyst. I wasn't "good" at that job until year 3 or 4. Good things take time.

I took Peter Norvig's article literally and I decided take the 10 year journey for myself.

If Peter's article changed my life, 50 lines of JavaScript (Node.js) changed my business.

These 50 lines delivered an internal operation required to sell our service. My team no longer needed to wake up at a specific time to execute this operation. The code performed the action perfectly, every single time without fail or down time.

I was hooked on the idea of writing code for my company.

But why would an entrepreneur, at 33 years old, focused on becoming a programmer?

With the advent of online and social media many people have goals and missions that are not their own. We see something online and we want the result of that thing. That is how I became an accountant (my parents told me accountant's make good money). Or an online entrepreneur (I heard entrepreneurs make lots of money).

But programming was the first thing I did, that I enjoyed, for the sake of doing it.

My programming journey will not focus on creating protfolio projects. 

I write programs for my company or things I will use personally. As I write this, I am in month 3 of the first year. My hope is that I will write one article to document the journey every year.

For now I will focus on the fundamentals of software enginnering with JavaScipt.

One small caveat: I might be cheating a bit here.

This is a 10 year journey. When I worked as a Big Data Analyst for FTSE 100 companies in London, I became an expert in "Financial Modelling". A financial modeller is essentially an Excel Programmer. I would create custom Excel software for my audience (customers). Excel programming is very like software development.

I had a customer with a need, and I have to fill those needs with an excel program. This is my starting point.

### See other posts in this series

- Year 0: This post
- Year 1: [4 Great Decisions - Year 1](https://www.kevinize.com/articles/Teach-Programming-1) 
- Year 2: [3 Great Decisions - Year 2](https://www.kevinize.com/articles/Teach-Programming-2) 


Pinned Articles

Sort Articles By Tag

All Articles