Skip to main content

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 simply send a search request to Google with the special condition that only pages linked to from links with this unique number in the link text are to be searched (this is a feature of Google's advanced search, configurable in the "Occurrence" setting). Neat, huh? But embedding Lucene in Flock is, of course, even better, although it does hog my disk space instead of Google's.

Comments

Post a Comment

Popular posts from this blog

Threaded chat article and demo

While nothing major, managing threaded conversations in chat has bothered me for quite a while. Yesterday I had an idea on how to improve matters: Works using existing chat infrastructure. Needs only augmented clients. Plays well even if other party uses a non-thread aware chat tool. Separates threads automatically based on interaction patterns. I've written an article and have created an online demo about it. Discussion welcome.
4 comments
Read more

Beyond TDD: Documentation Driven Development

There are quite a few articles extolling the virtues of test-driven development these days ( here's one ). And for good reason, too. Having done TDD for quite a while, I recently started combining it with documentation-driven design. This is what my open-source tool, JCite , is all about. With this approach, I sketch out the most important use cases, combine them into the index of a tutorial (links plus teasers summarizing the use-case), flesh out the tutorial topics (and thus use-cases) one by one, develop the use-case tests in parallel to each topic, cite the important parts of the tests as actual code samples into the topic, and only then start doing the implementation (this last step is accompanied by more tests, which are now more like unit-tests). In all, this is like literate programming, but of the use-case tests rather than the implementation code. TDD already helps to make you focus on the user during API design. DDD takes the effect further by making you tell consistent ...
Post a Comment
Read more

RSpec and BDD - something crucial missing?

RSpec Site : "RSpec provides a framework for writing what we call executable specifications of program behaviour. Since that’s rather wordy, we usually just call them specs. Some other people call these things examples." If I take a look at the examples on the RSpec site, I cannot help but wonder if just doing this (which they term "behaviour-driven development"), misses out on an important aspect of API documentation and the thought processes that should go into an API design. The missing element is explanation . In my experience, unless I force myself to explain my decisions to an audience (even a hypothetical one), I come up with too complex designs, inconsistent naming, and just generally too much hassle for the users of the API. Sometimes, complexity is warranted. But then, I believe it is important to justify it to your users. Show them why it's there. The RSpec approach is, as I see it, simply a very concise way to write your tests twice: once in natural...
1 comment
Read more