I wrote about Postwave a little while ago, but at the time this site was still using the hacked together Jekyll-based solution that I had been using since around 2013. It seemed a bit silly to build a blogging library but not use it for my own blog, but I was a little daunted by the task of migrating all my posts over in a way that didn't break everything. I had hit the point where I was writing posts for this site and wished I could be using Postwave so when I had a little bit of free time one night last week so I decided to give it a shot and it turned out to be...

Not that bad.

Postwave posts look very similar to Jekyll posts. They are Markdown files with a little bit of header information:

title: Powered By Postwave
date: 2026-02-06 14:58
tags:

**This blog is now using my home-grown blogging library, [Postwave](https://postwave.blog/)!**

With a little help from Copilot, I wrote a basic script to migrate all the Jekyll posts over to the Postwave directories and make any formatting changes needed. I'm planning to use this script as the basis for a future postwave migrate command in the Postwave library.

After this I just added some of the basic post display and archive code needed to make use of all those new Postwave-shaped Markdown files. Much of this code was lifted from the Postwave example blog.

The whole process ended up being pretty easy and I was able to migrate things without really changing any of the urls for old posts. It's very likely (and intentional) that nobody else will notice the change, but I know and that's what matters. It's a really good feeling to use a tool that you made for yourself and works EXACTLY the way you want it to.

I miss Heroku.

I know Heroku still exists, but I miss the generous free tier they offered. This was the perfect solution for spinning up relatively simple, low traffic, Ruby sites, which are what a lot of my projects are.

When Heroku decided to kick out freeloaders (like me) I started looking around for other hosting options I could mooch from. I ended up moving most of my small sites/projects to Fly.io. When I needed a small database, Supabase had a pretty good free tier and I ended up using Umami for some simple site analytics.

Honestly, this all worked pretty well. Fly.io had a good free tier. I only started incurring costs once I was hosting too many sites on my account. Umami worked fine, but the free tier only supported 3 sites and 6 months of data. I did run into a few issues with Fly.io deployments when they changed some configurations, but nothing major. I probably could have finagled a mostly workable, almost free hosting solution. But near the end of last year, I was fixing the deployment configs for one of my sites and I started thinking, "Why don't I do this all myself and have it work exactly the way I want!?".

Always a dangerous thought.

I've had a small Digital Ocean droplet for a while, just to play around with, but I wasn't doing much with it, so I figured I could use that. I started looking into "Heroku-like" self-hosting systems and landed on Coolify. I'm ok with a little DYI, but I didn't really want to do a lot of serious Linux server maintenance and this seemed to fit the bill. Setting up Coolify on a Digital Ocean droplet was pretty straightforward:

Open up some ports:

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 8000/tcp
ufw enable
ufw status

Install Coolify:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

And then I had a web UI to start setting things up.

Each site in Coolify is an application and applications are contained in projects. I ended up setting up two different projects "site" for all the applications that would be normal public facing websites and "tools" for things like analytics.

To handle deploys, Coolify creates a GitHub app that you install on your account and then you give it read permissions on the repos you want to deploy from. This works with both public and private repos. Whenever I push to the main branch of the sites repo, Coolify gets a webhook and deploys.

All of the sites I was trying to move over were pretty simple Sinatra sites and after a little bit of wresting with the configs (an a lot of asking ChatGPT questions), I got a pretty good pattern down for all the sites I wanted to deploy: - create an application that pulls from my GitHub app as a source and launches from a simple Dockerfle - once the site is deployed, Coolify provides a temporary url to test it out at - if everything looks good, just change the A record of the domain over to my Digital Ocean droplet's IP - add the domain name to the Coolfiy application's config (Coolify handles getting the https certificate!)

I wanted to keep using Umami for site tracking, but just run my own instance, which ended up being pretty easy. Coolify lets you create a new application from a public git repo (https://github.com/umami-software/umami in this case) and sets up the app from that. Coolify also has a simple flow for setting up a new database, so spinning up a Postgres instance for Umami was pretty easy. After getting that set up I moved all my sites over to my own instance of Umami, free of site and data retention limits!

One other thing I wanted now that I was self hosting was a little sftp server where I could upload files and have a publicly accessible url for them. To do this I set up an sftp server and then a standalone Nginx server, both pointed as the same persistent storage. Now I don't need to rely on a 3rd party service if I just want to share a small file! Not necessary but I did it because it's my server and I can!

Now I'm happy to say I'm self-hosting the sites I run:

• dinosaurseateverybody.com (the site you're looking at right now!)
• dontbreakprod.com
• postwave.blog
• evilbrain.band
• and a few small personal projects and the analytics for those sites

I'm not really a big fan of doing dev ops stuff. I have a limited amount of time to spend on personal projects and I'd rather spend that time building and not messing with servers. But there's something pretty satisfying about hosting your own sites. For me, Coolify was a pretty good paved path to get things up and running with a nice UI.

Earlier this year I wrote about Don't Break Prod, my software engineering career advice site. While I enjoy writing about this stuff, the original motivation for building the site was to test a new blog engine I'd been working on called Postwave.

For a long time I've been using weird, hacked together solutions to integrate blog posts into my sites. It started with my band and old personal sites where I used WordPress to write posts but then made custom functions to pull the posts directly from the database rather than letting WordPress render a nice site like a normal person would. Later, when I built this version of my site, I did something similar with a Jekyll backend and my own custom hooks into the generated html. I liked being able to write posts in Markdown, but it felt silly to circumvent the whole static site generator to build a dynamic page.

So I did what any impractical programmer would do. I just built my own thing that works exactly the way I want, without any regard for general practicality.

This is where Postwave came from.

Named after a Blue Meanies album and built to do a very specific thing, Postwave is a fairly simple Ruby gem that lets me write posts in Markdown and then dynamically integrate them into a custom site. When I'm building a small site I usually reach for Sinatra. Most of the time I just want a simple web application with some dynamic endpoints and minimal JavaScript. And then I want a blog engine that just fits into that.

Postwave gives me simple methods objects and methods so I can use things like post.title and post.body_html to build a post display page and postwave_client.archive to get a structured archive. It also autogenerates an RSS feed for me.

Postwave also has a few simple terminal commands for creating a new posts and "building" the blog, which updates the index, renames files based on post title, generates the RSS file, and a few other things. My workflow for writing posts is just to create a new post in the terminal, write the post in my code editor, rebuild the blog, and deploy the updated site.

It's not done (but what little personal project is?), but it is usable. I have an site/reference implementation for people to learn about it and the code is available if anyone is interested.

So this site must be using Postwave under the hood, right?

Well... not yet. Dinosaurs Eat Everybody still uses my hacked together Jekyll solution, but that workflow is starting to annoy me so I'm eager to port it over to Postwave now. I've been using Postwave for a while on Don't Break Prod so I feel pretty confident that it's ready for use elsewhere. I'd like to build some small tools to make it easy to migrate a Jekyll site to Postwave. The post format is very similar and it would just make my migration easier.

Postwave has been a great little "scratch your own itch" project for me. I'm looking forward to using it more for my own blogging needs. And if my problems sound similar to yours, try it out!

Nothing too deep here, just some things I've been mulling over that aren't worth writing whole posts about...

Are we all really going to be staff engineers? It seems like there are a lot of people (or companies?) pushing the idea that the future of software engineering is making design decisions and directing and correcting a bunch of agents to get the work done. This sounds a lot like what some staff engineers do. What does a junior staff engineer even look like? It seems like this whole idea relies on people being good at clear communication and multitasking (two things that are very easy to screw up).

I hate that everything requires a subscription. If coding with a state of the art LLM becomes the default, it means that by default coding will involve paying a monthly subscription. While companies will probably provide this for employees, there's now a perceived cost barrier for just wanting to build something on your own. It feels like model providers are hoping LLMs just become another utility that everybody needs to exist.

There's a difference between wanting something made and wanting to make something. Coding agents are fantastic for getting something to exist. I have absolutely used them to take on coding projects that I just didn't want to bother with. One of my favorite LLM uses at work with handling the boiler plate around new tests. It would be silly to say that AI isn't useful for making things exist. But sometimes you want to make things and doing that with heavy agent usage just feels kind of hollow. The feeling of accomplishment that you get from building something yourself is real and there's a cost to losing it. Sometimes I just need a table so I just buy one from Ikea, but that's a different experience than using a piece of furniture that you designed and built yourself.

AI can be really useful for learning, but you have to choose to use it for learning rather than just getting stuff done. Before you could get an agent to just build something for you, you had to get your hands dirty building it yourself. This often required either learning something new up front or incidentally learning something along the way. Now you have to consciously decide you're going to learn (which AI can help with!) in addition to shipping.

We haven't seen AI products really enshitify yet. That's not going to be fun...

You should just use a laptop. For most things.

Phones (and tablets, to some degree) are amazing because they're a powerful computing device that is always with you, but they're kind of awful for that same reason. When you can always pull out your phone to take care of a task, do your shopping, etc. you're always trying to do multiple things at once. If you can do it now you never have the excuse to plan to do it later. This has two pretty crappy consequences:

First, you never have to prioritize things. You just do them as soon you think of them. Maybe you're multitasking during dinner to get things done that don't actually matter. If you can keep checking Slack for work, you never have to decide you're done for the day. It can feel good to cram a little bit of productivity into gaps into your downtime, but sometimes it's good to have downtime. Being busy is not a virtue.

And second, it's harder to fully focus on your task. If you're reading emails or doing your shopping while you're out with other people you're only half doing both things. The double edged sword of using your phone for everything is that it's always with you, so you don't need to go to a dedicated "work space" to do your tasks. The inconvenience of getting out a laptop and opening it up to work is a feature. I think there's a lot of value in getting in the right head space to do non-trivial tasks and if you're primary device for getting things done is optimized for convenience rather than focus you're going to spend more time on the types of tasks that don't require deep focus.

Phones are great tools for a lot of things. They are really well optimized for portability (obviously), simplistic input, and consumption. The fact that I can get map directions or watch a movie wherever I am is a modern miracle. I love that I can pull out my phone whenever I get a random song idea and record a voice memo before I forget.

But I don't want to do the work of turning an idea into a finished song on my phone. For that I want to sit in a quiet place with instruments and a proper recording interface. It's not just that the tools are better with richer input mechanisms and more screen space for powerful UIs. The act of deciding to be in a "songwriting place" helps get my head into the task. It means I'm focused on one task.

Sometimes I'll even wait until I'm at a laptop to make non-trivial responses to text messages. Trying to type a paragraph or more on a phone keyboard feels like squeezing ideas through a straw, it just feels easier to type on a real keyboard with richer options for copying, pasting, and other text manipulation. Sure, if I'm out of the house and need to message someone, it's great to be able to just send something from my phone, but it's not an interface optimized for longer-form text.

Tablets are an interesting middle ground, but in many ways they still encourage more consumption than focused work. Attaching a keyboard can help. If you're mainly trying to write emails, watch videos, and look at websites it's probably ok, but you're still using a device that is optimized for scrolling and tapping. There are some use cases where a tablet might be superior to a proper computer, such as drawing. If I were doing comics right now an iPad with Procreate seems like it would be the best tool for the job.

I don't dislike phones (or tablets). They're amazing and useful tools. I just think that the habit many people have of pulling out a phone to accomplish whatever tasks happens to come to mind creates a world where you're always kind of multitasking and rarely sitting down to focus on things. Embrace the inconvenience of using a computer that might not be in your pocket at all times.

Just use a laptop. For most things.

Last year I picked up a Framework 13 laptop so I'd have a Windows machine to play Minecraft on with my kid. It's been useful to have around, but Windows 11 was just glaringly aggressive with how much it wanted me to sign up for various Microsoft services. I probably hadn't used a Windows computer for anything non-trivial since Windows 7 and the change was striking.

I got the urge to try dual booting Linux on my Framework so I installed Ubuntu and used DHH's Omakub to get it set up quickly. It was kind of fun and I've been using as my primary dev machine for working on Lox. Having a project has been helpful for just exploring the system a bit and I found myself switching back and forth between Windows and Ubuntu pretty often on that computer. Omakub really did a good job of making things look nice and providing some good defaults so I didn't spend a ton of time getting things set up and usable. I dug in to using Neovim as my editor and Alacritty as my terminal.

It's nice to have things both configured AND configurable.

When I saw DHH posting about Omarchy I was interested. Arch always seemed a little intimidating and I wanted to spend my time using my computer, not fixing/configuring it so having some good defaults and a little hand-holding on the install seemed nice. Due to some disk encryption requirements you're not able to (easily) dual boot Omarchy right now, so I didn't think I could replace my Ubuntu setup but my curiosity got the best of me. I found an old 2012 MacBook Air, bought a USB-Ethernet adapter (so I could run the install without wifi working), and put the ISO on a thumb drive.

The installation was surprisingly easy. I expected to run into some wifi issues but everything worked out of the box. Having played around with the Omakub setup on my Ubuntu install, I felt pretty comfortable with a lot of the default applications like neovim and Alacritty as well as some shortcuts like Super-space for the app launcher so that helped a lot.

Hyprland felt like more of an adjustment. This was my first time really using a tiling window manager. I use Rectangle on my Macs for some basic window resizing and positioning but this was the first time I'd really working in a purely tiled desktop. I tend to have a chaotic pile of windows on my screen most of the time so in some ways using a tiled window manager helped me avoid that because if I kept too many things open, the new windows were uselessly small. If I needed more space I used additional desktops or even just closed windows.

The focus on using built in (and configurable) keyboard shortcuts for launching common programs really helped (Super-Return for a terminal, Super-B for a browser, etc.). It made it feel more natural to quickly open things when I needed them and close them when I was done. I also really like the use of "web app windows", these are basically keyboard shortcuts to open up web apps (like email, Twitter, etc.) in chromeless browser windows via keyboard shortcut. Super-C to open a quick Google Calendar window is really nice and I've created and customized a few new shortcuts for myself.

So what about really hacking around with Arch? Well, I haven't done a bunch of power user stuff yet and honestly I don't plan on spending a lot of time futzing around with things. I still want to spend most of my time using my computer, not fixing/configuring it. I did put in a little time getting the display to rescale nicely when I plugged into a large monitor and closed the laptop to work in clamshell mode. It was fun to see how much control I had over things, if I wanted it. I might also look into some fun widgets that work with Waybar and Hyprland to display some useful into if I have the time and inclination.

It's nice to have things both configured and REALLY configurable.

So, am I going to cast off the oppressive shackles of MacOS and Windows so I can live exclusively in the land of the Free and Open Source? Eh, probably not. There are a few reasons I'll keep using my Mac and have at least a Windows partition somewhere:

• My M1 MacBook Pro is one of the nicest feeling laptops I've ever used. It's fast, it feels solid, and everything just works.
• Logic I use Logic for all my music recording. A lot of the people I make music with use Logic. I'm not going to switch.
• I use iMessage on a laptop a lot. I don't like typing long text messages on my phone, so I often switch to my laptop to send non-trivial things.
• Occasionally I'll find a game I want to play that's only on Windows (and/or Mac). I'm not a big gamer, and gaming on Linux seems to be getting better, but there are certainly some interesting things that come out that just don't work in Linux.
• Sometimes I want things to just work. Maybe that's a fingerprint reader or my Plex server, but I don't have as much time to fiddle with things anymore so there are many situations where I'm going to use the tools that get (and keep) me up and running with the least amount of effort.

That said, I do think I'll use this Omarchy set up a fair amount. I replaced the battery in my Omarchy computer and it's turned this 15 year old laptop into a very usable machine. I like that my computing environment doesn't feel like it has an "agenda". It's not trying to sell me on any services, just "here's an OS, try not to get yourself killed." It feels more like a powerful tool than a product, which is nice these days. Also, it's just fun to learn something different.

I'm enjoying using Linux and that kinda matters.

Earlier this month I put out a new EP from my solo project, And Or Not. If you want to skip the self indulgent dive into making this recording and just go listen to it, you can just go check it out.

And Or Not is an exercise in simplistic instrumentation. It's only bass, drums, vocals, and some keys for a little added texture. It's a nice balance to the more complex arrangements of things like Grave Danger. Like last time I started by just writing a bunch of bass riffs, recording them into one big project, and then coming back later to pick out ones I liked to build songs around.

Once I'd massaged those riffs into basic song structures I started putting some lyrics together. I've given myself a lot of leeway to write about whatever pops into my mind so I ended up writing about my disappointment around the current state of the internet (Let's Get Weird Again), Minecraft (Bedrock), and coffee (Top Me Off).

For the recording process, I took the demos I made for writing, mapped it to a click and started by laying down the drums. I think I'm a better drummer than I was when I did the first record but it still took a while to get everything down since I was sort of writing parts while I was trying to record them. I think I've gotten a little better at recording drums, too.

The bass parts were pretty straightforward to lay down, but I spent a little more time layering my tone. After seeing '68 live I got inspired to lean into a noisier, fuzzier sound and not be afraid to build up a more complex tone. I'm using bass amp models from Logic for my tone so I ended up taking the raw tracks and running them through three different amp setups (resulting in 3 tracks for all the bass parts). One track had a really fuzzy tone, one beefed up the low end, and a third focused on brightening the attack. Mixed together I got a really full sound, which was pretty important when there isn't much else in terms of instrumentation.

I did add some keys, mainly B3 organ, to thicken things up and add a bit of counter melody in a few parts, but it was pretty minimal. Mainly just to add some more texture to the songs.

Finally, vocals.

I'm still not very confident about my vocals, but doing a solo project means that it can just be whatever I put down so I've been digging into it. I had a lot of fun layering and doing harmonies on these songs. I also tried to put in a few more "character" elements ("wooo"s, "let's go!"s, etc.) to help combat the very "studio only" nature of these recordings (since I'm the band, these songs have never been played live). Doing vocals for this project has very much been an exercise in just laying stuff down and putting it out there with as much confidence as I can.

Even though this is my solo project I always love getting my kids in on songs so I had Elliot come in and record some extra vocals on Bedrock. We've been playing a lot of Minecraft lately and it seemed appropriate to get him in that song somewhere.

My favorite little easter egg on this record came from Max. If you listen really carefully at the end of the last song (Top Me Off), you can hear him say "Ok, can we play cars now?". I had been recording drums when he came down and wanted to play. He let me do one more take, waited very patiently, and after the last hit excitedly asked if we could play now. I thought it was a great little incidental moment so I left it in, isolated it, and turned it up.

The cover art was, somewhat begrudgingly, done with ChatGPT. I knew kind of how I wanted it to look and managed to get a full cover together in only a few minutes. Part of me wishes I had made it from scratch, just out of principle, but I got something I'm happy with and that's what matters.

Overall, I'm really proud of this EP. It took WAY longer than it should have to complete because I could only work on it in fits and bursts when I had free time (and could be loud at home). It feels like good progress for the previous record and, honestly, I just love putting out music.

Enjoy!

Why Crystal? I like it. It's syntax looks very Ruby-like but it has static (and sometimes explicit) typing. It's reasonably fast when compiled. Plus, by implementing all the examples in a different language it forced me to understand what I was doing enough to translate from Java to Crystal. I'm not the first person to implement a Lox interpreter in Crystal, but it is a less common project.

For a "toy" language built as a learning tool, Lox implements some nontrivial things. A simple "Hello world" looks as expected:

print "Hello world!";

It has loops! While loops and for loops (which are turned into while loops by the interpreter):

var k = 30;
while(k < 40) {
  print k;
  k = k + 1;
}

for(var j = 30; j < 40; j = j + 1) {
    print j;
}

And it has objects and inheritance!

class Animal {
  init(name) {
    this.name = name;
  }
}

class Cat < Animal {
  meow() {
    print "meow";
  }
}

var kitten = Cat("Mochi");
kitten.meow();

While this all feels like pretty standard stuff for any programming language you might use, it was really cool to build everything up from scratch. The parser was written from scratch in less than 500 lines of code, no using any big libraries like Bison or Yacc. The scanner handles a little over 40 tokens in less than 200 lines of code. It has a resolver to handle some scope ambiguities and static analysis. This is just been a really cool project.

In addition to all the cool programming language stuff I learned working on this I also used this project as an excuse to develop in Neovim on the Ubuntu laptop I set up a while ago (using DHH's Omakub).

Despite the code being a little messy in parts (sometimes I got impatient trying to handle Nils in Crystal) and containing some bugs, I'm sure, it's still really cool have this project in a "done" state. I might come back later and clean up the code or add some features (this implementation of Lox lacks a way to take user input...) but for now I'm going to move on to the next section of the book where I'll build Lox again, this time as a more optimized, compiled language implemented in C (I probably haven't touched C since college...).

If you're interested, check out my implementation of crlox.

When I first started it was pretty arduous. I actually had to grind the wheat to make flour for the dough. Making the cheese took forever. Toppings were a luxury unless I could find someone else who was making them and even then they could be really expensive.

As time went on, things got easier, though. I was able to buy bags of nice flour. Cheese was easy to get and a wide range of toppings became available. If I was really in a hurry, I could even find pre-made sauces that were pretty good.

More and more people got into making pizza so there were lots of new recipes out there to try, which was fun too.

Eventually I started seeing pre-made dough and even full kits with dough sauce and toppings ready to assemble and bake, which was pretty nice when I was in a hurry and just wanted something basic.

Then pizza delivery services popped up. I could just order whatever kind of pizza I wanted and it would show up at my door, faster than I could make one myself! Some of them were pretty good and it's a really easy way to get dinner when you're too busy to cook.

So now I have pizza whenever I want, which is pretty cool. I probably eat pizza more often now than I ever have.

I guess I don't really make pizza anymore, though.

🍕

For many of the more tech savvy people who are feeling this, there's a lot of push to leave all of these unpleasant places behind and live entirely in alternative spaces. This might mean getting Google out of your life, leaving Twitter or Facebook or whatever major platform. But that's hard if you want to interact with people who don't think about tech all the time. It's the digital equivalent of homesteading.

I've been trying to be more conscious about trying to make my online life more pleasant in pragmatic ways. Ways that make me happier without feeling isolated from my less tech focused friends. More "growing some of my own food at home" and less "moving into a cabin in the woods".

Actual Social Networks I've never found Twitter or Instagram to be particularly toxic places and I think that's because I've used them in an odd way. I only really follow people I know personally and I try my best to avoid algorithmically suggested posts. I will sometimes manually visit the profiles of interesting accounts, but the extra friction prevents me from passively consuming everything they post in perpetuity. This means my feeds on these sites are mainly friends and old coworkers who I actually like. I'm sure I'm missing a lot of funny videos and maybe some interesting content, but I think I'm happier this way.

Tending My Own Garden That said, I've been less inclined to engage on other people's platforms lately. The internet was weirder and more fun when it wasn't just people posting to handful of huge sites. I've been writing more on Don't Break Prod and doing more little updates to this site, with the plan to share more things here. Again I haven't deactivated my accounts on any major sites, I'm just not really interested in building my castle in other people's kingdoms (even if that costs me priceless things like "engagement").

Let's Get Weird Again Finally, I'm looking around more for weird fun things on the internet. People just building stuff because they wanted to see it exist. While a lot of the internet feels mean or angry or hustle focused or just un-fun in a lot of ways, there are still lots of people who just want to make cool stuff and share it. It's out there if you just poke around a little bit. I'm hoping the stuff I put out there contributes just a little to making the internet a bit weirder.

I don't think it's just rose colored glasses that make me think that the internet was more fun in the past. While many things have gotten better, something valuable has been lost. You can't go back, but you can focus on the things that make you happy and minimize the things that don't. It's not as bold a statement as dramatically quitting Facebook only talking to your friends who use Signal, but the internet can still be fun if you just don't wallow in the worst parts of it.

I'll go into more detail about the software I built in a future post, but long story short I built a little blogging tool called Postwave and I needed a site to put it through its paces. I needed something that I could make frequent posts to and see what it was like to really use what I had built. So I created Don't Break Prod, a collection of bite sized pieces of career advice for software engineers.

I've been thinking about mentorship and ways to have a good life as a software engineer for a long time. I have a bunch of notes and a decent outline for a book of engineering mentorship that I started and lost steam on a few years ago as well as insights gained from being both a mentor and mentee. Eileen and I have had great conversations about career stuff that I often walk away from with good insights. So I started writing down a list of ideas about how to make your life better as a software engineer. These range from simple technical ideas like, embracing linters to broader ideas about avoiding burnout.

The idea behind Don't Break Prod is to do short form posts, something longer than a tweet but shorter than a full blog post. The title should give you the basic advice, the content should provide some food for thought around it. This has also lowered the activation energy for me to write new posts regularly, which helps a lot. I've deliberately avoided having a comment section because while I want people to read these and engage with them, I really didn't feel like managing a community.

I'm not really sure what my big picture goals are for Don't Break Prod. It's doing a good job as a testing ground for Postwave and in a time where it feels like most content just exists on a few social networks it feels good to be writing directly on a site run myself. As for the content of the site, I think that having a career tha makes you happy and fits into your life the way you want is important. Thinking about these posts has helped me articulate ideas that are useful for me and I hope other people find them valuable.

While I've been sporadically posting to the site for a few years now, I've recently been getting a little more serious about making regular posts and trying to share them more broadly. I'd love to reach as many people as possible, as long as I can keep writing posts and promoting them in my own weird way.

On the 1st Wednesday of the month I was always scrambling to move my street-parked car in the hopes of avoiding a ticket. Often too late. So I wanted something I looked at every day to remind me of things like this, just a little dashboard in my kitchen to let me know what was going on during the day.

While this isn't a particularly novel idea and I'm sure there are a few out of the box products that will do this, I just though it would be fun to build something custom for what I wanted. It ended up being a small Sinatra app and I decided to play around with htmx for most of the dynamic frontend stuff. The basic features I wanted were:

• a big clock (date and time)
• local weather
• a QR code to log on to our local wifi network
• events for today and tomorrow:
  • city events (street cleaning, garbage day, snow plowing, etc.)
  • birthdays (I don't look at Facebook enough anymore for it to be a reliable reminder)
  • our shared Google calendar

This is what it ended up looking like:

Some of these were pretty simple. The clock is just some plain old Javascript running client side. Birthdays come from a big hardcoded Hash that just looks up date. The city events came from some hardcoded logic based on the date, things like:

# first Wednesday of the month
applicable = STREET_CLEANING_MONTH_RANGE.include?(timestamp.month) 
&& (timestamp.wednesday? || timestamp.tuesday?) && timestamp.mday <= 7

The QR code just seemed like a neat little feature. You can create QR codes that when scanned will allow you to join a local wifi network without manually entering the password. I just generated my code from something like this site.

For local weather I ended up making use of the OpenWeather API. It refreshes infrequently enough that I can use it for free.

The Google Calendar integration gave me the most trouble. For some reason it was WAY more of a pain in the ass to authenticate with Google and use the provided library to pull a list of calendar events than I figured it would be. It involved a lot of creating and refreshing access tokens and is still a little janky (but it work!).

While I started doing the dynamic front end stuff with vanilla Javascript I ended up rewriting almost everything in Htmx, mainly because it seemed interesting and I wanted to play around with it. For the VERY simple stuff I was doing (mainly periodically refreshing parts of the dashboard to get updated content) it was very clean.

For example, I want my weather to reload every hour so on the main dashboard page (the page that stays up all the time) there's a div that looks like this:

It just pulls the contents of /api/weather_htmx (which is just some html, rendered with the updated weather info from an API call to OpenWeather) and puts it inside that div. Magic!

I bought a cheap refurbished tablet to use as a display and it's been a great addition to our kitchen!

The purpose of a now page to write up what you're doing right now. Basically what you'd tell someone if you were catching up and they asked "So what have you been up to lately?". The idea has been attributed to Derek Sivers (who apparently is the guy who created CD Baby!).

Why did I add one? Do people really care what I'm up to now? I don't know. But I've been growing a bit disenchanted with the state of the internet lately. It feels like a lot of people trying to squeeze posts in between ads on a handful of social networks. I miss when the internet was more distributed and a bit more personal and weird. This felt like a little push in that direction.

For more about now pages check out nownownow.com

Earlier this year I was listening to a lot of Death From Above 1979 and just got the urge to write some fast, high energy song with just bass, keys, drums and vocals. Sort of a cursed jazz trio. I was also looking to push my drumming, which has been a focus this year.

I started just writing and recording a bunch of bass riffs when I had random nights free and then I'd come back later, narrowing down which riffs I liked the best. Because I was just writing on bass I felt like I ended up writing riffs differently than I would if I were writing on guitar. I felt more free to wander out of keys and write more chromatically, since I wouldn't have to fit things in a larger chord structure. It was really a fun way to write.

From there I started piecing together some basic song structure and trying to figure out what to write lyrics about. I tired to let the topics of these songs be a bit more "whatever popped into my head", worrying less about having central, cohesive ideas. I ended up writing about social media (Black Box), people reminding me to eat well (Eat This, You'll Live Forever), and our cat, who likes to hunt our children (Natural Predator).

Once I had the song structures down I recorded bass (DIed into Logic with a fuzzy amp model) and then started really working on writing/recording drums. This project ended up being a good excuse to dive a little deeper into recording drums at home. I picked up a kick drum mic off of Craigslist, gathered a bunch of 57s to mike the snare and both toms, and used one of my condenser mics as an overhead. It had fun playing around with getting a decent sound and learned a bit about recording drums. My basement is not the best space to record, but I made due.

The drums took me a long time to record. Part of this was nailing down exactly what the drum part should be and part of this was playing it right. I'm really glad I did all the tracks to a grid. It helped to be able to follow a click and punch in where I needed to.

After the drums were finished I worked on vocals. I was probably most nervous about this part since vocals have never really been a strength of mine. I tried to just let go, project, be loud where it made sense, be a little screamy where it worked, and just commit. I also leaned into using a bit of fuzz on the vocals, which fit nicely with the aesthetic of these songs. All in all it turned out well. It's certainly not the greatest vocal performance, but there isn't much that feels bad or like the vocals detract too much from the songs.

While recording "Eat This, You'll Live Forever" I had the kids come in and sing "Eat this!" and used their takes to build gang vocals in the outro. I'm really glad I got them involved and they seemed to really like hearing their vocals as I was mixing things.

I finished up by adding some keys. Mainly synth or organ parts doing some countermelody or beefing up some parts. After that, a bit of mixing. I ended up doubling all the bass parts, one track with some fuzz/overdrive and another with a lower, cleaner sound to beef things up.

In the end I came out with something that I was really proud of. This is the first time I've done a true solo record where I've played every instrument and done all the vocals (apart from some gang vocals by my kinds). I didn't really know what to do with it so I just put it up on Bandcamp and sent the link around. I'd love for more people to listen to it, but honestly, I'm just happy I made it. And Or Not is a fun format, bass driven, high energy, so maybe I'll do some more of these songs soon!

Over the past few years I've had on and off bursts of focus on practicing. Practicing guitar, drawing, chess, things like that. And I always find value in quantifying how often I'm practicing. I like to know how many hours per month, week, year, etc. I've spent on that skill. I feel like, as long as I'm practicing the right things, I can feel good about the progress if I can see a history of it. Plus wanting to see the numbers can help make sure I stick with things.

In the past I was just writing simple Markdown docs and then ran a small Sinatra app that pulled metadata out of that directory and gave me some historical stats. I called that system Input Coffee.

I figured I could automate things a bit more and build something a bit more reusable, so I decided to build a small command line based tracking app, Trackstar. I recognize that this type of interface only appeals to a very select group of people, but that group includes me, so I built it.

It's a pretty simple idea. You use the trackstar -n program to create a log directory, then (when you're in that directory) just use the trackstar command to make a new entry. It will prompt you for a few things; title, time, and some notes, then turn it into a Markdown file. You can get some basic stats by running trackstar -s (again, in the log directory).

It's pretty bare bones right now and I'd like to iterate a bit on the interface (I do thing command line apps can have nice interfaces). I'd also like to do a lot more around the stats, maybe even pull in the Sinatra app/web based visualizations of the data to get a better history, we'll see. For now it's kind of fun to keep it as a purely terminal interface.

The whole thing is just built in Ruby and could probably stand to be optimized a bit, but it was fun to build a gem that was a pure executable thing, rather than a library. You can check out the code and full instructions for how to use it on the GitHub repo.

I'm currently dog fooding it by tracking my guitar practice. So far it's working pretty well and I'm making tweaks as needed. If this scratches a specific itch you have, try it!

(It's available on Spotify, Apple Music, Bandcamp, Soundcloud and lots of other places!)

I wrote about some of the songwriting in this post but the recording process for this record was very different from anything else I've ever worked on. Since I was playing a lot of the instruments and we were never going to have everybody in the band all together at once it would be a really piecemeal process.

The Rhythm Section

First Dane did some rough recordings of his drum parts using the demos I had created. This let me do my recording over a live drummer rather than programmed drums from Logic Pro. This really helped me get a better feel for the songs and made things feel much more organic. While I was recording over new drum parts I built the "working" versions of the songs from copies of the demos, that way I could just swap out the demo parts for final parts rather than having to build the song again from scratch. It was pretty cool to hear the songs evolve just by swapping in better recordings one instrument at a time.

My first work was laying down guitars. I actually ended up using the same amp model I used in the demos for the clean track but did all of the heavy guitar parts through my Dual Rectifier miced with a SM-57. I ended up double tracking almost all of the rhythm guitar parts (both clean and heavy) and I was really happy with the thickness that gave me. Most of the miced recording was done in my bedroom (which is carpeted) with the amp facing a closet full of clothes. The tracks for Too Ghoul For School were done in the garage (mainly to make it easier to record while Elliot napped) and they ended up having a harsher sound.

The bass work was pretty straightforward. I bough a DI box and recorded all my bass parts through that. I did take my bass (and old Washburn) to get tuned up before I did any of the recording and it really made a big difference. The keyboard work was also pretty cut and dry. I actually used some of the demo keyboard work for the final version (the first arpeggiated organ chord in Grave Danger, for example!).

The Horns

The horns were a little tricker. The horns in the demos were all done via keyboard and I needed to share the parts with the other horn players. For this I sat down with MuseScore (in awesome piece of free open source software fore creating sheet music) and transcribed all four horn parts. It was really cool to see the sheet music for my arrangements and I think it really helped Margret and Andy lay down the trombone and trumpet parts.

I was doing the tenor and bari sax parts, but I only owned a tenor (which I had bough earlier this year, specifically for this project) so I needed to track down a bari. This was actually harder than I expected. At one point I emailed a local high school band teacher to see if the school could loan me one. Ultimately I had to rent one from a music shop about an hour away. I only had it for a week and that was still pretty expensive.

I recorded the tenor and bari parts and then sent Margret and Andy a mix of the songs with only the rhthym section and my sax parts so that they could record their parts on top of that. Dane set up some mics in his basement and over a few weekends they got all three songs done. I think this was a very new experience for them and it was awesome to hear all four horn parts together on real instruments.

The Drums (for real this time)

After recording the horns, it was time to do the REAL drum parts. After considering a few options we ended up going to Justin at Waysound Studios for the drum tracking. I've worked with Justin on a lot of projects when I was in bands back in Chicago and he's always fantastic. There's actually a live recording of Dane tracking these songs, if you want to watch about 4 hours of drum recording!

The drums turned out fantastic and added so much depth to the songs. Now it was time to do vocals.

Vocals (and everything else)

Vocals were strange. I had an idea of how they should sort of sound in my head and I did the vocals on the demo, but I knew that Alan was the right person to sing for this record. The problem was that he was in Minnesota and I was in California and we were only communicating through email. He did some rough demos of the vocals and I sent some notes back and then he recorded the final versions. The vocals were by far the weirdest thing to do remotely.

I also wanted Josh and Chris to add harmonies so I just sent them a mix with Al's vocals and let them just record a bunch of takes and send me whatever they had. I wanted to add a few background vocals parts, too so I set up a mic in the garage and layed down some of my own parts. I ultimately just picked a bunch of stuff that sounded good and pieced it all together.

While I was blindly working with the vocalists, Dane and Emily were recording Emily's synth and organ parts. I didn't have these in mind when I was arranging the songs, but there are some synth parts that now seem like they obviously needed to be part of this music. They ended up being great additions.

Finally, I wanted to get my family involved. First I had Eileen do some high harmonies and "oooo"s in Too Ghoul For School (which was ripe for vocal layering), then as I was mixing I heard Elliot repeating the work "ghoul" during the chorus, so I recording him and added his vocals into a few sections of Too Ghoul. It was really fun to be able to give him his first record credit before his second birthday.

Putting It All Together

Now I was sitting in front of three enormous Logic Pro projects with up to 60 tracks a piece. I was not remotely qualified to mix what would probably be a 9 or 10 piece band so again we turned to Justin at Waysound. After fooling around with some clever exporting techniques, I ended up just removing any EQ and effects from all the tracks and exporting them all to WAV files and then sending those over to him so he could work his magic.

The whole recording, mixing, and mastering process took almost a year (with my "solo" recording using up the bulk of that time) but we had a finished product before our self imposed deadline of Halloween.

Recording the record in this way had its advantages. I liked being able to work at my own pace and on my own schedule (which was really important with a kid). The process of migrating the demo into a final version piece by piece made it easier to work on my own, since I never had to bootstrap the songs from scratch.

It was really hard to work in isolation though. I'm used to being in the studio with other people who can provide feedback and keep me from getting in my own head about guitar tone. I missed the comradery of hanging out in the studio with friends. I augmented this by texting Dane a lot during the process. Technically, if I did this again, I'd be more diligent about making sure EVERYTHING lined up with a click track from day one. When pulling in parts from many different sources, having one source of truth for timing is really important.

I can't overstate how much fun I had making these three goofy songs with a bunch of friends. Even though they're ridiculous in subject, they really mean a lot to me and I loved the process working on them. I already have the seeds for several more Grave Danger songs and I'm excited to work on new material!

If you haven't heard the record yet, please take a listen:

"Ok dude. Let's do it: Let's write a couple of skath songs."

Dane and I used to play in a ska band called Captain Supreme back in college. After Captain Supreme broke up we joked around about forming a new ska band, dressing up like skeletons, and writing songs about graveyards and monsters and ghosts and stuff. It would be skath!

It was a fun idea, but I assumed it would be like all of the other hilarious band ideas I'd had with friends: fun to talk about but we'd never write anything. Well, for whatever reason this was different. I got really excited and we started trading song name ideas: "Grave Danger", "Escape From Skull City", "Hearse Chorus Hearse Chorus", "Spider!? I Barely Know 'er!". In a fit of inspiration I wrote the lyrics to "Grave Danger" on the spot and we started talking about who else we could get involved. That weekend I started writing some music and it seemed like a project that we could really get off the ground.

Eventually I realized that if we wanted to have some actual songs to record, I'd have to get serious about writing. Inspired by Dane's participation in #5amwritersclub I decided that I could get up a little early every morning and actually get some creative work done. While I'm not crazy enough to wake up at 5am, I did get up before 7:00 and found 30 minutes to an hour almost every day to make progress on these songs.

It felt really good.

I felt like a musician again and I felt like a songwriter again. Most of the songwriting I had done since leaving The American Autumn was done in single sessions. If I could get a full song out in a night, it didn't get done. This was different. I struggled through false starts that just wouldn't come together. I had to figure out how to connect parts that were cool on their own but needed to sound cohesive. I had to arrange a four part horn section without overwriting things. It felt good to put in the work on a creative project.

About six months later I now have three songs demoed: Grave Danger, Escape From Skull City, and Too Ghoul For School. I recorded all the music and vocals myself, using a keyboard for horns and Logic Pro's drums. Now I'm ready to do real recordings of this. I'll still play a lot of the instruments, Dane will be doing the drums, and we'll be getting other people involved to do vocals and other horn parts.

Six months may seem like a long time to write about 10 minutes of music, but I'm really proud that I was able to get these songs written and demoed while having a new baby and a busy job. What are we going to do with this recording? I'm not sure. I don't know if the world is clambering for ska songs about ghosts, so I might not quit my day job but that's ok. I really just want to see these songs exist.

Here's a few snippets of the demos:

I enjoy writing Ruby and I like things that are fast, so I've been trying it out. While it is still pre-1.0 it's been pretty nice to work with. And since it's a new language, there's an opportunity to write new libraries (known as "Shards" in Crystal).

My first Crystal Shard has been a money handling library, inspired by Ruby Money, that I call Moola. It gives uses the ability to define Money objects and do basic operations and conversions with them. Here are a few examples:

money = Moola.new(42_00) # creates a new Moola::Money object
money.format # "$42.00"
money.cents  # 4200
money.zero?  # false
money.to_f # 42.0

Moola::Money.new(5_00) == Moola::Money.new(5_00) # true
Moola::Money.new(5_00, "USD") == Moola::Money.new(5_00, "EUR") # false

Moola::Exchange.add_conversion(Moola::Currency.find("usd"), Moola::Currency.find("cad"), 1.3)
money = Moola.new(1_00, "USD")
money.convert_to(Moola::Currency.find("cad")) # Moola::Money(1_30, "cad")

I don't have much to say other than it seems like a great language if you like writing Ruby. For a newer language it's been a joy to work with and it's fun to build some basic libraries.

If you every find yourself writing Ruby and dealing with money, I encourage you to try out Moola.

I think my favorites from this group are the lonely space man, the tired dad, and the girl with her lizard.

The prompts for the drawings I did (in order) are: hungry, sad, hidden, jump, worried, scared, wet, escape, squeeze, tired, box, and friend.

I also posted these to Mount Saint Awesome, just so I don't completely forget that I have a comic.

To prepare for this life-changing event we've been trying to read up on lots of things as well as asking lots of people for advice on both pregnancy and parenthood. We knew, even before we got pregnant, that we'd wanted to digest this info and experience and share it with other people and we wanted to do that with a podcast. We actually talked a bit about doing a podcast back when we were both in improv and considered the possibility that we might be hilarious.

Whether or not we're all that clever, we did manage to start a podcast! It's called Don't Screw It Up and as of this blog post we've done 5 episodes. In each episode talk about different topic such as telling other people that you're pregnant or traveling with a belly full of baby, trying to actually site some legitimate research while still being entertaining. We're trying to take a less reverent, you-are-gia-mother-earth, everything is beautiful and magical attitude towards the whole processes of procreation which is in contrast to a lot of the blogs and other podcasts we've come across geared at future baby owners.

This is my first foray into recording a podcast and it's been a lot of fun to do the audio side of things. We're just recording with my Shure 57 and the MXL condenser mic with some pop screens. Once we start having remote guests, I think I'm going to need to work with this software I found called Looback that lets you create pass audio from one application (like Skype) to another (like Logic Pro X).

By the way, if you want to be a guest, let me know!

Doing this podcast has been really fun so far and it's cool to work with a new medium like this.

Check us out though all of these avenues:

Don't Screw It Up website

iTunes

Facebook

Twitter

I built a really basic time tracking tool, which turned out to be a really strong motivator. Seeing a graph of my practice time each week made me want to keep focused. Here's the graph from the past year:

I didn't do as much as I had hoped but I feel like I made some decent progress. My final numbers were:

guitar: 81 hours (128 posts)

art: 21 hours (39 posts)

chess: 5 hours (10 posts)

vocals: 1 hour (2 posts)

Obviously I wasn't that focused on vocals and I kind of gave up on chess pretty quickly, but I made a decent showing for guitar work.

I didn't let myself count noodling while watching TV or going to band practice. This had to be focused practice where I was really trying to learn something new or fix something sloppy or work on a skill I was lacking. I would have liked to hit 100 hours but 81 is still a lot more than I've put in any year prior.

Art was a mild success. I did count my time doing Inktober because a lot of that was drawing novel subjects, but a lot of the other work was fundamental practice and sketchbook work. I also spent some time ramping up with drawing digitally, which I now use a lot for Look At Me I'm a Racecar comics.

This Input Coffee project has really been helpful in getting me to work on skills that I actually care about. Over the next year I'd like to hit 100 hours of guitar and branch out a bit to some under-practiced skills I'd like to have.

Once again I received a Build Your Own Clone pedal kit for Xmas, this year it was the Classic Compressor. I've been playing a lot more guitar these days and I seemed like it would be fun to tighten up my sound a bit, so a compressor pedal seemed like a fun project.

The build itself was pretty simple and straightforward. Soldier all the pieces together. Don't burn myself. Don't burn anything important. I'm actually getting pretty decent at soldiering, if I do say so myself! What I wanted to do differently with this build was the visual look of the pedal.

The enclosure that comes with the kit is... utilitarian, to say the least. This time I wanted to not only paint the enclosure, but also design and print my own decals for the pedal. The painting was pretty simple, I just sanded down the enclosure, put down a coat of primer, and then used several coats of spray paint.

To do the design decals I ended up drawing some stuff using my Wacom tablet and then doing a layout in Photoshop and finally printing everything onto waterslide decals. For the design I ended up just drawing a simple coffee mug with the word "compresso" on it because it sort of sounds like espresso. Meh... it kinda works! The waterslide decals were pretty cool, you just print onto them, spray them with a clear sealant, wet them and then slide them onto the surface. Once it dried, I sprayed the whole thing with a few layers of clear sealant so the decal would chip or peal off as I stomped on it.

Last, but not least, I wasn't quite satisfied with the nobs that came with the kit. I wanted something a bit more retro looking so I bought some oven nob style nobs on Amazon to use. They didn't quite fit the pots on the pedal so I had to Dremel them out a bit before I could put them on the pedal. It's always fun to have an excuse to play with a Dremel.

The end result looks pretty cool (and sounds pretty good too!) I actually took apart the first pedal I built, an overdrive, with the intention of painting and adding a decal to it as well. The stuff I learned doing this pedal will be very helpful.

Here she is:

As I've been sadly neglecting Mount Saint Awesome these days, it was really nice to get back to drawing regularly. Doing this project really helped me explore other styles and techniques and also draw things that I might not have drawn for comics (like armadillos and astronauts). It was also good to work in just black and white. I've struggled with shading and shadows in black and white drawings in the past and it really helped to be constrained by this medium. There were a few drawings I wasn't very happy with, like the Gameboy, but all in all I was pleased with most of the work.

Hopefully this rejuvenates my art as I'd really like to get back to making comics regularly.

Here are all 16 Inktober drawings I did:

Note: I've also posted these as one big image to Mount Saint Awesome.

Recently I've seen a steady stream of people starring and forking the Darwinning repo on Github and I've received some really thoughtful and helpful pull requests from people, so I wanted to give the library a bit more attention. I had some free time this weekend and used it to finish off a major feature that I had been working on and finally published the 0.1.0 version of the gem!

The major feature I added was the ability to use Darwinning in existing Ruby models via include. This lets you utilize the library in projects that might not be specifically about genetic algorithms.

Here's my dumb, contrived example:

require 'darwinning'

class Triple
  include Darwinning

  GENE_RANGES = {
    first_number: (0..100),
    second_number: (0..100),
    third_number: (0..100)
  }

  attr_accessor :first_number, :second_number, :third_number

  def fitness
    # Try to get the sum of the 3 digits to add up to 100
    (first_number + second_number + third_number - 100).abs
  end
end

Then you can use some nice built in methods to generate a population of these objects and evolve them towards a fitness goal:

if Triple.is_evolveable?
  triple_pop = Triple.build_population(0, 10, 100)
  triple_pop.evolve! # evolve until fitness goal is or generations limit is met

  pp "Best member: #{triple_pop.best_member}"
end

I've been having fun working on this project and it's really cool to see some other people contribute to the project. If you want to play around with the library or have an interest in genetic algorithms just gem install darwinning or check out the Darwinning Github repo. There are always more updates to do, but it felt good to make some progress on this project.

If you don't want to read all my thoughts on recording the song feel free to just go listen to it now. I'll only be a little offended.

This song was written to be played live, only on acoustic, and has some holds that feel pretty loose so I had to start off by making sure I could actually play it with backing drum track. It took me a few tries to get the feel of it but I think it came together without sounding too rigid.

After recording the acoustic part, I got to have a lot of fun writing all the other things that go on top. I had a lot of fun with the bass and actually mixed some of the low end out of the acoustic to give the bass more room. The piano in the chorus really came together pretty nicely, particularly the hits under "I can't wait to write...". The left hand work there gave it some good body.

As usual, I was tempted to do more electric guitar noodling than I should but some after some editing I was pretty happy with the little theme I had in the verses. The lead part in the choruses ended up acting as more of a harmony that gave the chords an interesting sound at times.

There's a part in the 3rd verse right after the line "together with our furry child" where it sounds like someone just stepped on a piano. That's because the cat just stepped on the piano there. Since the line was actually about him I mixed it down but left it in.

The outro was interesting in this song. It was originally the verse or chorus of an early draft of this song that never really panned out, but I liked the lyrics and it was in the same key as the rest of the song so I really wanted to make it work. Also it was a nice held chord segue into actually popping the question, which was pretty important at the time.

I wanted to be sure this still sounded cohesive with the rest of the song, but still go out big and I think it turned out well. While I could have mixed it a little better, the pick slide into distorted power chords is just a lot of fun. The piano part was just something simple I stumbled on while I was messing around, but I really like what it adds. I ended up doing a lot of editing to decide which instruments should stop when and I'm happy with those choices. There was a lot of value in editing this song a few days after I had done most of the recording.

All in all, I was really happy with how this turned out and Eileen seemed to like it too. It's always fun to record original music and this song was particularly important to me.

I decided to start tracking this sort of thing again, partially in response to reading Make It Stick, and I wanted a simple way to track my practice sessions for things like guitar, chess, drawing, and other stuff I'm working on these days.

I started by just creating Google Docs for each session, which worked fine and helped me not avoid doing real practice by spending a bunch of time building a complex system to track my practice. But then I gave in and built a system to track my practice. Like the original WordPress blog, it's called Input Coffee.

This system is pretty simplistic, just a Sinatra app that reads some Markdown files and turns them into CoffeePost objects so I can examine them based on tags, subject, date, and a few other fields. The Markdown files use a format very similar to Jekyll's posts and I just parse out meta data from the little header. Here's an example post:

date: 2015-07-14
subject: guitar
tags: acoustic electric
hours: 1.0

Spent most of this session doing acoustic stuff...

I don't even have this hosted anywhere, I just run a local server when I want to see stats about my practice. Right now I just show total posts/hours (since May 25th, 2015), some breakdowns by subject (guitar, vocals, chess, drawing, etc.), and some numbers for the current and past week

Obviously, I'd like build out some more metrics and it might be fun to make a nicer interface, but for now this works for me and I've avoided overly-over engineering the solution. Being able to track this sort of stuff really helps keep me in good habits.

Here's a link to the song if you want to listen right away.

This is a pretty faithful cover. I didn't deviate too much from the original version and actually resisted my urge to add some lead guitar parts to the song. In place of the slide guitar, prominently featured in the original song, I focused more on the organ part to do something tonally interesting against the acoustic guitar. The organ also just fills the song out nicely without adding a bass part.

I also recorded some saxophone for the first time since recording the last Captain Supreme song, which was pretty fun.

This recording session gave me the chance to really work with with my new vocal mic (MLX 2003A) and my new monitors (JBL LSR305s). I ended up using the MLX for both vocals and the acoustic guitar and just used my SM57 for the sax. It was really nice to be able actually hear things in the mix with the new monitors. Hopefully the end result is better for that clarity.

As always, vocals were a challenge. They're not perfect but I feel like I'm making progress, which is always nice.

Enjoy!

Rust is a systems level language created by Mozilla that might be used in similar situations as C++. I haven't done anything this low level since I had to use C++ for a data structures class my sophmore year of college, which was a surprisingly long time ago.

I needed a small project to build if I was going to learn anything about the language so I decided to build a Bloom filter. A Bloom filter is a probabilistic data structure that is designed to be really space efficient and allows you to determine if something is "probably in the set" or "definitely not in the set". For example, web browsers use Bloom filters to store lists of dangerous websites, which is why you sometime get a warning for an obviously safe site.

The end result of this little project was Bloomfilter-RS, a small Rust library that implements a Bloom filter. It can be used like this to create a Bloom filter with 100 buckets and 5 hash functions:

let mut bf = BloomFilter::new(100, 5);

bf.insert("hamster");
bf.insert("coffee");

bf.check("hamster");
// (probably) true

bf.check("oatmeal");
// false

It was pretty interesting working with a lower level language coming from Ruby. I had to think about passing pointers and dealing with a much more robust type system. Fortunately working with Scala in the past prepared me a bit for dealing with generics and default immutability, but it really felt MUCH slower than working with a high level language like Ruby (which I suppose should be obvious).

I don't really have a major project in mind that needs a language like Rust right now, but I'd like to keep tinkering around with it just to expose myself to other types of langues. It's also just fun to follow a language as it's being built (as of this post Rust is still a few weeks away from it's official 1.0 release and some of the API still isn't quite stable).

Feel free to dig through my Bloomfilter-RS code and give me any feedback about style or a better way to use language features. It was certainly built as a learning experience.

I had been sketching the other day and I found it was a lot easier to decide on something to draw if I started with a box, like I would when drawing comics. I was looking for a subject for some comic-like art and decided to do a drawing for every song on this record. The scene-setting and exposition in these songs made them a perfect subject and it ended up being a really fun project. Some of the scenes I drew were just snapshots of things described in the lyrics and for some I took a few interpretive liberties. I recommend listening to the record while checking these out. Enjoy!

I'll probably post these on Mount Saint Awesome soon, but this seemed like more of a project than a comic, so I wanted to do a blog post first.

While some weeks I did manage to work with in those bounds and produce a standalone project in one week (for example; the bass pedal, my cover of In The Garage, and the Therimino) I actually ended up spending a lot of my Thing A Week time on pieces of larger projects like RecLaboratory and the photo listener. While this wasn't the original intention of the exercise I was still able to use the model to break up chunks of work and produce stuff worth talking about almost every week.

In the end I did 36 Thing A Week posts last year. Not as good as the 52 I would have liked, but it still represents a lot of productive weeks. I also found it really valuable to write about what I was working on each week. I think I just really enjoy sharing both the finished product and the process for the projects I work on.

Here are some things I made last year:

• a non-working video game
• a bass pedal
• the save the date card for my wedding
• a webservice that pulled tagged images from Twitter and Instagram
• a bunch of music
• a ring box out of an old book
• some watercolor paintings
• a webservice where you can do collaborative music recording
• an electronic musical instrument

While I really enjoyed doing the Thing A Week posts last year, this year I'm not going to have the same weekly goal. I may do some more Thing A Week style posts when I finish a project but I'm trying to focus more on just doing stuff rather than only on getting stuff done. For example, when I was writing music last year I focused a lot on writing things that I knew I could finish quickly so I ended up with a lot of short musical ideas, but not very many complete songs. I want to spend more time doing things like art, music, and coding (and whatever else sparks my attention) and doing it well. Maybe this means spending more time drawing in sketchbooks and less time making finished comics. Maybe this means starting a couple of songs and working on them until I'm REALLY happy with one.

I have a few project ideas (some big, some small) that I'm already starting to plan out, so I'll try to keep up with regular Thing A Week style postings discussing my progress on those things, even if it's just for my own enjoyment.

Last Christmas my mom got me a distance sensor that could be easily used with an Arduio (which is a totally normal gift) and I finally got around to playing with it. I had originally wanted to start working on some sort of robot but first I wanted to just play around with it and see what I could do.

After running through a few tutorials I decided it would be fun to make some sort of crude musical instrument using the distance sensor. I learned a bit about how to hook up a tiny speaker and then used the value of the distance sensor specify which tones to generate.

This created something that just constantly made steady sine wave sounding noise. I wanted to add the ability to do start and stop notes so I attached a small pressure sensor to the project. Then the tone would only play if you were pressing down on that sensor.

I also added a small LED light that turns on when a note is being played because lights are neat.

Because you control the instrument by moving one hand around, like you would on a theremin I decided to call my new creation a theremino (like theremin + Arduino... get it?). Unlike a theremin, the theremino plays discrete notes from a regular chromatic scale, changing notes every 4cm you move your hand from the sensor. It has a range from B2 to C6.

As you can see from the video below this instrument is actually kind of hard to play. It's tough to be accurate with your notes when moving around in mid air.

It had been a while since I had tinkered around with an Arduino, so this what a really fun little project. For those interested, I have the the Arduino code for this project available here and a wiring diagram for the Ardunio and breadboard here.

This doesn't mean it is complete or bug-free by any means. I'm sure there a lots of little rough spots and the UI, while not terrible, is still pretty bare-bones. But our goal for this "release" was to get the site to a point where we could show some friends and let them try things out. We really just want to see if we're headed in the right direction with what we have so far before we devote a lot of time to polishing the UI and the code base.

It's pretty exciting to finally start showing off something we've been working on for a long time (on and off for about 6 months now). While it's kind of nerve-wracking to worry about something breaking now that people other than Bobby and I are on the site it'll be fun to see how people start to use what we've built. We're rolling out invites very slowly as we become more confident about the feature set and stability of the system.

I also started a RecLab Blog (my first Tumblr account!) to act as a sort of company blog now that we're trying to involve other people in the site. As always you should follow/friend/read/whatever our Facebook, Twitter, Instagram, and blog.

Please go to www.reclaboratory.com and sign up to become an early tester and we'll probably send you and invite soon!

After getting the in-browser track recording to a working place the previous week, I wanted to reuse most of that functionality in this new modal. Building this new feature on top of that existing code caused me to refactor a few things, which was great. I also had to add the ability to use multiple tracks as a "backing track" for the recording because I imagine that users won't want to bounce the song after every recorded track. This takes advantage of the track pre-loading I had already built into the song page and a little bit of html5 audio object abuse.

This is one of the last functional pieces of the site that needed to be built before we start soliciting alpha testers. Originally we had wanted to open RecLaboratory to early users on September 8th (almost exactly 6 months after Bobby and I first started talking about the idea) but we really wanted to get the last features in so that we could offer users a compelling reason to interact with the service. I think we're getting REALLY close now!

I had been messing around with a little arpeggiated riff and I wanted to build something pretty repetitive, getting away from a verse-chorus-bridge structure. After I had the riff, I started building the drum part. The real breakthrough there was throwing in the handclaps, which start off sounding so happy but then sound more ominous under the bass and main guitar riff. Despite being pretty core to the whole song, the bass part didn't come in until much later in the writing process. I also ended up using amp models with a lot more reverb than I typically use. I have a tendency to seek out drier guitar tones, but the more spacious sounds really worked for this piece.

I resisted the urge to just keep stacking more and more tracks on top of each other in this song and let some parts be pretty sparse. I think I could put some lyrics over this but it was getting late and nothing was really jumping out to me, so I'm pretty happy with it being instrumental for now.

Enjoy!

One of my favorite cartoonists, Mitch Clem, has been working with his wife(?), Amanda to use watercolors in his comics for a while. They've done some really cool stuff in both color and black and white. I've seen other comic artists do it too and I've always loved the effect.

After a trip to the Walt Disney Museum, particularly the Mary Blair exhibit, with Eileen I was really inspired to try painting something so we went to the art store later that weekend and picked up some supplies. As a first project I wrote a short (questionably funny/comprehensible) comic and tried to paint that. The result was pretty cool, for my first time, and a lot of fun to do. It was a bit tricky working with watercolors in such a small size (the panels were maybe 2" x 3") but I learned a bit and really enjoyed the medium.

Then over the weekend I wanted to do a single scene and had the idea of just doing a simple girl playing guitar on stage. After watching a whole season of Inkmaster I decided to throw a few tattoos on her, as well. I am particularly proud of the hands in this piece. Usually I just give up and let the hands sort of fall apart, especially on guitars but I thought these turned out well. I'm really happy with how this turned out and I plan to keep working with watercolors in the future.

The core technology for this whole process is getUserMedia(). This is what prompts the user to allow the page to access the mic (or camera or whatever) and then handle a LocalMediaStream object. From there you can work with whatever is being picked up by the mic.

Outputing the audio in real time was very easy (hey I built a monitor!) and after doing a bit of research I found a fantastic library to help with the recording aspect of this project: Recorderjs. It provides a nice Recorder object to work with and, best of all, it's a VERY small, easy to understand library so I can go through every line of code and understand exactly what is being done. This is very important because all of this in-browser media work is very new and deep tutorials are rare. Plus I'm going to need to do a few things that haven't been done perfectly yet.

Right now I'm working on taking the recorded audio, which exists as a Blob tied to the page it was created on, and sending it back to the server to be uploaded in a way that works nicely with our existing Paperclip system. I'm really digging into some of the new HTML5 APIs for all this work and it's been really interesting.

The in-browser recording is the last new major feature we need to build before polishing up the RecLaboratory site (which I updated this week, too!) for a very early, very small beta. I'm really excited to get people using this tool soon!

I knew that I wanted custom instrument, track, and song icons so I started out with a small set of 8 (with plans to make more as we need them). I did these icons the same way I do my comics: first drawing in pencil, then inking, then scanning into Photoshop, then cleaning up the lines and adding color in Illustrator. They had to look good at a wide range of sizes: 400px to 30px so I didn't add too much detail.

To handle what I think will be the most commonly used instruments I started with (electric) guitar, (electric) bass, drums, keys, vocals, sax (perhaps my own bias), percussion, and general track.

So here they are!

Guitars are still hard to draw.

I used a small pallet of colors for all the icons in the hopes of creating an overall cohesive effect when they all get seen together on the site. Bobby doesn't like the percussion one very much and he's probably right. It's my least favorite too, but this seems like a good start and really adds some nice visual variety to the site. Plus it's always fun to draw things!

There are still quite a few things to fix up, particularly with Rocktopus, but it's nice to see the full application working together on remote servers. While the Rails/Heroku setup was pretty straight forward, Rocktopus was uncharted territory for me.

I had never "launched" a Flask application before so this was all a bit new. As a (temporary, I swear!) measure I moved the files to my server over SFTP and started up a Gunicorn server to run the application. I still need to put Nginx in front of all of this but for now it works as expected (though I can't imagine it would handle much traffic). I'd also like to learn more about Fabric for Python deployments. I've never been much of a sysadmin, so this was all a bit new to me.

The only really new thing I did for the Rails/Heroku app was add Unicorn as a server. Heroku has a great article that held my hand through this setup.

Also, as part of this setup I've been playing around with Slack and it's wonderful integrations for monitoring the app. So far I have it working with Heroku, PaperTrail, and Pingdom. Nothing's gone wrong yet, but I suppose that is to be expected when there are no users...

As I mentioned, there are still quite a few rough edges to be worked out, a bunch of minor features, and at least one major feature that still needs to be built but this feels like a big step in getting RecLaboratory launched and letting people try it out. We have some people in mind for VERY early alpha testers, but please let me know if you're interested in trying it out when it's ready!

For the wedding I wanted to build a ring bearer box out of an old book. After looking around some used bookstores I picked an old Tarzan book because 1) it seemed common enough that I didn't feel bad using it as materials and 2) it had a cool elephant on the cover. I wanted to hollow out part the inside pages and create inlays to hold the rings (like a secret flask holder but for wedding stuff).

I started by covering the covers in plastic (to avoid getting glue on them) painting the sides of the pages with puzzle glue in order to stick all the pages together. I did about 5 coats of this. Once that glue was dried I measured out the inlay and started carving pieces out using an Excato knife. This took a lot longer than expected and when I was down about half an inch, I coded the new inner wall with glue to give it a nice solid feel.

After I had my basic inlay I needed to dig out the slots for the actual rings. This was even more tricky. I thought I would be able to make clean cuts, like I did with the inlay but I ended up basically using the knife to turn the paper into pulp and then just digging the pulp out of the the slots. After removing top page from the inlay, which had been pretty well torn up by all the digging I was left with a nice ring box.

The pages held the rings perfectly and I could even hold the box open and upside down without the rings falling out. The box was put to use by our ring bearer, Sui Chi, on Saturday and it looked great! This was a cool little project and it was fun to build something non-digital again. It really took a lot longer than I expected but the result was worth it.

The work I did get done earlier this week was mainly with the RecLaboratory interface to Rocktopus, our audio processing API. I built the interface to the bounce_song functionality, which will take all the individual tracks of a song and combine them into a single (probably .mp3) file.

I also set up a sort of hacky but effective, for now, "loading screen" to let users know that their audio is being uploaded/processes. It seems like a little thing but letting the page just hangs after clicking submit is really bad UI. This is a very early version of the product and we haven't given UI the full focus it needs but this was one thing that would be too awkward to not address early. It was a bit of an awkward fix because we're not actually doing the audio processing or uploading as a background process. Eventually I'll build a queuing/callback system in Rocktopus that will work much nicer, but this gets us going now.

This next week is another busy week. It is the last week in SF before we fly back to Chicago for the wedding (which is less than 2 weeks away now...). If I get anything Thing A Week thing done this week it will probably be something wedding related.

I spent this week adding more features to the RecLaboratory audio player and I feel like it's in a pretty good spot for now. Obviously, there's more I'd like it to do but it's certainly at a point where it will work for basic track and song playback.

Here's a list of new features that got added this week:

• Visual indicators on the in page play buttons to show what is playing in the global player
• Some basic layout polish and player styling
• Jump forward or back in the audio by clicking on the progress bar
• Play/pause using the space bar
• Some basic (if clunky) error checking to make sure files loaded

One really interesting thing I found this week that I didn't expect is that audio playback is not interrupted by navigating around the site. If I reload the page the sauropod.audio object is empty and playback stops, but not if I'm just clicking links on the site. I haven't had time to explore it completely yet but I suspect it has something to do with either the way Rails caches JavaScript or with TurboLinks.

I'm really happy that is "just works" that way, I was worried that I would have to go back and turn this whole project into a single page app eventually to get uninterrupted playback, so this is a nice win. I do need to spend some time testing things to make sure I understand WHY it works. It seems dangerous to accidentally get a nice feature like this.

Like I said, while Sauropod is still a little rough around the edges, it's good enough to use for the site. I'm now moving on to fixing up the interface to Rocktopus for audio compression and song bouncing.

This week I'll be traveling to New York for a friend's wedding, so my Thing A Week time may be limited. Also I need to eventually finish writing the ceremony script for my wedding or else some people are going to be mad at me...

I got Sauropod hooked up into the asset pipeline of the RecLab Rails site and started attaching it to the various audio controls on the site. While Howler.js handles loading the audio file and playing the sound in browser, I still needed to build all the hooks to control and monitor the audio.

At this point I am able to click a "play" button next to a track and have Sauropod load the song and update global play/pause button, display the name and owner of the track (with links), and display a progress bar and time progress. I also have a global mute/unmute working and started on global volume controls. Most of the controls and UI updates were just simple hooks into Howler and some jQuery for display manipulation, but the progress bar and timer were a little tricky. While a regular HTML5 audio player sends an onprogress event that you can listen for to control the progress display I had to write my own listener that starts an stops with the audio. It wasn't very hard, I just used a setInterval() function around my own sauropod.updateProgress() function:

sauropod.play = function() {
  if (sauropod.audio.status != "playing") {
    _.each(sauropod.audio.tracks, function(s) {s.play()});
    sauropod.audio.status = "playing";
    sauropod.updatePlayer();
    sauropod.tid = setInterval(sauropod.updateProgress, 100);
  }
}

I still need to build all the hooks into playing a mutitrack song (though it should work based on how I've built the system) and then work on the track editing features (muting/level adjustments at a per-track level). I also need a bit more robust error handling and a cleaner UI, but all in all the audio player is coming along nicely.

Thing A Week Progress Update

So this week marks half a year of this "Thing A Week" project. It hasn't been exactly what I planned, one discrete project finished every week, but it has really keep me focused on building things and I've really enjoyed writing about my progress on all the things I've been working on.

Almost all of the weekend was devoted to knocking off extra wedding things, like designing take-home gifts for guests and buying a bunch of ties. There is a big list of things that we apparently need to do, but we're making good progress on it.

We had a really productive RecLab meeting on Tuesday where we worked out some good layout stuff and got the feed stuff into a good place. With the basic feed working, I am now able to move on to the audio player component: Sauropod.

Why is called Sauropod? Well a while ago I had to build an HTML5 based mp3 player for a job interview and I decided to call it 5auropod because 'sauropod' kind of sounded like 'iPod" and the '5' because of HTML5. Also sauropods are cool, enormous dinosaurs. When I started working on a player for RecLab I wanted to use the same name, but I was worried about starting JavaScript variables with a number so I just used "Sauropod". Convoluted, I know, but it makes sense to me.

Right now Sauropod is in it's VERY early stages, mainly just building out method names to architect the system. The basic idea is to build a library to work with songs and tracks that contain metadata and possibly multiple audio tracks that need to be played simultaneously or adjusted individually. I'm using Howler.js to handle most of the audio heavy lifting. It's been pretty awesome so far. I'm also trying out Underscore.js to give me a bit of functional programming in JavaScript. This is mainly to make working with arrays nicer, which I will have to do quite a bit with the arrays of Howler.js Sounds that make up songs.

Sauropod is still in it's very early stages, but I have a pretty good architecture planned out and I'm excited to see it develop.

First I took some pictures to use as a cover photo on our Twitter and Facebook pages. This ended up being a big project that involved moving a bunch of my music equipment around and finding a clear area in my small apartment. I am not a great photographer but I'm pleased with how it looks. Feel free to follow/friend us on either. We're starting to post things.

Last Wednesday night I just couldn't sleep so I stayed up until 2:30 and knocked off a few bugs around comments but the major work I got done this week was around the event feed. I knew I couldn't just rig something together with a bunch of ugly table JOINs I ended up using the public_activity gem. It listens for controller actions and makes an entry in a separate table for every event I want to show up in the feed. Most of our events are just the result of object creation and public_activity handles this really well right out of the box.

Right now I just have basic events around Users, Comments, Tracks, and Songs and I need to clean up how I'm using the public_activity params hash to avoid some n+1 database call issues but so far it's made it really easy to build feeds on User, Track, and Song pages. I'm working on building the main homepage feed now, which is proving a little trickier. Obviously I'd like to do this with a single call to the Activities model but because it's tracking polymorphic objects, the SQL is taking some work.

I'm hoping to have the feed stuff done by next week and start setting up a non-local version of the Rails site + Rocktopus soon. Then I have BUNCH of WebAudio stuff to work on around the player/audio tools. Oh, and I should probably be planning my wedding at some point too...

bonus thing

I actually drew a real comic this week, one where I penciled and inked and everything. Check it out!

For those who don't remember, Bird Watcher is a system that listens for photos with certain #hashtags and displays them to a live page. I plan to use it to let people take pictures during our wedding and show them on a projector during the reception.

This project has spanned a few Thing A Week posts and involved playing with the Twitter and Instagram APIs, as well as learning a bit more about Postgresql and the Sequel gem.

At this point most of the hard work had been done. I have Twitter and Instagram listeners (which both work in very different ways) that store info about photo posts in a database. I just needed to write something to pull them out and display them.

Originally I had written some nice code for prioritizing new photos and minimizing database calls but that ended up being a scoping pain in the ass in Sinatra. I would have had to build some sort of session object persistence system and honestly, the scale of this project just wasn't worth it.

I ended up with a simple AJAX loop on a timer that pulls a random "photo card" with the image and some information about it, and displays it on a page that should work nicely full screened on a projector. I still need to run some tests to make sure I don't get any weird image sizes but it's working well right now.

I'm a little worried that I'll spend part of my own wedding reception tweaking code or sshing into my server to restart some service, but I think everything should run pretty smoothly. This was a fun little project and made me play with some new technologies. Hopefully lots of people use it at the wedding.

I want Reclab to namespace songs and tracks by username, similar to the way Github namespaces repos. Obviously I also want to use nice identifiers for the resources rather than just id numbers, so I started by setting up FriendlyId, which is a great gem for this sort of thing.

What's really cool about FriendlyId is that it can generate a slug that is unique across multiple fields in the object. For example, I want to allow user1 and user2 to both be able to have a song name "My Song One" so I want the path to each song to be something like user1/songs/my-song-one and user2/songs/my-song-one. Note that the song identifier "my-song-one" is only locally unique, not globally unique. To do this FriendlyId lets you scope slugs:

extend FriendlyId
friendly_id :name, use: [:slugged, :finders, :scoped], scope: :user

Then, in order to get things to work with ActiveAdmin I had to make Songs "owned" by Users. If you don't do this, ActiveAdmin tries to use the FriendlyId slug as a globally unique identifier. This is an easy fix in the /admin/song.rb:

ActiveAdmin.register Song do
  belongs_to :user

I still need to clean up the routing in the rest of the app but this was a big step forward to some nicer paths.

Again, this is sort of cheating because most of the creative work was done by our very talented friend Debby. After listening to our asinine ideas she designed awesome invitations, RSVP cards, and thank you cards.

Then it was our job to pick out paper and envelopes and all that other stuff (which is a much bigger ordeal than I had ever imagined). Eileen and I both took a morning off of work just to talk to paper stores and printers. It was exhausting.

Once everything was actually printed on fancy paper we had to do all sorts of crafty things like tie twine around the jackets that hold the invitation and RSVP card, addressed all the envelopes, print return address labels, and puts stamps on everything. None of it was particularly hard (except for maybe addressing everything, but Eileen did that because my handwriting is illegible) but it just took a LONG TIME.

On Saturday morning we got everything mailed out, which felt good. This was a much bigger project than I expected it to be, but they turned out really cool.

The major breakthrough was getting the Rails site talking to Rocktopus, the audio processing API I've been writing. It's not perfect but it has some basic authentication and the Rails Track model gets updated based on the response from Rocktopus. This is all just working locally right now but it shouldn't be hard to set up a server to server connection once I have Rocktopus deployed somewhere.

The other large chunk of work I got done was due to being home alone this weekend. With Eileen hanging out with friends in Napa I decided to start working on the first real site layouts. I made great progress on the user profile pages and started doing some of the url rewriting work. I considered dropping Bootstrap in favor of Bourbon/Neat/Bitters after exploring the latter libraries at work but I think for what we're trying to build right now Bootstrap will get us up and running much faster.

As always, there's still a lot of work to be done but it felt good to make some serious progress this week. Again, if you are interested in this project head over to reclaboratory.com and enter your email. We'll get in touch with you when we're ready to start letting people try the site.

While I did make some progress on getting the RecLab Rails application to connect to Rocktopus (our audio processing library) the main thing we got accomplished last week was setting up our RecLab presence online.

A major part of this was building out a Launchrock page to point our domain at. So now if you go to reclaboratory.com you actually see something! Right now we're just collecting email addresses, but building this out helped us think through some basic service descriptions, a tagline, and formalizing how to write the name. It's officially RecLaboratory. Note the capital 'R' and 'L'. It took us a surprising amount of discussion to decide on this convention.

We also cleaned up our Facebook, Twitter, and Instagram accounts, so those are ready to be used.

Feel free to follow us at any of those places as we'll be starting to use them soon.

Eileen and I have been talking about doing more recording together (as Packets and Waves) and after a recent Hurray For the Riff Raff show, we were in the mood to do some old country songs. We settled on doing a cover of Loretta Lynn's Wine Women and Song. It's a short, simple song (which was important because we started learning it at about 11:30pm on Saturday night) and I just like the phrase "wine, women, and song".

We didn't want to it be an exact copy of the original so I tried to give it a dirty Black Keys-ish guitar sound and keep the guitar part pretty simple. I resisted to urge to layer on a bunch of random instruments and only used guitar, bass, and drums for most of the song. The piano was only added in the chorus and solo sections, even though I tried a few takes where I recorded some sporadic piano comping throughout the whole. In the end, the stripped down version just sounded cooler.

I'm really coming around the the virtual drummer in Logic Pro. At first I really resisted the idea of letting the software "write" my drum parts for me, but the sound is so much better than MIDI drums and I can actually get some interesting parts. For this song I used "Logan" with a retro sounding kit. I thought the tom driven verses worked out really well.

Eileen's vocals turned out nicely, as usual. I was tempted to dirty up the vocal recording with a tube mic simulator, but I ended up just using a simple "out of the box" compressor effect, which sounded fine.

This ended up being a really fun little project. It only took a few hours from idea to finished product and the result was really satisfying. Enjoy our cover of Wine Women and Song!

While not the most productive RecLab week, I did finish the basic comment functionality for Users, Songs, and Tracks. I also learned about seed.rb and wrote some seed code for the Instruments data. The trick there was that I wanted to be able to run rake db:seed multiple times, so I needed seed code that would let me update or create records. I ended up with a nice solution that lets me break the instruments down into separate arrays by family and then loop through everything to create or update:

instruments = [[strings, "strings"], [woodwinds, "woodwinds"], [brass, "brass"], [percussion, "percussion"], [keys, "keys"], [other, "other"]]

instruments.each do |f|
  f[0].each do |i|
    instr = Instrument.where(name: i).first_or_initialize
    instr.family = f[1]
    instr.save!
  end
end

Now I'll need to use a tagging system to attach both Instruments and general Tags to objects. I'm leaning toward As Taggable On, which apparently was written by an old childhood friend of mine. Awesome!

The art class is going well. Value and shading are still pretty tough for me because I've spent the last few years just doing line drawings for comics. I also have a tendency to draw pretty lightly (which is probably also a result of erasing pencil lines for comics). I don't think I'll leave this class a brilliant artist, but but I'm certainly learning things and getting better.

I spent a bunch of time this week prepping for and going on interviews and on Thursday I accepted a position as a Senior Full-Stack Engineer at Couchsurfing. Today was my first day and so far it's an awesome gig. The office is amazing, it's full of dogs, and I get lunch and dinner provided everyday by the staff chefs. The work seems like it will be a lot of fun too. I'm doing Rails development and it seems like I'll be able to have a lot of say in how the product gets architected.

While it wasn't the most productive Thing a Week week, getting a new job certainly qualifies this as a pretty productive life week.

Our big breakthrough this week was being able to actually collaborate on a song using RecLab. Bobby and I were able to record tracks on our individual computers, create new tracks in RecLab, and combine them together into a song. The process was pretty clunky and the interface is still very sparse but it felt like a big step to use the product for its intended purpose.

There is still lot of work to be done before we can even start letting other people try the product but hitting these little milestones feels good.

This week I started something new. I'm taking a Drawing 101 class at Root Division art studio in the Mission. I've been drawing comics for a few years now, it seems like I should start learning how to draw.

The class seems like it's going to cover the basics and have us work mainly with graphite and charcoal. I think it will be really good for me to take a step back and really learn some of these fundamentals. I haven't had any formal art training since Jr. High, so I'm about due. I really feel like my comic art has started to hit a wall and I'm having a hard time getting some ideas down on to paper.

The drawing above is the first thing our instructor had us do: first draw an apple from memory, then he put an apple on the table for us to draw. Apples are kind of hard to draw.

Hopefully I'll have some more impressive work from this class to post in the future.

bonus thing!

Eileen got me a copy of Logic Pro X for my birthday and so the first thing I did with it was play with all the amp models and pile a bunch of guitar parts on top of each other. The resulting 30 second piece ended up sounding like some kind of epic video game music:

The Rocktopus work has been going well. It's nice to get back into writing some Python again and I've been enjoying working with Flask. One of my favorite recent additions is the require_auth decorator. Python decorators are pretty awesome and make it really simple to roll some common functionality into several methods.

This allows me to write Flask endpoints like this:

@app.route('/path_name', methods=['POST'])
@require_auth
def path_method():
  # do a bunch of stuff for this endpoint
  # but make sure the POST body contains the proper authentication

The decorator itself is pretty simple and works something like this:

def require_auth(f):
    @wraps(f)
    def wrapped(*args, **kwargs):
        data = request.get_json(force=True)
        if not validate_auth(data):
            return response_arm.auth_fail() # return 401

        return f(*args, **kwargs)
    return wrapped

Rocktopus is really coming along nicely and I'm really close to getting it hooked up to the Rails site soon.

This week I start my drawing classes. I haven't had any formal art training since grade school and it seemed time to learn a bit more about drawing, given my interest in comics, so I signed up for a Drawing 101 course at a local art studio. Hopefully I'll have some cool work from the class over the next few weeks to show off in these posts.

The Instagram API works differently than Twitter's. In order to get real-time information you have to register a callback endpoint with Instagram. This endpoint has to respont to a GET call with a validation code sent by Instgram and then respond to POST with whatever you want. Instagram only notifies you of an event (such as a photo being posted with a certain #hashtag), they don't actually provide the media info, so you have to find that yourself, which is a bit annoying and kind of clunky.

Here is the Sinatra code you might used to create the GET and POST endpoints to register and use the Instagram API:

get '/instagram_stuff' do
  params['hub.challenge'] # for when you register your callback endpoint
end

post '/instagram_stuff' do
  # do stuff when Instagram tells you something 
  #    new has been posted
end

I was able to use a lot of the code I wrote for BirdWatcher (the Twitter listener) to store this info, so that was nice. I still need to write a front end to display all of these photos but that will be done some other week. It would be nice to bundle all of this together and create some sort of product for people where they provide a hashtag or keyword and I provide a nice display of photos from various services with those keywords. Maybe someday, when I have time to clean up this code a bit.

Of course I spent time this week working on RecLab, too. I got some S3 stuff set up and built out a few site forms. We were able to get a rough prototype of the basic track uploading and song creation functionality, which was fun to see. I also spent a bit of time working on our audio processing API. It's starting to come together and it's been very interesting designing something like this from the ground up.

To help us learn more about the types of people who might use RecLab I've put together a quick 10 question survey. If you are a musician, please take a minute and fill this out, it would be a big help! RecLab Musician Survey

The site is pretty straight forward Rails, so far. Nothing too out of the ordinary there. I'm starting to get deeper into the music objects and business logic of the site, which is fun. I've also been working a bit with Flask as a wrapper around some of the audio processing stuff. After Week 7 I had been looking for a good Flask project and now I've found one! I've found some great resources on building good APIs in Flask, such as this one which have been really helpful for designing non-trivial stuff. I have a bit of experience building APIs with a micro web framework from building the Unofficial Fitocracy Runs API in Sinatra, but this will be a bit more complex than that.

Hopefully we'll have something that I can actually show off soon. We'll certainly need early testers. I do still hope to have work on a few small projects that I can show off from week to week.

This week we did a lot of planning and architecture for the project and I started building the Rails application for the site. This is my first non-trivial Rails 4 project and it's been interesting to see some of the little differences. The biggest one I've come across so far is the removal of attr_accessible and moving that functionality into the controller. I need to learn a bit more about how that totally works but so far I've been able to use a lot of what I learned building Rails 3.2 stuff.

I've been really impressed with the Rails 4 gem compatibility, as well. Major stuff I like to use such as Devise, Active Admin, and Paperclip are all working just fine. Python could learn a lot here!

This week I was able to get the basic site together, make it look nice enough to work in for a while, build basic user/user profile and login functionality, and start building out some of the core business logic for working with recorded tracks. I also started putting together some survey questions so, musician friends, expect to be bugged to be asked questions soon. It might be a little while before we have an actual site for people to try but I'm always interested in talking with people about the idea.

Now I need to balance working on this with doing a couple other single-week projects, especially the stuff that is needed for the wedding.

That said I did git a bit of work done in a few areas.

I started the Instagram work and learned a bit more about how their streaming API works. It looks like I'll need to build a callback endpoint to take in post info and store things in a database and then Instagram will handle most of the hard work. I'll probably just end up building the callback endpoint as part of the exiting daveandeileen.com Sinatra application.

I also spent some time doing a bit of research on audio processing libraries for another project I'm planning. As of now I'm leaning towards PyDub. Hopefully I'll have some work from that project to post soon.

Finally, I'm planning to build a ring box for our wedding out of an old book (kind of like this, but with wedding rings). I was able to find a book I like at a used bookstore this weekend, so I consider that a small win.

This wasn't a great Thing a Week week, but at least I got a few productive things done.

I was pretty faithful to the original, mainly just taking some liberties with instrumentation in a few parts. I really like the dirty guitar and bass in song so I found some amp models that kept with that style. I did swap out the harmonica riff for a thin, high piano part over a crunchy bass. I really liked the hollow sound it created and it felt in line with my tendency to add keys to things. In that same vein, I used some synth in a few parts as well, replacing the little guitar riff in the verse and working with the guitar in the solo.

I actually had a lot of fun with the solo, again staying pretty true to the original but taking some liberties here and there. The synth was a fun addition and really beefed things up. I ended up falling back on some blues riffing during the end of the solo because I'm just not as metal as Rivers.

Again I used Garageband's Drummer feature for the drums. I spent a bit of time dialing them in and I was pleased with how they turned out. While laying out the song I did discover that Garageband doesn't let you change time signatures in the middle of a song. There is a single measure of 2/4 time in the verse so I had to just offset thing. I was worried that the automated drumming would sound weird around this change, but it ended up being fine.

The vocals... This is always tough for me. The verses turned out ok. They're pretty straight forward and in my range but the chorus was tough. Some of the high notes were a big of a strain for me and in general the choruses felt a bit lack luster. I just don't know how to get more character out of my voice. The last chorus with the high harmonies was especially difficult. I was really straining my voice there. As always, doing stuff like this is great practice and helps me improve so I just need to keep that perspective.

I wasn't especially pleased with the mixing and production on this song. I felt a bit rushed because I started working on this a little later in the week. I had recorded some of the guitar parts in a chopped up way and I can hear some lack of fluidity. None of the parts were difficult enough to get right to justify this type of recording but I was just in a rush to get something down. In general I think things just feel a bit choppy, but I suppose that's the price of doing things on a time crunch.

All in all, it was a fun project and it's alway nice to spend time recording. Enjoy:

bonus thing!

I also posted a comic to Mount Saint Awesome this week (the first in quite a while). It didn't feel like a big enough art project to be a full Thing a Week thing, but it's still worth checking out.

I ended up spending a lot of time just getting my Python development environment set up. Apparently it's been so long since I've done anything non-trivial in the language that I didn't even have basic tools set up well on this computer. I wanted to do things right and that took a bit of installing and uninstalling through various channels to get things just so. This meant Python installed threw Homebrew and then using that version of pip to install virtualenv. This way I didn't have to use sudo to install virtualenv. While this ended up being more frustrating than it should have been (and at one point led to me asking a Stack Overflow question that I later answered for myself) I did get things set up nicely, which is a major win.

Once I got down to setting up Flask thing were pretty smooth. For the basic stuff I was doing it felt very similar to Sinatra, which I've worked with quite a bit. I finally got to use Python's method decorators in practice which was neat (they drive the routing around the functions related to the routes).

The end result was a pretty basic first test site. Nothing really worth putting up anywhere. I'd like to keep playing with Flask and get a bit more reacquainted with Python so unless I have another burning project come up, I might just stick with it this week too.

This tends to happen to me a lot. My Garageband folder is full of 30 second long riffs and fleshed out song chunks, but I often hit a wall and I'm not sure where to go from there. Last week I sat down and tried writing some stuff influenced by a couple songs that either did piano and bass or just bass licks well. The main ones I referred to were Erase Me by Ben Folds Five and Sic Transit Gloria...Glory Fades by Brand New. They are both awesome songs and I especially love the way the piano and bass work together in the Ben Folds song but my ideas just weren't working. I ended up with some weird meandering minor bass parts thrown over some really weak piano parts.

I came back the next day and switched to a major key and started with the piano part first. From there I came up with something that I liked and wrote a simple bass part that just harmonized the piano roots in a few parts.

And that's where I got stuck. I spent a bit of time playing around with some sparse guitar parts and a few of the new amp models in the new version of Garageband. I also played around with the new Drummer feature of Garageband. It was pretty cool and maybe the most redeeming quality of Garageband X (the removal of the old keyboard shortcuts and export to mp3 are driving me nuts and might send my back to version 6!). The drum sounds are great and it's a big step up from the midi drum parts I had been working with in the old version of Garageband, but I did feel a bit uncomfortable with the loss of control over every single hit. I suppose it's a decent compromise.

So here's what I came up with. I ended up just doing some random guitar riffing and bigger chords at some point, but it really just felt forced and didn't take the song anywhere. Take a listen, though, because the piano/bass part turned out pretty nice:

I'd like to keep working with this song. It's different than most of the stuff I've written lately. I think that throwing lyrics over it will be a bit of a challenge just because I don't quite trust my voice for something this mellow, but it's a fun part and I think it could turn into something cool.

This week I'm leaning towards either a project with Python (I've been meaning to brush up on my Python for a while) or something artistic. I'm still not quite sure.

I ended up changing the format of the project a bit. Instead of a full Sinatra application I put everything into a single Ruby file that I can just leave running whenever I want to fire up the listener. I didn't need this project to serve any content, only run Tweet Stream and write to a database, so Sinatra was probably overkill to begin with.

I had some trouble with Sequel, the Gem I was using to interface with the Postgres database but eventually got things worked out. The weirdest issue was with trying to store the url of the photo. For some reason this didn't work:

def store_image(tweet_photo_url, tweet_user, tweet_text)
  ...
  @db[:photos].insert( :photo_url => tweet_photo_url, :service => "twitter", :username => screen_name, :name => name, :photo_text => tweet_text)
end

but this did:

def store_image(tweet_photo_url, tweet_user, tweet_text)
  ...
  the_url = "#{tweet_photo_url}"

  @db[:photos].insert( :photo_url => the_url, :service => "twitter", :username => screen_name, :name => name, :photo_text => tweet_text)
end

It must have something to do with the way Ruby handles certain strings or how Sequel or Postgres handle certain strings in INSERTs.

You can see the final file I'm using bird_watcher.rb in the Github repo for the project.

Next I'll need to write an Instragram listener. Hopefully that will be pretty quick as most of the mechanics will be identical to this listener. I might hold off on working on that for a bit, though. I'm thinking about tackling a musical project next week.

I was interested in how hard it would be to add RSS to this weird Jekyll/Sinatra hybrid I have running and had a few minutes tonight so I decided to give it a shot. It turned out to not be bad. I just followed this quick tutoral and found a nice template here and 90% of the work was done (basically I just add another template to my Jekyll project and a few lines in my config and an xml file gets generated along with everything else when I run jekyll build.

The only custom part was adding a few lines to my Jekyll handler method in my main Sinatra app to suppress the layout template and render the RSS file as XML:

if file_path.include? "rss.xml"
  content_type 'text/xml'
  erb contents, :layout => false
else 
  erb contents
end

Now you can subscribe to this blog via RSS is you so desire!

Once again I tackled a project for the wedding. I want to build a system that listens to Twitter and Instagram for photos that are tagged #daveandeileen then pulls them in and displays them somewhere at the wedding. This week I decided to finish up the Twitter listener.

This listener is basically just a small Sinatra app that uses TweetStream to listen for tagged tweets and then if it matches the criteria (has image and is properly tagged) it stores info about the tweet into a database. This same database will eventually hold Instagram (this was the whole reason I signed up for Instragram) data and then I'll need to write a nice front end that pulls the photo data out and displays the pictures in some nice way.

I call this week a partial failure because I got the app working locally, but ran into some trouble getting it deployed properly. I am not a great sys admin, but I'm learning a few things. This is also the first time I've set up a database on my VPS. I've really been spoiled by always working with databases through a nice visual interface so doing some Postgres work while sshed into my server felt like pulling teeth. I was just running into some issues pretty late on Sunday night so I ended up admitting defeat and went to bed. You can check out the code for this project on Github.

This next week (the week we are currently experiencing right now) is pretty busy. We're trying to finish up a bunch of other big wedding things (stuff that doesn't involve coding) and my parents are in town this weekend, so I know I'm going to be limited for "thing a week" time. I would like to use this week to finish off the deployment for Bird Watcher. I feel bad about letting a project spread over two weeks but I think it's best for my schedule and this project.

This Thing A Week was pretty straight forward: write and draw a comic. This is something I've done many times before. The main challenge was getting it good enough to print on cards and mail to friends and family. It just feels like because this is for the wedding, I should set the bar heigher than I would for a web comic. I'm always worried about my art not being good enough, so this comic was a bit stressful at times.

The layout wasn't too complicated but some of the poses and body positions were just a little odd for me and it took a bit to get them right. Like most comics I spent some time planning out the pannels and doing some quick sketches of a few poses before starting on the actual comic. I also decided to work at a larger scale, using 8.5 x 14 paper. This is always nice because I feel like I can work on details a lot better at this size.

I suppose there's not much more to say about this project. I'm a bit torn on what to work on next week, it's currently between writing a song that uses my new bass pedal, working on a programming project for the wedding, or starting to work on a new idea for Big CoreUs.

This week I built a bass overdrive pedal. I had received a kit for this pedal for Xmas (as well as an arm for holding circuit boards while soldering, which may be the nerdiest gift I've ever received) and I was excited to finally have time to work on it. Last year I built a Tube Screamer overdrive clone from a kit, so I've had a little experience building pedals from kits already.

The choice of a bass overdrive pedal was motivated a bit by listening to some newer Ben Folds. He has some great songs on his new record that are really carried by piano and gruff sounding bass. Now that I have this new pedal, one of my upcoming Thing A Week things will hopefully be a song written in that style.

This build was a bit more complicated than the last pedal I built, but I didn't have any major problems with it. It took a while to solder all the little components onto the board but I actually found it to be very relaxing. It takes a lot of focus but it isn't really mentally taxing. Soldering was a nice way to unwind after work this week. The biggest addition I made to this build was the choice to paint the enclosure. I had never painted metal before so I had to learn a bit about that (it's not that complicated). It really just involved sanding the enclosure, priming it, then adding a few layers of indoor/outdoor spray paint. I picked a nice ugly yellow, which ended up looking really cool with the black nobs. I had originally planned to label the nobs and draw some sort of design, but I just didn't find anything I like so I kept it totally clean, which ended up being a nice look.

The tone of the pedal itself it pretty cool. It has treble and bass levels as well as a blend control which lets you blend the drive and clean tones nicely. I did a quick recording so you can hear what it sounds like. I started with a clean bass sound for comparison then turned on the overdrive.

It felt good to finish a Thing A Week project, I was a little worried about the viability of this project after falling short the first week. Next week I will probably try to do something artistic, maybe comic related.

My goal was to build my first HTML5/JavaScript based game. I started out by picking a JS game framework suggested by my buddy Bryan. I ended up using Crafty and getting started with this tutorial. It was really good and by the end I had a top down adventure game thing that looked very Zelda-like.

From there I sat down and did a bit of planning to figure out what sort of game I wanted to make. This is where I may have gotten a bit ambitious. I decided to make a top down adventure game (similar to the one in the tutorial) about a T-rex/scientist who must fight off mammals and time travelers to gather parts to build a spaceship and blow up the asteroid that will cause the mass extinction of all dinosaurs. I planned out 4 stages, each with new mobs and planned to hand draw all the sprite fames.

Perhaps I was in a bit over my head, having never built a game before.

In the end, I was able to create a rather buggy game where you can move around a dark green square in a forest (made of light green squares) and go after gray squares (the parts!) while avoiding some brown squares (probably a rodent of some kind?). I wouldn't really call it a game, but I suppose I know a lot more about game building with JavaScript than I did last week. I did really like the idea for the game, especially the name "Professor Rex VonScience" and I got to draw several dinosaurs wearing a lab coat and a bow tie, so it wasn't a total loss.

If you'd like to "play" the "game" you can take a look here: Professor Rex VonScience Saves The World and the code is available on my Github.

So, now that I've already had an unsuccessful Thing A Week week, I need to figure out how to deal with failure in the project. I'd like to keep working on this game but I'd also like to avoid sticking with the same project several weeks in a row, particularly this early. Perhaps in an upcoming week I'll pick a subset of this game as my project and work from there now that I have a better idea about the kind of work it takes to make a game. I'm also not sure if I'm ready to set next week's project yet. I'm leaning towards building a bass distortion pedal, though.

A lot of what I want to be doing is making things and in order to stay focused on that I'm going to steal an idea from the brilliant Jonathan Coulton (of Code Monkey fame!) and try to do A Thing A Week. While Jonathan did this entirely with songs I'm going to branch out to include almost anything that I can create within the 1 week time frame. This might involve building a guitar pedal or brewing a beer or making some art or creating a small web app or piece of software or even... writing and recording a song. I have a bit of experience with this schedule from the early days of Mount Saint Awesome. Back when I first started the comic I was VERY dedicated to posting a comic every Monday and I stuck with that schedule for over a year. It really helped me improve as a cartoonist. Here is the first comic I posted and here is one of the later plot based comic I posted (this was less than 1 year of comics, but still a noticeable difference.)

The first thing I'm going to try is building an HTML5/JavaScript game. I've been doing web development for a long time now but I've never built a game and it seems like a good excuse to play with some new HTML5 stuff, plus I'd really like to get more serious about JavaScript. If all goes to plan I will have a game to show off here next Monday!

But this post isn't really about me learning chess. It's more about a game I played a few weeks ago.

I had convinced Eileen to go play chess in a coffee shop with me one Sunday evening. We were just going to play a very friendly, open game because she doesn't really play and last time we played she got really mad that I beat her (and refused to play chess with me ever again). We were sitting at a table next to a family with two young children, maybe 4 and 6 years old and as we started our game, the older child kept craning his head over to our table. Eventually his willpower failed him and he just came straight over and sat next to Eileen, asked what she was doing, and started suggesting moves.

His parents came over to apologize (and retrieve their stray child) and the father explained that he had started to introduce his son to chess a little while ago. Eileen and I were just having a friendly game so we ended up inviting the kid to play "on Eileen's team" and his parents helped them pick moves too. It was a completely casual game with everybody helping to look for the best moves for both sides and none of us (adults included) were particularly strong players.

The kid couldn't sit still for 30 seconds and spent the whole game wiggling around and leaning on Eileen and looking at the board from different angles but the game kept his attention, which was really impressive. It wasn't the game I had planned on playing but I think we all had a lot of fun. It felt good to help entertain a kid with something productive and it was just a genuinely enjoyable encounter with some random, nice strangers in a coffee shop.

With this song I wanted to just write something straightforward and not get hung up on trying to write anything super technical. I ended up with a simple intro - verse - chorus - verse -chorus - bridge - chorus structure and I tried my best to not overthink the lyrics (more on those later). By not getting bogged down worrying if my basics were interesting enough I was able to get a solid chord progression and structure down and then build off of it.

recording

The song started with just guitar recorded over a click track. Rather than trying to set up and mic an amp I ran my guitar through my homemade overdrive pedal and then a clean amp model in Garageband. Once I had my basic structure down I went in to write drum parts. I wrote the drum part by hand placing events on the piano roll set to a drumset sound. I'm sure there are better ways to do this, but it worked for this song and I like the freedom I get by beind able to hand pick every hit in a beat.

I stressed out about my bass tone a bit during this recording session. Usually I need to run my bass through an amp and mic it to get anything remotely usable, but I wanted to get some parts down imediately and plugging in wasn't an option at 11pm. I plugged directly into my recording interface (an M-Audio Fast Track Pro) and then just put one of the fuzzy Garageband bass effects on the tracks and the sound was actually ok so I ended up keeping it.

From there it was time to play with keyboards! The paino parts are all pretty simple, mainly just to add some depth and tone to the song. I had a lot of fun writing some cool little counter-melodies on the synth. I've always had a soft spot for bands like Zolf the Rock and Roll Destoyer and Motion City Soundtrack so I really enjoyed being able to write some really poppy synth driven stuff.

lyrics

And now lyrics. Like I said, this song was an exercise in not overthinking things. I just sort of wrote the first things that came to mind so this song ended up overtly being a generic pop sound with vauge romantic sentements. That said, the ideas for the lyrics came from watching Doctor Horrible's Sing-a-long Blog and from spending a weekend home alone when Eileen was out of town.

chorus

Well I can't get you out of my head
I dream about you when I go to bed
I can't get you off of my mind
And I don't mind
I can't get you out of my head
I keep replaying every word you said
I'd like to give you some of my time
If you don't mind

The deep insight here is that I had a bunch of songs from Doctor Horrible stuck in my head for a long time. They're really good! You should seriously watch it. That's honestly the extent of the depth of that chorus, I just kind of took the theme of having something stuck in your head and presented it in a general enough way to make for a good, hopefully catchy, pop chorus.

verse 1

Well I've been spending too much time
Home alone on my couch drinking too much wine
Watching TV and waiting for
You to come here and walk right through my door

verse 2

Now I don't eat and I barely sleep
I don't know how much longer I can keep
Walking through these empty rooms
Before I pick up my phone and call you

I wrote a lot of the music for this song over a weekend when Eileen was out of town so when I was looking for lyrical ideas for the verse I decided to just use the theme of being home alone and again present it in a vague way to make it sound like semi-romantic pop. I did take some liberties with the concepts. For example, there was no wine consumed that weekend but it's harder to find good words that rhyme with whiskey. I did watch copious amounts of TV, mostly The Guild, and I don't really do a good job of feeding myself or going to bed at a reasonable time when I am left home alone, so there is some truth to these words. I wasn't as happy with the vocals I got when recording the verses. I just couldn't seem to get a tone I was totally happy with, but I don't think it's too distracting.

the song

I'm really proud of how this song turned out. I had a lot of fun with the style and its always rewarding to hear a completed project that has some complextiy to it. If you don't want to travel all the way over to Soundcloud to hear the song, you can listen to it RIGHT HERE!

So, what is Darwinning?

Darwinning is a Ruby Gem built to help people write genetic algorithms. I got into genetic algorithms while taking a machine learning course during my masters and I've had a casual interest in them ever since. I even wrote a comic about them! I have also been enjoying Ruby lately, so I wanted to learn how to build a Gem. This project was started to satisfy both of those interests.

I also played with the Ruby unit testing framework, RSpec, for the first time with this project. The test coverage for Darwinning isn't great, but at least it's a start.

So, how do I use Darwinning?

Darwinning is totally available via RubyGems so you can install it the same way you would install almost any Gem:

gem install darwinning

Once it's installed you can make use of the Population, Organism, and Gene classes to build your own genetic algorithm based programs.

Here's an dumb example of how you might use Darwinning to solve a pointless problem:

Let's say for some reason you need a set of 3 number that add up to 15. This is a strange problem to have, but let's solve it anyway.

class Triple < Darwinning::Organism

  @name = "Triple"
  @genes = [
      Darwinning::Gene.new("first digit", (0..9)),
      Darwinning::Gene.new("second digit", (0..9)),
      Darwinning::Gene.new("third digit", (0..9))
    ]

  def fitness
    # Try to get the sum of the 3 digits to add up to 15
    (genotypes.inject{ |sum, x| sum + x } - 15).abs
  end
end 

p = Darwinning::Population.new(Triple, 10, 0, 0.1, 100)
p.evolve!

p.best_member.nice_print # prints the member representing the solution

This code declares an organism class that inherits from Darwinning's Organism parent class to represent solutions. Then we create a population of these solution organisms and evolve the population until a solution meets the fitness threshold or the generation limit is met.

So, what else can I do with it?

If any of this sounds remotely interesting to you, please check out the project on Github. I'm always happy to take good pull requests if other people want to contribute. I haven't been very active lately because I've been spending a lot of time on this website and my wedding website, but I do keep an eye on the project.

This new site is built mainly on Sinatra with Jekyll mixed in for some blogging functionality. I didn't really need any sort of content management system for most of the site so there is no database behind it and I'm using flat files (mostly just handwritten JSON) for anything that seems dynamic.

The interesting part was adding a Jekyll blog to an existing Sinatra site. Jekyll is super easy to set up on its own but I didn't want it to run the whole site. I wanted to be able to serve dynamic pages if I wanted. With some help from this blog post it was actually pretty easy to get things up and running. That post is a bit out of date but still very helpful.

To add Jekyll to Sinatra I first just created a new Jekyll site in a seperate directory and copied it over into a jekyll_blog/ folder in the root of my Sinatra project. I then removed the .gitignore, the default.html layout and the whole css/ directory (after moving the Pygments syntax.css into my main stylesheet directory) from the new Jekyll directory. I also adjusted the _post.html layout to not have a layout of its own by just removing all the YAML Front-matter from the file. This is because I want Sinatra to handle the layouts for everything.

The real meat of this is a custom function in the /blog route:

get '/blog/?*' do
    jekyll_blog(request.path)
end

def jekyll_blog(path)
  @page_title = "blog"

  file_path = File.join(File.dirname(__FILE__), 'jekyll_blog/_site',  path.gsub('/blog',''))
  file_path = File.join(file_path, 'index.html') unless file_path =~ /\.[a-z]+$/i 

  if File.exist?(file_path)
    file = File.open(file_path, "rb")
    contents = file.read
    file.close

    erb contents
  end
end

This just calls the jekyll_blog(path) function whenever you go to a page that starts with /blog/ and that just pulls the html content of either the post or the Jekyll index.html and puts into the <%= yield %> in my Sinatra erb layout.

This is a pretty simplistic solution and I want to add better 404 checking and a way to pull the post title out for use in the page title, but it gets the job done by pulling out the content of the post html file generated by Jekyll and putting it into the content container of Sinatra. Now all my layouts are handled by the same file and all my CSS comes from the same source.

While I like the idea of being able to write my blog posts in Markdown and from whatever editor I want I also wanted to have some sort of web based editor for my posts so I'm trying Prose. Prose is basically a web based editor for Github files (which is where all the content for this site resides anyways. It lets me go in and create new posts through a pretty nice looking Markdown editor with preview. It also helps with syntax and media uploading (though I haven't tried that yet). I've included a _prose.rb config file that sends me right to the _posts/ directory of this project when I'm working on it:

prose:
  rooturl: 'jekyll_blog/_posts'
  media: 'public/images/blog_media'

I think that the transiton from a really polished, very user friendly system like Word Press to something more technical like Jekyll will be interesting. I feel like I still need to work some kinks out of the system and I'm still not totally won over by Prose but it has been really fun to set this up. I'd also like to add comments through Disqus soon. Hopefully now I'll make this work worthwhile and actually write a few blog posts every now and then.