I’ve been thinking (and writing) about CORS recently because there’s a CORS error on the Bowdoin Orient’s site. The stylesheets for loading the Orient’s fonts are coming up with a CORS error in the Firefox console, while the Chrome console shows CORS errors for both the stylesheet and the font files.

I thought the solution would be fairly easy, but a quick diagnostic showed that it’s a little more complicated than originally expected. As I write this, I’m not sure what needs to be changed to fix the issue, but I’m going to try to outline my thought process while I debug it.

“CORS” errors are a certain type of web development errors that can be pretty confusing. Cross-Origin Resource Sharing related errors pop up when the web browser is trying to protect you from potential security vulnerabilities. When you don’t expect them, though, they can be pretty irritating—the error messages don’t make it entirely clear what you need to do to resolve the problem, and CORS itself is a complex enough topic that you won’t find any quick resolution steps on the internet.

Why do CORS errors occur in the first place? You nearly always see them when the following three cases are true: when the browser is

1. asked to load a remote resource (like a script, font, a page via AJAX, a WebGL texture, but not, notably, an image via the <img> tag) and that resource is
2. from an external domain, i.e. a domain that isn’t the same as the one in your address bar, but
3. the server doesn’t specify (by sending the correct HTTP headers) that the original domain is allowed to use that resource.

When all three of those cases are true, the browser will stop itself from loading the file, and will throw an error like the one above in the Javascript console. This might manifest as a font that doesn’t load, an AJAX call that doesn’t succeed, or other “why won’t this show up” kinds of problems.

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.