DEV Community: Henryk Konsek

Quickstart: Java command line tool

Henryk Konsek — Mon, 21 Mar 2022 15:50:10 +0000

I keep forgetting how to create new projects from scratch, so I like to keep my personal set of quickstarts on GitHub. Quickstart for Java command line tool is a simple implementation of Grep command implemented as Java fat jar.

Project is pretty feature-complete right now, however here is the short list of the things I'd like to improve:

add support for command line parsing
explicitly manage version numbers of all Maven plugins used by the project (compiler plugin, clean plugin, site plugin, etc)

Using context in Go - timeout

Henryk Konsek — Thu, 18 Feb 2021 11:07:19 +0000

Go comes with a powerful concurrency control tool called context. Context is primarily used when client should be able to keep a control over an execution of the library code.

Timeout control with context

One of the most common example of such pattern is controlling timeout of the function we are calling from our code. This is primarily useful when dealing with IO and network calls which can be blocking and unreliable by their nature.

Let's consider this example:

func callSlowApi() (string, error) {
  // this is slow API call
}

response, err := callSlowApi()

We call some slow REST API here. Right now we cannot control the execution of the callSlowApi() function. In particular even if we know that API is flaky and response can take ages, we cannot control for how long our client code is ready to wait before we want to cancel our attempt to call the API.

Good library design in Go should include context.Context as a first parameter in the function to allow client to control the timeout:

func callSlowApi(ctx context.Context) (string, error) {
  // this is slow API call, but context aware
}

// If API call takes longer than 5 seconds, return context timeout error
ctx, cancel := context.WithTimeout(context.Background(), 5 * time.Second) 
response, err := callSlowApi(ctx)
defer cancel()

Now execution of callSlowApi function can be controlled from the client code! In the example above our client code specified that we are ready to wait 5 seconds tops before we give up on the API call.

Keep in mind that we call defer cancel() in our example. It is used to send a signal to the callSlowApi function that we are not interested in this particular call anymore and it should be canceled. It is a good practice to call cancel function after we used a context in a call to avoid context leaks.

More examples

In this example you can see context timeout in action.

We define a "mock" task function emulating long running process that could time out:

func runTask(ctx context.Context, taskTime time.Duration) {
    select {
    case <-time.After(taskTime):
        fmt.Println("Finished long running task.")
    case <-ctx.Done():
        fmt.Println("Timed out context before task is finished.")
    }
}

As you can see, we're passing context as the first argument to it. Thanks to this approach we can control the timeout behavior on the level of the client code calling the function. In the example below we are calling our mock task for 3 seconds and with 1 second context timeout. As a result we should see function being timed out and canceled after one second:

func timeoutContextBeforeTaskIsFinished() {
    fmt.Println("This example should time out task execution:")
    ctx, cancel := context.WithTimeout(context.Background(), time.Second)
    defer cancel() // Always cancel() to avoid context leak

    runTask(ctx, 3*time.Second)
}

...

This example should time out task execution:
Timed out context before task is finished.

In the example below we are calling our mock task for 1 second and with 3 second context timeout. As a result we should see function being completed without a timeout:

func finishTaskBeforeContextTimeout() {
    fmt.Println("This example should finish task execution before context timeout:")
    ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
    defer cancel() // Always cancel() to avoid context leak

    runTask(ctx, time.Second)
}

...

This example should finish task execution before context timeout:
Finished long running task.

Summary

Go context is a powerful package that allows you to design library API with a powerful concurrency and reliability controls in place. It is highly recommended to include context.Context as a first parameter to the CPU/IO/network intensive functions you author. That would enable clients using your code to control how it behaves in case of reliability issues.

Context timeout is a great way to control how your client code interacts with an unreliable IO and networks.

Installing Windows 10 Terminal

Henryk Konsek — Fri, 12 Feb 2021 16:19:43 +0000

If you are Linux or MacOS user, then for sure you are used to feature-rich terminals. And probably you cringe a little bit inside every time you have to use Windows command prompt. I feel you, but maybe you don't know yet that Windows 10 offers official (and free) next generation terminal for Windows. Terminal for Windows borrows all the best features from Linux/Unix terminals.

You can try it really easily! Terminal is available in Windows Store, just find the application in the Store:

After installation you should see it as a new application in your run menu:

Probably the most important Terminal's feature is a support for multiple tabs. You can open new tab by clicking plus sign at the top of the Terminal window. Or even better, you can click the expand button to choose the terminal type you would like to open in new tab (PowerShell, Command Prompt, Linux distribution like Ubuntu, etc).

Microsoft did really great job when it comes to Terminal and they keep adding new awesome stuff with every release. Go give it a try!

Go interview task example - REST API

Henryk Konsek — Fri, 12 Feb 2021 10:16:34 +0000

Here is a sample application specification I use as a base for Go interviews. It's pretty simple to write and I use it as a foundation for further conversations with a candidate.

Task specification

create simple Go application exposing REST API
no specific web framework is required to be used
when /api/weather endpoint is called, fetch weather alerts data for the state of New York using this API
read weather alerts headlines from the api.weather.gov API response (JsonPath $.features[*].headline)
return alerts headlines in a similar response:

{"alerts": ["Wind Chill Advisory issued February 12 at 4:02AM EST until February 12 at 10:00AM EST by NWS Binghamton NY"]}

Extra points

It is up to you how simple or complex the application will be. However you can treat this application as an occasion to brag about the things you know. For example:

Do you like unit testing? Go for it and show us your favorite testing libraries in action!
Docker fan? Dockerize the application then and include your Dockerfile!
Any other cool libraries you know and wanna show us? Let us learn from you!

What is the right AWS Kubernetes distribution for you?

Henryk Konsek — Wed, 10 Feb 2021 15:34:38 +0000

Considering cloud market share held by Amazon, it is very likely that the cloud of your choice is AWS. If that is the case and you have already decided that Kubernetes is the way to schedule your workloads, you are probably asking yourself what cluster hosting approach should you choose. While choosing AWS EKS - the AWS managed Kubernetes offering could be the first thing that comes to your mind - it is worth to know the alternatives and make an educated decision.

The most popular Kubernetes cluster hosting methods for AWS

There are a myriad of different ways to run your Kubernetes cluster in AWS. Let's discuss some of the most popular ones.

Currently the most popular cluster hosting methods for AWS are as follows:

Kubernetes The Hard Way
Kubeadm
KubeSpray
Kops
EKS

Kubernetes The Hard Way

Hosting Kubernetes cluster "the hard way" means that the cluster has been bootstrapped by following steps from the famous Kubernetes The Hard Way guide authored by Kelsey Hightower. Kubernetes The Hard Way describes how to manually configure and install each Kubernetes component (like Kubernetes scheduler, Kubernetes API server, Containerd, CoreDNS, CNI and Etcd).

In practice The Hard Way approach requires you to start some EC2 Linux virtual machines (that will serve as your master and worker nodes) and installing each Kubernetes component (Etcd, Containerd, Kubernetes scheduler and so forth) into these Linux servers.

While Kubernetes The Hard Way is a great way learn a ton about Kubernetes internals, it is probably not the best choice for your production Kubernetes cluster. The main reason for that is because with The Hard Way approach all the cluster administration burden is on you and your organization. Creating and configuring all the infrastructure required by Kubernetes The Hard Way cluster is an extremely expensive activity, and I don't recommend following this approach if you don't plan to hire devOps engineers / SREs (Site Reliability Engineers) dedicated for this task.

The good case for The Hard Way approach would be if you would like to run customized version of Kubernetes cluster where you have full control over an every component of your installation. And if you are not afraid to cover the cost associated with this approach.

Kubeadm

Kubeadm is a cluster provisioning tool implementing the best-practices for creating Kubernetes clusters (following Kubernetes The Hard Way steps). Kubeadm performs the actions necessary to get a minimum viable and secure cluster. It follows Kubernetes operator architectural approach for cluster creation and management. What is also important, Kubeadm is an official Kubernetes SIG Lifecycle project - this is important because official Kubernetes SIG projects usually tent to have better community support and be more mature than their non-official counterparts.

Kubeadm is a great choice if you are ready to deal with the same con as in case of The Hard Way approach (i.e. provisioning EC2 servers and handling a cluster administration burden by yourself), but you would like to make provisioning of the cluster itself easier and automated out-of-the-box. Kubeadm makes it also easier to perform common cluster maintenance practices, such as a cluster version upgrade process or adding additional worker node to a cluster.

Kubespray

Kubespray is a set of Ansible resources (playbooks, inventories, etc) focused on Kubernetes provisioning, configuration and management. Kubespray can deploy to almost any kind of target environment you might want (including AWS, GCE, Azure, OpenStack, vSphere, Packet, Oracle Cloud Infrastructure) or even to bare metal (with an array of supported Linux distributions).

Kubespray is alsoan official Kubernetes SIG Lifecycle project - as in case of Kubeadm, this is important because official Kubernetes SIG projects have great community support. What is very interesting, starting from version 2.3
Kubespray supports kubeadm-based deployments. Moreover, starting since version 2.8 Kubespray deprecated non-Kubeadm deployments. It means that currently Kubespray basically relies on Kubeadm to perform cluster creation under the hood.

Kubespray is a strong candidate if you don't want to use EKS for some reasons (for example you need more customized Kubernetes installation over regular EC2 instances), but at the same time you need some higher level opinionated approach for a cluster provisioning process and configuration. Kubespray is also a great choice if you need a cloud-agnostic way of cluster provisioning and management - Kubespray allows you to provision your AWS cluster in a bare metal mode over pre-provisioned EC2 instances accessible via SSH. Another important factor for Kubespray would be familiarity with Ansible, if your operation folks already know Ansible - they will feel at home.

Kops

Kops is described as "kubectl for clusters" . Kops is a toolkit which brings you
very opinionated way of managing clusters on supported cloud providers (including AWS and GCP). Kops is not based on Ansible like Kubespray, instead it relies on AWS API calls directly. Kops provisions not only the cluster itself, but also an EC2-based infrastructure for your cluster. Kops leverages cloud specific features of each cloud provider to brings you the best experience - for example in AWS it will create auto scaling and self healing EC2 autoscaling group to host your cluster nodes. Kubespray is also an official Kubernetes SIG Lifecycle project.

When to use Kops? If you don't want to use EKS for some reasons (like fine-tuning cluster configuration), but you would prefer to rely on higher level and very opinionated tool providing rock solid and battle tested cluster setup - Kops is a way to go. This is also a good option if you don't care so much about being cloud-agnostic.

EKS

AWS EKS is a managed Kubernetes offering from AWS. It gives you highly available managed Kubernetes control plane, and a couple of ways to connect node workers to it (including on demand EC2 instances, Spot instances or even serverless compute engine Fargate). Cluster itself costs about 72 USD per month. In general EKS is the easiest way of provisioning and operating Kubernetes clusters in AWS. I highly recommend you choosing EKS if there is really no good reason for doing otherwise.

What could be reason for not using EKS? One scenario would be customization of your Kubernetes installation. EKS provides
you opinionated setup where you cannot tune every possible piece of your installation. Or even if certain customization is possible, you might lose AWS support for it. For example Amazon only officially supports the Amazon VPC CNI plugin.

Summary

AWS EKS is in general a reasonable default for running Kubernetes clusters in the AWS environment. If for some reason you don't want or can't use EKS, you can try to use less opinionated and more configurable alternatives. Keep in mind however that the more configurable and less opinionated approach is, the more expertise and operational resources is required in-house for your organization to successfully operate it.

25 interview questions for Go Developer position

Henryk Konsek — Tue, 09 Feb 2021 11:30:22 +0000

This is a list of common questions that can be asked by technical interviewers for Go developer position. This is definitely not a complete list, just a subset I find pretty likely to occur during the interview.

Questions

The questions are grouped by the category. Again - the list of categories is far from being complete, however it is very likely that question from given category will be asked during the interview.

Modules

What are Go modules?
What was used before Go modules were introduced?
What is vendoring?

Interfaces

What is an interface in Go?
How many functions can be usually found in an average Go stdlib interface?
How to define a function argument that can be anything?

Pointers

How to indicate nil string as a return type?
How to modify arguments passed to a function?
When arguments passed to a function is stored the stack? When on the heap? What is a difference?

Slices

How to define a variadic function?
How to pass a slice into a variadic function?

Strings

How to get a substring?
How to split a string?
How to join a slice of strings?
How to check if a string starts with a substring?
How to check if a string ends with a substring?

Context

What is context? Why is it useful?
How to define a context timeout for function execution?
How to handle a context timeout within that function?

Concurrency

Improve the following library function:
- func ExecuteShellCommand(cmd string) (output []string)
- Allow function caller to asynchronously receive every line of stdout of executed shell command (in real time)
- Notify function caller that command execution is over

IO

How to read local file as slice of bytes?
How to convert io.Reader into slice of bytes?

JSON support

What library and function would you use to parse JSON file?
What library and function would you use to parse JSON file that doesn't fit into RAM?
What JSON library would you recommend from the usability point of view? For example to support nested queries.

Summary

What do you think about the list above? What would you add or remove? What other questions do you find to be asked frequently during interviews? What questions to you like to ask when interviewing your candidates? Please leave the answer in the comments!