3 TERRIBLE Decisions I Made In The First 3 Years Of Teaching Myself Programming

## Ignoring Complexities That Were Interesting To Me



## Not Reading Programming Blogs Sooner (and getting sucked into Reddit)



## Programming Fun - Using Too Many Languages In Production

  - By this point I can write good web APIs in many languages.
  - Didn't calculate maintenance costs


## C# is f**king amazing for shipping


## Ignoring "theory"

  - Building and shipping apps are king. But knowing how to solve problems supports that
  - DS & Algos

### 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: [3 Great Decisions - Year 2](https://www.kevinize.com/articles/Teach-Programming-2)
- Year 3: This Post


Auto-Deploy To Production With Github Actions (Ubuntu)

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


Repetitive tasks should be automated. 

A task may be simple or easy, but if it interrupts your focus on core problem, it is a distraction.

Logging into a server to redeploy an application is one such distraction.

Github has an amazing CI/CD system called `Github Actions`.

## What Is A Github Actions

A Github action is a script that executes in response to another event. For
example, committing a project update is an event that can be used to trigger a Github Action.

Conveniently, there is a marketplace for pre-build modules. We can use these
modules as part of our scripts. More on this later.

## Preparing the CI/CD workflow

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

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

Inside the workflow folder, create a file called `deploy.yml`. 

The name of this file can be anything. Make sure it is a YAML file.

This is the file where you will write your CI/CD script.

## Find a plugin that can do what you want to do

Before writing the deploy script, it would be wise to search for a pre-made
module that can help.

Deploying an application to a server requires us to give Github access to
login and execute commands. 

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

## Give Github SSH privileges

The final step before writing the CI/CD script is to give Github SSH access to
our server. 

Navigate to your repo on Github.com. Then:
- click on settings 
- on the left click on secrets and Variables
- click actions.

In this section you want to add two secrets. The first secret is for your server username. 
The second secret is for your server private SSH key.

```yaml
- 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 the Appleboy
[documentation](https://github.com/appleboy/ssh-action#setting-up-a-ssh-key). Otherwise, your action will fail.

## Writing the CI/CD script

Here is the script for automatically deploying your project after committing.

(the script has annotations explaining key sections)

```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 ubuntu commands
          cd kev-blog
          git pull
          npm run build
          pm2 reload 1
```

Simplified overview of the script:

- When a commit is pushed to the specified branch
- Login to server at `~/` with the SSH secrets
- Find the `kev-blog` folder (the project)
- 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. You can see the success and failure messages.

That's it. Bye for now. 


How To Edit A Colorbuddy Based Colortheme For Neovim


As vim user, we spend many hours inside a terminal or vim. 

That is why themes are so popular. If I am going to spend eight or ten hours
inside vim every day, it may as well be nice, right?

To that end, I like to play around with my color themes.

I recently started using a colorbuddy based colortheme. Colorbuddy is a
neovim-based theme framework. You can use it 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. 

In this example, I will be editing my color theme for `markdown` files. 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 do not disable Treesitter for markdown, none of the changes you make for markdown will take effect.

## Change highlight groups, change colors

Text in Neovim are objects. All objects have a highlight group which represents the color for a specific object. 

For example, the H1 header text in a markdown file is in the `markdownH1`
highlight group. 

If you know the name of a highlight group, you can change the color of an
object.

Prior to Neovim v0.9, there wasn't an easy way to discover the name of the highlight group.

I suggest upgrading to 0.9. To discover the name of the highlight group, your
cursor over the text object 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/ (Mac M1)

Find the theme plugin folder and look for the .lua file.

## Add a new color with Colorbuddy

Using the `neosolarized.lua` theme as an example, I added a new color:

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

## Assign the color to the highlight group

I changed the H2 headline color for markdown. 

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

Now the H2 headline for all markdown files is #ADD8E6

That's it. Bye for now.


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: 

- A strong understanding of version control (Git and Github).
- How to use, operate and deploy to a Linux Linux Tools server (and use Nginx) - more on this later.
- How to create and organise config files
- Vim (used for everything other than Common Lisp) and Emacs (Used for Common Lisp Dev)
- How online Authentication works.
- Build, setup and manage a PostgrSQL Database (I already know SQL from my Finance days.)
- When to leverage immutable data structures & funcional programming
- 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:

- `PHP` - Rebuilt frosty in PHP. This was quite easy. I didn't use it. I don't like PHP :)  
- `C Programming` - Very basic but I learned how to create command line tools in C. C is a fabulous language.
- `Common Lisp` - I went deep here. I spent 16 months writing ("Common Lisp")[https://www.kevinize.com/articles/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 Learning And Using Common Lisp Made Me A Better Programmer


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

I replaced the backend of `Frosty App` with Common Lisp. The frontend remained 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. But I can share my experience as a TypeScript Web Developer.

## Closer to Programming Concepts 

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

The most common argument is that "Common Lisp doesn't have many libraries". This is true if you compare the number of libraries available on npm or pip. 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 they are implemented.

While using Common Lisp, I found myself writing functions for things I could easy find an `npm` package for. And, by doing so, started to uncover mysteries about deeper technologies I didn't understand.

Let's go through an example...

I deployed my a website as a Common Lisp app. I used a library for the server. But to deploy the app, I needed to understand how `sockets` and `threads` worked. And the difference between `Concurrency` and `Parallelism`.

I would have never explored these topics 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" Mindset

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

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

In the moment you need 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?

Here is the important part: __Learning to figure 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 is not really a skill. 

It is more of a habit. If this is not your nature, then Common Lisp will not help you develop it. However, if it is your nature, you may have noticed that when writing JavaScript, you didn't use this muscle.

A more experienced programmer has solved more problems than a less experience programmer. But if you compare someone with 2 years experience who figured out a lot of things versus someone with 6 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 open on my computer to explore my ideas. 

Slime is a Common Lisp REPL. It's special because it allows you to interact with your lisp program while it is running.

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 but you do not know how. In this phase, things change rapidly within a short period of time.

When I am writing business logic with JavaScript, I have a Slime REPL open as my playground. I use it to explore and test my ideas. 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__

First I 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
feature? 

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

When I am exploring, I want an easy way to see 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> 
```

With the REPL, I can run functions individually or see the values of variables inside the REPL. Instantly.

I can run each unit of code individually. If you have never used the Common Lisp REPL, it's hard to describe how valuable this is with words.

Try it.

That's it. Bye for now.


My Most Used Vim 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 stay away from frameworks in personal projects.

That sounds weird because most of my frontend work uses Next.js/React.js. Most
projects I work on involve adding new features to existing applications or
refactoring them.

When I was running Frosty Response, I often chose to not framework. I do not
like suprises. I do not like when non essential things change too often.

Frameworks are large code bases that do a lot of work in the back ground. But
the are also __tools__.

How would you like it if you work up one day, determined to finish building
your new vintage draw. You pulled out your hammer, and it is a different
shape.

Not cool.

Then there is the "multi-level framework problem". This happens when a framework requires another framework. How do you diagnose issues?

Actually it's quite easy... throw programmers at problem.

To accomplish authentication in Next.js (a framework), you need to use Next_Auth (another framework)

Most people use this. And most people are happy. It is a good tool.

But _NextAuth not fully support email and password authentication_. They make it intentionally difficult.

As a developer, I do not understand opinionated development tools. I like to have the freedom to make micro changes.

So I developed a custom system for authenticating users in Next.js, with email and password.

An important point I want to make about email and password authentication is
that not everyone has a Google, Apple or Facebook account for OAuth 2.0 login.
Email and password is still necessary. 

> Note - This flow uses TypeScript.
> Note2 - I will ommit imports and exports from code 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.

First, the packages. Second 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

I am creating the types for the entire project in one file (except
InitialToken type).

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

First, we need to create a 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 it's 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 is a standard form. Nothing special. I will focus on 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.


Accessing Protected API Routes With cURL


When I build new applications, I ignore the frontend completely. 

...

## How to login (get auth token) with curl

To login to an account with curl we need to pass our username and password as
follows in the curl request (without the square brackets):

```bash
--user [username]:[password]
```

This will send the username and password to the API `req.headers.authorization` value as an encoded value:

```js
Bearer [encoded value]
```

Inside the API route we need to convert this back to a username and password
value. So we can use it

```js
const base64Credentials = req.headers.authorization.split(" ")[1];
const credentials = Buffer.from(base64Credentials, "base64").toString("utf8");
const [username, password] = credentials.split(":");
```

We can not use the username to find a user in the DB. And use the password to
verify its value (with bcryptjs).

Assuming we found the user and verified the password, we now  can return the
jwt token: 

```js
const token = jwt.sign({email: user.email}, "superpassword")
return token
```

unlike the browser, we cannot store the token in a session or cookie. So, we
need to store it in a bash enviornment variable:

```bash
$> TOKEN=$(curl --request POST \
    -- url http://[apiroute]
    -- user [username]:[password])
```
The returned token will be saved in TOKEN.

## How to protect an API route

API routes can be protected with an authentication function (middleware) that we pass into
the route inside the server logic.

```js
function protectRoute(req, res, next) {
  if (!req.headers.authorization) {
    res.send("Not Authorized");
  } else {
    const token = req.headers.authorization.split(" ")[1];
    jwt.verify(token, "supersecret");
    next(); //<-- mandatory
  }
}

server.get("/admin", protectRoute, adminController)
```
The protected route looks in the authorization headers for a jwt token. If
found, jwt.verify is called to validate the token. If the token is wrong or
expired, the route will return an error.

## How to pass a jwt token to a protected route with curl

```bash
curl -- request GET \
  -- headers "Authorization: Bearer ${TOKEN}"
  -- url http://[protectedRoute]

```


Use Markdown To Power Your Blog Content With Next.js


I have been writing in Markdown for a decade. This website is a Next.JS
application. It's overkill but I use it to experiment with new ideas.

But my blog content are markdown files. In this post I will discuss how.

The focus will be on and using the `react-markdown` library.

## Install react-markdown

first, install react markdown with `npm i react-markdown`.

second, install react-syntax-highlighter with `npm i react-syntax-highlighter`

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

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

## Parsing Markdown into HTML

There are many ways to extract markdown from a file. That is outside the scope of this article. 

In the next 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 isn't activated for code blocks.

We first need to import 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>
						);
					},
				}}
			>

```

That's it. Bye for now.


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) 


Five Things To Reminder When Deploying Your Web App With Nginx

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


90% of the my applications are deployed on an Ubuntu server. 

Whether it's a Next.js app, Node.js server or a C# API, I use Nginx as a reverse proxy server. 

Setting up a new application, on a new server is not something I do every day. So it's easy to forget minor details that may have a large impact. (And, it's also why I write articles like this... as a reminder.)

Below is a list of reminders that, if missed, will cause the your application to fail.

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

## 1. Use the root section in Nginx properly

Your web files do not need to be in `/var/www`. You can put them anywhere. Whereever you decide to put them, make sure your point to the root location. 

In the server block top level, add a root:

```yaml
server {
    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`. 

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

`> sudo ufw allow 443`

## 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`

Even better, create a script to automate it.

## 4. Server names are required if you host multiple sites on the same server

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

A `server_name` which points to the correct domain allows this.

In the server block of the Nginx file, add:

```toml
server {
  server_name yourWebsite.com www.yourWebsite.com;
  ... 
}
```

```toml
server {
  server_name yourWebsite2.com www.yourWebsite2.com;
  ... 
}
```
## 5. Certbot for free ssl 

Remember to get ssl setup for your website

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

That's it. Bye for now. 


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

Productivity Is Not The Same As Effectiveness


The productivity industry is a $1billon dollar distraction.

A six years ago, I was obsessed with __productivity__. The result of my obsession was ineffeciveness.

Today, I spend zero time thinking about how productive I am. And yet, I am the most productive i've ever been. What changed?

My truth about __trying__ to become more productive by __learning__ about productiveity is this: **I stopped investing time into it. And put that time into my work.**

And just like magic, my effectiveness increase 3-fold.

## Ineffective Programmers

When I first became a software engineers I was facinated about hjfocus 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 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 32 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) 


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.



Pinned Articles

Sorted By Tag

All Articles