DEV Community: Daniel

Pragmatic Programming Understanding

Daniel — Fri, 18 Sep 2020 10:28:33 +0000

I’m taking a break from my usual articles to write something for beginners starting to program: Brief, simple explanations of various concepts and programming terms. These came from explaining some concepts to my friend who was completing a curriculum in computer science.

Features vs Design vs Implementation

Features: What the program can do
Implementation: How the program does it
Design: Planning features and implementations.

Programming paradigms

In programming we have logic (how), and data (what). Do note that these paradigms can be mixed.

Functional paradigm: It’s when you pass in data into logic, and have a new data as a result. E.g. Clojure.

Object Oriented paradigm: It’s when you place logic in data, and data uses signals to communicate between each other on what logic to trigger. E.g. Ruby

There are also paradigms that focus on what to control, the logical command or the logical result.

Imperative paradigm: You make logical commands that describe logic to change your data. E.g. C.

Declarative paradigm: You explain the final data result to program and it solves the commands to do it for you.

Types

Untyped languages are like maths. You focus on getting the algorithms right. Here we use schemas to restrict the range of data that can be correct. E.g. square root, but following schema of positive integers. This includes Python and Ruby.

Typed languages are like physics, you focus on getting the results right. Here types perform basic checking on intermixed values. For more complex checking to the level of schemas you need dependent types. This includes C and Haskell.

Mutability

Mutable means “can be changed. Immutability, the opposite, can prevent more human errors by making sure data can only be copied, but not changed. However, the trade off is that your program takes more space and is slower.

On the other hand, programs using mutable data structures can be very fast and use less memory but programmers will make more mistakes.

Project management

Scope: How much will you complete

Resources: How much can you use (including human resources)

Time: How long will you take

This brings us to the development styles:

Waterfall: Fixed scope, but flexible resources and time.

Agile: Fixed resources and time but flexible scope.

Spectrum of development

All of these require algorithm and data structure knowledge.

Front-end: User-facing application where you have less control over the environment. Can be web based, like HTML/JS/CSS, or native, like C++ or Java.

Back-end: Non-user-facing application where you have more control over the environment. Any language can be a backend language.

Infrastructure and Operations: Applications that host the front-end or back-end applications, and how to transfer the front-end application to the user etc

Data engineering: Applications that gather and clean data for use in other applications like AI applications.

Awesome Unity3D: State Machines — Effective State Management

Daniel — Thu, 27 Aug 2020 15:08:50 +0000

This article assumes you know what are Finite State Machines (FSM). If not, I would recommend reading this article that shows common pitfalls when writing code handling character state and why we use FSMs. If you prefer a "TL;DR", the gist is that without FSMs you need to use plenty of flags in your program, which can lead to many nested "if-else" statements everywhere, leading to a terrifying debugging experience. You do not want to waste your time in this self-made hell.

// Example of self-made hell
private void handleInput()
{
  if (Input.GetKeyDown(KeyCode.Space))
  {
    if (!isJumping && !isDucking)
    {
      // Jump...
    }
  }
  else if (Input.GetKeyDown(KeyCode.D))
  {
    if (!isJumping)
    {
      isDucking = true;
      setGraphics(IMAGE_DUCK);
    }
  }
  else if (Input.GetKeyUp(KeyCode.D))
  {
    if (isDucking)
    {
      isDucking = false;
      setGraphics(IMAGE_STAND);
    }
  }
}

FSMs are the kind of pattern that most people I know have a love/hate relationship with. Love it for it's ability to encapsulate dynamic application state, hate it for additional complexity. Personally I did not enjoy using code-only FSMs since juggling state transitions can be quite a handful especially in games with complex interactions between units but including a GUI solution for FSM like Playmaker can be pretty heavy.

On that note, what if there is a lightweight FSM system that we can use (or hijack) within Unity?

Using the `AnimationController` as FSM

Unity already contains a state machine for animations that we can use, with some modification.

Setup

Create an empty GameObject in the scene with an Animator attached.
Create a new AnimatorController asset somewhere in your project folder. Attach this to the Animator you've created.
Open Window→Animator→Parameters and create a trigger called "Next".

Customization

Create a class that inherits StateMachineBehaviour so we can create custom states, provide a cleaner interface for the state machine, and enable debugging. We can call our custom class LogicalStateMachine . StateMachineBehaviour already provides methods such as OnStateEnter , OnStateUpdate , OnStateExit , which we can use to provide interfaces such as these.

protected abstract void OnLogicalStateEnter(GameObject gameObject);

protected abstract void OnLogicalStateUpdate(GameObject gameObject);

protected abstract void OnLogicalStateExit(GameObject gameObject);

protected abstract void ResetState(GameObject gameObject);

public override void OnStateEnter(Animator animator, AnimatorStateInfo stateInfo, int layerIndex)
{
    ResetState(ActiveAnimator.gameObject);
    OnLogicalStateEnter(ActiveAnimator.gameObject);
}

public override void OnStateUpdate(Animator animator, AnimatorStateInfo stateInfo, int layerIndex)
{
    OnLogicalStateUpdate(ActiveAnimator.gameObject);
}

public override void OnStateExit(Animator animator, AnimatorStateInfo stateInfo, int layerIndex)
{
    OnLogicalStateExit(ActiveAnimator.gameObject);
}

To make it easier to debug, we'll use the trigger we've created before to create a Continue method that can force the next state to occur.

protected Animator ActiveAnimator;

protected void Continue()
{
    if (!ActiveAnimator) return;
    ActiveAnimator.SetTrigger(Animator.StringToHash(Next));
}

public override void OnStateEnter(Animator animator, AnimatorStateInfo stateInfo, int layerIndex)
{
    ActiveAnimator = animator;
    ResetState(ActiveAnimator.gameObject);
    ActiveAnimator.ResetTrigger(Animator.StringToHash(Next));

    OnLogicalStateEnter(ActiveAnimator.gameObject);
}

We can make this even better by creating an Inspector Button for it in the editor.

Personally I just use the Odin Inspector to create one but if you'd prefer a native solution there's one here.

Voila! A simple state machine you can use in your project. You can find the code here as well: https://gitlab.com/glassblade/unityfsm

Effective State Management in Games

This advice applies to most complex applications, but game is a good example. Games typically contain two types of state : persistent state and dynamic state. For example, in the game, "Enter the Gungeon", the persistent state would contain the unlocked pool of guns, while the dynamic state would contain the gun picked up by the player.

FSMs contain two basic components, state and transitions and I would recommend the following to make it easier to debug your state in FSM:

If you need to use a flag, don't. Use a state instead.
Spending some time before you code to identify what would be persistent state and dynamic state in your game relative to the FSM. Dynamic state should be reset each time you enter a state while persistent state will not.
Make an immutable copy of your persistent state on entering a state, only set persistent state on exiting a state. You can optimize this later on, but it makes it alot easier for debugging points of error.

Pragmatic K8s Understanding

Daniel — Sun, 16 Aug 2020 03:19:50 +0000

This article simplifies k8s as a magical tool to simplify deployment. By the end of the article you should have enough basic knowledge to discuss k8s with others, and to use it as well.

This article is also part of a Machine Learning Ops (MLOps) series.

But before we start, an image describing the experience of learning k8s right now in spite of the resources widely available in the web, which prompted me to write an article that follows the KISS principle.

Why kubernetes (k8s)?

Remember when during development you only have one machine to deploy with, and you're asked to scale your application without much budget? Naturally. you set up a load balancer and create two instances with different ports to handle the extra load. Later on, you're given more computers, and you do the same thing on those computers as well. This becomes a tedious task as more and more computers are required, and it's still not an easy task even with tools like Ansible.

What k8s does is automating away all of this, so most of the times after you set up k8s, all you need to do is register your new computer with labels of apps that are allowed on it, and k8s takes care of the rest. On a single computer, it handles load balancing and ports automatically for your applications when scaling up, all without bundles of bash/Ansible scripts, which brings us to the next great feature of k8s.

Writing k8s configuration files are pretty much like writing SQL code whereas tools like Ansible are similar to writing Python code. You just describe what you want, and k8s finds the best way to do it. Since the config are just YAML files, you can keep it with your repository as well. Updating the deployment is as easy as updating the configuration files and applying it to the cluster.

This means you can bring your application to multiple different clusters in different environment and expect more or less similar behaviour, which makes it very attractive for a lot of companies.

However, k8s requires containers to do its magic, so before I proceed to provide a simple guide to k8s, I have to explain containers.

Why containers?

Nuff' said.

The Actual Guide

K8s terms translator

Node: Computer that is not a container.
Cluster: Group of nodes.
Control plane: Node that controls other nodes.
Persistent Volumes: A description of what storage is available.
Persistent Volume Claims: A description of what storage you need.
Pods: A description for how containers are run and how they use persistent volumes.
Deployment: A group of pods.
Service: A description for how deployments communicate through the internet.

Using k8s

Minikube has, by far, the easiest way to start with k8s on a single computer.
Otherwise, the second easiest is to get one from Azure, AWS or GKE.
Finally it would be setting up a cluster manually using kops, kubeadm or kubespray.

K8s essentials for developers

There's really four basic concepts you need to know before using k8s: containers, persistent storage, deployments, services.

We'll use Nginx for this example.

Containers (Docker)

You'll have to be able to create a docker image. I wrote an article on how to reduce docker container size that would be useful as well, which also contains a sample docker file used to build the image.

Do note that containers can be restarted or destroyed often, for example when your container crashes k8s will automatically restart it.

Persistent Storage

The easiest to start with local data, but there are many other types as well. This type of storage will not be destroyed when the container is destroyed.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nginx-pv
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  hostPath:
    path: "/var/lib/path-in-node"

A persistent volume only describe what storage is available, it does not actually allocate the storage or block it off.

You can use access modes to describe the behaviour of pods when dealing with this storage (i.e. mounting). This is irrespective of the actual file system.

There are three modes:

ReadWriteOnce : the volume can be mounted as read-write by a single node
ReadOnlyMany : the volume can be mounted read-only by many nodes
ReadWriteMany : the volume can be mounted as read-write by many nodes

Deployments

This describes an actual "application". It uses containers and persistent storage.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      volumes:
      - name: nginx-vol
        persistentVolumeClaim:
          claimName: nginx-pvc
      containers:
      - name: nginx
        image: nginx:latest
        volumeMounts:
        - name: nginx-vol
          mountPath: /var/lib/path-in-nginx-container
        ports:
        - containerPort: 80

As noted, you can start with multiple replicas of your application. The deployment will create multiple copies of your pods using the template.

Services

You can expose your app to the internet using services. You can choose a load balancer between multiple nodes or just use a port on a node.

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      nodePort: 30080
  type: NodePort

The service automatically load balances between pods created by a deployment.

The service selects deployment based on the app label specified in the deployment (i.e. the selector).

Services, by default are only allowed to use ports 30000-32767. You can use another reverse proxy or ingress to do port forwarding, common options are Nginx and HAProxy.

Conclusion

And that's basically most of what you need to actually be productive in k8s.