A really beautiful little essay by Paul Lockhart about how we learn math now, and how we could do so, so much better.
[M]athematics is an art form done by human beings for pleasure! Alright, yes, it would be nice if people knew a few basic things about numbers and shapes, for instance. But this will never come from rote memorization, drills,lectures, and exercises. You learn things by doing them and you remember what matters to you.
David Troy has created a very cool visualization of how geohashing works. If you wanted to create your own geohashes (for example, to speed up proximity searches) there's an excellent python implementation of it.
When Can I Use... is a fantastic site to use when you need to decide whether or not to use some of the new CSS3 and HTML5 hotness. It offers comprehensive compatibility tables for relevant versions of all browsers, mobile and immobile, and even links to workarounds so you can just squeak by on using that one feature you just have to have. I'm planning on redesigning this site soon, and It's going to be a big help. Also, IE users, things here will still be readable after that, but otherwise, you're on you own until IE9 is ready for primetime.
In the process of putting together a presentation on functional programming, I've begun getting into Haskell a bit. It's a bit of a mindbender at first, but I'm enjoying it. For certain types of programming, it's an extrodinarily expressive language. Project Euler is a good example: I've started working through each of the problems, first in Python (a language I know) and then in Haskell. These kinds of math problems are places where a functional language can really shine, and I'm finding that even when judged against an imperative language that I think is particularly elegant like Python, the Haskell solutions often seem more, well...aesthetically beautiful. Fodder for a future blogpost, maybe.
Did you know Art Garfunkel keeps a list of every book he's read since 1968 on his website?
One of the most thoughtful, nuanced, and distinctive pieces I've seen about Wikileaks: 3 Quarks Daily: What is Julian Assange Up to? Contrast this with a fairly dissapointing essay by Umberto Eco on the subject which manages not only to get details about technology and state secrets wrong, but also doesn't really say anything interesting.
Belleville (the blogging engine I wrote, which powers this site) used to be on google code, now it's on github.
From Unblocking classical music's arteries on the blog On An Overgrown Path:
...[G]reat music making only happens when creative energy can flow freely between composer, performer and listener. Yet almost all of the current efforts to reach new audiences involve building the very barriers that block the vital energy flow. Classical music does not need a celebrity culture, it does not need inane presentation, it does not need to be markeketed like cornflakes by PR agencies, it does not need note perfect performances, it does not need national flags on the platform and it does not need the other brands of consultant created snake oil currently doing the rounds.
Excellent article by James Fallows about how Google's involvment in the future of journalism.
“Nothing that I see suggests the ‘death of newspapers,’” [Google CEO] Eric Schmidt told me. The problem was the high cost and plummeting popularity of their print versions. “Today you have a subscription to a print newspaper,” he said. “In the future model, you’ll have subscriptions to information sources that will have advertisements embedded in them, like a newspaper. You’ll just leave out the print part. I am quite sure that this will happen.”
Peru trip starts tomorrow. I have some notion of blogging and/or photoblogging my trip through the country, but it's an open questin whether I'll have the time.
Django-scaffold is now feature-complete. Test coverage is good—somewhere in the neighborhood of 85%—but needs to be closer to complete. Docs are also needed. Once those are done, I'll feel ready to call it 1.0. Well....maybe 1.0 RC 1. It would be nice to get it into production to really see where the bugs are, which I hope to do soon.
Nice post by Michael Zimmer on the fact that Facebook's Mark Zuckerberg really doesn't get it when it comes to privacy.
Had a very nice meal at Bistro Bouchon this past Saturday. If you happen to be in Richmond, give it a try.
There's plenty of evidence that Facebook is more than willing to sell its customers out:
...and ongoing security holes and exploits are a further cause for concern:
I hardly even bother signing in any more. I've been thinking of just closing my account.
Some of Poul-Henning Kamp's words of wisdom have been floating around in my head lately. Here's a snippet:
I wish we could reduce the amount of noise in our lists and I wish we could let people build a bike shed every so often, and I don't really care what colour they paint it.
Reading this and thinking "Bikeshed? Huh?" Aquaint yourself with Parkinson's Law of Triviality.
I've been working on a new, reuseable Django app calld scaffold. It aims to solve what I see as a common problem: you're building a site that needs sections and subsections. You not only need to be able to manage that hierarchy, but also hang other content off of it. More details on the project page. Suffice to say it builds off of Gustavo Picón's django-treebeard app and has, what I think are some pretty cool features. It's very alpha, but I hope to get a release candidate within a month. (This is also the first time I've worked with git, and I have to say, I'm really loving it.)
OK, so after reading the Django source code a little more closely, I found I was wrong. It absolutely is possible to invalidate the per-view caching. Here's a function I wrote to do it:
def expire_view_cache(view_name, args=[], namespace=None, key_prefix=None):
"""
This function allows you to invalidate any view-level cache.
view_name: view function you wish to invalidate or it's named url pattern
args: any arguments passed to the view function
namepace: if an application namespace is used, pass that
key prefix: for the @cache_page decorator for the function (if any)
"""
from django.core.urlresolvers import reverse
from django.http import HttpRequest
from django.utils.cache import get_cache_key
from django.core.cache import cache
# create a fake request object
request = HttpRequest()
# Loookup the request path:
if namespace:
view_name = namespace + ":" + view_name
request.path = reverse(view_name, args=args)
# get cache key, expire if the cached item exists:
key = get_cache_key(request, key_prefix=key_prefix)
if key:
if cache.get(key):
cache.set(key, None, 0)
return True
return False
You can use it like this:
from project_utils import expire_view_cache
def invalidate_blog_index(sender, **kwargs):
"""Invalidate the view-level cache for the blog:index page"""
expire_view_cache("index", namespace="blog")
post_save.connect(invalidate_blog_index, sender=Entry)
The is a pretty naive example, but basically whenever a blog entry is saved, the view-level cache for the blog index page is invalidated. Obviously you could be much more sophisticated with this. Per-view caching aside, I am quite sure that template fragment caching can only be invalidated when the TTL expires. That's a shame, but the per-view caching is far more useful anyway in my opinon.
...it's hugely useful. But some of those tools that make life so easy, like per-view caching or template fragement caching are hampered by the fact that they don't offer any way to handle invalidation. The process by which they generate cache keys is not exposed to the user, and if you don't know they key, you can't invalidate the cache. It would be nice to provide some hooks so that a function which recieves a model update signal could expire all instances where that model may have been cached. The only workaround? Roll your own with the low-level framework (which means more LOC in your project) or just don't invalidate and let things expire on their own. Neither approach is optimal.
