October 16, 2009

Pushing Erlang with xmlrpc

To help contribute to the Erlang community I've published my hacks over xmlrpc Erlang library.

This library has already received various patches that you can found around the web. I've decided to rather build a repository in the hope that it might drains contributions and help keep this library alive.

October 10, 2009

AppEngine next language ?

Python, Java, ...
Java also opened the door for JRuby. The next language could be a less generic one. The upcoming Wave service powered over XMPP and suggesting OpenFire server for support could well be the application killer boosting Erlang language via a server like ejabberd.
Erlang is opensource, powered by a virtual machine, highly suitable for network oriented applications. Surely the community around the language is sparse but it's gaining more and more interest as people face threading problems.

September 18, 2009

Mind the limits !

Running load simulator programs from linux might lead you to a limit ! This limit is often met through messages like :
Too many opened files

or in Erlang a more criptic message for the newbie :

It means you've bump on the hard limit of opened files by processes.
Changing the values in /etc/limits.conf or /etc/security/limits.conf will allow you to raise those limits.
Don't forget to close all your shell sessions to allow the system to effectively raise the limit !

May 2, 2009

OOPHM mode with GWT on OSX

Suffice to say that UsingOOPHM and building GWT from source allows to launch this mode
ant oophm
The behaviour of the interface is a little bit rough on the edges though on OSX.

Building GWT from SVN on OSX

Building GWT from svn trunk is documented in Making GWT Better.
But the compile process invoke a nasty parsing of svn info command which fails if your langage setting is not english.
You'll find that in build-tools/ant-gwt/src/com/google/gwt/ant/taskdefs/SvnInfo.java :

* A pattern that matches the Repository Root line in svn info output.
private static final Pattern ROOT_PATTERN =
Pattern.compile("\\s*Repository Root:\\s*(" + URL_REGEX + ")\\s*");

This pattern fails miserably on svn info like this :
Chemin : .
URL : http://google-web-toolkit.googlecode.com/svn/trunk
Racine du dépôt : http://google-web-toolkit.googlecode.com/svn
UUID du dépôt : 8db76d5a-ed1c-0410-87a9-c151d255dfc7
Révision : 5320
Type de noeud : répertoire
Tâche programmée : normale
Auteur de la dernière modification : jgw@google.com
Révision de la dernière modification : 5320
Date de la dernière modification: 2009-05-01 22:23:02 +0200 (Ven, 01 mai 2009)

I had to switch form iTerm to Terminal to achieve a good setup of my environment to achieve a sucessful building.
In Terminal preferences uncheck the LANG setting flag and in your shell do

export LANG=en_US

This should be enough to build GWT successfully !

PS: Pay attention to not interfere with JDK 1.6 if you have it installed on your machine.

September 13, 2005

Ajax libraries

Jean-Marc Orliaguet jmo at ita.chalmers.se on Z3lab mailing-list Thu Jul 14 21:26:20 CEST 2005


I've been testing various "Ajax" libraries recently and these are my
impressions (they correspond to the use cases that I have, others
certainly have other needs):

- first of all there is a lot of buzz around Ajax, when you start
looking for an Ajax framework you are likely to find all sorts of
libraries that do just anything on earth: drag-and-drop, visual
effects, animations, sortable lists; they belong to the "Application
framework" category.
Then there are the XMLHttpRequest wrapper libraries (belonging to the so
called "Infrastructure framework" category).

- some of the libraries are meant to be kept simple and lightweight,
others are really heavy-weight libraries. The Rico [1] / Prototype [2]
libs for instance take a lot of CPU on every page load (up to 3 or 4
seconds depending on your hardware). You really feel it when you tune
down your CPU to 800MHz. Obviously you are not supposed to reload the page.

- for drag-and-drop stuff, contextual menus, etc. I find that PDLib [7]
is just fine for what I need. It has the advantage compared to the other
libraries that I've seen so far to refer to classes of elements as
opposed to a collection of element Ids. The Rico lib [2] and
script.aculo.us [3] for instance need to register as many Ids as there
draggable and droppable elements. With PDLib, you just have to declare a
CSS class as draggable and a class as droppable. That makes a difference
when you have lots of elements on a page. The only problem with the
PDLib library is that there are a lots of versions around. I have done
some local modifications on it for CPSSkins [8] with bug fixes from
CompositePack [9], etc.

- By the way: what does drag-and-drop have to do with AJAX?
drag-and-drop has been around for years... My impression is that it is
better to keep the XMLHttpRequest part separate from the fancy stuff.

- So the next question is: what is the core functionality you'd expect
from an "Ajax" JS library? I've done a list of use cases for cpsskins
and it all comes down to one thing: being able to send requests to the
server and getting the result of the request inserted into the page in a
given place without reloading the page.

- An important factor is that it should go fast, so I started to look to
'lightweight' libraries [5] [6] with the minimum number of features
implemented. Sarissa [4] has a lot of XML/XSLT features that I feel
could as well be implemented in zope and that I presently have little
need for.

So I tested 'DataRequestor.js' [5] which is exactly what I need (simple
to use and fast).

- I've set up a test / demo page that updates a fragment of a page with
the date fetched from zope every time the uses clicks on the button:

- Conclusion: be careful with the buzz that surrounds Ajax, identify the
needs of your application, do benchmarks.

I hope that this review can be useful.

[1] http://openrico.org/demos.page - rico.js (69kB ...) + prototype.js
[2] http://prototype.conio.net/ - prototype.js (28kB)
[3] http://script.aculo.us/ - dragdrop.js (19kB) - effects.js (21kB) +
prototype.js (28kB)

[4] http://sarissa.sourceforge.net/doc/ - sarissa.js (27kB)
[5] http://mikewest.org/projects.php?action=viewProject&projectID=1 -
DataRequestor.js (16kB / documentation included - 6.4kB without the doc)
[6] http://xkr.us/code/javascript/XHConn/ XHConn.js (1.4kB)

[7] http://svn.zope.org/pdlib/trunk/
[9] http://plone.org/products/compositepack

August 5, 2005

The amazing web

Who can image what the web will look like in two years ?
If you look back in time on what the web look like in 2002-2003...
Where Google was ?