Blog

My latest web project required adding security and user authentication to a Nuxt app. The app is served as a static generated (pre-rendered) site on Netlify, which then "unfolds" into a full-featured single-page application upon loading. From then on, each successive route is explored on the live app in the user's browser and the user is therefore no longer navigating static files. This approach provides many benefits for SEO because the content of each discrete page is already embedded in a static generated file that represents the resource, and this improves both load times and Google's understanding of our website.

I'm continuing to work on a few different Nuxt projects after creating this website, but I quickly hit a point where I was tempted to copy code that I had already created, so I paused my projects and returned to my website with the goal of compartmentalizing those useful bits for reuse. After all, this is why the JavaScript ecosystem has npm!

I'm in the final stages of turning my website into a Nuxt app, and all my hard work is finally starting to pay off. When the site was previously statically generated on my computer using Hexo, it was relatively simple (if only tedious) to also configure the pages for ideal SEO. Each page was a collection of partial templates that rendered with the page's details from the command line. From there, I created a simple JavaScript plugin for Hexo that allowed me to add the relevant metadata fields that I needed for each page, but it required defining those properties on the actual Markdown files for each blog post. Once again: tedious. Now that the website is an app, those pages are still statically generated but they're created via a web framework that's actually flattening each route of a single-page application into a static page. Nuxt is creating static HTML that transforms into a SPA upon loading. Talk about a turbo charge!

As I continue converting this website into a Nuxt app, I’m encountering design decisions that permeate deep into the style of my actual website. It’s amazing how dramatic a decision about padding, font, and color can impact the aesthetic and usability of a web interface. I’m more inclined to use an established UI framework that’s been battle-tested and brainstormed into something more polished, rather than making something homebrew for the user to see and interact with. As a result, I’ve started mastering Material Design as I assemble my website and blog with Vuetify components.

At the end of 2017, I built this blog with Hexo and then migrated the rest of my site to to use the same Markdown format. Creating the website this way came with a lot of positives, one of the biggest ones being that I controlled the entire build locally on my computer. It’s been fairly easy to make small adjustments to the build process and the resulting files, but generating a static site has also impeded my ability to make this website more dynamic and interesting. But that’s all changing, as I’m converting my website and blog into a pre-rendered Nuxt app!

When we discuss the context of the “browser wars” we often focus just on how one particular browser can get an edge on its competitors by developing or supporting a new feature. While the growing pains of this process have made designing for differing browsers sometimes tedious and unreliable, the war seems to finally be coming to an end and it’s time to reap the rewards.

After about six months of work, my Pinwheel MUD engine (a variant of Ranvier) is finally in a usable, distributable state with the groundwork needed to add any variety of features. Up until now, I was rewriting all of the source files and making changes to the entities to support full persistence and a web server. I’ve also made numerous changes to the underlying architecture of the engine and reduced the discrepancies between player and non-player characters. As of now, it’s possible for someone to clone the repository, npm install, and with a single command launch a conjoined MUD-web server that’s ready for content and gameplay.

We’re almost another revolution around the sun and a lot has changed for me this year. I won a Google scholarship, got a promotion, completed a Udacity Nanodegree, lost some weight, and worked on lots of cool side projects. Now as we slide through December, I’m looking back on this year and what it’s meant to me.

This article will analyze the tragic Barca family and the accomplishments, flaws, defeats, and aspirations of this powerful Carthaginian clan. After Carthage was defeated by the Romans in the First Punic War, Carthaginian noble Hamilcar Barca conquered the Numidians and moved north into Spain in 237 BCE. He hoped to conquer new lands, subjugate the Celtiberian natives, and excavate the rich mines of the mountainous peninsula. All of these efforts were fueled by the empire’s recent defeat, with the newly-empowered Phoenician city-state requiring new territories and income to offset the costs of war.

In the last month, I’ve made continued progress on Pinwheel, my MUD game engine. In fact, there are only a few remaining elements of the core source code remaining before I feel ready to start building my developmental game world. In the course of refactoring and building this engine, I’ve cycled through many different themes for a game I could potentially build with it. I’ve tried not to let those themes steer my designs too heavily, with the goal of making a universal engine that can be molded easily to fit different themes. Some MUD engines come with stock content to showcase how the code could be adapted, but often times this content feels prescriptive and can get in the way of other ideas.

Lately, I’ve had a laser focus that’s consumed me in my latest project, Pinwheel: a fork of Ranvier, a MUD engine in JavaScript. This fork started as a question: can I add a web server to a MUD engine? The answer—which I found out pretty quickly—is yes. With that done, I turned my attention to the rest of the code. I started to rip things out and move them around. Even after weeks of tinkering with it, I’m genuinely fascinated by how this stranger’s software works. Reorganizing the blocks bit by bit, rewriting some parts entirely… all of it is rewarding. The silent reflection of teaching yourself another person’s code is oddly zen-inducing.

In a recent post, I made the case for MUDs in modern times which explored the niche that MUDs occupy on the internet. As a longtime player of MUDs, I started learning to code in order to tinker with downloaded codebases, trying endlessly to run ancient makefiles and compile spaghetti code hobbled together by lots of strangers on SourceForge. It was fun, but hardly effective!

I’ve just finished my Mobile Web Specialist course after completing my final project. I covered a lot of ground between the first project and the third one, including transforming a website into a performant offline-first web app. Each project stage was professionally evaluted and I received a line-by-line code review of my work, which wa really helpful for getting useful feedback. I managed to zip through the stages pretty quickly, because I had completed most of the lessons already through my scholarship program (all of the lessons in the Nanodegree are available for free). The course runs until the end of October but I’m now finished two months early.

In the age of smart devices and instant entertainment, can a medium as old as MUDs survive? Driven entirely by text, these Multi-User Dimensions ― or Dungeons, or Domains, or so many other options that they’re often called MU* ― are virtual worlds that consist entirely of text. Often outfitted as RPG-style games, these platforms are also home to niche internet communities on the fringes of the web. The servers are accessed via a telnet client, which is easy enough to launch in a command line. But there are a few popular applications that many longtime players opt to use. They’re rather reminiscent of the various chat programs built up around the IRC protocol, and provide simple functionality like logging, colors, aliases, triggers, timers, and even mapping.

Great news! I recently received a promotion at my job. I am now the Director of Business Development at a leading educational services company. We primarily help students study for the LSAT and law school, but we also provide instruction for several other standardized tests.

As described in Part 3, I was waiting to hear if I would be continuing my journey in the Grow with Google Challenge Scholarship for 2018. In the last few months, I’ve been diving into topics like service workers, IndexedDB, and ES6 and writing about them here on my blog.

As humans, we take our ownership of words very seriously. We see words as a way for a human to express their thoughts and feelings, and while all words have concrete meanings, there are connotations and sentiments associated with certain words and phrases that we think a machine could never truly master as an unemotional third party. Even if we sometimes perceive emotion in a machine’s words (thanks to the ELIZA effect), a computer will never learn language the same way a human does, so can they deliver narratives with the same authenticity, accuracy, and appeal as a person?

I set out to participate in this quarter’s #FC_JAM a few weeks ago. I scoped out the various fantasy consoles available, trying to find something lightweight and fun to use. Most fantasy consoles are written in C and accept Lua scripts, but I found that TIC-80 released JavaScript support and that instantly convinced me. Since I’ve been studying so much JavaScript, getting to stick with that language was the appealing choice. The console itself is all-inclusive, with a terminal, sound, sprite, and map editors, and with artificial restrictions of 240x136 pixels display, 16 color palette, 256 8x8 color sprites, and 4 channel sound.

Picking up where I left off in Part 2, I’m continuing my journey in the Grow with Google Challenge Scholarship for 2018. Last time I learned all about IndexedDB, but this part of the course taught me ES6, the 6th edition of JavaScript, which is widely used today (sometimes with other names, like ES2015 and Harmony). These lessons gave me a whole new perspective on the language, and they’ve answered many long-time questions I’ve had about the “magic” of JavaScript.

Picking up where I left off in Part 1, I’m continuing my journey in the Grow with Google Challenge Scholarship for 2018. Last time I learned how to use a service worker to cache simple data in the example app, but this part of the lesson taught me how to properly cache and serve page resources like photos via IndexedDB.

Good news! I’ve recently been accepted to the Grow with Google Challenge Scholarship for 2018!

I’m always looking to expand my knowledge of programming, especially JavaScript. In recent years, JavaScript has become my favorite and most productive language. I’ve pieced together my understanding of the language through tutorials, books, courses, and a few good mentors. Within the JS community, many people have been waxing poetic about Marijn Haverbeke‘s Eloquent JavaScript, so last year I started working through the book online. At the time, I had a strong foundation of JavaScript basics, but was looking for projects and exercises for practice.

Recently I’ve had a desire to start blogging again, to help me reflect as I work on projects. It’s a hobby I’ve explored since my exposure to the internet over a decade ago, and I’ve always considered myself a casual blogger. In the past, I’ve used platforms like WordPress and Blogger for personal blogs that usually revolved around projects. This time, I’ve been compelled to start branding my own name and taking ownership of my internet presence. To this end, I wanted to build a blog for myself so I’d have full control and ownership of both the written content and the supporting code of my blog. Originally, I was looking into writing my own blogging platform in React, but ultimately I have no interest in building a product from scratch when there are already several great open source options. There was no reason to reinvent the wheel in this case!

Animal Crossing has always been an important part of my life. It was magical and transportive at a time when things were dull and isolating. Like many American kids growing up in a small town, I adored AC because it offered me friendships unlike any others I had in real life. It also gave me Baabara, my first hag and an indicator of things to come.

Hi reader! I promise I can smile!