Holy crap it's March

March has definitely snuck up on me this year. Maybe partially because I have a lot of other work to do right now, days can be a bit of a slog to wake up, figure out which contract needs attention, build stuff all day, sleep, repeat. I definitely need to mix my days up a bit which was my intention when I said I was going to work out of some different locations a few weeks ago. Still have not gotten around to figuring out where those places are or when I would do this 😁

I made a few small tweaks to SPI Websockets to move the frame timing back to where it should be (in the spi package) but I’m still messing around with what designs I can actually build with it. I have to make a gif of the real thing vs the sim display before I can open source it. Afterwards I’m not sure about when I’ll get around to building something in it.

My first That Thing in Swift livecoding event was last week and went way better than expected. I built a small project in a little over an hour, had roughly 10 concurrent watchers the whole time and got some good feedback on Twitter afterwards. I did some digging into how to improve my setup afterwards and it seems cheap and straightforward to make some big steps up in quality, though I’m still not completely sold on the format. 1 hour is a long time to commit to watching a video!

I’m going to produce a few small (non-live) videos to go along with the most popular pages on the site (notably Singletons and Background threads) and post those at the top of the page in a new That Thing in Swift youtube account, we’ll see how many views and subscribers that gets us. Then we’ll figure out where to go from there!

Lastly on the project updates, I realized that I know very little about how Solar cells actually produce power. I get the photoelectric/voltaic effect but there’s a big difference between knowing that physical process versus how to turn it into functioning electricity. I’m keeping notes on everything I learn and I’ll hopefully wrap it up in some regular posts here.


Treat has finally made its way to the archived pile. I still think the core idea is awesome, there’s just no great hook for why you want to use it in the first place. Surprisingly (to me), the fact that people use gift cards is not enough to justify the same people wanting to do the same thing (but better, obviously) on their phone. It’s still in the back of my mind and there are a few small things I want to do work on to feel out some assumptions but it’s not going to happen for a few months.

A big takeaway from the project is that I got wrapped up in this Startup culture and let those norms decide how I would build a company.

One thing that has really resonated with me since then has been this great, simple Startup Growth Calculator from @tlbtlbtlb. Here’s a shot of the model that makes sense with how I work:

The good Startup Growth chart

All the things on this chart are concrete and achievable. Spend $100 weekly? That’s way more than I usually spend to acquire users, initial investment for an engineer on their own project is mostly time. $45 weekly revenue? That might not be achievable on day 1 but it’s a low target that should be easy to hit if your project has any merit at all (no, I don’t want to make a “free” product where the customers are actually advertisers). 3% growth? That’s minuscule for a startup.

Let’s push the “profitability” back by 6 months since you’re not making $45 a week immediately. That’s still a single year to get to profitability, incredible. I know this is a simplistic model and you’ll probably want to grow faster by reinvesting or getting new investment during this time scales but this is what my year 1 plan should be for any project that I want to make money on. And your starting investment in the project is time and not quite $2000, not even enough to get your halfway through this month’s rent in SF.

The best part is all the way on the right (outside the frame of this screenshot) where it says “$100M/yr revenue at year 7”. If you’re on track for $100M/yr, there’s nothing that can stop you.

Leap Day Updates

I wanted to get one more update in before the end of February, luckily we have a leap day this year!

I’m planning a live coding session for That Thing in Swift on Wednesday this week. I still have a few technical things to work out but I’m not committed to it being perfect, just good enough to get a sense of how much interest there is. I think it could be pretty cool.

I need to do some more thinking about how to test theories related to Boundary Layer in the very early stage. I did a bit of research into creating wind tunnels to do proper experimentation and - surprise - there are super shitty versions made for high school science fairs and then models created for final Masters theses. Insert scathing comment on the lack of curiosity in the modern human. I’m still too early to build anything but it’s good to know I can at least create a mid-range experimental rig that essentially doesn’t exist yet.


I neglected to mention another new project last time, Deep Birding , which is an attempt to play with machine learning by classifying the many birds that come to eat seed in the backyard. I think it’ll be fairly straightforward to identify bird type given enough training data but I’d really like to be able to identify individuals. I’m not expecting magic, I could identify individual birds myself given enough time and footage but it would be pretty impressive to be able to do it with machine learning.

Two things stand out as difficult: (1) lots of the example image classifiers available already have the images cropped to the same small size for testing. We’ll need to preprocess frames, looking for areas that have birds and then cropping to our processing size. (2) If we want enough detail to identify individuals, that means a relatively large bird image size. Convolutional processing is super fast with small images and might be prohibitively slow with images large enough to contain enough detail.

I’ve already collected 20 minutes of 1080p video with a few different bird species pecking around. I’m still working through the TensorFlow examples and figuring out how everything works so results are still a ways off.

Smaller project progress

It’s been too long! Time for some smaller project updates:

I started and mostly completed a microproject I’ve had in mind for a while. A friend has a string of ~750 addressable LED lights (model APA102-C) around the top of his roof deck and they’re controlled by a Raspberry Pi SPI interface. Since all the LEDs are individually addressable, he wrote a bunch of Go to make different patterns in the lights and the code gets deployed directly to the Pi.

I started writing some patterns but they’re difficult to test unless you’re physically there so I wanted to write a “deck simulator” where I could see the output of my patterns locally and revise them until they’re good. No clue how I was going to start but I had some time I allotted as free and this jumped into my brain.

I ended up writing a swappable spi-websockets library that has all the same interfaces as the real one but just forwards the spi data over websockets to whatever clients are connected. Then I wrote a simple visualizer in a canvas that interprets the data and draws all the lights. Some days I dread doing things that I don’t know really well because in contrast with how fast I can get stuff done in Swift, it feels frustratingly slow. Other days I’m OK with spending time learning something new.

So now I have to properly write the patterns I was planning on making in the first place 😂 I’ll post the code when I’m finished and give a quick wrap-up.

I got a ton of stuff done on the CMYK site for my brother two weeks ago, though not so much this past week. I was primarily wrapped up in getting some regular work done and being sick so not much extra time there. There’s some familiarity to it from my front end days but lots of new things to play with and APIs to work on.


I hit a big realization recently related to the work I do and the kind of thing I want to spend my time on. It’s definitely related to me coming off of Treat where I wanted to be a “startup CEO” and thinking more recently about going back to full time work. The core idea is that I shouldn’t let other people’s idea of success become my own. I’ve never been successful when I followed the normal thing to do and my favorite successes are when I’ve done something unusual and made it work. I have a pretty good idea of the box my successes fit into so I’ll be trying to be cognizant of those strengths.

One thing I really like to do is tackle big, weird problems that I have no (initial) expertise in and come up with new and different ways of doing things. I’m serious that it really interests me; I wake up thinking about these kinds of problems and it’s really motivating. I’ve always been a physics nerd but only way one works in physics professionally is by having your creativity beaten out of you over 6-10 years of rigid schooling. Obviously that doesn’t work for me but I’ve learned lots of fun stuff on my own over the years and occasionally I try to apply it in different areas. I’m not afraid of learning new things, particularly things that people think are “too hard” to learn outside of some structured learning environment.

One of the new projects I’ll be working on is a deep investigation into finding different approaches to minimize skin friction in aircraft. It’s one of those obscure subjects that I always do a bit of research on when I hear something related come up and I think I have some good ideas or at least directions to investigate. I’ll write up more about this particular project on its own soon but for now I’m calling it the Boundary Layer project.

On par for success

Success. Well, on par for success.

I’ve archived both PermissionScope and Pantry after finishing the maintenance releases I aimed to complete. I feel great not having those two things on my plate and I’m confident that I can deflect any new changes that might come through until a later date.

I don’t have a concrete plan for the next improvement to That Thing in Swift yet but I’m thinking about a few ideas. First, the community really enjoyed the post about writing your own API clients so I’m considering something along the same lines: a dependency that lots of people use that can be replaced with a small amount of good Swift. I like the idea because it’s different than what most Swift blogs write about - usually just an introduction to using x in Swift - and it requires a bit of creativity. I’d like to experiment with a few other ideas here, maybe some livecoding/video that incorporates actual code snippets that people can copy or follow along with.

Every time I think about finishing the work required for another Treat release, I keep coming back to the sending issue. Part of the reason that it didn’t work out is that there was no compelling reason to send a treat to a friend, even I didn’t do it that often. I’m hesitant to put more work into a part of the project that won’t fix a core issue. I still consider the sending issue every once in a while, I’m looking for a simple hook that could change the reasons for sending to something meaningful which would get me working on all those pieces again.


The last few posts have been new ideas! so let’s review: Pay by Tray is still an interesting idea but unless a restaurant owner who was really psyched about it fell into my lap, I probably won’t go anywhere with it. If that happens in the near future, I’ve already done enough thinking on it to ramp back up quickly enough. Successful projects (of this scale) require deep connections or lots of luck. I don’t have the former so I’ll keep it in the back of my head in case the latter appears.

Watercooler still fixes a problem I have (not enough social interaction while remote contracting) but I came up with a slightly different plan to tackle this for the time being which is probably better for me right now. This issue will probably be more prevalent in the future as remote work is more common and I still think it’s an interesting problem to solve (in an interesting way, not necessarily this one). In the meantime, you can sort of force this by just jumping on a random blab when you’re bored. It seems like most of the people there are in various states of boredom anyway.

I briefly looked into the tech I would need to build a stream of conversations from your friends on Twitter as mentioned here again. I came back to the idea after a while because it’s sticking in my head like a thing that might be a fun way to see what’s going on just outside of your social circle. And it seems like a thing that could be popular. I took a stab at it with pure js the other day but it looks like I will have to do some sort of oauth implementation which is more complicated than I wanted to get into. I then jumped over to Go to see if I could figure out the API calls needed to discover conversations in the first place but I ended up not wanting to spend a couple hours just getting back up to speed with Go. If I’m only interested in proving that it’s an interesting idea at the moment, I might as well do a quick swift implementation on the phone or iPad since that will be the least language friction (but UI still required).

I think I covered this before, but I’ll reiterate that ideas are super cheap and saying “No” (or just letting things die in this case) is not something that I’m concerned about. I like looking back on all this regardless of success.

Build log: Pay by Tray

Startups have improved on many UX aspects of takeout payments for places like your local coffee shop. Some of these improvements have been customer-facing like contactless payments and automatic tip selection, others are more business-focused like simpler ordering interfaces and better user management.

Very few of these improvements have been implemented in for in-house restaurant payment. We’re still waiting for servers to return with a bill, handing off credit cards, negotiating bill-splitting, calculating tips and waiting again before you can leave. There are a few high-integration apps which solve these problems but I don’t think I need to explain the downsides of requiring some of your party to have to download and sign up for an app to gain these benefits. Takeout payment successes have been primarily focused on business hardware and plenty of takeout payment apps attempting to simplify the process from the consumer side only have failed, in no small part due to the app download hurdle.

Pay by Tray simplifies the payment process for consumers in sit-down restaurants without forcing them to opt-in to some app. Businesses get to simplify payment for customers, gain extra time that waitstaff usually spend running bills and gain additional options for customer payment. No app required.

The product is essentially IoT for bill trays. There’s a nicely designed (draws your eye but at the same time feels familiar) bill tray that has a screen and an NFC reader (maybe a EMV dip slot). At the very least, this prominently displays your bill total. At most, you can pay on the spot with a single phone or multiple phones, splitting the bill and selecting a tip amount without doing any math or asking the waitstaff to go out of their way to split things 5 ways. A small but obviously visible LED on the tray indicates the state of the transaction - pending, paying, paid, etc - so waitstaff can glance at the tray to see that users have paid, particularly because after payment they can just get up and leave.


I’ve been thinking about this idea for a little more than a year - my first notes on this are from October 2014 - but it recently came up again and I dug into the competition to see what was currently available. So far I’ve only found apps that users have to know about and download in advance, thus plenty of effort has gone into making these apps as much about supported restaurant discovery as they are about the actual payment. I think that’s probably a distraction.

It might seem weird to have another build log for a new project so immediately after the initial build log for Watercooler but they’re distinctly different project types to me. Watercooler is a thing I can build just by throwing some hours at the engineering, Pay by Tray is a project I’d do a lot of research on and then go find some funding for a pre-product development cycle. A v1 product is mostly backend and hardware engineering, neither of which I’m very good at so I can’t really jump into the engineering anyways. Well, I can and most likely will just to get things started eventually but this is not an idea I can launch on my own so searching for buy-in from others first is the smart move here.

This has only been on my radar again in the last 48 hours so I’ll dig some more and ask around for feedback from friends next. This is always the most exciting

Build log: Watercooler / Workbreak

I’m diving deeper into the idea discussed last week about a mix of pomodoro timer and breaktime video chat that I’m calling either Watercoolor or Workbreak. No code yet, I’m thinking about the simplest tech for implementation and how to attract the first 100 users.

Actually, my primary concern right now is whether or not I should build the thing in the first place. I’m keenly sensitive to where I decide to spend my time right now (possibly as a result of this blog and my efforts to try and keep my active projects list short) and I was really hoping to break away from a strictly software based project and do something more interesting. However, the more I think about the project, the more I think I can put a basic version together with a minimal amount of work. Plus I like the concept! I think I would enjoy taking 5 minute breaks to chat with other people about projects.

Frontend choices

Obviously my first instinct was to build on iOS. Easy to do local notifications when your timer is up, easy to get video from the camera, etc. Distribution is the problem here. Distributing to randos is entirely through the app store (enterprise distribution is still too hard because it’s designed for enterprise) which means a level of polish that I simply don’t want to provide for a version 1. App icons of multiple sizes, app descriptions, privacy policies, app review - all these things make it hard to publish a true beta. And I want to build a true beta.

My second thought was a Chrome extension. I don’t really care that it’s not 100% of the browser market, it’s enough of the market that I’ll be able to tell if people want to use it. Easy enough to make a browser action button that displays the timer, easy enough to send notifications when the timer is up, easy enough to open a window to start a new break video session. I don’t know what it takes to publish on the Chrome extension store, it doesn’t seem like much effort. Obvious drawbacks are not having a fucking clue how chrome background extensions work other than the simple example case I went through and javascript 🤔

Lastly, I could still leverage Swift and make a quickie Mac app. Again, the syntax is straightforward, I’m sure AVFoundation (camera) is similar to iOS and distribution can still be done ad-hoc and gatekekeper-approved, particularly now that Mac dev certs are a part of the yearly developer membership. But organizing and building a menubar Mac app (I am so sorry, I know you don’t need another) is unfamiliar. There are unknowns and it feels a bit more “heavy” that a chrome extension.

Backend

Regardless of frontend platform, I will need a WebRTC server running somewhere, possibly with other negotiation servers (I’ve looked only briefly into this). It seems like there’s plenty of open source solutions and a $5 Digital Ocean box should cover enough usage to start. There are a few free services which I may use - PeerJS looks good but I’m unsure of how up-to-date it is since some of the examples are broken. Presumably you’d have to use JS for the frontend for this one too. Even if I used a free (or paid) service I still need to keep track of which clients are “on break” and looking for a connection. Despite the upcoming shutdown of Parse, I may still use it for this purpose! We have a year, after all.

Projects and Watercoolers

Many little changes since last time. I resolved the last remaining PermissionScope issue and the release went out just in time to get back on the Swift trending list on Github. 36 ⭐️ so far today, just passed 2000 overall! I would like to move this project to “archived” and defer any new work until later - for me, this is easy. I still have to figure out how to communicate this effectively to new PRs that come in 😬

I finished off a new post for That Thing in Swift regarding building your own API clients in Swift. It was definitely a hit, lots of tweets and talk about it which gave the site its best day ever (just over 2k uniques and almost 3k views 📈). Most of the traffic on a normal day is from organic search which increases naturally as more people learn Swift but my goal is to actually hit more first page search terms. It remains to be seen if just writing more posts == more search traffic.

I did a bunch more work getting the blog category pages working. Now if you click on a project in a post, you’ll see all posts mentioning that project. I really think the color coded project names help a lot with this! I can scan a bunch of posts and identify the paragraphs mentioning that project fairly easily.

Pantry had some new, good pull requests which I merged in. I’ll be setting up a new 0.3 release soon but I want get releases working via fastlane so making a new release isn’t such a pain. Prototype here, make sure everything works OK and then I can move the process to PermissionScope .


Lastly, a new idea: I realize (now, finally) that working from home has some serious drawbacks in terms of socialization. Maybe this seems obvious to you but I never really considered how much I enjoy miss meeting new people and hearing about their projects and sharing my own. There are lots of ways to accomplish this, I’m trying to figure out which one is right for me.

A Virtual Watercooler

One idea I’m playing with is a combination of pomodoro timer and video chat. An app of some sort that times you for 30, 60 or 90 minutes of work and then connects you with someone else taking a break from work for 5 minutes of chat about what you’re working on and how it’s going, that sort of thing.

I actually like the idea that you’d run into the same chatters a few times over the course of a week, it gives you an opportunity to learn about the process other people are going through. It behaves a bit like a water cooler where you have a chance to run into a finite set of people but which one is semi-random.

Still thinking about how to set up a minimal test case without too much engineering (remember our promise?). Probably just a website to start!

New Ideas

Unexpected benefit of this blog: I can collect stupid ideas in writing as well! Some ideas look really dumb after a day or two, others look even better. It’ll be nice to reflect on these after a week to see where they shake out.

A new take on Connect Four

I’ve been thinking for a while that I should try my hand at some sort of simple games on iOS. I love quick arcade-style games to unwind after a long day so I’m naturally drawn to creating something like that. Alternatively, I play asynchronous turn-based games with my Mother to keep in touch between phone calls and there aren’t enough good games in this model that are quick and fun.

I’ve been doing lots of technical interviews recently and one of them asked me to write up a connect four game in code. Most of it was just some Swift organizational yoga but detecting wins was a fun challenge and the solution I came up with involved simple row-wise detection of four subsequent same-colored pieces, and then each direction you could win in (row-wise, column-wise, diagonal-right and diagonal-left) just required translating the board matrix in that direction and doing the exact same check.

This got me thinking about building a quickie connect four iPhone game (the hard part is done! now it’s just everything else! you know this feeling). But the weird translational solution I came up with got me thinking about different ways you could play connect four. Rotating board connect four? Does that exist?

This sounds fun but I know that there’s a lot of work that goes into creating a polished app. I would probably start by creating something very basic and playing with connect four rotation to see if that is fun and weird.

Twitter Conversation Stream

For the most part I like the fact that you only see @-replies on Twitter to people you follow. Otherwise I’d be muting everyone who used Twitter more frequently (or way more frequently) than I do.

But I also like sometimes like digging into conversations that my friends are having with people just outside my friend group - or entirely outside. It would be nice to have a site that would find current conversations that my friends are part of and see the whole thing in context. And then they all flow by in a stream, just like individual tweets do (in a naive stream).

Probably just a web site connected to the Twitter API. I could even use their card rendering and do less of the styling work myself.

First week wrap up

Plenty of progress this week but no luck with paring down the list of “active” items to the ideal 2-3.

I cleaned up the rest of the potential items for a new PermissionScope release and made a change that I thought fixed the one remaining issue but it turns out not to be the case. Back to debug mode there.

I reviewed the one PR for Pantry and I’m just waiting for it to come back with some small changes before the 0.3 release is made. Still have not reached out to that contact about promotion though.

I did a little promotion for That Thing in Swift - unexpectedly, really - so some extra views early this week there. I got some positive feedback on a topic I started a couple weeks ago which I have a feeling will be relatively popular and well-shared. I will at least make progress on that post this week.

Mostly the beginning of this week was about catching up on some contract work. Seems like I’m ahead of the curve there at the moment so perhaps I’ll have more time to work on the tasks that I didn’t hit last week.

Definitely feeling the pressure to archive the VR project , it’s stagnating a bit and I’m not quite sure where to go with it if I don’t have any contacts inside the sports organization that I’m aiming for.


I’m torn on if I should include interviewing as a separate project. It is definitely a big focus at the moment and takes up a good chunk of my time.

It’s sort of like a big meta-project: I’m talking to people about existing projects and new ones, trying to figure out what’s interesting and worth the time to dig into further. I’m fortunate enough to not be under pressure to pick something immediately and taking your time with job decisions is one way to have control over a process that is frequently out of your hands.

For now, it stays off the list.

Coffee and phone calls

I thought a couple weeks of interviews would give me some nice downtime to wrap up a few projects. Turns out NOPE, it’s just an endless series of coffee dates and phone calls.

A few people have warned me to be super picky - possible because of the incredible demand for iOS developers - which is a great position to be in but also quite daunting. I still want to go through the first couple of steps with most people, until the ‘cons’ list starts piling up at least.

Perhaps this is what normal non-engineer days are like? There are people who essentially have ‘coffee and phone calls’ as their job description. That would probably take some getting used to but not entirely impossible.


Still, a few things did get done in the first half of the week. I made the necessary fixes for a much needed PermissionScope release. It’s mostly cleanup and bugfixes but I think I let the whole open source thing get away from me a bit so this was an attempt at getting the project back under control where I understood everything that was going on.

Try Again is actually on the public internet now, albeit in very rough form. It’s the standard publish-with-hugo-sync-to-s3 method I’ve been fond of for a while. I’m still narrowing down how to manage all the project views in the sidebar. I think it’s going to require some fancy templating work but that’s what I’m good at (definitely the thing I was known for when working on Movable Type), plus Hugo has an interesting data-driven content tool that I’ve been itching to experiment with.

The remaining time was spent on the couple bits of contract work I have currently. I don’t find balancing client needs all that difficult when all I’m doing is contract work but when I’m trying to work on other projects or interviewing it starts to reach the conflict zone. Still, it’s not a ton of hours right now so it’s relatively calm.

Try Again

I tend to work on a lot of projects simultaneously. Actually, I try not to do them simultaneously, it messes you up if you’ve got to context switch too rapidly through your day. But I start lots of projects and put them aside for a week or a month when something else comes up. Sometimes they get revived, sometimes not.

And that means lots of failures. Either from lack of interest or time or both. I don’t think that’s necessarily a bad thing but there are two things I wanted to be more mindful about related to this process: being clear when I “archive” a project (decide to stop working on it) and having a better understanding of the stuff that I want to do and how long it’s been since I worked on it.

To that end, you’ll find my quick tracker on the left side of the page. It’ll highlight any projects mentioned in the current post or give you a list of everything on the main page. Plus it’ll show a visualization since the last time I posted about each project (hopefully equivalent to the last time I actually worked on it) and archived projects will be listed below that with an indication of if they’re “finished” or not.

The idea of something being “finished” isn’t super important to me. I’m far more concerned that I keep trying to learn new things than about bringing each idea into a fully formed state. Some ideas are interesting but a product that is based off those ideas isn’t. Who’s to say you have to make everything into a product anyways?

The important thing is that we try again.

So this is going to keep me honest. I want to report a few times a week on progress for each item that isn’t archived, forcing me to move forward or abandon an idea.

Ideally, I’d like to have 2 active projects at a single time and be strict about not working on archived projects until there’s time to do so. Maybe that means building a little backlog of PRs on github before I make a new release but that could be OK, I’ll give it a shot at least.

Wrapping up treat

It seems like we’ve reached an impasse with Treat . It’s been our focus for almost a year now and while we’ve learned quite a bit about what people want and don’t want, there hasn’t been enough interest in any direction to really warrant the continued effort in the product. That said, I still think two key points we got right will define whatever product wins the mobile gift card segment in the future:

  • You can send a gift card to anywhere (or nearly so)
  • Interactions with your friends during/after sending

The plan is to keep it as a side project so anyone with outstanding treats can still use them and new users can send them. I even have a couple new features to roll out that are mostly done before it really goes into cold storage: full on sender-to-receiver chat (powered by Layer) and a new way to get info about your treat location (business hours, photos, etc) will be heading to the App Store soonish.

I’ll probably write a longer breakdown of the issues faced once that release is out.


Other things for this week: I am writing posts for Try Again before it even exists! This is traditionally opposite of how I usually do things (build first, write later) which doesn’t often work out. In general I tend to gravitate towards the “hard” engineering work first and the actual content or validation steps later which may have been the root of some initial issues with treat 😁 So we’re giving the reverse process a shot.

I lied just a little bit: I did doodle a quick design for the blog and started working up a quick template in Hugo before I started writing this. But it’s by no means complete (I don’t even think I can see this post yet). So the plan is to see how much I like writing about current projects a few times a week and slowly build a local site around it just to see how it feels. I’d like to have a rough site by the end of this week.

I asked around for some connections related to Project Y . I should put together some of the research I’ve done in the case that I get a meeting. I already know one company with a similar goal, though their technology choices make me wonder if they’re competent. It’s a bit of a stretch but I’ll keep tabs on it until it plays out.

I must, must, must resolve the issues with the upcoming PermissionScope 1.0.2 release this week. We’re encountering more and more people creating issues for stuff that’s been fixed and not released so it’s starting to be a drain. Still no great plans for how to test the project because of the complexity of permissions on iOS. Still thinking about it. I’m happy with the contributions and progress for Pantry so far, I should review the enum support and get that pulled in this week. Also, I have a plan for getting a bit more attention for Pantry that I should try this week.

While we’re on Swift, I started writing actual technical posts on That Thing in Swift again during the break. I realized that I’m being dumb not capitalizing on the insane Google ranking I have for some swift search terms so I might as well put a bit of effort into expanding the topics covered. Most of the blogs/results are slow and littered with ads so the least I can do is give a non-shitty alternative. So far I’ve published a piece on guard statements and I’m working on why you want to write your own API clients (as opposed to ad hoc usage of Alamofire or something).