2008-08-20

The inter-social-net

I knew it!
Portuguese are obsessed with hi5, Finnish love the vast amount of metal last.fm has, and whaddahell is friendster? It seems like it is unknown in Hungary:)

More interesting results here.

Whitespace as a programming language

...so you thought LOLCODE was the craziest programming language? FAIL.
Whitespace uses only 3 symbols (space, tab and line feed) to markup assembly-like instructions, everything else counts as comment:) I will not paste here the classical hello world snippet, because i am afraid blogger will mess it up, but to "see" the full source code, you can visit this page :)

CSS frameworks

Some time ago CSS "frameworks" were growing out of the ground like mushrooms after rain. Now we have at least a dozen, and the number is growing.
I have always wondered what similarities/differences they have, who knows, i might use one of them in the future. The answer comes from Eric Meyer, who has made some comparisons recently, which was summed up Jeremy Keith in this article. A good reading if you have two minutes.
Some other info on the topic can be found here and here.

2008-08-12

Reduce the size of your SVG

...so recently i was playing with SVG, and i wanted to embed an older version of this map of Europe into my html . Currently it is about 500 KB, but as far as i remember, it was even heavier. Pretty bad, if you want to inline it, and your visitors have to download it. So how did i reduce the size to one tenth of it?

gzip?
Yes, gzipped version of SVG exists, but not when you inline it, so its a no-go in my case.

delete unnecessary regions
I didn't need Greenland and Russia for example, so i just erased them from the source file.

delete unnecessary metadata
My file was scattered through with inkscape:xyz and some other editor's metadata, which might be useful when editing the file, but useless when i publish it on the web. They had to go.

group and style wisely
Don't repeat the same styles/transformations on many elements, use grouping instead (<g> element)

remove unnecessary transformations
A lot of my regions contained a very little translate transformation, which had no visible result at all, so i chucked them out.

compact path data
According to the SVG specs, you can reduce the size of your path data by removing redundant white spaces from around commands and coordinates. Works great!

simplify path data
Ok, this one you will not be able to do in your text editor. The idea is to reduce the number of coordinates required to describe a path. Even if it means you will have a less precise path, the result might be satisfying. To do this, you have to have Inkscape. Select an area, and you will see in the status bar the number of nodes it consists of. Now select path/simplify from the menu. If you are lucky, your number of nodes will be less, if you are not, it will actually be higher:) For me it worked best, when i set the simplification threshold (Edit/Preferences - Misc) from 0.0020 to 0.01. Yes, you will have visible deviation from the original path, but in my case it was acceptable. Also note, that under a certain number of nodes (for me it was around 80) it is not worth to run the simplification.

reduce coordinate precision
Ok, so i still had (and you will most likely have) a precision of four decimals in my path coordinates. What if i reduce it to 3/2/1/God forbid zero ?! Yep, no visible impact on the web, but huge saving on the filesize! This is the ultimate file size killer, if you can afford it.

NOTE: Other good tips you can read here and here.

2008-08-09

Ext 2.2 is out, but where are the old releases? [UPDATE]

If you like Ext JS, the new 2.2 version brings out some nice features for you. No question Ext is a great library and worth to play with, despite the recent disputes around the license change from LGPL to GPL.
My only frustration with Ext was only a few days ago, when i was about to make modifications in an open source project that had an earlier Ext 2.0 bundled, but not fully! So where can i get the full Ext 2.0 package to add some adapter files that were missing?
  1. Ext website? Forget it. On the download page you can only download the latest, on the "build your own" page you can have 1.1.1 and 2.1. No matter if you try to trick the forms, you will not get any 2.0 version :)
  2. Second idea: SVN! Hehe, forget it. Ext JS does NOT have open SVN access (that is free).
  3. Hmm, if you read the threads around the license dispute, you will eventually come accross a project that forked (basically just copied and published) the latest 2.0.2 LGPL version of Ext. It is called openEXT, a few days ago it was still available on sourceforge, by now it seems to have vanished. Anyway it was questioned if this fork was legal or not, so the question is still: where can we get a legal copy of 2.0?
  4. My frustration grows. What next?
  5. The idea pops out: lets look up some open source projects that use Ext, and have access to past releases. I am sure there are many, but the one i had immediate success with was SugarCRM. Download version 5.0.x, and there you go!
NOTE: I have no intention of ruining the business of ExtJS here, my only intention was to fix something that used an older version of Ext. Putting aside licensing questions, i strongly believe that closing down the access to older versions is rarely a good idea. It contradicts the philosophy of open source and the Internet itself.

UPDATE!

As Anonymous pointed out in the comments, the old releases are indeed available on the ExtJS website!
To my defense to reach it you have to go: home - support / community / learning center - API Reference and Demos(?) / Archived downloads of previous releases. Not the most logical you would say, and no link from the downloads page. Also if you ask Google who links to this page, you will get zero result. It doesnt appear in their robots.txt as disallowed, yet somehow it is not being indexed.

UPDATE2: OpenEXT seems to be back by now.

UPDATE3: There is a gcode project called extjs-public, which provides svn access to publicly released Ext JS versions. It seems to hold releases beggining of 2.0.2. Enjoy!

2008-08-01

Javascript documentation tools

...so you were a good programmer and you have added javadoc style comments in front of your javascript functions/classes/methods? Good boy! Now lets see what you can do with them. Solutions in order from worst to best (just to keep you entertained):

Javascript Documentor (JSD)
It is java based what would be super useful in ant scripts, however it expects me to write comments like:

/// <name
>MyFunction</name>
/// <param name="param1">The first parameter passed in.</param>
/// <param name="param2">The second parameter passed in.</param>

Whaaaat?
1. Programmers will NEVER write that much metadata
2. Javadoc syntax is already de-facto standard, why invent a new one?
3. Javadoc syntax is already supported by many IDEs/editors
Next, please!

jGrouseDoc
Well, first of all, have you guys ever seen your page in Firefox? You would be disappointed for sure, as it gives a big blank page. Yes, i know you were trying to be smart with some ajax content loading, it just didnt work.
Anyway, after switching to IE, and downloading the tool, it turns out that it is java based, it can nicely be integrated with ant (it even comes with a fairly complex build script), but the only thing it recognized in my javascript file was... the filename itself. Hmm, thats good for a start, but lets move to the next one.

NaturalDocs
It is PERL based. It is meant to be a documentor for multiple languages, javascript not being among the fully supported ones. Lets give it a try though. Issue command. Read manual. Issue command. Read manual. Ah, ok. Issue command. Generation done. Hmm, plenty of files and directories, but not a single html. Apparently it couldnt digest my file. Next one!

JSDoc
Not to be mistaken with the JSD above! Because this is good:) It is PERL based, and will be happily running after you have downloaded the HTML-Template package. It magically recognized all my kinky objects and methods, and generated a classical jsdoc for them. Well done, i will stick with this one.

JSDoc Toolkit [UPDATE]
Just to confuse you more, there is this "toolkit" version. It seems to be the younger brother of the above mentioned JSDoc, but it is completely javascript based. Getting rid of the PERL dependency is great but it comes at a price. The javascript based processing is terribly slow, you have to see it for yourself if it is worth to switch. If you decided to switch, you can find a nice template here.

NOTE: On this wikipage you will find a bunch of other documentors, some of them are general, a few, apart from the above mentioned, are specific for javascript.

Happy documenting!

UPDATE: jGrouse website is now functional.