mtik00

Jinja2 Cache Busting URLs in Python

Thu, 09 Nov 2017 14:52:30 -0700

Cache busting is a technique the gives web developers a compromise between asset load speeds and new features. In this article, we’ll discuss a pure Python way of implementing this feature in your Jinja2 templates.

What is “caching”

NOTE: This article will not cover HTML cache headers, proxy settings, etc.

Everything you see on a web page is loaded from somewhere. That “somewhere” could be a VPS in the cloud, a CDN service like CloudFlare, your machine, and so on. We’ll call these things “assets”. Assets are images and text files used to tell your browser how the page you are looking at should look. These are mostly things that don’t really change too often.

Since assets don’t change often, you can really speed up page loading by using something called “cache”. Serving files from the webserver can be really slow, especially if it’s a very popular website, or your internet connection is slow. The good news is that if you have visited that page recently, some or all of the assets will already be on your computer.

This all happens without much input from you, the user. Your browser will cache by default (unless using something like Tor Browser). Even if you have your browser cache disabled, the assets may be cached by a service like CloudFlare. That’s out of your control.

Quick loading is great, but what happens when the version of cute-puppy.jpg you have in your cache is different from what’s on the server? You’ll continue to see the same old boring puppy image. FOMO anyone?

There’s also evidence that search engines prioritize websites that use very long cache times (e.g. Google’s own Page Insights tool). A nice article on how caching works can be found here: https://jakearchibald.com/2016/caching-best-practices/

Busting the cache

Web developers use a technique called “cache busting” to ensure that any change to cute-puppy.jpg is immediately seen by users. They get around any “cache” mechanism by generally taking 1 of these approaches:

Change the filename: Instead of cute-puppy.jpg, they’ll use something like cute-puppy-v1.jpg. If the change the content, they’ll change the name to cute-puppy-v2.jpg.
Change the URL: Instead of using /static/images/cute-puppy.jpg in HTML, they’ll use something like /static/images/cute-puppy.jpg?v1.

The idea is the same. Any change a developer makes to the “asset” will cause viewers to download the updated file.

I prefer the second method. I think this is cleaner, and causes less overall churn in my source code control.

Pre-calculate vs JIT

The way I see it, you have two options here: 1) Use a build step to version your assets; 2) perform a “just in time” calculation when the resource is requested. This really depends on your process, but I don’t see a downside to pre-calculating a version. This method should also perform much better under load. Admittedly, I’m too lazy to measure it, so YMMV.

I decided to create a script that calculated the CRC32 for each of my static images and store the result in a JSON file. I load that file at the start of my script. This works great! It does, however, cause a lookup to occur each time the Jinja2 template is rendered. Jinja2 is pretty good a caching rendered templates (moar cache!), so I think that’s fine.

NOTE: You could also dynamically create this table at application start. I chose not to just to keep the start process simple and clean.

Here’s my Python function to calculate the CRC32 for each of my images:

import zlib
def build():
    """
    Builds the release files
    """
    # Calculates and stores the CRC32 for all images in 'static/images'
    outfile = os.path.join(THIS_DIR, 'app', 'cachbuster.json')
    image_dir = os.path.join(THIS_DIR, 'html', 'static', 'images')
    result = {}
    for root, dirs, files in os.walk(image_dir):
        for fname in files:
            fpath = root + '/' + fname
            relpath = fpath[len(image_dir) + 1:].replace('\\', '/')
            prev = 0
            for line in open(fpath, 'rb'):
                prev = zlib.crc32(line, prev)
            result[relpath] = '%x' % (prev & 0xFFFFFFFF)

    with open(outfile, 'wb') as fh:
        fh.write(json.dumps(result, sort_keys=True, indent=4, separators=(',', ': ')))

The fancy relpath thing is so the output is more manageable (more on that later). The file output looks a little like this:

{
    "about-us.jpg": "8212d43f",
    "favicon.ico": "be79d92e",
    "slider/title-img-01.jpg": "5849f6f0",
    "slider/title-img-02.jpg": "a66c8271",
    "slider/title-img-03.jpg": "2e2cbe84"
}

Jinja2

Jinja2 is a templating tool used by many Python-based web development frameworks (like Flask and bottle.py). It’s really quite handy when it comes to creating a single HTML file using nice OO concepts like inheritance.

Filter

The first thing we want to do is to add a custom Jinja2 filter. This is the thing that will compare some input to our JSON data and return a URL.

CACHEBUSTER = json.loads(open(THIS_DIR + '/cachbuster.json', 'rb').read())

CACHEBUSTER is just the data that was calculated during our build step.

def imageloader(partial_path):
    '''
    Returns the path with a cachbuster tag if found, or the path otherwise.
    '''
    if partial_path in CACHEBUSTER:
        return '/static/images/' + partial_path + '?' + CACHEBUSTER[partial_path]

    return '/static/images/' + partial_path

The function imageloader is the thing that we’ll use in our Jinja2 templates. This function accepts a single input, partial_path. We check for the existence of that path in our pre-compiled CRC32 data. If we find it, we return a URL with the calculation appended as a “query”. If not, we’ll assume that the path is relative to /static/images/.

Using our data file from above:

>>> print imageloader('slider/title-img-01.jpg')
'/static/images/slider/title-img-01.jpg?5849f6f0'
>>> print imageloader('someimage.jpg')
'/static/images/someimage.jpg'

All good! Any time we make a change to slider/title-img-01.jpg, the calculation will change, and we’ll get a new URL. Any item that’s not pre-calculated will be returned like normal.

The last part is to tell Jinja2 about this new filter in app.py.

1
2
3

jinja2_loader = jinja2.FileSystemLoader(TEMPLATE_DIR)
jinja2_env = jinja2.Environment(autoescape=True, loader=jinja2_loader)
jinja2_env.filters['imageloader'] = imageloader

The magic is line number 3. That tells Jinja2 to call our imageloader() function any time it sees a filter named imageloader.

Template Use

Here’s how I use the new filter inside a template:

<img src="{{'slider/title-img-01.jpg' | imageloader}}" alt="Title slider image 1">

'slider/title-img-01.jpg' gets passed to our function, which returns '/static/images/slider/title-img-01.jpg?5849f6f0'. That whole string then goes into the template, resulting in this:

<img src="/static/images/slider/title-img-01.jpg?5849f6f0" alt="Title slider image 1">

Perfect! As long as we keep generating our JSON file during our build process, the templates will always point to the latest asset without regard to our cache settings.

Where to go from here

I showed you how I cache-bust the images from one of my websites. This is done in pure Python, without other tools like Grunt. If you are already using compile tools, you may as well find out how they do cache-busting. But what fun is that?

This can be extended to your other assets. For example, why not to your .css and .js too? That excersize is left up to the reader ;)

Windows, Git, and SSH Keys

Tue, 07 Nov 2017 16:14:47 -0700

Git has the ability to use SSH keys in order to authenticate communications with a remote server. This is a magical thing! Depending on how you set it up, you may never have to enter your password again.

You may find differing opinions, of course. My suggestion is to store password-less keys securely on your development system. This may seem like a bad idea, but it’s a pretty common thing to do to make your life easier.

If your laptop/desktop ever gets stolen, it’s pretty easy to revoke it’s key.

Generating Keys

I do 99% of my development on my Windows computer. Windows doesn’t have any built-in SSH functionality (we’re not talking about WSL right now). That means that you will wind up installing PuTTY. It’s ok… everybody’s doing it!

I like to store my SSH keys in my profile directory. This will make your life a lot easier. The keys will also be slightly protected with your Windows login information. %USERPROFILE% is also the default place were utilities will look for your SSH config file.

In a command Window, type: mkdir %USERPROFILE%\.ssh

Generate your first key:

Open up PuTTYGen (might be in your Start menu if you installed it like that)
The default settings of 2048 RSA should be ok
Press the Generate button
Move your mouse over the window to generate some randomness
Export these things to your %USERPROFILE%\.ssh folder (you can ignore the without a passphrase warnings):
- Press Save private key: This will save a file with a .ppk extension. This is your private key; keep it safe! This should stay on your dev machine.
  For this example, name this devmachine.ppk
- From the menu, select Conversions -> Export OpenSSH Key: This is your private key exported into something that git will use.
  For this example, name this devmachine-openssh-private.txt
- Keep the Window open… the Public key for pasting is important for a later step.

Here’s a screenshot of my screen after I generated the key:

%USERPROFILE%.ssh\config

The SSH utilities that don’t use the .ppk directly will want to use the devmachine-openssh-private.txt file that you exported above. The easiest way to do this is to create a config file that tells the utilities which keys to use for which hosts.

Run the following command from the command line (careful here, don’t delete the file if it’s already there!):

type NUL >> %USERPROFILE%\.ssh\config

This will create an emtpy file. Now open that file up in your favorite text editor. Here’s a sample configuration for github.com:

Host github.com
    StrictHostKeyChecking no
    IdentityFile C:\Users\myusername\.ssh\devmachine-openssh-private.txt

(replace myusername with your user name)

All utilities that support this kind of thing, such as git, will automatically use this configuration to log in to the remote system (github.com, in this case).

NOTE: This format of .ssh/config is the same for both Windows and Linux.

GitHub

We’re using GitHub in this example, but this holds true for any other remote host that supports SSH keys (even Linux systems).

Go into your Settings, and select SSH and GPG keys
Press the New SSH key button
Give it an appropriate Title
Remember the PuTTYGen window you kept open? Copy the text in the Public key for pasting… section (right click, select Select all, then right click and select Copy)
Paste that text into the GitHub page were it says Key.
NOTE: The thing you copy/paste should start with ssh-rsa and probably end with == rsa-key-20171107 (the numbers would change)
Press the *Add SSH key button at the bottom of the form.

That’s it! Now you can use git clone to clone your repo using the Clone with SSH option. That will also give you the ability to use git pull and git push without entering in your password.

Bonus: Linux Server

Have a Linux server already using SSH? Great news, you can follow the same basic steps to allow password-less connections!

GitHub gave us a nice web interface to add the keys. No such luck in Linux (depending on what you think of GUIs). Still, its a relatively simple process.

NOTE: These directions really depend on how sshd is configured; the directions below are most common.

mkdir -p ~/.ssh
vim ~/.ssh/authorized_keys (or use a command-line editor your familiar with)
Add in the same text you pasted into GitHub (ssh-rsa.....== rsa...)
Save the file
IMPORTANT: Change the permissions: chmod -R 600 ~/.ssh (things may not work without this)

Back on your Windows machine, make another entry in %USERPROFILE%\.ssh\config that points to your Linux server.

Cloudflare with GitHub Pages

Mon, 06 Nov 2017 10:10:08 -0700

I recently changed my GitHub pages setup to incorporate the use of CloudFlare, because, why not?

NOTE: If you don’t have a domain, or don’t care about CDN/Caching, the instructions below are pointless! Just point people to https://<username>.github.io!

Why

In my Nginx Proxy for GitHub Pages post, I explained how to set up your own web server using Nginx and Let’s Encrypt to provide your own SSL certificate and proxy requests to GitHub. This is fine, but it still adds a layer of complexity and requires your own VPS for set up.

I was recently poking around CloudFlare. I found out that they have a free tier that supports all kinds of neat things. This includes a shared SSL certificate (perfectly fine for GitHub Pages content), CDN, DNS, and of course caching. I’m always up for a free introduction to new-to-me technologies.

Personally, the biggest benefit is that I no longer have to deal with minimizing anything! CloudFlare offers the options to minimize things for you (and bypass that when needed). This means that my development workflow is quite a bit easier. This pretty much negates my Testing Pipelined Static Content post!

Steps

Full disclosure: Most of these steps are already online, so you could also Google them too.

CloudFlare

The first step was to sign up for a CloudFlare account. That was easy. During the setup procress, CloudFlare figured out all of the DNS records I was using (name servers, mail records, etc). CloudFlare automatically sets them up as one would expect. For example, the MX records were left alone (which is exactly what you want). CloudFlare then tells you what to change on your registrar. This makes it so all domain name lookups go through CloudFlare’s DNS.

GitHub

The next step was to set up GitHub pages to know about our new domain. This is explained in GitHub’s online documentation. Just a quick settings change and a new CNAME file. One thing to note: you’ll want to add a .nojekyll file to your pages folder if you aren’t using Jekyll. (this is the best link I found for that)

Wait

Now you wait! DNS changes take a while to propogate through the system. It took my work network a full day to pick up the change; my home network only took a few hours. You’ll know its been changed on your network when you run nslookup <domain> and the result points to CloudFlare DNS.

Back to CloudFlare

By now, you should be serving your content through CloudFlare connected to GitHub. There are some settings in CloudFlare that you may want to enable:

SSL Full: On the Crypto page, you can set your SSL to Full. This will encrypt the connection between CloudFlare and GitHub. NOTE: You cannot use Full (strict) because your hostname is different from GitHub! You’ll get errors and your site won’t work.
Browser Cache Expiration: On the Caching page, you can now set the cache expiration. If you use cache busting techniques, you can set this to something in the far future, like “6 months” or “1 year”. Always Online is an interesting one too.
Auto Minify: This is a handy feature on the Speed page. I have CloudFlare automatically minify my JavaScript, CSS, and HTML.
Always Use HTTPS: I like always redirecting to HTTPS. AFter all, this is one of the reasons I’m using CloudFlare. I’ve created a rule on the Page Rules page to always use https for http://mtik00.com/*.

NOTE: These changes take affect immediately(-ish).

SSL

SSL/TLS is the biggest change. I’m no longer encrypting mtik00.com with Let’s Encrypt. This is because of 2 things:

Visitors are presented with CloudFlare’s SSL certificate
CloudFlare communicates directly to GitHub using GitHub’s SSL certificate

mtik00.com is no long providing any SSL. That should make sense since mtik00.com is really a virtual thing now. All of the content is served by GitHub and cached by CloudFlare.

Posting Process

My process of creating a post is identical to before (thanks to scripting). The only think I took out from my deployment script was the minification of things.

Caveats

Here are some things to consider when choosing this method.

Any DNS changes you need (e.g. SPF, DKIM, etc) will need to changed on CloudFlare’s DNS settings page.
Your site will NOT use your certificate (unless you pay CloudFlare to manage one). This is not the solution to use a domain-verified certificate.
This is mainly fire and forget. Don’t forget how things are set up!

virtualenvwrapper-win "No module named pip"

Wed, 09 Sep 2015 10:16:16 -0600

If you use virtualenvwrapper on Windows, you may have come across an issue where the environment cannot be created properly due to “ImportError: No module named pip”

I’ll let you Google the reason; here’s a fix. Basically, you need to create the environment without setuptools. Here are the basic steps:

mkvirtualenv --no-setuptools --no-site-packages newenv
wget --no-check-cert https://raw.github.com/pypa/pip/master/contrib/get-pip.py
python get-pip.py
del get-pip.py

Because I do this every so often, I’ve implemented my own mkvirtualenv batch file like so:

@echo off
IF .%1 == . (
    echo Usage: mkvirtualenv 'env name'
    GOTO :eof
)

@echo on
call C:\Python27\Scripts\mkvirtualenv.bat --no-setuptools --no-site-packages %1
wget --no-check-cert https://raw.github.com/pypa/pip/master/contrib/get-pip.py
python get-pip.py
del get-pip.py

FYI: I store batch files like this in C:\bin. I then put C:\bin in my path, so they’re available to all of my command-line activities.

The batch file is not perfect, since the path to the actual mkvirtualenv is hard coded, but it’s far easier than trying to store the output of something like python -c "import os,sys; print os.path.join(os.path.dirname(sys.executable), 'Scripts', 'mkvirtualenv.bat')".

Django and Cripsy Form Login with Icons

Sun, 30 Aug 2015 21:55:57 -0600

I recently created a website using the very nice Edge template for a new Django site. The log in form was nice, but I wanted a form with icons and no labels. Here’s how I did it…

The greatest thing is that this was a super easy change. I think it looks a lot nicer, to boot.

Here’s what the old login page looked like:

I used the incredible PrependedText FormHelper item to add a Font Awesome icon before the field. I had to set the field labels to empty-strings, as I:

Couldn’t figure out the Field item to set inside PrependedText
Couldn’t use self.helper.form_show_labels = False because I needed it for the remember_me field.

Here’s the python code:

    def __init__(self, *args, **kwargs):
        super(LoginForm, self).__init__(*args, **kwargs)
        self.helper = FormHelper()
        self.fields["username"].label = ""
        self.fields["password"].label = ""
        self.helper.layout = Layout(
            PrependedText('username', '<i class="fa fa-envelope-o"></i>', placeholder="Enter Email Address"),
            PrependedText('password', '<i class="fa fa-key"></i>', placeholder="Enter Password"),
            HTML('<a href="{}">Forgot Password?</a>'.format(
                reverse("accounts:password-reset"))),
            Field('remember_me'),
            Submit('sign_in', 'Log in',
                   css_class="btn btn-lg btn-primary btn-block"),
        )

Here’s the new login form:

The is subtle, but effective! (I think so, anyways)

Testing Pipelined Static Content

Mon, 10 Aug 2015 20:57:46 -0600

After working quite hard on my pre and post Hugo pipeline, I needed a way to test the actual content that will be pushed to the server. Python (once again) to the rescue!

I really love Hugo’s built-in server. hugo serve --watch is truly a great time saver. However, it has nothing to do with our pipeline (fingerprinting, compressing, etc). If we want to see what the end result is going to look like, we need a way to serve that content.

Python has many built-in packages. That’s the main reason it’s my language of choice. Python has a simple web server ready to go. I use hugo serve --watch when I’m creating my content. When I want to check the output of my pipeline, I use the following on the command-line:

cd <path to content> && python -m SimpleHTTPServer 8000

python -m SimpleHTTPServer 8000 tells Python to load the SimpleHTTPServer module and serve the content it finds in the current working directory on port 8000. Technically, you are running SimpleHTTPServer.__main__().

The great thing about this is that I can run both the Python server and the Hugo server at the same time, depending on what I need.

Here’s the batch file I use for this:

@echo off
cd %~dp0..

echo %1|findstr /xr "p" >nul && (
  goto :python
) || (
  goto :hugo
)

:: =============================================================================
:: Run python on the already-built static pages.  This is for checking the end
:: result of the pipeline to ensure everything worked.
:python
pushd mtik00.github.io
start python -m SimpleHTTPServer 8000
popd
goto :end
:: =============================================================================

:: =============================================================================
:: Clean the Hugo build directory, then call Hugo to serve the content
:hugo
IF EXIST build (
    rmdir /q /s build
    sleep 1
)

start hugo server --watch --source="site" --bind="localhost"
goto :end
:: =============================================================================

:end

Create a Post Date/Time with Python

Sun, 09 Aug 2015 21:07:30 -0600

I like to create draft posts as kind of markers for things I want to write about in the future. Unfortunately, when I do a hugo new post..., the current date is already put in the front matter for me. That’s really handy if I’m posting right away, but not so much if I have a draft for a really long time.

If you have Python installed on your system, here’s a quick one-liner to print out the current date/time in Hugo’s (really Go’s) format:

python -c "import time; print time.strftime('%Y-%m-%dT%H:%M:%S', time.localtime()) + '%+03i:00' % (-1*(time.altzone / 3600) if time.daylight else (-1*(time.timezone/3600)));"

I have that line wrapped in a batch file that I can run called htime.bat.

It’s quick and easy! It’s slightly easier than just changing it with your text editor.

NOTE: This command only takes into consideration timezones that change on the hour! Sorry India (and more)…

UPDATE 8/10/2015: I just came across the hugo undraft command that does basically the same thing.

Nginx Proxy for GitHub Pages

Sun, 02 Aug 2015 22:15:32 -0600

Nginx is my favorite web server. I find it much easier to configure and use than Apache. If you believe the hype, it’s also faster and consumes fewer resources. That’s really not the point of this article, however.

This point of this article is to show you how you configure Nginx on your server to serve static content that is actually served by GitHub pages.

TL;DR

Create a pages repo
Clone it to your local computer
Check in your static files
Set up your Nginx configuration file
git commit -am"..." && git push
Profit!

GitHub Pages

GitHub alows users to store static web content (HTML, CSS, and JS) in specific repositories. The only real caveat is that you must have index.html in your repository root. Of course, your files will also be public if you are using the free service. This service is called GitHub Pages. Here is this blogs repository.

Content

There are lots of ways to create your site. I use Hugo to generate the blog out of easy-to-generate Markdown files. Nice and relatively simple. However you do it, you’ll need to be able to generate static content.

Nginx

GitHub will serve up your pages to the web world just fine. For this blog, you can go to https://mtik00.github.io to browse it. It looks the same as https://mtik00.com, with the exception of the SSL key. If you want users to go to your custom URL, and you want to manage your own SSL keys, you’ll need to set up an Nginx proxy.

NOTE: If you don’t care about SSL and only want a custom domain, read this instead: https://help.github.com/articles/setting-up-a-custom-domain-with-github-pages/

Since your content is hosted on GitHub, you only need an Nginx configuration file that redirects. Here’s the configuration that I use (without the SSL setup):

server {
    server_name mtik00.com;
    listen 443 ssl spdy;

    # The site is actually hosted on github pages.  Using this proxy location
    # allows us to secure the connection with our own SSL keys, instead of the
    # generic github.io SSL keys.

    location / {
        proxy_pass https://mtik00.github.io;
        proxy_intercept_errors on;

        # allow GitHub to pass caching headers instead of using our own
        expires off;
    }

The magic happens when a user navigates to https://mtik00.com/. When the happens, the location / block matches, and all of the content is silently served from http://mtik00.github.io. How cool is that?

Users will never know (nor will they care).

Why

This might all seem a bit silly. Really, if already have a web server running Nginx, why set up the proxy in the first place? Why not just store your content on the server? Well, the way I see it, this method has the following benefits:

git commit -am"..." && git push is all that’s needed to update your site
Your content won’t take up any space on your web server
You get to control your content entirely

Only you can decide if it’s work it. It is for me. I can decide at any time to move the content off of GitHub, I can create new SSL keys as needed, and all I need to do to update is to push the new pages back up to GitHub.

Folder Structure

As I’ve mentioned before, I use Hugo to generate the static HTML files that are served by GitHub. That, in itself, is a separate repository. I started off with everything in the same repo. It was a little odd, but it wasn’t quite right. My development files were in a folder called dev, and the generated HTML files were in the repo root. I decided to make things a little more complex to make the static html file repo cleaner.

I currently have two projects: 1) My development files; 2) My GitHub pages static HTML files. The trick here is that my GitHub pages repo is a subtree located inside my other repo. It looks like this:

mtik00-pages/
mtik00-pages/mtik00.github.com

The base folder contains my development enviroment (batch files, python scripts, hugo binaries, etc). The only thing mtik00-pages/mtik00.github.com contains are HTML/CSS/JS files. My normal process goes like this:

hugo new content/post
edit the post in SublimeText2
commit the new content: git add . && git commit -am"adding new post"
build the static pages: hugo -d"mtik00.github.com
deploy the static pages: cd mtik00.github.com && git add -A . && git commit -am"new pages" && git push

Wordpress XML to Hugo MD

Thu, 30 Jul 2015 15:39:23 -0600

I’ve had a personal family blog in one form of another since 2002. For the last 10 years, give or take, I used WordPress. It’s a very fine and handy tool; especially for non-technical types. That’s the real issue… I’m a technical type. I started looking for something simpler, easier to maintain, and more secure. That led me to static site generators.

I won’t go into the details, but there are a few to choose from. I settled on Hugo. I was mainly interested in it because it seemed easy, was written in Go, and yes, it had a pretty website.

The Conversion

One of the many nice things about WordPress is the ability to export your site into XML (side note, I loath XML). There are some examples and script that do the conversion for you, but what fun would that be? In the process, I learned that:

Most HTML is Markdown compliant (that is, Markdown “understands” it)
It’s hard to tell an HTML-to-MD converter exactly how you want the HTML parsed.

On to the script! You can view the script here.. I won’t go over it in gory detail, but here are the basics.

WP exports everything, but I was only concerned with the post body, the date it was published (pubDate), the category’s (I called them tags in the script), the title, and where it should go. The last part took some predetermined knowledge of how I wanted my Hugo site to be set up (read [permalinks]). If you look at the exported XML file, there are lots of metadata that I’m ignoring (YMMV).

    tree = ET.parse(xml_path)
    channel = tree.find("channel")
    wp_version_check(channel)

    for post in channel.findall("item"):
        print "post title:", post.find("title").text

WP puts all of the posts in a <channel> element. Each post is located inside an <item> element. So far, so good! Now all we need to do is to loop through each item and grab the data we need.

def wp_to_hugo_date(wp_date):
    """Converts a UTC time string from the WordPress XML to a Hugo time string."""
    date = time.strptime(wp_date, "%a, %d %b %Y %H:%M:%S +0000")
    date = calendar.timegm(date)
    ltime = time.localtime(date)
    date = time.strftime("%Y-%m-%dT%H:%M:%S", ltime)

    date += "%+03i:00" % (-1 * (time.altzone / 3600) if time.daylight else (-1 * (time.timezone / 3600)))
    return ltime, date

I’m using this function to convert the pubDate from WordPress to the format that Hugo uses. Nothing real special here, although I’m sure there’s a much better way to calculate the time zone. The string-formatted pubDate will go into the posts front matter, and I parse ltime to figure out where the post should go.

That’s the basics. I ran this script on my entire WordPress XML dump (only 90+ pages, nothing too big). It created all of the Markdown posts full of HTML. It was up to me to then go in and adjust some of the HTML so it was rendered a little better by Hugo. Most of my time spent was on downloading images, checking them into Git, and reworking the gallery posts to use my new template (which is awesome, because now I can use {{ gallery path/to/gallery/folder }} in my markdown).

The point is, however, I was able to have a fully functioning port of my WordPress blog to Hugo in a matter of hours (the script only took a second to run). Woot!

Archive Place Holder

Sat, 01 Jan 1972 00:00:02 -0600

About Me

Sat, 01 Jan 1972 00:00:01 -0600

I’ve been writing software since I figured out how to hack Lemonade Stand back in the late 1970’s (ok, writing is a bit of a stretch). I absolutely adored my Commodore 64. Man, those power bricks just didn’t last!

My interest in computers never waned. I moved on from my C64, to my parents C128 (dual disk drives! woot!), to a 286, 386, 486, Pentium, and so on. After a short stint in the military, I moved to Colorado Springs to go to school.

I graduated from UCCS in the spring of 1999 with a Bachelors of Electrical Engineering. I really thought I wanted to be an analog designer. That dream was short lived! I soon realized that what truly made me happy was programming. With that knowledge in hand, I went back to school.

I graduated from CTU in the spring of 2005 with a Masters of Science in Software Engineering. I finally had the piece of paper that proved I could write code. I left my semiconductor job for a much-more-software-focused job in electrical test equipment (logic analyzers, to be exact). That worked out great, until they laid me off (no worries, I enjoyed the 3 months severance).

Luckily, I was hired right away. I continue to work in the storage industry, but I’m happy to say I’m 100% software focused! I’ve been writing code to facilitate test automation since 2007 (mainly Python). I really enjoy the challenge and I love the instant feedback I get since my customers sit right next to me.

About The Name

The name mtik, pronouced “em tick”, was my very first EverQuest character (a Gnome Necromancer). I had played quite a bit of Ultima Online prior to the release of EverQuest, but I can’t remember any of my character names. I used mtik as a character name for all of the MMORPGs that followed. It stuck! I became quite fond of it. I added the 00 to the end due to a name-collision when I signed up for something or another.