Dan Carroll | Blog

PAX East 2013

2013-04-04T23:30:00Z

I wanted to write a quick post with some general impressions from my time at the 2013 edition of PAX East. I've been attending PAX since 2008, but this was just my second year at the East coast version. I also only went for a single day, which greatly limits the amount of stuff you can see on the convention floor.

The venue

PAX East is held at the Boston Convention & Exhibition Center, and is the perfect location for this type of event. The building has a ton of space, and can easily handle the number of people that attend. It doesn't have the wacky charm that the Washington State Convention Center has (the site of PAX Prime), but I'll take the elbow room over charm any day.

The games

Battleblock Theater: I first saw this game back at PAX Prime in 2009, before it had a name. I've watched it closely since then, following its progression over the years. The game finally released today, and it seems to have benefited from the extra polish. I hope it can captivate me the same way Castle Crashers did, and I look forward to seeing what's next for The Behemoth.

Nutjitsu: This was a brand new game from Ninjabee. In its current state, it is a simple path building and stealth game built for tablets, with a fun art style and main character. I'm a big fan of their Kefling series of games, so I'm looking forward to playing this when it gets released.

Perspective: This game was one of the games playable at the Digipen booth, as it was a student project. It's an excellent platformer that makes very clever use out of the interaction between 2D and 3D space. I highly recommend checking it out, as well as some of the other Digipen games from recent years.

The talks

Beyond playing new games, I really enjoy PAX for the variety of industry talks and panels that are held.

Mass Effect Retrospective: This panel had a number of designers, writers, and even a voice actor from the Mass Effect series of games. I had envisioned fans with pitchforks, still angry about the ending of Mass Effect 3, but the panel ended up being mostly fluff and softball questions. It was still nice to hear some background information over various bits of the development process.

Classic Videogame Panel: This panel was hosted by ACAM, who also have a classic arcade game room at PAX East. They hosted a similar panel last year, with a number of the same panelists, but that didn't dampen my enthusiasm. I have no problem listening to those guys share stories and talk about what it was like to develop videogames back in the 80s.

Configuring No-WWW for IIS on Azure

2013-03-22T00:45:00Z

As part of the rollout of my site redesign, I've also switched hosts from WebFaction to Windows Azure. WebFaction was a great value for a shared host, and I'll probably continue to use it in the future for small Python/Django projects, but I've been experimenting with Azure on some other projects and took the opportunity to make the switch.

Where'd my .htaccess go?

Azure Web Sites use IIS as a web server, not the more common Apache (or Nginx) server widely used across the Unix world. While Azure handles all of the server setup and maintenance for many cases, you'll still need to get your hands dirty if you need custom handling.

One of the big behaviors I needed to maintain in the migration was to continue adherence to the No-WWW philosophy. This means making dancarroll.org the canonical name of my site, with www.dancarroll.org redirecting to the no-www version.

I had this set up on the previous iteration of the site using an Apache .htaccess file. It was very easy to find examples of how to do this across the web.

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=permanent,L]

IIS, however, does not use .htaccess files. Instead, I needed to create a Web.config file with the appropriate settings.

IIS URL Rewrite

Luckily, IIS has its own URL rewriting module. And, even luckier, Azure Web Sites get this module configured automatically.

To get this set up, you need to create a file named Web.config in the wwwroot directory of your Azure deployment. I was only able to find a few examples of doing no-www redirects for IIS, but all of them hardcoded the domain name in the file. This wasn't acceptable, as I like to reduce maintenance and use a similar configuration across many different web sites.

Here's what I came up with:

<?xml version="1.0"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Canonical Hostname" stopProcessing="false">
          <match url="(.*)" />
          <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
            <add input="{HTTP_HOST}" pattern="^(www\.)(.*)$" />
          </conditions>
          <action type="Redirect" url="http://{C:2}{REQUEST_URI}" redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

And that's it! I found that Azure would recognize the file modification and start using it, but you may need to manually restart the site using the Azure management portal.

Breaking it down

The documentation for IIS URL Rewrite is decent, but I wanted to provide a few quick notes about what is going on here.

<match url="(.*)" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
  <add input="{HTTP_HOST}" pattern="^(www\.)(.*)$" />
</conditions>

The match element defines the pattern that will be used to find URLs to be processed. In this case, the regular expression used captures all URLs. A condition is then created to provide additional refinement to which URLs will have a rewrite action taken. Here, the condition only looks at the server variable HTTP_HOST, which requires matching the host domain (not the full URL). The regular expression used only matches hosts starting with www..

<action type="Redirect" url="http://{C:2}{REQUEST_URI}" redirectType="Permanent" />

If there was a successful match, then an action is taken for that particular URL. In this case, the action is a redirect, with the "Permanent" redirectType mapping to an HTTP 301 status code. The url attribute defines the redirect URL, and I'm using two features here to generate it.

{C:2} is a back-reference, which as its name implies, refers back to data captured previously in the rule. The C states that we are referring to something captured by a condition (as opposed to the rule match), and the 2 is the second group match (0 is the full pattern, 1 is the www. part, and 2 is the remainder of the host).

Finally, {REQUEST_URI} is a another server variable that IIS lets us reference, and it contains the full path to the requested document. If the URL is http://www.dancarroll.org/blog/, then REQUEST_URI is /blog/.

Bonus Rules

A couple of extra URL rewrite rules I am using that are worth sharing.

Forcing lowercase URLs

<rule name="Convert to lower case" stopProcessing="true">  
  <match url=".*[A-Z].*" ignoreCase="false" />  
  <action type="Redirect" url="{ToLower:{R:0}}" redirectType="Permanent" />
</rule>

Redirecting default documents

For default documents (i.e. index.html), it is nice to redirect a request to domain.com\dir\index.html to its parent directory, domain.com\dir\. This also help to ensure there is only a single canonical name for any document.

<rule name="Default document - html" stopProcessing="true">
  <match url="(.*)index.html" />
  <action type="Redirect" url="{R:1}" redirectType="Permanent" />
</rule>

Redesign

2013-03-16T22:38:05Z

This site has been quiet for a long time. My last post was over a year ago in February 2012. That post before that was yet another year prior. With a full-time job and other personal commitments, blog posting and other side projects easily fall off the radar.

Take my site's new design, rolling out today. I initially started working on it in February 2011, going by the file creation timestamps on my machine. I worked on it for a week or so, got some feedback, then dropped it. A year later, I took the big step to actually create a source repository on Bitbucket to make sure the code was backed up somewhere safe (I don't recall making any other progress at the time).

It took me over a year from that point to actually pick up the project and push it through to completion.

The design

Like the previous design of my site, I have taken a lot of inspiration from people in the Django community. A lot of the design inspiration comes from Steve Losh, who has consistently done an excellent job at clean, readable web design.

I'm not sure what I was thinking with the previous iteration, which featured orange and beige on a darker, almost navy blue background. That's been fixed now!

The code

Like Steve, I also made a transition in how the site is implemented. Previously, my site was developed using Django. Django is a Python-powered web framework, and it gave me tremendous flexibility to add features like a lifestream. However, it came with a lot of overhead for a simple blog, and could be unreliable on inexpensive, shared web servers.

This new iteration of the site is built using Hyde, a static web site generator built in Python. Hyde allows me to work with Python code and templating languages, much like the one used with Django, but the end result is a static HTML and CSS website (rather than a dynamic site backed by executing Python code and databases). The end product can now be hosted anywhere with relatively good performance.

And like the previous iteration, the new version is still open source. For ease of browsing both implementations, the new design lives in a separate code repository on Bitbucket.

The problems

Another big improvement made during this transition is in ease of use and maintainability for me. Previously, I tried a few different ways of creating blog posts. First, I tried writing HTML each time I needed to create a new post, and uploaded it using Django's admin UI. This was a pain and prone to rendering issues.

Next, I spent a lot of time implementing support for the MetaWeblog API, which allowed me to create blog posts using applications like Windows Live Writer. That made post creation much easier for me, but those blogging applications would create ugly HTML with their own special markup, and often required tweaking the HTML by hand to get things to show up correctly.

Finally, regardless of how I created posts, they ended up being saved to a database on my web host. That's not a very safe location, so I needed to make sure to create regular backups.

The solutions

With Hyde, it was easy to convert all of my blog posts to be written in Markdown. When generating the site, the posts get passed through a Markdown filter to convert them to HTML. As long as I have good CSS defined on how to render what HTML gets produced, I can create a blog post using a simple text editor and know that it will come out looking good on the other side.

Aside: Django has built-in support for Markdown, so I could have used it with the site's previous implementation. However, things would have been more complicated. There would be performance issues if posts were passed through the Markdown filter for each web request, deployment complexity if I needed to leverage server-side caching, or implementation complexity if both versions were stored (Markdown version for editing, HTML version for serving up web requests).

For the issue of storing and backing up blog posts, content is now part of the codebase itself. It gets pushed up to Bitbucket, and lives on a few different machines where I have the code checked out.

The future

I feel very accomplished for finally completing this major redesign project, so I hope to actually use this thing more often. I'll never be prolific, but my goal is to publish at least several posts a year.

Caveat about WP7 Live Tiles without cellular data

2012-02-14T14:23:53Z

I have owned and used a Windows Phone since they were introduced in late 2010. While I am currently a Microsoft employee, I do love the device as a consumer. I previously used an iPhone 3G and have not had an desire to go back to that world. The biggest downside is missing out on some of the big iOS apps, especially games, but the overall experience WP7 provides with improved email, people, and information management has made up for the loss.

While I've owned one for a while, I hadn't had much of an opportunity to develop apps. As a former iPhone user, I wanted to jump into iOS app development, but was not able to since the development tools were only available on a Mac. I finally made the commitment and jumped into the mobile development world. For the past month and a half, I have been using my spare coding time working on Windows Phone development. Hopefully I will get the chance to blog about my experience, along with tips and tricks.

Meet Wi-Fi, the battery hog

One interesting "feature" of WP7 aims to save gobs of battery life. Whenever the screen is locked, the OS will turn off any active Wi-Fi connection (unless it is being used to stream music/video or download something in the background). I'm sure this feature is great for battery savings, but it does have one interesting implication that recently hit me.

I have a second phone I just acquired to use for testing my apps. I only have a single cell phone plan for my main phone, and the second phone connects using Wi-Fi only. One of my apps uses a background agent to download information and update a live tile. The live tile will not get updated, since the background agent has no connection to use when the screen is locked (as Wi-Fi is disabled).

The workaround? Plug your phone in. Wi-Fi connectivity stays active when the phone is plugged in, regardless of whether the screen is locked.

It would be nice if there was an option to disable this feature, since Windows Phone loses functionality if you don't have a cellular data plan. There is a suggestion on the WP7 UserVoice forum to add that option, in case you want to go vote for it.

Update (2013-02-27): Windows Phone 8 includes an option to keep Wi-Fi alive when the screen is off.

Announcing django-activitysync

2011-02-15T23:25:46Z

Today I'm happy to announce the release of my first reusable Django app, django-activitysync. The app allows easy integration of social network activities and status updates into Django projects. I've been using it to power the activity section of this website for the past year and have been eager to decouple it into a separate application.

What it provides

Django-activitysync can provide functionality similar to other lifestream solutions, but its real power is as an extensible framework for aggregating, storing, and displaying any type of simple item. It currently provides built-in support for Twitter status items, Twitter searches, Google Reader shared items, and Reddit liked items.

Adding support for a new network or activity type is as simple as implementing a new activity provider. Providers consist of 5 functions, one of which returns a list of simple objects containing the activity detail. Django-activitysync takes care of storage and duplicate detection.

How to use it

Django-activitysync is available as an installable Python package on PyPI. You will also find detailed documentation there on installation, configuration, and use. The source code itself is also available in a Bitbucket repository.

Future plans

This announcement marks the initial release of django-activitysync. I plan to continue supporting it with additional features, new social networks, and bug fixes. Feel free to open issues on the Bitbucket repository if you encounter bugs or have feature suggestions.