dwmkerr.com

This is the third part of my Effective Shell series - practical examples of ways to be more efficient with everyday tasks in a shell. Part 1: Navigating the Command Line Part 2: Become a Clipboard Gymnast Part 3: Getting Help Part 4: Moving Around Part 5: Interlude - Understanding the Shell Part 6: Everything You Don’t Need to Know About Job Control Part 7: The Subtleties of Shell Commands In this article I’ll show you how to quickly get help when working with tools in the shell, without disrupting your flow!

In this article I’m going to show you how to set up OpenShift to integrate with Splunk for logging in a Docker container orchestration environment. These techniques could easily be adapted for a standard Kubernetes installation as well! The techniques used in this article are based on the Kubernetes Logging Cluster Administration Guide. I also found Jason Poon’s article Kubernetes Logging with Splunk very helpful. First, clone the Terraform AWS OpenShift repo:

This is the second part of my Effective Shell series, which contains practical tips for using the shell to help with every day tasks and be more efficient: Part 1: Navigating the Command Line Part 2: Become a Clipboard Gymnast Part 3: Getting Help Part 4: Moving Around Part 5: Interlude - Understanding the Shell Part 6: Everything You Don’t Need to Know About Job Control Part 7: The Subtleties of Shell Commands In this article I’ll show you how you can use the shell as an efficient tool to compliment how you use the clipboard.

This is the first part of a series I am writing which contains practical tips for using the shell more effectively. Part 1: Navigating the Command Line Part 2: Become a Clipboard Gymnast Part 3: Getting Help Part 4: Moving Around Part 5: Interlude - Understanding the Shell Part 6: Everything You Don’t Need to Know About Job Control Part 7: The Subtleties of Shell Commands I can’t think of a better place to start than navigating the command line.

There are occasions where you might need to have scripts or commands which wait for TCP/IP ports to open before you continue. I’ve come across this need again and again when working with microservices, to make my life easier I’ve created a little utility called wait-port which will wait for a port to open: It’s built in Node, the project is open source, open for contributions and ready to use:

In this article I’m going to demonstrate some simple tips and tricks which will help you build and maintain beautifully simple mobile build pipelines. These techniques can be applied to different mobile app technologies and integrated into almost any build system: Each tip is demonstrated in the sample apps in the dwmkerr/beautifully-simple-app-ci repo. The Challenges of Mobile App CI Tip 1 - Embrace Makefiles for Consistency Tip 2 - Control Version Numbers with a ‘Touch’ Command Tip 3 - Control App Icons with a ‘Label’ Command Tip 4 - Support Configurable App Ids Tip 5 - Document, Document, Document Conclusion The Challenges of Mobile App CI Conceptually, a mobile app CI pipeline is pretty simple:

OpenShift is Red Hat’s platform-as-a-service offering for hosting and scaling applications. It’s built on top of Google’s popular Kubernetes system. Getting up and running with OpenShift Online is straightforward, as it is a cloud hosted solution. Setting up your own cluster is a little more complex, but in this article I’ll show you how to make it fairly painless. The repo for this project is at: github.com/dwmkerr/terraform-aws-openshift. Creating the Infrastructure OpenShift has some fairly specific requirements about what hardware it runs on1.

In this article I’m going to show you how to create a resilient Consul cluster, using Terraform and AWS. We can use this cluster for microservice discovery and management. No prior knowledge of the technologies or patterns is required! The final code is at github.com/dwmkerr/terraform-consul-cluster. Note that it has evolved somewhat since the time of writing, see the Appendices at the end of the article for details. Consul, Terraform & AWS Consul is a technology which enables Service Discovery1, a pattern which allows services to locate each other via a central authority.

I recently found a surprisingly helpful approach for server-side development which uses Slack in a creative way. The Problem The scenario can be roughly simplified to this: We are building a mobile app and application server. This will take data from a user, transform it and then pass it to the enterprise system processing. The problem is that the enterprise system doesn’t exist yet! Now this is not too much of a challenge, the first thing we did was build a simple mock of the enterprise system in Node.

In this article I’m going to demonstrate a few tips and tricks which can make your life easier when you are building or maintaining Dockerfiles. The need for a Build Pipeline Do we really need any kind of continuous integration or build pipeline for Dockerfiles? There will be cases when the answer is no. However, if the answer to any of the following questions is ‘yes’, it might be worth considering: