Saturday, March 29, 2008
What sucks most about the Mac
.. are those nearly weekly software updates which require a reboot. I didn't buy a Mac because I was influenced by those all-day-long digging mac fanboys, I bought it because I wanted to run some graphics and video editing software which is not available for Ubuntu Linux (my previous desktop system, from windows I stay away as far as possible) and for paying about twice the price compared to a similar Dell or noname hardware configuration capable of running Linux, I really expected a better user experience in every possible aspect, as promised in their glorified advertisement. But the requirement to reboot the machine for those nearly weekly minor updates really puts the Mac back into the stone age of computing !
Friday, March 28, 2008
Doloto - Javascript Rewriting paper by Microsoft
I just read the reseach paper (pdf) about Doloto a Microsoft project for speeding up Web 2.0 applications by serverside Javascript static code analysis, AST transformations and code splitting. They claim that with this technique the loading time of monolithic (all Javascript loaded at once) Ajax applications can be significantly reduced. In my opinion, a better approach is to build right away non-monolithic apps (Javascript libraries like dojo provide support for that).
Wednesday, March 26, 2008
Crary - A new Erlang lightweight web server
Beside of featherlight iserve and battle proved mochiweb (at MochiMedia), there is now an additional choice for lightweight Erlang HTTP servers: Crary, which shares similar design goals but provides a different interface. According to its author Scott Parish:
Crary, a HTTP server for the REST of us.Below a tiny little snippet illustrating how to write a hello world program with crary:
The intention is that its small enough and flexible enough to be used for most any HTTP server need. While it isn't a stand-alone system, nor does it have its own web-framework, these things can easily be built on top of crary. Crary should be easily embedded into the release of a larger application to provide a web interface or to create a web service interface.
start() ->To get your copy of crary just clone it from its git repository, or install it via erlware.
crary:start(8080, {?MODULE, handler, []}).
handler(#crary_req{method = "GET", uri = #uri{path = "/favicon.ico"}} = Req) ->
crary_dir_listing:write_file(Req, filename:join([my_doc_root(), "favicon.ico"]));
handler(#crary_req{method = "GET", uri = #uri{path = "/test"}} = Req) ->
crary:r(Req, ok, [{"content-type", "text/html"}], <<"hello world">);
handler(#crary_req{method = "GET"} = Req) ->
crary:not_found(Req);
handler(Req) ->
crary:not_implemented(Req).
Tuesday, March 25, 2008
New YouTube player - Nice, but still not ready for HD screencasts
Geoff Stern, the Google guy who recently rewrote the YouTube player, just posted an interesting demo, mashing up the video player with the Google maps API, demonstrating the new player's Javascript integration capabilities.
Other examples out there:
This brings new possibilities for screencasts (or video presentations / podcasts), for syncing the audio/video with text caption or any HTML content along the audio/video timeline. Now I am just waiting for YouTube not destroying anymore the HD quality of uploaded quicktime videos when they convert it to flash (requiring cumbersome hacks like this for online HD flash video), so that YouTube can eventually be used for high quality screencasts and video enabled online presentations.
Update: more chromeless players:
Other examples out there:
This brings new possibilities for screencasts (or video presentations / podcasts), for syncing the audio/video with text caption or any HTML content along the audio/video timeline. Now I am just waiting for YouTube not destroying anymore the HD quality of uploaded quicktime videos when they convert it to flash (requiring cumbersome hacks like this for online HD flash video), so that YouTube can eventually be used for high quality screencasts and video enabled online presentations.
Update: more chromeless players:
Sunday, March 23, 2008
Erlang processes benchmarked against threads of other languages
We all know that the result of benchmarks are only significant for that specific piece of code which is getting tested, and usually the benchmark authors favorite products are tuned to outperform its competitors. Nevertheless, below a summary of a benchmark recently discussed on reddit. The benchmark itself is just a few lines of source code (at least in Erlang), spawning a bunch of processes and doing some simple message passing between those processes. Thread implementations in other languages:
- C (pthread - GNU gcc): 8.5 times slower
- Python: 15 x slower, 1.4 x more memory
- Java: 20 x slower, 5.8 x more memory
- Ruby: 282 x slower, 3.4 x more memory
Subscribe to:
Posts (Atom)