Dave noticed that Disqus was now pulling FriendFeed comments and displaying them inline. Brilliant idea. I may switch my wordpress blog to use Disqus just for this. More here.
To test, please comment below, either here via Disqus or on the FriendFeed thread.
I’ve known for a while — and the sentiment has only grown over the past few weeks — that there is something about the way I use and interact with the contemporary social publishing tools and the surrounding culture — sites like Twitter/FriendFeed/etc — that isn’t quite working for me. Not to imply that those sites aren’t working in general, just that something is out of alignment for me individually.
Background: Six months or so ago I made a conscious decision to establish more of a web presence again. I had all but stopped writing on my personal site after taking my current job, but at the same time much of what I was thinking about and working on was designed to help that ecosystem thrive. So while I’m naturally shy in person, I bit the bullet and tried to actively engage with people on the web.
The best part of those sites is when I learn something new. Not just meet someone new (there are several billion people in the world — meeting people is easy, or so sez Thom Yorke) and not just meet someone smarter (there are billions of them, too) but to establish a connection with people that think about the things I am interested in. Me, I’m interested in things like computer science and intellectual property law right now. Politics, music, art, sure, but what really fascinates me most these days is algorithms, programming languages, ip licensing, stuff like that. So I was not simply seeking any random group, but rather a peer group.
Because the dirty little truth is that I care about the world of social media, public relations, silicon valley, startup culture, etc., about as much as I care about search engine optimization or the names of celebrity babies. It is the context in which we operate and live, but that alone does not make it interesting. In fact, most of it is a distraction — navels are not novel, and gazing at them just takes your eye of anything interesting up ahead.
(This entire post is an exercise in hypocrisy, which is why I’m burying it on a feed that has few readers.)
To address the situation, I’m aggressively pruning my reading lists — the thinking man’s attempt at going ostrich. I’m continuing to ween my Reader subscriptions, moving people that discuss social media and the like into a separate folder. I created a “Social” list on FF and as people post or like things that I would preferred not to be distracted at the time, I’m moving them into the Social list and off of the Home page. And I already don’t read Twitter other than the occasional search for comments directed at me or topics I’m interested in, so that’s not as much of an issue.
It’s not that I don’t like you or your blog, it’s that I just don’t like that I’m reading it all the time. So now I’ll just shunt those posts off to a place where I can collect and read them at a later date. Please don’t take that personally — information overload and the propensity for distraction just really has me down right now. It was either this or stop using these sites entirely.
I guess I just want these tools to serve me in a more professional and academic capacity, rather than a social or entertainment capacity. Hopefully this will work.
Earlier today I wondered how often the various forms of paragraph tags were used in HTML.
The three forms are:
A: <p>...</p>
B: ...<p>...
C: ...<p/>...
The consensus on FriendFeed was that the first form was clearly the way to go. But I was left wondering if, because of the legacy of early HTML, the second form might still be used with some frequency.
So this afternoon I wrote a quick mapreduce that examined a random sample of the web and counted paragraph tags.
The parser maintained a simple stack as it traversed through the document. Form A, <p>...</p>, is the number of balanced pairs at the end of the document, including empty pairs. Form B, <p>, is the number of open p tags that have no closing tag. And form C, <p/>, is the number of self closing tags.
The parser didn’t check for semantic validity — <p> tags could appear anywhere and still be counted — but I reasoned the number of misplaced tags would appear roughly equally in all three forms, so it was okay to ignore semantic errors for this casual experiment.
In the 833,866 html documents considered, form A (balanced pairs) was found 7,325,544 times, form B (unbalanced opening tags) was found 1,129,180 times, and form C (self closing tags) was found 44,180 times.
So the container <p>...</p> is used about 7x as much as the separator <p>, and both are used far more than the self-closing <p/>.
We also learn that 50.1% of the documents sampled contain only form A, 4.41% contain only form B, and a mere 0.21% contain only form C.
Further, 11.0% contain both form A and B, 0.70% contain both B and C, and 0.10% contain both B and C. And 0.15% of documents contain all three forms.
Interestingly, a full 33.29% of the documents sampled contained no <p> tags of any form at all. Presumably those documents use <br> and/or <div> tags to structure text into blocks, but I need to dig into this further.
The lesson for me is that, in keeping with the earliest HTML specifications, <p> is still used occasionally as a separator character in some documents. But because of the higher frequency of both A and B appearing (as opposed to B alone), it is slightly more likely than not that an unbalanced paragraph tag is that way by accident rather than by intent.
So there you have it. More than than you ever wanted to know about the simple little <p> tag.
Do you write paragraph tags in HTML like this:
The quick brown fox jumps over the lazy dog.
<p>
The five boxing wizards jump quickly.
<p>
Amazingly few discotheques provide jukeboxes.
Or do you always close them between paragraphs, like this:
Sixty zippers were quickly picked from the woven jute bag.
<p/>
A quart jar of oil mixed with zinc oxide makes a very bright paint.
<p/>
Jackdaws love my big sphinx of quartz.
Or do you enclose the paragraph itself, like this:
<p>
Sphinx of black quartz, judge my vow.
</p>
<p>
How quickly daft jumping zebras vex.
</p>
<p>
Jinxed wizards pluck ivy from the big quilt.
</p>
Just thinking about the history of HTML…
Step 1)
Download and put decorator.py from Michele Simionato’s decorator module in your path.
Step 2)
Add the following generic memcaching decorator to your views.py:
import logging
from google.appengine.api import memcache
from decorator import *
CACHE_EXPIRATION = 3600
def cacheable(keygen=None, expiration=CACHE_EXPIRATION):
"""A decorator that caches results in memcache.
keygen:
A function that returns the cache key based on the *args and
**kwargs of the function being called. If keygen is
not specified, the first positional argument will be used.
expiration:
The length of time to cache the response in seconds.
"""
# Define the decorator itself as a closure within cacheable
def call(f, *args, **kwargs):
# Don't use the cache at all if there is no expiration
if not expiration:
return f(*args, **kwargs)
# Use the supplied keygen to create a local cache key
# or use the first positional arg if none is supplied
if keygen:
local_key = keygen(*args, **kwargs)
else:
local_key = args[0]
# Create a global cache key that remains stable across instances
global_key = '%s:%s:%s' % (f.__module__, f.__name__, local_key)
logging.debug('Checking cache for %s' % local_key)
result = memcache.get(global_key)
if result:
logging.debug('Found %s in cache.' % local_key)
else:
logging.debug('Cache miss for %s.' % local_key)
result = f(*args, **kwargs)
logging.debug('Caching %s' % local_key)
if not memcache.add(global_key, result, expiration):
logging.error('Error caching response for %s.' % local_key)
return result
return decorator(call)Step 3)
Define a key generation function for http requests. This one ignores query parameters, but yours probably shouldn’t. By default the caching decorator uses the first parameter of the function call as the key, but in the case of http requests, we’ll use the request path.
def request_keygen(request, *args, **kwargs):
"""Returns a key based on the request path.
Args:
request: The http request object.
"""
if not request or not request.path:
raise ServerError('First parameter must be a request with a path.')
return request.pathStep 4)
Apply the decorator to any view corresponding to a GET request. The key will be the request.path, so if your logic uses query parameters be sure to modify request_keygen accordingly.
@cacheable(keygen=request_keygen)
def HomeView(request):
"""Prints the homepage"""
return render_to_response('home.tmpl')Step 5)
Use the decorator anywhere you’d like to cache the response in memcache.
@cacheable()
def get_url(url):
"""Retrieves a URL and caches the results.
Args:
url: A url to be fetched
Returns:
a http response
"""
return urlfetch.fetch(url)Step 6)
Sprinkle liberally.
Many new mobile devices, such as a T-Mobile G1 running Android, have barcode scanners that can extract URLs automatically from QR codes. Already popular in Japan, QR codes provide a mechanism for encoding arbitary data in an error-tolerant image format, offering a flexible way of distributing information like URLs in a machine readible form that can be emailed, printed out, or displayed on a screen. While OCR techniques are steadily improving, QR codes are significantly easier for a machine to read than strings of characters, and sometimes work better than publishing a URL directly.
The Google Chart API has support for generating QR codes, and we can use that feature to create a browser bookmarklet that makes it trivial to generate a QR code for any site on the fly.
Simply drag this bookmarklet to your browser toolbar:
Now visit any site you like and click on the ‘QR Code’ bookmarklet. A new window or browser tab will open, and in it you will find your QR code. You can download this image and email it around or print it, or you can save the URL and use it directly in a <img /> element and embed the code on your own pages. Anyone with a QR code scanner on their mobile device can easily navigate to the site just by holding their phone up to the code and scanning it in.
For example, here’s the QR code for http://blog.unto.net/:
This QR code was generated via the URL:
http://chart.apis.google.com/chart?cht=qr&chs=300x300&chl=http%3A//blog.unto.net/
Enjoy!
