Rating System

I have now integrated a rating system to blummy. You can rate blummlets at the “view code” page and the “Rate” link on the top left.
Furthermore there is the first library function for blummy: Blummy.getSelection(). It will retrieve the selection not only in IE and Firefox but also in Safari. If no selection is given you can add a string as parameter that will serve as question in the prompt box.

blummy, rating, library, api

Bugfixes and Interface improvements

I’ve released a new revision of blummy with the following changes:

  • [Bugfix] Improved HTTP Headers for Caching (now ETag and Last-Modified).
  • [GUI] Now there is a loading sign for ongoing searches.
  • [GUI] Predefined searches such as Random or Most Popular have been moved to tabs.
  • [GUI, Feature] You can resize a blummlet now by using the shift-key.
  • [GUI] A grid is shown on blummy to make it more obvious that the drag and drop function provides snapping to that grid.
  • [Feature] You can now specify to be logged in automatically on each visit.

The first point may be the most important one. It should improve speed of loading enourmously. Please give me some feedback if it works for you. Also any other feedback such as feature requests or bug reports are welcome.

Improvements

There are some new features I have implemented lately.

  • There is a random blummlet display
  • Search shows how many pages there are all in all.
  • You can also chose presets (empty, anon) so that you can easily start over or start from the anonymous blummy such as on the first page.
  • You can copy an uneditable blummlet to correct an error in another blummlet.

Blummy Feedback Roundup

People seem to like blummy very much :) There have been several blog posts about blummy in English, German, Spanish, Italian, Chinese, Japanese, and Korean (I was astonished that Google Translate — accessible via blummy ;) — was able to translate all these languages to understandable English):

Software As She’s Developed: Blummy: The Mother of All Bookmarklets

Ajaxian: If you are one of those people who love bookmarklets, and your bookmark toolbar is getting larger and larger for it, then this could be for you.

Max Kiesler: Blummy is […] in my opinion this is the best free apps of its kind. […] I review countless numbers of ajax and rails widgets, functions and apps every week but Blummy is truly a new and useful app that everyone who adds content to multiple websites should try.

UNEASYsilence: Blummy is the single browser bookmarklet to top them all. This nifty piece of javascript will single-handidly allow you to replace all your other favorite individual bookmarklets […] The screenshot does not do Blummy justice.

slapjack: Blummy Rocks. […] Maybe breaking free of the browser isn?t as important as I once thought.

Downloadsquad: Blummy: Configurable uber-bookmarklet – Today’s Browser Tip

Brandinfection: blummy – The Tool to end all Bookmarklets

The Social Software Weblog: Blummy addresses that problem quite admirably by collapsing a number of bookmarklets into one bookmarklet (or blummlets, as it were) to rule them all. […] It?s a bookmarklet aggregator. It?s the Flickr of bookmarklets, yo.

Libraryclips: This is a great idea, a place to keep all my bookmarklets to use on any computer, also relieves some space on my very heavy Links bar.

German: netbib weblog, Sprblck

Italian: dowload blog, SKY TG24, Tutto Gratis

Spanish: Microsiervos, Genbeta, ñblog

More: WebLeOn (Chinese), PleasureDelayerDiary (Japanese), Korean Jurist, Linmagazine (Hebrew)

Thanks for the feedback!

blummy, feedback, blog

Introducing: Blummy

So the project I’ve been working on lately is called blummy.

blummy is a tool for quick access to your favorite web services via your bookmark toolbar.
It consists of small widgets, called blummlets, which make use of Javascript to provide
rich functionality (such as bookmarklets).

blummy in action

You can create your own blummy by drag-n-dropping blummlets onto it.

It’s hard to explain unless you’ve tried it yourself. So Come along. (it’s free, of course)

blummy, ajax, bookmarklet, bookmark, favlet

Eclipse Everywhere. Buah.

It’s been a little quiet lately. This is because I am working on a cute little project that I will be able to present soon. More when the time is ready.

There has been rumor lately that Zend (developer of PHP) will release a PHP Framework. This is nothing new, there has been a IDE (Zend ) for a long time now. But it will be based on Eclipse.

Also Macromedia announced that their new Flex 2.0 environment (Flashbuilder) will be based on Eclispe.

Why on earth Eclipse?! I think this is the most slowest IDEs available. It’s based on Java which makes it incredibly slow already and it’s so blown up that it’s unbelievable.

I just can’t understand why developers would use such a tool. I am not willing to buy a GHz monster PC just to have an editor running there. That’s a pure waste of money and electricity. Emacs is kinda slow already but it runs on a few MHz.

Can anyone explain to me why to use such a monster?

I thought that maybe everything changed for the better by now and downloaded the whole thing. That’s 100MB already. This already shows how much memory it will consume. Ok, I still started it. It took more than 2 minutes on my Powerbook G4. Hello? The features it provides are so not worth that.

I can recommend TextMate (best completition) and EditPlus (best integrated (S)FTP). These are fast, neat text editors. That’s what I want.

eclipse, zend, php, flex, textmate, editplus

Caching of Downloaded Code: Testing Results

Today I did some experimenting with the caching of downloaded code (or On-Demand Javascript, whatever you want to call it).

I’ve set up a small testing suite that currently tests 3 different ways of downloading code: script-tag insertion via DOM, XmlHttpRequest as a GET and XHR as a POST.

These are my results for now:

Method IE6 Firefox 1.07 Firefox 1.5b2 Safari 2.0 Opera 8.5
script_dom cached cached cached cached cached
xhr_post not cached not cached not cached not cached not cached
xhr_get cached not cached cached not cached not cached

(Results are the same for Win and OS X where both browsers are available (FF & Opera))

Safari Code Downloading Cache Test

This gives an interesting picture: Firefox does not seem to cache any scripts, neither the ones loaded via DOM nor those loaded via XHR. Only IE loads an XHR GET request from cache.

I’ve got the script in my public testing area, so you can test it for your own browser. Please do so and correct my values if you receive different results.

The sources of my tests are available, too: index.phps and js.phps. I did my testings using the latest prototype.js library. Maybe I will try it later on with another library (e.g. with dojo.io.bind).

I’d be interested in more ways to download code (especially via document.write since I haven’t been able to include this properly to my tests) and in your results for other browsers. Just leave a comment.

UPDATE: I have now included the Expires header field with the Javascript file. Now FireFox in both version caches the script with script_dom, in version 1.5b2 it also caches XHR with GET requests.

XmlHttpRequest, caching, prototype.js, test

Better code downloading with AJAX

I’ve been playing with Code downloading (or Javascript on Demand) a little more.

Michael Mahemoff pointed me at his great Ajaxpatterns in which he suggests a different solution:

if (self.uploadMessages) { // Already exists
return;
}
var head = document.getElementsByTagName("head")[0];
var script = document.createElement('script');
script.type = 'text/javascript';
script.src = "upload.js";
head.appendChild(script);

Via DOM manipulation a new script tag is added to our document, loading the new script via the ‘src’ attribute. I have put a working example here. As you can see this does not even need to do an XmlHttpRequest (XHR later on) so it will also work on browsers not supporting that.

So why use this approach and not mine? Initially I thought that it was not as good as doing it via XHR because you receive a direct feedback (i.e. a function call) when the script has been loaded. This is per se not possible with this technique. But as in good ol’ times a simple function call at the end of the script file will do the same job (compare source codes from the last example and this one (plus load.js)).

Using this method to load code later on also provides another “feature” (thanks for that hint to Erik Arvidsson): Unlike XHRs Firefox also provides a cache for scripts loaded that way. There seems to be a disagreement about whether this is a bug or a feature (people complaining that IE caches such requests while it could be quite useful in this scenario).

When using dynamically generated javascript code you will also have to keep your HTTP headers in mind (scripts don’t send them by default). The headers Cache-Control and Last-Modified will do usually (see section 6.1.2 of my thesis)

The method above is also the method used by Dojo, a developer (David Schontzler) commented, too. He says that Dojo also only loads the stuff the programmer needs, so little overhead can be expected from this project.

Also Alex Russell from Dojo left a comment about bloated javascript libraries. He has some good points about script size to say (read for yourself), I just want quote the best point of his posting:

So yes, large libraries are a problem, but developers need some of the capabilities they provide. The best libraries, though, should make you only pay for what you use. Hopefully Dojo and JSAN will make this the defacto way of doing things.

So hang on for Dojo, they seem to be on a good way (coverage of Dojo to follow).

Finally I want to thank you all for your great and insightful comments!

ajax, dojo, code downloading, javascript on demand, caching, http headers

No Google Office To Be Expected

According to an interview of Sergey Brin (founder of Google) by John Battelle, Google does not plan to publish a web based office, as rumored before (fueled by a new partnership between Google and Sun (owner of openoffice.org)).

“I don’t really think that the thing is to take a previous generation of technology and port them directly,” he said. I agree with that. We have to think about new tools to be our future web apps. Just porting office apps to the web won’t work.

So what’s this deal about now? Google seems to want a wider distribution of their toolbar. According to the Cnet coverage (via John Battelle again):

“Details about what exactly that will entail were vague at best, with the only nugget offered being that Sun, in the immediate future, will make Google’s toolbar a standard part of the package when users download Sun’s Java Runtime Environment from the server seller’s Web site.”

Sergey Brin further stated that distributed thin web applications allowed you to do “new and better things than the Office package and more.” So further tools by Google can be expected.

google, office, sun, openoffice, ajax