import site content

16 files changed, 1377 insertions, 0 deletions

diff --git a/content/_index.md b/content/_index.md
new file mode 100644
index 0000000..7a689f0
--- /dev/null
+++ b/content/_index.md
@@ -0,0 +1,13 @@
+---
+title: "Jesse Luehrs"
+---
+
+I am a programmer, currently working for [Stripe](https://stripe.com/).
+
+I was a member of the Fall 1 2014 batch at the [Recurse Center](https://recurse.com/).
+
+I typically go by "doy" [on the internet](/internet/).
+
+I graduated from the [University of Illinois at Urbana-Champaign](https://uiuc.edu/) in 2008.
+
+I'm currently living in New York City.
diff --git a/content/blog/hacker-school-day-1.md b/content/blog/hacker-school-day-1.md
new file mode 100644
index 0000000..8ffe386
--- /dev/null
+++ b/content/blog/hacker-school-day-1.md
@@ -0,0 +1,33 @@
+---
+title: hacker school, day 1
+date: "2014-09-02T19:55:00"
+tags: [hacker school]
+---
+
+So I'm finally starting [Hacker School](https://www.hackerschool.com/). Today
+was partly an orientation day, and I spent a while meeting people and stuff,
+but eventually settled down to work.
+
+For my first project, I decided to work on an IRC bouncer in
+[Rust](http://rust-lang.org/). I've wanted a decent IRC bouncer for a while -
+I'm currently using [ZNC](http://wiki.znc.in/ZNC), which is the only really
+usable one I've found, but it doesn't really handle disconnection well. I'd
+like to be able to just close my laptop and go, and actually get all of the
+messages I missed when I open it back up. The problem is that if you don't
+explicitly disconnect the IRC client, the bouncer has no way of knowing when
+you stopped receiving messages, so messages in that timeout window tend to
+just get dropped, which makes it quite difficult to keep up with
+conversations.
+
+The solution I'm going to try is to split the bouncer into two parts, a client
+and a server. The server still runs as usual, but you run a bouncer client
+locally, and that is what you connect to with your IRC client. The bouncer
+client then talks to the bouncer server using a different protocol which
+allows you to sync unread messages reliably.
+
+The first problem that I ran into is that there doesn't appear to be a
+fully-featured IRC library for Rust yet (in particular, one that can handle
+being a server as well as a client), so... the first step is obviously to
+write one! I've done this before [in Lua](https://github.com/doy/luairc), so I
+don't think this should be an insurmountable obstacle. We'll see how accurate
+that assessment is this week, I suppose.
diff --git a/content/blog/keyboard-mappings.md b/content/blog/keyboard-mappings.md
new file mode 100644
index 0000000..5109b87
--- /dev/null
+++ b/content/blog/keyboard-mappings.md
@@ -0,0 +1,141 @@
+---
+title: keyboard mappings
+date: "2013-11-02T20:54:00"
+tags: [configuration, keyboard]
+---
+
+So I was at the [Pittsburgh Perl Workshop](http://pghpw.org/ppw2013/), and
+[John Anderson](https://twitter.com/genehack) gave a
+[talk](http://pghpw.org/ppw2013/talk/5084) about his personal configuration
+setup. It motivated me to spend quite a bit of time going over [my own
+configuration](https://github.com/doy/conf), but in particular it reminded me
+that I had been wanting to adjust my keyboard for a while now. My pinkies have
+been getting tired more quickly lately, and I'm fairly sure this is in large
+part because of how often I have to use the Shift and Control keys. I do all
+of my work on laptops, so it would be pretty inconvenient to get an external
+keyboard, so I decided to actually put some effort into looking at ways to
+modify my existing keyboard to be easier to type on.
+
+## Control
+
+One of the first things I did was read up ways to avoid finger stress. As it
+turns out, this is especially common in the Emacs community (since so many of
+their keyboard shortcuts rely on weird modifier key combinations), and there's
+even a [project](http://ergoemacs.org/) dedicated to making Emacs more
+ergonomic. One of the things that they do mention is that contrary to popular
+wisdom, [mapping Caps Lock to Control really isn't a very good
+solution](http://ergoemacs.org/emacs/swap_CapsLock_Ctrl.html). They recommend
+swapping Control and Alt instead, since Control is used far more often, and
+you can press the Alt key with your thumb, which is a much stronger finger.
+
+To do this, I added this to my `.Xmodmap`:
+
+    clear control
+    clear mod1
+    keycode 37 Alt_L Meta_L
+    keycode 64 Control_L
+    keycode 105 Alt_R Meta_R
+    keycode 108 Control_R
+    add control = Control_L Control_R
+    add mod1 = Alt_L Alt_R Meta_L Meta_R
+
+## Shift
+
+The next thing I started thinking about was how to reduce the usage of the
+Shift keys. I do a lot of programming, which uses punctuation characters quite
+a bit, and so I started
+[wondering](https://twitter.com/doyster/status/388138795557978112) if swapping
+the shifted and unshifted number row would be a good idea. As it turns out,
+[Brock Wilcox](https://twitter.com/awwaiid) did this [quite a while
+ago](http://thelackthereof.org/Keyboard_Number-Symbol_Swap), and he liked it a
+lot. Using that as a place to start, I came up with [this
+script](https://github.com/doy/conf/blob/master/bin/toggle_numkeys):
+
+    if xmodmap -pk | grep -q '(1).*(exclam).*(1).*(exclam)'; then
+    xmodmap -e 'keycode 10 = exclam 1'
+        xmodmap -e 'keycode 11 = at 2'
+        xmodmap -e 'keycode 12 = numbersign 3'
+        xmodmap -e 'keycode 13 = dollar 4'
+        xmodmap -e 'keycode 14 = percent 5'
+        xmodmap -e 'keycode 15 = asciicircum 6'
+        xmodmap -e 'keycode 16 = ampersand 7'
+        xmodmap -e 'keycode 17 = asterisk 8'
+        xmodmap -e 'keycode 18 = parenleft 9'
+        xmodmap -e 'keycode 19 = parenright 0'
+        xmodmap -e 'keycode 20 = underscore minus'
+        xmodmap -e 'keycode 34 = braceleft bracketleft'
+        xmodmap -e 'keycode 35 = braceright bracketright'
+        xmodmap -e 'keycode 49 = asciitilde grave'
+        xmodmap -e 'keycode 51 = bar backslash'
+    else
+    xmodmap -e 'keycode 10 = 1 exclam'
+        xmodmap -e 'keycode 11 = 2 at'
+        xmodmap -e 'keycode 12 = 3 numbersign'
+        xmodmap -e 'keycode 13 = 4 dollar'
+        xmodmap -e 'keycode 14 = 5 percent'
+        xmodmap -e 'keycode 15 = 6 asciicircum'
+        xmodmap -e 'keycode 16 = 7 ampersand'
+        xmodmap -e 'keycode 17 = 8 asterisk'
+        xmodmap -e 'keycode 18 = 9 parenleft'
+        xmodmap -e 'keycode 19 = 0 parenright'
+        xmodmap -e 'keycode 20 = minus underscore'
+        xmodmap -e 'keycode 34 = bracketleft braceleft'
+        xmodmap -e 'keycode 35 = bracketright braceright'
+        xmodmap -e 'keycode 49 = grave asciitilde'
+        xmodmap -e 'keycode 51 = backslash bar'
+    fi
+
+I bound the script to pressing both Shift keys at once as Brock recommended
+(using xbindkeys):
+
+    "toggle_numkeys"
+      Shift + Shift_R
+
+    "toggle_numkeys"
+      Shift + Shift_L
+
+and also set it to run when I logged into X. Note that this also maps a few
+other things - besides just the number row, it also makes tilde, underscore,
+left and right brace, and pipe into the unshifted characters for their
+respective keys. Underscore was the biggest win, I think - typing
+`$variable_names_with_lots_of_words_in_them` was always a pretty big strain.
+
+Again as Brock pointed out, I had to remap the keys in some other applications
+to make them stay usable. Strangely enough, both i3 and Firefox continued to
+work (I have `Mod4+1`, etc mapped to switching desktops in i3, and Firefox
+uses `Alt+1`, etc for tab switching). Not really sure what's going on there. I
+did have to add some remappings for the hint mode in
+[Pentadactyl](http://5digits.org/pentadactyl/) though:
+
+    set hintkeys=")!@#$%^&*("
+
+Zsh, readline, and vim also required remapping `)` to `0`, since I use the `0`
+command a lot. Here's from vimrc:
+
+    nmap <silent>) 0
+
+and zshrc:
+
+    bindkey -M vicmd ')' vi-digit-or-beginning-of-line
+
+and inputrc:
+
+    ")": beginning-of-line
+
+I couldn't figure out how to get the number keys in choose-window mode in tmux
+to remap (if anyone has any clues, let me know), but I did rebind the
+copy-mode command:
+
+    bind { copy-mode
+
+So far, I've been using this setup for a little over two weeks, and I'm liking
+it a lot. My fingers are noticeably less tired, and I feel like my typing
+speed while programming is quite a bit faster. A lot of things feel more
+natural too - for instance, `my ($foo_bar, $baz) = @_;` is now typed entirely
+without pressing the Shift key, which feels much better. One thing that does
+still bother me is that `(:` now requires one shifted and one non-shifted key,
+which makes it harder to type, but I'm fairly sure that overall I use `;` more
+than `:`, so I don't think switching that is worthwhile.
+
+In addition to these keyboard remappings, I also remapped a bunch of things in
+vim to use fewer keystrokes, but I'll talk about that in a future post.
diff --git a/content/blog/writing-an-nes-game-inside-the-cartridge.md b/content/blog/writing-an-nes-game-inside-the-cartridge.md
new file mode 100644
index 0000000..14f8891
--- /dev/null
+++ b/content/blog/writing-an-nes-game-inside-the-cartridge.md
@@ -0,0 +1,12 @@
+---
+title: writing an nes game - inside the cartridge
+date: "2014-10-14T12:00:00"
+tags: [hacker school, nes]
+---
+
+As an aside, this is what the inside of an NES cartridge looks like:
+
+![cartridge image](/blog/cartridge.jpg)
+
+Note specifically the two physical ROM banks, one labeled PRG and the other
+labeled CHR (and basically nothing else on the circuit board).
diff --git a/content/blog/writing-an-nes-game-part-1.md b/content/blog/writing-an-nes-game-part-1.md
new file mode 100644
index 0000000..b683980
--- /dev/null
+++ b/content/blog/writing-an-nes-game-part-1.md
@@ -0,0 +1,184 @@
+---
+title: writing an nes game, part 1
+date: "2014-10-13T16:00:00"
+tags: [hacker school, nes]
+---
+
+For the past week or so at Hacker School, I've been learning how to write
+games for the NES. This was intended to just be a brief debugging detour for a
+different project I was working on, but as these things tend to go, it turned
+into an entire project on its own. You can see the end result at
+[https://github.com/doy/nes-snake](https://github.com/doy/nes-snake), but I
+wanted to go over the code to give an overview about what programming for the
+NES is like.
+
+The NES itself has three processors - a [6502
+CPU](https://en.wikipedia.org/wiki/MOS_Technology_6502), a custom graphics
+chip called the PPU (picture processing unit), and a custom sound chip called
+the APU (audio processing unit, which I didn't use for this project). Game
+data is stored in [ROM](https://en.wikipedia.org/wiki/Read-only_memory) banks,
+typically with code and sprite data separate - code is stored in PRG-ROM
+(which consists of some number of 16KB banks) and sprite data is stored in
+CHR-ROM (which consists of some number of 8KB banks). The only difference
+between these two (other than the size) is that PRG-ROM is mapped to the
+address space of the CPU and CHR-ROM is mapped to the address space of the PPU
+(the different chips also have different address spaces). My game is simple
+enough to only require a single PRG-ROM bank and a single CHR-ROM bank.
+
+The CPU in the NES has a single flat 16-bit address space, which contains
+everything from system RAM (there is only 2KB of this), to [memory-mapped IO
+ports](https://en.wikipedia.org/wiki/Memory-mapped_I/O) (so reading or writing
+at specific memory locations doesn't actually access any memory, it instead
+accesses some hardware pins), to battery-backed RAM on the cartridge itself
+(if availble), to the actual program ROM. The PPU has its own entirely
+separate 14-bit address space, which mostly holds raw sprite data, color
+palettes, and information about which sprites should be drawn in which
+locations on the screen (that last part is typically the only thing that needs
+to be touched in a simple game).
+
+So this is what the basic skeleton of a small NES program (which uses a
+single 16KB PRG-ROM bank and a single 8KB CHR-ROM bank) looks like:
+
+```asm
+; .ROMBANKMAP describes the layout of the ROM banks that this assembly file
+; will produce. They will end up laid out sequentially in the output file. In
+; this case, we're writing a game that requires one 16KB PRG-ROM bank and one
+; 8KB CHR-ROM bank, so we specify that there are two banks in total, and we
+; then specify the sizes for each of those two banks. The output file, once
+; linked, will be a 24KB file, where the first 16KB is the PRG-ROM data and
+; the last 8KB is the CHR-ROM data.
+.ROMBANKMAP
+BANKSTOTAL  2
+BANKSIZE    $4000 ; PRG-ROM is 16KB
+BANKS       1
+BANKSIZE    $2000 ; CHR-ROM is 8KB
+BANKS       1
+.ENDRO
+
+; .MEMORYMAP describes how the ROM banks will be loaded into memory. On the
+; NES, program ROM has $8000-$FFFF available to it in the address space (which
+; corresponds to two banks of PRG-ROM data), but if you're only using a single
+; bank, it is typically loaded at $C000 (since the interrupt vectors must be
+; located at $FFFA/$FFFC/$FFFE). The CHR-ROM data isn't mapped into the main
+; address space (it is instead mapped into the PPU's address space), so it
+; doesn't actually matter what address we tell it to load into.
+.MEMORYMAP
+DEFAULTSLOT  0
+SLOTSIZE     $4000
+SLOT 0       $C000 ; a single PRG-ROM bank should be mapped at $C000
+SLOTSIZE     $2000
+SLOT 1       $0000 ; this location doesn't matter, CHR-ROM isn't in main memory
+.ENDME
+
+; .ENUM just creates a mapping of names to values. Variables don't actually
+; exist in assembly - all you have is memory locations, and so variables
+; can be simulated by creating aliases to locations in memory.
+; .ENUM is just a convenient shortcut for defining labels that point
+; to data. On the NES, the internal system RAM is located at $0000-$0800 (2KB),
+; and so we can just define labels that point into that section of memory and
+; use them as variables. In addition, most 6502 opcodes are shorter and faster
+; if they are accessing memory within $0000-$00FF (called the "zero page"), and
+; so we should try to put most common variables within that portion of memory.
+; In addition to putting variables in the zero page, NES programs typically use
+; $0100-$01FF for the stack (used by the PHA/PLA instructions) and $0200-$02FF
+; for holding sprite data until it can be copied to the PPU, so you should
+; avoid using those sections of RAM for arbitrary game data.
+.ENUM $00
+; global variable declarations go here
+.ENDE
+
+; This defines the first ROM bank (bank 0), and indicates that it will be
+; loaded into slot 0 as defined above. 
+  .bank 0 slot 0
+; .org indicates the offset that the following assembly code will be created
+; at, relative to the start of the current ROM bank. In this case, we're using
+; an offset of $0000, so this code will be loaded into the NES address space
+; starting at $C000.
+  .org $0000
+
+; The RESET label is the code that will be jumped to at power on (see below)
+RESET:
+  ; TODO: initialization code goes here
+loop:
+  ; TODO: game code goes here
+  JMP loop
+
+; The NMI label is the code that will be jumped to at the start of each frame
+; (see below)
+NMI:
+  ; TODO: per-frame drawing code goes here
+  RTI
+
+; .orga defines the absolute address that the following assembly code will be
+; created at. It must be a value within the current ROM bank. We're using .orga
+; here because $FFFA is a special value to the NES, and so using it literally
+; makes the code easier to understand. $FFFA is the start of three interrupt
+; vectors that define which code to run when various things happen. The first
+; one is the NMI handler, which runs on each frame. The second is the RESET
+; handler, which runs at system startup. The third is the IRQ handler, which
+; runs on external interrupts (usually from the APU or various external chips).
+; We don't use the IRQ handler because we aren't doing any sound, and we aren't
+; using any external chips, so it is just set to 0 (which disables it).
+  .orga $FFFA
+  .dw NMI   ; $FFFA contains the address to jump to at the start of each frame
+  .dw RESET ; $FFFC contains the address to jump to at power-on
+  .dw 0     ; $FFFE contains the address to jump to on an external interrupt
+
+; This defines the second bank, which holds the CHR-ROM.
+  .bank 1 slot 1
+  .org $0000
+; .incbin includes the contents of an external file literally into the output.
+; Here, sprites.chr should contain the literal contents of the CHR-ROM. This is
+; easier because the CHR-ROM doesn't contain any code, so defining it inline in
+; the assembly code file would be quite a bit less convenient. I'll talk about
+; ways to actually edit this file later.
+  .incbin "sprites.chr" ; sprites.chr should be 8192 bytes
+```
+
+This is using the syntax for the WLA DX assembler, which works well on Linux
+(most of the existing tutorials I've seen use various Windows-only
+assemblers). I'm using the
+[`wla_dx`](https://aur.archlinux.org/packages/wla_dx/) AUR package on Arch
+Linux, but similar packages should be available for most distros. To compile
+this code, follow these steps:
+
+* Save the code as `test.s`
+* Run `dd if=/dev/zero of=sprites.chr bs=8192 count=1` to create an empty CHR
+  data file (which will be included in the output)
+* Run `wla-6502 -o test.s` to generate an object file called `test.o`
+* Create a file named `linkfile` which is used by the linker, with the contents
+
+```
+[objects]
+test.o
+```
+
+* Run `wlalink linkfile test.rom` to create the actual ROM
+
+This ROM is not yet in the format required to be run by most NES emulators. To
+get it into this format, we need to add a 16-byte header which describes the
+layout of the file. You can download the header I used from
+[here](https://raw.githubusercontent.com/doy/nes-snake/master/header.bin) - it
+specifies a layout containing one PRG-ROM bank and one CHR-ROM bank. If you're
+interested in doing something different, you should read up on the [iNES ROM
+format](http://wiki.nesdev.com/w/index.php/INES).
+
+Once you have a file containing the header, you can create a file that will
+actually work in an NES emulator by running `cat header.bin test.rom >
+test.nes`. To run the ROM, I highly recommend using an emulator that aims for
+accuracy - a lot of emulators out there aim for compatibility, which typically
+means hacks for specific known games, and which will quite possibly just
+result in breaking games that they don't know about (including new games you
+are writing). Nestopia is a good recommendation if you don't know much about
+the subject. To execute the ROM you just created, run `nestopia test.nes`. You
+should just see a blank screen, since we haven't included any code to make it
+do anything differently, but it should successfully load and run.
+
+Next time I'll talk about the structure of the actual code in an NES game. For
+further information about the topics in this post, here are some useful links:
+
+* [WLA DX assembler reference](http://www.villehelin.com/wla.txt)
+* [NES Assembly Tutorial](http://nixw0rm.altervista.org/files/nesasm.pdf)
+* [NES Architecture](http://fms.komkon.org/EMUL8/NES.html)
+* [NES 101](http://hackipedia.org/Platform/Nintendo/NES/tutorial%2c%20NES%20programming%20101/NES101.html)
+* [NES technical documentation](http://emu-docs.org/NES/nestech.txt)
diff --git a/content/blog/writing-an-nes-game-part-2.md b/content/blog/writing-an-nes-game-part-2.md
new file mode 100644
index 0000000..d2cd675
--- /dev/null
+++ b/content/blog/writing-an-nes-game-part-2.md
@@ -0,0 +1,257 @@
+---
+title: writing an nes game, part 2
+date: "2014-10-14T15:30:00"
+tags: [hacker school, nes]
+---
+
+# code layout
+
+So before we get into the code itself, there are a couple more concepts that
+will be important to understand, in order to understand why the code is laid
+out the way it is.
+
+First, we need to understand how the PPU handles drawing. The NES was designed
+to work on CRT screens, which work by drawing a horizontal line at a time from
+the top of the screen to the bottom, at which point it starts again at the
+top. This is done by a device called an [electron
+gun](https://en.wikipedia.org/wiki/Electron_gun), which fires electrons at a
+screen of pixels. The key point here is that drawing is done sequentially, one
+pixel at a time, and the mechanism requires some amount of time to move from
+one line to the next, and to move from the bottom of the screen back to the
+top. The period of time when the electron gun is moving from the end of one
+line to the beginning of the next is called the "HBlank" time, and the period
+of time when the electron gun is moving from the bottom of the screen back to
+the top is called the "VBlank" time. Except during HBlank and VBlank, the PPU
+is busy controlling what actually needs to be drawn, and manipulating it at
+all can cause all kinds of weird graphical glitches, so we need to make sure
+we only communicate with the PPU during HBlank or VBlank.
+
+The way the NES handles this is to provide an interrupt (called NMI) which
+fires at the beginning of every VBlank, which allows you to do all of your
+drawing during a safe period of time. HBlank is harder to detect and not as
+useful (since it occurs in the middle of drawing a frame), and so it is not
+typically used except for some visual effects. NTSC television screens refresh
+at 60 frames per second, and the CPU clock speed in the NES is approximately
+1.79MHz, and so we get approximately 30,000 CPU cycles per frame, which
+translates into roughly 5,000-10,000 opcodes. VBlank, though, only lasts
+around 2273 cycles (roughly 400-800 opcodes), so drawing code needs to be
+especially efficient. In particular, we don't want to do any game logic at all
+during VBlank time, since that time is so limited.
+
+The other aspect that needs to be handled is system initialization. When the
+CPU starts up, it's in an undefined state, so we need to set things up to
+ensure that the game executes in a repeatable way. Emulators tend to be
+consistent in how they initialize the system state at startup, but this isn't
+true of the real hardware, so it's important to do this explicitly. Also, the
+PPU requires initialization, but that is handled automatically. It does take a
+bit over 30,000 CPU cycles though (a little over one frame), so we wait for
+two frames before starting our main game code. Two frames is plenty of time to
+do any initialization we might need to do.
+
+To illustrate these concepts, here is an example program which modifies the
+background color every second. The details about how the background color is
+set isn't particularly important (it's not really a feature you're likely to
+use very often), but this should illustrate the basic structure of an NES
+game. This isn't intended to be a lesson on 6502 assembly (there are plenty of
+much better tutorials and references out there for that - see below), but just
+to show how games for the NES specifically are structured.
+
+```asm
+.ROMBANKMAP
+BANKSTOTAL  2
+BANKSIZE    $4000
+BANKS       1
+BANKSIZE    $2000
+BANKS       1
+.ENDRO
+
+.MEMORYMAP
+DEFAULTSLOT  0
+SLOTSIZE     $4000
+SLOT 0       $C000
+SLOTSIZE     $2000
+SLOT 1       $0000
+.ENDME
+
+.ENUM $00
+; declare the label 'sleeping' to refer to the byte at memory location $0000
+sleeping     DB
+; 'color' will then be at $0001
+color        DB
+; and 'frame_count' will be at $0002
+frame_count  DB
+.ENDE
+
+  .bank 0 slot 0
+  .org $0000
+RESET:
+  ; First, we disable pretty much everything while we try to get the system
+  ; into a consistent state. In particular, we really don't want any
+  ; interrupts to fire until the stack pointer is set up (because interrupt
+  ; calls use the stack), and we don't want any drawing to be done until the
+  ; PPU is initialized. 
+  SEI              ; disable all IRQs
+  CLD              ; disable decimal mode
+  LDX #$FF
+  TXS              ; Set up stack (grows down from $FF to $00, at $0100-$01FF)
+  INX              ; now X = 0
+  STX $2000.w      ; disable NMI (we'll enable it later once the ppu is ready)
+  STX $2001.w      ; disable rendering (we're not using it in this example)
+  STX $4010.w      ; disable DMC IRQs
+  LDX #$40
+  STX $4017.w      ; disable APU frame IRQ
+
+  ; First wait for vblank to make sure PPU is ready. The processor sets a
+  ; status bit when vblank ends, so we just loop until we notice it.
+vblankwait1:
+  BIT $2002        ; bit 7 of $2002 is reset once vblank ends
+  BPL vblankwait1  ; and bit 7 is what is checked by BPL
+
+  ; set everything in ram ($0000-$07FF) to $00, except for $0200-$02FF which
+  ; is conventionally used to hold sprite attribute data. we set that range
+  ; to $FE, since that value as a position moves the sprites offscreen, and
+  ; when the sprites are offscreen, it doesn't matter which sprites are
+  ; selected or what their attributes are
+clrmem:
+  LDA #$00
+  STA $0000, x
+  STA $0100, x
+  STA $0300, x
+  STA $0400, x
+  STA $0500, x
+  STA $0600, x
+  STA $0700, x
+  LDA #$FE
+  STA $0200, x
+  INX
+  BNE clrmem
+
+  ; initialize variables in ram
+  LDA #%10000001
+  STA color
+  ; no need to initialize frame_count or sleeping, since we just set them to
+  ; $00 in the clrmem loop
+
+  ; Second wait for vblank, PPU is ready after this
+vblankwait2:
+  BIT $2002
+  BPL vblankwait2
+
+  LDA #%10000000   ; enable NMI interrupts now that the PPU is ready
+  STA $2000
+
+loop:
+  ; sleep while vblank is happening. this serializes the code flow a bit
+  ; (the NMI interrupt will almost certainly occur while we are in this loop
+  ; unless we do a significant amount of processing in the main codepath, so
+  ; it won't interrupt anything important). it also ensures that our game
+  ; logic only executes once per frame.
+  INC sleeping
+wait_for_vblank_end:
+  LDA sleeping
+  BNE wait_for_vblank_end
+
+  ; change color every 60 frames
+  LDX frame_count
+  CPX #60
+  BCS change_color
+  INX
+  STX frame_count
+  JMP loop_end
+
+change_color:
+  LDA #$00
+  STA frame_count
+  LDX color
+  CPX #%10000001
+  BEQ turn_green
+  CPX #%01000001
+  BEQ turn_red
+
+turn_blue:
+  LDA #%10000001
+  STA color
+  JMP loop_end
+turn_green:
+  LDA #%01000001
+  STA color
+  JMP loop_end
+turn_red:
+  LDA #%00100001
+  STA color
+
+loop_end:
+  JMP loop
+
+NMI:
+  ; save the contents of the registers on the stack, since the interrupt can
+  ; be called at any point in our main loop
+  PHA
+  TXA
+  PHA
+  TYA
+  PHA
+
+  LDA color
+  STA $2001
+
+  ; indicate that we're done drawing for this frame
+  LDA #$00
+  STA sleeping
+  ; and restore the register contents before returning
+  PLA
+  TAY
+  PLA
+  TAX
+  PLA
+
+  RTI
+
+  .orga $FFFA
+  .dw NMI
+  .dw RESET
+  .dw 0
+
+  .bank 1 slot 1
+  .org $0000
+  .incbin "sprites.chr"
+```
+
+The first thing we do when the system turns on is disable IRQ interrupts.
+Calling and returning from interrupts uses the system stack, but the stack
+pointer could be pointing anywhere at this point, and so interrupts would be
+confuse things quite a bit. We never reenable IRQ interrupts here because we
+don't use them at all (they would be reenabled by the `CLI` instruction). Next
+we disable decimal mode (this shouldn't actually do anything, since the NES
+doesn't have a BCD chip, but no real reason not to do this, to avoid
+confusion) and set the stack pointer to `$FF`. The stack pointer is stored in
+the register named S, and it is a one-byte offset from the RAM address
+`$0100`. The stack grows downward, so the stack pointer should start out
+pointing to `$01FF`, and then it will be decremented by `PHA` instructions and
+incremented by `PLA` instructions as necessary. Finally, we disable a bunch of
+other functionality on the PPU and APU, since we don't want them to be active
+until we have finished initializing.
+
+We need to wait for a total of two frames to ensure that the PPU is entirely
+initialized, so we next wait for the first frame to end, and then clear out
+the entire RAM space, and then wait for the second frame to end. At this
+point, the PPU is initialized, so we can enable NMI interrupts (by setting a
+bit in the PPU control register at `$2000`) and begin our main loop.
+
+The main loop is where all of the logic goes. In this example, we just
+increment the frame count every frame, and change the background color (via
+some magic) every 60 frames. This allows the NMI interrupt to do nothing more
+than write a single value to the PPU, without requiring any logic at all. This
+illustrates the basic principle of using the main game loop to set up values
+in memory, which the code in the NMI interrupt can just read and act on
+directly, without requiring any calculations.
+
+Here are some more useful links discussing the topics in this post:
+
+* [NES ASM Tutorial](http://nixw0rm.altervista.org/files/nesasm.pdf)
+* [The frame and NMIs](http://wiki.nesdev.com/w/index.php/The_frame_and_NMIs)
+* [6502 instruction set
+  overview](http://www.dwheeler.com/6502/oneelkruns/asm1step.html)
+* [6502 instruction set
+  reference](http://e-tradition.net/bytes/6502/6502_instruction_set.html)
+* [NES technical documentation](http://emu-docs.org/NES/nestech.txt)
diff --git a/content/blog/writing-an-nes-game-part-3.md b/content/blog/writing-an-nes-game-part-3.md
new file mode 100644
index 0000000..749b76d
--- /dev/null
+++ b/content/blog/writing-an-nes-game-part-3.md
@@ -0,0 +1,95 @@
+---
+title: writing an nes game, part 3
+date: "2014-10-15T15:30:00"
+tags: [hacker school, nes]
+---
+
+# input handling
+
+Now that we have a general idea of how a program for the NES is structured,
+it'd be useful to get a bit further into the specific capabilities of the NES.
+One of the pretty basic (and pretty important) ones is reading input from the
+controllers.
+
+The basic structure of an NES controller is a [shift
+register](https://en.wikipedia.org/wiki/Shift_register). To read the
+controller inputs, you send a signal to the latch pin, which stores the state
+of the input buttons in the register, and then you send a sequence of signals
+to the clock pin to put the state of each button on the output in sequentially
+(A, B, Select, Start, Up, Down, Left, Right). As it turns out, the code you
+have to write to read from the controller maps pretty exactly to these
+operations. This is what it looks like:
+
+```asm
+read_controller1:
+  ; memory address $4016 corresponds to the shift register inside the
+  ; controller plugged into the first controller port. writing to it sets the
+  ; state of the latch pin, and so we set the latch pin high and then low in
+  ; order to store the controller state in the shift register.
+  LDA #$01
+  STA $4016
+  LDA #$00
+  STA $4016
+
+  ; reading from $4016 reads the output value of the data pin and also sends a
+  ; signal to the clock pin in order to put the next bit of data on the output
+  ; for the next read. the value that is read has the state of the button in
+  ; the low bit, and the upper bits contain various other pieces of
+  ; information (such as whether a controller is plugged in at all, etc), so
+  ; if we only care about the state of the button we have to mask out
+  ; everything else.
+read_a:
+  LDA $4016
+  AND #%00000001
+  BEQ read_b
+  ; code for if the a button is pressed
+read_b:
+  LDA $4016
+  AND #%00000001
+  BEQ read_select
+  ; code for if the b button is pressed
+read_select:
+  LDA $4016
+  AND #%00000001
+  BEQ read_start
+  ; code for if the select button is pressed
+read_start:
+  LDA $4016
+  AND #%00000001
+  BEQ read_up
+  ; code for if the start button is pressed
+read_up:
+  LDA $4016
+  AND #%00000001
+  BEQ read_down
+  ; code for if the up button is pressed
+read_down:
+  LDA $4016
+  AND #%00000001
+  BEQ read_left
+  ; code for if the down button is pressed
+read_left:
+  LDA $4016
+  AND #%00000001
+  BEQ read_right
+  ; code for if the left button is pressed
+read_right:
+  LDA $4016
+  AND #%00000001
+  BEQ end_read_controller1
+  ; code for if the right button is pressed
+
+end_read_controller1:
+  RTS
+```
+
+Obviously this could be simplified by putting the reads in a loop (the [snake
+game](https://github.com/doy/nes-snake) handles it by shifting and packing all
+of the button states into a single byte which the code can query later on),
+but that does require more CPU cycles, especially if not all of the buttons
+are important.
+
+In the spirit of continuing with real working code,
+[here](/blog/input.s) is a sample program which changes the
+background color every time you press A, rather than every second like last
+time. Tomorrow, we'll work on drawing sprites!
diff --git a/content/blog/writing-an-nes-game-part-4.md b/content/blog/writing-an-nes-game-part-4.md
new file mode 100644
index 0000000..87a4257
--- /dev/null
+++ b/content/blog/writing-an-nes-game-part-4.md
@@ -0,0 +1,186 @@
+---
+title: writing an nes game, part 4
+date: "2014-10-19T20:00:00"
+tags: [hacker school, nes]
+---
+
+# graphics
+
+Now that we can handle input, it's time to learn how to draw things. All
+drawing on the NES is handled by the PPU. The PPU does sprite-based drawing,
+meaning that all drawing is two dimensional, and happens in 8x8 blocks. Colors
+are determined by a 16-color palette, of which a given sprite can only use
+four colors (transparency being one of the colors). There is a background
+layer, containing 32x30 tiles, and a set of up to 64 sprites, which can each
+be either in front of or behind the background.
+
+The PPU has its own memory space and mostly just runs on its own, handling the
+redrawing automatically every frame. In order to tell it what to do, we have
+to load various bits of data into its memory. As mentioned in an earlier post,
+the PPU is only capable of doing one thing at a time, so this drawing must
+happen at the beginning of the NMI interrupt, when we are guaranteed to be in
+VBlank.
+
+There are four steps involved in drawing a sprite. First, we need the sprite
+itself. The pixel data for sprites is stored in the *pattern table*, and is
+typically (although not always) stored in CHR-ROM. It contains 16 bytes per
+sprite, where each pixel contains two bits of data, so each sprite can contain
+at most four colors (including transparent). Since CHR-ROM banks are 8KB
+each, this provides enough room for two sets of 256 tiles - typically one set
+is used for the background and the other set is used for foreground sprites,
+although this is not required. The patterns are laid out in memory as two
+chunks of 8 bytes each, where the first 8 bytes correspond to the high bit for
+the pixel, and the second 8 bytes correspond to the low bit for the pixel
+(each byte representing a row of pixels in the sprite). To help with
+generating this sprite data, I have written a script called
+[pnm2chr](https://metacpan.org/pod/distribution/Games-NES-SpriteMaker/bin/pnm2chr),
+which can convert images in the .PBM/.PGM/.PPM formats (which most image
+editors can produce) into CHR-ROM data, so that you can edit sprites in an
+image editor instead of a hex editor.
+
+Once we have the pattern data, we then need the *palette table*, to determine
+the actual colors that will be displayed for a given sprite. The way that
+colors are determined is actually quite convoluted, going through several
+layers of indirection. As a basis, the NES is capable of producing 52 distinct
+colors (actually 51, since one of the colors ($0D) is outside of the NTSC
+[gamut](https://en.wikipedia.org/wiki/Gamut), and can damage older TVs if
+used). From those 52 colors, only 16 can be used at a time (although the 16
+colors can be distinct for the background layer and the sprite layer), and
+this set of 16 colors is known as the palette.
+
+To determine which palette color to use for each pixel in a given background
+tile, the two bits from the pattern table are combined with two additional
+bits of data from the *attribute table* to create a four bit number (the
+pattern bits being the low bits and the attribute bits being the high bits).
+The attribute table is a 64-byte chunk of memory which stores two bits for
+each 16x16 pixel area of the screen (so each sprite shares the same two-bit
+palette with three other sprites in a 2x2 block). The attribute data itself is
+packed into bytes such that each byte corresponds to a 4x4 block of sprites.
+This is all pretty confusing, so here is a diagram (from the [NES Technical
+Documentation](http://emu-docs.org/NES/nestech.txt)) which will hopefully make
+things a bit clearer:
+
+    +------------+------------+
+    |  Square 0  |  Square 1  |  #0-F represents an 8x8 tile
+    |   #0  #1   |   #4  #5   |
+    |   #2  #3   |   #6  #7   |  Square [x] represents four (4) 8x8 tiles
+    +------------+------------+   (i.e. a 16x16 pixel grid)
+    |  Square 2  |  Square 3  |
+    |   #8  #9   |   #C  #D   |
+    |   #A  #B   |   #E  #F   |
+    +------------+------------+
+
+     Attribute Byte
+       (Square #)
+    ----------------
+        33221100
+        ||||||+--- Upper two (2) colour bits for Square 0 (Tiles #0,1,2,3)
+        ||||+----- Upper two (2) colour bits for Square 1 (Tiles #4,5,6,7)
+        ||+------- Upper two (2) colour bits for Square 2 (Tiles #8,9,A,B)
+        +--------- Upper two (2) colour bits for Square 3 (Tiles #C,D,E,F)
+
+For sprites, the upper two bits of the palette index is specified when
+requesting the sprite to be drawn.
+
+The data about which background tile to draw is then stored in the *name
+table*. This is a sequence of bytes which correspond to offsets into the
+pattern table. For instance, to draw the first pattern in the pattern table,
+you would write a $00 to the corresponding location in the name table. The
+name table data is the combined with the appropriate attribute table data to
+get a palette index, which is then looked up in the palette table to determine
+the actual colors to use when drawing the tile.
+
+The data about which sprites to draw is stored in an entirely separate area of
+memory (not part of any address space at all), called the SPR-RAM (sprite
+RAM). It is 256 bytes long, and holds four bytes for each of the 64 sprites
+that the NES is capable of drawing at any given time. The first byte holds the
+vertical offset for the sprite (where the top left of the screen is (0, 0)),
+the second byte holds the index into the pattern table for the sprite to draw,
+the third byte holds various attributes about the sprite, and the fourth byte
+holds the horizontal offset for the sprite. The sprite attributes contain
+these bits of data:
+
+* The low two bits (bits 0 and 1) contain the high bits of the palette index,
+  as described above.
+* Bit 5 is set if the sprite should be drawn behind the background.
+* Bit 6 is set if the sprite should be flipped horizontally.
+* Bit 7 is set if the sprite should be flipped vertically.
+
+If you don't need all 64 sprites, you should just move the horizontal and
+vertical coordinates such that the sprite is offscreen ($FE or so).
+
+Now that we have seen all of the different pieces of the PPU memory, here is
+how it is all laid out in memory:
+
+    $0000: Pattern Table 0 (typically in CHR-ROM)
+    $1000: Pattern Table 1 (typically in CHR-ROM)
+    $2000: Name Table 0
+    $23C0: Attribute Table 0
+    $2400: Name Table 1
+    $27C0: Attribute Table 1
+    $2800: (used for mirroring, which I won't discuss here)
+    $2BC0: (used for mirroring, which I won't discuss here)
+    $2C00: (used for mirroring, which I won't discuss here)
+    $2FC0: (used for mirroring, which I won't discuss here)
+    $3000: (used for mirroring, which I won't discuss here)
+    $3F00: Palette Table 0 (used for the background)
+    $3F10: Palette Table 1 (used for sprites)
+    $3F20: (used for mirroring, which I won't discuss here)
+    $4000: (used for mirroring, which I won't discuss here)
+
+So, to draw a background sprite at the top left of the screen, you would write
+the sprite index to VRAM address $2000 (assuming default settings).
+
+The final piece of information necessary to be able to use the PPU is how to
+transfer data from main memory into VRAM. This is done via certain
+memory-mapped IO addresses.
+
+First, to copy data into SPR-RAM, you should write all of the sprite data to a
+single page (a page is a 256-byte chunk of data whose addresses all start with
+the same byte) in RAM, and then write the page number into address $4014 (the
+$02 page ($0200-$02FF) is typically used for this purpose). The address to
+start writing from can be set by writing a byte to address $2003, and so you
+typically want to write $00 into $2003 before starting a full page transfer
+with $4014. If you want to write to only certain parts of SPR-RAM, you can do
+this via address $2004 - set the base address to write to via $2003 as above,
+and then write a sequence of bytes to $2004 to store them into SPR-RAM.
+
+To copy data into the main VRAM address space, you use the addresses $2006 and
+$2007 in the same way that $2003 and $2004 were used for SPR-RAM, except that
+you need to write two bytes into $2006 before you start writing to $2007,
+since the address space is larger. Since the order of the bytes matters here,
+you can read from $2002 to ensure that the next byte written to $2006 will be
+the high byte of the address. Note that $2006 is also used for scrolling
+(which is based on the last address written to), and so you generally want to
+write $2000 back into $2006 at the end of drawing.
+
+Finally, you need to initialize the PPU in a few ways in order to allow
+drawing, which is done via $2000 and $2001. These addresses hold quite a few
+different configuration bits, but the most important ones are:
+
+* Bit 7 of $2000 should be set to enable NMI interrupts (we did this last
+  time).
+* Bit 4 of $2000 should be set to use pattern table 1 instead of 0 for
+  the background.
+* Bit 3 of $2000 should be set to use pattern table 1 instead of 0 for
+  sprites.
+* Bit 0 of $2000 should be set to use name table 1 instead of 0 (this is
+  actually more complicated due to mirroring, but we won't get into that).
+* Bit 4 of $2001 should be set to enable the sprite layer.
+* Bit 3 of $2001 should be set to enable the background layer.
+
+The default pattern and name tables will be fine for now, and so
+initialization should set $2000 to $%10000000 and $2001 to $%00011000.
+
+[Here](/blog/sprites.s) is a sample program which draws a background
+and a sprite, and allows you to move the sprite around the background with the
+controller D-pad. It will require a CHR-ROM data file with actual patterns in
+it, so you can download that from [here]({{urls.media}}/sprites.chr)
+
+Further reading:
+* [NES ASM Tutorial](http://nixw0rm.altervista.org/files/nesasm.pdf)
+* [NES technical documentation](http://emu-docs.org/NES/nestech.txt)
+* [NES ROM Quickstart](http://sadistech.com/nesromtool/romdoc.html)
+* [NES 101](http://hackipedia.org/Platform/Nintendo/NES/tutorial%2c%20NES%20programming%20101/NES101.html)
+* [CHR ROM vs. CHR RAM](http://wiki.nesdev.com/w/index.php/CHR_ROM_vs._CHR_RAM)
+* [CHR data layout for The Legend of Zelda](http://www.computerarcheology.com/wiki/wiki/NES/Zelda) (Note that unlike what is described above, Zelda stores its pattern data in RAM rather than ROM.)
diff --git a/content/contact.md b/content/contact.md
new file mode 100644
index 0000000..bba4997
--- /dev/null
+++ b/content/contact.md
@@ -0,0 +1,7 @@
+---
+title: "contact info"
+---
+
+* **Email**: doy at tozt dot net
+* **Twitter**: @doyster
+* **IRC**: doy (on irc.freenode.net)
diff --git a/content/internet.md b/content/internet.md
new file mode 100644
index 0000000..88005c2
--- /dev/null
+++ b/content/internet.md
@@ -0,0 +1,12 @@
+---
+title: "me elsewhere on the internet"
+---
+
+* [Twitter](https://twitter.com/doyster)
+* [GitHub](https://github.com/doy)
+* [CPAN](https://metacpan.org/author/DOY)
+* [last.fm](https://www.last.fm/user/doyster)
+* [Project Euler](https://projecteuler.net/index.php?section=profile&profile=doy)
+* [Steam](https://steamcommunity.com/id/doyster/)
+* [nethack.alt.org](https://alt.org/nethack/plr.php?player=doy)
+* [crawl.akrasiac.org](http://crawl.akrasiac.org/scoring/players/doy.html)
diff --git a/content/projects.md b/content/projects.md
new file mode 100644
index 0000000..1ec7fe3
--- /dev/null
+++ b/content/projects.md
@@ -0,0 +1,106 @@
+---
+title: "projects i've worked on"
+---
+
+### conf
+
+* [Source](https://github.com/doy/conf)
+
+My (extensive) collection of configuration files.
+
+### runes
+
+* [Source](https://github.com/doy/runes)
+
+Runes is a VT100 terminal emulator for Linux written in C.
+
+### reply
+
+* [CPAN](https://metacpan.org/release/Reply)
+* [Source](https://github.com/doy/reply)
+
+Reply is a customizable and lightweight REPL for Perl. It provides features
+like pluggable tab completion, automatic class loading and refreshing, history
+support, and (through the Carp::Reply module) automatically launching a REPL
+when an exception is thrown. It can be easily extended through a powerful
+plugin system.
+
+### Spreadsheet::ParseXLSX
+
+* [CPAN](https://metacpan.org/release/Spreadsheet-ParseXLSX)
+* [Source](https://github.com/doy/spreadsheet-parsexlsx)
+
+Spreadsheet::ParseXLSX is a Perl module which can read .xlsx files (as
+generated by new versions of Microsoft Excel). It handles reading both the data
+and formatting from these files.
+
+### Dungeon Crawl Stone Soup
+
+* [Website](https://crawl.develz.org/)
+* [Source](https://github.com/crawl/crawl)
+
+I was a member of the development team for Dungeon Crawl Stone Soup, a
+roguelike game written in C++ and Lua. I contributed several features
+throughout the game, and I was also the release manager for the 0.6 release.
+
+### Moose
+
+* [CPAN](https://metacpan.org/release/Moose)
+* [Source](https://github.com/moose/Moose)
+
+I was a member of the development team for Moose, a module which provides
+advanced object orientation capabilities for Perl. I was also the release
+manager from 2011 – 2012. I am also the maintainer of several widely used Moose
+extensions, such as MooseX::NonMoose and MooseX::Aliases.
+
+### Text::Handlebars
+
+* [CPAN](https://metacpan.org/release/Text-Handlebars)
+* [Source](https://github.com/doy/text-handlebars)
+
+Text::Handlebars is a port of the Handlebars.js templating language to Perl. It
+uses a custom parser on top of the Xslate template engine framework. It
+supports nearly the entire feature set of the JavaScript implementation, and we
+used it at Infinity Interactive to ease the transition of one of our large web
+applications from client side templates to server side templates.
+
+### OX
+
+* [CPAN](https://metacpan.org/release/OX)
+* [Source](https://github.com/iinteractive/ox)
+
+OX is a web framework for Perl based on the PSGI specification, which uses the
+Bread::Board dependency injection system to manage application components. We
+used it internally at Infinity Interactive for many client projects.
+
+### Plack
+
+* [Website](https://plackperl.org/)
+* [CPAN](https://metacpan.org/release/Plack)
+* [Source](https://github.com/plack/Plack)
+
+I was a member of the core development team for Plack, the reference
+implementation of the PSGI specification for Perl web server/application
+interaction (similar to Python's WSGI and Ruby's Rack). I have also contributed
+to the design of PSGI.
+
+### Perl
+
+* [Website](https://perl.org/)
+* [Source](https://perl5.git.perl.org/perl.git)
+
+I was the release manager for the 5.17.1 development release of Perl, and I
+have also contributed many bug fixes to the Perl core. In addition, I have
+contributed to the initial implementations of the p5-mop project, a prototype
+of a new object system for Perl, including features like a meta-object
+protocol.
+
+### TAEB
+
+* [Website](https://taeb.github.io/)
+* [Source](https://github.com/TAEB/TAEB)
+* ["Behavioral" AI Source](https://github.com/TAEB/TAEB-AI-Behavioral)
+
+I was one of the lead framework developers for TAEB, a Perl framework for
+programmatic interaction with NetHack. I was also the primary developer for the
+leading AI written for TAEB.
diff --git a/content/resume.pdf b/content/resume.pdf
new file mode 100644
index 0000000..01fc5d5
--- /dev/null
+++ b/content/resume.pdf
diff --git a/content/resume.tex b/content/resume.tex
new file mode 100644
index 0000000..4edab96
--- /dev/null
+++ b/content/resume.tex
@@ -0,0 +1,198 @@
+% vim:foldmethod=marker commentstring=%%%s
+% license {{{
+% This work is licensed under the Creative Commons
+% Attribution-NonCommercial-ShareAlike License. To view a copy of this license,
+% visit http://creativecommons.org/licenses/by-nc-sa/1.0/ or send a letter to
+% Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
+% This file is adapted from Todd Courtesan's resume, at
+% http://www.courtesan.com/todd/resume.html
+% }}}
+% preamble {{{
+\documentclass[letterpaper]{article}
+\usepackage{jesse_resume}
+\hypersetup{hidelinks}
+\setlength{\oddsidemargin}{-0.75in}
+\setlength{\evensidemargin}{-0.75in}
+\setlength{\textwidth}{8in}
+\setlength{\topmargin}{-0.75in}
+\setlength{\textheight}{10.5in}
+% }}}
+\begin{document}
+% Header {{{
+\resheader{Jesse Luehrs}
+          {http://tozt.net/}
+          {doy@tozt.net\hspace{0.5in}}
+          {(618) 616-6287}
+          {70 America St. \#1R}
+          {Providence, RI 02903}
+% }}}
+% Education {{{
+\resheading{Education}
+\begin{itemize}
+    % Hacker School {{{
+    \item \ressubheading{Hacker School}{New York, NY}
+                        {Student}{September 2014--November 2014}
+    % }}}
+    % UIUC {{{
+    \item \ressubheading{University of Illinois at Urbana-Champaign, College of Engineering}{Urbana, IL}
+                        {Bachelor of Science in Computer Science with Minor in Mathematics}{August 2004--May 2008}
+        \begin{minipage}[t]{\textwidth/2-0.2in}
+            \begin{itemize}
+                \resitem{Overall GPA: 3.61, Technical GPA: 3.81}\vspace{-7pt}
+                \resitem{James Scholar in Engineering (2004--2005)}\vspace{4pt}
+            \end{itemize}
+        \end{minipage}
+        \begin{minipage}[t]{\textwidth/2-0.2in}
+            \begin{itemize}
+                \resitem{Dean's List (Fall 2004--Fall 2006)}\vspace{-7pt}
+                \resitem{Graduated with Honors}\vspace{4pt}
+            \end{itemize}
+        \end{minipage}
+    % }}}
+\end{itemize}
+% }}}
+% Work Experience {{{
+\resheading{Work Experience}
+\begin{itemize}
+    % Infinity Interactive {{{
+    \item \ressubheading{Infinity Interactive (\url{http://iinteractive.com/})}{Manhasset, NY (telecommuting)}
+                        {Senior Programmer}{February 2010--August 2014} \vspace{6pt} \linebreak
+        \small{I was in charge of a large, legacy codebase which handles employee
+        engagement survey registration and reporting, and I have also written
+        and deployed many smaller sites myself, mostly using Perl. Since we
+        relied heavily on open source software, a large portion of my time was
+        also devoted to maintaining various open source projects, as well as
+        developing new open source software that could be useful in the
+        future.}\normalsize
+    % }}}
+    % UIUC Hydrogeology Lab {{{
+    \item \ressubheading{UIUC Hydrogeology Lab (\url{http://www.gwb.com/})}{Urbana, IL}
+                        {Visiting Research Programmer}{February 2006--February 2010} \vspace{6pt} \linebreak
+        \small{I worked on the Geochemists' Workbench, a geochemistry software suite
+        written in C++ and Tcl/Tk. I added support for several new image output
+        formats as well as adding font embedding support to the existing
+        PostScript format. I also helped add parallel processing support to
+        several scientific calculations, using OpenMP. I ported our calculation
+        applications from Windows to Linux, to allow them to be run on large
+        clusters. Finally, I implemented a testing framework for our calculation
+        applications using Perl's Test::More.}\normalsize
+    % }}}
+\end{itemize}
+% }}}
+% Projects {{{
+\resheading{Projects}
+
+\small{A more complete list of my projects is on my website
+(\url{https://tozt.net/projects.html}). All of my personal open source work is
+also available on GitHub (\url{https://github.com/doy}), and my Perl open
+source work is also available on the CPAN
+(\url{https://metacpan.org/author/DOY}).}\normalsize\vspace{-3pt}
+
+\begin{itemize}
+    % termcast {{{
+    \item \resshortsubheading{Termcast (\url{https://github.com/doy/python-termcast-server})}{2014--present} \vspace{6pt} \linebreak
+        \small{I wrote a server and client to allow users to stream their terminal
+        sessions over the network for other people to watch.}\normalsize
+    % }}}
+    % libvt100 {{{
+    % \item \resshortsubheading{libvt100 (\url{https://github.com/doy/libvt100})}{2014--present} \vspace{6pt} \linebreak
+    %     I am the author of libvt100, a terminal parsing library written in C
+    %     and Lex. I am currently using it in the Termcast server and in Runes, a
+    %     terminal emulator.
+    % }}}
+    % Text::Handlebars {{{
+    % \item \resshortsubheading{Text::Handlebars (\url{https://github.com/doy/text-handlebars})}{2013--present} \vspace{6pt} \linebreak
+    %     I am the author of Text::Handlebars, a port of the Handlebars.js
+    %     templating language to Perl. It uses a custom parser on top of the
+    %     Xslate template engine framework. It supports nearly the entire feature
+    %     set of the JavaScript implementation, and we used it at Infinity
+    %     Interactive to ease the transition of one of our large web applications
+    %     from client side templates to server side templates.
+    % }}}
+    % Reply {{{
+    % \item \resshortsubheading{Reply (\url{https://github.com/doy/reply})}{2013--present} \vspace{6pt} \linebreak
+    %     \small{I wrote Reply, a lightweight and extensible REPL for Perl. It includes
+    %     many useful features such as tab completion and history support.}\normalsize
+    % }}}
+    % Dungeon Crawl Stone Soup {{{
+    \item \resshortsubheading{Dungeon Crawl Stone Soup (\url{http://crawl.develz.org/})}{2009--present} \vspace{6pt} \linebreak
+        \small{I am a member of the development team for Dungeon Crawl Stone Soup, a
+        roguelike game written in C++ and Lua. I contributed several features
+        to the game and was also the release manager for the 0.6 release.}\normalsize
+    % }}}
+    % Plack {{{
+    % \item \resshortsubheading{Plack (\url{http://plackperl.org/})}{2012--2013} \vspace{6pt} \linebreak
+    %     I am a member of the core development team for PSGI and Plack, the
+    %     specification for Perl web server/application interaction (similar to
+    %     Python's WSGI and Ruby's Rack).
+    % }}}
+    % Perl {{{
+    \item \resshortsubheading{Perl (\url{http://www.perl.org/})}{2011--2013} \vspace{6pt} \linebreak
+        \small{I was the release manager for the 5.17.1 development release of Perl,
+        and I have also contributed many bug fixes. I have also been a lead
+        developer on the p5-mop project, a prototype of a new object system for
+        Perl.}\normalsize
+    % }}}
+    % OX {{{
+    % \item \resshortsubheading{OX (\url{https://github.com/iinteractive/OX})}{2011--present} \vspace{6pt} \linebreak
+    %     I am the lead author of OX, a web framework for Perl based on the PSGI
+    %     specification, which uses the Bread::Board dependency injection system
+    %     to manage application components. We have used it internally at
+    %     Infinity Interactive for many client projects. In addition to writing
+    %     most of the framework itself, I also wrote a series of advent calendar
+    %     posts documenting it, which can be seen at
+    %     \url{http://ox.iinteractive.com/advent/}.
+    % }}}
+    % Moose {{{
+    \item \resshortsubheading{Moose (\url{http://moose.perl.org/})}{2009--2013} \vspace{6pt} \linebreak
+        \small{I am a member of the development team for Moose, which provides
+        advanced object orientation capabilities to Perl. I was also the
+        release manager from 2011--2012.}\normalsize
+    % }}}
+    % TAEB {{{
+    \item \resshortsubheading{TAEB (\url{http://taeb.github.io/})}{2008--2011} \vspace{6pt} \linebreak
+        \small{I was one of the lead framework developers for TAEB, a Perl framework
+        for programmatic interaction with NetHack. I was also the primary
+        developer for the leading AI written for TAEB.}\normalsize
+    % }}}
+    % Volition {{{
+    % \item \resshortsubheading{System for Defining, Documenting and Recording Game Events (\url{http://volition-inc.com/})}{2007--2008} \vspace{6pt} \linebreak
+    %     This is a library written in C which can be added to games in order to
+    %     track arbitrary events and report them to a remote server, for use in
+    %     gameplay testing. This project was completed for Volition as my senior
+    %     project, and was used as part of their testing process for Saints Row
+    %     2.
+    % }}}
+\end{itemize}
+% }}}
+% Talks {{{
+\resheading{Talks}
+
+\small{Slides and videos (where available) for these talks can be found at
+\url{http://tozt.net/talks.html}.}\normalsize\vspace{-3pt}
+
+\begin{itemize}
+    \item \resshortsubheading{Introduction to Rust (50 min)}{YAPC::NA 2014} \vspace{6pt}\linebreak
+        \small{This talk describes the Rust programming language, touching on
+        its major features and design philosophies that make it
+        interesting.}\normalsize
+    \item \resshortsubheading{Dependency Injection with Bread::Board (50 min)}{YAPC::NA 2012, YAPC::EU 2012} \vspace{6pt}\linebreak
+        \small{This talk provides an overview of dependency injection, and
+        gives concrete examples of it using the Bread::Board module for Perl.}\normalsize
+    \item \resshortsubheading{OX - the hardest working two letters in Perl (50 min)}{YAPC::NA 2011} \vspace{6pt}\linebreak
+        \small{This talk describes the OX web framework for Perl, including a
+        conceptual overview and usage examples.}\normalsize
+    \item \resshortsubheading{Extending Moose (50 min)}{YAPC::NA 2010} \vspace{6pt}\linebreak
+        \small{This talk goes into detail describing Moose's meta object
+        protocol, including what it is, how it works, and how you can extend
+        it.}\normalsize
+\end{itemize}
+% }}}
+% Skills {{{
+\resheading{Skills}
+\begin{description}
+    \item[Languages:] \small{I am fluent in C, C++, Perl, Lua, and shell, and I am also proficient in Python, JavaScript, HTML/CSS, Scala, Rust, and LaTeX.}\normalsize\vspace{-6pt}
+    \item[Tools:] \small{Make, vim, git, Firefox}\normalsize
+\end{description}
+% }}}
+\end{document}
diff --git a/content/resume.txt b/content/resume.txt
new file mode 100644
index 0000000..4c492eb
--- /dev/null
+++ b/content/resume.txt
@@ -0,0 +1,110 @@
+Jesse P Luehrs
+==============
+Address: 702 W. Green St., Apt #2
+         Urbana, IL 61801
+Phone:   (618) 616-6287
+Email:   doy@tozt.net
+Website: http://tozt.net/
+
+=========
+Education
+=========
+University of Illinois at Urbana-Champaign, College of Engineering
+Urbana, IL
+Bachelor of Science in Computer Science
+Aug. 2004 - May 2008
+- Overall GPA: 3.61, Technical GPA: 3.81
+- James Scholar in Engineering (2004 - 2005)
+- Dean's List (Fall 2004 - Fall 2006)
+- Graduated with Honors
+
+===============
+Work Experience
+===============
+UIUC Hydrogeology Lab
+Urbana, IL
+Visiting Research Programmer
+February 2006 - present
+- Worked on the Geochemists' Workbench, a geochemistry software suite
+  written in C++ and Tcl/Tk.
+- Added or enhanced support for several different image output formats
+  including PDF, SVG, and PostScript, including adding TrueType font
+  embedding to PDF and PostScript files.
+- Helped add parallel processing support to several scientific
+  calculations, using OpenMP.
+- Designed a new XML-based configuration file format for our
+  applications.
+- Ported our calculation applications to Linux, to allow them to be run
+  on large clusters.
+- Implemented a testing framework for our calculation applications in
+  Perl, using Test::More.
+
+Smile-A-While Amusements
+Traveling, Illinois/Indiana/Missouri
+Concessions manager
+Summer 2004 and 2005
+- Managed several amusement games on the Luehrs' Ideal Rides carnival.
+
+========
+Projects
+========
+Moose (http://moose.perl.org/): 2009 - Present
+- Member of the Moose Cabal, the lead development team for Moose.
+- Wrote several extensions for Moose, including MooseX::NonMoose, which
+  allows classes built with Moose to easily interoperate with other
+  types of classes, and MooseX::Aliases, which allows Moose attributes
+  to be referred to by different names.
+
+Bot::Games (http://github.com/doy/bot-games): 2009 - Present
+- Bot::Games is an IRC bot framework written in Perl, designed for
+  multiplayer game moderation.
+- Uses Moose extensively to provide a clean and extensible plugin system
+  for adding games.
+
+TAEB (http://taeb.sartak.org/): 2008 - Present
+- TAEB is a Perl framework (using Moose) for programmatic interaction
+  with NetHack (http://nethack.org/).
+- Primary developer for the leading AI written for TAEB.
+- Developed several standalone Perl modules in the course of
+  development, including Graph::Implicit, which implements several
+  useful graph algorithms, and IO::Pty::Easy, which provides a simple
+  read/write interface for interacting with pseudo-terminals.
+
+Smithy (http://sourceforge.net/projects/smithy/): 2008
+- Smithy is a cross-platform map editor for the Aleph One engine
+  (http://marathon.sourceforge.net/), written in OCaml.
+- Contributed several GUI improvements, including writing custom widgets
+  using LablGTK.
+
+System for Defining, Documenting and Recording Game Events
+  (http://volition-inc.com/): 2007 - 2008
+- This is a library written in C which can be added to games in order to
+  track arbitrary events and report them to a remote server, for use in
+  gameplay testing.
+
+LuaIRC (http://luaforge.net/projects/luairc/): 2006 - 2008
+- LuaIRC is a fully-featured IRC framework written in Lua.
+- Supports all standard IRC functionality, including CTCP and DCC.
+
+======
+Skills
+======
+Languages:
+- Proficient in C, C++, Perl (CPAN id: DOY), Lua, Bash, OCaml
+- Working knowledge of Ruby, Tcl/Tk, JavaScript, LaTeX, HTML/CSS,
+  PostScript, sed
+Operating Systems:
+- Linux (Arch, Debian, Gentoo)
+- Windows (2000, XP)
+Tools:
+- Make, Vim, Microsoft Visual Studio, Cygwin, Darcs, Subversion, Git
+
+==========
+Activities
+==========
+Inline Insomniacs:
+- I was the webmaster for the Inline Insomniacs rollerblading club from
+  2005 until 2007.
+Falling Illini:
+- I was a member of the Falling Illini skydiving club from 2007 until
+  2008.
diff --git a/content/talks.md b/content/talks.md
new file mode 100644
index 0000000..3759321
--- /dev/null
+++ b/content/talks.md
@@ -0,0 +1,15 @@
+---
+title: "talks i've given"
+resources:
+  - name: slides
+    src: "talks/extending_moose_yapc_na_2010/001.html"
+---
+
+* YAPC::NA 2014 - [Introduction to Rust](http://www.yapcna.org/yn2014/talk/5360) ([video](http://youtu.be/5EFCMaEbgX4), [transcript](https://github.com/doy/intro-to-rust-yapc-na-2014/blob/master/talk.md), [slides/examples](https://github.com/doy/intro-to-rust-yapc-na-2014/tree/master/examples))
+* YAPC::EU 2012 - [Dependency Injection with Bread::Board](http://act.yapc.eu/ye2012/talk/4181) ([video](http://youtu.be/Xpk7AV90gd8), [slides](/talks/bread_board_yapc_eu_2012.pdf), [source](/talks/bread_board_yapc_eu_2012.key))
+* YAPC::EU 2012 - [TIMTOWTDI in 2012](http://act.yapc.eu/ye2012/talk/4182)
+* YAPC::NA 2012 - Dependency Injection with Bread::Board ([video](http://youtu.be/DhhaOQWoOpw), [slides](/talks/bread_board_yapc_na_2012/), [source](/talks/bread_board_yapc_na_2012/slides.vroom))
+* YAPC::NA 2011 - [OX - the hardest working two letters in Perl](https://web.archive.org/web/20110709062708/http://yapc2011.us/yn2011/talk/3251) ([slides](/talks/ox_yapc_na_2011/), [source](/talks/ox_yapc_na_2011/slides.vroom))
+* YAPC::NA 2010 - Extending Moose ([slides](/talks/extending_moose_yapc_na_2010/), [source](/talks/extending_moose_yapc_na_2010/slides.vroom)) <!-- was http://yapc2010.com/yn2010/talk/2646 -->
+* YAPC::NA 2010 - App::Termcast - share your terminals! (lightning talk) <!-- was http://yapc2010.com/yn2010/talk/2647 -->
+* YAPC::NA 2009 - [Botting NetHack with TAEB (lightning talk)](https://web.archive.org/web/20120323005415/http://yapc10.org/yn2009/talk/2148)
diff --git a/content/work.md b/content/work.md
new file mode 100644
index 0000000..20bce0e
--- /dev/null
+++ b/content/work.md
@@ -0,0 +1,8 @@
+---
+title: "work"
+---
+
+I currently work for Stripe and am not actively seeking employment. My (not
+particularly up to date) resume can be found here:
+
+[My resume](/resume.pdf) ([LaTeX source](/resume.tex), [plaintext](/resume.txt))