workshop · @jnjosh’s internet weblog

Becoming an Amatuer Watchmaker: Servicing a Vintage Watch

Sun, 09 Feb 2025 16:00:10 -0500

Last year I dramatically fell into the world of watchmaking. I’ve often been mildly interested in watches and how they work but just assumed it was something too hard to do. I don’t remember where it started exactly this time, somewhere between Nat and I just deciding to try a DIY watchmaking kit or getting lost in the Wristwatch Revival YouTube videos, but when I say dramatically fell into the world, it’s not an exaggeration. I’ve fully set up a watchmaking desk, acquired a lot of strange and specific tools, and have now completed my second service. Between November and February I disassembled, cleaned, lubricated, and assembled a vintage Elgin watch I found on eBay—I learned a lot, did dumb things, acquired new tools, and finished the process with a new watch in my watch box.

The first watch I serviced was a learning experience. I actually did it 3 times because each time I had done something wrong and decided to just start from scratch. It also was a simple watch—no date, not automatic, etc—but also a very difficult watch in that it was hard to get it to perform well as it was a old and cheap 1-jeweled watch movement. I got through it and the watch is now in Nat’s watch collection, but I definitely plowed through it making a lot of mistakes.

My next watch would be the real test of what I learned. So I started looking for things to repair on eBay. I knew that a watch really needing restoration would probably be too hard, so I looked for things that were older but claimed to at least still work in some form. This may not surprise you but there are a lot of options for old watches on eBay. After browsing I landed on this vintage Elgin with a Linen Dial. I just loved the style of the linen and the way the numbers look—this Z-shaped 2 gets me every time. Even though I had gone through a service already this would be my first with some experience so I wanted to also expand a little—this one had a calendar wheel too, which the previous watch and learning movements (a Seagull ST36) didn’t have. So I bought it and excitedly waited for it to arrive.

About a week later in early November it showed up. I was pretty lucky. This watch was a bit of a risk, while the eBay seller said it was running—they couldn’t figure out how to open the case to inspect the movement or share photos of it. My naïvety shined here and I just thought, I’m sure it’s fine. I can definitely figure out how to open it. It was nice and the dial was better than I imagined. So I took a few photos and tested it on the timegrapher. It was running but a bit poorly, losing about 1.5 minutes a day.

So here we go, let’s get this thing open and start cleaning it. Oh wait. But. It’s not a normal watch. How do I open this thing? I studied it for a while, longer than I’d like to admit, and just couldn’t figure it out. The back was pretty scratched up so it looked like others had tried to open this too in the watch’s history. Then I remembered one of the many many episodes of Wristwatch Revival I watched where he had to remove the movement from the crystal side. It turns out this watch is a monocoque shell watch—meaning it was one piece. I had to remove the crystal first, but how? A new tool!

This—the most metal tool ever 🤘—is a crystal lift tool that squeezes the crystal just enough to be removed from the edges of the metal watch case. After you remove the crystal from the front of the watch, the movement can be removed easily. Also this type of case needs to use a split stem since you can’t easily remove the crown and stem—which was a scary process of pulling the crown until it detaches. And now I can pull the movement out and start inspecting it.

The movement is an Elgin 315, which looking deeper is based on an A. Schild 1802/1803 caliber. And it was dirty! Whoever serviced this thing last time really enjoyed using lubrication and often things were just stuck to each other or there were pooled areas of lubrication. It was kind of gross. Also it introduced my second big problem. I took macro photos of each step of the disassembly so if I needed to refer to something I could. Taking off the calendar wheel unfortunately was too easy, it all was under tension and so over-lubricated that once I loosened the screws of the cover plate it all kind of just popped out. Thankfully I didn’t lose any of the tiny parts, but I don’t know exactly how they all go back on since this was my first project with calendar works. This is a forshadowing moment for later. Anyway, I got everything disassembled and cleaned through my ultrasonic and thouroughly dried.

Time to reassemble! First part of this I recorded a video so you can follow along. Most of the reassembly went well, I had ordered a new mainspring because I don’t yet have a mainspring winder and it’s a pretty expensive tool—new mainsprings are cheap if you can find them. Getting the main part of the watch back together has become a bit more routine now that I’ve done the process a few times. Also at this point all the parts were still in good shape after I inspected them, so didn’t need to order anything new yet.

Then comes the calendar works. Remember earlier when everything stuck and I wasn’t able to see how it all goes back together? Well this is when it bit me. Thankfully it’s not too hard to reason about what goes where and some deep studying of the photos I did get helped a lot. Bad news is some parts do need to go in the right way and not upside down. Now listen, when it comes to watchmaking, one thing I’ve learnd pretty well is to not force things. These parts are small and delicate. Forcing is a bad idea. So, of course, after getting the calendar works back together but with an upside down lever holding the calendar wheel in place, it was not turning. This is when I forced it and… well tore the teeth off this hour wheel. Sometimes I guess you have to relearn lessons the hard way.

So… I went looking for another hour wheel and found a new old stock one and an old one on eBay, both about $5-10. So I bought the eBay one first but later thought I’d rather have the newer one. So I waited for a week and they both arrived on about the same day. The new one however didn’t fit. It was the right size but it was not as deep and the teeth didn’t line up, so the old one it is and now I have an extra part. I’m starting a collection of extra parts now I guess. But now it works and look at that calendar moving nicely but without needing to force it.

On the home stretch now! Just need to get it back in the case and wrap it up. It’s never that easy of course. I pulled the crown stem out to get it back in it’s case and accidentally popped the yoke off it’s place—the yoke a small part that helps hold tension around the stem when changing between winding and time setting. That gave me one more practice run on assembling the calendar works so… hey practice! Wrapping this up I got the dial and hands back on, reapplied the crystal and put on a new strap. I chose this blue leather one because I thought it went really well with the dial. I was able to get the performance improved a lot from losing a minute plus a day to hovering around +/- 3 seconds per day. Also I was able to improve the amplitude a lot even getting over 300º in some measurements.

Really happy with how this turned out. I’m still so new to this hobby and still make all the mistakes you’d expect. It’s really interesting as some times I feel like I’m using similar skills to engineering. I’m reasoning about how things fit together, I’m building up a stack in my head of what connects to what, I’m testing and measuring improvements, and when things go bad I’m in full debugger mode. Watchmaking has become that thing that exercises my love for programming but gets me away from a computer all the time. It’s been so fun to learn and I’m looking forward to what’s next. I’ve been busy on eBay and have given myself quite the backlog.

Do you want to nerd out about watches with me? I have been posting a lot of these photos and videos to Instagram so feel free to reach out there or on Mastodon. I’m still quite new in this but I’m definitely deep in that “I can talk about this for hours” level.

Be a Goldfish

Sun, 02 Feb 2025 19:24:36 -0500

It’s been a bit over 10 years since I first became an engineering manager—minus a couple non-manager roles in the startup world as a lead engineer. That realization and my normal end of year productivity reboot has had me thinking a lot about how I operate outside of the core mechanics of how I do things—namely how I have changed and how things operate in my head. The thing is, I’ve always been really good at dropping work out of my head at the end of the day. Usually only getting stuck on work topics if things are really bad or I’m really perplexed or really upset about something. Something not dropping easily at the end of the day is kind of an indicator for me that I need to change or address it. I’ve been wanting to write about this for awhile but watching Cinema Therapy’s episode on one of my favorite television shows—Ted Lasso—brought the idea back.

You know what the happiest animal on Earth is? It’s a goldfish. It has a 10-second memory. Be a goldfish.

— Ted Lasso (Jason Sudeikis)

January 2025 was a rough month for me—a continuation of an already difficult December where I had my first experience with COVID. Not only were there a lot of really sad and difficult things going on at home but it was a rough time coming back to work. All the excitement for 2025 was suddenly real and … woah we aren’t ready. Large projects need planned, teams need roadmaps, everyone is excited but also frustrated and wanting answers. There were days after long stretches of meetings where I just wanted to curl up and cry. But hey… “Be a goldfish.”. I had to really lean into this. When things are hard it’s super easy to worry on things that you don’t normally worry about.

I’ve worked with a lot of really opinionated engineers who focused so much on their idea that they were often blinded by other ideas. I can remember ending days furious at them. Like “I’ve been doing this too for years, can you at least look at my point of view?”. “Be a goldfish”. I didn’t let it get too deep beyond that first day. Some of those engineers are now good friends.

I recently read the book “Rise” by Patty Azzarello and it was right there too, but worded differently. It tells us “Don’t stay angry” and “Keep moving forward”—isn’t that what a goldfish does? These are obviously more related to how you react to encounters and experiences, but I don’t see why thinking about it like a goldfish is all that different. Someone is abnormally short with you? Maybe they too had a bad day. Be a goldfish.

As engineering managers, we are often faced with scenarios where we think we might have the right answers but almost every time it’s better to work with the team to get there. That can be hard to accept. Sometimes you might think your idea was better and resent the different path. Be a goldfish.

As leaders, we have to make hard decisions and say no to good ideas—often risking uncomfortable conflict or just the knowledge that the team disagrees with a decision. Be a goldfish.

It’s not perfectly applicable to all scenarios—some things do need to be seriously addressed. However, for me I’ve found that most day-to-day challenges, conflicts, disagreements, imposter syndrome feelings, and more have always been good to feel in the moment and evaluate if I need to learn from it or not, but then move forward and be a goldfish.

Barbecue sauce.

Automating LUTs on Video

Mon, 27 May 2024 14:43:58 -0400

My wife and I have worked on our YouTube channel from time to time and one thing that comes up regularly is how we capture video differently. We normally use our iPhones as that’s the sort of best middle ground of good video and convenience. However, I often get fancy and use apps like the new-ish Blackmagic Camera App to record ProRes 422 HQ / Apple Log footage on my iPhone 15 Pro. That’s great and all but a lot of the time, Nat will edit the videos as I’m at work or something. So then she has to color correct the videos and the pipeline just gets really annoying. Of course, I could just stop being so fancy and just record in the camera app with the same settings as her footage. Hmmmmm… should I?

Nah, of course not! I’ll just script away the problem. So I wrote a bash script that takes in my Log profile based footage, applies the LUT Apple provides to bring it back to Rec.709, and also samples it down to regular ProRes 422—to save some space.

First, you’ll need a couple tools. Like I said you need a LUT to apply. Thankfully Apple provides a nice LUT on their developer site—I use the AppleLogToRec709-v1.0.cube option as I’m recording in Apple Log and Rec.709 is good enough for our YouTube purposes. Other LUTs are out there in the community too if you’d prefer something else.

Next you’ll need a tool that can apply this lut to your video. If you haven’t used it, ffmpeg is a tool for working with audio and video and… it is a lot, but it’ll do great for what we need.

$ brew install ffmpeg

Now you just need to run ffmpeg with some settings, provide it the LUT and go. Here’s what the settings I’m using do:

	ffmpeg \
		-hide_banner \   			## Hide command line updates, quiet mode
		-loglevel error \			## Only show errors, I don't want it to be verbose
		-i ${filename} \			## The INPUT file name
		lut3d="lut.cube" \			## Apply the LUT itself
		-c:v prores_ks \			## Encode into ProRes, still want some quality ;)
		-profile:v 2 \				## Lower to ProRes 422, not
		-c:a copy \					## Copy settings in output
		Converted-${filename}		## The OUTPUT file name

Like I said, FFMPEG is a lot, but you can generally get it to do what you need with some tinkering. So with that, I wrapped it up into a nice little script:

#!/bin/bash

# The I'm too fancy script

DIRECTORY=$1
OUTPUT=$2

pushd ${DIRECTORY} > /dev/null

for filename in *; do

	echo "Applying LUT to ${filename}"
	ffmpeg \
		-hide_banner \
		-loglevel error \
		-i ${filename} \
		-vf \
		lut3d="AppleLogToRec709-v1.0.cube" \
		-c:v prores_ks \
		-profile:v 2 \
		-c:a copy \
		${OUTPUT}/Converted-${filename}	
done

popd > /dev/null

Now I can just process the files easily…

$ ./convert ./Input /Users/jnjosh/Desktop/Convert/Output

…and then share the resulting Rec.709 files for editing. I’m sure there is a nice way to do this out there but that wouldn’t be so fun.

So I'm starting another blog about Italian stuff

Sat, 13 Jan 2024 16:48:08 -0500

As little as I blog here it might be a surprise that I’m starting a different blog but here we are. Over the last year, I’ve spent a lot of time learning Italian, learning how to cook Italian, and learning about my family history and genealogy. So much that I just want to talk about it all the time. Most people don’t want to hear me talk about Italy all the time so it’s an outlet. If you want to follow along, check it out!

Permalink

2023: Entertainment Year in Review

Sun, 31 Dec 2023 20:06:48 -0500

I almost forgot to blog this year! It’s now the last minute—9pm on December 31—and the only thing I could think of was to write was a sort of ‘Year in Review’ of the movies, TV, and music I’ve enjoyed this year. It is something I’ve wanted to do before anyway, so why not start the tradition? So if you’ll indulge me here are a few interesting movies, shows, and songs I was entertained by in 2023.

Movies

Well this certainly wasn’t my most busy year watching Movies. I think I watched a lot of TV instead. Still, I was able to watch 52 movies—a few even in Italian.

I rewatched a lot, including going through all the Star Trek films (“Hello, Computer”), rewatching all the Indiana Jones movies, and a bunch of classic movies over Christmas break. Some stand out highlights for me this year were:

“One Hundred Steps” (Italian: “I cento passi”)—a based on a real story about a small town in Sicily. As I’ve been learning Italian I’ve also been trying to learn about modern Italian history. This is one of a few I watched but it had me reading wikipedia about the events it was based on.
“Indiana Jones and the Dial of Destiny”—Say what you want about bringing back another Indy movie after Crystal Skull, but I had a really fun time with this movie. It reminded me of the fun of an Indy movie but didn’t try to hide too much from age. It all culminates in a wild fantastical ending that had me just grinning like a kid. This is a fun movie.
“Millenium”—Not a highlight but really a lowlight. I watched this movie several times when I was a kid and my memory of it was a fascinating time travel story. I rewatched it this year and it’s not a good movie. My memory of it was better. I miss that movie. It’s risky to rewatch movies from childhood.

TV

TV was much more exciting of a year for me. I’ve struggled to remember everything I watched that was really good—probably forgetting something. I wish I kept up with TV like I do movies so I don’t have a cool image like I get from Letterboxd. Still, some notable highlights:

“Last of Us”—I thought I was bored with zombie-based shows after getting tired of The Walking Dead years ago. This however told such a great story—especially the Nick Offerman episode. I rarely listen to making of podcasts but tuned in weekly for this one.
“Foundation”—This show is hard to describe, it’s science fiction spanning generations touching on themes of religion and fascism, but it has me on the edge of my seat. Every season ends with me wanting more.
“Doctor Who”—If you know me you know I’m a whovian. It’s a show that can do anything, anywhere, and anywhen. The 4 specials brought back a Doctor as the 14th doctor and introduced a new 15th doctor. Doctor Who is my deserted island entertainment.
“Star Trek: Picard Season 3”—This show accomplished such a wonderful end to the series. It was able to bring fan service for the story, not just because. It was an unnecessary good bye to the characters but I’m glad I had a chance to see them all again. Only problem was lack of Wesley Crusher!
“Star Trek: Strange New Worlds Season 2”—Some of the most fun I’ve had watching TV this year. It’s fun and challenges the ideas of Star Trek. Plus we got to see Spock sing.
“Guida astrologica per cuori infranti” (“An Astrological Guide for Broken Hearts”)—It’s not a new show this year but we binged it all. On the surface it’s a simple romantic comedy but the characters are so good and fun to watch them go through hijinx. I’ve rewatched it a few times too to practice Italian.
“My Brilliant Friend”—A show about two friends growing up and growing apart. It’s frustrating, maddening, fun, annoying, exciting. I wasn’t expecting to think about this show as much as I have.
“GenV”—The last show I watched of the year. It’s in “The Boys” universe and it shows—this is not a superhero show for kids. It’s so on point with modern life all through the lens of superheros. I’ve never seen a spinoff fit so well into it’s original show while also being its own thing.

Music

As you may have guessed I mostly listened to Italian music this year. In fact here’s a playlist of all my favorites. Some songs I sing along with and get stuck in my head have been:

“L’ultima notte” by ARIETE
“Di Notte” by Ernia, featuring Carl Brave & Sfera Ebbasta
“Ciao Ciao” by La rappresentante di lista
“La musica no c’è” by Coez

Well, that’s a year. I expect next year will be mostly the same, just more Italian and maybe more films.

Why Monorepos?

Thu, 06 Oct 2022 23:27:17 -0400

I really like the idea of “asking a lot of dumb questions to learn fast” and while I don’t think this is a dumb question it’s kind of dumb in that it’s a controversial question on the internet. Maybe I can learn something at least? So here it goes.

Why are so many developers so smitten with monorepos?

What’s a monorepo? From Wikipedia, it’s a “software development strategy where code for many projects is stored in the same repository”. All your different apps, libraries, and utilities are in one large repository, a “shared codebase”. As you can imagine stashing a bunch of disparate projects into one large repository leads to some problems, namely size. This leads to tools like Rush for Javascript developers to help manage the monorepo. A lot of large tech companies, including those I’ve worked with use this. Continuing on Wikipedia we see some benefits:

Ease of code reuse - when all the code is in one big directory you can just reference anyone else’s code (libraries ore even projects) without needing any sort of dependency management or semantic versioning.
Simplified dependency management - Since many projects in the monorepo may depend on similar third-party libraries, they can be optimized and provided consistently by the monorepo.
Atomic commits - When you need to make a large change affecting multiple projects and libraries, you can push it all together without chaining releases. For example, a model change can be made in a library, the frontend, and the backend all in one pull request.
Large-scale code refactoring - Similarly to atomic commits, you can do large refactors across multiple projects in the course of one pull request—making sure everything continues to work as expected after the pull request is merged.
Collaboration across teams - With all projects, owned by different teams, the code ownership model is much more flexible. You can contribute to and receive contributions from other teams.

I’ve spent most of my career working on native software (iOS, macOS, Windows, etc), but did do some web development here and there. I say that because I think I’ve mostly—but not exclusively—seen monorepos coming from web development teams. Maybe that’s why this is such a strange idea to me? I know it’s not quite this bad but it reminds me of development before adopting version control systems where we’d just store the code on a network drive—everything in one directory is easier!

That’s a bit extreme and when I think about this more critically there are some clear benefits, namely atomic commits. One team I worked on we built a distributed codebase where a rich model layer was in it’s own repository. In the early days when a team owned that project, it was great. Contributions were open, but the team aimed to work with the frontend team to make sure their needs were met by the time it was needed. No silos, everyone talked! As things change, that project became ownerless and people just started making changes—forced to do a semantic versioned release for every change. This would be fine if there were many consumers of that library, but there was one client app.

This was a design problem that multiple repos highlighted. A design problem that would have made more sense for it to start in the repository of the client application, and only moved to a separate repo if more applications started using the project. So for a single application, even heavily factored into core components and libraries, I think I’m newly open to that just being one repo. You can still maintain code ownership with Github features, and even publish semantic versions if you want, but can take the benefit of those atomic commits.

Maybe that is my core struggle with this idea. The above project was all one iOS application written in Swift with the occasional Objective-C. Should there be another iOS app in that repo? Should the Android app have been in that repo too? I don’t think so but maybe that’s not just about multiple applications, but also multiple technologies all in one large repo. Maybe this is why web folks like it, when everything is Javascript why draw boundaries!?

Also, what about the rest of those benefits? Anyone can change anything? So you save the effort of managing dependencies by opening up the risk of uncontrolled changes. Friction can be good to a software project. If I look at those benefits again, I could probably talk to why it’s good that you can’t do that or why it’s already possible without putting all your code in one repo. Let’s do it!

Ease of code reuse - It is easier if all the code out there is easily accessible, but is that really what you want? That seems like a very stack overflow copy paste solution to just access any solution provided in the monorepo. I’d rather build on a solid foundation, even at the cost of velocity. You make up for it when the worst happens because you have clearer boundaries to debug.

Simplified dependency management - It is simpler to not have to think about versions, but is that better? Package dependencies are still required for third party tooling so you aren’t avoiding it and at best you are losing out on meaningful semantic versioning allowing you to rollback dependencies easily without having to manage all the commits of an entire repository. Additionally a good framework team can predict needs and work with you to best provide APIs that solve more than just your needs.

Atomic commits - As I noted above, this is a benefit I can get behind, but I don’t know that it’s always what you want in a distributed set of apps and libraries. Friction is good and not everything needs to be hacked together in the same pull request. It can be fine to build the foundations in one library at a specific version, then add support in the app in another repo. I do understand that it’s hard when teams are working with fewer people than they need and there may not be anyone to own that library you need to contribute to.

Large-scale code refactoring - If your project is so coupled that you need to do such large scale refactoring where this is valuable, I wonder if your problem is not the repo but the codebase. Code is a liability, not an asset. I’d rather have a heavily factored set of projects that have clear protocols and when one isn’t meeting needs, replace it. This sounds to me like everything is so interconnected that it’s hard to reason about, so you need to have it all in one folder so you can just unravel the spaghetti.

Collaboration across teams - Multiple repos already provide this sort of collaboration in a more sustainable and arguably responsible way—you just contribute to their repository. I know I know, there is overhead in that in time and velocity, but really shouldn’t we be aiming for sustainability? I know in a monorepo you can still use code ownership to force a team to be required to review pull requests, but that’s not always great. One large pull request could end up requiring dozens of code reviews because you’ve touched multiple teams’s owned code. I know that’s the same with multiple repos, but that’s my point.

I think there is an artificial feeling to this that makes me feel like it’s about perceived speed and velocity, not good software organization. In many of these cases it seems to aim to remove all barriers to any contribution instead of building good foundations.

And I’m not even getting into the massively large size of these monorepos.

So… with all that, I’m starting to come around on it to a point. I do think having all applications in one repo is not worth the tradeoffs. However, I do understand why a large web app would want to be a monorepo with all libraries accessible in the repo—it’s all one stack. I think I also understand a platform as a monorepo as well, those scenarios where the application stack is a platform and apps are built on that platform.

There is a certain reality to it that I understand. Teams and organizations change. Ownership and focus changes. When there is no team to own something, it can very quickly lead to a library or project getting duplicated instead of made a true dependency. These realities open my mind up to it a bit more.

I read somewhere that “Understanding requires effortful engagement” and I think I just did this exercise here. I’m not convinced this is the best path for an organization, but I think I understand it more and maybe would choose to group more projects together—especially if they are all in the goal of shipping a single application in a single technology stack. What do you think? I’d love to continue thinking through this and if you have experiences that talk to monorepos, I’d love to hear. Let’s talk on twitter.

Things 3 as a Kanban board

Sun, 04 Sep 2022 20:38:22 -0400

I’ve written from time to time about productivity on this blog. I definitely think about todo lists and productivity too much and constantly try different things. Earlier this year I went back to paper even just to keep track of all the things I need to do in a day. Well… starting a new job gave me another opportunity to evaluate how I track todos… and I’m back to using Things 3, but in a new way!

Simplicity was my first goal, I don’t want to have to keep tagging things so I simplified down to two tags, “In Progress” meaning I’m currently working on it as you’d expect and “Blocked” meaning I can’t work on it but need to keep it in focus, not just lost back to it’s project or area. This means that my today view has tasks I need to do today, but I can tag them with one of these two tags and remember where I am in the day. This benefits me personally in that I’m very visually distracted and can see another task and think “oh that’s more fun” or “oh that’s easier!”.

This has another big benefit I’ve recently learned with Things. Things allows you to create multiple windows with a different view or set of filters selected. So I can keep a window for Today, and a window for In Progress open. I actually will often have 4 windows open, one with Inbox and one with Today’s Blocked tickets.

The neat thing here is that you can actually treat this as a sort of kanban-board style columns. Dragging a task from Today (filtered to No Tags) to Today (filtered with In Progress) will apply that tag appropriately. Dragging it back to the Today (with No Tags) window or to Blocked will remove tags or add the blocked tag, respectively. This has been really fun for me and requires very little work to maintain.

So I’ll dedicate one space, usually on my laptop monitor (my secondary monitor) to have this “kanban” setup. Then also have an In Progress window on my main window to keep the memory alive for what I’m currently trying to do. When I’m done, I go pick another thing and move it to In Progress.

It’s not perfect, filters will often get removed if there are no tickets in the current view with that tag, so you have to occasionally reset the windows. Also dragging from Blocked to In Progress just applies both tags. Still, it’s been pretty fun to use this way, especially on top of Things really great interface with hot keys and navigation. Let me know on twitter if you’ve done anything like this or have found any other tools that helped you.

Exploring Jetpack Compose

Sun, 11 Jul 2021 18:32:27 +0000

After last month’s adventures into SwiftUI with my little weather app, I thought it would be interesting to recreate the same project, but in Android’s upcoming version of a declarative UI framework, Jetpack Compose. I’m curious how it compares to SwiftUI and what the Android development experience is like in 2021.

I’ve been developing on Apple’s platforms in some form since the early aughts. With the iPhone SDK in 2008 I took it from a side curiosity to my main career. During my time at Two Toasters I started learning a little about Android, did some Android work for our game engine at Highrise, and in 2018 I built an Android app for a client. I found that last experience painful—but I believe this was more about being more accustomed to Apple’s patterns and the nature of a side project.

So… What’s it like now? Is this declarative UI as significant on Android as it seems to be on Apple platforms? I downloaded the arm64 Arctic Fox beta for my M1 MacBook Pro and decided to find out.

Check it out on Github, Kotlin Weather (Swift Weather for reference)!

First thing I noticed is this arm64 build of Android Studio runs pretty well for most of what I needed to do. The emulator itself launched almost immediately. Some of my most painful memories were dealing with launching the emulator—or even paying a lot for a third party emulator. Unfortunately, most of this was beta so I did have to do some shenanigans in Gradle to get all the right versions of compose and the tools I wanted to use. Xcode just includes all that you need to use the new tools without any extra configuration.

Android Studio Arctic Fox Beta and Xcode 13 Beta Side by Side with their respective cell views

The big differences I noticed between SwiftUI and Jetpack Compose are mostly syntactical (VStack = Row, HStack = Column) but in some cases I think Android’s approach is harder to reason about. Now this could be a situation where I just didn’t understand (or it’s still just early). Still, thinking about State and LiveData types seems much more difficult with Compose.

For example, in SwiftUI I can just identify my model as a @StateObject and using @Published I can receive updates.

@StateObject var model: WeatherReportModel

class WeatherReportModel : ObservableObject {
    private let client: OpenWeatherMapServiceClient
    @Published var currentWeather: WeatherReportSectionModel?
    @Published var forecasts = [WeatherReportSectionModel]()
}

This state management can get complicated but a simple example is easily decorated with these property wrappers. I expected Kotlin and its much more expressive annotation system to be better for this kind of thing. Unfortunately, I found it harder to reason about. Eventually I got something working by observing a LiveData in my ViewModel as a Compose State type, but it wasn’t immediately clear what the best pattern here should be. I ended up looking at other sample projects to see what they did. This alone took me down some false starts as the beta-nature of this lead to implementations that aren’t available since last year.

// Set up a mutable live data in my view model
private val weatherCellModel = MutableLiveData<WeatherCellModel>()
val weatherLiveData: LiveData<WeatherCellModel>
	get() = weatherCellModel

// Then later, observe it as state (with null as default)
val report: WeatherCellModel? by model.weatherLiveData.observeAsState(null)

I’m going to keep reading as Compose continues to mature. I’m sure I’m overcomplicating it out of ignorance, but SwiftUI’s method for managing State feels easier to think about.

Once you get all the state dealt with, most of the differences start becoming syntax. SwiftUI expects you to conform to their View struct where Compose is built in a @Composable decorated free function. Both systems use modifiers to change the way a component is displayed.

// Jetpack Compose
Text(
	text = "Hello, World!",
	fontWeight = FontWeight.ExtraBold,
	fontSize = 18.sp,
)

// SwiftUI
Text("Hello, World!")
    .font(.headline)
    .fontWeight(.bold)

Interestingly modifiers in SwiftUI are like builders on the Text object where in Compose, they are parameters. This seems a little funny to me in that Java and Android seems more likely to use that builder pattern.

One last thing that is nice, and similar to SwiftUI’s live view is how your JetPack Compose based functions can be updated and automatically displayed in the emulator. SwiftUI does this too but it’s built in to Xcode—and often is broken in my experience. Many times when working on this Kotlin-based weather app, I’d update layout and switch over to the emulator to find it already running my change.

Is it… the future!?

I think, yes. It reminds me a lot of early SwiftUI and I think seeing how Compose evolves will be fun to watch. I think it will be an important tool for Android development in the future. SwiftUI felt more “ergonomic” to me but that is admittedly biased by my comfort with Apple platforms—not to mention it has had a year or so more to evolve. I guess next I’ll have to build this on React to really see all three major platforms.

Building My Second Brain

Sun, 04 Jul 2021 00:12:57 +0000

You may have noticed lately that I’ve been blogging a bit more regularly. It’s something I’ve always wanted to do with my site but always found reasons not to do it. A lot of times the reasons were just being busy—which is kind of a fake reason. Other times it was I just didn’t know what I wanted to write about. So I’d like to talk a little about what changed in my blogging mindset, what tools I’ve been using, and how I’ve started building a second brain.

What is a Second Brain?

I think way too much about productivity tools. I’m always trying new things and reevaluating what I use. Sometimes it’s a distraction, but it’s often led to new systems that help me get things done. During one of these late night revenge bedtime procrastination sessions I came across this idea of the Second Brain.

The core principle here is a system around the notes you take from books, articles, and videos such that you don’t have to maintain these ideas in your head. By capturing your notes into a system like Roam Research, Obsidian, or Craft you gain the ability focus on connections and building on existing knowledge. All these tools allow you to see connections via backlinks (or in some cases visual graphs).

Next change is how to take notes—which for me was previously in the category of “not good”. I first read about Andy Matuschak’s Evergreen notes. This showed me that taking notes isn’t the point, thinking is. To me that means categorization and tagging is less important than the note itself. Notes that should be atomic units. I’ve recently started reading “How to Take Smart Notes” which goes into similar ideas with the Zettelkasten System. These notes allow me to think, they allow me to see connections, they gave me the realization that writing is thinking.

The Zettelkasten System talks about three types of notes. Fleeting notes are singular thoughts you have that come up at any time, permanent notes are those that have been formally written with connections to other notes, and project notes are those notes written about a specific project. It also uses notes that are literature references and slip boxes (Zettelkasten is German for “slip of paper box”).

Let’s look at what I’m currently doing.

How I’m Taking Notes and Creating More

Of the tools I mentioned above, I’ve been using Craft (it’s a beautiful and native app) for capturing these notes and connections. I’m also using Things 3 as a system for both capturing new ideas and planning tasks I want to do.

I start with something like fleeting notes, if something comes up during the day I’ll add a note in my Things 3 inbox to think more about it later. If I decide to turn it into a note, I’ll move it into Craft’s inbox and within the next week, I’ll migrate it to a permanent note in my “Note Box” folder. Here I try to be brutal about the ideas and only add them if they either expand some knowledge I have notes for or something I want to build on. The point isn’t to have hundreds of notes I never see but to build on what I know or what I want to know.

Next when reading books, articles, or videos I create a document in Craft’s inbox that is a sort of bulleted feed of things that surprised me or caused me to think. If a thought is something I want to capture, I’ll make it a fleeting note in the inbox as well—but link to it in the document. When finished consuming the content I move it to an “Input” folder in Craft. Understanding requires effortful engagement and this engagement has had me focusing on what I want to capture from an article.

Finally when I think I have enough about some topic to talk about I’ll schedule a blog post in my Things area for my blog—I try to plan for the next 3–5 posts so I have time to write code if needed. This engagement in these ideas have given me more ideas about what I want to write about and kept me excited about learning more about the topic such that I can create something interesting. Then I write my blog post in Craft itself, linking to all the notes that informed it and storing it in an “Output” folder.

Will it Keep Working?

I don’t know! My track record here isn’t great—this could be my last blog post until next year when I’m reminded that I want to blog again. I hope not and this system has given me the best framework to organize my thinking, plan for what I want to learn, and start to create more. I’m still learning about good note taking, Zettelkasten, and second brain. Let me know on twitter if you’ve done anything like this or have found any other tools that helped you.

Designing Interviews for Engineers

Sun, 27 Jun 2021 18:44:58 +0000

Interviewing is hard and there are a lot of problems in the industry and the processes that we use. A lot of companies rely on a half to full day interview cycle to both get an idea of the candidate’s skills/fit and give the candidate an idea of what your team is about. 4–5 hours is hard to give both employer and candidate a complete picture of what it’s like to work on this team.

I think about this too much probably and I think we as an industry can do better at hiring engineers. When I was at Highrise I worked a lot to help rebuild our system for hiring and as a hiring manager in my current role, I’m continuing to think how to best do this.

I think we all know the answer in a perfect world. Design the interview for each candidate. This is hard of course because this kind of due diligence in hiring takes time and time is the thing hiring managers often lack.

I think we can have this though. I think we can build a system that allows us to do this due diligence, but also is a system we can rely on to design it in our busy schedules. My current thinking on interviewing has grown from two key tenets.

It’s the hiring manager’s job to guide and design an interview for each candidate.
There should be a source of truth that anyone on an interview team can use to know the background of the candidate, the plan for the interview, and the expectations for each interviewer.

Let’s dive into this a bit more.

It’s the hiring manager’s job to design the interview

As former engineers, we engineering managers want to build systems that can be easily relied on. Unfortunately, this leads to many hiring managers applying the same interview to every candidate as if it’s a function where the input is the new candidate and the output is a true/false decision on if they “fit” and have the skills. It often goes something like: let’s have the candidate do several leetcode challenges, give them a few trick or clever questions, and use our guts to determine if they are a good candidate.

This is very subjective and it doesn’t really take into account that people have different backgrounds and experiences.

People can be anxious or just distracted in an interview. Building a system that tests them on areas that aren’t what they would do from day to day and trying to trick them or test them under stress leads to false results. In fact this just builds on those anxieties.

Instead let’s try to do better. Let’s try to use what we know about the candidate to design an interview for them that best answers the questions of “should we hire them?” and “what’s it like to work with them?”. You or someone on your team has likely done an initial screening call with them. Assuming you want to move to the next step, ask questions about what you know from that call or from their resume.

They were really strong with architecture but didn’t really talk much about testing. Are they a good tester?
They had some really good fundamentals but their designs were not clear or too clever. How would they build an architecture with your business’ challenges?
They were heads down and finished every challenge during the screening but they didn’t talk at all. How would they communicate with the rest of the team or non-technical stakeholders?

These questions can inform what to do next. They help you design the best interview for the candidate. Here’s where you can start relying on systems. Build yourself a library of projects that can be sorted by “focus area” and “level”. Then add some common questions for each project and what you’d expect to see from candidates when given the project. This takes work but it can be reused for a long time.

These projects should be specific to the type of work your team does—think about having the candidate build a UI with a similar spec to what your team uses instead of general algorithm questions. You can bake the algorithm problem into the project’s goals of course, but it alone is not the point. Then for each project give it a general focus area and level.

The best projects are more closely related to your business, but some vague examples could be:

- Build an image app that downloads results from flickr and displays them.
	- Focus Area UIKit, Networking, API
	- Level: Software Engineer II–Senior Engineer
	- Common Questions and Notes:
		- Do they properly separate concerns between API functionality and UI?
		- Do they communicate about how they want to build it and work with you
		  or just go heads down?
		- If they breeze through this section move on to either unit testing 
		  or more architectural questions about their implementation.
- Implement a framework for providing autocomplete search results 
  from the Github API
	- Focus Area: Architecture, API Design
	- Level: Senior Engineer–Staff Engineer
	- Common Questions and Notes:
		- How did they approach their access to components? 
		- Is their design a pass through to the API or something more modeled 
		  to the problem? How would they improve it?

You can prep projects to help get them started—you only have an hour and seeing people set up a project isn’t always the most valuable use of time. Then share it with them at the beginning of the interview or earlier if your company utilizes take home projects. All of these also give you the opportunity to see how they work with the tools you use daily.

Building a library like this gives you many different focus areas that you can plug in to best determine this candidate’s skill level, communication level, and what it’s like to work with them. Further, by designing this for each candidate you have fewer chances of getting to a debrief and not knowing if you should hire or not.

This does take some work to set up but once you have a basic process it’s really not a heavy lift. In my experience, I’ll review all the notes for a candidate and come up with a basic interview panel in as little as 10–15 minutes. You are responsible for bringing this individual on to your team and the cost of making bad decisions is high, it’s worth taking at least a little time to think through each candidate. You are the hiring manager.

Source of Truth for the Interview Plan

Now that you have built a plan for this new candidate, you need to make sure everyone on your team understands it and knows what to expect. Relying on everyone to just decide what to do during the interview leads to unanswered questions and duplicated work—which just makes you look like not a good company to join.

To avoid this I’ve started creating what I call a “prebrief” document. This is a simple document that:

Links to all information about the candidate—their resume, previous notes from screenings, your company’s internal expectations for the relevant career level, or any other relavant data about the role or candidate.
I’m mixed on this section, but I like to include a “tl;dr” section of the above information that summarizes the data you’ve seen so far. Some care needs to be taken here to be void of any opinions—keep it focused on the data and don’t accidentally give people your opinions on the candidate. Your team is also busy so giving them a brief they can quickly glance at helps everyone be more prepared.
A brief schedule for each person on the panel with their focus area and highlights to look out for.

A Sample Prebrief Document

Now set up a brief call with your team—can be as little as 15 minutes—to go over each person’s role in the panel and aim for clarity. Each person should know what they are looking for in the interview and can give the candidate a quick agenda of what to expect.

Summary

These two tenets have helped me build better interviews on my teams from start-ups to large businesses. It’s helped me better communicate with all the people I’m expecting to help me decide on hiring and the added clarity creates a better environment for candidates—they are told what to expect, have interviews that actually challenge them where they are, and they don’t have the same question 3 times.

What do you think? Let me know on twitter. I’m constantly interested in learning how other people solve these problems so I’d love to hear what your team does.

A Swift Time Capsule

Sun, 20 Jun 2021 23:47:11 +0000

A while back I got into an argument with a friend about the lifetime of code “now days”. He argued that code written in C and C++ was much more likely to continue working forever, needing fewer updates, and being generally more of an asset. My response was generally “code is a liability, not an asset”. We should strive to create good code, but too much changes in the industry year to year and you’ll eventually need to replace it with new tools and environments—at least for most consumer facing apps.

We are 7 years into this new Swift adventure—which kind of proves my point above, we should be migrating from Objective-C to Swift as it’s better in almost every way. That hurts a lot to say but it’s true. However, I’m wondering if my friend was right to some extent. Swift today is not Swift of 2014 and had you been an early adopter, you would have had a lot of migrating to do.

I was curious lately how much has changed since the beginning and found a project I had worked on back in 2014—with a small update for Swift 1.2 in 2015. The project is to basically consume weather from a public API and display it—a super small representation of what most apps I’ve worked on contain. I downloaded a fresh copy of Xcode 13 and opened it up! So how did it change?

Check it out, Swift Weather!

Opening the Time Capsule

Of course, I was immediately prompted with “WeatherApp contains source code developed with Swift 3.x” and I’d need to migrate to Swift 4. Of course I was opening a Swift 1.2 project and have no interest in stopping at Swift 4, so let’s continue.

Oh… well I guess I can’t really go on. FIrst thing is obviously this app could not run as it targeted iOS 8 and iOS 9 is as far back as Xcode 13 cares to think about. However, the real problem was I decided to use a custom JSON parsing system (this was all before Codable!). Runes and Argo were used with this incredibly expressive syntax that I did not completely forget about. /sarcasm.

static func decode(json: JSONValue) -> Forecast? {
    return Forecast.create
        <^> json <||? "list"
}

So I didn’t really want to unravel that mess. Since most the UI stuff would be needing a rewrite in SwiftUI and I now have access to Codable I thought I’d just start from scratch on this project.

Before continuing, one feature of early Swift that I thought was interesting was method currying. This allowed you to treat a function with multiple arguments as a sequence of functions. It was removed in (I think) Swift 3? I still think it’s neat, but it’s probably for the best to remove it.

static func create(kelvin: Double?)(city: String?) -> WeatherItem {
    return WeatherItem(kelvin: kelvin, city: city)
}

A Whole New World

I deleted everything and just started from scratch. I knew that the API and Parsing side of this would be rewritten with URLSession and Codable structs and I’d want to build a new UI with SwiftUI—something I’ve had little time to work with over the last couple years.

The first thing I noticed? A new App Project is very simple. It contains the project, a WeatherApp.swift, an Assets bundle, and a ContentView.swift. It appears the Info.plist has been moved to be shown as part of the project.

Building the new API stuff was much better, Codable is a nice system. The real update was switching from blocks to async functions available with Swift 5.5. That turned my old Objective-C era mindset fetchWeather function into a much easier function to reason about. It went from this…

func fetchWeatherWithLatitude(latitude: Double, longitude: Double, completion:((WeatherItem?) -> Void)!) {
	let URLString = baseURLString.stringByAppendingFormat(weatherPathFormat, latitude, longitude)
	
	if let URL = NSURL(string: URLString) {
		let request = NSURLRequest(URL: URL)
		
		NSURLConnection.sendAsynchronousRequest(request, queue: queue, completionHandler: {
			(response: NSURLResponse!, data: NSData!, error: NSError!) -> Void in
			
			if response == nil {
				completion(nil)
				return;
			}
			
			var jsonError: NSError? = nil
			if let result: AnyObject = NSJSONSerialization.JSONObjectWithData(data, options: NSJSONReadingOptions(0), error: &jsonError) {
				dispatch_async(dispatch_get_main_queue(), {
					let value = JSONValue.parse(result)
					let item = WeatherItem.decode(value)
					completion(item)
				})
			}
		})
	}
}

… into something much more clear.

func weather(latitude: Double, longitude: Double) async throws -> WeatherReport {
	let request = try weatherRequest(forEndpoint: .current,
									 latitude: latitude,
									 longitude: longitude,
									 apiKey: self.apiKey)
	let (data, _) = try await URLSession.shared.data(for: request)
	guard let report = try? JSONDecoder().decode(WeatherReport.self, from: data) else {
		throw WeatherServiceError.decodingFailure
	}
	return report
}

Now I can leave behind not only all the pre-URLSession and pre-Codable world, but more importantly I can leave behind the strange code flow we all lived with under the call-callback structure.

The other big thing is of course, SwiftUI. It took me a little bit to think through how to structure things with a pure-SwiftUI project—and I probably have a lot to learn still—but it’s so much more easy to read and reason about than the older style. I learned to read that through experience, SwiftUI code I could probably show non-tech people and they could read it. Also it simplifies things a lot.

struct ContentView : View {
    @StateObject var model: WeatherReportModel


    private func updateWeatherResults() {
        model.fetchAllReports(location: CLLocationCoordinate2D(
            latitude: 35.9940,
            longitude: -78.8986)
        )
    }

    
    var body: some View {
        NavigationView {
			List {
				if let weatherReport = model.currentWeather {
					WeatherForecastSectionView(
						forecast: weatherReport,
						isCurrent: true
					)
				}
				ForEach(model.forecasts) { forecast in
					WeatherForecastSectionView(
						forecast: forecast
					)
				}
			}
			.navigationTitle("Swift Weather")
			.listStyle(.sidebar)
        }
        .refreshable { updateWeatherResults() }
        .task { updateWeatherResults() }
    }
}

That last bit there with .refreshable { … } is a new feature in SwiftUI that’ll automatically add a UIRefreshControl to your UI. So nice.

Summary

In the end, it’s not less code—actually CLOC reports it’s about the same amount of code (I did format a lot of multiline inits, though). The interesting thing is not that the lines of code are smaller however, but that the code is more easy to reason about and read. At least I hope so. I’ll have to put it back in the time capsule and come back in 2028 to see how things worked out.

I still think code is not something you should treat like an asset. You should do your best with what you know but be ready to move forward. This little experiment showed me that moving forward can be good, Codable and async/await alone show this.

What do you think? Let me know on twitter or feel free to look through the WeatherApp sample project and play around with it.

Patterns with Swift Concurrency in new APIs

Sun, 13 Jun 2021 21:39:04 -0400

I’ve watched a lot of this year’s WWDC sessions—like over 30 this weekend. This year just seemed to be really interesting and I’ve really enjoyed many of the videos. Also, I’m super excited about DocC and can’t wait to start building better documentation!

One thing has been bugging me. After watching Meet async/await in Swift, Meet MusicKit for Swift and Meet StoreKit 2 sessions I started noticing an interesting difference in patterns in use with Swift Concurrency. So far I’ve seen 3 different patterns.

Pattern 1: The ol’ fetch me a response with this request pattern

This seems the most common pattern I’ve seen and what I’d probably naturally do when building something that supports the new language features.

let (data, response) = try await URLSession.shared.data(with: request)

Passing a request to a data task will eventually result in a response. This seems the most abstracted where a request describes the request itself but the data task asynchronously fetches the data and responds.

Pattern 2: The request gives you the response pattern

This was the first time I had the thought that the patterns were different. While watching the Meet MusicKit for Swift session they reviewed the new API for MusicCatalogSearchRequest.

func response() async throws -> MusicCatalogSearchResponse

So when using this you’d be asking the request itself to asynchronously fetch a response.

let album = try await albumRequest.response()

This seems to blur the lines of what responsibilities requests have. Typically I wouldn’t think of a request being the facilitator of it’s own response.

Pattern 3: The static function request

Later while watching the Meet StoreKit 2 session I noticed another pattern, request directly associated as a static method on Product.

static func request(with identifiers: Set<String>) async throws -> [Product]

Leading to a fetch of products like this:

let products = try await Product.request(with: identifiers)

In my limited experience with Ruby on Rails, this reminds me of the patterns there for some reason. The type itself knows how to find instances of itself given some search criteria. This probably reads the nicest and is maybe the most ergonomic but it means a lot of the fetching behavior is owned by the Product type itself or an extension.

So… what’s the point?

I find it interesting that with this new push for Swift Concurrency there isn’t a clear pattern that Apple recommends. Apple has often had strange APIs that come out of nowhere in the past—I’m looking at you CAMediaTimingFunction’s initWithControlPoints::::. However, this seems to be a bit more fundamental. Maybe it’s an artifact of many teams doing different things then all trying to get something ready for Swift Concurrency? Maybe it really doesn’t matter and I’m over thinking it? Maybe there are good reasons I’m not seeing in the public interface for these different APIs to use different patterns? I don’t know, but I’m interested to see what the community adopts, if anything.

What is a good pattern?

Patterns are mostly important as a means of consistency and convention, so I’m not going to over index on what is right. It’s way too easy to look at a public interface and judge it harshly.

For me, that initial pattern as shown in the URLSession example makes the most sense. Here you have a clear request type that can declare the request’s parameters and potentially be reusable, a response type, and a task type that owns the actual async work.

Saying Goodbye to Triangle Cocoa

Sun, 03 May 2020 15:28:26 -0400

Organizing Triangle Cocoa—CocoaHeads and NSCoder Nights—changed my life. My career was mostly focused on .NET programming for AutoCAD and I dabbled with Mac programming on the side. When the iPhone SDK was released I fell in love with it. I started learning as soon as it was possible—I went from dabbling to “taking it seriously”. There was a lot struggle in learning alone, none of my coworkers knew anything about Apple platforms and there wasn’t as much content out there as there is today.

Eleven years later–my career has changed, I’m a better engineer, and I’ve found a network of friends and mentors. Not to mention I’ve been a speaker at several conferences and even other meetups. After all this time, I’ve decided to move on as the organizer and find someone else to guide the group’s future.

Early on the struggle to understand Cocoa Touch with a few hours on nights and weekends was a challenge. I started listening to other developers in the industry via podcasting, twitter, and other local meetups. After attending NSConf in Atlanta in early 2010, I was convinced I wanted to start a CocoaHeads chapter (so we could talk about Mac dev too!). Throughout 2010 I tried several times to get it moving and had little success. Adding it to meetup.com in early 2011 helped it really start to grow.

Over the years we’ve had so many great meetings—check out the historical repo that lists all the CocoaHeads meetings and their talks. We’ve also had an NSCoder Night going for most of this time too. Over 800 members and 726 events in 10 years! In this time we’ve had meetings with as many as 60 people, a talk from the founder of CocoaHeads, and once as a group were able to outvote other, bigger, cities to draw CocoaConf to Raleigh.

The biggest CocoaHeads we've ever had. We had over 60 people that month and we had a talk from the founder of CocoaHeads.

So why stop? Early on information about Cocoa was not as wide-spread. I had such a great time at that conference I asked myself, “what if we had a conference every month?”. This “vision” of what CocoaHeads could be was a driving force in making sure there was content for beginners and advanced engineers. I really wanted to create a community that welcomed everyone. I think I succeeded. However, nowadays there is so much content out there online I’ve struggled with what my driving “vision” for the meetup would be. The answer has been, “I don’t know”. I had to ask myself a new question, “Should someone else take ownership of this meetup?”.

The answer to that question is “Yes”. I’ve done this for over 10 years and it’s time for someone else to find their vision—assuming someone will take it over. I emailed the group and heard nothing besides a lot of much appreciated “thank you"s from many of my friends. Then surprisingly at the 11th hour, someone decided to step up and take the meeting. I hope they can continue it and hope for the best.

Thank you to everyone who took the time to help organize the meetings, speak, help others, and everyone who just attended meetings. You all made this one of the best groups I’ve ever attended. You’ve also helped make this a great community that continues with or without the meetup.

Triangle Cocoa changed my life for the better. If you are considering organizing a meetup in your community I highly recommend it. You learn so much about how to be a leader, how to be a better contributor, and how to communicate with people. You also will make a lot of new friends.

Another System for Productivity

Sun, 29 Sep 2019 16:47:34 -0400

It‘s been at least two years since I last wrote about TODO lists and I‘ve tried several different options from going back to the Bullet Journal, trying OmniFocus again, to using Agenda for notes and todos. Through all this I still wasn’t feeling like I found a great system and easily could convince myself to ignore a todo or have to do weird things like moving tasks when I couldn’t get to them in a day. I think I’ve found a new system for the long term.

I wrote about Things last year and it‘s no surprise to me that I went back to it. I love OmniFocus too but it‘s largely overkill for what I need and required too much management. Things is simple and powerful enough to do almost everything I want and provides a cool visualization to show the progress of a project.

It‘s not Things 3 alone that is a part of this new system. I learned a new way to prioritize tasks for myself such that I can make good decisions about what I should be doing. It starts with a mindmap. Every week or just occasionally, I‘ll have a brain dump to get as many tasks down on paper. In my case I use Notability on my iPad Pro and write out a basic mind map of tasks.

It actually really helps me to do it in this format because I enjoy the writing—and drawing. This format also really helps me expand tasks that are related and expand out the map to more tasks that I might have forgotten.

Now that I have all these things listed out the next step is to prioritize. I‘d known about the four quadrant method for years—I think it‘s called the Eisenhower method. Recently I learned about a 9-space grid. It’s effectively the same idea though. On one axis the urgency increases, and on the other axis value. For example the top-left quadrant contains items that are high value and very urgent. I still end up using the 4 quadrant method but I think seeing it in context of the 9 grid is really helpful.

Next I‘ll do my best to prioritize everything on the mind map. This helps me think about relationships or dependencies between tasks and think about both how valuable/urgent they are. Sometimes it helps writing it into the 9-grid but I’ve found over time—and my use of the 4-grid instead—I can just as easily rate everything on a 1-4 scale.

Here‘s where Things 3 comes into the picture. I follow some simple rules that helps this all stay together. I create “Areas” for each portion of my life. Most importantly I‘ll have one called “Self” and several for the other areas. Note these aren’t “Projects”. I define an Area as something that can contain Projects or individual tasks. As an example, the “Work” area may have a project like “Release v1.2” or individual task like “Set up meeting with Joe”. I don’t ever create projects like “Misc”, a project is defined as something that can be completed, all other tasks just live in the area itself.

Now how do I apply the prioritization? Tags. Things 3 has a nice tag system and you can add a tag with some hot keys like ctrl + 1. This is especially great since I prioritize these by 1-4. This means new tasks can be immediately prioritized when I create a task. This is one of the key things to me. Even though I love the above method for brain dumping, I get new tasks or ideas all throughout the day. This tag system means I can give an immediate prioritization and even a target day to work on it.

Finally this all comes back to the day to day. Every morning I look through each of my projects and determine if I can work on it today or not. Now I have a list of todos that need to happen today. This crosses across all areas of my life. It‘s the source of truth of what I need to do.

Things 3 also allows you to filter a view by tag. Since tags represent priority, I can choose to only see those urgent high value tasks when I have high energy, and choose less urgent tasks when I’m lower on energy.

This all seems like a lot. It‘s not really. The brain dump only happens when there are a significant number of tasks. Otherwise, I just add things as they come up. This creates a system that is easy to manage and not overwhelming. This helps me keep up with tasks more. Also, individual projects get a nice little progress indicator which helps me see at a glance how they are doing. For me a system has to be extremely simple to reason about and easy to manage. Otherwise, I‘m incredibly capable of avoiding the work of managing my time and allow myself to focus on things that aren‘t as valuable. I‘ve been doing this now for a few weeks and it‘s going well. I can‘t say it‘s the final system I‘ll use but I think it‘s the most likely going to stick around for some time.

Cross Platform Thoughts

Sun, 18 Aug 2019 12:27:06 -0500

Cross Platform development for most mobile apps is just simply not worth it. Sure, there are great open source options like React Native and just plain C++ but you end up spending the same time trying to be clever and “share code” when you could have just built your product with all the platform has to offer. There seems to be a lot of realizations this year with Dropbox dropping their C++ components and last year Airbnb sunsetting React Native components. I’ve played this game before and while it was a great challenge, I would advise anyone not to do it for most cases.

Back in 2017 I joined the Highrise team as the Lead Mobile Engineer and one of the first decisions we needed to make was: what is the future of our game and how could we create it so that it could live on Android?

Highrise is unique in that it’s both an app and a game. We quickly explored some cross platform options for making the game components like Unreal, Unity, libGDX, etc. These options seemed great for the parts of the app that were a game but not so great for the standard app components. We’d end up having “crappy Game UI”™ which was explicitly something we did not want. We wanted the app to feel as good as Instagram or any Apple app when not in game-based UIs. I proposed the best path as either “let’s not be clever and just make the app twice” or “let’s build the game components in a shared C++ layer and the app components natively”. I had done this previously when working on BA3’s mapping engine and felt this could be a great solution for our problem. We could write the hard game-based code once and write specific UIs for each platform. I shared this at local meetups as cross platform shenanigans.

You know what? It was actually pretty fun! We ended up with an extra platform, C++, and a lot of bridging code in Objective-C++ (and JNI-based C for Android) and had to make a lot of calls on how we’d communicate game events between the UI and core layers. We worked with Flatbuffers which gave us simple data to pass around. We now had a platform that we could build on top of, we had a core layer that was compatible with multiple platforms, and we had a UI layer that would not be foreign to most iOS or Android developers. I’d even go as far as saying if you are building a game, this is probably the best way to get cross platform game logic while not sacrificing a great app experience.

Would I do it again? No.

The thing is we really didn’t save much time. Most features ended up being full stack features so we couldn’t isolate a developer from the Core as much as we wanted. This meant that we had to expose bridge objects going both ways—which is not a simple problem—for most features. We also had to deal with many layers of abstraction making things like simple networking much harder to debug. In the end, we spent about the same amount of time as if we had just built the app for each platform. We could have even saved some time when you consider we could us one platform as a guide to build the other platform and not fight issues that worked well in one platform and not on the other.

One of the first things I teach new developers is “don’t fight the platform”. Instead of trying to be clever and solving your too many platforms problem by adding another platform, just build your app simply. Build in Swift with all that Apple offers or build in Kotlin with all that Google offers. You’ll appreciate the simplicity of it when you have to debug any issue. You may have to think a little bit harder to coordinate releases between the platforms, but that is a far simpler problem than trying to build something that works great on whatever platform it runs on. I’ve since moved on from Highrise and BA3, but one lesson I’ll take with me is don’t try to be too clever.

On Hiring at Highrise

Sat, 31 Mar 2018 19:24:55 -0400

Late last year at Highrise we were working on hiring a new server engineer for our team. We weren’t really clear what we were looking for and different parts of the team had different ideas about the ideal candidate. I worked with the team to overhaul our system to create a better process for choosing candidates. Last week Gusto published an article about our system which is a really great write-up about our system.

Permalink

Debugging with Sound

Thu, 08 Feb 2018 22:27:06 -0500

Debugging is hard. You have to remember what you or someone else was trying to do while understanding what’s actually going on. I don’t remember where I heard it, but there is a saying that goes something like “Don’t write code at the peak of your understanding because debugging it requires 2 times the understanding…”. Sometimes it’s not that it’s hard it’s that there is just too much going on. For these cases, I’ve been using sound.

One case where this comes in handy is debugging a network call and cache hit. Imagine you are building a system that checks an in-memory cache, an on-disk cache, and a download operation. You’ve probably done this several times. Debugging this is hard because you really don’t want to stop, you want to know that it’s hitting all the different points appropriately. Sure logging is fine here, but that’s prone to confusion if you have a noisy log. What I find helpful when debugging things like this—or any type of retain/release pattern—is to add a sound-based break point.

Now I don’t have to study and read, I just use the app and listen. If I hear a Ping, a Funk, and a Frog sound when I’m expecting it—I know I’m on the right track. The great thing is you also don’t have to stop the debug session, you can simply add these while debugging.

I think this is a great tool and it’s kind of fun! I don’t use it all the time but every once in a while I find something that fits this debugging tool well. Then I can listen to my code instead of reading it.

Calling Kotlin from C++

Mon, 05 Feb 2018 23:37:13 -0500

At Highrise we’ve been building the future of our platform in a way that supports Android. We’ve put together a stack that is pretty challenging but really fun to build. It’s based on a C++ core and platform specific projects in Swift (for iOS) and Kotlin (for Android) that uses that core. On Swift you need to have an Objective-C++ wrapper for Swift to call functionality in the C++ core, but it’s pretty straightforward and things like wrapping a block in an std::function works pretty well. Android however runs on the JVM and requires using JNI to communicate with C++. This took away the niceness of Kotlin lambdas for asynchronous completion away from us. Or did it?

I first tried to pass a kotlin lambda to the core and wasn’t able to make it work. My fallback was to create a convention of well-defined callbacks. For example, a call to ‘loginUser’ would result, eventually, in a call to ‘callbackLoginUser’. This required a lot of overhead because of how JNI works. For each callback-prefixed function I had to build an interface that hard-coded the java parameter code, the method, and the class.

 static JniMethodInfo callbackLoginUserMethod() {
     JniMethodInfo callbackInfo;
     JniHelper::getMethodInfo(callbackInfo,
                              "com/app/android/Login",
                              "callbackLoginUser",
                              "(ZLjava/lang/String;)V");
     return callbackInfo;
 }

 static void callbackLoginUser(jobject object, 
 					    	   bool succeeded, 
 					    	   std::string errorMessage) {
     auto info = callbackLoginUserMethod();
     auto errorString = info.env->NewStringUTF(errorMessage.c_str());
     info.env->CallVoidMethod(object, info.methodID, succeeded, errorString);
     info.env->DeleteGlobalRef(object);
 }

These are basically helper methods to hide the boilerplate JNI code behind a simple function call. It works and is easy to reason about since we created a common convention. That said, I couldn’t stop thinking about being able to use kotlin lambdas. Of course, the idea came to me on the drive home.

First thing I thought was since everything in Java (and Kotlin) are objects, a lambda must also be a class that gets generated in the JVM. After a little study, it does!

 val completion: (Boolean, String) -> Unit = { success, value ->
 	println("$value -> $success")
 }

For example that code becomes a class is created with a name like: com.app.android.Login$loginUser$completion$1. And an invoke function with the right params is created: invoke(boolean, java.lang.String). With this knowledge I just had to figure out how to actually call the invoke function, which was pretty clear with all the boilerplate JNI I had written.

First I needed to acquire the name of the class. JNI functions are basically C functions that you need to manage, so the lambda shows up on the C++ side as a jobject. The matching JNI function will receive a jobject instance of the lambda.

 // In Login.kt, identify the kotlin external function that will call to C++
 private external fun nativeLoginUser(completion: ((Boolean, String) -> Unit))

 // In Login.cpp, define the C function that will be matched with the above
 // external function.
 JNIEXPORT
 void Java_com_app_android_Login_nativeLoginUser(JNIEnv *environment, 
 												 jobject thiz, 
 												 jobject completion) {
 	//…
 }

The first task will be to identify the generated class of this completion object.

 JNIEXPORT
 void Java_com_app_android_Login_nativeLoginUser(JNIEnv *environment, 
 												 jobject thiz, 
 												 jobject completion) {
	jclass klass = environment->GetObjectClass(completion);
    jmethodID classMethodId = environment->GetMethodID(klass, 
    												   "getClass", 
    												   "()Ljava/lang/Class;");
    jobject klassObj = environment->CallObjectMethod(completion, classMethodId);

    auto klassObject = environment->GetObjectClass(klassObj);
    auto nameMethodId = environment->GetMethodID(klassObject, 
    	                                         "getName", 
    	                                         "()Ljava/lang/String;");
    jstring classString = (jstring)environment->CallObjectMethod(klassObj, 
    														     nameMethodId);

    auto className = environment->GetStringUTFChars(classString, NULL);

    //…
 }

Now that we know what class we are communicating with, we’ll need to find the invoke method. This part is still a bit hard-coded, unfortunately. You have to provide a param code that matches tha actual method signature. Something like “(ZLjava/lang/String;)V”. This translates Z to Boolean, L to java/lang/String, and V to Void. This matches the signature of the lambda (except for that Unit type, which I don’t fully understand). Using the JniHelper class that comes with Cocos2d-X I can get that method information. Finally I can call the method on the specified object with the vargs of the arguments to send.

 JNIEXPORT
 void Java_com_app_android_Login_nativeLoginUser(JNIEnv *environment, 
 												 jobject thiz, 
 												 jobject completion) {
	// Get `className` (above)

    JniMethodInfo invokeMethod;
    JniHelper::getMethodInfo(invokeMethod,
                             className,
                             "invoke",
                             "(ZLjava/lang/String;)V");

    jstring message = JniHelper::getEnv()->NewStringUTF("Success!");
    invokeMethod.env->CallVoidMethod(completion, 
    								 invokeMethod.methodID, 
    								 true, 
    								 message);
    environment->ReleaseStringUTFChars(classNameString, className);
 }

Finally, in Kotlin I can simply add a new function that calls the native/external C++ function with the lambda.

 private external fun nativeLoginUser(completion: ((Boolean, String) -> Unit))
 fun loginUser() {
    nativeLoginUser({ success, value ->
        if (success) {
            println("Yes!")
        }
        println(value)
    })
 }

There is a lot I didn’t cover here like releasing objects properly and getting a global reference to objects that you may need to wait for asynchronous callback. That’s all JNI specific stuff and it, unfortunately, takes a lot of trial and error to work out. I’m also not totally happy with the way the param code is hard coded. I think I could probably generate the param string from the Kotlin side and pass that with the block. It’s not ideal but still better than the convention-based method. Have you done this? I’d love to hear your experiences!

On using Things 3

Mon, 05 Feb 2018 11:45:14 -0500

I really enjoyed this post about using Things 3. I’ve been using it off and on since last year but this post has already changed how I structure my projects. The funny thing is I now have more areas and projects but I don’t feel as overloaded as when I had a more dense hierarchy. I previously had projects children of companies or bigger contexts. Now projects have their own area.

Permalink

Static Blog Automation

Fri, 19 Jan 2018 00:11:12 -0500

As I’ve written about in the past this blog is powered by Hugo—a static site generator. That’s great and all but it really limits when I can write posts. Something running Hugo needs to build the site and that output needs to be published somewhere. I’ve done a few things to make this process a more automatic.

Writing Posts on my MacBook Pro

First of all I needed to make it much easier to create a new post. My theme has three types of post content and it’s not easy to remember which command I need to do the right type of post. To solve this I created some simple bash scripts to help out.

function newmicropost() {
    local date=`date +%Y-%m-%d-%H%M%S`
    local file="microposts/${date}.md"
    hugo new ${file} | cut -d ' ' -f 1 | xargs subl 
}

// $1 The name of the file to create
function newpost() {
    hugo new "posts/$1.md" | cut -d ' ' -f 1 | xargs subl
}

// $1 The name of the file to create
function newphotopost() {
	hugo new "photos/$1.md" | cut -d ' ' -f 1 | xargs subl
}

This is really great when I want to publish a Micro.blog post about some idea that pops up while working. I’m already in the terminal normally so jumping to my blog directory and typing newmicropost is pretty quick.

Writing Posts on my iPad or iPhone

This is a bit more difficult and I’m still working out how to best do this. The biggest key was to not have to run Hugo myself. Offloading that task (and hosting) to Netlify powered by a Github webhook means I can create and publish from any device simply by commiting to Github.

An app like Working Copy or Clone makes this possible. It’s admittedly a bit of a chore to post from the iPhone because you have to not only create the markdown file in the right place, but also create the correct front matter so that Hugo can properly generate your page. My current process is to write a post in Ulysses, where I have a document with all the expected front matter. Then when I am ready to publish I copy that over to Working Copy and push a commit.

I’d like this all to be better. I’m really interested in what others have done here. I love having a static website, but the nature of it puts a pretty nasty obstacle in my way.