ABOUT US

I have a bunch of RaspberryPi devices kicking around the house and office. There are some Pi 2s, Pi 3s, and a Pi Zero. I use them for a lot of different things. I just setup a Pi 3 to act as a scanning server for the Fujitsu iX500 ScanSnap that we use to keep a paperless home. There's a Pi 2 running NUT, some cron scripts, and some other admin stuff for my home network. We got a Pi Zero from an Ada Box that we setup to run RetroPie. While interesting, it's not overly complicated stuff. Places like Los Alamos National Labratory use Raspberry Pis for prototyping their large systems.

I didn't just terminate cables in a mechanical room and mount a few pieces of hardware directly to a wall. Instead I got a wall mount rack to organize everything in.

One of the things that I knew I wanted to do with this home network was run cables to as many places as possible

Moving into the new house meant a new internet provider and the standard installation of home networking gear that exists in (hundreds of) thousands of houses throughout North America

Thoughts about the hidden costs of actions

Slides and other materials from PrDC 2016

It was time for a new keyboard and I was looking for something mechanical and ergonomic.

Logging DD-WRT system entries to the cloud

As I mentioned in my last blog post (Microservices and Boundaries), I regularly see the question "How big should my microservice be?" The fast answer, albeit not the easy one, is that they should be the 'right' size. In that last blog post I talked about getting the right functionality into the right places (Antel for phone related functionality, Abitab for payment related functionality). There are a lot of people giving a lot of advise about scoping microservices, and I disagree with the majority of it. Here are some of the suggestions I've seen.

One of the most common questions I’ve been getting asked about microservices is “How big?” I was recently down in Montevideo Uruguay speaking at the .NetConf UY Meetup speaking about microservices. As part of my vacation in Uruguay I wanted to get a local SIM card for my phone so that I would have data without relying on free WiFi. At the time I was getting the SIM and making things work it seemed like one of the most frustrating experiences I’ve ever had. Lots of running around, lots of wasted time. Once I got onto the plane home I started thinking about it in a different light.

I spent the better part of this afternoon fighting with this error (and arguing Canadian voting rights with the Western Devs). I was trying to run our project’s build script which uses nAnt and MSBuild to work all the compilation magic we need. There are a lot of pieces of information on how to solve this on the web. Most solutions revolve around "Install Visual Studio 2010", "Install the Windows Software Development Kit for Windows X", or "Turn off the generation of serialization assemblies in your projects/solution". Some of these are just downright scary solutions…others won’t work in my situation.

In my first post I made reference to the idea of microservice isolation a number of times. I figured that this is as good of a topic as any to start with. The concept of isolation and boundaries is core to how you build your microservices. Let's leave boundaries for another post because it's a complicated and deep concept by itself.

This past winter I started working on a project that was being architected with a mind towards using microservices. Prior to this I'd only seen the term 'microservices' floating around in the ether and really hadn't paid much attention to it. I wanted to share what we did and what I learned through the process and my subsequent research. That experience and research has led me to one belief: the microservice topic is massive. This post is going to be a kick-off to a series that will cover that material. With that, let's dig in.

I'm doing some work right now that requires us to send SMS messages. The organization I'm working with has never had this capability before so we are starting at ground level when it comes to looking at options. As part of our process we evaluated a number of different criteria on about four different SaaS options; twilio, plivo, nexmo and sendinblue. For reasons not relevant to this post, plivo was the initial choice of the client. We moved from analysis to writing a proof of concept.

I'm working on a cedar garden gate for our back yard. It's all mortise and tenon joinery which means I make a lot of use of my Narex bench and mortise chisels. The more you use chisels the duller they get. Dull chisels cause you two problems; you can't be as precise with them, and you run the very real risk of amputating a finger. As much as I have two of each finger I really do want to keep all eleven of them. Getting tight fitting tenons requires fine tuning of their thicknesses by the thousandth of an inch. Both of those fly directly in the face of what dull chisels are good at…so tonight was all about sharpening them up.