Planet Erlang

OneChannel: a desktop Publish/Subscribe client for instant news delivery

Marek Foss — Tue, 08 Dec 2009 06:16:36 GMT

Today, ProcessOne launches a free, desktop Publish/Subscribe (PubSub) client. OneChannel will instantly receive new messages, minimizing the delay of distributing news updates and blog posts.

PubSub protocol uses XMPP and is much faster than RSS – imagine instant messaging, but instead of messages from friends, you get news and articles. And it doesn’t have to make feed requests, the new content is pushed straight to OneChannel once available. Moreover, it reduces the load on the servers. Instead of having thousands of RSS clients checking every hour for new content, they just have to wait for the data to be broadcasted to them.

We prepared several channels with IT articles, World headlines and ProcessOne messages, and soon you will be able to add your own channels to the collection. Since OneChannel is released as a public beta, please give us feedback and suggestions.

Note that most channels currently are coming from RSS, so the update interval is the one of the RSS polling. However, we will start pushing content directly in PubSub in the future.

We have build this client because we think PubSub is underused in the XMPP community and in the real-time web in general. This will allow the community to be able to use a client as a reference and basis to accelerate PubSub adoption.

For now, the client is able to render Atom or HTML payload (including embedded Flash objects like YouTube videos) only, but we plan to add new supported payload in the future.

To start testing, you just need a free account on the XMPP Sandbox, and the latest Adobe AIR Framework installed (available for Windows, Mac and Linux).

To download the PubSub client and learn more, go to OneChannel website.

RabbitMQ at the Skills Matter Functional Programming Exchange

Mon, 07 Dec 2009 10:37:30 GMT

Today I was lucky enough to give a talk at the Skills Matter Functional Programming Exchange. I talked about resource management in RabbitMQ and how we’re improving this in upcoming versions of RabbitMQ. All the sessions were videotaped and it would seem that a podcast will be going up shortly. In the mean time you can have a look at the slides if you want to.

The attendance was really good and the talks well received. There was a good range of talks, from some very practical and pragmatic such as my own, to slightly more theoretical talks. It was great to see Haskell, Erlang and F# being discussed outside of a purely academic setting and great to see so many companies and organisations getting really interested in functional programming and coming along to see how other people were making the most of it.

The Park Bench session was also good fun, with a good range of questions and experience being demonstrated by all. A good, fun atmosphere, and I’m sure all enjoyed the day.

Garbage Collection in Erlang

Mon, 30 Nov 2009 16:24:03 GMT

The new persister that is being developed for RabbitMQ is nearing completion and is currently working its way through code review and QA. It’s being pretty thoroughly tested and generally stressed to see what could go wrong. One of the issues that we’ve come across in the past has to do with Erlang’s garbage collector: indeed there’s code in at least one area of RabbitMQ written in a specific (and non-obvious) way in order to work around issues with Erlang’s garbage collection of binary data.

We had noticed in the release notes for Erlang R13B03, that it mentions improvements to the garbage collector, and today when testing with both R13B02 and R13B03, we noticed substantial improvements with R13B03. The new persister is able to send out to disk partial queues. Thus a queue can have a mix of messages - some just in RAM, some just on disk, and some somewhere in between. This is separate from whether or not a message is marked persistent. The proportion pushed out to disk varies smoothly with the amount of RAM left available to Erlang: the idea is to avoid flooding the disk with enormous amounts of write requests which would potentially stall the queue, and cause blockages elsewhere in RabbitMQ.

The test I’d written used the Erlang experimental client. It had one channel, it created a queue, consumed from the queue, set QoS prefetch count to 10, and then went into a loop. In this loop, it would publish two 1KB messages, then receive 1 message, and acknowledge it. This way the queue would always grow, and memory would be fairly fragmented (the gap from the head of the queue to the tail of the queue would increase steadily as the head is moving forwards at twice the rate of the tail). With no memory limit, I saw the following (I manually killed this after the queue grew to just over 350,000 messages long (which means 700,000 publishes, and 350,000 acknowledgements)):

Note that for R13B03, the garbage collector is much more active, and in general memory usage is certainly more fine-grained. In this test, all the messages were always in RAM, no messages were pushed out to disk. Flat-size refers to the value returned by pushing the queue state through erts-debug:flat-size/1 which returns the amount of memory used by the data structure.

Next, I imposed a limit of about 200MB and did the same test. With R13B02, it got stuck after just over 260,000 messages: it was no longer able to reclaim any further space, and so flow-control kicked in and stopped the publisher, game over. With R13B03 it soldiered merrily on - I ended up manually killing it somewhere past the 1million message mark as I was getting bored. It’s also very clear to see how with R13B03, it successfully kicks down to pushing all the messages out to disk (which is why the size of the state suddenly gets very small - the memory growth from there on is due to an ets table). That’s certainly still possible with R13B02, and I have seen that happen, but there’s much greater risk, as seen here, of it getting stuck before that happens.

In short, the garbage collector in R13B03 seems a solid improvement. Even if you’re not using the experimental new persister, I suspect you’ll gain from upgrading to R13B03. And yes, that really is 1-million 1KB messages successfully sent into a queue using under 200MB of RAM.

Introducing rabbitmq-status plugin

Mon, 30 Nov 2009 09:57:50 GMT

RabbitMQ is a becoming decent product, but it shares some of the common problems of young software - for example, beginners have a hard time understanding what happens under the hood. Don’t get me wrong, Rabbit generally works perfectly as a black-box. But at some point, when things go wrong or when Rabbit needs to be added to a monitoring infrastructure, it becomes necessary to understand more about the internals. This is when things get difficult.

I was wondering how we could address this issue and decided that Rabbit should serve a simple http status page similar to status pages that are known from Apache or Haproxy projects.

A picture is worth a thousand words, so here’s the screenshot of rabbitmq-server in action:

The status page shows memory, file descriptors and Erlang PIDS usage. You can also see basic information about connections and queues.

Installation

The installation is pretty straightforward. As with other RabbitMQ plugins, all you need to do is grab the compiled .ez binaries, put them in the correct place and then run the command: rabbitmq-activate-plugins.

Precompiled binaries are here (compiled using Erlang 5.6.3/R12B-3). They should work with RabbitMQ 1.7.0 and the latest default mercurial branch.

Step-by-step install instructions, checked on my Ubuntu Karmic box, follow:

wget http://dev.lshift.net/majek/rabbitmq-status_1.7.0.tar.gz
tar xvzf rabbitmq-status_1.7.0.tar.gz
sudo mkdir /usr/lib/rabbitmq/lib/rabbitmq_server-1.7.0/plugins
sudo mv rabbitmq-mochiweb.ez mochiweb.ez rabbit_status.ez \ /usr/lib/rabbitmq/lib/rabbitmq_server-1.7.0/plugins
sudo rabbitmq-activate-plugins
sudo /etc/init.d/rabbitmq-server restart

Usage

Once you’re done with that, you should be able to access the local webserver under port 55672. You need to supply valid RabbitMQ username/password. The default URL should work in most cases: http://guest:guest@127.0.0.1:55672/.

You can also get raw data in JSON format:

$ curl http://guest:guest@127.0.0.1:55672/json
{'bound_to': '0.0.0.0:5672 ', 'datetime': 'Sun, 29 Nov 2009 19:40:22 GMT', 'fd_total': 1024, 'fd_used': 31, 'mem_binary': 4317158, 'mem_ets': 1348072, 'mem_total': 'unknown', 'mem_used': 19856037, 'pid': '24561', 'proc_total': 32768, 'proc_used': 118, 'connections': [{'address': '127.0.0.1', 'channels': 1, 'frame_max': 131072, 'peer_address': '127.0.0.1', 'peer_port': 53700, 'pid': '<0.1052.0>', 'port': 5672, 'recv_cnt': 3271, 'recv_oct': 819137, 'send_cnt': 45, 'send_oct': 60139, 'send_pend': 0, 'state': 'running', 'timeout': 0, 'user': 'guest', 'vhost': '/'}, ...], 'queues': [{'acks_uncommitted': 0, 'arguments': '[]', 'auto_delete': 'false', 'consumers': 1, 'durable': 'true', 'memory': 371896, 'messages': 501, 'messages_ready': 500, 'messages_unacknowledged': 1, 'messages_uncommitted': 0, 'name': 'b', 'pid': '<0.1069.0>', 'transactions': 0, 'vhost': '/'}, …]}

The plugin is beta quality and is tested only on Linux. Leave us a feedback if you found it useful or if you have any comments.

New teeterl; 4x faster

Max Kharchenko — Sat, 28 Nov 2009 23:08:00 GMT

Three months ago I decided to give teeterl a once over. The goal was to make it faster, order of magnitude faster. Today, the new teeterl version has become mature enough to run estone_SUITE and produce meaningful performance measurement printout. The result: it is almost 4 times faster than earlier teeterl. Not 10x, but definitely on the right track. BEAM is still a distant performance star boasting more than 2 times more estones.

The new version of teeterl has a goodish bit under the hood. The most noticeable are the new partial, generation-aware garbage collector and the fact that teeterl VM is now register-based.

The new teeterl can not do much more than run a few test suites now. Nevertheless I will release the source of github as soon I figure out how to push it into existing 'teeterl' repo without destroying the previous version.

stdin/stdout in Erlang

Max Kharchenko — Sat, 28 Nov 2009 23:06:00 GMT

Erlang blogs and message boards are littered with messages expressing dissatisfaction with Erlang syntax, the language's handling of strings, verbosity of records etc. Members of the discontented crowd usually stop short when specifics are requested. I will try to make my small rant about Erlang as specific as possible.

My grudge is about stdin/stdout. Why would modern software need these? Existence of stdin/stdout assumes that Erlang is started from a text-based shell. These days it usually not the case. Why io:format() pretty-printing is crafted to output text on a screen of 80 columns? Erlang is all about non-blocking input/output and then there is io:get_line() getting text from nowhere. I am aware of Elang's telecom heritage and RS-232 interface. But this kind of thing definitely slows the adoption of Erlang in today's world of World-Wide Web.

The new version of teeterl does not have io module as it does not have stdin/stdout concept. On the other hand the new teeterl has had an embedded web server with comet functionality from day one. All input/output in the new teeterl is done through a socket and HTTP. Instead of io:format() there is format:to_json() call and all actual formatting including pretty-printing is done on the client side with jQuery/Javascript. Well, a printout still may appear on stderr but only as an epitaph on the tomb of init process.

Laying out VM vitals

Max Kharchenko — Sat, 28 Nov 2009 22:54:00 GMT

The teeterl's poor performance felt like a cold shower to me. And at the opportune moment I decided to have a closer look at why it is so bad. By then I had a scaffold implementation of a register-based teeterl VM. The new version was already churning out primes numbers in spadefuls without a hitch. But I decided to take two steps back and measure if the decisions I made were of any merit. It happened many of them did more harm than good.

For about a week I was rewriting my shiny new VM into a new application, cleverly named teepad, that was doing nothing but creating random stack frames, touching various memory locations, allocating chunks of memory from the heap, a dispatching random instructions from a dozens of garbage modules. It weighs heavily on a fellow's mind to write a simulation software of the sort. When someone laboriously develop a sizable do-nothing system for a long time, thoughts start to creep in. I am lucky it did not take too long. Now I have speed readings of the garbage mincer and can make a few observations.

Do not reenter VM's main function

As everybody knows the main function of a VM is where the huge switch statement is. I was toying with the idea of reentering the routine on every Erlang function call. Thus register values will be instantaneously back to existence after return. Well, Erlang process should yield from time to time, and I added a separate stack which was filled in when the process was yielding. Boy, it is probably the worst stack management scheme out there. teepad was able to dispatch 2.5 times more commands if such nastiness is avoided.

Keep the number of opcodes moderate

With teepad it was possible to boost the number of different opcodes to a sizable number increasing the number of cases in the master switch statement accordingly. I thought it would be neat to have an opcode for, say, 'move r1, r2' and another opcode for 'move r2, r3'. I was quite wrong again. teepad experiments showed that twice as many opcodes means 15% less throughput, 5 times - shaves 25% from performance.

Packing/unpacking of arguments does not matter

These days of multi-layered caches you may do any number of bitwise operations on a value already retrieved from memory. Take highest 6 bits, mask out 3 lower bits, add 7 to the result, do it on every dispatch and you won't tax your performance noticeably. Bitwise operations help to reduce the memory footprint of a VM and thus stimulate a better cache behavior that more than offset the additional CPU cycles burn of bit fiddling.

More details for someone who care

1. Instruction set generated from the types below:

Type	Prob	#variants	#args	Options
test	0.2	10	1-3	[branches]
enter	0.05	1	1-1	[reduce,jumps]
enterf	0.01	2	3-4	[reduce,jumps,intermodule]
call	0.02	1	1-1	[reduce,calls]
callf	0.01	2	3-4	[reduce,calls,intermodule]
bif	0.01	8	2-3	[reduce,heap]
move	0.3	10	0-2	[]
make	0.1	10	1-3	[heap]
select	0.1	5	1-3	[heap]
compute	0.1	20	2-3	[]
apply	0.01	2	1-2	[reduce,jumps]
'receive'	0.001	1	1-1	[yields,messages]
error	0.0001	1	1-1	[exits]

Implementation of each opcode is randomly generated using Options column, e.g. 'receive' instruction has 1 variant and appears once per each 1000 instructions. Its implementation may include unpacking its arguments, touching the mailbox memory and faking a context switch.

2. Modules are generated from instruction set using probabilities of commands of given type

# of modules is 10.
Module size ranges between 1000 and 100000.
Reductions before yield is, obviously, 1000.
Instruction arguments are packed (4 arguments into 1 word).

3. Generated program is compiled, run for 5sec and the number of instructions dispatched is reported.

The source code of teepad and raw measurement data are gladly provided upon an e-mail inquiry.

Python web app as an egg with Paste, Fabric and Spawning

Sat, 28 Nov 2009 04:23:00 GMT

One of the major success of PHP is how easily you can deploy PHP applications. Thanks mod_php for that. Python or Ruby requires quite more work even though it’s not that painful if your using something like Passenger with Ruby. I’m still looking for a way that I find brilliant. So I played with Paste, Spawning and setuptools to build a very minimalist WSGI application you deploy without any pain using Fabric.

Before we start, you can find the code bellow on GitHub.

First the setup.py file that describe our application:

from setuptools import setup, find_packages setup(name="app", version="0.1", description="example application", long_description="", keywords="", author="Yoan Blanc", author_email="yoan.at.dosimple.ch", url="http://yoan.dosimple.ch/blog/", license=’All rights reserved’, packages=find_packages(), zip_safe=False, install_requires=[], entry_points={"paste.app_factory": ["main=app:make_app"]}, )

It’s all standard except the entry point called paste.app_factory that will be used by Paste to create the WSGI application. For the Djangoist here, Paster acts like your manage.py.

Make the WSGI application itself, into app/__init__.py:

def application(environ, start_response): start_response("200 OK", [("Content-Type", "text/html")]) return ["<h1>Hello World!</h1>"]

And the factory (called make_app inside setup.py) is required as well in the same file.

def make_app(global_conf, **app_conf): return application

Now, you might be wondering how this make_app is called. Paste works with ini files that decribe your configuration, from the app your using to the database, the server, logs, and so on. It’s very handy to replicate the same kind of environment you find when working with Ruby on Rails by having different ini files for each.

So there is the app.ini:

[app:main]
use = egg:app [server:main]
use = egg:Spawning
host = 127.0.0.1
port = 8000
num_processes = 1
threadpool_workers = 1

The first section describes the application to use. It’s the egg that setuptools will create and install. That’s right, your application is exactily like any other python package. It means dependencies resolution, updates,… And the second part describe which server paster will have to use to run it. Spawning is a very efficient server that handles graceful code reloading. Pure happiness.

Before you can run it using :

$ paster serve app.ini

You’ll have to install it.

# python setup.py develop

develop means it symlinks the package to your directory and you won’t have to reinstall it later to take into account the changes made.

It should run just perfectly. Now let’s worry about deploying it somewhere else. Local web applications are nice but sharing them is cool too.

This is the fabfile.py, Fabric is more or less like Capistrano (Ruby):

from __future__ import with_statement
from fabric.api import env, run, put, local, cd env.hosts = ["localhost"]
env.path = "~/www/app" def build_egg(): local("python setup.py bdist_egg") def cleanup(): local("rm -rf build") local("rm -rf dist") def start(): with cd(env.path): run("PYTHONPATH=app.egg paster serve app.ini" "--daemon --pid-file=app.pid") def stop(): with cd(env.path): run("paster serve --stop-daemon " "--pid-file=app.pid") def deploy(): build_egg() put("app.ini", env.path) put("dist/*.egg", env.path+"/app.egg") cleanup()

A pythonic Makefile, more or less that has special power to deal with deployment. This how you can use it.

$ fab deploy
$ fab start

It created a .egg, uploaded it to the destination and started the Spawning server using Paster. It will run on the port 8080, to see it on the port 80 I’d use something like Nginx as a proxy. But it’s a different story (and very simple by the way).

After you made some changes simple run:

$ fab deploy

to see them live.

$ fab stop

Will stop the server.

How awesome is that?

There is a lot more that can be done regarding how you’re playing with the eggs. Using virtualenv to keep multiple, sane environments and maybe your own cheeseshop where all your eggs can live (see Ask’s Chishop)

I’m very fresh on that field but am very happy seeing that such good tools exist. Please share your experience, I’m looking forward knowing what kind of process is used in the real word out there to.

La force de PHP est et a été sa facilité de déploiement, on dépose un fichier et c’est parti mon kiki. Merci Apache + mod_php. Scénario pas toujours aussi simple dans les autres environnements d’applications web (si je mets de côté tout ce qui est CGI bien évidemment). Pour avoir bossé dans un environnement Ruby on Rails ces six derniers mois, un serveur fonctionnant sous Passenger est assez simple par rapport à ça. Recherchant toujours comment mettre ceci en place dans le monde Python, voici une approche assez minimaliste (certainement trop) pour déployer une application WSGI sous forme de paquet Python via Paster, Spawning et Fabric.
Ne voulant polluer cet espace-là, merci de regarder les exemples de code dans la zone anglophone. Ils sont également disponible sur GitHub.
Si Ruby a les gems, Python a les eggs (bien que certains Python soient ovovivipares) centralisés sur PyPI. Les avantages que je vois à créer un paquet pour son application est tout ce qui vient avec setuptools (et ses alternatives), c’est-à-dire : gestion des dépendances, exclusion des tests (et de leurs dépendances), versions, et certainement séparation en de multiple paquets.
Une fois le fichier setup.py créé, il va s’agir d’écrire un application web Python, ici WSGI mais il y a pas que ça et ça devrait couvrir 98% des besoins.
Ian Bicking a mis au point un système d’outils plus ou moins lié à WSGI nommé Paste qui permet de configurer et lancer une application web via des fichier de configuration INI (quand on est cool on fait du YAML parait-il). Paste requiert qu’on lui fournisse une méthode retournant une application WSGI, cette méthode dite fabrique, reçoit tous les éléments de configuration du fichier .ini. Chose très pratique afin d’avoir divers environnements tel que Ruby on Rails le pratique, comme : développement, test, production. Libre à chacun de faire comme il l’entend.
Le fichier .ini en question définit le paquet Python de nombre application et le serveur web à utiliser, ici Spawning qui a la force de se recharger automatiquement en cas de modification de fichiers détectée.
Travaillant avec un paquet, il est nécessaire de l’installer avant de pouvoir s’en servir. L’installation avec develop crée un lien symbolique où les modifications seront prises en compte sans devoir réinstaller.
Vous devriez pouvoir visualer ce hello world sur le port 8080 de votre machine.
Dernière étape, la plus intéressante peut-être, déployer votre application sur une machine distante, même si distante signifie localhost c’est pour l’exercice.
Si Ruby a Capistrano (et d’autres), Python lui a Fabric qui peut être vu comme un makefile pythonique avec des super pouvoirs lié à SSH.
Le fichier donné ici permet de créer le fichier .egg, de l’envoyer sur l’autre machine (votre serveur) via deploy, puis de le démarrer avec start. Tous les autres deploy’s ne demanderont pas de redémarrage puisque Spawning s’occupe de ça directement. Une fois que vous en avez terminé, un simple stop l’arrêtera. Je trouve judicieux de lancer les applications en tant que simple utilisateur sur un port comme 8080. Il est quand même de bon ton d’avoir un véritable serveur web tel que Apache, Lighty ou Nginx servant de proxy vers votre application et s’occupant de tous les fichiers statiques par la même.
In fine, la solution de l’egg exécuté tel quel est un peu brutale. Je vous invite à vous pencher vers virtualenv et Chishop. Et recherchant toujours une bonne manière de combiner tout ceci, vos solutions m’intéressent.
Bien du plaisir!

OneWeb demonstrates the power of XMPP inside the browser

Mickaël Rémond — Thu, 26 Nov 2009 06:00:29 GMT

We have just released an experimental extension for Firefox that adds XMPP interactions to the Mozilla browser.

OneWeb Firefox extension is a good exemple of Firefox hackability and shows how XMPP integration in the browser can bring value for real-time web interactions.

XMPP stands for eXtensible Messaging and Presence Protocol. The protocol is mostly known as an Instant Messaging protocol, but it has actually been designed as a generic messaging protocol that can do much more that chat. OneWeb Firefox extension demonstrates a small part of what you can do when you integrate XMPP by design into the browser behaviour.

Note that this is an early alpha version developed in a few days to demonstrate our purpose. There is still room for many improvements and contributions are of course welcome.

Description

OneWeb alpha version is able to do the following:

It gives an interface to interact remotely with your opened Firefox browser. You can interact with opened Firefox from another browser running OneWeb or from an XMPP instant messaging client (supporting adhoc commands). You can thus control your Firefox browser from your desktop or even from a mobile device.
It gives a way to share and broadcast your favorite pages with your contact on your XMPP account. Simply click "Share page" in contextual menu and a shared bookmark will be created, distributed to your contact and notified by their OneWeb plugin.
It can synchronize your bookmarks with your other Firefox browsers. This feature is experimental. Backup your bookmark before installing OneWeb on your Firefox.

Video

Download

The module can be downloaded from ProcessOne Labs.

Code source is available on ProcessOne Labs.

You need an XMPP account to test this software but you can get a development XMPP account for free on our XMPP Sandbox.

Update: We recommand you to use the XMPP Sandbox for ease of use. Your XMPP server needs supports for Pubsub and PEP which is not a common feature.

The Tutorials are available form the successful Property-based Testing Tutorial Workshop 2009

Sun, 22 Nov 2009 16:00:00 GMT

After the successful Property-based Testing Tutorial Workshop 2009 in Stockholm all the ProTest related tutorials - including Exago, Inviso/Onviso, McErlang, PULSE, QuickCheck and Wrangler - are now available online! You can find them on the Tutorials page.

Take ProTest Tools Survey and win Erlang Programming book!

Sun, 22 Nov 2009 16:00:00 GMT

It's been two years since ProTest - an EU funded research project on property based testing and test driven development - was established. We would like to sum it up and therefore we need YOUR feedback!

Have you heard about Exago, McErlang, Onviso, PULSE, QuickCheck or Wrangler? Are you using any of these tools?
By answering these and other questions, you will help influence the research and dissemination strategies for the next two years. Filling the survey in should not take longer than 15 minutes. Its results will be presented at Erlang conferences and workshops and made public on the ProTest website.

What's more, all participants are entered into a FREE PRIZE DRAW to win one each of three 'Erlang Programming' books by Francesco Cesarini and Simon Thompson. So please, by Monday 14th December take our survey!

It is available here in the traditional web-based form, you can also take it via IM - just add: survey@bot.surveys.erlang-consulting.com to your Jabber buddies and enter "start". If you have any queries, do not hesitate to contact Aniko on aniko@erlang-consulting.com.

We appreciate your time and willingness to help us!

Loving Clojure

Wed, 18 Nov 2009 18:02:15 GMT

I seem to be liking Clojure …

Let me backup a bit, in the last couple of weeks I have been debating between picking up Scala or Clojure (don’t get me wrong Ruby is still my favorite).

I always wanted to pick up a functional programming language so I dabbled a bit with Erlang and Haskell, liked Haskell a lot but without much practice it kind of died (sad times) and Scala seems too much like Java, yeah I know it seems to have a bigger crowd than Clojure and there are a lot of big names behind it.

Maybe that’s exactly why I choose Clojure (since its the underdog), or cause it is different enough from Java or simply cause it has a better syntax and seems more elegant (apparently Clojure has better integration with Java, don’t quote me on it), anyways I decided to learn Clojure.

Peepcode has a nice screen-cast to get you started off on Clojure. If you are on the Mac there is a nice bundle for TextMate and anywhere else Netbeans with the enclojure plugin seems to be the best.

On a side note it seems more and more that Netbeans has the latest and greatest plugins for everything, then comes IntelliJ and finally eclipse, what’s going on with eclipse ? has it reached its peak and now it will start dropping off ? but on the flip side there seems to be more and more apps built on top of the Eclipse RCP like Xmind, so is Eclipse no longer going to be the leader of the IDE and just become a platform for building RCPs. This of course depends on what Oracle is going to do with NetBeans, I really hope they give the same amount of love to NetBeans as Sun did.

Ok getting back to Clojure, don’t get your panties in a bunch when you see all those parenthesis, it is just the layout that is shocking, indent it well and it is no more than what you are used to.

Here’s an example
(defn fac
"Returns the factorial of n, which must be a positive integer."
[n]
(if (= n 1)
1
(* n (fac (- n 1)))
)
Is same as
(defn fac [n] (if (= n 1) 1 (* n (fac (- n 1)))))
But the first one is a lot more easier on the eyes (even brain?) than the second one. Most examples that you see look like the second one and it frightens people, don’t let that stop you take my word and go for it.

Clojure seems to be very easy to pick up, things seem very intuitive, like the other day I was wondering, how to return a default value from a map if the key is not found and there is was right there in the api.
(map key default-value)
So simple! I was easily able to extend the examples that came with the peepcode screencast. Anyways I have started on this path, let’s see where it goes.

Update 2009/12/03

- Looked at the Clojure source code, looks squeaky clean, I applied to become a member so that I can expand on the test coverage, hopefully they will accept me.

-It is (load-file “hello.clj”) and not load-file “hello.clj” , I keep forgetting that and after a few mins I realize it.

XMPP Sandbox: a development server for the XMPP community

Mickaël Rémond — Tue, 17 Nov 2009 04:00:10 GMT

ProcessOne now provides an online XMPP server dedicated to developers of XMPP solutions on XMPP Sandbox.

We realized that many of the developers building a solution start by creating an account on a public server, used for production. This is not a good practice, because:

During the learning process, developer can try connecting buggy clients. It is not very friendly to test buggy client on a real life, production server. I have seen very ugly traffic on production servers and this is something that should be avoided.
Production servers have limitations in term of resource usage. During development and experimentation, this is nice to be able to try innovative approach without hitting those limitation too soon.
Developers want to test the best and newest features of XMPP. Our XMPP Sandbox will feature the best and latest technologies.
We want to provide a showcase for some of our extra components (like our gateways for example). They are deployed on XMPP Sandbox and developers can directly assess themselves how good they are.

So, the XMPP Sandbox is now open as a beta service. Start playing with it, developers! Give us your feedback as many improvements are planned in the coming months!

For feedback and discussions, the XMPP Sandbox forum is open. You can also follow xmppsandbox on Twitter to share your feedback and feature request and get notified of changes.

For developers that can be in Paris on the 17th of december 2009, you can also join the "real life" developer sandbox during the SeaBeyond event.

Welcome in the sandbox and build amazing things!

Happy 7th birthday, ejabberd!

Mon, 16 Nov 2009 12:32:36 GMT

Yes, ejabberd is already 7 years old.

Let's celebrate with a timeline of ejabberd, Erlang/OTP, XMPP/Jabber protocol, and Tkabber:

If you find any mistake, please comment. I built the graph using EasyTimeLine.pl, if you want the datafile, please comment.

EUC 2009

Mon, 16 Nov 2009 03:31:51 GMT

The Erlang User Conference in Stockholm was a lot of fun! Thank you everybody at Erlang Training and Consulting for the excellent organisation.

My favourite talk of the day was Patrik Nyblom on the development of SMP support in the BEAM virtual machine. He was entertaining andalso inspiring: that is some really hot technology that our programs are sitting on. I'm reminded of Klacke's talk in London last year: Erlang programmers do have a more powerful tool than everybody else and now is the time to make the most of it.

Kostis Sagonas's presentation of the latest Dialyzer developments was great too. I'm one of those opinionated bastards who doesn't care much about standardized programming styles and this tends to put me at odds with people writing linting tools. This time I had no room to complain: the tool is entirely optional, the motivating examples of bugs it can find were very easy to relate to, and it's been developed and maintained as a production tool for many years now. Great marketing!

Some of the other talks really lacked motivating examples for me. I'm sure it's fun to write cloud-hosted databases and map-reduce frameworks, but what problem does it solve for me? The SQL people have long since fallen into the trap of "if all you have is a hammer, everything looks like a nail." NoSQL might be the same.

I dined a bit too well with friends on the nights leading up to the conference and so I missed the first talks about Nitrogen and advanced parse-transform hackery, which is a pity because I heard they were some of the best.

The whole week in Stockholm has been a really great time. I'm writing this on my short flight back to Switzerland at the moment and feeling very glad to live in the neighbourhood again. Now back to Erlang hacking..

Go borrows key concepts from Erlang

Sun, 15 Nov 2009 17:34:01 GMT

The Go language, getting a lot of attention because it was recently open sourced by Google, seems to be a sort of programmers’ Rorschach test in that everyone calls it a replacement for C++/Python/Erlang/Your Language Here… My sense is it wouldn’t be getting that much attention if it were released apart from Google. But thinking about Go for the past few days made me realize that the most important part about Go is actually its “Erlang-ness”. Everything else it provides is nice if you’re a C++ developer doing systems programming already, but not critical. But the goroutine/channel piece is the part that actually differentiates the language as something worth investigating that you can’t easily work around with the existing toolset.

Would it replace Erlang for many applications? Probably not, because though the coroutines will be powerful in certain systems, Go is not a platform like Erlang, with all the benefits of hot swappable code, supervisor processes,hibernating processes, etc… To a non-developer I would describe Go as containing some of the building blocks that make Erlang a great language and platform, but ultimately Go is targeting lower-level systems development. That type of coding wouldn’t be a good fit for Erlang anyway.

So where would they overlap? Probably most likely the two languages would be in applications that are not too OS-level but not too application-centric where OTP or hot-swapping code, multi-machine communication, etc would be requirements. The most obvious example would be web infrastructure. Would Go be a good fit for writing a web server vs Yaws or Mochiweb? Probably. Would I want to use Go to write my own cross-node communication that i get for free with Erlang? Probably not.

So I’m realizing that Go provides a service to the Erlang community in that it validates the fundamentals of the Erlang platform. Goroutines are equivalent to Erlang processes:

Why goroutines instead of threads?

Goroutines are part of making concurrency easy to use. The idea, which has been around for a while, is to multiplex independently executing functions—coroutines, really—onto a set of threads. When a coroutine blocks, such as by calling a blocking system call, the run-time automatically moves other coroutines on the same operating system thread to a different, runnable thread so they won’t be blocked. The programmer sees none of this, which is the point. The result, which we call goroutines, can be very cheap: unless they spend a lot of time in long-running system calls, they cost little more than the memory for the stack.

And Channels to Erlang messages: ( see slide 28 from this deck)… very cool stuff and further evidence of the slow but inexorable march toward mainstream multi-core programming.

Comparing Erlang, Go, Java, and C

Sun, 15 Nov 2009 16:41:15 GMT

Tim over at timyang.net has an interesting ‘hello world’ web server test between Erlang, Go, Java, and C. The C code is an nginx plugin, Java uses the MINA framework; Erlang and Go are small standalone apps. Java ‘won’, with Erlang in second place. Interesting article and the first I’ve seen comparing Go and Erlang performance.

ejabberd 2.1.0 finally released

Jérôme Sautret — Fri, 13 Nov 2009 06:36:22 GMT

ejabberd 2.1.0 is finally released, and it comes with an enormous list of 314 new features, improvements and bugfixes. It has been 21 months since the last major ejabberd release 2.0.0, and 8 months since 2.0.5.

Very brief list of additions:

Erlang/OTP R13 support
HTTP-Bind (BOSH) optimization and clean-up
LDAPS support
MUC rooms can require a CAPTCHA to join the room
PubSub: major improvements. Update to XEP version 1.12
PEP and Caps: many improvements
Run commands with ejabberdctl or other frontends (XML-RPC, HTTP)
STUN server
XEPs like: XMPP Ping, Roster Versioning, Import/Export Format

Check the Release Notes for a more complete list of changes:
http://www.process-one.net/en/ejabberd/release_notes/release_note_ejabberd_2.1.0

If you upgrade from a previous ejabberd version, read carefully the release notes, because there were several changes in the installation path and the configuration options.

The list of solved tickets since 2.0.0 is available on ProcessOne bug tracker:
http://redir.process-one.net/ejabberd-2.1.0

ejabberd 2.1.0 is available as source code package and binary installers for Linux 32 bits, 64 bits, Mac OS X Intel, and Windows:
http://www.process-one.net/en/ejabberd/downloads

Acknowledgments:

A big thank you to everyone who helped in the ejabberd project during the last months. This list is extracted from ejabberd's commit log between version 2.0.0 and 2.1.0:

Alexander Tsvyashchenko, Alexey Shchepin, Anastasia Gornostaeva, Andreas Ntaflos, Andreas van Cranenburgh, Andrzej Smyk, Andy Harb, Andy Skelton, Anton Podavalov, Apag0r, Attila Vangel, Badlop, Brian Cully, Carlos E. Lopez, Chris Newcombe, Christoph Anton Mitterer, Christophe Romain, Christopher Dupont, Clochix, Dariusz Markowicz, Dominges, Doruk Fisek, Eric Cestari, Etan Reisner, Evgeniy Khramtsov, Fabrice Colliot, Felix Geyer, Gabriele Stilli, Geoff Cant, George Hazan, Glenn Sieb, Graham Whitted, Gustaf Alströmer, Igor Goryachev, Jack Moffitt, Jacob Vorreuter, James Iakovos Mandelis, Jan Kusanagi, Janusz Dziemidowicz, Jeffrey Rogiers, Jon Bendtsen, Jonathan Auer, Jonathan Schleifer, Juan Pablo Carlino, Justin Boffemmyer, Justin Kirby, Jérôme Sautret, Kevin Crosbie, Konstantin Khomoutov, Luca Brivio, Lukáš Polívka, Magnus Henoch, Marcin Owsiany, Marek Bečka, Martin Langhoff, Massimiliano Mirra, Mats Cronqvist, Matthew Reilly, Maxim Ryazanov, Michal Schmidt, Mickaël Rémond, Myers Carpenter, Neustradamus, Nicolas Vérité, Nikolaus Polak, Oleg Palij, Otávio Fernandes, Pablo Polvorin, Pablo Saratxaga, Paul Guyot, Pedro Melo, Philipp Hancke, Ruslan Rakhmanin, Sergei Golovan, Shelley Shyan, Smart2128, Spike, Stefan Strigler, Stephan Maka, Stian B. Barmen, Thomas, Thomas Baden, Thore Alstromer, Tsukasa Hamano, Vincent Barat, Viq, Zbyszek Żółkiewski, and Zhan Caibao.

ejabberd 2.1.0 - HTTP-Bind, LDAPS, PubSub 1.12, STUN, Ping, Roster Versioning

Fri, 13 Nov 2009 04:02:40 GMT

ejabberd 2.1.0 is finally released! And it comes with an enormous list of 314 new features, improvements and bugfixes. It has been 21 months since the last major ejabberd release 2.0.0, and 8 months since 2.0.5.

Very brief list of additions:

Erlang/OTP R13 support
HTTP-Bind (BOSH) optimization and clean-up
LDAPS support
MUC rooms can require a CAPTCHA to join the room
PubSub: major improvements. Update to XEP version 1.12
PEP and Caps: many improvements
Run commands with ejabberdctl or other frontends (XML-RPC, HTTP)
STUN server
XEPs like: XMPP Ping, Roster Versioning, Import/Export Format

Facebook chat team gets Erlang User of the Year award

Mickaël Rémond — Thu, 12 Nov 2009 09:06:37 GMT

Chris Piro and Eugene Letuchy get Erlang User of the Year 2009 award at Erlang User Conference in Stockholm at a testimonial to the value of their achievement for the Erlang community.

We have mentioned the Facebook chat system by revealing their use of ejabberd as an XMPP interface.

Alexey Shchepin and me from ProcessOne had already been elected "erlang user of the year", respectively in 2006 and 2004.

Congratulations to Chris Piro and Eugene Letuchy!

Go or Unladen Swallow?

Tue, 10 Nov 2009 15:55:37 GMT

Go is a new programming language to come out of google and this thread on Google discouraging python internally for new projects seems more than just coincidence.

Go is an attempt to combine the ease of programming of an interpreted, dynamically typed language with the efficiency and safety of a statically typed, compiled language.

By combining dynamic features, safety, garbage collection and efficiency in a single language and environment, Go claims to remove the reasons why programmers end up building systems using multiple languages. A brief look at Go shows strong C origins with nice support for "goroutines" - essential sequential processes communicating using channels. I don't quite get the "safety" claim of the language since you can take the address of an uninitialized variable in Go. It could qualify as a "C with concurrency" language I think.

Go already has a great set of packages that should make it immediately usable as a pragmatic language. (The terse package names are very reminiscent of Erlang's package structure.) It even has a package for interfacing with Google Native Client (NaCl) for audio/video access.

(minor edits)

Øredev 2009

Sat, 07 Nov 2009 06:43:11 GMT

I made a quick stop at Øredev in Malmö on Friday Nov 6.
It seemed like it would have been a fun place to spend the week, but alas I was too busy to do more than just come in, give my talk, and go home again (getting up 4am London time to make it in time…) I did manage to catch Stuart Halloway’s talk on Clojure and had some good discussions.

Here is a copy of my slides

John Hughes on Erlang and Haskell

Fri, 06 Nov 2009 08:29:42 GMT

John Hughes talks about his experience with Erlang vs. Haskell in an InfoQ Interview. While the discussions about strict vs lazy, pure vs side effecting, and dynamic vs static typing are interesting he raises a good question for the LtU crowd at the end:

I think functional programming is a very interesting concept for the future and for the present indeed. One of the things I do wonder about though, is when I got interested in the field, the mainstream was probably Fortran and COBOL and even C was fairly new at that time. The functional programming pioneers spoke of an order of magnitude improvement in productivity and I think functional programming has delivered that.

If you compare Haskell programs to C code or even C++ often, they are about an order of magnitude smaller and simpler. The same is for Erlang, those results are being validated in the industry. Where is the next order of magnitude coming from? I wish I had an answer to that question because it's hard to see almost. When you look at a beautiful Haskell program, how could this be 10 times shorter? But I think we need to be asking ourselves that kind of question. If I had a good idea there, I would spend the rest of my career working on it.

So, LtU, where is the next order of magnitude coming from?

Strategic Guide: Instant Messaging and Security

Mickaël Rémond — Fri, 06 Nov 2009 02:46:44 GMT

ProcessOne releases its Strategic Guide on Instant Messaging Security. It focuses on the impact of Instant Messaging on businesses, explore possible security risks of Instant Messaging usage and give advices on how to mitigate them.

Businesses recognise that instant messaging can help to improve employee productivity, but are often reluctant to sanction its use due to concerns about security. This Strategic Guide examines the real risks associated with instant messaging in corporate environments and explains how to mitigate them.

Download the document:

English version: Strategic Guide: Instant Messaging and Security (PDF).
French version: Guide Stratégique: Messagerie instantanée & Sécurité (PDF).

Facebook chat supports XMPP, with ejabberd

Mickaël Rémond — Thu, 05 Nov 2009 03:06:18 GMT

Facebook is preparing the launch of their XMPP connection interface. It means that users will be able to use Facebook with any type of XMPP clients, ranging from desktop to mobile clients.

This is a huge news for XMPP because it consolidates the protocol as the de facto open standard for Instant Messaging and Presence. Facebook adds about 300 million potential users that can now use XMPP for chatting. This adds to large Google Talk figures and the many other large deployments around the world, like Yandex and Live Journal. XMPP could become the most largely used instant messaging protocol in the coming months!

Facebook announced on their developer blog they had the intention to support the XMPP protocol in May 2008: Using Facebook Chat via Jabber.

It now seems the launch is close as the XMPP software stack has been deployed on chat.facebook.com, as our bot at IMtrends have found out: chat.facebook.com on IMtrends.

We are proud that this XMPP support is built on a customized ejabberd XMPP server as announced several times by Facebook development team, including one of their latest conferences in Edinburgh in September 2009: Functional Programming at Facebook by Chris Piro and Eugene Letuchy.

The missing piece is currently what login and password to use to connect, but I am sure it will be announced by Facebook in due time.

Good job Facebook team!

Tsung - Load Testing Tool in Erlang

Raymond Tay — Sun, 01 Nov 2009 16:05:00 GMT

You've must have heard of Tsung - a load testing tool. Well i've got the opportunity to learn and use it in my current employment and its really versatile in conducting load tests for web-based applications. It has many features that i've come to appreciate after spending a couple of years with Mercury Interactive (its defunct now after being bought over by HP in 2006); admittedly Mercury's solutions were more versatile than what Tsung can offer but considering that web is the common platform where many applications are being hosted on; i think its a safe bet :)

So, IMO i think

Tsung is good for conducting load testing scenarios and executing them in a local / distributed manner
Load Testing can be relatively light weight (Erlang processes are hitting the target app) and hence the cost of using relatively heavy weight machines is likely to reduce since there is lesser need to use those machines since more concurrent users can be simulated on 1 machine in Tsung. (I'll see whether this assumption is correct)

Good starting points (URLs of interest):

A load testing tool would be useless if it didn't know how to capture server response data (e.g. checking whether an expected string is returned) and reuse it (e.g. session ids returned from servers which you can use subsequently in a HTTP POST/GET in an URL-rewrite type of string) subsequently, generate dynamic data, read data from an external file (commonly used in storing <username, password> pairs)

So my example would illustrate the logging in to a website (e.g. http://projecteuler.net) and logging out from it - simple enough to illustrate my point.
Next what i did was to record the series of events that mimick my user logging and logging out of the website and this is captured in the tsung_recorder_timestamp.xml
and i used that XML file and included some other stuff so that it looks like what i have for you below (this is a basic load test scenario)

<?xml version="1.0"?>
<!DOCTYPE tsung SYSTEM "/usr/local/share/tsung/tsung-1.0.dtd">

<tsung loglevel="info" dumptraffic="false" version="1.0">

<clients>
 <client host="localhost" use_controller_vm="true"/>
</clients>
<servers>
 <server host="78.110.165.8" port="80" type="tcp"></server>
</servers>

<load>
 <arrivalphase phase="1" duration="2" unit="minute">
 <users interarrival="1" unit="minute"></users>
 </arrivalphase>
 <user session="rec20091102-01:30" start_time="0" unit="second"></user>
</load>

<options>
 <option name="file_server" value="/tmp/userlist.csv"></option>
</options>

<sessions>
<session name='rec20091102-01:30' probability='100' type='ts_http'>
<request><http url='http://projecteuler.net/' version='1.1' method='GET'></http></request>
<request><http url='/style_main.css' version='1.1' if_modified_since='Sat, 29 Nov 2008 20:04:00 GMT' method='GET'></http></request>
<request><http url='/images/logo.jpg' version='1.1' if_modified_since='Thu, 28 Dec 2006 14:12:43 GMT' method='GET'></http></request>
<request><http url='/images/icon_register.png' version='1.1' if_modified_since='Fri, 31 Dec 2004 12:48:16 GMT' method='GET'></http></request>
<request><http url='/images/icon_about.png' version='1.1' if_modified_since='Fri, 31 Dec 2004 12:48:28 GMT' method='GET'></http></request>
<request><http url='/images/icon_problems.png' version='1.1' if_modified_since='Fri, 31 Dec 2004 12:48:26 GMT' method='GET'></http></request>
<request><http url='/images/icon_login.png' version='1.1' if_modified_since='Fri, 31 Dec 2004 12:48:32 GMT' method='GET'></http></request>
<request><http url='http://projecteuler.net/images/corner_tr.gif' version='1.1' if_modified_since='Thu, 10 Apr 2008 19:35:02 GMT' method='GET'></http></request>
<request><http url='/images/corner_tl.gif' version='1.1' if_modified_since='Thu, 10 Apr 2008 19:34:41 GMT' method='GET'></http></request>
<request><http url='/images/corner_br.gif' version='1.1' if_modified_since='Thu, 10 Apr 2008 19:35:10 GMT' method='GET'></http></request>
<request><http url='/images/corner_bl.gif' version='1.1' if_modified_since='Thu, 10 Apr 2008 19:34:55 GMT' method='GET'></http></request>
<request><http url='/images/euler_main.jpg' version='1.1' if_modified_since='Mon, 21 Jan 2002 19:18:20 GMT' method='GET'></http></request>

<thinktime random='true' value='2'/>

<request><http url='http://projecteuler.net/index.php?section=login' version='1.1' method='GET'></http></request>

<thinktime random='true' value='6'/>

<request subst="true">
<match do="continue" when="match">Logged in as %%readcsv:getUsername%%</match>
<http url='/index.php' version='1.1' contents='%%readcsv:getUserString%%' content_type='application/x-www-form-urlencoded' method='POST'></http>
</request>

<thinktime random='true' value='4'/>

<request><http url='/images/icon_tick.png' version='1.1' method='GET'></http></request>

<thinktime random='true' value='4'/>

<thinktime random='true' value='3'/>

<request><http url='http://projecteuler.net/index.php?section=logout' version='1.1' method='GET'></http></request>
</session>
</sessions>

</tsung>

Hence, the main thing you should note is the use of dynamic substitution (e.g. %%readcsv:getUsername%%) where i wrote a simple erlang program to read my username and password from a file (see the XML tag option above) and replacing each simulated user with a valid user id and password.

Next, i checked that the server response contains a string Logged in as XXX where XXX would be dynamically generated by the function (Check out the erlang code for the function, simple stuff).

The erlang program is shown below.

 1 -module(readcsv).
 2 -export([getUserString/1, getUsername/1]).
 3
 4 getUserString({Pid, DynVar}) ->
 5 {ok, Line} = ts_file_server:get_next_line(),
 6 [Uid,Pwd] = string:tokens(Line, ","),
 7 "username=" ++ Uid ++ "&password=" ++ Pwd ++ "&login=Login".
 8
 9 getUsername({Pid, DynVar}) ->
10 {ok, Line} = ts_file_server:get_next_line(),
11 [Uid,_] = string:tokens(Line, ","),
12 Uid.

The above erlang code must be compiled via erlc and you place the .beam file into the directory via a command like this

sudo mv readcsv.beam /usr/local/lib/erlang/lib/tsung-1.3.1/ebin/

Now, running the load test should be alright.

Note: In this load test, i defined a duration of 2 minutes with 2 users since load testing using 800 gazillion users is considered a chargeable offense so DON'T DO IT.

Have fun!

Adaptive layout for the mobile web

Sat, 31 Oct 2009 04:37:00 GMT

One web, is still in the air and we, as web developers, are still hoping that it will be the case. Nowadays, phones are getting better and better and the need of doing a specific version of any website if, as I see it, fading away. When someone tells you: “Hey, I need an iPhone/Android/Pre/Maemo app (or maybe an Opera/Vodafone widget) for my website!” I would try to show her/him that, at a very small cost, a well done website can be adapted to those devices.

If the iPhone marketshare is quite big, other platforms are emerging. The cool side is that they are built on Webkit as well, like: Android or Palm Pre. Less powerful phones might run Opera mini which has also a very good support of web standards. I’ll try to show simple things you can do to give your website a better experience everywhere without building multiple versions of it.

The biggest problem, the width. On the desktop side, it’s commonly assumed that 1024x768 is the standard. This is why the ~960px width layout is so common (take Yahoo!, Facebook, LinkedIn, …). My opinion is that netbooks will gain some marketshare too and it also weight the fact that one size fits all will be outdated in the next years.

Devices might use HVGA 480x320 (iPhone, Pre, HTC Dream) or QVGA 320x240 or maybe bigger or smaller. The iPhone comes with a feature to control the viewport, which might be supported by the others (like Opera) or not.

<meta name=viewport content="width=320; user-scalable=1;">

Like Daniel Glazman said during Paris Web 2009, please don’t prevent the user to scale in/out. This is totally non-standard and there is a standard way of doing that. It’s called media-queries.

<link href="small.css" media="handheld, only screen and (max-device-width: 480px)" rel="stylesheet" type="text/css">

This stylesheet gonna be applied on handheld devices and others with a very narrow screen (smaller than 480px in this case) and it enables to do cool things like :

going with a liquid layout instead of a fixed or elastic one;
linearizing multiple-columns layout (float:none);
hiding unnecessary stuffs (like you already do in your print stylesheet of course);
resizing big picture (max-width: 100%);
making small things bigger, so you can click them more easily (like tiny icons);
taking into account that there is no :hover state on a touch screen;
and many more…

Such small screen cannot take advantages of the two dimensions, like a usual monitor does, so a linear (in the Y-axis of course) layout is preferred.

They are of course many, more issues that can be addressed like the iPhone file-size cache limitation, bandwidth reduction, HTTP calls,… I wouldn’t focus on those until you get an audience worth doing so. If it’s not your target of course.

I won’t throw the baby with the bathwater and native applications are good if you need to do specific things with the device itself or require specific performances. Phones offer, or will offer, access to the address book, the camera, the geo-localization,… Most of those require specific actions which aren’t completely specified/implemented yet, like OMTP Bondi or W3C itself.

The best platform to test that is OSX, simply because the iPhone SDK won’t work elsewhere. Testing with the Android emulator or Opera Mini can be done on any platform. Mozilla promised to release soon a version of Fennec targeting the Maemo platform which is already using Gecko. By the way, the N900 looks awesome! To develop it, simply activate that stylesheet for everyone, so no media-queries.

It very easy to start adapting a website to smaller devices and may even force you to have a better grid structure. Maybe not yet a business advantage, but sooner or later it will.

Un seul web (“One Web”) a été usé et re-usé lors du dernier Paris Web. C’est une idée ou un espoir qui plane depuis toujours il me semble. Avec la démocratisation des appareils nomades permettant de consulter le véritable web (ni WAP, ni i-mode). Le réflexe actuel me semble être : « il faut que je fasse réaliser une application iPhone/Android/Pre (ou un widget Opera/Vodafone) pour mon site ». Dans ce cas, je présenterais ce qu’il est possible de faire avec l’existant, et ce qui nécessiterait une application native.
Si le monde du mobile est une jungle encore plus dense que ce qu’on expérimente avec les navigateurs usuels. Les acteurs principaux se divisent entre Webkit (iPhone, Android, Palm Pre, …) et Opera (avec Opera mini). Des moteurs de rendu connus (entre autres) pour leur support de qualité des standards. Des outils existent pour éviter de produire plusieurs versions d’un même site.
Le pas premier à franchir est qu’il est assumé aujourd’hui que 1024x768 est le minimum syndical. Pour preuve le nombre de sites reposant sur cette largeur là, de manière fixée. L’arrivée des netbooks va, j’espère tendre vers un parc informatique encore plus hétérogène et une fin progression de la taille unique.
Pour revenir à nos moutons, nombre d’appareils ont un écran dit HVGA (demi-VGA, 320x480) ou QVGA (quart-VGA, 320x240). C’est pourquoi vous verrez souvent la ligne suivante :
<meta name=viewport content="width=320; user-scalable=1;">
Un élément propriétaire à l’iPhone, qui force la largeur à 320px et dans ce cas autorise le zoom utilisateur. Comme l’a souligné Daniel Glazman lors de sa présentation (ou devrais-je dire show) en novembre dernier, désactiver cette fonctionnalité est un non-sens. D’autres navigateurs peuvent supporter cet attribut là, je pense notamment à Opera.
Mais, la boîte-à-outils du W3C n’est pas en reste, avec les media-queries qui permettent de cibler un navigateur selon des spécification techniques :
<link href="small.css" media="handheld, only screen and (max-device-width: 480px)" rel="stylesheet" type="text/css">
Comme dans ce cas, la largeur maximale en pixels de l’appareil. Donc si l’appareil est plus petit que 480px de large, la feuille de style est appliquée. Feuille qui permet de faire tout un tas de choses intéressantes :

passer à une mise en forme fluide, et non plus fixée ou élastique ;

linéariser des colonnes ;

masquer ce qui sert de décoration

limiter la taille maximale des images, par exemple ;

agrandir certains éléments pour pouvoir les sélectionner avec de gros doigts (sur un petit écran) ;

prendre en compte qu’il n’y a pas d’effet de survol sur un écran tactile ;

et tout un tas d’autres…

Il y a plusieurs autres points à prendre en considération si l’audience se servant d’appareil nomade est assez importante. Une version adaptée, ne saura certainement pas contenter tous les usagers. C’est à mes yeux un investissement faible et qui amène forcément un plus qualitatif, passer de deux dimensions à une seule implique que la logique de base soit bonne.
Pour ne pas jeter le bébé avec l’eau du bain, il y a un intérêt à l’option application native, pour ne serait-ce qu’au niveau des performances. Plus spécialement dès qu’il s’agit d’intéragir avec l’appareil lui-même, comme consulter le carnet d’adresse, l’appareil photo ou le GPS. Des solutions au sein du navigateur arrivent tant via le W3C qu’OMTP Bondi pour citer ceux que je connaisse.
En matière de test, tout est testable depuis partout, sauf pour l’iPhone où le SDK nécessite le système d’exploitation OS X. L’émulateur Android offre différentes géométries d’écran, ce qui est intéressant. Opera mini est disponible en ligne. Pour parler un peu de Mozilla, Fennec devrait arriver pour le N900 (Maemo utilisant déjà Gecko) d’ici peu. Sinon, en activant la feuille de style comme une autre permet de faire un premier test également. Il y a de quoi s’amuser à améliorer l’expérience utilisateur de nos sites sur ces appareils là. C’est vraiment ludique à faire, même en tant que non-possesseur de ce type d’appareils là.

Learn You Some Recursion

Fri, 30 Oct 2009 19:30:00 GMT

I've added a new chapter to Learn You Some Erlang. This one's about recursion and tail recursion and explains how to work in a language without looping constructs of any kind. We visit common operations such as calculating factorials (yeah, every functional programming tutorials does that), finding the length of a list, reversing, slicing and zipping lists. I also added an example in, which is about building quicksort in 2-3 different manners and another one about recursively reading and building binary trees in order to construct a small address book. As for additional changes, I've completely rewritten my Erlang plugin for SyntaxHighlighter making the code much easier to read (hopefully). I should also add that I feel a bit sorry for not updating the site faster this time, providing a single chapter when I usually get 3 out in the same time period. I've been busy with work projects and did not have enough energy to do as much stuff. I also feel recursion is a touchy subject to teach; it needs to be done right, be very simple without being too patronizing or plainly boring, etc. So I've taken more time to make it as good as possible.

Web site downtime since Friday 30 October 6.00 UTC

Thu, 29 Oct 2009 08:42:08 GMT

This web site will be unavailable during the morning of Friday 30 October, since 6.00 UTC (9.00 Moscow Time). It is expected that the migration will take at least 6 hours, so be patient ;)

Other services affected will be the mailing list, the chatroom and Bugzilla.

The reason is that the hosting of this website and many other ones, Jabber.Ru, will migrate to a new machine.

See you at the come back!

Python quirks

Thu, 29 Oct 2009 07:53:00 GMT

I’ve been using Python for a while. Recently I have noted some nuances, wonders and counter-intuitive things I ran into. The list grew surprisingly fast. Disclaimer: Most of the problems that I list here can be understood and explained. It’s just my opinion that something is odd, so forgive me if I raise something that, in your opinion, [...]