<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Aaron Kuehler</title><link>https://aaronkuehler.com/</link><description>Recent posts from Aaron Kuehler</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 09 May 2019 00:00:00 +0000</lastBuildDate><atom:link href="https://aaronkuehler.com/tags/hardware/rss.xml" rel="self" type="application/rss+xml"/><item><title>Building a Healthy Code Review Culture</title><link>https://aaronkuehler.com/blog/2019/05/09/building-a-healthy-code-review-culture/</link><pubDate>Thu, 09 May 2019 00:00:00 +0000</pubDate><guid>https://aaronkuehler.com/blog/2019/05/09/building-a-healthy-code-review-culture/</guid><description>&lt;div class="plainsummary"&gt;
&lt;p&gt;In short: I share how I think teams should run code review &amp;ndash; not mainly to hunt for bugs, but to share knowledge and become better, more engaged teammates. I offer practical advice for giving and receiving feedback kindly, and for writing clear commit messages and change descriptions that explain why a change was made.&lt;/p&gt;
&lt;/div&gt;
&lt;h2 id="motivation"&gt;Motivation&lt;/h2&gt;
&lt;p&gt;I thrive on critical feedback. Be it from automated tests as I drive the interfaces and interactions of code I&amp;rsquo;m writing or perspective, advice, and coaching from coworkers. Code Review is an opportunity for team members provide critical feedback during the evolution of projects. In some contexts, I&amp;rsquo;ve worked on teams which struggle to extract the true value of Code Review. The following are opinions I use to help teams realize more productive uses of Code Review. This is not a prescription, but rather a set of meditations to encourage a constructive, elevating atmosphere of honest discussion about the work we do.&lt;/p&gt;</description></item><item><title>DIY Baby Monitor</title><link>https://aaronkuehler.com/blog/2017/11/19/diy-baby-monitor/</link><pubDate>Sun, 19 Nov 2017 00:00:00 +0000</pubDate><guid>https://aaronkuehler.com/blog/2017/11/19/diy-baby-monitor/</guid><description>&lt;div class="plainsummary"&gt;
&lt;p&gt;In short: I worried that a store-bought internet baby camera could be watched by strangers, so I built my own using a Raspberry Pi and a camera that can see in the dark. It cost about the same as a cheap camera, but I decide who is allowed to watch and it runs on my own home network.&lt;/p&gt;
&lt;/div&gt;
&lt;h2 id="motivation"&gt;Motivation&lt;/h2&gt;
&lt;p&gt;&amp;ldquo;Daddy, you have to stop talking to me through the camera at night&amp;rdquo; is the phrase which immediately preceded the hurried unplugging and dismantling of the Foscam FI8910W in the children&amp;rsquo;s room. For you see, I had never used the two-way audio functionality of the device. It&amp;rsquo;s a hard pill to swallow, you&amp;rsquo;re supposed to be their protector but you&amp;rsquo;ve potentially invited the faceless stranger into their bedroom. Such was my experience. We, like many parents looking to avoid an outrageously priced video baby monitor, purchased the Foscam &lt;abbr title="Internet Protocol"&gt;IP&lt;/abbr&gt; night-vision camera to remotely keep an eye our child at night, and at nap time. We locked the thing down, allowing &lt;abbr title="Local Area Network"&gt;LAN&lt;/abbr&gt; connections to the video/audio stream. It&amp;rsquo;s hard to say for sure if an outside party actually gained access to the Foscam device, but the question alone is enough to make any parent yank the device from the wall and put it in a sound and light proof hole in the ground. After all, &lt;a href="https://krebsonsecurity.com/2014/01/bug-exposes-ip-cameras-baby-monitors/"&gt;security issues with IP cameras and WI-FI baby monitors&lt;/a&gt; are documented. So what&amp;rsquo;s a parent to do?&lt;/p&gt;</description></item><item><title>Literate Dotfiles</title><link>https://aaronkuehler.com/blog/2017/10/04/literate-dotfiles/</link><pubDate>Wed, 04 Oct 2017 00:00:00 +0000</pubDate><guid>https://aaronkuehler.com/blog/2017/10/04/literate-dotfiles/</guid><description>&lt;div class="plainsummary"&gt;
&lt;p&gt;In short: I keep my personal computer setup files, called dotfiles, in one document that mixes plain-English notes with the actual code. A tool named Babel then pulls the code out to build the real files on my machine. I have used this for a few months and find my setup much easier to read, understand, and change with confidence.&lt;/p&gt;
&lt;/div&gt;
&lt;h2 id="motivation"&gt;Motivation&lt;/h2&gt;
&lt;blockquote&gt;
&lt;p&gt;Let us change our traditional attitude to the construction of programs:
Instead of imagining that our main task is to instruct a computer what
to do, let us concentrate rather on explaining to human beings what we
want a computer to do.&lt;/p&gt;</description></item><item><title>Installing Coreboot</title><link>https://aaronkuehler.com/blog/2015/09/20/installing-coreboot---lenovo-thinkpad-x220/</link><pubDate>Sun, 20 Sep 2015 00:00:00 +0000</pubDate><guid>https://aaronkuehler.com/blog/2015/09/20/installing-coreboot---lenovo-thinkpad-x220/</guid><description>&lt;div class="plainsummary"&gt;
&lt;p&gt;In short: I replaced the locked factory start-up software (the BIOS) on my Lenovo ThinkPad X220 laptop with free, open software called Coreboot. I used a Raspberry Pi wired directly to the laptop&amp;rsquo;s memory chip to write the new software onto it, and I also switched off a hidden Intel feature that could let outsiders control the machine.&lt;/p&gt;
&lt;/div&gt;
&lt;h2 id="motivation"&gt;Motivation&lt;/h2&gt;
&lt;p&gt;When not at work, I primarily use a Lenovo Thinkpad x220 with Debian GNU/Linux. Recently, the factory installed wireless card failed. I purchased a replacement wireless card from &lt;a href="https://thinkpenguin.com/"&gt;Think Penguin&lt;/a&gt; and quickly found that the factory &lt;abbr title="Basic Input/Output System"&gt;BIOS&lt;/abbr&gt; prevents the use of non-whitelisted hardware. I took this as a challenge to see if I could work around the freedom limiting factory BIOS.&lt;/p&gt;</description></item><item><title>Design Effective Interviews</title><link>https://aaronkuehler.com/blog/2015/05/14/design-effective-interviews/</link><pubDate>Thu, 14 May 2015 00:00:00 +0000</pubDate><guid>https://aaronkuehler.com/blog/2015/05/14/design-effective-interviews/</guid><description>&lt;div class="plainsummary"&gt;
&lt;p&gt;In short: I interview candidates by weighing both their technical skills and their people skills. Instead of directly asking the three things I most want to know &amp;ndash; can they do the job, will they improve the team, and will they be happy here &amp;ndash; I ask for concrete examples from their past and look for patterns. I try to keep candidates comfortable, stay honest about my organization&amp;rsquo;s strengths and weaknesses, and treat each interview as practice to get better.&lt;/p&gt;</description></item><item><title>Raspberry Pi Temperature Sensor</title><link>https://aaronkuehler.com/blog/2014/12/01/raspberry-pi-temperature-sensor/</link><pubDate>Mon, 01 Dec 2014 00:00:00 +0000</pubDate><guid>https://aaronkuehler.com/blog/2014/12/01/raspberry-pi-temperature-sensor/</guid><description>&lt;div class="plainsummary"&gt;
&lt;p&gt;In short: I wired a small temperature sensor to a Raspberry Pi, wrote a short Python program to read the temperature once a minute, saved the readings in a time-series database (InfluxDB), and drew a live graph of them with Grafana.&lt;/p&gt;
&lt;/div&gt;
&lt;p&gt;A few weeks ago, I purchased a Raspberry Pi. After reading &lt;a href="http://www.amazon.com/Raspberry-User-Guide-Eben-Upton/dp/1118921666/ref=sr_1_1?ie=UTF8&amp;amp;qid=1417487615&amp;amp;sr=8-1&amp;amp;keywords=raspberry&amp;#43;pi&amp;#43;beginners&amp;#43;guide"&gt;Eben Upton&amp;rsquo;s Book - Raspberry Pi User Guide&lt;/a&gt;, particularly the two chapters on which he focuses attention on the &lt;abbr title="General-Purpose Input/Output"&gt;GPIO&lt;/abbr&gt; pins, I had an idea for my first project. The post covers the first iteration of a home temperature monitoring project I put together using a Raspberry Pi, a &lt;a href="https://www.adafruit.com/products/1782"&gt;MCP9808 Temperature sensor&lt;/a&gt;, an old Mac Mini (early 2008), &lt;a href="http://influxdb.com"&gt;the InfluxDB time series database&lt;/a&gt;, &lt;a href="http://grafana.org"&gt;Grafana time series visualization applcation&lt;/a&gt;, a bit of &lt;a href="https://www.python.org"&gt;the Python programming language&lt;/a&gt;, and &lt;a href="http://smarden.org/runit/"&gt;the runit init system&lt;/a&gt;.&lt;/p&gt;</description></item><item><title>iOS Environment Variables</title><link>https://aaronkuehler.com/blog/2014/07/12/ios-environment-variables/</link><pubDate>Sat, 12 Jul 2014 00:00:00 +0000</pubDate><guid>https://aaronkuehler.com/blog/2014/07/12/ios-environment-variables/</guid><description>&lt;div class="plainsummary"&gt;
&lt;p&gt;In short: I show a cleaner way to handle the settings an iOS app needs &amp;ndash; such as which web address it should talk to &amp;ndash; by moving them out of the code and into a separate file that lists the right values for each build. At startup the app checks how it was built and loads the matching settings, so I can change configuration without touching or breaking the app&amp;rsquo;s code.&lt;/p&gt;</description></item></channel></rss>