DEV Community: Jordan Gregory

Easy Access to Terminal Commands in Neovim using FTerm

Jordan Gregory — Mon, 18 Mar 2024 13:26:14 +0000

Have you ever found yourself having to switch contexts too many times in the course of using your favorite text editor Neovim? I certainly have.

Having a common set of tools already set up in different windows or sessions in Tmux or Zellij is obviously an option, but there is a subset of us ( 👋 ) that would rather just have fingertip access to our common tools inside of our editor.

This quick article will show you how to achieve such a state.

The Setup

Obviously, you should probably have Neovim installed and are somewhat familiar working with it.

In my case, I have switched to Lazy.nvim for all of my Neovim plugin needs ( Thanks again Folke! ), so it would be great if you were at least minimally familiar with how Lazy works as well.

The last thing you really need is a common set of tools that you want fingertip access to. I really commonly use LazyGit and K9s in my day job so those are the tools I will show off in this article.

The Plugin

To achieve our goals of fingertip access nirvana, we are going to be using a plugin called FTerm.nvim.

If you want to see an exhaustive list of all the things you can do with FTerm, go check out the repository (and leave a star or whatever).

The How

In typical Lazy.nvim fashion, we simply add a lua file in the normal plugins directory that looks like so:

-- ~/.nvim/lua/plugins/fterm.lua

return {
  {
    'numToStr/FTerm.nvim'
  }
}

If you save that, you now have access to FTerm as soon as you run :Lazy or restart Neovim.

The default state is not exactly ergonomic though because to launch it, you would need to run :lua require("FTerm").toggle() to get it to show up, but now that we have access to the FTerm API, we can get all kinds of fancy with user commands or with custom keybindings as I will show here.

-- ~/.nvim/lua/plugins/fterm.lua

return {
  {
    'numToStr/FTerm.nvim',
    config = function()
      local fterm = require('FTerm')
      vim.keymap.set('n', '<leader>tt', function() fterm:toggle() end, {desc = '[T]oggle [T]terminal'})
      vim.keymap.set('t', '<leader>tt', function() fterm:toggle() end, {desc = '[T]oggle [T]erminal'})
    end,
  }
}

This didn't add a whole lot, but now FTerm is a whole lot easier to get access to. While in NORMAL (n) mode, you simply have to press <leader>tt to toggle open the floating terminal, and the same to toggle it closed assuming you are in that floating terminal (which is in TERM (t) mode).

FTerm, by default, will simply open your $SHELL which is great for a whole lot of reasons, but we are wanting direct access to a handful of terminal commands, so lets add them:

-- ~/.nvim/lua/plugins/fterm.lua

return {
  {
    'numToStr/FTerm.nvim',
    config = function()
      local fterm = require('FTerm')
      vim.keymap.set('n', '<leader>tt', function() fterm:toggle() end, {desc = '[T]oggle [T]terminal'})
      vim.keymap.set('t', '<leader>tt', function() fterm:toggle() end, {desc = '[T]oggle [T]erminal'})
    end,
  },
  {
    'numToStr/FTerm.nvim',
    name = 'FTerm.LazyGit.nvim',
    config = function()
      local fterm = require('FTerm')
      local lazygit = fterm:new({
        cmd = 'lazygit',
      })

      vim.keymap.set('n', '<leader>lg', function() lazygit:toggle() end, {desc = 'Toggle [L]azy[G]it'})
      vim.keymap.set('t', '<leader>lg', function() lazygit:toggle() end, {desc = 'Toggle [L]azy[G]it'})
    end,
  },
  {
    'numToStr/FTerm.nvim',
    name = 'FTerm.k9s.nvim',
    config = function()
      local fterm = require('FTerm')
      local k9s = fterm:new({
        cmd = 'k9s',
      })

      vim.keymap.set('n', '<leader>tk', function() k9s:toggle() end, {desc = '[T]oggle [K]9s'})
      vim.keymap.set('t', '<leader>tk', function() k9s:toggle() end, {desc = '[T]oggle [K]9s'})
    end,
  }
}

So things got just a little more complicated, but lets walk through it:

Now we have 3 plugins being returned by the same lua file that I've called fterm.lua, but if you notice, they are all the same source, just renamed. This is how I am getting custom behavior.

The first is just the behavior we defined before because I do still want access to just my $SHELL.

The second renames the plugin from the default (FTerm.nvim) to FTerm.LazyGit.nvim (this is just so Lazy doesn't smash all of the configs together in one directory and we get weird behavior). The last little bit we added was the custom command we want to run; lazygit in this case. We then do basically the same thing as before, but with new keybindings to get easy access to our custom command.

The third is a repeat of the second, but with k9s rather than lazygit.

In doing this, I now have access to lazygit in a floating window just by typing <leader>lg and access to k9s in a floating window by typing <leader>tk.

Feel free to rinse and repeat with your favorite commands 😄

If you liked this content, let me know and I can create some more. Even better if you have a topic. Heck, maybe I'll even make a series.

Writing a Rust CLI to complete the DigitalOcean Functions Challenge

Jordan Gregory — Wed, 15 Jun 2022 04:24:44 +0000

Prelude

To continue from my Go CLI write-up and my Python CLI Write-up, I will go in to detail about writing a Rust CLI to perform the same DigitalOcean Functions Challenge

The Code

I'm sensing a theme here, but much like my last two write-ups, I simply threw everything into the main.rs file that was created with the cargo new sharks command.

First things first, if you have done any development with Rust that accesses the web via JSON, there are a few essential crates to grab:

Reqwest is a crate that makes sending web requests simple, and even though I used the blocking client, you can use Tokio to make Reqwest asynchronous just as simply.
Serde / serde_json / serde_derive are obvious choices for serialization/deserialization.

For the CLI, I personally like to use Structopt, but feel free to use whatever you are comfortable with.

My Cargo.toml dependencies look like so:

[dependencies]
structopt = { version = "0.3" }
reqwest = { version = "0.11", features = ["blocking", "json"]}
serde = { version = "1.0" }
serde_json = { version = "1.0" }
serde_derive = { version = "1.0" }

Now, knowing that I want something similar to my previous two write-ups, I started with the API URL constant and some Request and Response structs:

// src/main.rs

use std::collections::HashMap;
use serde_derive::{Serialize,Deserialize};

const API_URL: &str = "https://functionschallenge.digitalocean.com/api/sammy";

// Obviously, the serialize trait needs to be here so that
// we can turn this into JSON later. I usually use debug here
// as well just in case I need to do a little println!
// debugging.
#[derive(Debug, Serialize)]
struct Request {
    name: String,

    // Because of the type keyword, we needed to name this
    // field something other than type, so _type suits me
    // just fine, but we have to tell serde that we want to
    // rename this field when we go to actually serialize
    // the JSON.
    #[serde(rename(serialize = "type"))]
    _type: String,
}

// Again, and obvious deserialize trait needed with the
// response. And again, the almost obligatory Debug trait.
#[derive(Debug, Deserialize)]
struct Response {
    message: String,

    // In this case, we need to tell serde to give us the
    // "zero" value of a HashMap<String,Vec<String>> because
    // a successful response will not have this field, and
    // will cause the app to panic because this field doesn't 
    // get used.
    #[serde(default)]
    errors: HashMap<String, Vec<String>>
}

And for the request/response, this is really all we need to do.

Now, I'll set up the CLI struct really fast:

// src/main.rs
...

use structopt::StructOpt;

...

// I went ahead and created a "possible values" constant here
// so that we have the CLI filter our sammy type input for us.

const TYPE_VALUES: &[&str] = &[
    "sammy",
    "punk",
    "dinosaur",
    "retro",
    "pizza",
    "robot",
    "pony",
    "bootcamp",
    "xray"
];

...

// In classic fashion, we have to derive the structopt trait
// as well as the obligatory debug trait. The additional
// structopt config follows it.
#[derive(Debug, StructOpt)]
#[structopt(name = "sharks", version = "0.1.0")]
struct Opt {
    #[structopt(long = "name")]
    sammy_name: String,

    #[structopt(long = "type", possible_values(TYPE_VAULES))]
    sammy_type: String,
}

Now all we have to do is pull it all together in the main() function:

// src/main.rs

...

fn main() {
    // Build the opt struct from the arguments provided
    let opt: Opt = Opt::from_args();

    // Build a new request from those arguments
    let r: Request = Request {
        // notice the clones here, I needed that values later
        // in the output, so this was just the most painless
        // way to not fight the borrow checker :D
        name: opt.sammy_name.clone(),
        _type: opt.sammy_type.clone(),
    };

    // Grab a new blocking client. I don't care if this
    // blocks because of what this app is and does, but
    // you may care more. Feel free to try this async.
    let c = reqwest::blocking::Client::new();

    // Build the JSON from our Request struct
    let resp_body = serde_json::to_string(&r).unwrap();

    // Send the request
    let resp: Response = c.post(API_URL)
        .header("ACCEPT", "application/json") // Set a header
        .header("CONTENT-TYPE", "application/json") // Set a header
        .body(resp_body) // Set the body
        .send() // Send it
        .expect("failed to get response") // Don't fail
        .json() // Convert response to JSON
        .expect("failed to get payload"); // Don't fail

    // Here, I'm just doing a little error checking to see if
    // something exists. There are obviously far nicer ways
    // to do this, but again, this was fast and accomplished
    // the goal.
    if resp.errors.len() > 0 {
        println!("ERROR: {:#?}", resp.errors);
        return
    }

    // Give us a success message if it worked!
    println!("Successfully created Sammy: {} of type {}", opt.sammy_name, opt.sammy_type)
}

With all this written down, now we can just do a cargo run -- --name <your sammy name> --type <your sammy type> and it works as expected.

Conclusion

Like usual, if you want to see the full file, feel free to check it out on the repository here:
https://github.com/j4ng5y/digitalocean-functions-challenge/tree/main/rust

Writing a Python CLI to complete the DigitalOcean Functions Challenge

Jordan Gregory — Mon, 13 Jun 2022 19:38:19 +0000

Prelude

To continue from my Go CLI write-up, I will go in to detail about writing a Python CLI to perform the same DigitalOcean Functions Challenge

The Code

Like the Go code I wrote earlier, I just threw everything into main.py for this example, so to get started, I simply created a main.py file and installed the first few dependencies I knew I wanted to use with Pipenv like so:

pipenv install requests structlog click

Requests I always use when I have to interface with the web in Python applications.
Structlog is my structured logging package of choice for Python applications.
Click is my CLI framework of choice for Python applications.

In doing this, now I have a Pipfile and a Pipfile.lock and can go about doing my actually development.

First, I knew I wanted to have a Request and a Response class defined, and knowing what I know from the previous example, I was able to just write the classes.

#!/usr/bin/env python3
import logging
import sys

import requests
import structlog
import click


class Request:
    """
    The Request class will contain all of our methods to handle a request to the DigitalOcean Function Challenge api.

    Attributes
    ----------
    API_URL : str
        The API_URL attribute is a static string to hold the URL of the API to access.

    name: str
        The name attribute is the name of the Sammy that we wish to create.

    t : str
        The "t" attribute is the type of the Sammy that we wish to create. This attribute is named "t" to avoid
        conflicting with the "type" keywork.

    log : structlog.BoundLogger
        The log attribute is not an attribute to be dealt with directly, rather the _get_log(self) method will retrieve
        the bound logger for us.

    Methods
    -------
    _set_name(name: str)
        This method sets the value of the name attribute.

    _set_type(t: str)
        This method sets the value of the t attribute.

    _set_log()
        This method gets the application logger and sets it to the log attribute.

    _get_url() -> str
        This method returns the value of the API_URL attribute.

    _get_name() -> str
        This method returns the value of the name attribute.

    _get_type() -> str
        This method returns the value of the t attribute.

    _build_headers() -> dict
        This static method returns a dictionary to be used as a request header.

    _build_request_body() -> dict
        This method returns a dictionary to be used as the request body.

    do() -> requests.Response
        This method is the primary class method and is used to perform the HTTP POST request.
    """
    def __init__(self, name: str, t: str):
        """
        Parameters
        ----------
        :param name: str
            The name to give to your new Sammy.
        :param t: str
            The type to give to your new Sammy.
        """
        self.API_URL = "https://functionschallenge.digitalocean.com/api/sammy"
        self.name = None
        self.t = None
        self.log: structlog.BoundLogger = None
        self._set_name(name)
        self._set_type(t)
        self._set_log()

    def _set_name(self, name: str):
        """This method sets the value of the name attribute.

        Parameters
        ----------
        :param name: str
            The name of the new sammy to create.
        """
        self.name = name

    def _set_type(self, t: str):
        """This method sets the value of the t attribute.

        Input validation is handled at the CLI layer. We will need to do further input validation if we don't do the
        validation at the CLI layer.

        Parameters
        ----------
        :param t: str
            The type of the new sammy to create.
        """
        self.t = t

    def _set_log(self):
        """This method gets the application logger and sets it to the log attribute."""
        self.log = structlog.stdlib.get_logger()

    def _get_url(self) -> str:
        """This method returns the value of the API_URL attribute."""
        return self.API_URL

    def _get_name(self) -> str:
        """This method returns the value of the name attribute."""
        return self.name

    def _get_type(self) -> str:
        """This method returns the value of the t attribute."""
        return self.t

    def _build_request_body(self) -> dict:
        """This method returns a dictionary to be used as the request body."""
        return {
            "name": self.name,
            "type": self.t,
        }

    @staticmethod
    def _build_headers() -> dict:
        """This static method returns a dictionary to be used as a request header."""
        return {
            "Accept": "application/json",
            "Content-Type": "application/json"
        }

    def do(self) -> requests.Response:
        """This method is the primary class method and is used to perform the HTTP POST request."""
        return requests.post(url=self._get_url(), json=self._build_request_body(), headers=self._build_headers())


class Response:
    """
    The Response class will contain all of our methods to handle a response from the DigitalOcean Functions Challenge
    api.

    Attributes
    ----------
    resp : requests:Response
        The actual response that is retrieved from performing the do() function from our Request class.
    log: : structlog.BoundLogger
        The log attribute is not an attribute to be dealt with directly, rather the _get_log(self) method will retrieve
        the bound logger for us.

    Methods
    -------
    _set_log() -> None
        Gets the application logger.

    _get_status_code() -> int
        Gets the HTTP status code from the requests.Response object the class was initialized with.

    _has_errors() -> bool
        A helper to let us know if errors exist in the requests.Response object the class was initialized with.

    do() -> None
        The primary method of this class. Do is used to print the information from the response to the terminal.
    """
    def __init__(self, resp: requests.Response):
        """
        Parameters
        ----------
        :param resp: requests.Response
            A response object from our Request class do() method.
        """
        self.resp = resp
        self.log: structlog.BoundLogger = None

        self._set_log()

    def _set_log(self):
        """Gets the application logger."""
        self.log = structlog.stdlib.get_logger()

    def _get_status_code(self) -> int:
        """Gets the HTTP status code from the requests.Response object the class was initialized with."""
        return self.resp.status_code

    def _has_errors(self) -> bool:
        """A helper to let us know if errors exist in the requests.Response object the class was initialized with."""
        respj: dict = self.resp.json()
        if "errors" in respj:
            return True
        else:
            return False

    def do(self) -> None:
        """The primary method of this class. Do is used to print the information from the response to the terminal."""
        if self._has_errors():
            for e in self.resp.json()["errors"]:
                for ee in self.resp.json()["errors"][e]:
                    self.log.error(ee)
                return
        else:
            self.log.info(self.resp.json()["message"])

Note: Notice the shebang at the top of the file. I personally like to do this with Python applications so I can call the file directly. In doing this though, you have to provide the file with the appropriate permissions to run. In my case (on a unix-like OS), I just had to run chmod +x main.py to allow it to run.

Now we have a few classes to handle our request and our response.

I wanted structlog to handle things a little more json-y for me, so I needed to add a logger configuration function as well like the following:

...

def configure_logger():
    """Basic application level logging configuration"""
    logging.basicConfig(
        format="%(message)s",
        stream=sys.stdout,
        level=logging.INFO,
    )
    structlog.configure(
        processors=[
            structlog.processors.add_log_level,
            structlog.processors.JSONRenderer(),
        ],
        logger_factory=structlog.stdlib.LoggerFactory(),
    )

Now that our logger is configured, all we had to do pull it all together with a CLI:

@click.command()
@click.option('-n', '--name', "name", help='The name to give to your new Sammy.')
@click.option('-t', '--type', "t", type=click.Choice([
    "sammy",
    "punk",
    "dinosaur",
    "retro",
    "pizza",
    "robot",
    "pony",
    "bootcamp",
    "xray"
], case_sensitive=False), help='The type to give to your new Sammy.')
def main(name, t):
    configure_logger()
    req = Request(name, t)
    response = req.do()
    resp = Response(response)
    resp.do()


if __name__ == "__main__":
    main()

Note: Again, notice the if __name__ == "__main__" statement, this is just the line that says "Do this if the file is called directly".

Really all this main() function does (with the help of some Click decorators), is to set the name flag, the t flag for the type, and then run our functions as we have designed them.

Running our new app is a simple as ./main.py --name <my name> --type <my type>.

Like usual, if you want to see the full file, feel free to check it out on the repository here:
https://github.com/j4ng5y/digitalocean-functions-challenge/tree/main/python

Writing a Go CLI to complete the DigitalOcean Functions Challenge

Jordan Gregory — Thu, 09 Jun 2022 15:39:23 +0000

The Challenge

DigitalOcean released their version of serverless functions and released a challenge recently to showcase them as well. Being one that doesn't like to turn down a challenge, I took DigitalOcean up on their challenge with a Go CLI.

Getting started

First, it was pretty simple to read the challenge on the challenge website, but it left a few questions to be answered.

The Content-Type and Accepted headers tell me that this application accepts and sends back JSON data, but the directions in the overall documentation don't really say that other than that a parameters file is a JSON document, but I went ahead and wrote my CLI as thought the API did accept and send back JSON. I was correct, but the documentation here wasn't entirely clear.
Once you have deployed you "Sammy" (or your DigitalOcean mascot). You have to have a keen eye to catch it. If you don't believe it's there, you can easily inspect the page elements for something that looks like the Sammy that you created.

The Code

In this case, as this was just a throw away app, I just wrote everything into a main.go file and turns on modules with go mod init <github.com/your_handle/project_name>.

The first thing to do was to start with a CLI that would accept the name and type parameters as described in the instructions. I opted to put these flags in the init function and load a few module variables so I didn't really have to do much with them and I expected them to run each time the app was run.

// main.go

package main

import (
    "flag"
)

var (
    sammyname string
    sammytype string
)

const (
    API_URL = "https://functionschallenge.digitalocean.com/api/sammy"
)

func init() {
    flag.StringVar(&sammyname, "name", "", "The name to give your new Sammy.")
    flag.StringVar(&sammytype, "type", "", "The type to assign to your new Sammy.")
    flag.Parse()
}

func main() {}

Running our app with go run main.go now gives us our command line flags.

After looking again at the docs, the Sammy Type parameter is really a enum, so I created a type and a few helper functions and used them to set the variable appropriately.

// main.go
...

import (
    "fmt"
    "log"
    "flag"
    "strings"
)

var (
    sammyname string
    sammytype sammyType
)

type (
    sammyType string
)

const (
    API_URL = "https://functionschallenge.digitalocean.com/api/sammy"

    sammyType_Sammy sammyType = "sammy"
    sammyType_Punk sammyType = "punk"
    sammyType_Dinosaur sammyType = "dinosaur"
    sammyType_Retro sammyType = "retro"
    sammyType_Pizza sammyType = "pizza"
    sammyType_Robot sammyType = "robot"
    sammyType_Pony sammyType = "pony"
    sammyType_Bootcamp sammyType = "bootcamp"
    sammyType_XRay sammyType = "xray"
)

func NewSammyType(s string) (sammyType, error) {
    var t sammyType
    switch strings.ToLower(s) {
    case "sammy":
        t = sammyType_Sammy
    case "punk":
        t = sammyType_Punk
    case "dinosaur":
        t = sammyType_Dinosaur
    case "retro":
        t = sammyType_Retro
    case "pizza":
        t = sammyType_Pizza
    case "robot":
        t = sammyType_Robot
    case "pony":
        t = sammyType_Pony
    case "bootcamp":
        t = sammyType_Bootcamp
    case "xray":
        t = sammyType_XRay
    default:
        return "", fmt.Errorf("%s is an invalid sammyType", s)
    }
    return t, nil
}

func (s sammyType) String() string {
    return string(s)
}

func init() {
    flag.StringVar(&sammyname, "name", "", "The name to give your new Sammy.")
    st := flag.String("type", "", "The type to assign to your new Sammy.")
    flag.Parse()

    sammyType, err := NewSammyType(*st)
    if err != nil {
        log.Fatal(err)
    }
}

...

Now, we had something that is type correct for the API.
Next, I simply wrote in a struct to represent the request, as well as a few helper functions there as well.

// main.go
...

import (
    "fmt"
    "log"
    "flag"
    "strings"
    "bytes"
    "encoding/json"
    "io"
    "io/ioutil"
)

...

type (
    sammyType string

    sharksRequest struct {
        Name string `json:"name"`
        Type string `json:"name"`
    }
)

// func NewSharksRequest() is something that I normally write, but there was really no point in this case.

func (req *sharksRequest) setName(name string) *sharksRequest  {
    req.Name = name
}

func (req *sharksRequest) setType(t sammyType) *sharksRequest {
    req.Type = t.String()
}

func (req *sharksRequest) marshalJSON() ([]byte, error) {
    return json.Marshal(req)
} 

...

Now we had something to send to the API. So it was just a matter of sending a request, and seeing what the output was as the output wasn't documented at all (that I could see).

// main.go
...

func main() {
    // Set some variables to use:
    // Mostly we need the set up the base request struct and
    // the http client.
    var (
        c := http.DefaultClient
        r := &sharksRequest{
            Name: sammyname,
        }
    )

    // We can use our helper function to make sure we are
    // getting correct values here.
    r.setType(NewSammyType(sammytype))

    // marshal the struct to JSON
    rb, err := r.marshalJSON()
    if err != nil {
        log.Fatal(err)
    }

    // Build the new http request
    req, err := http.NewRequest(http.MethodPost, API_URL, bytes.NewBuffer(rb))
    if err != nil {
        log.Fatal(err)
    }

    // Set the required headers (from the docs).
    req.Header = map[string][]string{
        "Accept": []string{"application/json"},
        "Content-Type": []string{"application/json"},
    }

    // Send the request
    resp, err := c.Do(req)
    if err != nil {
        log.Fatal(err)
    }

    // Because we don't know the structure of the output
    // we can just output the response to the terminal.
    defer resp.Body.Close()

    out, err := ioutil.ReadAll(resp.Body)
    if err != nil {
        log.Fatal(err)
    }
    log.Println(string(out))
}

Running our code via go run, go run main.go -name <myname> -type <mytype> actually works at this point, but I don't like the raw byte string that we are outputting. In a real API handler, we want to put the response into a struct, so now that I can see some output, I can build a struct.

The output for me looked something like this for a success:

{"message":"Shark created successfully! Congrats on successfully completing the functions challenge!"}

and this for a failure:

{"message":"The name has already been taken.","errors":{"name":["The name has already been taken."]}}

So, with this info in mind, I wrote another struct and some more helper methods to load that info into:

// main.go
...

type (
    sammyType string

    sharksRequest struct {
        Name string `json:"name"`
        Type string `json:"name"`
    }

    sharksResponse struct {
        // Message seems pretty strait forward and exists 
        // in both the responses, so this is a pretty safe
        // bet
        Message string `json:"message"`
        // Errors on the other hand, I don't have enough
        // info to strongly type the response, but the
        // map type here works for now. I can change it
        // later if there is more I want to do with the
        // errors.
        Errors map[string][]string `json:"errors"`
    }

    // func NewSharksResponse() is something again that I would normally write, but it isn't necessary in this example

    func (resp *sharksResponse) unmarshalJSON(body io.ReadCloser) error {
        b, err := ioutil.ReadAll(body)
        if err != nil {
            return fmt.Errorf("unable to read http body: %w", err)
        }

        return json.Unmarshal(b, resp)
    }
)

...

Now that we have this, we can add it to our main function:

// main.go
...

func main() {
    // Set some variables to use:
    // Mostly we need the set up the base request struct, 
    // the response struct, and the http client.
    var (
        c := http.DefaultClient
        r := &sharksRequest{
            Name: sammyname,
        }
        R := &sharksResponse{}
    )

    // We can use our helper function to make sure we are
    // getting correct values here.
    r.setType(NewSammyType(sammytype))

    // marshal the struct to JSON
    rb, err := r.marshalJSON()
    if err != nil {
        log.Fatal(err)
    }

    // Build the new http request
    req, err := http.NewRequest(http.MethodPost, API_URL, bytes.NewBuffer(rb))
    if err != nil {
        log.Fatal(err)
    }

    // Set the required headers (from the docs).
    req.Header = map[string][]string{
        "Accept": []string{"application/json"},
        "Content-Type": []string{"application/json"},
    }

    // Send the request
    resp, err := c.Do(req)
    if err != nil {
        log.Fatal(err)
    }

    // We have a structure to unmarshal to now, so lets use
    // it.
    defer resp.Body.Close()

    if err := R.unmarshalJSON(resp.Body); err != nil {
        log.Fatal(err)
    }

    // Now we can send some better info to the terminal
    if len(R.Errors) > 0 {
        log.Fatalf("An error occurred. Message: %s, Errors: %v", R.Message, R.Errors)
    }

    log.Println(R.Message)
}

And with that, I would say we have a successful application. To see the full code, feel free to check out my repository for the challenge here: https://github.com/j4ng5y/digitalocean-functions-challenge

I will put more languages in this repo too, so follow the instructions in the README to look at other examples (as I create them). I will have similar write-ups for those other languages as well.

Basic auth with NGINX Ingress Controller on Kubernetes

Jordan Gregory — Thu, 20 May 2021 15:27:07 +0000

So, I couldn't find a lot of good resources online when I went to do this yesterday, so I figured I would post what I did to accomplish this task.

This particular post will not try to explain the basics of Kubernetes Ingress controllers, if the need is there, I can write another post explaining more of the basics. Feel free to comment on the post if you would like me to do so.

First things first, let me start by clearing up a few things:

The first order of business is that I am in no way affiliated with NGINX or F5, I am just a fan of their products.

The NGINX Ingress Controller, provided by F5 (the company that owns NGINX) is not the same thing as the ingress-nginx controller (the ingress provided and maintained by the Kubernetes community).

I don't have anything against the ingress-nginx controller, but there are a number of things that the NGINX Ingress Controller does that ingress-nginx does not, and I needed those particular features. Again, if you would like a breakdown of the differences, I could write another post, but I feel like F5 did a decent job with this post:
Which NGINX Ingress Controller am I using?

Both are open source (but the NGINX Ingress Controller has a paid support option) and I'm pretty sure that the following steps can be performed with the ingress-nginx controller as well, but I've not tested it.

With that out of the way, here is what I did to enable BASIC AUTH using the NGINX Ingress Controller by F5.

Assumptions and Necessary Pre-Work

So, my basic assumptions are these:

You have a running Kubernetes cluster that you can access ... somewhere.
You have the NGINX Ingress Controller installed (NGINX Plus is not necessary, but enabling snippets is necessary).

If you do not have the NGINX Ingress Controller installed, just follow the steps in the guides:

The only real pre-work step is that you have to have a valid .htpasswd file to provide to the controller pods.

In my case, I did the following in an Ubuntu container:

apt-get update
apt-get install apache2-utils
htpasswd -c .htpasswd <my_first_user>
<< The utility will ask you to input the password for the user >>

cat .htpasswd

If you need more than a single user, feel free to rinse//repeat the htpasswd -c ... step for as many users as you need.

I then just copied the contents of that file via cat, but you could have just as easily mounted a local volume to the running container and saved the file there for easier use.

Adding the .htpasswd file to the existing/future NGINX Ingress Controller pods

First, we have to add the contents of the .htpasswd file to either a ConfigMap or a Secret, and given the contents, I chose a Secret, so to do this, I created this resource:

# Contents of htpasswd.yaml
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: htpasswd
  namespace: nginx
stringData:
  .htpasswd: |
    << CONTENTS OF .HTPASSWD THAT YOU COPIED FROM PRE-WORK >>

and then simply applied it using kubectl apply -f htpasswd.yaml, but feel free to call the file whatever you want.

If you happened to save the contents of the .htpasswd to a file before hand, you could have simply run kubectl create secret generic htpasswd -n nginx --from-file=<your_file>, in hindsight, I would probably do this.

Now, we have to add this file the NGINX pods. To do this step, we need to get the deployment name that we have to edit:

kubectl get deployments -n nginx

NAME           READY  UP-TO-DATE  AVAILABLE  AGE
nginx-ingress  1/1    1           1          15d

Using this, we can simple edit the resource using the following command:

kubectl edit deployment nginx-ingress -n nginx

The modifications we have to make are as follows:

...
spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: nginx-ingress
        ...
        # THIS IS WHAT WE NEED TO ADD TO THE CONTAINER
        volumeMounts:
        - mountPath: /etc/apache2
          name: htpasswd
        ...
      # AND THIS IS WHAT WE NEED TO ADD TO THE OVERALL SPEC
      volumes:
      - secret:
          defaultMode: 420
          items:
          - key: .htpasswd
            path: .htpasswd
          name: htpasswd
        name: htpasswd
      ...

If you are comfortable with patching Kubernetes resources, that would be a viable alternative to just editing, but I was in a time crunch.

Modifying your ingress to use the work

So now, the last step is you modify your ingress to actually use everything we have done up to this point. So again, we need to get the name of your ingress and edit it.

kubectl get ingresses

NAME        CLASS  HOSTS                      ADDRESS  PORTS AGE
my-ingress  nginx  my-service.whatever.myTld  1.2.3.4  80,443  15d

Go ahead and edit your ingress like so:

kubectl edit ingress my-ingress

The only changes we need to make are to the annotations of the ingress, and the annotations we need to add are:

metadata:
  ...
  annotations:
    ...
    # THIS IS THE ADDITION
    nginx.org/server-snippets: |
      auth_basic "my-ingress";
      auth_basic_user_file /etc/apache2/.htpasswd;

Once you save the resource, go ahead and try to access you ingress ... and voila! you are presented with a login popup that we are all so familiar with.

Parting Words

Yeah, basic auth is kind of dumb, but there are still reasons for it. If you are interested in paying for NGINX Plus you get access to automated JWT authentication and things of that nature, but I simply just didn't need all of that at this layer. Other ingress controllers (ambassador, kong, etc...) may make this process easier or not, but we don't use them, so that is the reason for this post.

Like I said, this may very well work with the ingress-nginx controller as well, but, I'll leave that to y'all to work out and report back.

Svelte + Rust WASM = ❤️

Jordan Gregory — Sat, 17 Oct 2020 03:13:35 +0000

So, over at STLRust, I've been looking for the best JS framework to pair with my WASM escapades for a while.

At this point, I've all but written off the bigger frameworks such as React, Angular, and Vue for reasons beyond the scope of this article.

I decided on Svelte due to its minimalism ultimately.

On my path of bootstrapping my new stack though, I realized that there just isn't any real good documentation on doing this sort of thing yet, so I went ahead and created a template to solve half of that equation.

So if you are in the mood to play around with Svelte and WASM, feel free to give it a try:

https://git.stlrust.org/j4ng5y/svelte-wasm-template.git

I switched to OpenSuse

Jordan Gregory — Sat, 11 Jul 2020 22:22:44 +0000

So, after the news that SUSE purchased Rancher, I figured I would give them another go mostly because I love k3s almost as much as I love kind.

Is there anyone else to thought the same thing?

Is there anything else that made you make a hard OS switch like this?

a new way to download hashicorp tools

Jordan Gregory — Wed, 08 Jul 2020 18:53:54 +0000

Have you ever found yourself distro hopping, or supporting a large cluster of servers/workstations that all need certain hashicorp tools on them?

Have you ever started to make up curse words from having to go to the downloads section of each tool and/or build them from source every time?

Well folks, I have the tool for you. In an abundance of laziness, I created this tool to grab any/all of the hashicorp tools for you and put them in normal places.

j4ng5y / hashi.up

A simple app to get the hashicorp tools

Hashi.UP

This is a little tool to help grab the hashicorp tools more easily, rather than having to go to each web page, find your OS/Arch, and download the tool.

Getting the tool

Head on over to the Releases page and grab the version you need for your os. This is a simple binary, so no real installation is necessary.

On a *nix system, you may need to provide execution privliedges to run this tool: chmod +x hashi.up

Building from source

You would need to have Go installed and runable, to do this, head over to The Go Downloads Website and install it.

Additionally, you would need to have make installed.

Otherwise, simply clone this repository, cd into the repository direcotry, and run make && make install.

Usage


Usage
  hashi.up [flags]
  hashi.up [command]

Available Commands:
  help        Help about any command
  install     Install one, some, or all of the hashicorp

…

View on GitHub

Feel free to check it out and if you find a bug, I'm very interesting in making that a good tool, so I'll fix it in a jiffy.

How I Do Go Application Configuration in 2020

Jordan Gregory — Wed, 19 Feb 2020 21:18:33 +0000

There are many ways to handle application configuration in Go applications:

1). Simple environment variable using os.Getenv("MY_AWESOME_ENV")
2). Manually writing parsers for yaml/json/toml/hcl/envfile/java.properties files with their corresponding libraries.
3). Reading in from an external system (e.g. etcd, consul, etc...) using their individual libraries/api's.
4). CLI flags
5). Using a battle-harded library to do the hard stuff for you.

For this particular article, I'll focus on number 5 from the list above because this is actually the way I do configuration these days.

Enter The Viper 🐍

So these days, rather than spending cycles maintaining my own configuration library, I use one of the more popular configuration libraries in the wild today:

spf13 / viper

Go configuration with fangs

Viper allows you to do all of the common configuration scenarios and then some, so for my projects, it's the best of all worlds.

Set it up

In all things Go these days, installing dependencies, Viper included, is as simple as running the following command in your "Go Modules" enabled project:

go get -u github.com/spf13/viper

Note: The "-u" in the go get command just updates the dependency if you already have it for some reason or another. I usually tend to include it.

Great! How do I use it?

The repository hosts a few good examples on usage, so feel free to check it out here: https://github.com/spf13/viper/blob/master/README.md

Considering that you are reading this particular article though, I'll run through a few common scenarios that I find myself in when I write things these days.

The way I tend to really set this up is by defining a new Viper instance in a primary struct and having sub-components read from that configuration.

So let's pretend that I want to build an HTTP server.

I typically will have a struct defined somewhere in my application that will look something like this:

...
type Server struct {
    // HTTPServer should be fairly obvious
    HTTPServer    *http.Server

    // Configuration is the Viper instance we will reference later on
    Configuration *viper.Viper

    // You may or may not need this, but most apps do :D
    Database      *sql.DB
}

func NewServer(cfg *viper.Viper) (*Server, error) {
    // my fancy server setup constructor logic
}
...

All of my handlers (db, web, etc...), hang off of this Server struct in some way or another, so these components can access the configuration data.

Scenario 1: Environment Variables

Viper has a few ways to work with environment variables. Personally, I like to be fairly explicit with what I am expecting, but Viper gives us the ability to simply set an environment variable prefix to handle things later:

...
viper.SetEnvPrefix("MYAPP_") // All environment variables that match this prefix will be loaded and can be referenced in the code
viper.AllowEmptyEnv(true) // Allows an environment variable to not exist and not blow up, I suggest using switch statements to handle these though
viper.AutomaticEnv() // Do the darn thing :D
...

Scenario 2: Configuration Files (regardless of extension!!)

Usually, you would support a single configuration file format and stick with that until the app dies or a new major version came out, but you don't have to worry about that any more with Viper because it supports most of the big ones:

JSON
YAML
TOML
HCL
.env
.properties

You may be asking yourself, "But rando teacher internet guy, my config files are deeply nested! How do I access this data?". Getting data is easy fortunately and just follows the dot-notion way of life:

...
viper.Get("my.deeply.nested.configuration.item")
...

this will get the value of the "item" item from the following JSON file:

{
  "my": {
    "deeply": {
      "nested": {
        "configuration": {
          "item": "check it"
        }
      }
    }
  }
}

Configuration items don't have to be strings either, there are plenty of functions for pulling specific data types out:

GetBool
GetDuration
GetFloat64
GetInt
GetInt32
GetInt64
GetIntSlice
GetSizeInBytes
GetString
GetStringMap
GetStringMapString
GetStringMapStringSlice
GetStringSlice
GetTime
GetUint
GetUint32
GetUint64

The viper.Get() function just simply returns an interface{}, so if you can cast it, you can work with it.

To get this to work, all you have to do it provide a file name (without the file extension) and the 🐍 magic just does it's thing:

...
viper.SetConfigName("config")
...

If you really, really wanted to only support a particular config file type, you can do that too:

...
viper.SetConfigType("json")
...

You also can assign any number of other locations to look for this configuration file, the common ones I tend to use are something like the following:

...
viper.AddConfigPath(".")
viper.AddConfigPath("./config")
viper.AddConfigPath(path.Join(homeDirectory, ".my-awesome-app"))
viper.AddConfigPath(path.Join(homeDirectory, ".my-awesome-app/config"))
viper.AddConfigPath("/etc/my-awesome-app/")
viper.AddConfigPath("/etc/my-awesome-app/config")
...

Note: homeDirectory is a variable, so I have to set that somewhere 😄

You can also set full config file location with:

...
viper.SetConfigFile("./config.yaml")
...

Or feel free to just provide this information via a CLI flag. Speaking of which...

Scenario 4: CLI Input

I'll be real, I don't do much CLI stuff anymore without Viper's sister repo:

spf13 / cobra

A Commander for modern Go CLI interactions

My only exception here is for something that maybe needs to use klog or some other very, very small app, but 9/10 times, Cobra all day.

The pair make it very, very easy to add CLI elements to existing text config files. There are just a few elements (such as maybe a --debug/--config flag) that just live better on the CLI only and not in a config file that is automatically consumed by your app.

Here is a quick snippet of what my CLI's paired with Viper tend to look like:

...
func runCLI() {
    var (
        configFileFlag string

        vCfg = viper.New()

        myAppCmd = &cobra.Command{
            Use: "my-awesome-app",
            Version: myVersionConstant,
            Short: myShortDescriptionConstant,
            Long: myLongDescriptionConstant,
            Args: cobra.NoArgs(),
            PreRun: func(ccmd *cobra.Command, args []string{
                        vCfg.SetConfigFile(configFileFlag)
                        if err := vCfg.ReadInConfig(); err != nil {
                            log.Fatal("unable to read in config due to error: %+v", err)
                        }
                    },
            Run: func(ccmd *cobra.Command, args []string){
                     svr, err := server.New(vCfg)
                     if err != nil {
                         log.Fatalf("failed build server struct due to error: %+v", err)
                     }
                     if err := svr.Run(); err != nil {
                         log.Fatalf("server failed to start due to error: %+v", err)
                     }
                 },
        }
    )

    myAppCmd.Flags().StringVarP(&configFileFlag, "config", "f", "./config.yaml", "The path to the config file to use.")
    vCfg.BindPFlags("config", myAppCmd.Flags().Lookup("config"))

    if err := myAppCmd.Execute(); err != nil {
        log.Fatalf("the CLI failed to run due to error: %+v", err)
    }
}
...

Obviously, there is some crucial stuff missing from that, e.g. - my constant values, what my server.New(vCfg) function looks like, etc..., so to that end, I direct you to my article specific repository:
https://gitlab.com/j4ng5y/how-i-write-go-configs-in-2020.git

Scenario 5: All of the above

I won't go through the specific examples again 😄, but please to check out my repository to see them all in action:
https://gitlab.com/j4ng5y/how-i-write-go-configs-in-2020.git

Scenario 6: None of the above?

Yeah, that is right, you don't really have to use any user modifiable way to do this and still have access to the same API that all your other apps use. You just have to set them up:

...
viper.SetDefault("MyConfigItem", "holla atcha boi")
...

Conclusion

The choice for configuration is ultimately yours, but I have found that using Viper has greatly simplified my application boot-straping.

This article was not to give you a fully thought out way of doing anything in particular, just sharing my experiences with the community as a whole.

If you have any further questions Re: this or anything else really for that matter, please don't hesitate to comment here or reach out to me on twitter @j4ng5y.

You can find my on the Gopher slack @Jordan Gregory as well.

Conditionals in Python

Jordan Gregory — Thu, 20 Jun 2019 19:00:56 +0000

In the last article ( "Lists and Loops in Python" ), we created a programme that outputted our name, age, profession, favoriteAnimal and a list of our hobbies.

In this article, we're going to extend our programme to act differently depending on the age variable. Before we get started, let's remove some code we won't be needing in this article:

#!/bin/env python

# Start of our code

name = "Jordan"
# age = 31

hobbies = ["hiking", "playing music", "example1", "example2"]

print("Hello World. My name is {0}.".format(name))

print("I have {0} hobbies, and they are: ".format(len(hobbies)))

i = 0
while i < len(hobbies):
    print(hobbies[i])
    i+=1

# End of our code

Note : We've commented out the age parameter. While not a hard rule of Python, it is best practice that you not declare any unused variables. If we had declared it ( age = 29 ) but not referenced it - it is considered unused, but you will not see an error when running the programme like you would with a more strict language; rather, the interpreter will just clean up the memory at the end of the programme run.

Running the application now, you should see the following output:

$ python first.py
Hello World. My name is Jordan.
I have 4 hobbies, and they are: 
hiking
playing music
example1
example2

We're now going to bring back the age variable and, depending on its value, we'll print one of the following:

If age is less than 10, we will print "I am x years young".
If age is more than 10, we will print "I am x years old".

To do this we're going to use an if statement. The syntax for declaring an if statement in Python is simple:

if expression:
    // Run this code if expression evaluates to true

To perform an action dependant on age, we can simply add two if statements to our code ( Note: we have omitted all of the code not related to age, at this stage, to focus on what we're discussing )

#!/bin/env python

# Start of our code

age = 31

if age < 10:
    print("I am {0} years young".format(age))

if age > 10:
    print("I am {0} years old".format(age))

# End of our code

We are now performing two checks:

Is age less than ( < ) 10? If it is, we print out the first message.
Is age greater than ( > ) 10? If it is, we print out the second message.

Perfect! Actually, unfortunately not. There are two things wrong with this code snippet.

Problem 1

We're checking if age is less than ( < ) and greater than ( > ) 10, but what if age is 10? It doesn't call either Print statements.

python conditionals.py

To fix this we first need to decide what statement we should print if the persons age is 10. I think 10 is still pretty young so let's print out the first statement. If you disagree, see if you can make it print out the second statement.

We then need to change our "less than" ( < ) condition, to be "less than or equal to" ( <= ).

#!/bin/env python

# Start of our code

age = 31

if age <= 10:
    print("I am {0} years young".format(age))

if age > 10:
    print("I am {0} years old".format(age))

# End of our code

Now if we run our programme with an age of 10, we get our message printed!

$ python conditionals.py
I am 10 years young

Problem 2

Regardless of what value is given to age, we're always checking two things:

Is the value less than or equal to 10?
Is the value greater than 10?

In this situation age can only match one of these expressions, so we're asking the computer to do extra work. This might not seem like a big deal now, but if we grew our application to have thousands or millions of unnecessary checks we'd see a big performance hit.

Instead of two if statements, we can use an if/else statement. The syntax for declaring an if/else statement is very simple:

if expression:
    # Run this code if expression evaluates to true
else:
    # Run this code if expression evaluates to false

The age variable is only ever going to be less than or equal to 10, or greater than 10, as we've previously stated. So we only need to check for one of those conditions, everything else fits in the else statement:

#!/bin/env python

# Start of our code

age = 31

if age <= 10:
    print("I am {0} years young".format(age))
else:
    print("I am {0} years old".format(age))

# End of our code

Take some time to have a play with the code - we'll still be here when you're ready to continue.

Ready?

Excellent. Let's take this to the next level and make our programme more "age aware". This time we're going to check for four possible outcomes:

If the age variable is less than 13, we will print "I am considered a child"
If the age variable is between 13 and 19, we will print "I am considered a teenager"
If the age variable is between 20 and 67, we will print 'I am considered an adult'.
If the age variable is 68 or older, we will print "I am considered a senior".

We already know having four separate if statements isn't a good idea, but an if/else statement can only handle two outcomes so what are we to do now? We can use the if/elif/else statement!

The syntax for declaring an if/elif/else statement is very simple:

if expression:
    # Run this code if expression evaluates to true
elif anotherExpression:
    # Run this code if anotherExpression evaluates to true
elif yetAnotherExpression:
    # Run this code if yetAnotherExpression evaluates to true
else:
    # Run this code if none of the above expressions have evaluated to true

The difference between else and elif is the latter allows us to specify another expression.

If the first expression hasn't evaluated to true, then the next expression is checked. This continues until an expression does evaluate to true, an else statement or the conditional statement ends.

If an expression does evaluate to true, it skips the rest of the elif and else statements.

We can easily use this logic in our programme, without needing to learn many new concepts:

package main

# Start of our code

age = 70

if age < 13:
    print("I am considered a child")
elif age >= 13 and age < 20:
    print("I am considered a teenager")
elif age >= 20 and age < 68:
    print("I am considered an adult")
else:
    print("I am considered a senior")

# End of our code

Let's run through these expressions, one by one:

if age < 13 - we check if age is less than ( < ) 13. If it is, we print out the "child" statement and don't have to perform any more checks.
elif age >= 13 and age < 20 - we check if age is greater than or equal to ( >= ) 13 and if age is less than 20. This gives us a range of 13 - 19. If the expression evaluates to true we print out the "teenager" statement and don't have to perform any more checks.
elif age >= 20 and age < 68 - we check if age is greater than or equal to ( >= ) 20 and if age is less than 68. This gives us a range of 20 - 67. If the expression evaluates to true we print out the "adult" statement, and don't have to perform any more checks.
else - if age is any other value (i.e. 68 or above) we print out the "senior" statement.

Now let's add back the code from the beginning of this article:

#!/bin/env python

# Start of our code

name = "Jordan"
age = 31
hobbies = ["hiking", "playing music", "example1", "example2"]

print("Hello World. My name is {0}.".format(name))

if age < 13:
    print("I am considered a child")
elif age >= 13 and age < 20:
    print("I am considered a teenager")
elif age >= 20 and age < 68:
    print("I am considered an adult")
else:
    print("I am considered a senior")

print("I have {} hobbies, and they are: ".format(len(hobbies)))

i = 0
while i < len(hobbies):
    print(hobbies[i])
    i+=1

# End of our code

That's it - we've now added an if/elif/else statement to our Python programme!

Before you go, see if you can complete the following challenge:

It is possible to optimise the last if/elif/else statement further, see if you can figure out how. Hint: we're still asking the computer to do more work than is necessary.

If you need another hint, or want to show us your solution, get in touch with us on our Contact Us page.

CodeTips strives to help beginners, with zero or very little experience, learn to code.

We do cross-post to other sites to reach a wider audience, but why not subscribe to our newsletter and get the newest articles straight to your mailbox?

The original source for this content is CodeTips. The original content is kept up-to-date, but other sources may not be the latest version.

Lists and Loops in Python

Jordan Gregory — Thu, 13 Jun 2019 15:51:55 +0000

Before reading this article, you should have read about arrays, types and loops.

As you will learn, Arrays are typically immutable and can hold information (usually of one particular type) and store them along with an index value.

Python adds another layer on top of the typical array type, which makes them easier to work with, by allowing information of any type as well as making them mutable. This construct is called a List.

In "writing your first programme in Python", we wrote a programme that outputted your name, age and profession. In this article, we’re going to extend that programme and have it print out all of your hobbies as well.

Note: You were also asked to complete three challenges at the end of "writing your first programme in Python". We’re going to assume you completed them. If you haven’t, this article shows you the solutions so make sure you at least try them.

After completing all three challenges, you should have ended up with something similar to this:

#!/bin/env python

#Start of our code

name = "Jordan"
age = 31
profession = "Developer"
favoriteAnimal = "Penguin"

print("Welcome to my first Python programme. My name is {0}. I am {1} years old. I work as a {2}. My favourite animal is a {3}".format(
    name,
    age,
    profession,
    favoriteAnimal,
    )
)

# End of our code

We now want to add another piece of information; what our hobbies are.

I have three main hobbies, so the obvious thing to do is to create three new variables and print them to the terminal as we did before:

#!/bin/env python

# Start of our code

name = "Jordan"
age = 31
profession = "Developer"
favoriteAnimal = "Penguin"

hobby1 := "Coding"
hobby2 := "Bass Guitar"
hobby3 := "Hiking"

print("Welcome to my first Python programme. My name is {0}. I am {1} years old. I work as a {2}. My favourite animal is a {3}".format(
    name,
    age,
    profession,
    favoriteAnimal,
    )
)

print("My hobbies are: {0}, {1}, {2}".format(hobby1, hobby2, hobby3))

# End of our code

We've now added a second print statement which prints our hobbies to the screen. Pretty neat huh? Well, actually, no.

It may look acceptable to do this for three hobbies, but what if you had ten hobbies?

#!/bin/env python

# Start of our code

name = "Jordan"
age = 31
profession = "Developer"
favoriteAnimal = "Penguin"

hobby1 = "example1"
hobby2 = "example2"
hobby3 = "example3"
hobby4 = "example4"
hobby5 = "example5"
hobby6 = "example6"
hobby7 = "example7"
hobby8 = "example8"
hobby9 = "example9"
hobby10 = "example10"

print("Welcome to my first Python programme. My name is {0}. I am {1} years old. I work as a {2}. My favourite animal is a {3}".format(
    name,
    age,
    profession,
    favoriteAnimal,
    )
)

print("My hobbies are: {0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}, {8}, {9}".format(
    hobby1,
    hobby2,
    hobby3,
    hobby4,
    hobby5,
    hobby6,
    hobby7,
    hobby8,
    hobby9,
    hobby10
    )
)

# End of our code

It's starting to look a bit messy, isn't it? What if we had 100 hobbies?

There must be a better way! Thankfully, there is. Lists!

In Python, lists can contain any type and are declared by simply using variable = [] to create an empty list.

stringList = []
intList = []
boolList = []
multiTypeList = []

We can immediately add items into our list by simply adding items within the list declaration.

stringList = ["string1", "string2"]
intList = [1, 2]
boolList = [True, False]
multiTypeList = ["string", 1, 3.14, True]

Before we go any further, try to complete the following challenges:

Take the ten hobby variables and convert them into one hobbies array.
Change the print statement to print out the new list, instead of the ten variables.

Done? Excellent. You should have ended up with something similar to this:

#!/bin/env python

# Start of our code
name = "Jordan"
age = 31
profession = "Developer"
favoriteAnimal = "Penguin"

hobbies = [
    "example1",
    "example2",
    "example3",
    "example4",
    "example5",
    "example6",
    "example7",
    "example8",
    "example9",
    "example10",
]

print("Welcome to my first Python programme. My name is {0}. I am {1} years old. I work as a {2}. My Favorite animal is a {3}.".format(
    name,
    age,
    profession,
    favoriteAnimal
    )
)

print("My hobbies are: {0}".format(hobbies))
# End of our code

Running your application now ( python main.py ) should give you the following output:

Welcome to my first Go programme. My name is Jordan. I am 31 years old. I work as a Developer. My favorite animal is a Penguin.
My hobbies are: [example1 example2 example3 example4 example5 example6 example7 example8 example9 example10]

Now we have our hobbies list and we can add and remove items easily, without having to create new variables or amend the print statement.

So our code is now looking nice and neat, but I'm still not very keen on what we're outputting to the terminal; we've got those ugly square brackets ( [] ) and what happens if we add a new hobby, which is made up of multiple words?

hobbies = ["example1", "mountain biking", "example2", "example3"]

Which would print:

My hobbies are: [example1 mountain biking example2 example3]

Is it "mountain biking" or "mountain" and "biking"?

So do we have to go back to separate variables? Thankfully not! We can use a loop!

Before we change our programme, let's make a simple example of a loop to understand the concept.

If we wanted to print the numbers 1-10 we could write 10 different print statements, which is very manual, or we could write a loop to do it for us. In the following example:

The init statement. Executed before the first iteration of the loop, we define a new variable ( i ) and assign the value 1 to it ( i = 1 ).
The condition expression. Executed before each iteration of the loop, it checks if the expression ( i <= 10 - is i less than or equal to 10? ) is true. If it is, it runs another iteration.
We then print the value of i during each iteration and then simply increment the value of i by 1 (e.g. if the value of i is 3, running i+=1 would increment it and it would now be 4)

i = 1
while i <= 10:
    print(i)
    i+=1

We can now use this new technique to print our hobbies. In the following example:

We have added a new print statement that prints the number of hobbies we have. The len method simply returns the length of the list; in this example 4.
We define our init statement and set the value of i to 0. We have set it to 0 instead of 1 because Python list indexes start at 0.
We define our conditional expression and set the condition to i < len(hobbies) ( is i less than the length of hobbies ). We're using "less than" ( < ) instead of "less than or equal" ( <= ) because Python list indexes start at 0.
We define our post statement and increment the count of i as we did in our previous example.
We then print each element of hobbies.

#!/bin/env python

# Start of our code

name = "Jordan"
age = 31
profession = "Developer"
favoriteAnimal = "Penguin"

hobbies = ["example1", "mountain biking", "example2", "example3"]

print("Welcome to my first Python programme. My name is {0}. I am {1} years old. I work as a {2}. My favourite animal is a {3}".format(
    name,
    age,
    profession,
    favoriteAnimal,
    )
)

print("I have {0} hobbies, and they are: ".format(len(hobbies)))

i = 0
while i < len(hobbies):
    print(hobbies[i])
    i=+1

# End of our code

The following is an illustration of the link between our list index and values:

|     0    |        1        |     2    |    3     |
*----------*-----------------*----------*----------*
| example1 | mountain biking | example2 | example3 |

We appreciate this was a lot of information to take in, so feel free to reach out to us if anything isn't clear.

CodeTips strives to help beginners, with zero or very little experience, learn to code.

We do cross-post to other sites to reach a wider audience, but why not subscribe to our newsletter and get the newest articles straight to your mailbox?

The original source for this content is CodeTips. The original content is kept up-to-date, but other sources may not be the latest version.

Writing Your First Python Programme

Jordan Gregory — Sat, 01 Jun 2019 11:31:03 +0000

By the end of this article, you will have written a Python programme that outputs a sentence based on a number of variables.

If you've made it to this article you should have read the Python Introduction, and be familiar with variables and data-types.

As we stated in the Python Introduction, Python is an interpreted language so its types are inferred.

There is only one way to declare a variable in Python.

In the following example:

x is assigned the value "Hello World" and has an inferred type of String.
y is assigned the value True and has an inferred type of Bool.
a is assigned the value 1 and has an inferred type of Int.
b is assigned the value 3.14159 and has an inferred type of Float.

x = "Hello World"
y = True
a = 1
b = 3.14159

As Python is a dynamically typed language, there is no way to declare a variable as a specific data-type.

It is, however, possible to perform logic based on the type, using the type() function.

The following if statement checks to see if the type of y is bool and, if True, will run the <do something> action. Otherwise, it will skip the indented section of code.

y = True

if type(y) is bool:
    <do something>

It is also possible to perform "type casting" in Python. In the following example:

The variable x is assigned the value 1 and has an inferred type of Int.
The value of x (1) is "casted" to a float and assigned to the variable y. The type of y is therefore float.

x = 1
y = float(x)

print(type(x)) // => outputs int 
print(type(y)) // => outputs float

Your first Python programme

It's finally time to write your first Python programme. You can write this anywhere on your machine, however, it is best practice to keep your development code in a specific place and well organized.

Within your home directory ($HOME on Linux and Mac, %userprofile% on Windows) create a new directory called python (e.g. the full Linux path would be /home/codetips/python ). Navigate to this directory and create another directory called firstApplication (e.g. the full Linux path would be /home/codetips/python/firstApplication) and open it in your code editor of choice.

We're going to leave out most of the specifics of Python best practices, so you're not overwhelmed with too much information, but everything will be explained in future articles.

In your new firstApplication directory, create a new file called main.py, add the below code into it, and save the file.

#!/bin/env python

# Start of our code

print("Welcome to my first Python programme!")

# End of our code

Now, open a terminal, navigate to your firstApplication folder, and run the following command:

python main.py

Your output should look very similar to the following:

$ [user@linux]: python main.py
Welcome to my first Python programme!

As you can see, the print function outputs text to the terminal. Unfortunately, as a first programme goes, this is pretty boring. Let's make this more personal with Variables!

Replace the contents of main.py with the following code:

#!/bin/env python

# Start of our code

name = "Jordan"
age = 31
profession = "Developer"

print("""Welcome to my first Python programme!\n\
My name is {0}\n\
I am {1} years old\n\
I work as a {2}""".format(name, age, profession))

# End of our code

This time we're outputting four different sentences. One from the previous example and the other three are using the same print function, but notice the .format() function at the end of the string definition.

The """ statement in Python means that we are going to create a multi-line string.

The format function allows the programmer to pass variables through to the string. In the above example:

the name variable (in position 0, referenced in the string as {0})
the age variable (in position 1, referenced in the string as {1})
the profession variable (in position 2, referenced in the string as {2}).

Knowing the position of the variables, also known as the index, allows the programmer to repeat the same thing any number of times by simply referencing the position within the string. We will cover this in a future article.

We can define strings in the following ways:

string1 = "This is a string using double-qoutes"
string2 = 'This is a string using single-quotes"
string3 = `This is a string using back-ticks`
string4 = """This is a multi-line string \
using double-quotes"""
string5 = '''This is a multi-line string \
using single-quotes'''

It is best practice to use double-quotes by default, but all of the above are valid python syntax.

Now see if you can complete the following challenges:

Change the variables so the programme prints out your name, age and profession.
Change the programme to output everything on one line, instead of four lines.
Add a new variable, favoriteAnimal , and incorporate that into your outputted sentence.

Tweet us at @RealCodeTips and show us your solutions. If you get stuck along the way, reach out and we'll do our best to help.

We've also set-up a Slack community to help people in more real-time. You can join us here.