Now, I’ve been using SO almost constantly since it started. It’s probably the best general resource for answering programming questions on the internet. What I haven’t really been doing until recently is contributing.

Why contribute? Well first off, I have legitimate answers to some of the questions on there. Helping other people out with understanding their code is lots of fun. But there’s more to it than that.

Answering questions on SO helps my code review skills. There’s a big gap between knowing the answer to a question and clearly explaining it, especially without speaking about it in person. It’s really hard to leave a good answer without going over 10 lines.

I wasn’t initially expecting this, but I also get my code reviewed. People will comment on my answers to suggest optimizations, point out mistakes, or just agree with my solution. All of these help me to write better code.

It also helps me learn. Because I want to give good answers, I commonly double-check my solutions before submitting my responses. I spend about as much time in the Rails docs as I do writing text. This reinforces my own skills and often teaches me something new that I didn’t know before.

The last thing I do is pick questions that I don’t know the solution to, and then try to solve them. I’ll create a new Rails project, add the code from the question, and then work through it until the problem is resolved. This is pure learning for me, with the bonus that I can pass my findings onto others.

If you do any kind of coding, I’d recommend contributing to Stack Overflow. Not only will you be helping others, it’ll make you a better programmer.

About a week before I published my last blogpost on Who Goes First the first version of the app was posted on Reddit by a friend of mine. His title was ‘App made by a colleague of mine‘.

I was surprised by the comments. Here are a couple of them:

Is this an app? It seems just like a website.

Well, the new cool thing is to call a page in “the cloud” that does one specific thing a “web app”…

Yeah, it’s annoying. I was expecting a link to iTunes or one of the Android markets.

I have no doubt that Who Goes First is a (web)app, not just a website. It also runs well on mobile devices thanks to Bootstrap’s responsive design, so there’s no need for a native app. Nevertheless, it still didn’t fit these commenters’ definition of ‘app’.

We have similar problems with the Shopify App Store. I think the name is fine, but on more than one occasion merchants have been confused when going there because they’re expecting mobile apps, not webapps. We’ve been considering changing the name to ‘plugin store’, ‘extension store’, or something similar to combat this.

Where does this disconnect happen? I think the problem is context. I, my friends, and my colleagues are all deeply involved in technology and so have a fundamental understanding of how software is designed, developed, and distributed. On the other hand you have the people who consume the software we make. They don’t know the first thing about APIs, application frameworks, software patterns, or anything else that goes into making an app and what differentiates an app from ‘just a website’. They shouldn’t have to, either. The whole point of software is to abstract the complicated parts away from the user so that they don’t have to deal with them.

Who Goes First is a super-simple web app that spits out a random rule to decide who takes the first turn in a board game. It supports user submissions and has a contact form. That’s it.

Gems Used

• randumb
• state_machine
• activeadmin
• bootstrap-generators

The backbone of this app is Active Admin. I love this gem. The documentation took a little while to decipher but once I had a general idea of what was going on it was a pleasure to use. Before using activeadmin I’d always used the console to ‘administer’ my site – creating objects, updating state, that sort of thing. Activeadmin bypasses all of that by providing a proper web interface complete with authentication thanks to devise. It’s just customizable enough to allow complex actions like triggering state changes on objects so it was perfect for Who Goes First as all user submissions need to be moderated before going live.

Randumb is a brilliant little gem that adds a random method to ActiveRelation that does exactly what you’d expect: Pulls and returns a random object from the current relation. I’m using it to grab a single object but you can specify a count if you want more. Very useful.

Bootstrap-Generators provided my layouts. Bootstrap (from Twitter) is a godsend for developers such as myself who hate spending time (and suck at) designing layouts. The generators gem gets everything set up for you and provides basic rails-y templates to get started with. One note if you’re planning on using this gem though: At the time of writing the current release on rubygems.org does not contain the responsive templates, so grab it from the github repo instead. The responsive aspect was paramount for me as I envision people using the app on a smartphone, tablet or whatever at the gaming table.

Finally, there’s state_machine. I used this gem to provide the basis of my moderation mechanism. New user-submitted rules start in a ‘pending’ state and only appear once I move them to ‘approved’. There’s also a ‘denied’ state for rules I don’t want published.

Other things I learned

Heroku has really good mail support thanks to Sendgrid. I was able to hook up my contact form really easily (although my webhost’s mail server bounced the first few messages as the domains didn’t match up. D’oh!).

Activeadmin doesn’t play well with the asset pipeline. The styles and js are hidden away in the gem so I had to explicitly load them in the initializer. Easy once you know how, but it was a pain when I deployed to production for the first time and found that my styles were broken.

What’s next?

I’m pretty pleased with the site as-is at the moment, but I do have some ideas for improvements. The first thing I want to do is add some normalization to new submissions so that they’re all correctly capitalized and punctuated. Right now about half of the submissions have full stops at the end and half don’t which and it’s a pain to go in and edit them all manually.

I’m also considering adding modifiers to the rules. A lot of them refer to the ‘most’, ‘biggest’, or ‘largest’ of something. Detecting these and randomly replacing them with the opposite version (‘least’, ‘smallest’, etc.) would add some free variety to the ruleset.

Actually, it’s not that bad. One of the reasons I took my job was because I enjoy these ‘right brain’ problems. Applying flair and creativity to something as rigid and mathematical as software is incredibly rewarding.

It’s definitely not easy to switch over from left brain to right brain mode. Thankfully, there are some really great resources for software developers like me who are dabbling in unfamiliar territory. Here are a couple that I’ve found useful.

Presentation is Everything

Slide design for developers is a fantastic guide to giving better presentations. I still default to ‘bullet lists and pictures’ way too often when I’m presenting. After reading this article I resolved to start putting some visual punch into my slides cut down on the text as much as possible. From the article:

My slides are not designed for people who didn’t see the talk in person. They’re designed to support my words, not some online audience.

This is something that is easy to forget when writing slides. I never used to write slide notes which resulted in my constantly turning round to read my own slides while presenting them. If you need to read your own slides, you’re doing it wrong. My colleague Edward recently gave an internal presentation rooted in the principles introduced in the article and it was stellar.

Copywriting

We recently designed the Shopify App Store, and part of that involved writing guidelines for developers who are publishing their apps there. After being the App Store custodian for six months I’ve seen my fair share of good and bad attempts at listings. It’s easy to tell them apart, but harder to quantify exactly what a good listing has that a bad one doesn’t. Furthermore, we have to explain these concepts (once we’ve figured out what they are) to developers.

I’ve found Copywriting for Geeks to be a great resource for figuring these things out. It’s got a great guide for doing precisely the kind of writing we’re encouraging our developers to do with their app listings, and helped me to pin down the points I wanted to make. Right now you can get it for free (in exchange for signing up for the author’s mailing list), so I definitely recommend taking a look.

1. Calendar: Built in widget, with custom text size to make it more readable
2. Date and Time: Another built in widget.
3. Weather: Covered last time, it takes weather info from Yahoo and displays it.
4. ToDo List: A placeholder for now, but will display a particular shared note from Evernote that we can fill with important things we need to do.
5. Weasels!: Geckoboard has an image widget, so I wrote an endpoint that looks like a  jpeg but fetches a random image from a person’s Flickr photostream and returns it. Every time the board refreshes, Tada! New image. In our case, it’s usually embroidery or ferrets.

A quick recap: My plan was to sell t-shirts to Starcraft 2 fans. My primary audience for this was /r/starcraft, which has 80,000 members. To this end, I looked into Reddit’s self-serve advertising service.

Reddit advertising works on a proportional bidding system. On any given day, you can place a bid to get your ad shown. 48 hours before the start of that day, they total up all the bids and give your ad a proportion of pageviews equal to your bid’s fraction of that day’s total from all advertisers. So if I bid $50 for a day and so does one other person, we get half of the pageviews each. It’s good in that you get to set your own budget, but the downside is that you don’t know the totals and therefore can’t predict how much exposure your ad will get beforehand.

For my own part, I decided to set up a campaign that ran over a weekend on /r/starcraft with a budget of $50 a day. Here’s how it went:

Ad Stats. The orange line = uniques, blue = total.

You can see from the graph on the left that I got on average 5k unique impressions every hour. Not bad! What’s more interesting is the number of clicks. Initially the clicks were very high indeed, but each subsequent day they decreased. I imagine this is because the same redditors come back every day, and so the ones that have already clicked on an ad won’t do so again next time. I don’t know if this pans out for a longer campaign, but I’m inclined to stick to the short format to combat the risk of stagnation.

I got 12 full coversions (i.e. people placing orders) from the campaign, which if I’d actually converted to sales would have covered the costs of the advertising and netted me some profit to boot. Overall, definitely worth my money.

I have some plans for reviving my shop in the next few months, and when I do I’ll definitely be advertising it on Reddit again. I’ll be posting about it on here if everything goes well.

#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.

Pull

The trouble with forums generally is that they’re not designed to push topics to you; You have to go to them to get updates. This is great if you’re a casual user but when you’re an administrator who needs to read everything that gets posted, it’s a hassle. I had to remember to check the forums constantly. It also meant that regular users weren’t engaging one another as much as we wanted: More often than not initial responses were provided by admins rather than other users.

Push

That’s why we ditched the Shopify developer forums and redirected them to a new Google Group for developers. Mailing lists are by design inherently push-based, so now the messages come to me. There are options to reduce or turn off notifications all together but judging by the number of times a community developer comes to the aid of another it seems that they prefer to get notified immediately.

User Land

I recently had the opportunity to see things from the other side when I delved into the Dropbox developer forums. It only supports RSS updates (boo!) so once I’d posted I had to remember to go back and check for updates. That took me 3 days. The responses I found on my return were great, but if I had been able to track the thread via email I’d have known a lot sooner. I also find myself with no desire to go back and read through topics to answer them.

Alternatives

Google Groups are fantastic, but they’re not for everyone. The Ottawa Android group that I attend uses Libre List which is a far lighter weight solution. A quick google search reveals many more possibilities.

PostCatcher allows you to create a url that serves two purposes:

1. When you POST to it, PostCatcher will record the request
2. When you GET the page in a browser, it displays the previous requests for you to examine

Investigating an unfamiliar webhook is as easy as registering your PostCatcher url to receive updates and then generating some requests. The PostCatcher page will update in real-time with the new data, allowing you to see and examine out the structure easily.

Alternatives

Before PostCatcher I used a similar service called PostBin. It’s written by progrium, who is also responsible for Localtunnel. Unfortunately I’ve found that PostBin is unavailable more often than not due to being over quota, hence the switch to PostCatcher. The latter also benefits from a slicker ui as well as login via. Github allowing you to keep track of your previously created ‘catchers’.