Using Go

I chose to learn Go during my Programming Languages course in college, when we were told to find a new language to learn. I was tired of the chaos of JavaScript and PHP, and I was drawn to the idea of non-OO, statically typed code without manual memory management. While I haven’t built anything professional-grade with Go yet, I have used it to begin building two sites (one of which works! ;), and I love it.

Even though I don’t have a lot of experience with Go, I feel confident in my ability to use the language well. And even though I haven’t finished these side projects, I do finish the work I get paid for.

What I’ve Done

  • Meal Picker (not working)
    This is a tiny project I started to help my wife and I choose what to eat. It was some of the first Go code I wrote, and I tried to do it without depending on a database, so it stores data in CSV files. When I pick it up again, I think I want to use Bolt instead.
  • SAVvie (working, but not finished)
    This was a group project that I made with fellow students. We each wanted to use a different language, so it’s not an example of how I’d structure a production service! But I did do a (to my mind) substantial amount of work in Go, and the site’s basic functionality is usable.

What I Still Want to Do

  • Work on a large Go codebase
    Go is so easy to read and work with. I’m looking forward to the day when I can really use this language in a big project.
  • Port Space Trader to Go
    Back in the day, I used to absolutely love playing the game Space Trader on my Palm Pilot. I want to bring it back with modern ports for some combination of desktop, web, and mobile, and I think I want to do it in Go.


Contacting Me

  2. GitHub
  3. LinkedIn

For more information (or a resume), email me! If you want me to work on a project, it might have to wait until I graduate in a few months, but shoot me an email and let’s see what happens.

On CSS Polyfills

I want to respond to “The Dark Side of Polyfilling CSS” by Philip Walton. At the end of the article is this hashtag:


I disagree completely. Putting aside the fact that the word “fatigue” has only negative connotations, CSS is already different enough between browsers. If a CSS snippet’s meaning can be changed at will by JavaScript, then:

  • There will be more code in the rendering pipeline, and therefore more bugs
  • Scripts can change the meaning of valid CSS, interfering with the CSS author’s expectations and intentions
  • Browser vendors can justify ignoring niche new features because the JS community will already have an implementation
  • More JS has to be included in the page (yes, less than a polyfill, but a nonzero amount nonetheless)
  • Instead of being processed by compiled and (hopefully) well-tested code, CSS will have to rely on JS – let that sink in.

Where does it end?? I strongly believe in the separation of concerns, and in using the right tool for the job. At what point does an application just ignore HTML/CSS and run entirely in JavaScript? (Yes, I’m sure it’s already being done.) You might as well ship a desktop app if you’re just using the browser as an execution environment.

The difficulty of polyfilling CSS should convince developers to write simple, backwards-compatible, and extensible CSS; not to make it more complicated.

This Website!

Originally built with Jekyll and a fully custom theme, I decided to migrate the website to Hugo for better cross-platform testing support. Hugo was easy to get running, but the customization system took a couple hours to fully understand.

The theme is a slightly modified version of Hyde using the Merriweather font for the title. The Markdown parser automatically uses typographically correct quotes, and Hugo shortcodes help create a consistent visual appearance.


Prounounced like “savvy,” the name SAVvie comes from our initial prototype name, “Social Argument Voting,” and the verb “vie,” which means to compete. We imagined it to be an online implementation of Robert’s Rules of Order — a place suitable for online debate and group decision-making.

SAVvie is a team project that was jump-started during the 24-hour Southern Utah Code Camp hackathon of 2016. I took on the responsibilities of a team leader for the four student developers who created the app: Katrina Mehring, Nick Rossi, Jacob Ward, and myself. After the hackathon, I continued to work on SAVvie with Katrina.


List of all arguments on the site including their voting scores
Detail page for a single argument, including voting buttons and comments
Login page with an error message

Architecture and stack:

  • MVC pattern
  • Vagrant dev environments
  • Controller: Go’s standard net/http package
  • Views: Go’s standard html/template package
  • Models:
    • C# CLI for persisting arguments and votes to filesystem
    • Go packages for persisting users and comments to filesystem
  • No browser JavaScript yet

Advanced Content Management


To simplify the creation of complicated page layouts, I developed a new “Advanced Page” content type in our CMS. Advanced pages have automatic support for custom row-and-column layouts and pluggable, reusable, structured component blocks.

Advanced page multi-column demo screenshot

Advanced page multi-column demo screenshot


I work in the wonderful Web Services department of my university. I love my job, but our entire department has fewer than five employees supporting the entire university website: almost 3,000 pages and hundreds of faculty and staff. Most of them contact us with updates, and a few make their own changes in the CMS.

Our site uses Bootstrap’s grid system, and many of our pages require custom multi-column layouts. Unfortunately, our CMS’s WYSIWYG editor doesn’t support multi-column layouts except via hand-coded HTML. This meant that Web Services had to be involved whenever someone needed a change to these pages, and we had to be careful not to break the layout when adding or removing columns.


When summer started, I spent a few weeks learning how our CMS could be customized. I developed a new page rendering system (using Apache Velocity, if you’re curious) that had built-in support for multi-row and multi-column layouts. At the same time, I added support for reusable blocks of WYSIWYG content. These blocks are structured and their WYSYWIG interface can be customized.

Advanced page editing interface

Advanced page editing interface

Reusable accordion component's editing interface

Reusable accordion component's editing interface

SUU to Everywhere

When the marketing department asked us to build a site for their newest campaign, “SUU to Everywhere,” I implemented the CMS page types and the CSS for the site’s design.

SUU to Everywhere front page

SUU to Everywhere front page

At the time, our site didn’t really have anything like this. A coworker and I planned a way for the new code to be reusable in other areas (specifically the university news). We made structured page types for the stories so Marketing could easily create and edit the stories. We used Masonry to keep the lower section of images flexible and visually interesting, and I used flexbox to ensure the top three images would be responsive regardless of aspect ratios.

WYSIWYG interface for editing a story in the CMS

WYSIWYG interface for editing a story in the CMS

Falling Spikes

January 2016 – July 2016

Falling Spikes is an iPhone game based on an idea by Scott Chapman. The player controls a bouncing ball by moving it left and right to avoid randomly falling spikes. Scott and I wanted to develop and publish this game for iOS devices with the hopes of making semi-passive income. His field is business, and mine is programming. The game took about 90 hours to create.

The game is currently in the process of being submitted to the App Store.

Casino Game Maker GDK

Casino Game Maker, a local startup, approached me to create a new website. The company had me develop the site online, so I believe it’s public knowledge, but they never marketed the site and it is currently down. It involved large file distribution, multi-level managed user accounts, and online payments.

The site had two parts: the majority of it was built using CodeIgniter, an older PHP framework that was easy to use and nice to work with. I built several public-facing pages as well as an admin area by hand. The second part of the site was running on DokuWiki, which I customized to integrate with the user authentication system of the main site.

I’ll dig up the source code and get some screenshots sometime, especially if there is a request for more information.

It’s been quite a while since I made this website. If I were to do it again, with what I know now, I’d probably use CodeIgniter again. However, I think Django would be a more appropriate choice. I’d be much easier to build the admin area, and Django is better suited for code reuse than CodeIgniter. I just don’t have any real experience with Django yet.


Built during Southern Utah Code Camp 2014, JuxtaPros is a web app for quickly making lists of pros and cons. Jacob Ward and I came up with the idea, and we actually tried to build it for Code Camp two years in a row. The first year, we built the front end but ran out of time before we could build the back end (it didn’t help that neither of us had built a back end before).

The second year, we decided to start with the back end. Unfortunately, we also decided to try learning Node and React for the first time… We didn’t finish much that year, haha. But for only having worked on it for 48 hours, I’m proud that we’ve got a working front end.

If I were to try again without time constraints, I think this would be a good project on which to learn Angular. But if I wanted to actually finish it using tech I know, I’d use jQuery on the front and Go in the back.

Inaugural Entry

Three days ago, Apple gave its 2013 WWDC keynote presentation. They announced OS X Mavericks, the new Mac Pro, and a new design for iOS 7. I’m taking the opportunity to move my own development efforts forward, by creating Mindful Code. Under this name, I intend to create apps for iOS and Mac that truly understand how people think of and interact with their systems.

The definition of “mindful” has nothing to do with beauty, versatility, or even ease of use. To be mindful is to be aware of truth, and to respect it. Only when software is mindful of its users can it become an extension of their thinking. And then? Then it becomes beautiful.


For a long time, Goodness was my most successful project: a Chrome extension designed to help people overcome pornography addictions. I sold it in 2013 with about 11,000 users, and has since grown (unmodified, as best I can tell; you can still see my name in the screenshot) to many more than that.

Screenshot of Goodness's options page