Greg Taylor

EMDR Map Sheds its Snake Skin

2013-04-16T14:40:00-04:00

As a fun exercise, I set out to re-write the WebSocket server behind EMDR Map in GoLang.

The Python version

The initial version of the WebSocket server powering the map was developed with Python, gevent-websockets, and ZeroMQ. While the original Python version was pretty simple, it was much heavier on memory and didn’t free resources very quickly after disconnections. My biggest gripe was that I wasn’t entirely happy with how the Greenlets interacted with one another. Time to needlessly re-invent the wheel for fun and profit!

The GoLang version

After cobbling something together, I found that some resources were saved, but nothing earth-shattering. More importantly, I feel that the channels and goroutines pattern makes a lot more sense for this particular project than my coroutines and internal ZeroMQ sockets.

I apologize for the lack of build instructions or documentation of any sort, but such is the norm for my experiments like this!

See the EMDR Map.
View the project on GitHub.

Linode NextGen

2013-04-09T14:40:00-04:00

As of today, Linode announced the completion of their upgrade effort, dubbed “Linode NextGen“. Upgrading an internaitonal fleet of servers is nothing to sneeze at, but they succeeded with flying colors.

In the last few months, we saw Linode:

Double the amount of RAM per instance
Bump all instances up to eight virtual cores (from four)
Invested heavily in improving their network
Bump instance outbound cap by 5x
Increased outbound monthly transfer by 10x

They have allowed much higher usage of their resources without compromising on performance. This wasn’t a matter of just upping the quotas and calling it a day.

Why does it matter?

One only need take a look at lowendbox or ServerBear to see that there are plenty of affordable options for VPS providers. Linode is still nowhere close to being the cheapest, but that’s not really Linode’s game. They’re going to give you something a little faster, a little more roomy, and they’re going to keep you happy wth their support. While it’s entirely possible you’ll find someone with similar specs, you’ll be hard pressed to find a competitor with the strength of this offering from top to bottom (price, hardware, network, service/support).

Linode has traditionally been a little more expensive, very developer-centric, and has (in my experience) had a pretty good customer service story. These latest round of upgrades don’t push Linode down into the “budget” category (nor should they), but they do make a good chunk of their competitors in the same category/price range look inadequate. For example, I’m not sure how I could justify using Rackspace after these adjustments for my own purposes.

We all win

Regardless of whether you use Linode or even like them, let’s be clear about one thing: When upgrades and bigger jumps like this happen, we all win. Other providers are going to look at this and will have to decide whether their current offerings need a shot in the arm. Linode is no industry juggernaut, but they are well known enough for this to cause a few ripples.

Let’s sit back and see who makes the next big jump.

Amazon Route 53 DNS failover

2013-04-02T00:03:00-04:00

While it is no longer shiny and new, I just recently got a chance to sit down and play with Amazon Route 53’s DNS failover feature. So far, I have found it to be simple and very useful for simple cases where DNS fail-over is acceptable.

My usage case

I run EVE Market Data Relay (EMDR), which is a distributed EVE Online market data distribution system. All pieces of the infrastructure have at least one redundant copy, and the only single point of failure is the DNS service itself. We can afford to lose a little bit of data during fail-over, but a complete outage is something we can’t have.

Sitting at the top of the system are two HTTP gateways on different machines at different ISPs. These are set up as a weighted record set, with each gateway weighing in at 50/50 (requests are divided evenly).

We introduce the Route 53 magic by adding in a health check and associating it with each of the two resource record sets. The health check involves Route 53 servers around the world periodically calling a pre-determined URL on the two HTTP gateways in search for a non-error HTTP status code. If any of the entries fails more than three times (they check roughly every 30 seconds), said entry is removed from the weighted set.

By the time that Route 53 picks up on the failure, yanks the entry from the weighted set, and most fast ISP DNS servers notice the change, about two minutes have elapsed.

Why this is a good fit for EMDR

With EVE Market Data Relay, it’s not the end of the world if 50% of user-submitted data gets lost over the minute and a half it takes for Route 53 to remove the unhealthy gateway. It’s highly likely that another user will re-submit the very same data that was lost. Even if we never see the data, the loss of a few data points here and there doesn’t hurt us much in our case.

With that said, DNS failover in general can be sub-optimal in a few basic cases:

You don’t want to leave failover up to the many crappy ISP DNS servers around the net. Not all will pick up the change in a timely manner.
You can’t afford to lose some requests here and there. DNS failover isn’t seamless, so your application would need to be smart enough on both ends if data loss is unacceptable.

For more simple cases like mine, it’s wonderful.

Price

In my case, Route 53 is health checking two servers that are external to AWS, which means I spend a whopping $1.50/month on Route 53’s DNS failover.

Assorted useful bits of documentation

More details on how the health checks work can be found on the Route 53 documentation.

Refer to the Amazon Route 53 DNS failover documentation for the full run-down.

Patwright mentioned in the Greenville Journal

2013-04-01T23:30:00-04:00

The Greenville Journal just did a neat interview piece on Pathwright with Paul. This may or may not be interesting to others here, but I figured I’d share.

namecheap.com EssentialSSL and Amazon ELB

2013-03-29T13:30:00-04:00

For those using the SSL capabilities of Amazon Elastic Load Balancer (ELB), you often need to upload a Certificate Chain to avoid SSL errors in some browsers.

We use Namecheap and their Comodo EssentialSSL wildcard certs. If you specify “Other” as your server type, you’ll get a collection of files that comprise the Certificate Chain/CA Bundle, instead of a single file (like you’d get if you specified Apache during the CSR submission process). If you haven’t purchased your cert yet, save yourself some trouble and just say you’re using Apache. If you specified “Other” or have found yourself with a bunch of *.crt files, read on.

I am going to assume that you are using OpenSSL. I am also going to assume that you have the same files I do. If this isn’t the case, you could try downloading their CA Bundle, but this may or may not work (or be up to date).

cat EssentialSSLCA_2.crt ComodoUTNSGCCA.crt UTNAddTrustSGCCA.crt \
    AddTrustExternalCARoot.crt > ca-chain.crt

This is all you need to paste into the “Certificate Chain” field in the SSL Cert selection dialog on the AWS Management Console.

While you’re here, have another tip: If the dialog complains about an invalid Private Key or Public Key Certificate, you probably need to PEM encode it. My key was RSA, so this is what PEM-encoding looked like for me:

openssl rsa -in mycert.com.key -out mycert.com.pem

This is then safe to paste into the “Private key” field. If for whatever reason your *.crt file came back in another format, you could also use this same set of steps to encode it (though, my was sent to me PEM encoded already).

Your knowledge is valuable

2013-02-14T04:00:00-05:00

Most people have something that they are truely passionate about. When they think of whatever this happens to be, their day brightens, perhaps they feel excited, or maybe they talk the ear off of friends about it. This kind of calling, hobby, or special interest is such a positive motivator to have.

Some of us feel the urge to get out and share, spread, and teach our special thing to others. We are fortunate to live in a time where there are many ways to do this. Perhaps we schedule Meetups with other interested people. Some of us establish flourishing online communities to discuss our beloved subject. Maybe some still post informative Youtube videos with How-To’s and instructions.

To this motivated, enthusiastic group of individuals, I’ve got a message for you: You have got something valuable in a number of ways. Not only do you have something that enriches your life, you potentially have something that could make some money for yourself on the side.

If you have knowledge to share, I’d like you to check out Pathwright, which is geared towards letting you spread and share what you know with others. You can create your very own School of Guitar, or perhaps you’d like to share what you know about restoring Classic Cars. Maybe you’d like to teach others how to program, or offer training for particular software products. All of this is possible, and it’s priced to be affordable to individuals like you and I. In fact, you can play around with Pathwright without paying a dime.

Whatever your passion, I hope that you’ll take a look at our passion (Pathwright) and let us know how we can help you share yours.

A few example ideas for things I personally would love to see:

An organized, moderated school of Photoshop
A school for user interface design
A school of whatever programming language
A school for guitar players
A school of Rowing
A school of dog training

Shoot us an email. We’d love to hear how we can help share what brightens your day.

We all wear many hats, and it’s great!

2013-02-12T22:02:00-05:00

Something that I had hoped for and have found in working at a small business (Pathwright) is the variability I see from day to day. You have a general idea of what you need to be doing, what your goals are in the immediate, mid, and longer term, but it’s hard to predict exactly how each day will shake out. Let’s look a hypothetical 8-5 as a co-founder at Pathwright, for example:

Perhaps you start the day working on triaging and fixing a bug. But now you see that you’re going to need to switch over to customer support while your colleague meets with a prospective client. In the afternoon, you’re back to figuring out how to optimize a slow page load. Then you’re scheming ways to attract new customers. Maybe you even do some sales work to help drum up new business.

The great thing about being in before all of the structure and compartmentalization is that if you have an itch, you can scratch it. You don’t do any one thing long enough to get tired of it, and new challenges are constantly being thrown at you.

This is probably not appealing to everyone. Some would think of a day like this as a nightmarish stream of interruptions. It very well can be, in some cases on some days. However, more often than not it’s fun to work on the many parts of the business you’re working to build. My primary responsibility is backend development and infrastructure, but I sometimes put on the support hat, or the sales hat, or the marketing hat.

Jack of all trades, wearer of many hats. That’s the way it is, and that’s the way I like it.

Fabric task for notifying New Relic of a code deploy

2013-02-11T22:52:00-05:00

We’ve been doing some playing around with New Relic lately at Pathwright. One of the neat things it does is track when code deploys happen, and how they affect responsiveness and resource consumption.

In order to notify New Relic when a deploy happens, you simply POST to their web-based API with the information you’d like to include (change logs, commit hashes, etc).

We currently do this via a Fabric task, which I figured I’d share. We tend to run this from our deploy task. Enjoy!

import socket
import requests
from fabric.api import run, cd

def notify_newrelic_of_deploy(old_commit_hash):
    """
    New Relic tracks deploy events. Send a notification via their HTTP API.

    :param str old_commit_hash: The previously deployed git hash. This is
        easily retrieved on a remote machine by running 'git rev-parse HEAD'.
    """

    with cd(env.REMOTE_CODEBASE_PATH):
        new_commit_hash = run('git rev-parse HEAD')
        changes = run('git --no-pager log %s..HEAD' % old_commit_hash)

    headers = {
        # Adjust this to reflect your API key.
        'x-api-key': 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
    }
    payload = {
        'deployment[app_name]': 'Your App Name',
        # This is also very important to update with your own value.
        'application_id': '1234567',
        'deployment[description]': 'Fabric deploy is fun deploy',
        'deployment[revision]': new_commit_hash,
        'deployment[changelog]': changes,
        'deployment[user]': '%s@%s' % (LOCAL_USERNAME, socket.gethostname()),
    }

    requests.post("https://rpm.newrelic.com/deployments.xml",
                  data=payload, headers=headers)

Switched to Pelican

2013-02-10T11:42:00-05:00

For the last four years, my blog has been powered by Django. As I have found myself becoming more and more busy, I have stopped wanting to hassle with keeping things up to date on the server and the application.

After a weekend of tinkering and conversions, I’m now up and running on Pelican. Generation is relatively quick, I like that it uses Jinja, and blogging in Restructured Text is strangely… relaxing? The only downside is that the documentation, while reasonably complete, has some unclear spots (custom page generation and RSS/Atom feed settings in particular).

Ansible first impressions

2013-02-08T06:22:00-05:00

After brief visits with Puppet and Chef for config management, I’ve set my sights on Ansible. It’s late and I’ve been staring at this stuff for way too long today, but here are some early observations:

I really like that it is written in Python. Puppet and Chef are great pieces of software, but I spend my days staring at Python. It’s nice not having to context switch away.
The documentation, while organized somewhat weirdly, is surprisingly thorough and helpful. I found myself much less frustrated and overwhelmed in comparison to my forays into Puppet and Chef.
It’s just SSH.
The playbook organization and format make a lot of sense to me. It feels a whole lot less complex than Chef in particular.

As far as negatives:

The documentation is very good but it could use some organizational tweaking. The related links at the bottom of some of the pages are very erratic and sometimes incomplete.
If you’re wanting to use Ansible as a Python API, the docs for this are pretty incomplete.

So far, Ansible looks very promising. I think this is going to be a great fit for us at Pathwright. Perhaps we’ll even have some time to contribute improved docs.

Amazon Elastic Transcoder Review

2013-01-30T20:37:00-05:00

Amazon Elastic Transcoder was released just a few short days ago. Given that we do a lot of encoding at Pathwright, this was of high interest to us. A year or two ago, we wrote media-nommer which is similar to Amazon’s Transcoder, and it has worked well for us. However, as a small company with manpower constraints we’ve had issues finding time to continue maintaining and improving media-nommer.

With the hope that we could simplify and reduce engineering overhead, we took the new Elastic Transcoder service for a spin at Pathwright.

Web-based management console impressions

One of the strongest points of the AWS Elastic Transcoder is its web management console. It makes it very easy for those that don’t have the time or capability to work with the API to fire off some quick transcoding jobs. With that said, I will make a few points:

At the time of this article’s writing (Jan 30, 2013), it is extremely tedious to launch multiple encoding jobs. There’s a lot of typing and manual labor involved. For one-off encodings, it’s great.
Transcoding presets are easy to set up. I appreciate that!
Some of the form validation Javascript is just outright broken. You may end up typing a value that isn’t OK, hitting “Submit”, only to find nothing happen. The probable intended behavior is to show an error message, but they are very inconsistently rendered (particularly on the job submission page).
The job status information could be a lot more detailed. I’d really like to see a numerical figure for how many minutes AWS calculates the video to be, even if this is only available once a job is completed. This lets you know exactly how much you’re being billed for on a per-video basis. Currently, you just get a lump sum bill, which isn’t helpful. It’d also be nice to see when an encoding job was started/finished on the summary (you can do this by listening to an SNS topic, but you probably aren’t doing that if you’re using the web console).

Web API impressions

For the purpose of working Elastic Transcoder into Pathwright, we turned to the excellent boto (which we are regular contributors to). For the most part, this was a very straightforward process, with some caveats:

The transcoding job state SNS notifications contain zero information about the encoding minutes you were billed for that particular job. In our case, we bill our users for media management in Pathwright, so we must know how much each encoding job is costing us, and who it belonged to. Each customer gets a bill at the end of the month, without needing to hassle with an AWS account (these aren’t technical users, for the most part). Similarly, the “get job” API request shows no minutes figure, either.
If you’re writing something that uses external AWS credentials to manage media, you’ve got some setup work to do. Before you can submit job #1, you’re going to need to create an SNS topic, an IAM role, a Transcoder Pipeline, and any presets you need (if the defaults aren’t sufficient). If you make changes to any of these pieces, you need to sync the changes out to every account that you “manage”. These are all currently required to use Transcoder. This is only likely to be a stumbling block for services and applications that manage external AWS accounts (for example, we encode videos for people, optionally using their own AWS account instead of ours).
At the time of this article’s writing, the documentation for the web API is severely limited. There is a lack of example request/response cycles with anything but one or two of the most common scenarios. I’d like to see some of the more complex request/responses.

Some general struggles/pain points

While this article has primarily focused on the issues we ran into, we’ll criticize a little more before offering praise:

As is the case for anyone not paying money for premium support, AWS has terrible customer support. If you want help with the Transcoding service, the forums are basically your only option. The responses seen in there so far haven’t been very good or timely. However, it is important to note that this support model is not limited to Elastic Transcoder. It is more of an organizational problem. I am sure this is on their minds, and if there is a group that can figure out how to offer decent support affordably, it’d be Amazon. Just be aware that you’re not going to get the best, fastest support experience without paying up.
We do low, medium, and high quality transcodings for each video we serve at Pathwright. Our lower quality encoding is smaller (in terms of dimensions) than the medium and high quality encodings. With media-nommer and ffmpeg, we were able to specify a fixed width and let ffmpeg determine the height (while preserving aspect ratio). The Amazon Transcoder currently requires height and width for each preset, if you want to specify a dimension. Given that our master video files are all kinds of dimensions and aspect ratios, this is a non-starter for us.
If you submit an encoding job with an output S3 key name that already exists, the job fails. While you do open yourself up to some issues in doing so, we would appreciate the ability to say “I want to over-write existing files in the output bucket”. There is probably a technical reason for this, but I think this fails the practicality test. A solution can and should be found to allow this.
Because of the aforementioned poor support, I still don’t have a good answer to this, but it doesn’t appear that you can do two-pass encodings. This is a bummer for us, as we’ve been able to get some great compression and quality doing this.

Overall verdict

For Pathwright, the Amazon Transcoder isn’t capable enough to get the nod just yet. However, the foundation that has been laid is very solid. The encodings themselves execute quickly, and it’s great not having to worry about the state of your own in-house encoding infrastructure.

The prices are very fair, and are a large savings over Zencoder and Encoding.com at the lower to moderate volumes. The price advantage does taper off as your scale gets very large, and those two services do offer a lot more capabilities. If your needs are basic, Amazon Transcoder is likely to be cheaper and “good enough” for you. If you need live streaming, close captioning, or anything more elaborate, shell out and go with a more full-featured service.

Once some of the gaping feature gaps are filled and the platform has time to mature and stabilize, this could be a good service. If the customer support improves with the features, this could be an excellent service.

Verdict: Wait and see, but so far, so good.

MUD tech is fun/cool, but…

2013-01-08T04:26:00-05:00

As software development evolves, there are an ever-expanding number of ways to put together very complex, elaborate systems that are fun to geek out on. Multi-processing is becoming increasingly prevalent, distributed systems are a boon to cases with massive scalability or reliability requirements, and there are all kinds of neat data stores available. These are all definitely things that have a place in software.

But what does this mean, in the context of a MUD?

Honestly, very little. Even a very large MUD with hundreds of connected players can be ran on a very pedestrian machine with a modest amount RAM, and very little bandwidth. Multi-threading is not a requirement for performance (and can often work against it). Highly distributed, multi-server setups are hitting nails with jackhammers. After all, we’re talking about a genre that primarily features smaller (<100 connected players) games.

An important thing to keep in mind when developing a MUD is that simple, well-thought-out MUD architectures have a huge advantage over those their more complex kin: They are easier to develop, and they are a lot more likely to ever see the light of day.

MUDs are a labor of love

Although you’ll hear people crying about the demise of the text-based genre, there will always be a niche out there for our kind. However, the vast majority of the games in our space are going to remain non-commercial, and mostly developed by volunteers on their spare time.

By making simplicity a high priority, we make sure that it’s easier to make progress when you do have a few moments to sit down and work on your game. While you could write a super-distributed, super-fault-tolerant MUD server, it’s probably going to make future development more complicated, and you may run out of steam before you get anywhere close to being “done”. As someone who would love to see more great MUDs out there, this makes me sad!

Developing and launching a MUD is a labor of love, and it has to be fun and interesting to you. You have a finite amount of time to get your game launched before you probably lose interest and move on to other things. This “time limit” varies from person to person, and some possess the rare ability to regularly, routinely work on a game for years before going public, but those types are very rare now. Your goal should be to open to the public before your “ok, time to move on” timer goes off. Simplicity is one of your biggest allies while pursuing this goal.

But… there are always caveats

A very valid counter-point to this argument for simplicity is that MUDs are a great way to learn new technologies, to experiment, to do things one might not normally do. If one’s goal is to tinker more so than to actually release a game to the world, you can throw this all out the window. Get as complex/geeky/sexy as you’d like, and have a blast. Who cares if you never ship? That’s not the point for you, anyway.

For those that are most concerned with actually “shipping”

Focus on your core functionality. What is your “minimum viable product?” What is the most direct way to get to your opening day? Avoid unnecessary complexity, and remember that you can always refactor and improve performance/scalability as you grow. Nothing is set in stone.

Avoid traps like multi-threading (unless you really have to have it), super scalability, and elaborate distributed setups unless you just really want to play. You’re designing a Gocart, not an IndyCar.

Simplicity. Clarity. Focus. Oh, and ship the damned thing!

Why I won’t be gifting this Christmas

2012-12-10T20:48:00-05:00

As I slogged through December 2010 with a one eye on the wallet, and the other on my Christmas shopping list, I arrived at an important realization: I had stopped enjoying what Christmas had become. As a child, the stressful, time-consuming, expensive parts were hidden away; it was fun and full of excitement. As I grew, I gradually came to realize that Christmas is an industry, a Hallmark holiday. I didn’t care for the time away from family shopping, the constant stress to get everyone something, or the fear of gifting something that the recipient didn’t like.

I arrived at the realization that I was playing along because it was expected of me. I also realized that I had started dreading this song and dance every year.

2010 was my last “regular” Christmas. Starting with 2011, I laid out my desires going forward: Do not buy a gift for me. I will not buy a gift for you. However, I will gladly donate to a charity of your choice, if you’ll do the same for me.

As expected, I received a very mixed reaction to this. Some were happy that they could cross me off their list, some really understood my reasoning, and others pressured me to re-join the commercialized mosh pit. I ended up donating to six different charities, and spent more time with family (instead of shopping). Financially, there was no difference, since I donated what I would have normally spent (which is great). Best of all, my conscious was clear, and I sailed through December with zero regrets.

This year, I will be doing the same. I will gladly donate to a charity of your choice if you will donate to mine: Shriner’s Hospital for Children. Simply shoot me an email letting me know that you donated (no need to tell me how much), and which charitable organization you’d like me to donate to.

As far as why I chose Shriner’s, pull up a chair for story time.

When I was in highschool, the band would send a small detachment to Shriner’s on Christmas Eve to play for the children who were too far from, or too sick to go home. Wanting to help brighten their day, I volunteered in December 2003.

We arrived, got set up, and were ready to greet the children, who then started to filter in. Some were wheeled in on gurneys, others walked, some were in wheelchairs. I was surrounded by scared, sick kids who wanted nothing more than to be well and back at home with their families for Christmas. We played our set, and for a brief moment, the kids were happy and all smiles. As we left, I imagined the smiles fading, and the patients being carted back to their rooms. It really put things in perspective for me, and made sure I didn’t take what I had for granted.

This Christmas, I’d like to help those children smile and get well instead of buying you a gift card or a trinket. I do not chastise or look down on those who choose to do otherwise, nor will you hear anything further on this from me. I figured I’d explain why I won’t be gift swapping (indefinitely) and wanted to make sure friends and family understood why.

Keep in mind what Christmas is all about this holiday, and have a great one!

python-route53 released!

2012-11-14T01:19:00-05:00

After some more time in the cooker, python-route53 1.0 has landed on PyPi. This is a stand-alone Route 53 package, independent from the one in boto. The major hilights are:

Python 2.7 and 3.x compatibility.
Extremely simple API
Powered by requests

Read the documentation, see the source, and yell at me on the issue tracker or Twitter.

python-route53 feedback wanted

2012-11-08T16:17:00-05:00

Late last night (or early this morning), I finished the draft of python-route53, a stand-alone Route 53 module with Python 3.x and Python 2.7 compatibility. Route 53 is an excellent DNS service offered by Amazon Web Services. It exposes everything through an API.

My intentions with python-route53 are two-fold:

There were no Python 3 compatible Route 53 modules that I knew of. I had a need for one.
I didn’t feel like any of the existing Route 53 modules were as simple and easy-to-use as they could be.

What I’d like to do is reach out and get some feedback on whether I have succeeded or not in both regards. I’d like to get a packaged release out later this week, but hoped to get some eyeballs on the documentation and the source before it lands on PyPi.

If you’d like to take a look, see the python-route53 documentation and the project at Github. Feel free to leave issues on the issue tracker with feedback, or tweet at me.

Evennia MUD server gets BSD’d

2012-11-02T03:35:00-04:00

As of a few days ago, the Evennia MUD server has been re-licensed under the BSD License. We feel like this will knock down another barrier for those considering running a game with Evennia. I can’t recommend this codebase enough for anyone who may have caught the MUD development itch (hey, they still exist!). Griatch has been doing an awesome job making improvements and building a community.

Evennia is an advanced Python+Django MUD server, with all sorts of goodies (like a web-based client). While the project has been going on for a number of years, the community has been growing a bit faster over the last year or two. We hope this will help continue that trend.

Feel free to stop by #evennia on FreeNode IRC to lurk, hang out, or ask questions.

python-fedex and colormath re-licensed under BSD

2012-10-23T05:07:00-04:00

I am happy to announce that python-fedex and python-colormath have been re-licensed under the BSD License. At the time these two packages were created, there were reasons for GPL’ing these. However, said reasons have long since been removed, so it’s BSD time!

My involvement with both of these projects has been minimal since I joined DUO Interactive, since we don’t have a use for either. However, my hope is that a more permissive license will encourage contributions. I still review pull requests for both of these when they appear, and would be very much open to capable individuals taking over maintainership of either.

python-bluefin 1.3 released

2012-10-16T20:55:00-04:00

python-bluefin 1.3 has been released, now with improved error handling. The major feature in this release is that we have smoothed over some inconsistencies in Bluefin’s error handling.

Instead of setting an HTTP status code indicating an error like they do for most of the Bluefin API errors, we get an HTTP 200 back, and a rarely used attribute in the response contains an error flag, with another rarely used attribute containing a cryptic error message. Since you need to handle invalid credit card numbers and authorization failures gracefully, we now return a different exception (that still inherits from what was previously returned). We also provide a more friendly error message for the authorization-related errors, that are not user-friendly, or human-friendly.

Of course, you can still access the original exception message through Exception.raw_message. See the changelog for full details.

This release is backwards compatible, it’ll just give you better granularity in your error handling.

Get it from the PyPi page, or by installing ‘bluefin’ from pip/easy_install.

python-bluefin 1.2 released, sans urllib2

2012-09-19T21:36:00-04:00

python-bluefin 1.2 has been released. python-bluefin is a very thin wrapper around the Bluefin payment gateway’s API. The two major changes are:

urllib2 has been removed, with the excellent requests taking its place.
We now check directmode’s status_code for known failure codes and raise exceptions based on what we find. Previously, no exception was raised, which would result in a silent failure if you weren’t looking at status_code yourself.

To install, either easy_install/pip install bluefin, or download directly from its PyPi page.

Mountain Lion observations so far

2012-08-04T18:28:00-04:00

As some of the software I use on my Macbook Pro now requires at least 10.7, I had to retire my trusty Snow Leopard a few weeks ago. After a few weeks of using Mountain Lion, I’ve got things mostly straightened out to where I’m productive again. A few random observations:

The Good

I appreciate being able to download the 10.8 upgrade digitally, and open it directly on the desktop like any other application. This is easy enough for most people to figure out quite easily.
Things do seem a little more snappy on my mid-2010 MBP. Nothing drastic, but less beachball-of-despair.
After getting spoiled by Ubuntu’s Unity notifications, it’s really nice to see Apple implement something similar. Gave me an excuse to uninstall Growl.
Being able to grab the XCode suite from the App store is more convenient than having to mess around with Apple’s funky developer site.

The Bad

The reversal of the default scroll direction upgrading an existing 10.6 install, was very abrupt and unnecessary. For upgrades, they should probably preserve the old settings when possible. Sometimes software companies do stuff just to be different for the hell of it. I get the sense that this was one such example of this behavior. It doesn’t make life better or easier. This got set back to the original behavior.
The auto-hiding of scrollbars was similarly unecessary. Vertical space is at a premium with these laptop monitors, but there is loads of horizontal space. I really like being able to see how far into something I am without doing any goofy finger tapping, so this ended up getting set back to “Scrollbars always visible.” Here’s how to make them stay visible.
The “overscroll” bouncing when scrolling past a page’s top or bottom limits is strangely disconcerting on a desktop OS for me. I’m not sure why I dislike it so much, but I find it jarring. Maybe if it bounced less. Here’s how to disable it.

The Ugly

The 10.8 install completely flips its shit when encountering Linux partitions, to the point where you can’t proceed with installation. There are various ways to attempt to fix this, but I eventually ended up sacrificing the Linux partitions temporarily. Bummer. Some people have figured out how to correct the various errors you get here, but this wasn’t quite worked around on day 1 when I upgraded.