We have a customer that developed a hardware device to make physical measurements. Some years ago we wrote a suite of software tools for the customer: a tablet application for configuring the hardware device, a django web server to receive uploaded XML documents generated by the device, and a user-facing web application (using the same django server), providing reporting and data analytics.
It sounds so pleasant — a sky of golden rays flanked by purples and reds and oranges. The end of the day.
Or, for software developers, the end of life of a technology or version of that technology that can, depending on the prevalence of the technology, invoke feelings of concern, dread, or even near-panic.
Python is a powerful programming language with extensive library support. But what does one do when needing to integrate with a platform specific C or C++ component that has no native python support? There are two options. Completely rewrite the functionality in python or create a python extension. Either option can be painful and prone to errors. Enter Cython. It’s like the peanut butter and the jelly to the extension sandwich.
So, it has come to this.
Reports, yes, your application will have to have reports – in brand colours, with images and logos abounding, and probably festooned with graphs of various sizes, shapes and degrees of relevance to what was once a nice, streamlined set of data. This report has just become a part of the application ‘product’, meant not just to communicate, but also to entice and enthrall. Form has become just as important as function… and, did I forget to mention? It also needs to be exportable.
Exportable, portable, downloadable, shareable – because as I mentioned, it’s not just data now. It is now something clients/users need to be able to ‘have’, to attach to emails, send to their marketing departments, and incorporate into their powerpoints.
There’s a few ways to make this happen, but generally speaking, it’s time to break out the PDFs.
I’ve written a few posts here in the past on twitterbots — little bits of code that can generate and respond to tweets. Since those posts were published, I’ve traded messages with a few people who used the code for my original bot to write their own, and when I recently went back to the original post I noticed this at the end:
Now that I’ve built this and seen it running, I can imagine extracting the underlying logic for this into a little twitterbot framework so that next time I get a weird urge to do something like this and a few hours that I have nothing better to do with, I can make another bot quickly.
I pulled together a few hours this past week and did exactly that, creating a Python twitterbot framework that I’m calling ‘nanobot’.