I love the taste of kombucha. Since I already do some fermentation at home, I figured that I could try fermenting my own ‘booch at home, too. So last month, a friend gave me a jar of kombucha with a gelatinous, leathery-like film floating at the top. It was pretty gross-looking, but this was the SCOBY or the “symbiotic culture of bacteria and yeast,” and it was essential for making my own kombucha.
There are plenty of kombucha-making tutorials online, but my friend recommended that I watch the You Brew Kombucha channel on YouTube. Andrea and I learned that it’s actually pretty straightforward to make kombucha, and it’s also really cheap! It’s just tea and sugar (and time). There are basically two parts to kombucha making:
We put sweet black tea (we use Assam tea at home) along with the SCOBY in a large jar, and we just basically let it sit there for 7-10 days. We should be okay as long as we have a piece of cloth over it (to prevent contamination) and that it’s away from direct sunlight. We also try and taste the tea from time to time to see if it’s good enough for our liking.
We technically have kombucha after the first fermentation, but the second fermentation adds additional flavor and carbonation. This is fun for us because we get to mix in different fruit juices and try out different flavors.
We first puree the fruit and put them in bottles. We then pour the kombucha into those bottles and shut them tight. The sugar will turn into carbon dioxide as it ferments for a few days (4 seems to be the sweet spot for us), making the kombucha fizzy.
My personal favorite so far is honey with lemon juice. It makes a really refreshing kombucha.
Repairability has become a big part of my decision making when I buy new devices these days. I don’t know much about electronics, but learning to make minor repairs on my iPhone, Android, and Roomba made me realize that I could easily give new life to old and hobbling tech. It felt good to keep something going, and I’m hoping that this will help save me money and reduce my e-waste in the long run. So, now that it’s time for me to find a new laptop, I wanted to make sure that there was a chance for me to at least swap out a few components if I needed to.
I’ve been a Mac user for many years now, so I thought it made sense for me to do some research on the latest MacBook Pro laptops first. How repairable are they? It would be great if I could avoid switching OSes in the first place.
I found out that the new MacBook Pros only scored an abysmal 1 out of 10 on iFixit’s reparability rating. Apparently, they’ve all had terrible scores since 2012. They have everything soldered and glued together which meant that I wouldn’t even be able to upgrade the drive or RAM if I wanted to. It was clear that I was going to have to leave macOS if I’m adamant about getting a repairable laptop. (There are repairable Macs out there, but they’re desktops and not laptops. The Mac Mini scored a 6 out of 10, and the Mac Pro scored an amazing 9 out of 10! But even if I wanted a desktop, a Mac Mini is too underpowered for work, and the Mac Pro is almost too excessive.)
Trying it out
I wasn’t sure if I could even pull off moving to another OS. I knew that I wouldn’t be able to use Linux for work, but could I move to Windows? It’s been 13 years since I last used one.
I thought that the best way to know was to try it out. So, I committed to using Windows 10 on Bootcamp for a week to see if it was any good. I told myself that if it didn’t work out, I could just get a Mac like I always did.
Most of the apps I use are fortunately cross platform. Figma Desktop, Krisp.ai, TiddlyWiki, VSCode, and Zoom all work the same way on Windows. For everything else, I had to do some work to find alternatives. Here’s where I moved to:
I’m sad that nothing really comes close to a Fantastical alternative on Windows. The built-in calendar is fine to manage both my personal and work calendars, but it’s missing a lot of the features that I use. It doesn’t have calendar groups/sets, and it doesn’t understand natural language. Typing in “Order chicken wings every Friday at 7pm” just won’t work on Windows.
The repairable laptop
I was convinced that Windows was good enough for my day-to-day work, so I went ahead and got a Dell XPS 17. Its slightly smaller counterpart got a 9 out of 10 on iFixit, and it’s got some good reviews online, too. I’ve been using it for a week now as I’m writing this, and I’m loving it.
I’ll still have my old MacBook Pro around to use from time to time (looking at you, Principle and Rotato), so I won’t be 100% on Windows. There’s also a lot to look forward to on the Apple side. They recently released their environmental progress report, and they talk about making it easy for people to repair their devices. I hope to one day see more repairable laptops from them.
During Hack Days last month, Robert and I thought it would be fun to make a Figma plugin that we could use while designing. We had many ideas, but we ended up settling on the idea of a plugin that fetches website metadata. We wanted a plugin that could fetch Open Graph information about a podcast, a song, or a news article, and we wanted to make it easy for people to import that data into Figma.
Since Figma only runs on web browsers (even though it’s written in C++!), the plugins have to behave like any other website. For us, this meant that the plugin we’d have to follow restrictions like the same-origin policy. It means that we can’t just fetch and scrape the website’s metadata from Figma since they likely won’t have the right CORS headers set.
For the Open Graph plugin to work, I had to set up an intermediary server that would scrape the website on behalf of the plugin. I’m not good at writing backend code, but I managed to write a simple server that was good enough for me to work with. You can find the server code on GitHub.
The server is far from done, and there are definitely many edge cases that I haven’t come across yet. What happens when a website blocks me? How long should I cache the page? What if there are no meta tags on the page? Are there any security implications for the Figma user?
There’s also the problem of actually running this server. I don’t think I’d want to run and maintain a VPS, so I’m thinking of exploring the possibility of converting it into serverless code. I’m thinking of looking into Cloudflare Workers soon.
I expected the UI for this plugin to have a fair amount of re-rendering, so I wanted to learn React before jumping into this project. Unfortunately, I couldn’t find the time to learn React, but I did find a wonderful templating library called lit-html. It was easy for me to understand, and it got me up and running immediately.
The plugin code is at the point where it can fetch data from the server and import images into the Figma document. It was a big win for me, especially since working with images is a bit complicated in Figma because of its architecture. I think the next step for me is to make this plugin more robust. What should it do when the server or network is down? Will this run on all major browsers? What kinds of errors will the plugin encounter? I have to address all of these before releasing this to everyone. You can find the code on GitHub, too.
It was fun!
It felt good to take a short break from design and do some frontend work. I’ve been feeling a bit rusty, but it was good to know that I can still write programs from time to time. I only got to work on it for a week, but hopefully, I can find the time to get this to the finish line.
These days, I expect electronics companies to be unhelpful when it comes to repairing. When I replaced the batteries on my iPhone 7, I had to buy unofficial parts, buy prying tools, read community-made tutorials, and pray that I don’t break my device while I force it open.
I was surprised when I learned that iRobot (the company that makes Roomba vacuums) doesn’t just sell spare parts, they also have tutorials on how you can replace them yourself. Wirecutter reports that they even sell parts for the original Roomba from 2002!
I’ve been using TiddlyWiki for two months now, and I’m amazed at how versatile this piece of software is. Since it’s able to weave together all the disparate parts of my life, it’s become my go-to notebook for almost anything. I’ve become dependent on it for documenting and understanding my life.
But if TiddlyWiki is going to be my notebook for everything, I have to get it to work on my phone, too. I’ve been hesitant about it because I assumed that it would be a pain to work on WikiText without a keyboard, but it didn’t end up being as bad as I thought it would be. I also like that I get to look things up on my wiki while I’m away from my computer.
The first thing that I needed to do to get set up on my phone was to get an app called Quine. Even though TiddlyWiki is just an HTML file (there’s no server component here), saving can be a bit of a pain because browsers don’t allow websites to write directly into files. Quine is a modified browser specific for TiddlyWiki that lets you bypass that restriction.
Next, I needed to figure out how to sync the wiki between my computer and my phone. The simplest solution is to drop the wiki into a service like iCloud, Dropbox, or Resilio and call it a day. Any changes that I make on my phone would automatically sync with my computer and vise versa. If you’re thinking of doing this yourself, this might be good enough for you! Dropbox even lets you recover old versions of the file if you ever needed to revert back to them.
But I wanted more control over my backups. I want to have the freedom to tweak the code and try out new themes and plugins without worrying about breaking my wiki. I wanted version control. I wanted Git on my phone.
I didn’t know if it was even possible to use Git on iOS, but I did a quick search and found Working Copy. All I had to was to link my GitHub account and point it to the right repository. GitHub now offers unlimited private repos for free, so I’ve taken advantage of that for backing up my wiki. Working Copy downloads the repo to my phone, and it makes the files available to third-party apps like Quine.
While this is not as convenient as using Dropbox, it makes me feel more confident about my wiki’s integrity in the long run. I’m excited about this setup, and I hope I can keep this going in the years to come.
Last week I got to make bagels with my coworkers over Zoom. We were supposed to get together in person for our annual meetup, but we opted to do everything online instead because of the pandemic. That bagel-making class was honestly one of the highlights of my week! I feel like it’s such a treat to see people in their own kitchens.
I rarely bake, so bagels were a bit of a mystery to me. I heard that bagels are boiled and then baked, so I assumed that it would be difficult to make them at home. It turns out to be pretty straightforward, and you can check out the whole recipe here. The hardest part for me was probably kneading the dough for ten straight minutes.
I think learning how a particular dish comes together is what I find enjoyable in cooking. And that I get to eat it if it all goes well! Even though bagels can be found in just about any grocery store, I feel I have a better appreciation of it now that I know how to make it.
Last week, I also got to make Bibingka for the first time. It’s a rice cake that’s usually sold as street food during Christmas in the Philippines. Andrea thought that since we had just made salted duck eggs, we should use it to make Bibingka, too. You can find the recipe that we followed here.
Bibingka and salted duck eggs were things that my family never made back in the Philippines because there was really no need for it—you could easily get them from a street vendor or at the store. But now that I don’t have easy access to Filipino food, I feel like it’s become a bit of a necessity for me. I’m feeling proud of myself for learning the dishes that I ate growing up, and that I’m seeing them in a new light now that I’m making them as an adult.
The other day I learned that there’s an archive of my very first homepage on the Wayback Machine!
I never thought I’d see this page again, and I don’t think 2006 me ever expected it to survive this long either. I just wish that it got to archive the Flickr photos, too. I was 15 at the time, and I was learning about Linux on a free shell account on anapnea.net. They happened to offer static web hosting as well, so I thought that it would be the coolest thing ever if I built my own homepage—especially since everyone else seemed to be on Friendster (the Myspace of Asia).
The auto-playing music is obnoxious and the multi-colored text is childish, but I was proud of this website. It was a way of showcasing my interests and I loved that I could do it outside the constraints of social media platforms. I learned how to use the command line, SSH into a server, and write some HTML to make this into a reality.
So I thought I could commemorate it by reviving it and giving it a proper place to live online.
I couldn’t find a clear way of downloading Wayback Machine archives, but I found this gem called Wayback Machine Downloader which did all of the work for me.
Most of the markup was generated by a tool called Nvu which was an open source clone of Adobe Dreamweaver. Back then I was big into open source software and I absolutely refused to use anything that’s proprietary. I also didn’t have the money to spend on software anyway.
But because the markup was automatically generated, things were smushed and hard to read. I thought I could at least clean it up before I uploaded the code to GitHub. Fortunately on VSCode you can easily fix it by pressing ⇧⌥F.
Wayback Machine wasn’t able to archive the Flickr photos that I embedded on the page so I had to swap them out with ones that I had taken recently. I hosted those on my Backblaze B2 bucket.
For hosting, I wanted the code to live on GitHub so the easiest way to host it was through GitHub Pages. I simply made a CNAME record on my DNS provider to point jagtalon.github.io to 2006.jagtalon.com. Done!
Fair warning that music might automatically play when you visit 2006.jagtalon.com. Embedded music was all the rage back then, so 15-year-old me thought he’d embed some MP3s in there, too.
I grew up eating a lot of itlog na maalat or salted duck egg when I was growing up in the Philippines. My family usually makes a simple salad out of it that you either eat with rice or on the side of the main dish. It really only has two ingredients:
Hard-boiled salted duck egg
You can also add onions, fish sauce, or black pepper if you want to add some variation to the taste and texture. Salted duck eggs are usually sold in Asian markets, but because of COVID, it’s not easy to go to one. Fortunately we got a delivery of fresh duck eggs from Imperfect Foods, and we thought that it might be fun to try and make our own salted duck eggs at home. It turns out to be easy, but it takes a long time to make: 3 weeks. Here’s the recipe that we followed: Salted duck egg recipe (video version)
It’s a success! It tastes exactly how I remember it to be. I’m not sure if it’s worth doing, but I’m glad that I know know how salted eggs are made.
Yesterday, I learned how to repulgue or crimp an empanada to get that beautiful braided edge. I had trouble doing this the first time when I was following Bon Appetit’s video on making empanadas, but I finally got it when I followed the technique in this other video. The difference is that the second repulgue used a flat surface to help with the crimping.
I’m starting to love the process of journaling and note-taking on TiddlyWiki. Being able to weave my ideas, notes, and experiences together easily has been a bit of a game-changer for me. Who knew that a wiki would be so useful in my day-to-day life? The downside of using TiddlyWiki is that it’s not exactly what I wanted out of the box. I had to put in some effort and tinker to get it to work well for me because it felt like it was missing some of the features that I needed. Here are the plugins and tools that I’m currently using that make TiddlyWiki more of a joy to use:
1. Stroll. As I mentioned in “Hello, TiddlyWiki,” the cool thing about Stroll is that it adds bi-directional links to my documents. It means that if I make a “Nintendo” link in a document called “Animal Crossing,” “Animal Crossing” will end up creating a link back to “Nintendo,” too. This lets me see all the relationships between my documents. For example, it can tell me when I played Animal Crossing and the people that I played with on that day.
2. TiddlyDesktop. TiddlyWiki is a single HTML file that somehow has everything it needs inside of it. I’m not just talking about the JS and CSS—it has all my documents and images inside of it, too. There’s no database, there’s no server, and there’s no use of browser storage either. Each document that you make ends up being a part of the HTML itself. It’s a crazy yet brilliant way of creating a self-contained program. It pulls this off by being a quine. This means that TiddlyWiki’s source code and data can be viewed and modified within TiddlyWiki itself. However, the downside of being an HTML file is that you can’t write to the local filesystem directly. People have created different solutions for getting around this, but I think my favorite is TiddlyDesktop. It’s a specialized browser that makes saving wikis less awkward and more natural for people.
3. Whitespace Theme. The default theme that comes with TiddlyWiki is a bit too spartan for me, so finding a nicer coat of paint on an app that I use all day makes a difference. You can find a few more themes here.
4. Favorites. I have documents that I frequently go back to, and the Favorites plugin is perfect for pinning them on the side.
5. Project Manager. I’ve been using TiddlyWiki to track my article reading list, book reading list, and some of the ideas that I have for my blog, and the Project Manager plugin has been perfect for that.
I’m still learning as I go, but I’m pretty content with my current setup. The only thing that I’m anxious about is performance: since everything is in a single HTML file, are things going to get slower in a few months or years? In this video, the creator says that 100MB wikis are still fast, but I’m curious about the limits of large web apps. I guess we’ll find out!