This is a piece I did as a gift for my family that lives in western Michigan. There are countless beautiful beaches on the Michigan west coast, but Holland State Park has always been special for my family. I practically grew up on this beach, watching the sailboats go by. Besides the subject, I like this piece for the many different textures I was able to capture.
Lately, my writing efforts have been entirely focused on my master’s degree in Human-Computer Interaction, so I thought I could at least post some of that work here for the time being.
I recently wrote a research paper about web usability in developing nations. I love discussions around web performance, so I was particularly interested in this topic. In the context of the class, I wasn’t able to dive as deep into the technical aspects as I would have liked, but I’m pretty happy with out it turned out overall. Here is a quick intro to the paper:
The internet is widely available and reliable for those of us in developed countries like the United States and most of the European Union. We have fast, highly accessible networks, ever more powerful technology to access these networks, and relatively good education systems to help us use them. But people in less developed areas of the world can have a significantly different, and often more challenging experience accessing the web. What are the problems people in these developing countries face in regards to web accessibility and usability? How can a better interaction with the web help improve the lives of these people? As designers, developers, and analysts, what can we do to improve this interaction, and why do we even care in the first place?
I’ve had some time to reflect on my work from the past few months, so I’d like to write about a couple of projects and some insights I’ve gained from them.
One of the organizations I work for is going through a major overhaul on its eCommerce platform. We are moving inventory to a new warehouse, changing shipping policies, adding new products, and working towards simplifying our customers’ experience. My role so far has been to rework our SQL databases to conform to our new data structures, rewrite the back-end (PHP) logic associated with those tables, and rework our store website’s custom admin panel. It’s been a lot of work, but I’ve really enjoyed the chance to stretch out my SQL knowledge.
I also started a just-for-fun personal project of developing a web-based computer game. The idea for the game is in the same vein as old text-based adventure games like Zork or Colossal Cave Adventure. I’m working to include multiplayer capabilities as well, similar to games like MUD1. My reason for starting this project is to familiarize myself with a more Javascript-centric stack. I’m exclusively using JSON data structures to store and pass data between the web app and the server, no databases included. The current prototype does have a PHP back-end, but my goal is to transition to Node. It’s been a fun and very unique project so far.
Data structures seem to be a common thread between my work projects lately. My work involves different ways of organizing data, like JSON, SQL, and associative arrays, and how to communicate that data around different programming frameworks. It’s always satisfying when all the different parts of a system fit together nicely and churn out exactly what you expect.
My dad, brother and I spent a couple days backpacking through the Shawnee Forest on the River-to-River trail a few years ago. It was a very hot summer, so a lot of the small creeks normally running through the park had completely dried up. We came across one such creek bed around mid day, and stopped for a meal break. I recently did this sketch of the area in graphite.
If there’s two things every developer loves talking about, it’s tooling and build processes. I’ll start by talking about the build process I’m currently using for my web projects.
Every website and application I develop is versioned in Git, and hosted on either BitBucket or GitHub (though not always on my own personal account). I take advantage of the processing hooks that come with Git as the hub of my build process. I start by setting up a bare headless Git repo on the development server, and adding that repo as a remote on the project’s repo. That way I can quickly, easily, and safely push code up to the server. Then I set up Git’s built-in post-receive hook, where all the magic happens.
In the post-receive hook, I run a shell script to set the work tree of the development server (wherever the live directory is). Then the script does a `git checkout` to pull the actual project files into the live directory. So in short, I can use a single Git command to push code to a secure headless repo on the development server, which then runs a script to pass the project files into the live directory. This is a fairly standard setup, but usually there’s a lot more work to do with compiling and compressing. Work that can be automated on the server.
If I have my way on a project, I’m always using Sass and jQuery for styling and scripting. Those two file types both need to be compiled and minified to run and deliver quickly on the web. I use the same post-receive hook to run a `sass` command that compiles and minifies my .scss files into pure .css all in one go. Easy enough, but the javascript takes a bit more effort. For that, I use the Node module Gulp. Gulp is simply a javascript file that is meant to run on the server, similar to a shell script, rather than in a client. It’s used to do tons of really amazing work, but for my purposes it’s great for simply minifying javascript and other assets.
With Gulp, I start by writing the gulpfile.js that will hold the minifying script. I use the Gulp Uglify plugin to do this as simply as possible. Part of the reason I use Gulp is because it can handle image compression as well as javascript, so I also use the ImageMin plugin. Once the script is in place for the Uglify and ImageMin processes, I push the Gulp file up to the development server. On the server, I install Node, npm, Gulp, and the two plugins, so that I can start actually running the Gulp file. Then I can simply add the `gulp` command to that same post-receive hook, and everything will be up and running smoothly.
The advantage of this build process is that I don’t have to do any manual compiling or minifying, and more importantly, I don’t have to version or push around any compiled or minified files. It keeps my local project repos and my GitHub repos nice and clean. I do usually version the Gulp file, but I think it’s a small price to pay. It takes some initial setup time, but over the course of a project, the overall time saved is well worth it.