This is what I came up with. It’s simple to use, inexpensive, and flexible enough to work for different clients. You can customize the slideshow, changing the slide duration, transition effects, tooltips and more.

Development

The development process was pretty smooth, owing a lot to Shopify’s rails app generator. I was a little dubious of their “Build a Shopify app in 8 minutes” video, but after I actually followed the directions it went speedily.

In addition to the generator, there is the Shopify API client for ruby and a nice set of MongoHQ, who run a hosted MongoDB platform. I wanna write up the whole MongoDB bit, but suffice it to say that it went well, and MongoHQ was great to work with when I has support issues.

Shopify Application Approval Process

There has been plenty of negative buzz about Apple’s AppStore, basically coming down to longer release cycles and finicky reviewers, so I was interested to see how Shopify handled this. The slidehow app is pretty tiny, and very different than most of the other existing apps in the Shopify app inventory. There are many integrated shipping solutions, order fulfillment services, accounting platforms, and that sort of thing. There are very few UI apps.

My app, to my surprise, was approved in under 24 hours. The Shopify team pointed out two bugs to fix, and after those were done, the app was approved. I was so excited I tried the app out on the RaRu Design site immediately, only to find a few show-stopper bugs. After fixing those, and getting some good customer feedback, I was off to the races.

I thought I would be a hundredaire within the month, but it took about 5 product installs to realize that I actually had to code the billing charges. Once I realized my mistake, I added the necessary snippets of code to actually charge my customers.

Bad Review

Within a day of publishing the app, I received a rock-bottom 1-star review. Ugg. The reviewer didn’t find fault with the slideshow app; they were more concerned with that Shopify had let through an app that was ‘faceless’ and didn’t really seem to have anyone or any company behind it. It is a little scary; giving API access in Shopify is currently all-or-nothing (read or read-write actually). Even if an app only needs read access to product images, it is given read access to customers and orders. I worked with the reviewer to provide some feedback to Shopify that would keep both customers and developers happy with the platform.

Stricter App Guidelines

A few days ago, I received an email from the same fellow who approved my app in the beginning. He asked me to remove all references to Shopify from the branding of my app. This makes sense. I unimaginatively named my app ‘Shopify Product Slideshows’ at first (to be migrated to an equally unimaginative ‘Easy Product Slideshows’). Even the Shopify rails generator includes Shopify branding (at the time of writing), which will not pass the approval process. I understand that they may not have thought of everything up front, but it would be nice if the requirements were spelled out somewhere.

Overview

I dig Shopify’s API, their open-source mindset, and their quick+painless approval process. For the sake of the customers and developers, however, they could step back and think it through a little bit more. Specifically, more thorough QA, thinking through the branding requirements ahead of time, and more granular API access would be nice.

Have munin send alerts to a Jabber server.

Why

Email is great for interpersonal communication, but it doesn't make sense as the medium for every communication that crosses your path. It is confusing to interleave emails from people (that need responses) with email alerts sent from servers (which never need an email response). While both of these messages are important to know about, they are different forms of communication, and should be treated a such.

An XMPP server is a good way to handle alerts because 1) it is sandboxed from other communication (i.e. email), 2) it integrates easily with human workflows (IM), 3) other people and programs can easily listen in.

How

Here's the gameplan:

1. Setup Jabber server (PartyChatApp)
2. Setup Jabber client (Gmail)
3. Create ruby Jabber script
4. Configure Munin
5. Test Munin

The first step is to setup a Jabber server that you can send messages to. Party Chat is a simple and free way to create a Jabber enabled chat room. Party Chat has several cool and silly features. Most importantly, Party Chat will persist the messages, so even if you log out for the night, the full transcript will be available to you when you log back on. This is essential for keeping track of whats going on.

Anyway, so create a PartyChat room with a name you'll remember.

• xmpp4r-simple
• xmpp4r

Here are some additional resources about Munin alerts:

• Munin - How to Contact
• Munin- Alert Variables

Now, wait a few minutes, and you should have those Munin alerts popping up in the PartyChat window.

Bonus Round

See how you can use some of PartyChat's features to add some more value to your alert system. Maybe check the messages for 'Critical' or 'Warning' and use PartyChat's plusplusbot to keep track of how many warnings/criticals have been issued.

Or, pass Munin variables to the ruby script in order to make the message prettier.

10.3.8 307 Temporary Redirect

The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI.

If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

Blahdity blah blah. So while 302's force the redirect location to be requested with a GET, 307's are able to redirect with a POST request. Buuut, there are a couple of caveats. 1) Redirection of POSTs should not be automatic, due to the security issue, and 2) in real life not everybody actually knows how to handle a 307 *Ahem*, I'm looking at you Internet Explore.

Example

Here's a quick PHP example to get us going.

Rockin' it with CURL:

nick-stielaus-computer-3:~ nick$ curl -L -F "file=@Desktop/shortVids/sheep.flv" http://127.0.0.1:1234/pluggd/upload_redirect/form.php?do_a_redirect
Upload: sheep.flv
Type: application/octet-stream
Size: 174.1796875 Kb
Stored in: /private/var/tmp/phpRYQVYc

And FireFox's nice message:

How FireFox handles a HTTP 1.1 307 Response

Credits

A Stack Overflow discussion got me going on this.

That's about all there is to it. Toss it in your ~/.bash_login thusly:

And you can access it like this:

Turning of the RI and Rdoc documentation speeds up gem installs. Here, installing capistrano without docs takes about 11 seconds, whereas installing the documenation more than doubles the time to about 24 seconds.

If you want to turn off the documentation options, add this line to your ~/.gemrc file:

So that it looks something like this:

Testing this compression can be a little tricky, because often clients handle it so seamlessly you may not know it ever happens. Additionally, server configuration may further complicate testing, compressing data for some requests and not others, i.e. Nginx's gzip_http_version directive, which may only serve compressed data for HTTP 1.1 requests.

Curl provides a simple tool for checking server responses.

First, a few curl arguments that will come in handy:

• "--silent" prevents curl from showing progress meter
• "--write-out 'size_download=%{size_download}\n'" instructs curl to print out the download size
• "--output" instructs curl to throw away the output, sending it to /dev/null

Using these arguments, we can make a simple request for a path on the server:

Here, you can the response was 31032 bytes. Next up, lets make the same request, this time adding the Accept-Encoding header to ask for compressed content.

Nice! This downloaded only 2553 bytes of data, so it the data is definitely being compressed. Up next, lets try making the request a third time, now making the request a HTTP1.0 request.

This response was not request, which makes sense when using Nginx with the gzip_http_version set to '1.1'. Additionally, this method can easily be applied to POST requests if you add the appropriate arguments to curl.

References:

• Nginx Http Gzip Module
• Apache mod_deflate
• Mod Deflate example/logging
• Curl homepage
• Curl man page

Dirty Bird!

]]> http://dev.nuclearrooster.com/2009/08/07/murder-turtle/feed/ 0 http://dev.nuclearrooster.com/2009/08/07/going-to-gem-med-school-open-source-ruby-projects-with-dr-nic-williams/ http://dev.nuclearrooster.com/2009/08/07/going-to-gem-med-school-open-source-ruby-projects-with-dr-nic-williams/#comments Fri, 07 Aug 2009 07:11:37 +0000 nick.stielau http://dev.nuclearrooster.com/?p=143 Grooving with Dr. Nic, and digging in to some projects

Going with the Flow

Despite my feelings that the title Dr. should be strictly reserved for those that save lives, Dr. Nic Williams does have plenty of good advice to offer (and he offers it in a nice format on his website). After having made some of the same mistakes and asked the same questions he has, I decided to try out the new and improved open-source project workflow. There are several things to be achieved from these open-source projects:

• Have fun
• Learn something new
• Share code

There are also some thing that should be avoided, less favorable outcomes:

• Write code, but don't go the full 9 yards to distribute + share it
• Spend too much time on setup/distribution
• Tie yourself down with maintaining your projects (they should set you freeeeee!)

Two great presentations can help you achieve these goals, and avoid the pitfalls. The first is a a great presentation about what an open-source project should be, what it shouldn't be, and how they can make your life better, not worse.

The next presentation is about how to quickly and effectively distribute and share your projects.

In order to get this all down, the good Dr. describes a workflow and a set of tools for each step.

• Packaging - RubyGems
• SCM - GitHub
• Continuous Integration - RunCodeRun
• Blog/Resume Integration - RunCodeRun Sexy Blog Badge

The Project

I decided to write a little ruby wrapper for the 'ddate' command, part of the 'util-linux-ng' package, that convert Georgian dates to Discordian dates. Why? Because I like it, and if you are going to pick a project to learn on, it might as well be ridiculous. I got attached enough as it was to this project, even though I don't think anybody could come up with an excuse to use Discordian dates, let alone happen to be using ruby.

Snafoos

One thing that started to bug my is the gem, class, module, and github repository names. It seems simple enough, but sometimes you are so excited to get you idea down in code that you rush through this first step. It will be around for a while, and is kind of a pain to change once you get it all set up. So take a few minutes and think about a name. One without WeIRd caps or anything that might annoy you in the future.

I also found newgem to be a little wonky. It a nice tool to have around, but I think (rightly so) it is tailored to Dr. Nic's workflows, and might not work for everybody.

Lastly, I found myself wresting with Hoe. The 'rake pacakge' task was failing if I added the Hoe require statement, and runcoderun was failing without the statement. That brings me to a little tangent. I didn't really dig into what was going on there, but this is an example of something that is unexpectedly not idempotent; you should be able to require and require and require, then run some code and everything should be fine and dandy. I'm not sure how or why requiring Hoe (when it is clearly used, anyway) would break anything, and it almost annoys me enough to find out. Almost.

Good stuff

I like RunCodeRun. It is simple continuous integration that makes sense. I also like the blog badge, although it currently looks horrible on my blog.

Stuff I'll add

Speaking of blog badges, I want to see if I can get the github projects blog badge working. Associating myself with a project is another step for creating a fully-rounded project. This badge helps integrate that step right into the existing workflow.

For learning projects, I plan on adding some non-standard notes to the README, including sections about what I learned and what would have done differently. Open source the code, and open source the learning process. Its not like I have any customers to scare away with honest comments.

As Nic Williams said, "Don't attach your self-worth to your code - your code probably isn't that good." Its true. I am a better software developer than I am a coder, and I aim to be. You can write code quite a few different ways and it all compiles down to the same thing. To me, nailing the workflow and the tools is the hard part, and the part that deserves the most attention.

Working with software, your code will always improve and you will keep learning new tricks. But too many people let their workflow and tool-set become stagnant, which can leave you further behind than knowing a few extra tricks in this language or that one.

Not sure why this is, but for me there was a pretty easy work around to checking for a 0 byte file; start reading the lines from the file and break after you read the first line to tell that the file is not empty.

OS X 10.5.7

Ubuntu 8.0.4

Red Hat Enterprise Linux ES release 4 (Nahant Update 6)

Mr T Pitties the fool who is still using RHEL4

Despite the fact that RHEL4 was initially release on the first day of my life I could legally drink a brew, or maybe because of that fact, I am bitter about RHEL 4. A single dog year is comparable to 7 human years, right? So what is one linux year? Should it be measured in the man-hours of code committed to the kernel and distribution? Should it be measured in man-hours of time wasted by the meat-cloud trying to do simple tasks like building and installing libraries? If you're lucky, you aren't inclined to try to measure it at all.

Ubuntu? Delcious! RHEL4? Not so yummy. (but its a date thing, not a distribution thing)

From Wikipedia:

Red Hat Enterprise Linux 4 (Nahant), 2005-02-15. Uses Linux 2.6.9

* 4.1, also known as Update 1, 9 June 2005[8]
* 4.2, also known as Update 2, 5 October 2005 (Release Notes)
* 4.3, also known as Update 3, 7 March 2006 (Release Notes)
* 4.4, also known as Update 4, 11 August 2006 (Release Notes)
* 4.5, also known as Update 5, 1 May 2007 (Release Notes)
* 4.6, also known as Update 6, 15 November 2007 (Release Notes)
* 4.7, also known as Update 7, 24 July 2008 (Release Notes)
* 4.8, also known as Update 8, 18 May 2009 (Release Notes)