Python

At Caktus, we maintain some open source packages, which are usually pieces of code that we’ve found useful when building an application, and we figure they might be useful to others. From time to time, those open source projects need a little maintenance: Maybe a bug fix has been provided from a community member, or we need to update to support a new version of Python or Django. I always hesitate to do this because I know there are multiple steps involved to ensure that any updates are properly tested, documented, versioned, and released. One of my silly blockers is that I always seem to forget how to upload a release to PyPI, which is the Python Package Index, a repository of software for Python. I call it silly because it shouldn’t really be a blocker, seeing how simple it actually is, but I still forget it each time and have to walk through the documentation step by step to make sure I do it properly. I recently found a tool that helps with this process.

This is how to set up the One True Development Environment for Python.

Haha, just kidding, there is no such thing. Here's one way to do it that works for me, and an attempt to explain the benefits of doing it this way.

We’ve published summaries of our most popular blog posts before (see Top 19 of 2019 and Top 18 of 2018), but this time, we’re taking it a step further. We’re sharing the 20 most popular posts in 2020, regardless of the year the post was originally published. And some of these have been around a while! Based on total pageviews, here are the blogs that rose to the top of the popularity list, from most viewed to least viewed.

I keep up with what's happening in my field by following a number of blogs and an occasional email list. I don't read everything posted in all of these, but by scanning the topics in a feed reader, I can keep up with what's going on, without wasting a lot of time.

Last August, our CTO Colin Copeland wrote about how to import multiple Excel files in your Django project using pandas. We have used pandas on multiple Python-based projects at Caktus and are adopting it more widely.

In my previous line of work as an archivist, the question of what to do about email archives was an ongoing and deeply-considered topic. Email is everywhere. Yes, even Gen Z and millennials use it, despite thousands of think pieces that would have you believe that the old ways are giving way to business meetings conducted on fixed-gear bicycles, over avocado toast and Instagram.

During the last year we gave our popular technical blog an official name: Developer Access. We published 32 posts on the blog, including technical how-to’s, conference information, web development best practices and detailed guides. Among all those posts, 19 rose to the top of the popularity list (based on total pageviews):

These days it’s easy to get swept up into the buzz around Python’s strengths as a data science package, but Python is also great for the more mundane, business process side of computing. One of the most important business processes is generating reports, and the most used and venerable form of report is the PDF. Python has a great library for generating and manipulating PDFs: ReportLab. I recently read more about this extremely useful library in ReportLab: PDF Processing with Python, by Michael Driscoll. With a few caveats, it’s an excellent resource.

I enjoyed working through the book Creating GUI Applications with wxPython by Michael Driscoll, learning various techniques for programming GUI applications in Python using wxPython.

For many years, we've been running an ELK (Elasticsearch, Logstash, Kibana) stack for centralized logging. We have a specific project that requires on-premise infrastructure, so sending logs off-site to a hosted solution was not an option. Over time, however, the maintenance requirements of this self-maintained ELK stack were staggering. Filebeat, for example, filled up all the disks on all the servers in a matter of hours, not once, but twice (and for different reasons) when it could not reach its Logstash/Elasticsearch endpoint. Metricbeat suffered from a similar issue: It used far too much disk space relative to the value provided in its Elasticsearch indices. And while provisioning a self-hosted ELK stack has gotten easier over the years, it's still a lengthy process, which requires extra care anytime an upgrade is needed. Are these problems solvable? Yes. But for our needs, a simpler solution was needed.