I’ve been playing around with Google App Engine quite a bit lately. Whenever I’d create a new project, I’d start by copying and pasting a folder called “new_project_template” which is included in the software developers kit. The template contains a bare-minimum hello world script. As I made more and more apps, I realized that I always added the same things to this folder before writing the actual “guts” of the code.
I always had to fix the indents, add some basic import statements, and include my favorite web scraping library, Beautiful Soup. So I created a template of my own and named it “better_project_template” (creative? I know). The folder has the Beautiful Soup module, base.html and index.html templates, as well as some useful shortcuts added to the main.py file. Anyone interested can download this folder here for their own use.
I’ve been a big fan of Bit.ly. The added utility it provides to link shortening is unmatched. It makes tinyurl.com look like the url shortener of simpletons. Using Bit.ly conveys that you are tech-savvy to a certain degree. But what if you want the benefits of Bit.ly, without looking pretentious? Use biturlly. It’s a simple tool I developed last week that takes a long url, shortens it through Bit.ly, then shortens the Bit.ly link through tinyurl. You’ll get the click tracking of Bit.ly with the humility of tinyurl.
A little while back I wrote about how Bit.ly has the potential to bring us ever closer to the “semantic web” comparing it to the seemingly out-of-date delicious.com. Since that post, Bit.ly has added a few features as well as refined its user interface which suggest where Bit.ly may be headed.
The most significant new feature is profile pages. Just as Delicious accounts are in the form of delicious.com/username, Bit.ly accounts are in the form of username.bit.ly. Instead of linking to a Delicious account to show the world what you are sharing, you can just link to your Bit.ly account. However some features are missing from the profile pages, most notably, share/click counts. Bit.ly could easily list next to each link on adelevie.bit.ly the number of times someone has shortened the same url as well as total number of times people have clicked on that link. The data is all there, it’s only a matter of incorporating it into the user interface. Nevertheless, the people at Bit.ly do seem to understand the power of using their own click data to find what is relevant on the web. They’re testing the waters very slowly with this concept.
Back in October of 2008, the Bit.ly blog had a post titled Yesterday’s Top Bits where they simply listed the highest-clicked Bit.ly links. Later, in February of 2009, Bit.ly created a Twitter account called bitlynow which tweets the highest-clicked Bit.ly links for a certain time period. This gives Bit.ly the ability to keep a pulse as to what’s being shared on the web in a similar manner as Twitturly. Twitturly’s advantage is that its data include just about every link that goes through Twitter. Bit.ly’s advantage is that its click/referral tracking feature allows it to look beyond just Twitter. I’d like to see some amalgamation of Twitter, Twitturly and Bit.ly.
While Bit.ly’s new features are encouraging, they still don’t address the 800 pound gorilla in the room: its growing database of semantic data about each Bit.ly link (from Open Calais‘ api). Solely tracking the flow of links only gives part of the picture. Tracking the flow of the meaning of those links is a lot more valuable. It would be nice to see Bit.ly make sense of all this data.
I like using App Engine’s webapp framework. It’s very simple and similar to the web.py framework. However, simple tasks such as outputting data or rendering templates require way too much boilerplate text. For example, to output a rendered template, you must type:
1
2
3
4
5
6
7
8
| template_values = {
'greetings': greetings,
'url': url,
'url_linktext': url_linktext,
}
path = os.path.join(os.path.dirname(__file__), 'index.html')
self.response.out.write(template.render(path, template_values)) |
To avoid this morass of boilerplate code, and to better keep track of your code, simply add the following snippet to the beginning of every instance of the RequestHandler class (each “page,” if you will):
1
2
3
4
| disp = self.response.out.write
def render(template_name, template_values):
path = os.path.join(os.path.dirname(__file__), '%s' % template_name)
disp(template.render(path, template_values)) |
Now to render a template, simply use return render('index.html', {'form' : someForm()}).
Think of this as App Engine’s version of Django’s Render_to_Response function ;).
Similarly, if all you want to do is spit out data that won’t go through a template just use return disp("some string").
I have recently been allotted about 20 beta invites to the question-and-answer service, Aardvark. It has been hailed as “Yahoo Answers meets Twitter — but better.” From the article:
The simplest explanation is Yahoo Answers meets Twitter — real-time, rapid fire responses, by actual human beings, to intelligent (and not-so-intelligent) questions. It helps you find answers that are too complicated, even for Google’s search algorithms.
If you want an invite, simply leave your e-mail address in the comments or send me an e-mail. (hint: my e-mail address is on the page that starts with “a” and rhymes with “about”.)
UPDATE: I have been replenished with invites from the good folks at Aardvark. I have about 30 left.
I am working on an api of sorts. This requires that I create several methods in which data is appended in a url as a string of GET-data. To access GET-data in a Django view, you simply use request.GET['parameter']. However, it is a pain to write request.GET['parameter'] about 20 times when the only thing that is changing is the name of the parameter.
To get around this, I have devised a simple solution:
1
2
3
4
5
6
7
| def view_name(request):
params = ('param1', 'param2', 'param3', 'param4')
data = {}
for param in params:
param_value = request.GET[param]
data[param] = param_value
return HttpResponse("here is the dictionary of all of your GET-data: %s" % data) |
Now you can easily alter GET (or POST) parameters without deleting and rewriting request.GET['parameter'] for the nth time. The data is accessible in a dictionary. Just want the value for param1? Just use some_var = data[param1].
And here is the code on my favorite pastebin.
UPDATE: Upon using this, I realized there is a much simpler way to accomplish the same thing:
data = request.GET. Getting the value for param1 is as easy as data['param1']. I’ll still leave this post up for learning experience purposes.