Fix image

config.toml

@@ -17,10 +17,10 @@ copyright = "This work is licensed under a Creative Commons Attribution-ShareAli
 [Params]
   AuthorName = "Joshua"
   github = "joshuaboniface"
-  linkedin = "joshua-boniface-80b2b273"
+  linkedin = "joshuamboniface"
   email = "joshua@boniface.me"
   description = "A blog about tech and shiny things"
   cv = "/pages/cv"
   legalnotice = "/pages/legal"
 #  cover = "/img/background-cover.jpg"
-#  logo = "/img/logo.jpg"
+  logo = "/images/joshua.jpg"

content/custom-pdu-3.md

@@ -22,17 +22,21 @@ Well, there is. With a decent amount of electrical know-how, some programming, 3
 
 My first two forrays into the custom PDU project were simple devices that used the ACS714 [Hall effect](https://en.wikipedia.org/wiki/Hall_effect) current sensors alone. These units were built out of plastic wall boxes with the sensors held in series with the hot lines connecting to each plug.
 
-The first iteration worked well, but was quite small, with only 16 outlets (4 boxes), which I quickly outgrew. The second iteration was a fair bit larger, with 28 outlets (7 boxes), which was more than enough for my rack even now.
+The first iteration worked well, but was quite small, with only 16 outlets (4 boxes), which I quickly outgrew.
 
-![PDU 2.0](/images/pdu/2.0/finished.png)
+![PDU 1.0](/images/pdu/1.0/finished.jpg)
+
+The second iteration was a fair bit larger, with 28 outlets (7 boxes), which was more than enough for my rack even now.
+
+![PDU 2.0](/images/pdu/2.0/finished.jpg)
 
 This design had a lot of downsides however:
 
-1. In terms of monitoring, only getting the current was somewhat problematic. Current, measured in amperes, is only one part of the energy equation, and voltage and power factor are other important components which the ACS714 sensor does not provide.
+1. In terms of monitoring, only getting the current was problematic. Current, measured in amperes, is only one part of the energy equation, and voltage and power factor are other important components which the ACS714 sensor does not provide. I was able to hack together a solution in my monitoring software by using the output voltage readings from my UPSes, but this wasn't satisfactory to me, especially given the slow speed of readings and the inaccuracy relative to a live device reading.
 
-2. The sensors were, in my experience, notoriously unreliable. They were nearly impossible to calibrate (due partly to #1) and would sometimes report wildly inaccurate values due to interference. This was especially pronounced with low loads, since I needed to use 20A sensors for safety which have a correspondingly low threshold. Under 0.1A (about 12W) they were completely useless, and under 0.5A (about 60W) they were often +/- 15-20% out from a Kill-A-Watt's readings.
+2. The sensors were, in my experience, quite unreliable. They were nearly impossible to calibrate and would sometimes report wildly inaccurate values due to interference. This was especially pronounced with low loads, since I needed to use 20A sensors for safety which have a correspondingly low threshold. Under 0.1A (about 12W) they were completely useless, and under 0.5A (about 60W) they were often +/- 15-20% out from a Kill-A-Watt's readings. Only at very high current values (>1.0A) were they accurate, and then only to about 1 decimal place, a fairly rough value.
 
-3. The physical design of the PDU was cumbersome. Each box had to be wired in a very tight space with very tight tolerances on wire length, leading to many a scraped and cut finger. Maintenance was also a hassle for this reason. If a sensor died, which thankfully has not happened, replacing it would be a massive chore. And due to the through runs of the power busses, made out of normal 14-2 Romex wire, the boxes were permanently attached to each other. This was fine at the start, but connect 8 of these boxes together and the unit became cumbersome to work with.
+3. The physical design of the PDU was cumbersome. Each box had to be wired in a very tight space with very tight tolerances on wire length, leading to many a scraped and cut finger. This was fine at the start, but connect 8 of these boxes together and the unit became cumbersome to work with. Maintenance was also a hassle for this reason. If a sensor died, which thankfully has not happened, replacing it would be a massive chore. And due to the through runs of the power busses, made out of normal 14-2 Romex wire, the boxes were permanently attached to each other, making disassembly tricky at best.
 
 In setting out to design version 3 of the PDU, I wanted to solve all 3 issues, making something more robust and easier to service and maintain, as well as more accurate.
 
@@ -108,7 +112,7 @@ The first task was to calibrate the sensors. Looking through Xose's library code
 
 To solve this problem, I used on of the free STM32's to build a sensor calibrator. The idea is quite simple: I would connect up the sensor to the calibrator, attach a known resistive load (a 40W and 60W lightbulb in parallel totaling ~100W of load), and connect everything to a no-name Kill-A-Watt to give me a reference. I could then enter the reference value the Kill-A-Watt showed, and let the calibrator read the modules and calculate the correct multiplier.
 
-This process took a lot of iteration to get right, and in the end I settled on code that would run a large number of scans trying to determine the exact value that matched my input values. But it was worth the time, and the results turned out to be perfect - I was able to use the calibrator on each sensor to determine what their multiplier should be, and then store this for later.
+This process took a lot of iteration to get right, and in the end I settled on code that would run a large number of scans trying to determine the exact value that matched my input values. But it was worth the time, and the results turned out to be perfect - I was able to use the calibrator on each sensor to determine what their multiplier should be, and then store this for later use inside the live code on each microcontroller, giving me nearly to-the-watt accuracy.
 
 ```C++
 [calibrator code]
@@ -116,7 +120,7 @@ This process took a lot of iteration to get right, and in the end I settled on c
 
 ![Calibrator output](/images/pdu/3.0/calibrator-output.png)
 
-With the calibration values in hand, I turned to writing code to handle the actual module microcontrollers. The code here ended up being extremely simple: simply poll the PWM of each sensor in turn, calculate the output, then display it on the serial console for reading by the Raspberry Pi. Note the `struct` for the sensor modules, which contain the individual multipiers found during the calibration step for that given module, as well as the identifier of each plug.
+With the calibration values in hand, I turned to writing code to handle the actual module microcontrollers. The code here ended up being extremely simple once I had the calibration: simply poll the PWM of each sensor in turn, calculate the output, then display it on the serial console for reading by the Raspberry Pi using JSON formatting. Note the `struct` for the sensor modules, which contain the individual multipiers found during the calibration step for that given module, as well as the identifier of each plug.
 
 ```C++
 [microcontroller code]
@@ -126,6 +130,10 @@ The final step was to write the controller software for the Raspberry Pi side. T
 
 [TBD]
 
+```Python
+[pdusensord code]
+```
+
 ## Putting everything together
 
 With all the programming and module assembly done, I could begin assembling the final PDU. Here is the final result:

content/pages/cv.md

@@ -19,30 +19,35 @@ I am a driven, service-oriented individual with a strong knowledge of Linux admi
 ## Educational History
 
 #### Mohawk College (Hamilton, ON) - Network Engineering and Security Analyst
-* Sep 2008 - Dec 2012
+* Sep 2008 - Dec 2012 (completed diploma)
 
 #### Carleton University (Ottawa, ON) - Bachelor of Computer Science
-* Sep 2007 - May 2008
+* Sep 2007 - May 2008 (incomplete; two semesters)
 
 ## Employment History
 
-####  VM Farms (Toronto, ON) - Linux DevOps Administrator, Operations Technical Lead
+#### [Clearcable Connects](https://clearcable.ca) (Hamilton, ON) - Senior Systems Architect
-* Aug 2016 – Present
+* Oct 2018 - present
+
+In the role of Senor Systems Architect I provide operational support, research, and development to the Clearcable Standard Operating Environment (SOE) through a DevOps mentality and mentorship of teammates. In this role I have been responsible for several major projects, including the deployment of a self-build hyper-converged hypervisor management system called [Parallel Virtual Cluster](https://github.com/parallelvirtualcluster/pvc) for customer systems to provide greater resilience and reduce administrative burden, the creation of several additional deployment methodologies for the SOE system including support for a wide range of underlying hypervisors, the continued improvement of our monitoring frameworks, and the tight integration of Ansible and Infrastructure-as-code into our team systems administration workflows. This role has also necessitated the development of several tools and utilities, mostly using Python, for internal use, as well as the documentation and training of staff in their use, as well as the continued improvement of existing tools and workflows. In the sub-role as deployment specialist, I have deployed over 10 new customer systems from pre-sales to completion, along with continued day-to-day maintenance of our SOE systems.
+
+####  [VM Farms](https://vmfarms.com) (Toronto, ON) - Linux DevOps Administrator, Operations Technical Lead
+* Aug 2016 – Sept 2018
 
 In the role of Linux System Administrator I provided management of systems for web application developers within the framework of a DevOps operations service providing consulting advice and managed hosting. Using both an in-house Xen based cloud as well as various remote computing services including AWS, I helped ensure the continued operation of the platform as well as the day-to-day administration of customer systems. Utilizing configuration management with Puppet and Ansible, I provisioned and managed applications serving millions of users and using multiple web development stacks, HTTP servers, and database backends, in addition to various proxying, queueing and caching applications. During late 2017 and 2018 in the role of Technical Lead for Operations, I assisted in the training of new employees and daily technical decisions with a mind for best-practices, and interacted regularly and in-depth with customers using various communication tools.
 
-#### Clearcable Network Services (Hamilton, ON) - Linux System Administrator
+#### [Clearcable Network Services](https://clearcable.ca) (Hamilton, ON) - Linux System Administrator
 * Jan 2013 – Jul 2016
 
 In the role of System Administrator I used my skills with internetworking and Linux servers to ensure the proper operation of the Clearcable Networks Standard Operating Environment, a Debian GNU/Linux-based Internet Service Provider platform running on Cisco UCS hardware, and using Xen virtualization and bcfg2 configuration management. This included management of provider-grade services including DNS with BIND9; ISC DHCP in advanced configurations; Postfix/Courier email stacks; monitoring with Icinga and Munin; server hardware maintenance and support including full system rebuilds, hardware performance analysis and troubleshooting. I contributed advancements to the platform, assisting in its continued development and growth, including a major distribution upgrade project and implementation of live migration functionality to the platform using DRBD. During oncall rotation and daily support tasks, I also assisted in the deployment and maintenance of service provider networking, including routing and CMTS/ DOCSIS and VoIP access technologies to ensure the optimal operation of our client systems.
 
-#### HHS Population Health Research Institute (Hamilton, ON) - Systems Administrator
+#### [HHS Population Health Research Institute](https://www.phri.ca) (Hamilton, ON) - Systems Administrator, co-op
 * Sep 2010 – Aug 2011
 
-In the role of Student (Co-Op) Administrator, I was responsible for day-to-day support of desktop systems and users, including deployment of new systems, hardware replacement/reimaging, and management of accounts with Active Directory. A long-term project during me tenure was an extensive documentation of the site datacenter including diagramming and inventory of the facility.
+In the role of Student (Co-Op) Administrator, I was responsible for day-to-day support of desktop systems and users, including deployment of new systems, hardware replacement/reimaging, and management of accounts with Active Directory. A long-term project during my tenure was an extensive documentation of the site datacenter including diagramming and inventory of the facility.
 
 #### The Home Depot (Burlington, ON) - Special Services, Tool Rental, Electrical, Cashier
 * Oct 2006 – Jan 2013
 
 ## Personal Interests 
-Fantasy and Science Fiction literature, repairing and building computers, performing and composing music, astronomy and astrophysics, science and technology papers and books
+Fantasy and Science Fiction literature, repairing and building computers and other DIY projects, performing and composing music, astronomy and astrophysics, science and technology papers and books, leader of the [Jellyfin project](https://jellyfin.org).