Taipei: the user-friendly city

Taipei: the user-friendly city

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 had longstanding plans to meet up with an old friend from New York in Japan after my time in Saigon, but no idea where I was heading after. Mike strongly encouraged me to go to Taipei, and offered to intro me to a Taiwanese-American friend of his who had been living there the last 10 years and could show me around a bit.

It is this arbitrary sequence of events that found me, roughly two weeks later, landing at Taipei’s Taoyuan International Airport.

Scaling with Rails

Scaling with Rails

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.

Leverage often comes in knowing what not to build

Leverage often comes in knowing what not to build

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.

On microservices and distributed architectures

On microservices and distributed architectures

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.

My personal laptop, reasonably high-end for the time, had a 5400 RPM spinning disk and 2 GB of RAM. SSDs were exotic, even on servers. Nowadays, you can get bare metal servers with 512gb-1tb of RAM, 2x multi-core CPUs and terabytes of fast SSD storage for a price that is perfectly reasonable for even small companies. Similarly, you can easily and cheaply launch fleets of high-spec virtual servers with providers like Amazon Web Services and DigitalOcean at minutes’ notice.

In many ways, it seems to me that we are often basing architectural decisions on imagined constraints. In my experience, a decision to embrace a microservices architecture should not follow primarily from concerns about scalability.

Some reflections on slow travel
Belgrade, Serbia

Some reflections on slow travel

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 over a period of a year. 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.

Why not give users equity?

There is a perspective from which the venture model that dominates a large subset of the tech industry is a little baffling. The infrastructure necessary to operate web/software products has never been cheaper. To an extent, the manpower has also never been cheaper (in the respect that it is increasingly practical to hire from a global talent pool spanning regions with very modest salaries). Still, the model that dominates Silicon Valley and other leading innovation hubs is one of selling off huge chunks of equity and pursuing liquidity for shareholders (via acquisition or IPO) over autonomy and sustainability (i.e. indefinite operation with profit distributions).

I say this is “baffling”, but there are reasons why the model persists.

PeerStreet follow-up review (performance over 2 years)

PeerStreet follow-up review (performance over 2 years)

I wrote a review of the PeerStreet peer to peer lending platform in late 2016. Now, having spent 2 years investing with PeerStreet, I wanted to do a retrospective as I have had a much more comprehensive exposure to the platform and more stats.

At a high-level, PeerStreet allows investors to participate in short term real estate lending. PeerStreet purchases short term loans (typically 11-24 month maturity, though there are also ultra-short-term 1-3 month offerings) from other hard money lenders and divides them among investors on the platform. You receive income from these notes in proportion to your investment. A major advantage of PeerStreet over certain other peer-to-peer lending platforms like Lending Club is that notes are secured by a first lien on a property, at a known loan-to-value ratio (which gives you some amount of downside protection in the event that the borrower defaults).

A simple recipe for forwarding webhooks to your local development environment

A simple recipe for forwarding webhooks to your local development environment

If your web application integrates with third party services via Webhooks, you will likely have encountered the need to forward Webhook requests to a local development server.

My solution to this had long been a free utility called Localtunnel, which forwards requests from a randomly-generated public host (i.e. [random-prefix].localtunnel.me) to your local machine. A major problem with Localtunnel is that it will not provide you a persistent URL, so you end up having to constantly reconfigure services to point to newly-allocated/temporary URLs.

If you have a VPS or dedicated server, you can use SSH remote forwarding to accomplish the same thing that Localtunnel does, but maintain a persistent remote hostname and port. This way you can configure development Webhooks once for your third-party integrations and be set.