Google Sidewiki

Web-wide comment toolbars aren't new, although the web-scribblers I've tried before were barely social, never mind wiki-like.

But, Google as usual comes in with the simplest (to the user) implementation: SideWiki (official blog post)

If you are the verified owner of a site in Google Webmaster Tools, Sidewiki lets you "Write as the site owner", pinning your messages to the top.

There's some worries around about sidewiki "stealing" blog comments or fracturing the conversation around a page: but much same goes for Facebook, Twitter, Digg, Reddit, Friendfeed, etc. Facebook et al even add headers to shared links so that comments can go to facebook rather than the website.

A notation for nested data structures in Python

The Python programming language makes it easy to compose collections into nested hierachies, built up from lists, dictionaries, tuples and objects with generated attributes. One can put together a dictionary that maps a pairs of strings to lists of objects whose "calls" attribute is a dictionary mapping ints to pairs of dates and whose "topics" attribute is a list of integers. If for some reason such a nested data structure is actually returned by a function (e.g. to fill a complex report template), anyone using it will also need to understand what it holds. So, I've been refining a notation that I use in docstrings to concisely express the structure a composition of collections. Here it is by example:

• List of strings: [name]
• Set of strings: {name}
• Pair of string and int: (name, age)
• List of tuples: [(name, age)]
• Dictionary from strings to dates: {firstname: birthdate}
• Object with dynamic attributes: .name .age .phones=[phone]
• Putting it all together: {(country,city): [.name .phones=[phone]]}
• Example from the intro: {(name1,name2): .calls={phone:(start,finish)}, .topics=[topicid]}

The notation as it stands describes the semantics of a collection or composition of nested collections and not the types of the collected objects, but it could be extended to do so, for example {firstname<string>:birthdate<date>}, although the types are redundant in that case. In languages which lack convenient collection types, one would typically define classes for everything named above. There would be an Address class having "country" and "city" fields, a Person class having "name" and "age" and "phones" fields and a PersonPair having "name1" and "name2" fields and a DateRange having "start" and "finish"... which is fine if a lot of code relies on PersonPair objects and makes the structures explicit, but is annoying for throwing together ad-hoc collections.