The Obsidian website describes it as “A second brain for you, forever.” While this certainly sounds enticing, its actual description is a bit more useful:
…a powerful knowledge base on top of a local folder of plain text Markdown files.
To put it even more plainly, Obsidian is both a collection of folders and markdown files on your local filesystem and a piece of software that views them and can interconnect them in a really slick way. Their thesis is that traditional forms of note taking and conventional knowledgebases are typically highly linear and in that regard, very much unlike the human brain, which is graph-like in nature. Obsidian leans into this idea so heavily that it ships with a graph viewer of your entire knowledgebase, referred to as a “vault.”
An example from their site:
The way I stored information was a total mess and I was constantly forgetting about things due to not being able to find them. Trello was a game-changer for me for a long time, and I happily spent a very long time as a paid-tier customer, but over time I found it to be lacking. There wasn’t a great deal of support for interconnecting cards from different boards. Sure it can do this, but being able to zoom out to a ten thousand foot view and see your entire data set as a graph is next-level visibility. Obsidian gives me the tools to be able to map out my thoughts as I do in my head, which in my view is immeasurably powerful.
On top of the features it ships with, it’s extensible with custom plugins, and some of the open-source plugins created by the community are phenomenal. My absolute favorite plugin is obsidian-kanban by mgmeyers. This plugin enables you to turn any plain old markdown document into a full Kanban board, essentially a full Trello clone, except there’s no central server. The entirety of this board lives in your local filesystem and can thus be committed to source control such as Git. Inside each Kanban board in your vault, each card can be just a simple blurb of text or a link to an entire markdown document, the relationship of which will be displayed in the graph.
From the obsidian-kanban Github repo:
It’s simple– because it provides an entirely new way to think about how your data, knowledge, memories, and important documents are stored and related.
Wait what? Important documents?
Yep. We’re going to cover that too once we talk about git-crypt
.
An Obsidian vault is highly flexible and versatile. You can use it to store virtually anything from collections of recipes to an internal blog, or something like daily standup meeting notes which is something I use it for daily so that I keep a historical record of my daily standup posts on Slack (I’m a fully remote worker, so our standup updates are posted in a dedicated channel in slack every morning). Additionally, as part of devops / security ops work I’ve been doing, I send regular reports containing compiled lists of application exceptions with triage notes, etc. Obsidian helps me keep track of all of my application triage notes throughout the day so that they’re very easily composable into a report at the day’s end. I feel like nearly everyone out there especially in tech has some kind of use case similar to these.
Obsidian is free. There’s no central service, no connection-required functionality, no subscription, and no login to remember. Your vault is 100% local and isolated to your machine unless you decide to replicate it to another machine or mobile device using something like Git. The only paid functionality offered by Obsidian is a “sync” service that enables it to synchronize your vault across multiple devices. I haven’t even considered paying for this as it’s not a big deal to me to manually update my vault on my various devices as Git makes that super easy. Plus, I feel like anyone who gains real value from looking at a graph to remember things probably isn’t the optimal demographic for cheeky paid convenience features.
That being said, Obsidian costs nothing to try and doesn’t require you to wrangle yet another login to yet another service that might leak your data in yet another data breach.
So you’ve decided to take the plunge and give it a go. Firstly, you can create a new vault or convert an existing directory into an Obsidian vault. This can be really useful for migrating your existing notes into Obsidian. Once your vault is created, you’ll be able to drag and drop your existing markdown notes around into folders and a structure you can create within the Obsidian application.
If you’re creating a brand new vault from scratch and not converting an existing directory into a vault, you’ll need to specify a name and location on the filesystem for it to live. This name will be important when we secure the vault for git.
My wife and I recently returned from Iceland, and while I was there, I used Obsidian exclusively to store, track, and manage our boarding passes, itinerary, hotel / bus / rental booking confirmations, etc. I keep my vault in a private Git repository, but I also encrypt all of the data within my vault such that not even the source control service I use can peer inside and invade my privacy. This is super easy.
We’re going to use git-crypt to privately store our Obsidian vault on Github. We’ll begin by installing git-crypt
as described in the installation documentation found in its Github repo.
For this, you’re going to need a PGP keypair. If you’re unfamiliar with PGP, this video should get you sorted out.
If you’re running MacOS, git-crypt
can be installed very simply with Homebrew:
brew install git-crypt
Then initialize your Obsidian vault as a Git repository:
cd YourVaultName && git init
Once git-crypt
is installed, we’ll need to create a .gitattributes
file at the top level of your Obsidian vault directory that looks like the following, replacing YourVaultName
with the name of your vault as it appears in the filesystem:
secretfile filter=git-crypt diff=git-crypt
*.key filter=git-crypt diff=git-crypt
YourVaultName/** filter=git-crypt diff=git-crypt
YourVaultName.md filter=git-crypt diff=git-crypt
.obsidian/** filter=git-crypt diff=git-crypt
Once this is created, cd
into your Obsidian vault, initialize git-crypt
, and add yourself as an authorized user with the email you used to create your PGP keypair:
cd YourVaultName
git-crypt init
git-crypt add-gpg-user myname@myemail.com
At this point, everything should be configured for your vault to be PGP encrypted at rest on Github. Once you commit and push to Github, you’ll notice that all of the data is rewritten. This is git-crypt
doing its job. Once you’ve pushed up to Github, take a look around the repo in the Github web interface and ensure that all of the markdown documents in your vault are unable to be rendered by Github.
🎉 We’re done. Now you have a free, portable, resilient, encrypted, and version controlled digital brain that you can teleport anywhere in the world. Since you’re leaning against PGP, you can be confident in storing even sensitive documents within your Obsidian vault.
I really hope you get the same kind of value I do out of Obsidian. I can only hope it’s as good a fit as it has been for me. Good luck!
]]>When the sublease on our slip ran out, we decided to press pause on the never-ending waterfall of boat projects by pulling her out of the water, swearing we would start working on remediating some of these issues once Washington’s rainy season started coming to a close. Thankfully, that time is finally here, and it’s time to start working on the boat to get her ready for some larger trips we have planned for later this summer– namely sailing to Victoria, BC and Desolation Sound.
Our boat has a LOT of wood on it. It’s a fiberglass hulled boat, but all of the brightwork and both of her masts will need to be stripped, sanded, and varnished. This is going to be a huge task as each newly varnished area will require several coats. In the case of the masts, this means multiple trips up and down each one, stripping, sanding, and probably something like 7-8 coats of varnish each.
As you can see in the above picture, the old varnish last applied by the builder of the boat has far exceeded its maximum lifespan and is overdue for reapplication. Once it’s started to flake off like this, it’s just a matter of time before rain and moisture deteriorate the wood and if left untreated, can ultimately compromise the structural integrity of the boat. It’s important to note that this deck cleat is designed to make fast parts of the running rigging, which can have huge forces exerted on it due to the load of the wind on the sails and ultimately the running rigging.
As our boat was owner-completed as opposed to factory-completed, there are a few elements of its construction that leave me wondering why certain decisions were made. The above photo is of the underside of the portion of the boom gallow that mounts to the deck. This is a load-bearing part of the sailboat, as the main boom will want to pull upward on these fittings. These bolts need to be shaped up, evenly cut and fit, etc. I’d also like to fabricate a metal plate to sit between the washers + nuts and the wood itself to further reinforce this component.
Thankfully we’re not alone in this endeavor. We’ve had some pretty great help and advice from the owners of the boatyard, and while we’re quite new at this kind of work, their help has been invaluable, and we can’t overstate how much we appreciate their guidance in showing us the way to do this work ourselves. Fixing the boat is great, but learning how to fix problems of this kind on our own is worth a whole lot more.
Winter in the Pacific Northwest is hell on a boat, as can be seen in the sheer amount of gross happening on our deck and cabin top. Step one in Operation Tender Boat-loving Care is to make her sparkle again. Next weekend will be our first few days aboard to knock these work items out, and cleaning everything up will be the first order of business. From scrubbing every part of her interior and exterior, to cleaning the teak decking with oxalic acid to re-caulking all of our deck fittings, we don’t intend to stop until she’s boat-show beautiful.
The Trello board I keep for boat work is too heavy on the “Planning” and “In Progress” cards, but much as I do in my professional life, I’ll soon start moving cards to the right and knocking these issues out one by one until she’s ready to head for the warm waters of Desolation Sound.
]]>I’ll just leave it to Glenn Greenwald to paint the picture. It’s a really important talk, and I highly recommend you watch it.
Suffice to say, digital privacy is extremely important to me. I believe it should be to everyone, but sadly this isn’t the case. If you came here from my FB / Instagram post today, please contact me in cases of reunions, events of note regarding friends / family, etc. My withdrawl from social media doesn’t mean I don’t want to communicate!
Email: wricketts@protonmail.com
Keybase: @willricketts
Mastodon: @willricketts@fosstodon.org
Telegram: @willricketts
Github: @willricketts
]]>Eve Online and Stellaris have very similar map systems. Both have solar systems represented in a DAG-like structure. The DAG’s nodes represent solar systems. In the case of Eve Online, this structure’s edges are representative of Stargates, and in Stellaris, warp lanes between solar systems.
In any case, both systems function in a similar way, in that players and their fleets traverse a large DAG to move around the galaxy.
Based on a system of ephemeral matches, Stellaris’s game maps are generated uniquely for each. Thus, each time the player creates a new empire or species and starts a game, a new map is generated and configured via the player’s selected settings when creating the game.
One of the major strategies when starting a game of Stellaris is to rapidly expand to claim and build defenses around choke-point systems, or systems that have many connections as to control the flow of traffic through that portion of the map. This is a side-effect of this galactic map model that I’m intent upon creating.
Eve’s map is persistent, in that the game has no concept of “rounds” or “matches.” The game map, save for additions by their publisher, has and will remain the same since the release of the game in 2003. Being that the intent of Rhea is to be a single persistent game world, this is the path I’ve elected to follow.
Some very desirable but non-obvious effects arise from this kind of model for a galactic map. With a static map, various regions or sections of it become known within the playerbase for being better or worse to own from a strategic perspective. Eve has regions of the game that are notoriously difficult to invade, and has a few that are notoriously favorable for an invading military to stage their assets.
Creating a map of this size and detail was a challenging problem to solve, and at the time of this writing, still presents obstacles to overcome to achieve an optimal map structure.
When I first sat down to work on figuring out the most immediate challenges in building Rhea, my intent was to get something simple working and then expand upon the idea later. Upon researching how I would go about generating a map of this nature with DAG-like properties, I found Astrosynthesis, a piece of software used for generating celestial structures primarily for role-playing games and hobbyist world-building. This program had a bunch of great features that’d be useful for my needs, but two features stood out in particular. Astrosynthesis has a user-created plugin ecosystem and an XML exporter.
Before long, I had a galaxy containing ~20 solar systems and connections between them, which I exported to a large XML document, which I was able to load into the Elixir-based backend of Rhea with elixir-XML-to-map.
From this very large map, I perform a series of mutations on the data to order it into a list of Solar Systems and one of Gates. With these lists, I first created a DB record for each of the solar systems within PostgreSQL. With a SolarSystems table populated with data, I would need to represent the data somewhere that graph-oriented data feels right at home. This is where Neo4j comes into play.
If you’re unfamiliar, Neo4j is a graph database. This turned out to be the perfect tool for Rhea. It was immediately apparent that its Cypher query language had the features needed to power several in-game systems for Rhea. Namely its ability to find the shortest path between nodes, or in the domain of Rhea, solar systems.
Claiming victory over my first set of development goals, I took a 2-month break from working on Rhea to focus on a large project I was leading at work, a large web service responsible for creating and marshaling Twilio conference calls in parallel– also built using an Elixir umbrella, also structured with the intent of utilizing BEAM’s distribution features in the future.
When I finally had time to devote to Rhea again, I revisited the map I’d generated and simply wasn’t happy with the result. After generating entirely new map data, this time for 2000 solar systems, I was dismayed to learn that the XML schema for my new map data was fundamentally different than that of my previous map. This would require me to write an entirely new parser and process for loading the map data into PostgreSQL and Neo4j. This was unacceptable to me.
Not being comfortable with the idea of such a pivotal piece of the system relying upon a proprietary dependency, I started exploring ways of generating my own map from scratch, but how?
A while back, I was reading about Brownian Motion and the aggregation of particles to form a structure. After diving back down that rabbit hole, I discovered Diffusion Limited Aggregation. This seemed to be the ideal method for generating a structure akin to the galactic maps of both Stellaris and Eve Online.
I found a simple C++ implementation of DLA and quickly generated a set of 2000 particles. This algorithm has a CSV output of the following schema:
id, parent_id, x, y, z
0,-1,0,0,0
1,0,0.934937,0.354814,0
2,0,0.0525095,-0.99862,0
3,1,0.989836,1.35331,0
4,3,1.92472,1.70826,0
5,3,0.65572,2.29584,0
...
EUREKA!
That was precisely what I needed to generate a fully original map! I built out each point as a Solar System in Postgres and Neo4j with its coordinates. After reducing the list down to a collection of IDs and Parent IDs, I was then able to build the stargates that connect the various solar systems together.
Originally, I built a name generator to automatically name each Solar System, but this was quickly outgrown and I was once again searching for a solution to unblock my map work.
After finding a super slick name generator built in Javascript, I was able to give each solar system a unique name that doesn’t sound like a Heroku deployment.
Below: the final structure of my fractally generated galaxy map:
Below: a closer view of a group of solar system:
Having a totally original galaxy map with a predictable and repeatable process for generation opens up all sorts of possibilities for new features and clever tricks. Having tied all of the generation and persistence process to a single function in the backend, rebuilding the map and trying generation with different inputs takes a matter of seconds::
def build_universe do
construct_map_db()
construct_graph()
IO.puts "Universe created"
end
# I couldn't resist writing a function called "destroy universe"
def destroy_universe do
[{:ok, _}, _] = [
Task.async(&Main.destroy_map_db/0),
Task.async(&Main.destroy_graph/0)
]
|> Enum.map(&Task.await/1)
IO.puts "Universe destroyed"
end
If you’re familiar with graphs, then you were probably left wondering why I refer to Rhea’s map as a directed acyclic graph as opposed to an undirected acyclic graph. Rhea’s stargates are represented in its persistence layer as pairs of gates, each unidirectional. This enables me to, at some point, build a wormhole system in which a player’s fleets can travel from one part of the galaxy to another instantly, but perhaps not return home through the same wormhole.
Perhaps I’ll introduce a player owned structure that prevents enemy fleets from leaving a Solar System once they’ve traveled through a stargate. This would lead to a much more robust system of player combat tactics and provide an overall more engaging experience, possibly allowing the few to overcome the many in a fleet engagement.
The map is far too linear, and this needs to be fixed before proceeding. This is my primary development item on the project, and I’m currently working on an algorithm that utilizes Solar System coordinates to create connections between solar systems that share a geographic region with one another. I assure you that will get its own blog post :)
For now, I’m happy enough with my work to begin sharing the obstacles I’ve overcome in building the game I’ve always wanted.
Thanks for reading, and I’ll see you in the next post.
]]>Over the last several months, I’ve been working on the backend for a lofty project. While not that much of a PC gamer, I generally focus on two types of games:
Aside from Star Citizen, due to the possibility of it being vaporware, all of these titles have been staples of the last several years of PC gaming for me– especially Eve Online, Planetarion, and Stellaris.
Each of these games have unique characteristics that I really enjoy, but I’ve always thought about what it would be like for a game to incorporate all of them in harmonious union. Eve Online’s metagame, political intrigue, complex player-driven economy, and expansive universe create an immersive third person experience with an extremely high skill cap. Stellaris focuses more on developing and scaling an empire from the perspective of its leader. Planetarion shares with Stellaris its perspective, but is a tick-based game played largely in text within a web browser, making it extremely portable and not totally married to a client with its own specific system or platform needs. To distill these properties into those that inspire the dynamics of Rhea:
Whew. There’s a lot to unpack there. Suffice to say, I’ve had a bit of difficulty describing the project in a brief way that’s easy to understand for someone who’s unfamiliar with these three titles, so I’ve taken to describing Rhea as “a tick-based 4x space conquest strategy MMO.” Most people are familiar with terms like “MMO” and “space conquest,” though a bit of this might take some explanation.
The tick system of Planetarion is very different than the temporal systems of most strategy games, in that a “tick” takes place every hour. A tick consists of all of the calculations required to update the game’s state for the next hour. Player resource balances are updated, fleets are moved based on their course, and combat outcomes are calculated. This allows the game to be played over a longer period of time in which the players are able to set up actions to be performed, and the system will execute them over time. The player is able to note when their attention will be needed next, and can return to the game upon a tick in which they want to perform their next action.
Rhea’s map is in essence, a giant DAG (directed acyclic graph) with solar systems represented as nodes and the stargates that connect them represented as the edges between those nodes.
This is not unlike the maps of all three games I’ve used as examples and inspiration for Rhea. In my view, it’s a great system, so I’ll borrow from their developers’ wisdom. The interesting difference in Rhea is that the Galaxy, in its current working model, contains 2000 distinct solar systems.
Check out an extremely early-stage rendering of Rhea’s game map here. Also to note is that this is not the final structure of the galaxy, as it’s simply the initial result from being fractally generated. There’s still plenty of work to be done in transforming the structure to have more interconnectedness and to be less of a corridor and chokepoint heavy layout.
When the player creates a character and enters the game, as of the time of this writing, they are provided a basic ship, are given some basic resources for expanding their wealth and influence, and are dropped into the game in a central area of the map in which they cannot be attacked by other players. This is a concept that was inspired by Eve Online’s idea of “high security space” or “hisec.” This is essentially an area of the game that’s PVE (player versus environment) only in which attacks on other players are disabled. The player has the freedom to exploit the very basic resources in this area and eventually equip themselves to venture further away from the galactic center in pursuit of greater wealth or conquest.
Players are able to claim space as their own, colonize planets, build facilities on orbital bodies that exploit their resources, and build defensive structures to stave off attacks and raids from other players or groups of players.
Players can form organizations with other players, are able to claim solar systems on their behalf, and can go to war with other player organizations for any number of reasons– from conquest and annexation of their enemies’ sovereign space to a simple raid over an enemy’s borders to pillage resources from an orbital facility.
I’ve chosen Elixir for the backend implementation of the various game services due to its wonderful ability to handle i/o bound operations with great efficiency. I also believe using a functional language is wise for building a “tick” system as a tick itself is basically a process of performing a large mutation of externally held state (PostgreSQL) in a predictable and repeated way.
Rhea’s backend, in its current state, is built as an Elixir umbrella with a few sub-apps handling various aspects of the game, such as its public api, persistence layer, galactic map (more on this part of the project in later posts), and a general orchestration layer, main
.
Aside from main
, each of these sub-apps exposes an interface to its various public functions as to prevent cross-application coupling:
defmodule GalaxyMap.Interfaces.Importers.MapGraph do
@moduledoc """
Interface for Map Graph importer
"""
alias GalaxyMap.Importers.MapGraph
defdelegate run(solar_systems), to: MapGraph
defdelegate clear_graph_data(), to: MapGraph
end
Rhea leverages the Quantum library to handle its various timed jobs, the majority of which take place when a tick is executed (every 20 minutes). Other various temporal features include scheduled statistics gathering, fleet combat precalculation, etc.
Rhea is a large project. For a single developer working on it in their spare time, it’s a really large project, but it’s a game that combines my favorite mechanics of my favorite titles as well as adding mechanics and systems I’ve always wanted to see in the 4x strategy genre. In essenece, I feel like I’m building the game I’ve always wanted.
I plan on releasing more comprehensive posts regarding game mechanics, technical implementation, and game lore in the future on this blog. Thanks for taking a look :)
]]>I spent the majority of the dry season of 2017 on my motorcycle exploring the East side of the Cascade Crest– Mazama, Twisp, Wintrhop, etc, but when I bought the Gypsea Rose, I knew that when the sun and heat gave way to grey clouds and perpetual fog and rain, the cabin of my boat was the only place I really wanted to be. There’s just something about its small space that’s really inviting. I’m sure you’re already thinking of the challenges of such a small living situation.
Good lord. This was the most difficult thing to combat on my boat. The fiberglass hull would constantly sweat as the cabin inside was warm from electric heaters, but frigid from its other side submerged in the water of the Puget Sound in January or so. This led to a bunch of mishaps and uncomfortable nights aboard. One memory I have of this specifically was returning home from a long trip to the East Coast, and wanting nothing more than to get back to my boat and get some good sleep. I returned to the boat to find that my heating units had stop running during the course of my 3.5-week absense. When I came aboard, got in bed, and turned the heaters on, it basically started raining condensation all over me from the ceiling, soaking my bedding and all of the sitting areas aboard. Absolutely miserable.
Storms are really nothing to scoff at even living aboard in a marina, let alone at anchor or on a mooring ball. For those unfamiliar with mooring balls, they’re essentially a chain that’s anchored to sea floor that’s held above the water with a buoy. You can simply sail up to one, tie off, and be held somewhat securely all night. There were plenty of evenings of 40+ knot winds in which I had to get up out of bed into 30-ish degree winds to check my lines to see if anything was fraying or coming apart. The most aggravating inconvenience of this situation is the inevitable awakening caused by some line or halyard slapping against some other part of the rigging, causing a maddening, rhythmic noise that could wake up even heavy sleepers. This necessitates getting up out of bed, popping the forehatch or opening up the companionway (door) to get on deck and fix it, only to have to do the same thing again 30-40 min later to check lines.
Other people in the marina I’ve kept my boat have largely been a problem. With the good comes the bad, and with this weird but satisfying marina life come the undesirables seeking budget accommodations in cheap sailboats or ones that are simply rotting at the waterline and in no way seaworthy. Theft, illicit activity, etc run rampant in the section of the marina I was in. I had countless pieces of gear go missing or turn up in someone else’s posession. Just recently, my dinghy was stolen and sold to another person in the marina. Luckily that guy was nice enough to give my dinghy back without any sort of contest once I showed him pictures of me using it during the previous season. Sadly, this isn’t uncommon in the world of liveaboards in some places. It just comes with the territory.
Waking up to the sun over the Puget Sound was a spectacular way to begin the day. My time aboard during the winter months gave me time to work on projects in the cabin, play old RPGs from my youth, and learn to fix broken things on the boat. I made the most of it, and I hope I get to spend another winter aboard.
]]>Keeping Sanity up in Bellingham, WA has been pretty advantageous given its close proximity to the San Juan Islands. The Islands provide their own set of challenges for sailors to contend with. Strong tidal currents, cold water, and at times large swells are enough to provide for some pretty exciting sailing, but can leave you stuck at anchor, on a mooring ball, or in a paid overnight moorage for a few days at a time. After two days of laying around on the deck of my boat, I start to feel a bit antsy to get back out on the water, which brings me to my least favorite point of hanging out at anchor or a moorage– the limbo you end up in trying to decide whether or not it’s wise to continue on the trip. I’ve made a fair amount of mistakes out on the water, but luckily none of them have been vessel-ending or severely injurious. However, the last two trips I’ve taken have aroused a fair bit of caution for future voyages.
Right after my return from Thailand, I decided to go on a solo trip around the San Juan Islands. The second day of that trip consisted of waking up at Blakely Island, and heading to Friday Harbor for coffee, onto Roche Harbor at one of the most western points of the San Juans, and then onto Sucia Island navigating through the finger islands of Stuart. That evening, I sealed up and went to bed while tied fast to a mooring ball.
That night was rough. The boat was sloshing around in the waves from about 9:30pm until sunrise, throwing me around in the small berth in the bow of the boat. After some sunlight crept over the horizon, I decided it was a great idea to go ahead and make my way home north of Orcas Island; a course I’d sailed many times. This day was different. Sailing out of my anchorage, I found the open water swells to be much larger than I’m typically comfortable with; blue water crashing onto the bow of the boat as it rode violently up and down the incoming swells. This began with reefed sails with a boom lashed forward– tiller in one hand and a bottle of mead in the other, and ended with white knuckles around the tiller and the VHF in the other hand set to channel 16, the Coast Guard distress and mayday channel. At this point, I’d decided it was time to do an about-face and head back to the island where I could take refuge in one of its many anchorages. After coming about and putting the swells behind me, the boat surfed back to Sucia where I managed to get back onto a mooring ball.
While sitting on deck and wondering what to do, I took the advice of some other folks around me and decided to head South out of Sucia instead of West. After fighting similar conditions for several miles down the coast of Orcas Island, I emerged from the big seas into calm waves and 8-10kt winds all the way into Friday Harbor, where I’d take refuge and work on the boat for several days until the weather was clear to get back to Bellingham.
I’d set off after arriving home from Thailand in the hope of relaxing out on the water for a few days, and instead ended up dealing with dangerous conditions and being stranded in a harbor for days on end. With the good comes the bad, and with great sailing come mishaps and close calls. This is probably why I love this shit so much.
]]>If you kept up with the previous iteration of this blog, you may have stumbled across a post entitled You Probably Didn’t See This Coming, or: I Moved to Washington. If not, it basically detailed my very abrupt relocation from Atlanta, GA to Bellingham, WA. I was offered an amazing and fully remote software engineering position in September of 2016 which allowed me to move to Bellingham, which I’d been wanting to do for years. Without this opportunity, a move to Bellingham would be pretty difficult, being that there are virtually no software jobs in the area that don’t require a close proximity to either Vancouver BC or Seattle. Now before you say, “Why wouldn’t you move to Seattle,” I’d like to clarify that I am not a city person. I’ve lived in two other major cities in my lifetime and have absolutely no desire whatsoever to repeat that experience. Seattle is a beautiful town and I love visiting, but I vastly prefer smaller towns when it comes to actually dwelling somewhere.
After moving to the Pacific Northwest, I quickly bought a Kawasaki KLR 650 motorcycle, which I rode constantly through the late winter, spring, and all summer of 2017. I was taking trips over the Cascade Crest into the desert of Eastern Washington as often as I could. On the same day I purchased the KLR 650, I started the Basic Mountaineering course through the Bellingham branch of The Mountaineers. This course led to all manner of outdoor adventures from Skaha Bluffs in British Columbia to The Squak Glacier on the volcanic Mt. Baker. Once the course ended, I ended up buying a 27-foot sailboat, which has utterly consumed my free time– so much so that I now live on it for no reason other than that I want to.
I recently went down to Georgia to clear out a storage unit I had in Norcross containing all of the belongings I wanted to keep, but didn’t want to immediately bring across the country with me. I returned to Georgia with the intent of arranging a shipment for all of the storage unit’s contents. I instead gave it all away to an awesome charity called The Place. I’ve grown to be a person of much simpler needs than I once was, and I just didn’t see a reason to keep all of that stuff for myself. I’ve got my boat, my bike, and an internet connection. That’s already more than I need to be happy with my current situation, so why hang onto extra baggage?
These days, I’m really content to divide my time between spending time with the people who I care about, going on adventures, working on projects, and sailing my boat. It’s a pretty simple life, which is exactly what I was craving during my time in Atlanta. I’m super thankful for the opportunity to totally transform my life, and I don’t see myself leaving Bellingham anytime soon.
]]>