A few months ago I wrote an Introduction to Kubernetes. In that article I created a service to achive communication between containers. This service acts as a load balancer that redirects requests to pods that are part of a deployment. We communicate with this load balancer via an IP that is assigned to it.

A service that needs to communicate with another service can query Kubernetes to discover the IP address for the load balancer and use that IP address for communication. This is does the job, but there are some things that are not possible with this configuration that we get from Istio.

Database migrations

Database migrations (or Schema migrations) are the technique used to keep track of changes in the schema of a database. There are many tools for handling database migrations for different languages and frameworks; They typically provide these features:

• Represent schema changes in code (so they can be added to source control)
• Keep track of the last migration applied
• Apply only the necessary migrations

Having all the schema changes in code also makes it easy to ensure all environments are running exactly the same DB schema.

In this article we are going to learn what is concurrency in computer systems. To understand it better, we’ll see what are the problems that occur when there is concurrency and what are some ways to prevent those problems.

What is concurrency?

Concurrency referes to the ability of a computer system to do different things at the same time.

We see concurrency in action in our computers when there are multiple programs executing at the same time. We can be playing some music in our computer and at the same time browsing the internet, for example.

At a high level, there are two ways of doing concurrency:

• Time slicing
• Parallel execution

For hardware that supports parallel execution, time slicing can be done on top of it.

Jackson is a set of tools for working with JSON data in Java. Jackson contains a wealth of features, so don’t expect this article to cover them all.

Parsing arbitrary JSON strings

To get started with Jackson, let’s look at how we can parse an arbitrary JSON string:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
package example;

import com.fasterxml.jackson.databind.JsonNode;
import com.fasterxml.jackson.databind.ObjectMapper;

public class Exampler {
  public static void main(String args[]) throws Exception {
    String json = "{\"hello\":\"world\"}";
    JsonNode root = new ObjectMapper().readTree(json);
    if (root.has("hello")) {
      System.out.println("Value of hello is: " + root.get("hello"));
    }
  }
}

The example above prints:

1
Value of hello is: "world"

What are immutables?

An immutable is a type that can’t be modified after it has been created.

The most common way to define an object in Java is by instantiating a class; Once the class is instantiated, we can modify its properties directly or by calling methods that modify them. Let’s look at an example of a mutable object:

1
2
3
public class MyClass {
  public int value;
}

This is a very simple type that we can instantiate and modify:

1
2
MyClass obj = new MyClass();
obj.value = 4;

Immutables differ from these types in that once instantiated, they can’t be modified (Properties can’t be changed and there are no methods to modify them).

In a previous article, I explained a little about how Language Server Protocol clients work. This time I’m going to explain how we can take advantage of this protocol in Vim.

Installing vim-lsp

Configuring vim-lsp is a little more complicated than installing other plugins, because it requires many pieces to be put together in order for it to work correctly.

Let’s start by installing vim-lsp:

1
2
cd ~/.vim/pack/my-plugins/start
git clone https://github.com/prabirshrestha/vim-lsp.git

There are a lot of IDEs out there that offer features like auto complete, go to definition, etc. Traditionally each IDE has logic for parsing and understanding code in a project, and plugs this understanding into its UI. How good the IDE’s understanding of a particular language together with their user experience are their most powerful selling points.

In the past, different IDEs that supported the same language had their own proprietary code that gave them insights into a programming language.

LSP is an open source standard created by Microsoft. It defines a protocol for a program that understands a programming language to talk to another program (typically an IDE) that wants to take advantage of these features. This protocol allows anybody to build a server that understands a language and make it available to the world. Programmers can leverage these servers to provide powerful tools or IDEs.

The server

The server takes care of understanding the structure of a program and implementing an API to share this understanding.

There are various server implementations out there and they vary widely in the number of features they support.

Helm is a package manager for Charts.

You might already be familiar with package managers like the ones used for Linux distributions (apt, yum, etc.). In Linux, a package manager takes care of installing, updating, configuring and removing packages from a machine. Helm does something similar, but with Kubernetes applications.

Charts are a set of files that describe a Kubernetes application. These files must be laid out in a folder structure that follows a convention that looks like this:

1
2
3
4
5
.
├── Chart.yaml
├── templates
│   └── application.yaml
└── values.yaml

The Chart.yaml contains some information about the Chart. It looks something like this:

I wrote an article not long ago showing how to get started with Kubernetes.

In that article we started pods by passing options as command line arguments to kubectl create. This works for demostration purposes, but it’s not usually the way Kubernetes deployments are managed.

Having files that describe the characteristics of our deployment allows us to add these files to source control, which gives us the benefit of keeping track of changes as well as making it easy to change things like the number of pods without having to remember all other details.

For this article, I’ll assume you already have a Kubernetes cluster and a configured kubectl client. If you don’t have these ready, you might want to take a look at my introduction to Kubernetes to get those set up.

GraphQL advertises itself as a query language for APIs. To understand what this means, let’s compare it with REST.

In REST, we usually have endpoints that give us information about a resource, for example: GET /user/1 could return something like:

1
2
3
4
5
{
  "id": 1,
  "name": "Jose",
  "phone": "999-888-7777"
}

We have multiple endpoints we can use to get different information about different resources. If we need an endpoint that contains information from different resources, we sometimes create endpoints for specific purposes: GET /user/1?includeParents=true. Which could return something like this:

1
2
3
4
5
6
7
8
9
{
  "id": 1,
  "name": "Jose",
  "phone": "999-888-7777"
  "parents": {
    "mom": "Maria",
    "dad": "Carlos"
  }
}