Being a former Googler, one question I get asked a lot by my friends is “How can I get a page about me removed from Google?”
Almost always, my response is “don’t get published”.
Seriously. Google will make available any content that they know how to get to. “They” being the Googlebot, a tool that Google uses to find pages on the internet and make those pages available as a result when you search. So if you don’t want to be on Google, then simply don’t affect the world in a way that you would be notable at all.
Now that’s a sad lifestyle, when you really think about it. You should be happy to be in Google’s index! But if something about you is published, and that information makes its way online, and you really don’t want it to be there, you do have hope. You just have to get that information removed or have the author block Google from indexing that page. If you are nice enough about it, most webmasters will at least remove your name from the page(s) in question. Then give it a few weeks for Google to re-index the page and you’ll be fine.
I’ve spent the past six months working on a lot of different projects but one of the biggest projects I’ve been working on is a back-end system for the company I work for. If you ever want a sure-fire way to begin eating, breathing, and sleeping in Python, try joining a start-up and building something like this from the ground up. Lucky for us, Django is around to make this sort of thing far less difficult.
One of the greatest features of Django is the built in form handling functionality. Define some fields, throw a variable at the template, and add a form tag and submit button and you are pretty much done. It even does all the validation for you. Well, sort of…
As all generic things go, the validation that Django does is, well, generic. It’s easy to override the methods that do the validation, but then you lose the original validation provided by Django. So what do you do when you want to add to the existing validation instead of replace it? It isn’t exactly documented but it is possible…
In this example we have a form with a field that is only required in certain circumstances. Everything else about the validation needed to be the same.
Define the form:
class CreditCardPaymentForm(forms.Form):
mark_paid_in_full = forms.BooleanField(required=False)
payment_note = forms.CharField(required=False)
In this form you will have a checkbox to mark the payment “paid in full.” What we want is to require a note when that checkbox is selected. I’ve omitted the rest of the form as it’s irrelevant for the example.
This is where the trickery comes in. We are going to override the clean() method, check if mark_paid_in_full is selected, and change payment_note to required if it is, then run the existing validation.
def clean(self):
if self.cleaned_data['mark_paid_in_full']:
payment_note_field = self.fields['payment_note']
payment_note_field.required = True
try:
super(forms.CharField, payment_note_field).clean(
self.data['payment_note'])
except forms.ValidationError, error:
self._errors['payment_note'] = error.messages
return self.cleaned_data
As you can see a few things happen here. First it’s important to know that self.fields will contain all the field objects. Then we try to call the CharField’s clean method. I won’t delve into the specifics of how super works as there are already many articles covering that topic but if you aren’t familiar with super, it’s worth reading about. Then if the clean method raises a ValidationError, catch it and put it in the _errors property. You could just as easily leave the ValidationError raised and Django would print the error message… albeit at the top of the form. In some cases this might be desirable, but here we want to actually tie those errors to the appropriate field. Finally, you should always return self.cleaned_data or you will get some truly bizarre results
if this is something you are trying to do I hope this saved some time.
So I’ve been on and off playing with some of the developer builds of Chromium on Mac. For folks who don’t know, Chromium is the name of the open source browser that Google builds Chrome from. There isn’t an official Chrome for Mac yet but the source for Chromium has been in a state such that you can build the browser for a few months now. Well I just found out that I’ve been wasting my time doing my own builds because there is a buildbot up now.
Trust me, the browser is still far from prime time. Things like plugins don’t work yet – so you won’t be watching any Single Ladies videos quite yet, but it is still fun to play around with and wonderful to see that even in it’s early stages it is QUITE snappy at rendering web pages!
To download a copy go to http://build.chromium.org/buildbot/snapshots/sub-rel-mac/ and then select the most recent build number and download the zip. Enjoy!
This talk blew me away. It was presented by David Ewing from Synapse Wireless and shows how they put together an RF engine that runs python right on it. How great is it to be able to write code for embedded hardware using such a high level language!? Really the technology is interesting enough but you have to watch the video for the live demos. Unfortunately the first couple minutes didn’t get recorded because of technical difficulties but you can jump in pretty easily and besides, it gets you closer to the good stuff.
I’ll definitely be buying some of their modules to play with! (and maybe even an easy button)
My new job involves a whole lot of Django development. While we were testing the first version of our new site just before launch we stumbled across an interesting limitation of Django: The included django.contrib.auth package limits usernames to 30 characters and this can not be over-ridden easily. Thirty characters may seem like a lot for a username but if you want to use email addresses as your login identifier it can easily become a problem.
So I found myself in the office at 8pm digging through Django’s source code to find all the locations where the character limit is hardcoded in such a manner that it can not be overridden. There aren’t many but there are a few and it is honestly quite annoying that these values are hard coded. Eventually I’d like to contribute changes to the project that will allow you to change the limit more easily but for now I’ve attached a patch that can be used against Django 1.02 and will allow for up to 75 characters in the username.Django 75 character username limit patch
Applying is as simple as dropping the diff in the django/contrib/auth directory and running patch -R < django-75-char-username.diff
I randomly stumbled across what has to be one of the coolest new websites around -- animoto. This site takes your pictures and whatever music you want and makes an amazing video from them. One of the coolest behind the scenes aspects of the site is that they’ve used Amazon Web Services (AWS) to scale their business. If only Google App Engine had a service for background processing. Here is one I created from my cruise last month:
Check out this quick 60 second explanation of how the system works. Oh, and let’s talk about how hot Tom Clifton (the guy in the below video) is… damn hipsters (check out this picture if you don’t think he is hipster enough.
Here is a video of Tom talking about the service at more length:
Finally, the guys that work there seem to be pretty geeky, and their blogs are totally worth reading, even if you do think Ruby is freakin strange.
