I love writing blog posts, and today I’m setting out to do something I’ve never tried before: write a blog post about writing blog posts. A big part of our mission at Caktus is to foster and help grow the Python and Django development communities, both locally and nationally. Part of how we’ve tried to accomplish this in the past is through hosting development sprints, sponsoring and attending conferences such as PyCon and DjangoCon, and building a knowledge base of common problems in Python and Django development in our blog. Many in the Django community first get to know Caktus through our blog, and it’s both gratifying and humbling when I meet someone at a conference and the person thanks me for a post Caktus wrote that helped him or her solve a technical problem at some point in the past.
While I personally don’t do as much software development as I used to and hence no longer write as many technical posts, the Caktus blog and many others in the community continue as a constant source of inspiration and education to me. As software developers we are constantly trying to work ourselves out of a job, building tools that organize information and help people communicate. Sharing a brief, highly specific technical blog post serves in a similar capacity; after I’ve spent 1-2 hours or more researching something that ultimately took 5-10 minutes to fix, I’d hate for someone else to have to go through the same experience. Writing up a quick, 1-2 paragraph technical post about the issue not only helps me think through the problem, but also hopefully saves a few minutes of someone else’s life at some point in the future.
To help me better understand what I like so much about blogging, I went back and reviewed the history of Caktus blogging efforts over the past 5 years and separated our posts into categories. While I’m sure there are innumerable ways to do this, in case it serves as a source of inspiration to others, what follows are the categories I came up with:
-
Technical Tidbits. These types of posts are small, usually a paragraph or two, along with a code or configuration snippet. They might cover upgrading a specific open source package or reusable app in your project, or augment existing Django release notes when you find the built-in Django documentation lacking for a specific use case. Posts in this category that we’ve written in the past at Caktus include upgrading django-photologue and changing or SHMMAX setting (for PostgreSQL) on a Mac. These are great posts to write after you’ve just done something for the first time. You’ll have a fresher perspective than someone who’s done the task many times before. Because of this, you can easily anticipate many of the common problems someone coming to the task for the first time might face.
-
Debugging Sugar. Posts handy for debugging purposes often rely on a specific error message or stack trace. Another good candidate for this type of post is documenting an existing Django bug that requires a specific workaround. Posts we’ve written in this category include using strace to debug stuck celery tasks and the (thankfully now obsolete) parsing microseconds in the Django admin. A good sign you need to write a post like this is that you had to spend more than 5-10 minutes Googling for an answer to something or asking your co-workers. If you’re looking for an answer and having trouble finding it, there’s a good chance someone else out there is doing the same and would benefit from your blog post.
-
Open Source Showcase. Open Source Showcase posts are a great way to spread the word about a project you have or a teammate has written, or to validate a 3rd party app or Django feature you’ve found particularly helpful. These are typically longer, more in-depth analyses of a project or feature rather than an answer to a specific technical problems (though the two are not always mutually exclusive). At Caktus we’ve written about our django-scribbler app as well as several new features in Django, including bulk inserts, class-based views, and support for custom user models. While these posts can require a significant time investment to get right, their value as augmentation to or 3rd-party validation of Python and Django development patterns cannot be underrated. Patterns are set through a community rallying around an open source package or approach. Proposing and sharing these ideas openly is what drives the open source community forward.
-
Mini How-tos. Mini How-tos are generally a combination of other types of posts. They start with a specific goal in mind -- setting up a server, installing a reusable app -- and walk the reader through all the necessary steps, services, and packages required to get there. If you feel passionately that something should be done in a certain way, this is a great way to set a standard for the community to be aware of and potentially follow. This could cover anything from configuring a Jenkins slave to using Amazon S3 to store your static and uploaded media. Similar to an Open Source Showcase, Mini How-tos are an asset to the community insofar as they help advance and disseminate common approaches to software development problems. At the same time, they’re open to review and critique by the wider open source community.
A big thank you to everyone in the Python and Django community for being open and willing to share your experiences and problem solving efforts. Without this, Caktus would not be where it is today and for that I am deeply grateful. If this post happens to inspire at least one short technical post from someone who hasn’t written one before, I’ll consider it a success.
