I’m heading back to Stripe in San Francisco to work on the Terminal SDK team!

But yikes, I had a busy spring. I finished my Bowdoin career, presented and submitted my thesis, presented some research I had been working on with the Art History department, and ran a Triathlon. Whew!

I’ll be at home relaxing for a while, enjoying the hometown I’ve been away from for the past four years. In July, I’ll be moving out to San Francisco, where I’ve spent the past two summers. We found a cute apartment in the Sunset District, and I’ll be spending a bit of time getting settled there. Soon after I move, my friends and I are hoping to hike the John Muir trail. Then, finally, I’ll return to Stripe, where I interned in the summer of 2018. I start in early August.

TL;DR: Bowdoin wrote about me! →

Rebecca Goldfine of the Bowdoin Communications Office wrote a really nice piece about my honors project, where I’ve been working on synthetic training data for ML models. I’m really thrilled that they wanted to show off my work!

I’ve been working on image object detection for my senior thesis at Bowdoin and have been unable to find a tutorial that describes, at a low enough level (i.e. with code samples), how to set up the Tensorflow Object Detection API and train a model with a custom dataset. This aims to be that tutorial: the one I wish I could have found three months ago.

I moved the Bowdoin Orient site from a custom CMS to a WordPress-based system over a year ago; since that time, I’ve struggled to find a proper development and deployment workflow that made sense for the Orient. This year, as the Orient welcomes four new members onto its web staff, I’ve been working to ensure that the website could easily be developed and deployed.

The system I built was based on solving the core problem of WordPress development: that the disadvantages of using exclusively local or remote development outweigh the simplicity of those two methods. I wanted to ensure that we could avoid those disadvantages and fulfill other requirements while using the best best practices I know of. Furthermore, I wrote it in Ruby to familiarize myself with the language used most often at Stripe, where I interned this past summer.

I’ve been working on a crossword puzzle creator for about three years, and I can’t tell whether it’s close to done or barely even started. In that time, the project has morphed into a personal playground in which I experiment with new, experimental web technologies. In practical terms, this means I’ve been restarting the project fairly regularly, using a new web framework each time. I’ve learned how to solve the same problem five different ways. I’ve rewritten entire UIs as my design chops have improved. I’ve been learning, but I haven’t made any progress.¹

When I realized that this cyclical development was getting problematic, I stepped back and looked at what I was doing. This project had become solely devoted to my own learning: I wasn’t building a crossword puzzle anymore, I was using the application design for my own education. My having fallen into this hole wasn’t necessarily a bad thing; in fact, there are benefits to experimenting with unknown technologies using a known problem domain. The question, therefore, becomes: which project ideas are better suited as vehicles for learning, and which are better suited for working to completion?

Wired, OReilly and others have been publishing articles about the rising potential for an RSS reemergence. RSS, the relatively obscure, techie-centric publishing technology that let users aggregate their own feed of web content, is heralded as a refreshing alternative to contemporary news curation. Today, in the age of a few large internet companies controlling news curation (and therefore, controlling what people read), the above writers (and many others) argue that we need to regain control of our own reading habits by decoupling them from social media; instead, we should curate our own RSS feed subscriptions. By doing this, writers argue, the semi-algorithmic middleman that brings articles to readers will be cut out. Readers will directly (and exclusively) access the content they want to see without being tracked, analyzed, or otherwise judged.

But the web today is not set up for an RSS revival. RSS itself is an imperfect technology that can be abused by publishers and was abandoned by readers for good reasons. The central problem RSS hopes to solve—over-curation of news—certainly still exists, but RSS is not the right technology to solve it.