Zeall, like many other software startups, uses GitLab for version control and issue management. We also use the ever-popular Google Calendar to handle meetings, reminders, and deadlines. For several months, we’ve been looking for a way to automatically push GitLab issue deadlines into Google Calendar, and until now it seemed impossible. Only after a recent migration from our own private mailserver to G Suite did we find a solution — or rather, figure out how to feasibly build one.
This might sound like a strong opinion, but I’m just going to put it out there: Python should make tzinfo mandatory on all datetime objects.
To be fair, that’s just an overzealous suggestion prompted by my frustration after spending two full days debugging timestamp misbehaviors. There are plenty of practical reasons to keep timezone-agnostic datetimes around. Some projects will never need timestamp localization, and requiring them to use tzinfo everywhere will only needlessly complicate things. However, if you think you might ever need to deal with timezones in your application, then you must plan to deal with them from the start. My real proposition is that a team should assess its needs and set internal standards regarding the use of timestamps before beginning a project. That’s more reasonable, I think.
I pose this question in quite a literal sense. Why does Python 2.7 have this behavior?
>>> (1,) > [2] True
No matter what the tuple, and no matter what the list, the tuple will always be considered greater. On the other hand, Python 3 gives us an error, which actually makes a bit more sense:
>>> (1,) > [2] Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unorderable types: tuple() > list()
The following post is a journey into some CPython internals, with a goal of finding out why 2.7 gives us such a weird comparison result.
Have you ever used a ternary expression inside a condition? I hope not. It seems that whoever wrote the Java drivers for MongoDB didn’t have this much sense.
The offending line of code can be found here: ConnectionStatus.java
It basically goes like this:
try {
// a bunch of stuff
} catch (Exception e) {
if (!((_ok) ? true : (Math.random() > 0.1))) {
// silently ignore error
}
else {
// log error
}
}
The intent appears to be to log just 10% of errors that result in an “okay” status, while logging all “not okay” errors. However, this condition is utterly unreadable, and I believe this awful implementation actually yields the opposite result.
Continue reading The single most hideous line of code I’ve ever seen
Today, I wrote gitply — a fairly simple Python script for visualizing the weekly activity of each contributor to a git repository.
It started out as a run-once script to get some statistics for one of my projects, but I ended up improving it incrementally until it turned into something friendly enough for other people to use.
I recently stumbled across an old joke about a software engineer that proposes an overly-complicated model for a simple problem. While I agree with the general sentiment of the joke, I don’t agree with the line of discourse that it represents. Among developers, overthinking is portrayed as wholly counterproductive. I disagree — I think overthinking a system is beneficial.
You may say, “But a toaster doesn’t need inheritance models for different types of breakfast foods!” I concede, this is true. But nonetheless, you should consider, “But what if it did?”