Skip to main content

Posts

Showing posts from October, 2005

Starring and searching in Flock is great!

Amongst a host of others, Flock realizes an idea I had a while ago and told Google about: a real simple way to remember a site. In Flock, it's called to "star" a site. Very quick. No folder selection. And with full text search. This is exactly right. Because at the moment I am starring the site, I am really ready to move away from it again. I don't want to bother with classification. When, later, I look for it again, I will probably remember enough about it so I can find it using the history search.
My own idea went like this. I was going to create a small extension to Firefox that would, at the press of a hotkey, add the current page to my "trail", a list of tagged pages. This list I would periodically upload to a publicly reachable web server in a very special format. All the link texts would contain a unique number assigned to me (a GUID probably). Then I would submit the list to Google for reindexing. When, later on, I need to search through my trail, I …

Procrastination

So now I know how to call it: procrastination. And now I know I am not alone by far. My own reaction lately was to consciously start thinking and writing more again (as you can see here, at least the latter part), and I implemented a tool that monitors my activity throughout the day so at least I can, at the end of a work day, see what ate the time. Seems someone else had a similar, albeit even more radical idea: he blocks apps from himself.

Just found TracksLife, too. Interesting take on what people might use easy-to-setup structured databases for.

StructuredBlogging

Just came across the site StructuredBlogging. This addresses kind of the same problem I want to address with the emergent data entry language. Make it easy for people to add structure. However, it seems that StructuredBlogging requires effort by someone to create the structure in advance of it being used, whereas the emergent approach lets non-technical people add structure of their own.

Debugging Domain Specific Languages

One of the problems with debugging domain specific languages (DSLs) is that a single DSL construct is often mapped to a multitude of aspects in the generated code or generic implementation. Thus, the classic concept of a breakpoint is difficult to interpret.

However, it seems to me that this could be overcome fairly easily. Simply allow users to set breakpoints targeted at specific aspects of the system. Once you think about this, it becomes clear that such breakpoints might even be useful in mainstream generic languages with non-trivial framework support, such as Java or C#. Imagine, for instance, being able to set breakpoints on a class declaration that trigger when an instance is constructed, serialized or deserialized. Now, I know you can do this by overriding the corresponding methods and setting a breakpoint there. Cumbersome, but workable. What, however, if the feature designer did not allow for overriding the aspect? Imagine such a class breakpoint triggering when an instance i…