A few things I've felt like writing down. All opinions etc are my own.
As the customer base for Sourcegraph’s “multi-single tenant” Sourcegraph Cloud offering grew, I had the opportunity to join the team to scale out the platform to support the hundreds of instances the company aimed to reach - which it does today!
At Sourcegraph we have a developer tool called sg, which has become the way we ensure the development of tooling continues to scale at Sourcegraph. But why invest in ensuring contributions to your dev tooling scales?
Zap is a structured logging library from Uber that is built on top of a “reflection-free, zero-allocation JSON encoder” to achieve some very impressions performance comapred to other popular logging libraries for Go. As part of developing integrations for it at Sourcegraph, I thought I’d take the time to look at what goes on under the hood.
Sourcegraph’s continuous integration infrastructure uses Buildkite, a platform for running pipelines on CI agents we operate. After using the default approach of scaling persistent agent deployments for a long time, we’ve recently switched over to completely stateless agents on dynamically dispatched Kubernetes Jobs to improve the stability of our CI pipelines.
Sourcegraph recently held a brief internal hackathon where we got to work on a variety of ideas related to our freshly minted “Sourcegraph use cases”. One idea that was raised was extending Sourcegraph’s core code search functionality to allow queries over search notebooks, a new product that enables live and persistent documentation based on code search, to aid in content discovery for onboarding.
In a rapidly moving organization, documentation drift is inevitable as the underlying tools undergoes changes to suit changing needs, especially for internal tools where leaning on tribal knowledge can often be more efficient in the short term. As each component grows in complexity, however, this introduces debt that makes for a confusing onboarding process, a poor developer experience, and makes building integrations more difficult.
As a tool for searching over all your code, accurately mirroring repository permissions defined in the relevant code hosts is a core part of Sourcegraph’s functionality. Typically, the only way to do this is through the APIs of code hosts, though rate limits can mean it can take several weeks to work through a large number of users and repositories.
With dark mode on every website nowadays, my website seems to have fallen a bit behind the times. I decided it was about time to give my website a bit of a facelift - and over-hype it with a blog post!
As an organisation grows, it becomes increasingly important to record knowledge and processes. One popular approach is using a collection of Markdown files, tracked in Git, where changes can easily be proposed and discussed. Unfortunately, the readability and understandability of these changes is often quite poor, negating much of the benefits of using a version control system.
Many open-source services are distributed as Docker images, but sometimes you’ll want to extend the functionality slightly - whether it be adding your own endpoints, manipulating configuration of the service within the Docker image, or something along those lines.
We’ve had a design sitting around for a while now, but this year we’ve finally decided to get to work and churn out a brand new, from-the-ground-up refresh of our 4-year-old website to showcase our new branding and this semester’s projects!
To scratch my visualisation itch, I invested in a lively period of trying to hack together an interactive website for a course project. Featured in this post: some Python + Notebooks, BigQuery, React, Uber’s deck.gl visualisation framework, GitHub Pages, and a lot of hand-wringing.
Every semester, quarantine or not, there comes a time where I tell myself - look, you’ve got to stop procrastinating! Assignments need to get done, material needs to be studied, grades need to be salvaged! So I sit down in a cosy spot, whip out my laptop, open up all my course notes and…
One of my projects while working at Sumus involved building a Figma plugin to generate a property pitch report from data about a property collected by employees, mostly aggregated on a central Wordpress instance.
When I started working remotely part-time for Sumus, my role was primarily as a software developer on an investor portal they wanted to build. I wasn’t starting from scratch - there was already a sizable codebase going, and a simple nonautomated deployment set up on Google App Engine.
So the other day I had a sudden, irresistible urge to make something using the Rough.js library, which lets you make gorgeously sketchy graphics. The urge probably originated from the fact that I had exams I was meant to study for.
I read about Bullet Journals (“BoJo”) recently. It’s more or less an analogue life journalling/task-management flow. I don’t really trust myself to write and read and keey a physical notebook (though I do have a bunch of cute small notebooks I could use for this purpose), so I had a think about how I could automate some parts of this.
One of my projects at Riot Games involved designing an extension to an internal application specification we have to describe services to allow engineers to declaratively define alerts on their application. Part of my extension design proposal was a feature that would allow users to specify “selections” from other parts of the spec and perform arithmetic on them as values in their alert thresholds.
Launch Pad projects are the product of months and months of continued iteration, and it’s easy to forget how far you’ve come. Today I finally hit publish on an article I wrote celebrating a year of progress for the club!
RTrade Technologies wanted to explore offering a service that would provide a set of Interplanetary Filesystem (IPFS) nodes, hosted on our end, that customers can use to bootstrap their private networks - groups of IPFS nodes that only talk to each other.
Recently at work, I came across a documentation website recently set up for one of our APIs. I thought it looked great, and slick, and super nice, and wanted to adopt it for anther project. I was told the documentation was generated using a project called Slate, and after taking a look I knew I had to try it out. It’s very pretty.
UBC Launch Pad is a student-run software engineering club whose primary objective is to be the best space at the University of British Columbia for students to meet other tech enthusiasts, build projects in a team setting, gain experience with professional development tools and principles, and share their knowledge with others! 🚀
So today day I gave a big “Developer’s Guide to Docker” workshop at my university! The goal was to introduce the concept of containerized services, how they are leveraged in industry, and how small-scale projects can take advantage of Docker during development.
Here at UBC Launch Pad, many of our teams’ projects are web applications. A pretty awesome step in any web application’s development process is when you deploy it for everyone to try out, and we wanted to enable all our teams to get there.
My first project at UBC Launch Pad was Sleuth. The goal of Sleuth changed quite a bit over the course of the semester but at its core we wanted it to be a search engine, geared towards UBC-related content.
Outside of work, my main focus has been UBC Launch Pad’s Inertia project, of which I am now the project lead. We want to develop an in-house continuous deployment system to make deploying applications simple and painless, regardless of the hosting provider.
I’ve been working in the Bioinformatics team at Michael Smith Genome Sciences Center. Most of my contributions center around building web tools, but I had the opportunity to do some more bioinformatic work as well.
At work, part of my job has been slowly revamping my team’s various scattered web platforms - a collection of about 3 servers serving 6 different websites - into a more consolidated and (hopefully) neater codebase. This involved trying to get rid of a lot of scary code.
As the summer progressed, my part time job selling pickles began to take up 4 to 7 hours per day, pretty much every single day. As fun as eating, chopping, packing, and talking about pickles was, I felt I needed a change of pace in my spare time. Something fun. Unfortunately, Game of Thrones only came along once a week, so I filled the rest of my time with something just as fun: sitting in front of a laptop for hours on end.
