Code

My wife and a friend run The Crafty Coop (edit: now closed) – an event planning business that also sells handmade party decorations/favors online and at craft shows. One of the ways I help out is as the designated “IT guy” by handling the web/email hosting and other technical stuff.

When we were initially setting up the website using WordPress we looked for a widget that would generate a listing of their Etsy shop items but we weren’t really happy with the ones we found – they either required that the Etsy shop be broken up into sections or they didn’t quite display the way we wanted. I decided to try to write my own instead of tweaking one of the existing ones and Etsy Shop Widget was born.

I decided early on that I wanted to avoid generating the HTML in PHP as much as possible. I knew I’d have use some PHP for the WordPress admin settings but I wanted to use a front-end framework for the widget itself. I was already using Vue.js in other projects so when I found a template project for creating a WordPress plugin that used Vue.js I was good to go.

The Etsy API requires an API key and is rate limited so I wanted to cache the results rather than fetch them each time the page loaded. I added standard WordPress settings for the API key, the shop name, and the cache time and put them all in a settings section.

Right now this limits the widget to only one shop per WordPress installation but that’s all we need right now. In the future I’ll move the shop name to an attribute of the widget instead.

On the back end I created a custom WordPress action that uses the WordPress transients API to store the cached data from Etsy. Basically if get_transient returns some data then that data is simply returned to the caller, otherwise wp_remote_request is used to make the call to the Etsy API and the returned data is stored using set_transient with the appropriate cache duration.

function ESW_Listings_request()
{
    $listings = get_transient('etsy_shop_widget_listings');

    if ($listings === false) {
        $options = get_option('ESW_settings');

        $response = wp_remote_request('https://openapi.etsy.com/v2/shops/' . $options['ESW_Etsy_Shop_Name'] . '/listings/active?includes=MainImage&api_key=' . $options['ESW_Etsy_API_Key'] . '');

        $listings = $response['body'];

        set_transient('etsy_shop_widget_listings', $listings, $options['ESW_Cache_Time'] * 60);
    }

    echo $listings;

    die();
}

add_action('admin_post_esw_listings', 'ESW_Listings_request');
add_action('admin_post_nopriv_esw_listings', 'ESW_Listings_request');

The rest of the PHP side is pretty straightforward – there’s an “[etsy-shop-widget]” shortcode that generates an empty div with an ID of “etsy-shop-widget” that is used as the root of the Vue.js application and some code that links the styles and scripts generated by webpack when building the Vue.js code.

The front-end code is currently pretty basic as well. The Vue.js application just makes an AJAX request to the WordPress custom action, stores the resulting data in a component, and then uses the data to render a list of the item names, pictures, and prices.

@Component
export default class App extends Vue {
	listings: Array<EtsyListing> | null = null;

	async mounted() {
		const response = await Axios.get<EtsyResult>(window['esw_wp'].siteurl + '/wp-admin/admin-post.php?action=esw_listings');

		this.listings = response.data.results.sort((a, b) => a.last_modified_tsz - b.last_modified_tsz);
	}
}

<template>
	<div class="esw-listing-container">
		<div class="esw-listing-item" v-for="listing in listings" v-bind:key="listing.listing_id">
			<a :href="listing.url" target="_blank">
				<img class="esw-listing-item-image" :src="listing.MainImage.url_170x135" />
			</a>

			<a :href="listing.url" target="_blank">
				<div class="esw-listing-item-title" v-html="listing.title"></div>
			</a>

			<div class="esw-listing-item-price">
				{{ listing.price }}
				{{ listing.currency_code }}
			</div>
		</div>
	</div>
</template>

At some point I’d like the make the listing a little fancier – maybe with a single image and previous/next buttons rather than a simple scrolling list but we’re happy with the way it is working for now.

One of my most complete projects is Feed Center – an RSS feed reader designed to blend in with the Windows desktop.

Years ago when push technology was the hot new thing I got my online news from applications like PointCast and MSNBC News Alert – but they were eventually discontinued as web sites moved to other delivery mechanisms like RSS feeds. I tried to find an RSS reader but never really found one that I liked. I didn’t want some Outlook lookalike that I had to specifically open and read through. I wanted an app that would blend in with my desktop as much as possible and be something that I could glance at every so often for the latest news. At some point I started fiddling with creating my own and Feed Center is the result.

In theory Feed Center supports all of the common RSS versions and Atom with some special handling for common errors. The fact that I’m parsing the feeds with an XML parser makes it a little harder to handle the edge cases but it works well enough so far.

Feeds are added in a “default” category but they can optionally be organized into any number of other categories. The top of the main window has a selector for the current category – I’m not sure I like the way it looks but I haven’t come up with anything better yet.

The arrows at the top of the window (as well as mouse buttons 4 and 5 if you have them) will scroll through the feeds in the current category in alphabetical order. The current feed will also scroll automatically every minute unless the mouse is hovering over the window – it would be annoying to have the feed change when you’re getting ready to read one.

Double clicking an article will open the web page for the article. By default the system default browser will be used but there’s an option to choose another browser instead. There’s also buttons to open all of the articles for the current feed and to mark all of the articles as having been read.

The code base has had some major changes over the years – originally the UI was done using WinForms and I used XML files as storage. After a few corrupt XML files from power failures I switched to using SQLite and then to SQL Server Compact. At some point I rewrote the UI using WPF so I could get rid of a bunch of custom painting for the feed list.

The project has a full installer created with WiX that uses a modified bootstrapper to automatically relaunch the application after an upgrade.

Other than the code on GitHub I haven’t made anything public yet but I plan to use AppVeyor for build and deployment at some point – probably with the installer served as a GitHub release.

The next project up is LaundryMonitor which uses the most hardware of anything I’ve done so far.

I’d always wanted something that would let us tell if the washing machine or dryer was running but I never knew exactly the right way to detect it. After we got our solar panels I was doing research on how to track power usage and came across an article about current sensors and had the idea that I could hook up a current sensor to each appliance and watch the output voltage to know if the appliance was running. While trying to find a decent sensor I stumbled across a current switch which was more or less the same idea but had everything in one package – when the current was over a certain threshold the switch would close and that could be easily detected.

My first thought was to use a PowerState Tail but only a 120V version was available – there was nothing like it I could use for the 240V of the dryer. Eventually I settled on a Dwyer Miniature Current Switch and I’d use one each for both the washer and dryer just to be consistent.

Next up was to figure out how to monitor the switch. I was going to use a Phidget I/O Board attached to a central server and run wires across the house from the washer and dryer to the I/O board but the idea of running all the wires wasn’t too appealing. I was about to try some sort of XBee setup when I found the C.H.I.P. Kickstarter and it seemed like it was worth a try – the C.H.I.P. was cheap, had digital I/O, had WiFi, and I could use anything that’d run on Linux to make it all work. The full board is probably a bit of overkill for just monitoring two switches but at $9 a device it really didn’t bother me that much.

Hooking up the dryer was relatively easy – I opened the control panel, used the schematic to find the wire that powers the motor, disconnected the wire, ran the wire through the current switch, and reconnected the wire. I mounted the sensor on the back of the dryer for easy access in case I needed to adjust it but the motor draws enough current that the switch was able to detect it easily.

The washer was pretty much the same but I decided to monitor the main power line so I could detect if the washer was running at any point in the cycle. The trouble was that at certain times (like when the washer was filling) the current draw was way too low for the switch to detect even with the sensitivity set as low as possible. I solved this by looping the wire through the sensor several times to amplify the current to the point where the switch could pick it up.

From here on out things were simple – I just had to run some smaller wires from the switch to the digital I/O ports on the C.H.I.P. and then start working on the software. I ended up sticking the C.H.I.P. a few feet away by the power outlet so I didn’t need too long a USB cable to power it.

So far this has been running for a little over two years and the hardware continues to work well. I’m planning to do a similar build to monitor two sump pumps – the only change is that I’m planning to use the PowerState Tail since they’re both 120V with standard plugs so it’ll be a lot easier to hook up.

I’ll cover the software side of the project in my next post – right now the monitor is a standalone service that does all the work but since I’m going to be adding more devices I’m thinking that I need to break things up a bit.

I’m going to take a break from status windows for a little bit to cover my WorkIndicator project.

I’ve been working remotely for almost 14 years now and my family found it hard to tell when I was working or on the phone. It often looks the same whether I’m working or not – I’m sitting at my computer, sometimes with my headset on. At some point I came across a blog post by Scott Hanselman that described hooking up a status light to Lync and I was inspired to create something similar.

The first task was to find something I could use as a status light – after some research I settled on a USB HID Green/Yellow/Red Visual Indicator from Delcom. I liked that it had a stoplight design and it came with a C# sample – perfect!

My main workflow is to connect to my work system using Microsoft Remote Desktop so the easiest way to detect if I am working or not is to look for the remote desktop window. I created a class that uses SetWinEventHook to get ObjectCreate, ObjectDestroy, and ObjectNameChanged events and watch for a window with the title of my remote desktop window. If the window was found I’d set the indicator lights to yellow, otherwise I’d set them to green. Lately I’ve been using a VM as well so I updated the code to be able to look for multiple window titles – if any of them are detected the light is set to yellow.

Originally there was also Skype integration – I was able to use the Skype API to detect if I was on a call and if the call was muted. If I was on a muted call the right light would be on, and if I wasn’t muted the red light would blink. This made it easy for the kids to tell how quiet they needed to be when coming into the room. Unfortunately Skype no longer supports this API (and I’m not using Skype anymore anyways) so I removed this code from the project.

The application also has a tray icon with a menu so I can manually set my status – for example, I can select “talking” and the red light will blink. This is my workaround until I come up with something that’ll work for my current phone setup.