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. (more…)
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 are 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’. (more…)
Last time, we decided to embark on a brave new adventure and give our Django framework a big upgrade with the inclusion of Django Channels. We got just far enough to get the development server running, but while this may be an adequate start, it’s better to develop against something like what we intend to deploy, right?
So, let’s go the rest of the way and get ready to develop against something that at least resembles a standard production-ready environment with Django Channels.
You stare mournfully into the mass of code you’ve inherited. At some point, it’s clear, the requirements called for the server to push information to the client, because there’s an unholy mix of Server-Side Events, long-polling, hidden iframes and even a Java applet in there, all supporting some level of long-term connectivity with the server. It’s almost fascinating in its barely functional hideousness, and you would be inclined to leave well enough alone… except for the new feature specifications you’ve been assigned, which require the client to be able to send data back to the server in response to the received events, in as close to real-time as you can get.
It’s time for a major overhaul. Only Websockets can save us now. And, as it so happens, one of your favourite frameworks just added support for real-time, bi-directional communication…