So I've been doing a bit of Python recently for a project I'm working on on a Raspberry Pi. There will be a longer blog post about that in the next few weeks. But one thing I ran up against was that I wanted to start my daemon, written in Python, using a systemd service on Raspbian.

Normally, you would just shove a script invocation into a systemd unit and call it good, but in my case I had made use of Pipenv, which is a bit like Bundler in the Ruby world and Composer in the PHP world, to manage my project's dependencies.

Sometime in the mid 90s, I downloaded an astronomy program for my computer. I don't even remember what it was called. In poking around on it, I discovered that it could plot future total solar eclipses and that one would pass, from the resolution of the map, very close to where I then lived in eastern Tennessee. The date was August 21st, 2017.

As you can tell from the last few posts, I've been having a lot of fun with collectd and instrumenting my systems. But I had one glaring hole until recently: my Ubiquti Unifi AP access points. Well no longer!

Warning: Doing this is making a clear tradeoff between security and speed. Do not do this on the public Internet or across a network you do not trust.

rsync is one of those tools that is in every computer user's toolkit. It's fantastic for moving large amounts of data around and for migrating data from one system to another.

rsync also has a ton of options and, after awhile, you get to where muscle memory means you just type the same few options over and over again. With me, that was -avz, archive, verbose, compression.

Recently, I was migrating several terabytes of data from a NAS to a computer. As is often the case, I fired up an rsync job and watched it.

It maxed out at about 35 megabit. Across a gigabit switched internal network.

Okay, no profit in this, but it certainly is fun!

I have two Nest thermostats in my house and, after some teething pains (yay the life of an early adopter) they have been pretty solid. But they're also black boxes that I know little about. I know they're collecting mountains of data and sending it back to the Google mothership. Wouldn't it be nice to get at some of that data and build my own reports?

Extending my post from last year, here's some additional data I'm grabbing from pfSense and stuffing into collectd via a script. I'm now grabbing:

• DHCP Leases
• CPU Temperature
• Thermal Zone Temperature
• SSD Drive Temperature
• UPS information (via NUT)

Here's the exec script:

Today, with little fanfare, Apple dropped a bunch of new products, including a new cheap iPad and a red iPhone.

What?

AngularJS's built-in ngResource is a great tool for natively supporting REST APIs in your Angular application. But what happens when you need to support something besides a simple call that retrieves a list of JSON objects? You quickly run into the limits of ngResource.

Here's a great case where you might need to do something more complex: paging. Say you want to get a list of objects, and there's 10,000 or so of them. You don't want to send 10,000 objects to your frontend app. You want to send a portion of them, but you still need to indicate to the app that there are more.

Surprisingly, considering how widespread this pattern is in web development, there does not seem to be a native way to accomplish this. But you can extend ngResource. Here's how I did it.

Since it's been awhile since I wrote a post about what I use in regards to software, hardware, etc. Perhaps it's time that I did that again. So here's a list of what I'm using in 2016:

So I've recently been on a graphing thing, wanting to collect all kind of data from my home network. And collectd seems to be a good candidate for doing that. With a huge number of plugins, it can collect and send just about anything you can think of to a time series database (I'm using InfluxDB for this).

But, there's a significant hole in my data collection: my pfSense firewall. Well, not anymore!