One of the oft-touted benefits of the beloved static site/blog generator Jekyll is the ability to host websites generated using the tool on free platforms such as Github Pages and Netlify. So why would you want to host Jekyll-generated websites on your own server? Well, there are many reasons. For one, hosting Jekyll websites on Github Pages requires either that the site’s repository be public (meaning that you cannot check in unpublished/draft articles without them becoming browsable in the repository) or that you have a “Pro” account (which is great if it’s something you need, but with private repository hosting included with free/standard accounts many people do not). Even disregarding these points, many of us have a strong desire to retain as much ownership of our data as we can, and if you share that outlook then you too may prefer to host Jekyll on your own server.

Hosting a Jekyll website on Ubuntu Server is very straightforward, yet I struggled to find any comprehensive guide on the subject when I was figuring it out for myself this past week, so I decided to document the process for anybody hoping to do the same.

Beginning around 2018, I turned some of my investment focus and allocation to private markets. My first deals in this area were via EquityZen, a platform whose focus is mainly late-stage growth companies. Offerings on EquityZen are secondary sales, where an early employee or existing investor is choosing to sell a large block of their own stock. Secondaries are a contrast to traditional primary offerings, where a company itself is issuing stock, and the cash from the sale is going directly into the company to fund operations. Secondaries are a very common practice both for founders/early employees to “take money off the table” if they know they may still have years ahead of them until IPO (or acquisition), and also for funds that need the liquidity (either for redemptions, distributions, or just to allocate to new opportunities).

For the last several years, I have been traveling full time. It is something that changed my life and that I wouldn’t trade for anything. But with it also come challenges. There is a burden in starting over again and again every several months – figuring out a new city, developing new friendships (though I am lucky enough to be able to reconnect often with many of my friends around the world thanks to communities like Hacker Paradise and Nomadlist), finding a productive work environment, and also the more basic things like just getting phone service and figuring out transit, etc.

I spent the month of January 2020 in Da Nang, Vietnam, a beach city situated in the central coast of the country, roughly halfway between the capital city of Hanoi to the North and Ho Chi Minh City to the south . It seems people haven’t yet written much about Da Nang from the perspective of a long-term traveler, so I wanted to share some impressions and thoughts on my time there.

I never expected to end up in Taipei.

For the last couple of years, I have been working remote. Initially from Berlin, then for an extended stretch from Eastern Europe. For the last 6 or so months I have been in Asia.

I had come to Saigon, Vietnam after several months in Bangkok. In Saigon I had struck up a chat at a local bar with another traveler, a student Brewmaster at Olds College, Alberta, Canada. This traveler, Mike, ended up becoming one of my better friends and more reliable companions on nights out in Saigon over the weeks that followed.

I have spent much of the past decade now building web applications professionally. Though not exclusively so, a large part of this work has ended up being with the Ruby on Rails framework. There is a widespread notion that monolithic Rails applications don’t scale, but in my experience I have found such applications often the most readily scalable of all that I have encountered.

I wanted to share some high-level insights and personally-acquired knowledge on this subject, in the hopes that such things may be taken into consideration by teams or developers weighing their options in architecting a web application for scale. There are also quite a few pitfalls, and these often contribute to an intuitive (if not very deeply introspected) sense that Rails codebases scale poorly, so I will attempt to highlight these pitfalls as well.

Something I have observed in my work over the last few years is that many genuinely competent, highly productive developers are tricked by their very skill into undertaking projects that, though ultimately successful to a degree, produce outcomes much poorer than had they simply integrated with a third-party platform. Oftentimes immense leverage can be gained simply by knowing what not to build.

One of the very wonderful things about the moment that we live in is how many mature platforms – both open source and closed, community-driven and commercial – we have at our disposal.

Like the boiling frog, we often fail to appreciate just how significantly the infrastructure upon which we rely as developers has improved over the last decade. When I began working with the Rails framework in 2010, everything from the hardware we used for local development, to the infrastructure upon which we tested and deployed, was positively anemic by today’s standard.

I’ve spent the last couple of years doing what I would call slow travel, spending periods of a month or more in different cities. This began in late 2016 with a job that brought me to Berlin for months at a time. I quit that job last October and in the time since have been through Europe, Asia, the US, and then back around to Europe, where I am for the next several months with no fixed end in sight. I wanted to compile some observations that I’ve made in this time.

I spent a good part of last year living in Berlin, encountering large, Cold War era constructions on my morning walk. This style of architecture, distinguished by exposed concrete cast in hard lines, with little paint or ornamentation, is part of an architectural school known as Brutalism, and was very popular through the mid 20th century, especially in Eastern Europe.

The term has since been transposed to the online realm with brutalistwebsites.com, a site put together in 2016 by Pascal Deville (now Creative Director at the Freundliche Grüsse). I wanted to pay tribute to the tongue in cheek term by recognizing some of my own favorite Brutalist websites.