#shopify Christmas party was a blast. As evidence, I am typing this on my new iPad 2

— David Underwood (@davefp) December 18, 2011

I’ve been wanting to do something ‘cool’ with it since then, but until now I hadn’t found the right project. Then earlier this week I came across Geckoboard, a neat app that allows you to create Panic-like status boards to monitor all sorts of interesting stats.

I decided I wanted to use it to create a living room dashboard that pulls in my calendar events, the current time, the weather, and maybe a todo/shopping list. I would then place my iPad somewhere prominent and have all the info available at a glance.

Mixing Business and Pleasure

Unfortunately for me, most of Geckoboard’s built in widgets are integrations with business oriented services: Github, Basecamp, Pingdom, that sort of thing. Whilst these would look great in an office lobby, I don’t think my wife would appreciate live uptime stats in our living room. Time to improvise!

Geckoboard has this concept of custom widgets which allows you to shoehorn any data you can get your hands on into various predefined templates for display. There are a range of different chart types available, as well as maps, numerical displays, and plain text.

I decided I was going to get my feet wet by creating a weather widget that would display the current temperature along with the conditions. This would be represented in a custom plain text widget.

Sourcing the weather data turned out to be really easy. Yahoo has a fantastic weather API which is free to use for non-commercial purposes that works by simply sending a request with your location to a particular endpoint. The hardest part (which is still dead simple) is looking up your ‘WOEID’ (short for Where On Earth ID), a numeric ID for your location.

WOE Is Me

With my WOEID in hand, it was time to wrangle the data. I created a new Rails project with a simple endpoint that took an ID and spat out the weather data for that location. With a little help from the xml-simple gem I then refined the response to include only the data I needed (The temperature and the condition text) before re-wrapping the response in json to be returned. This was maybe half a dozen lines of code in my controller. In fact, Rails is probably way over the top for something like this but it’s what I have the most experience with so I went with it anyway.

I created an app on Heroku to host everything, and then tried it out. Here’s what the widget looks like (excuse the boring Ottawa weather):

Really simple, but exactly what I wanted. I liked it so much that I decided to share it. Head over to the app on Heroku for instructions on how to use it yourself: Gecko-Weather.

I’m planning on adding a couple of extra features soon, namely the ability to specify Fahrenheit/Celsius and some error handling in case the weather info is unavailable for some reason. I’m also open to suggestions, so please post any requests in the comments!

“Microsoft manager Paul Maritz sent Brian Valentine, test manager for Microsoft LAN Manager, an email titled “Eating our own Dogfood”, challenging him to increase internal usage of the company’s product.” – Wikipedia

I’ve been at Shopify for the better part of a year now, so I thought it was about time that I engaged in some dogfooding of my own. The result has just gone live: The Noble Pony

Giving Myself a Crash Course In E-Commerce

Setting this up was a bit trickier than if I worked at, say, Facebook. Shopify is not a service unto itself, but rather an tool that forms part of a much larger chain: running an online shop. Before I even signed up for a Shopify account I needed several things:

1. An audience
2. A product
3. A business plan
4. Funding

After considering some alternatives I decided that I would sell T-shirts with my own designs on them. This was because all the creative work could be done by one person (me) at my computer using free software (Inkscape). I could then take the designs I came up with to a local printer who would handle the manufacturing. As for an audience, I was primarily designing for myself. However, I knew that I would have to publicize my products somehow and so picked interests of mine that had strong communities I thought I could market to.

My business and funding plan are very closely linked. Due to the way T-shirts are printed, it only makes sense to order them in bulk. Economies of scale and all that. Putting my own money up to fund an initial printing run would be too risky, so I’m running the shop on a pre-order basis: People promise to pay for shirts, and if enough people are interested then I do the print run and ship the shirts. If not, oh well. I cancel the orders and no-one loses out (except my hopes and dreams of striking it rich).

Getting Set Up With Shopify

Once I had a design for a shirt, investigated the production costs, and decided on the business plan I got to work and set up The Noble Pony, my very own Shopify shop. The actual mechanics of doing this I’ll cover another time, but the main elements I needed were:

1. A storefront design
2. A payment processor
3. A fulfillment/shipping solution

I went as bare-bones as possible by tweaking a Shopify theme called Solo for the storefront and setting up PayPal Express Checkout for my payment processor. I’ll be handling the fulfillment side of things myself so I did some research into Canada Post rates and set a couple of weight-based flat rates accordingly. The shipping setup was the hardest part by far as I initially went through the process of setting up an account with UPS only to find out that shipping really small/light packages with them was way too expensive (Shipping the shirts would have cost more than the shirts themselves).

The Finished Product

So what have I actually created? I threw around a couple of ideas about Reddit-related shirts as well as Starcraft-related shirts. Then I played with Inkscape until I finally came up with this:

If you’ve ever played Starcraft 2 you’ll recognize this instantly: It’s a group of the battle.net league icons. There’s a little more to it than that though. The shirt itself looks like this:

The design is supposed to mimic the way a soldier wears his or her medals or ribbon bar. Plus I think it looks cool.

What’s Next?

My goal is to have 100 pre-orders by the end of January. Since opening the shop and announcing it on /r/starcraft two days ago I’ve pre-sold a grand total of… 2 shirts. Clearly the age of ‘If they build it, they will come’ is long over. My next task (and the subject of my next blog post) is to learn as much as I can about publicity and advertising and sell the hell out of the shirts. I’ll report back with my findings.

Note: Mad props to ~JovDaRipper for creating the brilliant T-shirt templates. Go check out his gallery on DeviantArt.

Here’s a link to the repo: https://github.com/davefp/Limelight

The good news is that I’ve made considerable progress over the last six weeks overhauling the back-end to make it easier to maintain and expand. I’ve also learned a lot more about relational databases in the process, which is good for me if not the plugin users.

The bad news is that this process isn’t finished yet, so it’ll be a little while longer before there is a new version available. I hope that anyone out there who is waiting for a new release isn’t too disappointed.

In terms of functionality, I’ve updated the API requests to grab all the tickets for a project, instead of just the first ‘page’:

Still, not to worry. To avoid confusion and general awkwardness, I’m going to change the name of the app to Limelight. I’m pretty sure that there are no existing apps in the same domain with that name. Pretty sure. Not 100%. So if there are any app developers out there developing a Lighthouse app called Limelight… I’m sorry in advance. Hopefully I’ll be ok this time though.

I’m going to release a new version of the app with the changed name in the next couple of days.

Lighthouse is a lightweight hosted bug-tracker produced by entp. It’s advertised as “Beautifully Simple Issue Tracking”.

Lighthouse Keeper is a small AIR app produced by me. It allows you to export Lighthouse ticket info to a csv file.

Background

I learned about the existence of Lighthouse earlier this week at a job interview. I’ve used a couple of bug-trackers before, but Lighthouse had never appeared on my radar. The two guys interviewing me got into a spirited conversation with each other about the various pros and cons of different bug tracking solutions, but Lighthouse in particular. One of their comments was

I wish there was a way to export my tickets as a csv file.

Maybe someone will come up with something using the API.

That’s a challenge if I’ve ever heard one.

Implementation

I’m a big fan of Flash/Flex, so I set to work that evening on a small app that would grab Lighthouse projects for a given domain then allow you to perform searches on the tickets in an individual project and export the results. Fortunately, flex is designed around tasks just like this.

Lighthouse has a fairly comprehensive REST API available for developers. Using either your regular login info or a generated API key, you have access to (as far as I can tell) all of the functionality you get from the regular web interface.

Thanks to this, retrieving data from the API was achieved in less than an hour, and then the rest of the time (about 6 more hours) was spent wrangling it and tweaking the interface.

The current incarnation is still very much an experimental product, but I want to release it to let people (and prospective employers) test it out and see what they think.

Download

So, without further ado, here it is:

Lighthouse Keeper version 0.1

As always: Questions, comments, suggestions and criticism are welcomed and encouraged.

It seems though that there is still interest in the plugin, so over the next few weeks I’m going to give it an overhaul. It’s been a long time coming, and since I first wrote the original code I’ve learned a lot about the ‘correct’ way to program web apps.

The current code is not very flexible: In order to implement the new features that are in the roadmap, I’m going to have to start again from scratch. This time I’m going to give the plugin a proper DB back-end, so that reaction text can be updated without resetting the count, and so that posts in different categories can have different reaction options (and a lot of other things, too!). This should also make it a lot easier to maintain and add further features to.

So, if you use wp-reactions, or are holding off until some of the features you want are available, rejoice! I expect to have a new version available by the end of the year.

I recently started playing Dungeons & Dragons (4th Edition) after listening to the podcasts Penny Arcade did at Wizards of the Coast (who publish D&D). I’m DMing the Keep on the Shadowfell campaign for a bunch of other new players. We’re all thoroughly enjoying it. And yes, that makes us all thoroughly nerdy.

I don’t have very many miniatures, which is a problem because 4th Edition relies heavily on moving characters and monsters around on a grid during combat. There are many alternatives (such as Lego men, dice, or other small objects), but I wanted something a little slicker. I wanted my game pieces to have a uniform look and feel, and not break the immersion by forcing the players to think too much about what each item represented:

“Ok, so the quarter is a goblin, and the dime is an orc. No wait, the dime is the goblin, and the quarter is the orc. Got that? Oh, and 3 more goblins appear from around the corner. Does anyone have any change?

I had a look round online for ideas for replacements, and found several people had made their own tokens using images found around the web. To be honest I was disappointed by these, as they were usually mismatched and of dubious quality. I needed a better solution.

This is how I came to design my own tokens to use in place of miniatures for D&D. I spent some time learning how to use Inkscape (which is an excellent piece of software, btw) and came up with some generic token designs that can be adapted to represent many different monsters. Here are some samples:

The basic design is this: The monster’s name is printed round the edge of the token, their race is represented by the upper icon, and the monster’s role is the lower icon. The roles in the sample are (clockwise from top left) Soldier, Swarm, Minion and Artillery.

Interestingly, some experienced players I’ve recieved feedback from already have said that I’m providing too much information to players by putting the monster names and roles on the tokens. I would definitely like to hear from anyone who plays D&D or other role playing games what they think about this.

Once I have finished running my current campaign, I plan on putting together a pdf with all the tokens in and releasing it under a Creative Commons license. This would just be a first stage, however. Eventually, I want to have an online generation wizard that allows people to create their own tokens from the templates, put them in a pdf and print them for their own use. This may take some time, as I have no idea how to programatically create/edit svg files. Cross your fingers, and maybe a few months down the line you’ll see something along these lines appear.

A quick Google search revealed this: Marquee Component. Fantastic! One of my favourite things about working with flex is that there’s a huge community out there who have already written the component you need in 90% of cases.

Still, I needed to adapt the component to fit my needs. The ‘secret project’ involves a media player, and the marquee was for the song title. I wanted it to display the artist and title at a fixed width, but scroll back and forth if the text was too long. I call it a ‘bounce’ marquee. Here’s the demo.

The first modification I made was to change the way in which the component defined the movement. The original marquee had a property defining the duration of the scrolling. This was unsuitable because it meant that longer text scrolled faster. Make the string long enough, and the text would scroll past too fast to read. Instead, the bouncing marquee has a scrollSpeed property that defines the speed in pixels per second. The length of the string (in pixels) is divided by this number to produce the duration of the scroll, which is then passed to the Move effect.

Secondly I changed the effects to match my desired behaviour. I simply defined to Move effects with Pause effects between inside a Sequence. The first move takes the text from it’s initial position to and scrolls it until the end of the string can be seen. The second move takes it back. The length of the pauses can be changed by overriding the pauseDuration property on the component.

This was all well and good, but there was still a problem. Updating the properties of an Effect whilst it’s playing does not take effect until the effect is stopped and restarted. Therefore I needed a public update() method to be called that would reset the effects and allow the changes to take place.

All in all I’m pretty pleased with how the component turned out. The hardest part was figuring out why the effects weren’t updating properly when I changed the text. It seems there was a timing issue that judicious application of the validateNow() method fixed. For the curious, here’s the code for both the component and the demo:

• Bounce Marquee version 1
• Bounce Marquee Demo version 1