Archive for the ‘Django’ Category

RedNoise, a Django-centric WhiteNoise addon

Thursday, June 4th, 2015

I’ve developed with Django for a number of years – out of all the frameworks I’ve ever used, it strikes the best balance between “let me get stuff done” and “don’t try to provide me too much, get out of my way when I say so”. I was ecstatic when WhiteNoise was released, as it solved a very annoying part of the development process with Django – static files. Rather than uploading things to S3 (ala the old Storages route) it’s now just easier to toss CloudFront in front of your files and let uwsgi serve it up. Since WhiteNoise debuted, I’ve used it on a few different projects, and over time I found myself wanting a few things that it lacked – django-rednoise provides them.

Feel free to read on for details, or go find it on GitHub! I published it as a separate module as the goals differ from the established WhiteNoise goals, but I’d be absolutely open to it being merged or pulled from.

DEBUG Please

WhiteNoise has a Django-specific module that you can use, but it’s essentially geared towards production use-cases. I tend to prefer having a development setup that mimics my production setup; patching Django urls to load static or media files in development just feels clunky to me.

RedNoise respects whether Django is in DEBUG mode or not. If DEBUG is set to True, RedNoise will mimic Django’s default static-file loading pattern, so you don’t need to reload the entire server just to debug some frontend issues.

Serve Media Files

WhiteNoise doesn’t support serving user-uploaded media files, but I wound up having to throw together a CMS at one point and ran into this limitation. Content authors and editors wanted to be able to upload photos, but I didn’t want to have to keep a separate S3 bucket for it all. RedNoise will serve media files, hooking into the associated parameters to make it “just work”.

Should You Use It?

I’ve run it for a bit with no real issues; I would say that whatever you do, tossing a CDN in front of it all is pretty efficient. Provided you do that, the CDN should absorb most of the requests, leaving your server to do its thing.

If you use WhiteNoise, and wish you had the above features, give django-rednoise a shot. It’s just a pip install away.

Using the myGengo Translation API with Python

Tuesday, May 31st, 2011

For those who haven’t heard the news, Google has deprecated a slew of their APIs, leaving many developers and services in a bit of a pinch. While there’s admittedly still time for developers to transition, it’s a good time to start considering alternatives. In my opinion, it’s probably a good idea to choose an alternative that has the technology in question as a core competency, otherwise you’re much more liable to have your provider pull the rug out from underneath you.

With that said, many engineers are hit particularly hard by the deprecation of the Translation API that Google has so generously offered up to this point, and desire a solid alternative. While there are other machine translation APIs out there, I wanted to take a moment to show more developers how integrating with the myGengo API can get them the best of both worlds.

A Polite Heads Up
As of May 31, 2011 I am currently working with myGengo to further develop their translation services. However, this post represents my own thoughts and opinions, and in no way represents myGengo as a company. myGengo offers both free machine translation and paid human translation under one API, and is currently offering $25 in free API credits to all new developers interested in trying it out. I simply want to show other developers that this is very easy to use.

Getting Started with the myGengo API

This takes all of 5 minutes to do, but it’s required before you can start getting things translated. A full rundown is available, which includes details on using the API Sandbox for extensive testing. For the code below, we’re going to work on the normal account.

A Basic Example

The myGengo API is pretty simple to use, but the authentication and signing can be annoying to do at first (like many other APIs). To ease this, there’s a few client libraries you can use – the one I advocate using (and to be fair, I also wrote it) is the mygengo-python library, which you just installed. With this it becomes incredibly easy to start making calls and submitting things for translation:

The above script should print out 25.00 if you signed up with myGengo using that link above.

Actually Translating Text

Extending the above bit of code to actually translate some text is very simple – the thing to realize up front is that myGengo works on a system of tiers, with said tiers being machine, standard, pro, and ultra. These dictate the type of translation you’ll get back. Machine translations are the fastest and free, but least accurate; the latter three are all tiers of human translation, and their rates vary accordingly (see the website for current rates).

For the example below, we’re going to just use machine translation, since it’s an effective 1:1 replacement for Google’s APIs. A great feature of the myGengo API is that you can upgrade to a human translation whenever you want; while you’re waiting for a human to translate your job, myGengo still returns the machine translation for any possible intermediary needs.

It’s your responsibility to determine what level you need – if you’re translating something to be published in another country, for instance, human translation will inevitably work better since a native translator understands the cultural aspects that a machine won’t.

This really couldn’t be more straight-forward. We’ve just requested our text be translated from English to Japanese by a machine, and gotten our results instantly. This is only the tip of the iceberg, too – if you have multiple things you need translated, you can actually bundle them all up and post them all at once (see this example in the mygengo-python repository).

Taking it One Step Further!

Remember the “human translation is more accurate” point I noted above? Well, it hasn’t changed in the last paragraph or two, so let’s see how we could integrate this into a web application. The problem with human translation has historically been the human factor itself; it’s slower because it has to pass through a person or two. myGengo has gone a long way in alleviating this pain point, and their API is no exception: you can register a callback url to have a job POSTed back to when it’s been completed by a human translator.

This adds another field or two to the translation API call above, but it’s overall nothing too new:

All we’ve done here is change the level we want, to use a human (standard level), and supplied a callback url to post the job to once it’s completed. As you can see, the response from our submission includes a free machine translation to use in the interim, so you’re not left completely high and dry. You can also specify a comment for the translator (e.g, if there’s some context that should be taken into account).

Now we need a view to handle the job being sent back to us when it’s completed. Being a python-focused article, we’ll use Django as our framework of choice below, but this should be fairly portable to any framework in general. I leave the routing up to the reader, as it’s largely basic Django knowledge anyway:

Now, wasn’t that easy? Human translations with myGengo are pretty fast, and you get the machine translation for free – it makes for a very bulletproof approach if you decide to use it.

Room for Improvement?

mygengo-python is open source and fork-able over on GitHub. I’m the chief maintainer, and love seeing pull requests and ideas for new features. If you think something could be made better (or is lacking completely), don’t hesitate to get in touch!

Rendering emails with Django templates

Tuesday, July 13th, 2010

I talk a lot about Javascript on this blog: client-side, server-side, wherever the language can be used. It’s not the only language I enjoy working in, though; Python has always had a bit of a soft spot with me, and with that comes some inevitable Django love.

I use Django for a lot of my server side tasks where I don’t feel I can safely use something like Node.js. On top of being battle tested beyond belief, it’s a veritable bag of magic tricks just waiting to be used. Take this one case I ran into recently: I’m building a service (stealth at the moment, stay tuned) that has to do something as simple as send out an email when a new user signs up.

Now, that email should ideally contain a few things. Let’s assume that, for a basic example, we’re gonna just include their username, a brand new password, and their full name (how we’ll use each of these is shown in depth below). Django makes sending mail pretty easy, using the send_mail function:

That’s all well and good, but what if we want to do more than just a simple string for our body message? Ideally, we should be able to treat this like any other Django template. In practice, this is actually incredibly easy (and fun).

The code should be fairly well documented, but for those who’d like a little more verbose of a walkthrough, it’s pretty simple: instead of passing in a string, load up a template and pass it a rendering context. See, what got me the first time around is that the render method of get_template needs a Template Context to do the dirty work, not a standard dict.

With that, here’s an example of an email template – it’s literally just a Django template, but ready for all your email attributes.

Django’s templating system is incredibly flexible, and can easily be used for more than just your generic views. If you have any questions or suggestions, feel free to throw them in the comments!