Recently, I’ve been toying with the idea of starting a new YouTube channel with my wife. We haven’t pinpointed exactly what kind of video content to create yet, but it’ll probably be a mixture of family travel vlogs, street photography walks, reaction videos, and sharing perspectives on parenting.

I haven’t really taken YouTube seriously before because I’ve always been more of a blogger, but I think it’s difficult to build an audience nowadays without a video strategy. Whenever I dive into a new hobby, I have a tendency to get obsessed with what tools and gear to invest in. In the past, this personality trait of mine led to me spending way too much money on high-end cameras, headphones, and bicycles. Luckily, I still love photography, listening to music, and cycling, so it’s not such a big deal.

This time around, I wanted to take the opposite approach. Instead of buying the latest and greatest camera and lens combo, I decided to use my existing iPhone 13 Pro. On the accessories front, I picked up a Zhiyun Crane M2S gimbal, a few Moment lenses, and a DJI wireless microphone kit. In total, I spent around $800, which isn’t too bad for a decent video rig.

The camera system on the iPhone 13 Pro – decent hardware plus excellent computational augmentation – is pretty great, so I don’t feel like I’m missing too much. It’s definitely more than enough to get started with.

I’m going to start filming some stuff once I get back to Japan in a few weeks, so stay tuned for more information!

I’ve been getting more and more into web development lately. It didn’t interest me too much in the past because I could never wrap my head around JavaScript despite having finished multiple Udemy courses on JavaScript and React. I feel like my personality is just at odds with how the JavaScript web development ecosystem is structured – it’s just too complex and chaotic, and it doesn’t have to be.

Anyway, I do most of my software development (if you can call it that) in Python. Until recently, most of the stuff I was developing was backend only – APIs, trading bots, etc. At some point, I heard about HTMX and hyperscript on a podcast, where it was being pitched as a way to do modern frontend development without having to write a single line of JavaScript.

As a chronic avoider of JavaScript, HTMX and hyperscript instantly caught my attention. In a nutshell, HTMX lets you send swappable HTML fragements from a backend server to a frontend, while hyperscript lets you create client-side interactivity with a natural language syntax.

To get a sense of what HTMX can do, check out this ICON blockchain tracker I’ve been working on. It’s still in active development, so some pages may look funny or break completely. The stack I’m using for the tracker is FastAPI, HTMX, TailwindCSS, and a little bit of hyperscript here and there. It’s pretty amazing to me that in 2022, it’s possible to develop something like this without writing any JavaScript. I know this way of doing things is fringe and contrarian, but it really brings me joy.

Before you go, click the hyperscript-enabled button below. It makes a request to a blockchain API and fetches a few block hashes – no JS required. Open up your web inspector if you’re curious as to how it works.

Recently, I’ve been working on a page to track GitHub activity for ICON-related repositories. The page has a component that displays every commit made to the tracked repositories. This component is powered by a background service that scrapes GitHub’s API for new commits every few minutes, and stores new commits in a MongoDB database.

As you can imagine, this task is fairly resource-intensive (especially for repos with a large number of commits) because GitHub only displays up to 100 commits on each API call. So, scraping commit data from a repo with 5,000 commits would require 50 API calls.

To make things a bit more efficient, I added some additional logic that queries the database for all commits to a repo, queries the GitHub API for the total number of commits, and compares the two numbers. If the two numbers are equal, the background service can just skip the resource-intensive API calls for the given repo.

Here’s a simplified version of the function I wrote to get the number of commits to a GitHub repo:

import requests
from urllib.parse import parse_qs, urlparse

def get_commits_count(self, owner_name: str, repo_name: str) -> int:
    """
    Returns the number of commits to a GitHub repository.
    """
    url = f"https://api.github.com/repos/{owner_name}/{repo_name}/commits?per_page=1"
    r = requests.get(url)
    links = r.links
    rel_last_link_url = urlparse(links["last"]["url"])
    rel_last_link_url_args = parse_qs(rel_last_link_url.query)
    rel_last_link_url_page_arg = rel_last_link_url_args["page"][0]
    commits_count = int(rel_last_link_url_page_arg)
    return commits_count

Back in December 2020, I tried out Cloudflare Pages for the first time during its public beta. After a few days of trying to get it to work with my blog, I gave up and reverted back to the always trusty Vercel.

Long story short, Cloudflare Pages was still very new at that point and there were some compatibility issues with a few of the larger images on my blog. Also, site builds were taking upwards of 10 minutes on Cloudflare, versus 1-2 minutes on Vercel.

Recently, I decided to take a look at Cloudflare Pages again because of Imgix’ new pricing model. I used Imgix to generate different sized variants of images on my blog because I don’t like the WordPress model of storing multiple sizes of the same image locally – it’s a waste of space. Imgix used to offer a cheap plan with generous limits, and my monthly bill never surpassed $8. The new pricing model includes a free plan that supports 1,000 origin images and unlimited transformations. Unfortunately, I don’t qualify for this plan because I have too many images on my blog.

The funny thing is I was actually grandfathered in on the old plan, but I wanted to take advantage of the two origin sources offered on the new free plan. After switching to the new plan, I was excited to reduce my monthly costs for hosting this blog. A few days later, I got a notification that I had exceeded 1,000 origin images and Imgix would no longer serve new images unless I upgraded to a paid plan – the cheapest of which is $75/month.

Here’s a breakdown of Imgix’ new pricing model:

• Free ($0/month) – 1,000 origin images, 2 sources
• Basic ($75/month) – 5,000 origin images, 5 sources
• Growth ($300/month) – 25,000 origin images, 10 sources

To me, this pricing model feels weird because $0/month to $75/month is too big of a jump. I’d love to see a $15-$20/month “Creator” tier that offers 5,000 origin images and one source because I get the feeling that photography-centric bloggers like me don’t really care about the number of sources – we just need support for a lot of images.

At this point, I had two options:

1. Reduce the number of images on my blog.
2. Find a different provider for image resizing.

Option 1 obviously wasn’t happening, so I started looking for a new provider. After exploring various options, I ended up going with the Image Resizing feature that’s included with Cloudflare’s $20/month Pro Plan. I didn’t mind the $20/month fee because it’s a whole lot cheaper than paying $75/month to Imgix for image resizing ONLY.

Here are a few of my favorite features on the Cloudflare Pro plan:

• Dynamic image resizing
• Image optimization with Cloudflare Polish
• Built-in web analytics (this allowed me to get rid of my $14/month Fathom Analytics subscription as well)
• Support for Automatic Signed Exchanges
• Super fast global CDN

While migrating my image resizing stack to Cloudflare, I decided to give Cloudflare Pages another shot as well. I’m happy to report that the Pages product has been polished (no pun intended) significantly since I last tried it. After linking my blog’s GitHub repository to Cloudflare Pages, it was able to build and deploy the site in less than two minutes with zero issues. Best of all, I ran a few page speed tests and found that Cloudflare Pages is slightly faster than Vercel and Netlify.

I’m glad I was able to move my entire stack (DNS, hosting, and image resizing) to Cloudflare. If you use a static site generator like Hugo to power your blog, I highly recommend hosting on Cloudflare Pages and taking advantage of the powerful features on Cloudflare’s Pro Plan as well.

I recently picked up a Leica M10 Monochrom. More to come.