Add Piwik, clean up test box post, add circuit diagram.

content/Electronics/test-box.md

@@ -10,9 +10,9 @@ This post details the design and construction of Test Box v2, a custom device us
 
 In 2007, I was semi-formally named Club Armorer at [Cobra Fencing](http://cobrafencing.com). The job entails testing and repairing fencing equipment owned by members and the club itself, some general facility maintenance tasks, and serving on the equipment inspection committee at tournaments. Equipment inspection, as the name implies, involves testing each competitor's gear to ensure that it meets requirements set forth by the [USFA](http://www.usfencing.org/page/show/695208-rulebook "US Fencing Association"). The tests are primarily concerned with ensuring the safety of the fencer as well as the integrity of the competition. The safety-related tests ensure that protective gear is, in fact, protective. The integrity-related tests were what I found more intriguing, and what the rest of this post is concerned with. Modern competitive fencing uses a system of wires, contacts, and tiny springs to detect when a point has been scored. At the center of the fencing strip, there is a scoring machine, which is connected to a spring-loaded reel of wire at each end of the strip. The fencer clips the reel wire onto the back of his or her jacket, and connects it to his weapon with a body cord worn inside the jacket. Inside the tip of the weapon, there is a button which is depressed when the weapon tip strikes a surface, such as one's opponent. This closes a circuit, which is detected by the scoring machine. An additional circuit is completed between the weapon (which is made of conductive metal) and the opponent's metallic vest or jacket, to indicate that the touch was on-target. To ensure that all scoring machines reliably detect a hit made by a fencer, the body cords, weapons, and conductive jackets are tested to ensure that the item's electrical resistance does not exceed a defined limit. This is done by a panel of armorers, many of whom use custom testing devices ranging from a small adapter for off-the-shelf multimeters to complex all-in-one setups.
 
-## The Precursor
+## The Original
 
-[![og-box](/media/testbox/thumbnails/1000x_/og-box.jpg)](https://ant.sr/test-box/og-box)
+![og-box](/media/testbox/thumbnails/1000x_/og-box.jpg)
 
 I felt the need for a club test box. My grandfather got me into circuits and electrical engineering at a young age, so I felt (perhaps overly) prepared for the task. Many internet hours and a few meetings with my grandpa later, the original Test Box was born. It has now faithfully served me and Cobra Fencing for almost **7 years**, so I rewarded it (and myself) by replacing the meters which had become sticky and sluggish with age. Despite breathing new life into the original, I felt it was time to design a new version.
 
@@ -29,37 +29,39 @@ The test box would need to test for a few things to fully examine a piece of equ
 
 ## Design
 
-[![Raspberry Pi, PiTFT, ADC Pi](/media/testbox/thumbnails/1000x_/first-test-multimeter.jpg)](https://ant.sr/test-box/first-test-multimeter)
+![Raspberry Pi, PiTFT, ADC Pi](/media/testbox/thumbnails/1000x_/first-test-multimeter.jpg)
 
 I decided early on that Test Box v2, or at least my first prototype of it, would be built around a Raspberry Pi. It can reliably run Linux, and is exceptionally cheap at $35\. I liked the ability to build multiple prototypes and replace parts easily. I found the $45 [Adafruit PiTFT 2.8" Cap Touch display](https://learn.adafruit.com/adafruit-2-8-pitft-capacitive-touch) an attractive proposition as well, as installation is almost entirely plug-and-play with the Raspberry Pi. My first PiTFT seems to be defective, as the touchscreen has a pretty bad jumpy cursor issue. When I reported this to Adafruit support, they told me to [wipe down the display with a dryer sheet](http://forums.adafruit.com/viewtopic.php?f=50&t=61328). This didn't help. I haven't had this issue with the second one. The box needed an Analog Digital Converter to perform the measurements, and the Raspberry Pi does not have one onboard. The [AB Electronics ADC Pi](https://www.abelectronics.co.uk/products/3/Raspberry-Pi/17/ADC-Pi-V2---Raspberry-Pi-Analogue-to-Digital-converter) is doing the job. It is an 8-channel 17-bit ADC, providing ample resolution for my needs. It is mounted on top of the Raspberry Pi in the photo to the right. A bit of research showed that the easiest way to measure resistance with an ADC would be to build a [voltage divider](http://en.wikipedia.org/wiki/Voltage_divider) circuit (a resistor, essentially) for each channel. With a bit of soldering, I had the core components of Test Box v2 completed.
 
+![Voltage Divider Circuit](/media/testbox/thumbnails/1000x_/Voltage-Divider-Circuit.png)
+
 ## Prototype
 
-[![First attempt at fitting it all together](/media/testbox/thumbnails/1000x_/prototype-interior.jpg)](https://ant.sr/test-box/prototype-interior-1)
+![First attempt at fitting it all together](/media/testbox/thumbnails/1000x_/prototype-interior.jpg)
 
 Afraid of butchering the enclosure, I decided that a prototype was necessary. A piece of cardboard came in handy, along with some banana jacks from Radio Shack. This allowed me to ensure all the hardware worked, mock real use-cases looking for any unforeseen problems, and think through any final design details. Mounting the LCD on my makeshift lid also kept the different circuit boards from shorting each other out. My first guess at positioning the screen turned out to be just fine, and I transferred much of the layout to the final version.
 
-[![The prototype, all wired up.](/media/testbox/thumbnails/1000x_/prorotype-interior-flash.jpg)](https://ant.sr/test-box/prorotype-interior-flash)
+![The prototype, all wired up.](/media/testbox/thumbnails/1000x_/prorotype-interior-flash.jpg)
 
 I proceeded to mount the voltage divider board, and wire each channel to the appropriate connector(s) on the panel. Having all of this set up, I turned my attention to the software needed to make it tick.
 
 ## Code
 
-[![Prototype Exterior](/media/testbox/thumbnails/1000x_/prototype-exterior.jpg)](https://ant.sr/test-box/prototype-exterior-1)
+![Prototype Exterior](/media/testbox/thumbnails/1000x_/prototype-exterior.jpg)
 
 Writing the code for this was fairly straightforward, as the ADC manufacturer provides a [Python library](https://github.com/abelectronicsuk/ABElectronics_Python_Libraries/tree/master/ADCPi "ADCPi Python Library"). I used [Kivy](http://kivy.org/ "Kivy - A python framework for UI development") to build the UI. My code is public at [git.xhost.io/anton/test-box](https://git.xhost.io/anton/test-box) (be warned: The code is somewhat of a mess. A thorough rewrite is pending.) [testbox.py](https://git.xhost.io/anton/test-box/blob/master/testbox.py "anton/test-box/blob/master/testbox.py") is the main program, which runs on the Raspberry Pi as a daemon. It uses [measure.py](https://git.xhost.io/anton/test-box/blob/master/measure.py "anton/test-box/blob/master/measure.py") to interact with the ADC and retrieve resistance measurements.
 
-[![The user interface (first iteration).](/media/testbox/thumbnails/1000x_/prototype-bodycord.jpg)](https://ant.sr/test-box/prototype-bodycord)
+![The user interface (first iteration).](/media/testbox/thumbnails/1000x_/prototype-bodycord.jpg)
 
 Kivy was slightly troublesome to install on the Pi as it had a few prerequisites which took **ages** to compile and install on the 700 MHz single-core ARM processor. Once it was working however, developing the UI was easier than I imagined possible. 10/10, would use again. The completed UI shows a "Connect something!" call to action when idle. When the box detects a body cord, weapon, or other test subject connected, the screen displays the resistance of that item. The measurement is shown in green or red, depending on the resistance threshold for that type of item.
 
 ## The Build
 
-[![Transplanted into the real enclosure](/media/testbox/thumbnails/1000x_/almost-done-open-with-battery.jpg)](https://ant.sr/test-box/almost-done-open-with-battery)
+![Transplanted into the real enclosure](/media/testbox/thumbnails/1000x_/almost-done-open-with-battery.jpg)
 
 With working code, I set out to re-assemble the test box in its permanent (aluminum) enclosure. Lacking access to a proper machine shop, I decided to make do with a vice, a drill, and a coping saw. The banana jacks used for test connections required a simple round hole, and so were very quick to complete. Cutting, and subsequently filing, the opening for the LCD took way longer than I care to admit. This assembly has one flaw, which I'm one online order away from fixing. The Raspberry Pi and the other two circuit boards are both mounted to the conductive aluminum+steel enclosure with conductive steel bolts. This grounded the enclosure, which is problematic when a test connector is accidentally shorted to the case (with a finger, for example). When this happens, measurements become unpredictable and incorrect. The bolts will be replaced with [adhesive PCB standoffs](http://www.banzaimusic.com/Adhesive-Standoffs/) as soon as I can get my hands on some (Radio Shack let me down, as always), which should address the fault.
 
-[![RJ45 and Micro USB jacks](/media/testbox/thumbnails/1000x_/connectors.jpg)](https://ant.sr/test-box/connectors)
+![RJ45 and Micro USB jacks](/media/testbox/thumbnails/1000x_/connectors.jpg)
 
 The last step left before the hardware is complete is to install Micro USB and Ethernet ports on the back of the box. The Raspberry Pi is powered through USB (which is convenient, as almost any cell phone charger can be used as a power source). The Ethernet port is used for programming. When the Pi detects an available network and receives an IP address from DHCP, the address is displayed on-screen. This allows me to SSH in and get to work.
 
@@ -67,4 +69,4 @@ The last step left before the hardware is complete is to install Micro USB and E
 
 The test box surpassed my own expectations. It is possible (likely, even) that this was due to low expectations, but I'm still calling it a success. It is **smaller** than the predecessor. There is no **need for calibration**. Power is supplied over USB, and an optional battery can be installed inside to act as a backup. I haven't purposefully tested battery runtime yet, but the device has been used for over an hour without a power supply attached without problems. There may be a follow-up with more technical details and some extra features. Stay [tuned](http://ant.sr/feed "Follow my RSS feed!")!
 
-[![weapon-test](/media/testbox/thumbnails/1000x_/weapon-test.jpg)](https://ant.sr/test-box/weapon-test)
+![weapon-test](/media/testbox/thumbnails/1000x_/weapon-test.jpg)

content/Web Development/squashing-sqlalchemy-flask-migrate.md

@@ -2,7 +2,7 @@ Title: Squashing SQLAlchemy Migrations with Flask-Migrate
 Date: January 17, 2016
 Cover: /media/flask.png
 
-<img src="/media/yodawg-migration.jpg" alt="Yo dawg" class="inline-right" />While developing a Python application with SQL<wbr>Alchemy, you may find yourself rapidly iterating on database schemas as your project evolves. If you are committing your work often (**as you should be**), this can lead to oodles of [schema migration scripts](http://alembic.readthedocs.org/en/latest/tutorial.html). When a project is in production, these migrations are great for rapidly deploying changes. Until then, there is little use in accumulating a pile of migrations representing every small tweak you made to your models. Squashing these migration scripts into a single "initial" migration is good for your sanity, and results in a leaner git repository. I didn't find the process of squashing your alembic migrations to be well-documented online, so here's my version.
+While developing a Python application with SQL<wbr>Alchemy, you may find yourself rapidly iterating on database schemas as your project evolves. If you are committing your work often (**as you should be**), this can lead to oodles of [schema migration scripts](http://alembic.readthedocs.org/en/latest/tutorial.html). When a project is in production, these migrations are great for rapidly deploying changes. Until then, there is little use in accumulating a pile of migrations representing every small tweak you made to your models. Squashing these migration scripts into a single "initial" migration is good for your sanity, and results in a leaner git repository. I didn't find the process of squashing your alembic migrations to be well-documented online, so here's my version.
 
 # Squashing _Some_ Migrations
 

pelicanconf.py

@@ -45,3 +45,6 @@ FEED_DOMAIN = 'https://ant.sr'
 
 MENUITEMS = (('Resume', '/media/resume.pdf'),
     ('Code', 'https://git.xhost.io/anton'),)
+
+PIWIK_URL = 'analytics.ant.sr'
+PIWIK_SITE_ID = 4

theme/templates/analytics.html

+{% if PIWIK_URL and PIWIK_SITE_ID %}
+    <script type="text/javascript">
+    var _paq = _paq || [];
+    _paq.push(["trackPageView"]);
+    _paq.push(["enableLinkTracking"]);
+    (function() {
+        var u=(("https:" == document.location.protocol) ? "https" : "http")+"://{{ PIWIK_URL }}/";
+        _paq.push(["setTrackerUrl", u+"piwik.php"]);
+        _paq.push(["setSiteId", "{{ PIWIK_SITE_ID }}"]);
+        var d=document, g=d.createElement("script"), s=d.getElementsByTagName("script")[0]; g.type="text/javascript";
+        g.defer=true; g.async=true; g.src=u+"piwik.js"; s.parentNode.insertBefore(g,s);
+    })();
+    </script>
+{% endif %}

theme/templates/base.html

@@ -86,5 +86,6 @@
     {% endif %}
     {% endblock %}
     <script src="{{ SITEURL }}/theme/js/script.js"></script>
+    {% include 'analytics.html' %}
 </body>
 </html>