posts

In one of my previous posts, I wrote about underscore-cli for looking at JSON output (e.g. to see the curl response from a REST web service). An alternative to this is jq, a command line processor for JSON. This CLI allows for simple, yet powerful expressions that make any CLI pro user be productive when interacting with REST services.

As I reviewed the 2017 Thoughtworks technology techniques trends, one cool recommendation was about to “try” the concept of Lightweight Architecture Decision Records. I must admit, I have been looking for something like this as I’m tired of having note pads everywhere, and I’m really trying to stay away from MS-Word documents and Powerpoints for developers. I have been looking for something lightweight, easy for developers to follow.

I have been using Spring for many years now and I really like the simplicity and non-invasive model of its features. As I have been implementing 12 Factor applications, I needed to start using a central way to configure the many microservices we are building. This is where Spring Cloud Config comes to the rescue.

Here is another update on my gitconfig:

At some point in your REST endpoint implementation, you will need to return a non 200 response. Now, most implementations show how to implement this using exceptions. While this may seem like a nice approach (from a programming language point of view), exceptions can add overhead to the running JVM. This translates to ineffective use of resources of the JVM for supporting non 200 responses.

A few months ago, I was invited to speak on Spring Boot and Cloud Native. This was a good discussion. It was fun to build an app from scratch using Boot. For those interested, you can find the app in my github account:

The existing Cloud Foundry (CF) architecture includes a layer to support “Service Brokers”:

The Ozone Widget Framework (OWF) is a set of tools to enable “widgets” in the UI to communicate to each other. I must admit that the framework (or platform) was an early approach to projects such as “Rave” or “Wookie” (Apache), yet I’ve been asked if CloudFoundry supports it. While my experience using OWF has been somewhat painful, I noticed that an OWF deployment requires a server that is “optimized” for its deployment. As such, OWF can work on CF using the “buildpack” feature. I suspect you can argue that OWF can be re-written as a web application component to work with the “standalone” java buildpack, however such work is beyond the scope of this post. This post describes what I had to do to create the “ozone-buildpack” to get this working.

I just published a Vagrant file (and configuration) for whoever wants to start picking up some BOSH CLI and/or CF CLI development. I’m experimenting with BOSH, so I figure I’ll share my config. This is found here:

In using CloudFoundry, I find myself using the CLI more often than not. This works for me very well because I enjoy using CLIs more often than not, however some things can also be done with scripting.