AEM Uber JAR locations

Old-ish news, AEM 6.4 is out. If you’re developing and looking for a quick project start, be sure and check out sdkman! and use sdkman to install lazybones. Then, with lazybones, create an aem-multimodule-project templated project and follow the prompts. It couldn’t be easier (for small projects, at least)! Repos Adobe’s Repo Maven Central Repo (is missing 6.3.2 and 6.4.0)

ASG Rolling Updates on AWS with Terraform

The cloud is great. Isn’t the cloud great? …and because you’re reading this you know about running compute instances in the cloud. If you’re unlucky enough to still be dealing with code deployed to machines instead of containers, you might be in the painful world of shipping code by automated or manual move and re-start procedures. Perhaps you are lucky enough to be in a containerized environment, but not on Kubernetes.
Read more

Authoring an end of life digital access instruction document

The other day I established my Last Will, Living Will, and Power of Attorney after not having one in place, ever. Though I put these docs in place relatively late in my game, I have thought about end of life activities before, but mainly limited in scope to digital access. Specifically, how to access my encrypted computer, encrypted cloud backups, and encrypted drives stored on premises where I reside when something happens.
Read more

Kubernetes on AWS: An overview of KOPS

What is KOPS? Self described as “The easiest way to get a production grade Kubernetes cluster up and running” (on AWS (and others, see below)). KOPS looks a lot like Terraform. In broad strokes it takes cluster, context specific arguments and creates cloud resources that house and facilitate the usage of a Kubernetes cluster. KOPS Highlights Automates the provisioning of Highly Available (HA) clusters on AWS from the CLI, similar to helm or kubectl.
Read more

Helm, Kubernetes 'package management', in a nutshell...

What is Helm? Helm is a Kubernetes package manager managed by CNCF, and started by Google and Deis. It packages multiple Kubernetes resources into a single logical deployment – a chart. Core Objectives Installing resources in Kubernetes should be easy like apt/yum/homebrew Teams should be able to easily collaborate Releases should be reproducible Packages should be sharable Building Blocks Helm consists of the following four resources: A chart is a package, a bundle of Kubernetes resources A release is an instance of a chart that has been loaded into a Kubernetes cluster (tiller) A repository is a collection of public charts A template is a kubernetes resource / configuration file consisting of Go/Sprig templating Client and Server A user (you, jenkins, etc…) uses the Helm CLI to communicate with Tiller, the Helm server.
Read more

Kubernetes: Basics

What is Kubernetes Led by Google, the Kubernetes project aims to build a robust platform for running many containers. It allows for the automation of deployments, scaling, and management of containerized applications. Kubernetes enables teams to more effortlessly move workloads across cloud infrastructures by grouping containers into logical units for easy management and discovery. Why migrate to Kubernetes? more efficient use of cloud resources – resulting in cleaner architecture and huge potential savings in cloud costs removal of centralized team release responsibilities in lieu of specific functional teams decentralized schedule for release cycles across product areas Architecture: Master nodes A Kubernetes cluster is composed of two types of nodes; master nodes and worker nodes.
Read more

Load testing an in-memory, reactive, geospatial REST API

Yesterday I wrote a project writeup on building an R-tree-based reactive REST API for geospatial data and queries. This blog post will cover the query load testing efforts for the REST API. First though, a quick refresher… R-trees have been around for decades and are used commonly with quad-trees, b-trees, and geohash algorithms in a variety of spatial engines from PostGIS to Redis. I’ve done extensive no-SQL load testing of geospatial engines in the past, but haven’t written about it.
Read more

An ephemeral, reactive geospatial REST API

I spent a portion of my holiday break (mainly the plane rides) tinkering with Ratpack and a reactive R-tree library. This is the second time I’ve tinkered with this combination of tech. Unlike the first, which was benchmarking NoSQL geo-spatial engine candidates; Mongo, Redis, Rethink, R-tree, and ElasticSearch, this exploration/POC was meant to test the performance of a REST-enabled in-memory, ephemeral, geospatial “engine” without a backing data store, related drivers, and the network overhead.
Read more

BAAAHS Lighting Controller Development

The Big Ass Amazing Awesome Homosexual Sheep (BAAAHS) is a well known fuzzy entity in the Bay Area queer maker and burner space. BAAAHS garners attention with its peacock-like bedazzling light shows, light beacons, earth-shattering beats, and two-story dance and lounge spaces. Oh. And a pool slide. I can’t forget that pool slide! 2016 was my first year burning with BAAAHS. In 2016 we set out to complete an ambitious number of new structural changes to Pearl (BAAAHS’ other gendered daytime name).
Read more

Tinkering with Metromile driving data in AWS Athena

Metromile is a car insurance company that has been a leader in the pay-as-you-go insurance marketplace. Their rates are calculated based on two components: a base rate composed of the rating for the vehicle type (think Porsche vs Toyota Camry) and the registered address (home address) of the vehicle a per-mile rate for a driver based on their driving history / available data In order to calculate the per-mile billing, the company issues you an ODB-II adapter (more on ODB-II).
Read more