A Neate Blog

As a developer, I find that one of the easiest ways to ship an application is to create a Docker image via a custom Dockerfile in order for it to be deployed usually on AWS/Azure/Oracle cloud Kuberenetes (AKS, EKS, OKE). In recent times I’ve spent some time looking into the docker image created and attempted to find ways to shrink the final image size and also make the build quicker by caching docker image layers, this post is Part 1 of my approaches and also the final outcomes. This particular Dockerfile builds an Oracle JET UI Application.

TL;DR:- Ordering your commands in terms of slowly-changing outputs to more frequently increasing output has a huge impact on build time, explicitly specifying files to copy instead of copying everything results in image size reduction and finally using ADD for local tar archives means Docker will automatically unpack the archive for you, no more manual unpacking! The above might sound like common sense but they’re often overlooked, even in production ready applications.

If you find yourself working with Kubernetes, whether that’s in the cloud on AKS (Azure), EKS (AWS), OKE (Oracle Cloud), GKE (Google Cloud) or even locally, chances are you have encountered the need to edit a piece of config via the kubectl edit command, did you know that you can change the default editor that kubectl edit uses, on Windows it’s Notepad by default but I changed it to VS Code and here’s how.

TL;DR:- You need to create an environment variable named KUBE_EDITOR, the value should be set to the CLI command to open the editor of your choice and ideally specify a watch flag so K8s knows when the file has has been saved and closed.

The Nordic APIs 2019 Platform Summit attracted both industry experts and thought leaders, this year I was lucky enough to be selected to present a consumer’s take on GraphQL vs REST. My short presentation and accompanying demo (written using Oracle JET) imparted the top 3 factors a consumer considers when looking at an API, the key take-away is that ultimately the design of the API is more important than the technology the API is built in.

Early July I had the pleasure of presenting at the UKOUG Southern Technology Summit, this one day conference contained various streams but I mainly attended the Development stream. Three of the sessions that stuck in my mind were Phil Wilkins’ presentation of “What Makes A Good API”, David Callaghan’s session on “Hermes’ Chatbot, Holly” and finally Susan Duncan’s session on “High Productivity in a Microservices World”.