Google doesn’t have much on this topic, so here is what I found. You can’t use reflect to inspect a package at runtime. You can use go/parser to inspect the package if you have access to the source code I needed to inspect a package to facilitate generating code at compile time. So the go/parser route worked fine for me. The following code prints out the types and consts and functions found in the files of the .
Traditional software development disciplines teach us to control public functions and interfaces exported by our code. As the exported code forms what is known as the public surface of the code package. It is through this public surface that we proclaim to our users which interfaces and functions are available for use.
Making an interface public proclaims two things 1. The interface is well tested and approved for use. 2. The signature of this interface is guaranteed not to change for this major version.
Every time I need to process a stream of data two things are usually true. A I need to breakup a stream of data into smaller chunks I can then process. B I have to code the buffering of the stream manually. This involves reading in a chunk from the stream, then searching the chunk for the data I want, then fetching another chunk, and so on. In most languages this results in a non trivial bit of code.
In Golang channels are the recommended method for sharing data between threads, and I don’t refute this, but for simple single value data access a mutex is often more appropriate, simpler and more performant. While building the args library, I needed a way to provide end users a thread safe way to retrieving the newest version of a config object. As I was very excited about my first practical application of channels, I initially implemented value access using golang channels.
As soon as Torus was announced, allegations of CoreOS suffering from Not Invented Here (NIH) syndrome began to fly. Kelsey Hightower came to their defense with this tweet.
Just finished a quick conversion from octopress to hugo, the hugo learning curve was a little high, as it doesn’t have a ton of opinions about your site; unlike octopress. But with the help of these two blogs, and the hugo site documentation I have almost everything working. Nathan Leclaire Parsia Hakimian Hugo Documentation
Openstack provides fantastic capabilities Enterprise companies can leverage to manage their infrastructure in addition provide supportive capabilities that applications can directly take advantage of like Swift and Keystone. As a whole open stack has a rich suite of tools that make it very compelling for enterprise companies to run their infrastructure on. The one area where open stack falls short is an application orchestration. That being said, it does have a project called Heat which attempt to fill this gap, but the adoption of heat as an application deployment platform and orchestration system has been lacking.
The 1.2 release of Kubernetes added a new feature called ConfigMap which provides mechanisms to inject containers with application configuration data. Injecting configuration files works great for most applications but the new ConfigMap feature comes with the ability to not only provide an initial configuration when the container starts, but also to update the configuration in the container while it’s running. In this post I’ll show you how to write a microservice to take advantage of the updated configuration and reconfigure your service on the fly.
If you are running the CoreOS beta channel, you should already have kubelet installed, but if you are running stable channel like me and wish to play with the latest and greatest kubernetes and deploy a non trivial sized cluster, read on.
I’ve been working on building and installing Kubernetes from scratch and during this process I followed a guide on the CoreOS website called CoreOS + Kubernetes Step By Step. In this guide they demonstrate using cloud-config to install SSL Certs on the core OS operating system. Altho this makes the guide simpler; by doing this I have found it encourages bad behavior. This is because when you trying to scale the solution one immediately starts reaching for a configuration management systems to handle installing a SSL Certs and binaries onto CoreOS workers/masters. This is not what you want!
I picked up pdf copy of Sam Newman’s book, Building Microservices. Since I’ve had some experience with SOA and microservices I thought I’d take a look. I’m really glad that I did, it’s a great book! The following are some quotes from the book and my thoughts on the subject.
“With micro-services, we can make a change to a single service and deploy it independently of the rest of the system.” — If multiple services rely upon a single service, you can’t just change it inside a vacuum, deploy it and expect dependent systems to never have problems.
.yellow { color: #C7C327; } .green { color: #00C120 } .red { color: #C71E12 } Due to the collaborative nature of git; over time I begin to accumulate quite a few branches and working closely in a team compounds this problem. Remembering what branch needs to be merged, and what branches need a pull can tax the little grey cells. As a solution to this problem, I present git wtf Instead of trying to explain what it is, lets just run git wtf and examine it’s output.