To receive updates in your inbox, subscribe to my TinyLetter.
Code is read much more often than it is written. As software developers, we have many options for ensuring our code is as readable as possible. In this post I’ll describe how you can use several free open source tools to automate code reviews in your GitHub repositories.
I learned about OKRs in 2019, and since then have come to appreciate them. They’re simple: come up with one high-level Objective you’d like to accomplish, then come up with separate, measurable Key Results that indicate whether you’ve hit your objective or not.
For the last several years I’ve kept track of every film I’ve seen and ranked them. This year was no different.
In this article we’ll go over how to handle webhooks using Django, create a webhook in GitHub, and test the webhook on your local machine using ngrok. But first a brief primer on webhooks.
A few weeks ago I released a little web app to the world. The app is called Lintly, and it is a code quality checker that helps keep codebases squeaky clean.
I recently announced the release of a project I’ve been working on for a few months. The project is called Lintly. It is a continuous Python code quality checking tool that lints your code when you push to GitHub. I won’t go into detail about what Lintly is here — you can read about that in the other blog post or go to lintly.com. Instead, I’d like to discuss my experience creating my first proper side project, some of the mistakes that I made writing it, and how I fixed the mistakes.
I work on a web application called SideKick. SideKick has several dashboards depending on the type of person logged in. The “type of person” could be an employee of SideCars (the company where I work), the owner of a car dealership, or a dealer’s agent. Each dashboard has lots of handy widgets, as dashboards are wont to do. We contain the logic of each widget in a Django template tag so they can easily be resused. Here’s an example of a widget:
Django had support for loading initial data into a database before Django 1.7. It was simple: put a file called
initial_data.json in the
fixtures folder of one of your Django apps and it will be loaded into your database each time the application starts up. It looked a little something like this:
It’s time that I finally start a blog. I’ve put it off for far too long. And after spending a weekend with some of the more important folks in the Django world, I suppose you could say I’ve found a bit of inspiration. Here goes nothing.