Que 2009 vous soit profitable avec du bonheur, des enfants et GTA IV à 60 FPS. Et que vos projets soient couronnés de succès.

Vue partielle de 2008 :

XMPP

Un de mes objectifs à long terme était de m’impliquer dans un projet Open Source. Les quelques patches que j’ai envoyés aux developpeurs d’ejabberd semblent rentrer dans cette catégorie.

XMPP est vraiment passionnant à travailler en ce moment. Il y a un livre chez O’Reilly en préparation, fini de lire les XEP et leur (nécessaire) sécheresse.

HTTP

Les services REST, atompub, l’importance des headers de caching, Amazon S3 (en vrac … rien de spécifique à 2008, sinon mon intérêt)

All things Apple

Bien qu’il soit en réparation parce qu’un ventilateur vibrait de manière insupportable, mon nouveau MacBook Pro a instantanément rendu le design du précédent obsolète.

En 2008 aussi j’ai enfin un accès permanent, systématique et abordable à internet, via mon iPhone et mais aussi sur mon portable grâce à feu NetShare.

Ohm Force

2008 a été l’année de l’embauche : 2 nouvelles têtes, Cid à la communication et David sur le développement web, plus une troisième qui arrive bientôt.

2008 a aussi été l’année de l’explosion. Les membres d’Ohm Force sont maintenant tout autour de la France : Marseille, Chartres, Carhaix, et le reste en région parisienne. On avait aussi Vincent à Nice, mais il a réajusté sa vie professionnelle en 2008.

Martin

Certes, il date de 2007, mais les mises à jours sont constantes, et il commence à parler (plus de deux mots à la suite).

Passions :

• les camions de pompier
• la combo lave-linge/sèche-linge (un tas de boutons à appuyer)
• le lave-vaisselle, le vider, (avec l’aide de son papa et/ou de sa maman)

Il a trouvé ces passions-là tout seul, et avec une complémentarité sur les passions de son père (qui sont : ne pas vider le lave-vaisselle et ne pas faire la lessive)

Note pour plus tard : prendre une machine à chargement frontal, et apprendre à Martin à trier les couleurs et le blanc.

Les autres jeux sont toujours basé sur les règles du CalvinBall, mais uniquement dans sa variation 1 joueur.

Misc

Je suis membre de l’APRIL depuis cette fin d’année.

Quoi de neuf en 2009 ?

Des tas de supers choses vachement bien. (Certains à Ohm Force sont beaucoup plus pessimistes, je refais un stock de boite de conserves des fois qu’ils aient raison).

Mes objectifs en vrac :

• apprendre un nouveau langage (ou un vieux, je me remettrai bien à Python)
• faire des mises à jour sur MangerVite (je me demande si j’ai pas écris ça l’année dernière à la même période …)
• maîtriser mon Picooz (et éviter les cheveux d’Hélène et les poils de chat dans le rotor de queue)
• améliorer la qualité de mon code
• Getting Things Done !
• me faire battre par Martin à Super Smash Bros Brawl
• finir les campagnes de Left 4 Dead en expert
• transformer l’intranet d’Ohm Force en extranet
• Utiliser Git.
• Donner des cours, mais je sens déjà que ca va être dur.
• ???? ??? ? ???? ?? ????
• ??? ?? ????? ????? ??? ????

(oui y en a deux autres, mais ce sont des surprises, j’ai pas envie que Google vende la mèche à ceux que ça concerne)

GL HF guys !

(“good luck and have fun” dans la terminologie des jeux vidéos, et c’est aussi adapté en début d’année)

But first of all, why would you ever want to write your own mod_roster for ejabberd? Here is why:
We have a massive database of users, user information and relationship status already, we store this in postgresql and are quite happy about that state. When we started to build ESL Wire around an XMPP-Server (first OpenFire, now ejabberd) we were quickly facing the problem of having two databases that need to be kept in sync, but basically hold the same data. Since syncronization of _the same data_ is generally a bad idea and most of the time leads to inconsistencies we had to think up something different. Since we already planned of “opening” our infrastructure a bit, to make it easier to scale to different countries, users and customers, we decided to have a field-test with the jabber-server. By now we are talking to the ESL database using a webservice and parsing it’s JSON responses. All data is being kept in one place and we no longer have any inconsitencies. So basically what we have now is a mod_roster_json…of course this brings other issues to the table, but hey, let’s take it step by step!

So, what is important information?

Read the Jabber RFC and escpecially focus on all it’s “exceptions from the rule”, read up on gateway-interaction and be sure you know how the subscription states in jabber work.

* RFC3921

Then, look into the hooks ejabberd provides and what the functions that handle the hook need to return, this caused me a lot of headache, since I found this quite late…after a lot of reverse engineering other “mod_rosters”.

* Events and Hooks

Relevant hooks for mod_roster are:

remove_user(User, Server) -> ok
resend_subscription_requests_hook(Acc, User, Server) -> [Packet]
roster_get(Acc, {User, Server}) -> [RosterItem]
roster_get_jid_info(Acc, User, Server, JID) -> {Subscription, Groups}
roster_get_subscription_lists(Acc, User, Server) -> {[FromSubscription], [ToSubscription]}
roster_in_subscription(Acc, User, Server, JID, SubscriptionType, Reason) -> bool()
roster_out_subscription(Acc, User, Server, JID, SubscriptionType, Reason) -> bool()
roster_process_item(RosterItem, Server) -> RosterItem

If you want to implement Nested Roster Groups, you will need this as well:

privacy_iq_get(Acc, From, To, IQ) -> {result, Packet} | {error, Error}


In this context the return values mean this (in examples):

ok = ok
Error = ?STANZA_ERROR/3
[Packet] = {xmlelement, …}
[RosterItem] = #roster
Subscription = none | from | to | both | remove
Groups = [string()]
bool() = true | false


After this, implement the functions as wanted above, set the debug level to 5 in ejabberd.cfg
and put this everywhere you may need to see the current state of data:

?DEBUG(“MY_MOD_ROSTER: DATA AT THIS POINT IS: ~p~n”, [Data])


Now walk through your code step-by-step and have a look at the original mod_roster and/or
mod_roster_odbc to see what the hooks are supposed to do (will describe this here later).

* mod_roster.erl
* mod_roster_odbc.erl

Comparing these two should give you a good idea of what the functions are supposed to do and how you should handle the incoming data to get to what you need to return to satisfy the hook. Once I have a bit more time, I will describe in depth what the hooks are supposed to do.

Oh, and one more thing:

If you have “slow” transactions on where you store your data (webservice, for example) be sure to play around with the queing setting of your module, since this can lead to some strange results when you just changed a rosteritem but another thread was too fast and fetched the old one again. Do this by playing around whith this line:

IQDisc = gen_mod:get_opt(iqdisc, Opts, one_queue),


See possible values here:

* no_queue: no thread is created to run the handler
* one_queue: one thread is dedicated to run the handler
* {queues, N}: N threads are created to run the handler
* parallel: one thread is created for each IQ received

Since its relaunch, Planet Erlang is now indexing content from tens of Erlang related blogs. Thank to its search engine, you can now find many blog posts and articles on lots of different Erlang topic. ejabberd is one of the most covered topic there.

You should have a look and try searching for ejabberd in the search engine (search field on the right).

The list of resources is growing every day as we are adding even more older resources.

Your comments and feature requests are welcome !

The biggest feature I’ve added to date, though, is a new linked-in driver that allows Yaws to use the sendfile system call on Linux, OS X, and FreeBSD. I never wrote a linked-in driver before, so I was happy and fortunate to have an Erlang expert like Klacke providing hints and reviewing my code.

I did some preliminary testing that showed that sendfile definitely improves CPU usage across the board but depending on file size, sometimes does so at the cost of increasing request times. I used my otherwise idle 2-core 2.4GHz Ubuntu 8.04.1 Dell box with 2 GB of RAM, and ran Apache Bench (ab) from another Linux host to simulate 50 concurrent clients downloading a 64k data file a total of 100000 times. I saw that user/system CPU on the web host tended to run around 33%/28% without sendfile, while with sendfile it dropped to 22%/17%. The trade-off was request time, though, where each request for the 64k file averaged 0.928ms with sendfile but 0.567ms without. With larger files, however, sendfile is slightly faster and still has better CPU usage. For example, with a 256k file, sendfile averaged 2.251ms per request with user/system CPU at 8%/16% whereas it was 2.255ms and 16%/27% CPU without sendfile, which makes me wonder if the figures for the 64k file are outliers for some reason. I performed these measurements fairly quickly, so while I believe they’re reasonably accurate, don’t take them as formal results.

On my MacBook Pro laptop running OS X 10.5.6, CPU usage didn’t seem to differ much whether I used sendfile or not, but requests across the board tended to be slightly faster with sendfile.

I ran FreeBSD 7.0.1 in a Parallels VM on my laptop, and there I saw significantly better system CPU usage with sendfile than without, sometimes as much as a 30% improvement. Requests were also noticeably faster with sendfile than without, sometimes by as much as 17%, and again depending on file size, with higher improvements for larger files. User CPU was not a factor. All in all, though, I don’t know how much the fact that I ran all this within a VM affected these numbers.

Given that Yaws is often used for delivering mainly dynamic content, sendfile won’t affect those cases. Still, I think it’s nice to have it available for the times when you do have to deliver file-based content, especially if the files are of the larger variety. Anyway, I committed this support to the Yaws svn repository back around December 21 or so. If you’d like to do your own testing, please feel free — I’d be interested in learning your results. Also, if you have ideas for further tests I might try, please leave a comment to let me know.

It works very simply. The hooks are written as methods of a regular python class with the “remote_” prefix:

class UserMonitor(object):
    
    def remote_receive_packet(self, jid, frm, to, packet):
        print “>>“,  to_domish(packet).toXml()
    
    def remote_send_packet(self, frm, to, packet):
        print “<<“,  to_domish(packet).toXml()

which is published by using a PersistentPortMapper:

nodeName = buildNodeName(“uccaro@olindo.bluendo.priv”)
epmd = PersistentPortMapperFactory(nodeName, cookie, “olindo.bluendo.priv”)
epmd.publish(proxy = UserMonitor()) 

After this it’s possible to call the methods proxy:receive_packtes and proxy:send_packet from any erlang node.

Then we register with ejabberd using a second node which calls the register methods, using the ejabberd api:

And bingo, after this ejabberd happily starts calling our hooks!

As bonus in the code you find also a function which translates from the ejabberd xml representation to twisted domish nodes, which is far more usable.

Almost a year ago I did some Apache and Nginx performance testing. Apparently I have the bug again and have done some performance testing on Nginx, Yaws and MochiWeb. The latter two being Erlang based. Again deathmatch may be an overstatement but this is my attempt at gleaning some interesting performance data from some high performance web servers. Also, I attempted to improve the graphs this time around since they were a bit hard to read the last time.

The Setup:

I was not able to use the same server and setup as the last time, so comparing between this and my last deathmatch probably isn’t very accurate. For this test I used a Intel Dual Core 2.2GHz, 4GB RAM machine running Ubuntu 8.10 (64bit) and for the test server. Erlang (R12B-3), Yaws (1.77) and Nginx (0.6.32) are installed from the standard repository and mochiweb from subversion (rev 88). All are using the default configurations outside of adjusting listening port numbers. The test is again against a basic robots.txt file. The tests were done using a consumer grade 100mb switch and all tests originated from an old laptop I had laying around. I think that about covers the test bed, if you have any questions let me know.

For the tests I used autobench (httperf under the hood) with the following command, each test ran ten minutes apart. The order of the tests were done in was MochiWeb then Yaws and lastly Nginx.

autobench –single_host –host1 HOST –port1 PORT –uri1 /robots.txt –low_rate 10 –high_rate 200 –rate_step 10 –num_call 10 –num_conn 5000 –timeout 5 –file SERVER-results-`date +%F-%H:%M:%S`.tsv

The Results:

There are a few results from httperf/autobench that I would like to show, errors, network I/O, reply rate (and it’s standard deviation) and response time. (click on the graphs for a larger view)

MochiWeb and Yaws both seem to be the most consistent here. Nginx had a couple of funky spikes, I do not know if this was an issue with Nginx or with my tests and/or test bed. Take from it what you will.

Nginx seems to use a bit more network I/O consistently through the lower ranges of this test and then again as some spikes. MochiWeb and Yaws seem to have some inconsistencies as well.

The reply rate and network I/O graphs certainly seem to be tied, which would make sense. Edit: Average reply rate is average replies per second.

In the higher reaches of the tests Yaws seems to be most consistent.

MochiWeb seems to have consistently the highest response times with Nginx has the lowest. This also follows the data from the first deathmatch. Nginx had consistently low response times against Apache. Edit: Response time is how quickly replies are sent in milliseconds.

Next up are the system graphs, I have CPU usage (both cores combined), context switches, interrupts and load. To help read these please note recall that each test ran ten minutes apart and the order of the tests was MochiWeb then Yaws and lastly Nginx. The data was gathered using sar at five minute intervals and graphed using ksar.

It seems Nginx is the clear winner here. Kernel polling may be the answer here, a retest may be in order to see if it makes a difference.

MochiWeb and Nginx seem pretty even on context switches with Yaws a little higher. I suppose turning on kernel polling might make this a bit more even, since Erlang and Nginx both use epoll. This may also account for the CPU usage difference above.

Interrupts are fairly even across all of them.

Again Nginx takes it, again likely due to kernel polling being disabled. That’s my best guess anywho.

The data I used to create the graphs and etc is available here.

Let me know if you are interested in me retesting anything, I may try to enable kernel polling and try again if I get a chance.

Note that these are *my* experiences with each webserver, your testing and experiences may be different. As with most things there are pro’s, con’s, trade offs and pitfalls. The only way to find out what will work best for your environment is to test, test and test.

Update:

I performed the upper half of the tests again to see if there were any changes to sporadic jumps in the graphs http performance graphs. My initial test using the old laptop I saw the same results. I then ran the tests from a VM (running Ubuntu 8.10 in a KVM VM) on my dual core machine and found that the results were much more even. Unfortunately it’s the same machine that the webservers are running on but the results look much better. The first set is using the same setup as before but just adjusted to have the top half test. The second is the same test but with kernel polling turned on in Erlang.

All of them are very even and close, no real winners here.

Looks like Nginx is the clear winner with Yaws next, followed by MochiWeb.

Pretty much the same as last time (likely a little higher across the board due to running the tests in a VM on the same machine). Note that Nginx is a system process, so for Yaws and MochiWeb follow the blue line and Nginx follow the green.

About the same as before, other than being higher due to running a VM.

Pretty much the same as before again, Nginx seems the lowest.

Now for the tests with kernel polling enabled in Erlang (erl +K true).

With kernel polling on it looks like Yaws actually performs better in the reply rate test with MochiWeb performing worse and Nginx in the middle

In the response time test a huge change is noted, MochiWeb goes from roughly a ~14 ms response time at 2000 requests to ~65 ms. Also noted Yaws performs much better matching or beating Nginx.

With kernel polling in the Erlang webservers Nginx still seems to come out on top for CPU usage.

Following the performance trend we saw above Yaws sees a drop in context switches and MochiWeb increases.

Load-wise things stay roughly the same with Nginx being the lowest.

While it certainly seems that my old laptop that I did the original tests on is too slow or has a network issue, hopefully with these new tests we have some more clarity. It seems that Yaws improves with kernel polling enabled and competes well with Nginx. MochiWeb on the other hand apparently has issues with kernel polling and actually degrades performance. If anyone has more info on the internals of MochiWeb and possible causes I would be certainly interested.

If anyone would like the data from the second round of tests it is available here.

The resulting new module is named sha2 and it implements SHA-224, SHA-256, SHA-384, and SHA-512.

• Code
• Light documentation
• Tests are included in the module but you get the test vectors here
• It’s open source, BSD license

I hope you find it useful.

The new set of Erlang web frameworks is more proof of the number of ambitious, sharp developers moving to the language is growing.

[Update: I’ve posted a new module that implements more SHA digest variants and so renders this module obsolete.]

Scala and Erlang

I met Erlang 2 years ago, which finally brings me to Scala. I learnt a lot from Erlang, and I entered the Scala world with Erlang atmosphere surrounding me. The FP, the Pattern Match, the Actor/Process, I found these familiar friends in Scala everywhere.

Scala has extra bonus, to me. The domains I faced are usually with a lot of business logic, or, the worlds I try to describe are not only messages, they are, models I don’t think are suitable to describe in Function only.

The world itself is OO/FP mixed, like Martin’s quote: Two sides of coin. It’s something like the Particle/Wave in Quantum. The world is an infinite whole, but the reason of Human Being is always finite, it’s an unsolvable contradiction: Infinity vs Finite. We have to read our world in OO and, in FP, in snapshot and in continuation.

There won’t be “Super Hero” in computer languages, the world is getting self-organization and harmony, so do the languages. Each language is living in an eco-system, born, growing via interacting with environment, disappear ...

The Economy

My Self

Then, we got a 8-core CPU machine several weeks ago, and we did same performance testing on it, to see the scalability. Since Erlang is almost perfect on scalability, you can image the result, yes, about 700 transactions/second now, scaled almost linear. Until it crashed with “out of memory” when million hits processed.

It left a very big “erl_crash.dump” file there, I had to dig the issue now. My first guess was, were some remote requests (access db, access remote web service etc) timeout but the process itself was not timeout yet, and cause more and more processes kept in VM?

A quick grep “=proc:“ erl_crash.dump showed that the total number of processes was about 900, which was resonable for our case.

So, which process ate so many memory? A quick grep “Stack+head” erl_crash.dump showed that there was indeed a process with 285082125 size of Stack+head there.

Following this clue, I caught this process:

=proc:<0.4.0>
State: Garbing
Name: error_logger
Spawned as: proc_lib:init_p/5
Last scheduled in for: io_lib_format:pad_char/2
Spawned by: <0.1.0>
Started: Sun Apr 1 01:21:50 2012
Message queue length: 2086029
Number of heap fragments: 1234053
Heap fragment data: 281266956
Link list: [<0.27.0>, <0.0.0>, {from,<0.42.0>,#Ref<0.0.0.88>}]
Reductions: 72745575
Stack+heap: 285082125
OldHeap: 47828850
Heap unused: 121777661
OldHeap unused: 47828850
Program counter: 0x0764c66c (io_lib_format:pad_char/2 + 4)
CP: 0x0764c1b4 (io_lib_format:collect_cseq/2 + 124)

This bad guy was error_logger, which is from OTP/Erlang standard lib: error_log, writing received messages to log file or tty. The typical usage is:

error_logger:info_msg(“~p:~p “ ++ Format, [?MODULE, ?LINE] ++ Data))

Which will format Data to a String according to the Format string, and write it to tty or log file.

The above case showed the message queue length of process “error_logger” had reached 1234053, and the Stack+heap is 285082125, about 272M size.

So the cause may be, that the message queue could not be processed in time, the messages were crowded in error_logger’s process and finally caused “out of memory”. The bottle-neck was that when error_logger tried to format the message to String, Erlang VM was weak on processing them, which seemed to need a lot of CPU cycles.

In my previous blog, I talked about Erlang is bad on massive text processing. Erlang processes String/Text via List, which is obvious bottle-neck in Erlang now, with Erlang is getting much and much popular and more and more Erlang applications are written.

But, why this did not happen on our 2-core CPU machine? It’s an interesting scalability related problem:

“error_logger” module will registered one and only one process to receive and handle all log messages. But Erlang VM’s scheduler can not distribute ONE process to use multiple CPUs’ computing ability. In our 2-core machine, the whole ability is about 140 transactions/second, the one process of “error_logger” just happened to have the power to handle corresponding log messages in time. Under 8-core CPUs machine, our platform scales to handle 700 transactions/second, but there still only one process of “error_logger”, which can not use 8-core CPUs’ ability at all, and finally fail on it.

BTW, I think error_logger should cut its message queue when can not process them in time (disk IO may also be slower than receiving messages).

]]> Blogs, Caoyuan Blog 2008-12-31T20:42:51+01:00 http://www.planeterlang.org/en/planet/article/The_Best_of_Bill_-_2008/ http://www.planeterlang.org/en/planet/article/The_Best_of_Bill_-_2008/ It’s time for the last post of 2008. On December 31, 2004, I created a “Best of Bill” posting for 2004 and it was quite popular (based on the number of unique hits the posting got). So, I continued the tradition each successive year after that. Since 2007 my year-end posting has been cumulative, so it includes the best postings from previous years as well. The latest cumulative summary is always available from the side bar (via the “Best Posts” link).

You can always find my past weblog postings by either drilling down from the monthly summaries (available when you click on the month name in the calendar in the side bar or by clicking on the month name in the summary below) or by using the search utility (also in the side bar). It’s hard to know which posts others find most interesting, but hit counts and email comments seem to be as good a measure as any. So, a feature that I introduced to the summary (from 2006 onward) is that I’ve flagged (using “[*]“ as the “flag”) the posts that either got the most “hits” on my blog each month or ones that resulted in a significant amount of email to me. However, when one of my posts appears on Reddit or Digg, that always drives up the page count even though the post may not be what I would have considered one of my “better” posts. So, I use some “subjective” assessment as well as raw numbers in my rankings. For a number of months, it was too close to call, so I flagged multiple high-ranking posts for those months.

I have deliberately tried to leave out of the summary any postings that are personal, or product/meeting announcements, or non-Lisp related (although my definition of “lisp-related” might be fairly “broad” in some cases ).

My five “most popular” posts of the past year were:

1. What Emacs is to editors, Stumpwm is to window managers
2. Clojure could be to Concurrency-Oriented Programming what Java was to OOP
3. Hacking the OLPC XO Laptop - Part 1: Initial Setup
4. Understanding SLIME (Using Emacs and Lisp Cooperatively)
5. My Lisp-centric “Good Easy”

1. January:
   • Happy New Year and Happy 50th Birthday to Lisp!
   • Installing w3m for Emacs Internet browsing on Mac OS X Leopard
   • Lisp on the OLPC XO Laptop
   • clbuild - (Lisp with Batteries Included - Part 2)
   • Git for SBCL Hackers
   • Hacking the OLPC XO Laptop - Part 1: Initial Setup [*]
   • Hacking the OLPC XO Laptop - Part 2: Xfce
2. February:
   • Hacking the OLPC XO Laptop - Part 3: Ubuntu [*]
   • Hacking the OLPC XO Laptop - Part 4: Debian and Ratpoison
   • Summary of lispvan February meeting - Doing Evil Things with CL
3. March:
   • What a Long Strange Trip It’s Been [*]
   • The OLPC XO “sticky key” Syndrome
4. April:
   • My Lisp-centric “Good Easy” [*]
   • What Emacs is to editors, Stumpwm is to window managers [*]
5. May:
   • Summary of lispvan May 2008 meeting - LoL with Drew [*]
6. June:
   • Lisp by Analogy: Macros=Kanji, Continuations=YouTube
   • Summary of lispvan June 2008 meeting - Using PLT Scheme for Game Development [*]
7. July:
   • Lisp in the Comics - Part 4
   • iPhone: Ubiquitous Computing circa 2008
   • Summary of lispvan July 2008 meeting - Web development with Lisp and UCW (With Lisp it’s cheaper) [*]
8. August:
   • Little Brother [*]
9. September:
   • Embed Books in a Web Page
   • Summary of lispvan September 2008 meeting - The BKNR Common Lisp web application development environment
   • iPhone version of my Blog [*]
10. October:
    • Exploring Clojure (Lisp on the JVM) - Part 1
    • Exploring Clojure (Lisp on the JVM) - Part 2 - Setup
    • Exploring Clojure (Lisp on the JVM) - Part 3 - Some Language Features [*]
    • Exploring Clojure (Lisp on the JVM) - Part 4: Not Your Daddy’s Namespaces
    • Exploring Clojure (Lisp on the JVM) - Part 5: Clojure Documentation using FreeMind
11. November:
    • Clojure is about programming to abstractions [*]
    • How I Use My Mac
    • A Basic Emacs Setup for Clojure
    • Clojure SLIME Mods for Java Documentation
    • Summary of lispvan November 2008 meeting - 0x20 Years of Lisp Systems, a Personal Journey
12. December:
    • Clojure could be to Concurrency-Oriented Programming what Java was to OOP [*]
    • My Clojure Emacs Setup (I’ll show mine if you show yours)
    • Clojure Blogs | Yahoo Pipes | Clojure Pipe
    • Understanding SLIME (Using Emacs and Lisp Cooperatively) [*]

2007:

1. January:
   • SLIME Tips and Techniques - Part 1 [*] (See also Part 2, Part 3, Part 4, Part 5, Part 6, Part 7)
   • Emacs Keymaps and the SLIME scratch buffer
2. February:
   • Using “Open with” Emacs on a Mac [*]
3. March:
   • God Wrote in Lisp Code
   • Darcs Repositories for Edi Weitz’s Libraries
   • Emacs and Google Calendars [*]
   • Mac OS X GeekTool
   • Emacs GeekTool
4. April:
   • Lisp with Batteries Included [*]
   • KPAX - A CL Web Application Framework
   • Knowledge Representation Tutorial
5. May:
   • Backups and the Cobbler’s Children
   • Lisp Blogs | Yahoo Pipes | Lisp Mashup
   • Concurrent Beer Song in Erlang [*]
   • Lispdoc - Online Lisp Documentation Search
   • MapReduce Beer Song in Erlang
   • Farm Where the Fertilizer is Thickest
   • Concurrent Beer Song in Erlang - Part 2
   • Distel = Emacs erlang-mode++ [*]
6. June:
   • Parallel Map Beer Song in Erlang [*]
   • Y Combinator in Erlang
   • Test Libraries for Erlang
   • My Emacs Color Themes
7. July:
   • Quicksilver for Emacs: anything.el [*]
   • Live Code Update in Erlang
   • Distel = Erlang-like Concurrency in Emacs
8. August:
   • Summary of lispvan August 2007 meeting: JazzScheme
   • Gnus and Gmail Setup for Dummies
   • Getting Git on Mac OS X
   • View PDF/PS/DVI files in an Emacs buffer [*]
9. September:
   • Converting QuickTime Movies to Ogg
   • Reddit Clone with Hunchentoot
   • SLIME Refactoring [*]
10. October:
    • Emacs Running All The Time [*]
    • Working with a Metadata-based DSL in Emacs
    • More LispCasts
    • How to start a Lisp User Group
11. November:
    • Regex-tool for Emacs
    • Why you should buy an OLPC XO Laptop
    • The reason there’s a “Cult of Mac” [*]
    • Running Windows/Linux in a VM on Mac OS X
12. December:
    • Emacs Fortune File [*]

2006:

1. January:
   • Concurrent/Parallel Programming - The Next Generation (Follow-ups were posted here, here, and here)
   • Surviving Emacs (Follow-ups were posted here, here, here, here) [*]
   • Lisp is for Entrepreneurs (Follow-up posted here) [*]
   • Update on Termite (A Lisp for Concurrent/Parallel Programming)
2. February:
   • Falling off the wagon with DrScheme
   • New Lisp Online Search Tools
   • Summmary of lispvan February 2006 meeting: PLT Scheme Simulation Collection
   • Who is this guy?
   • The Most Important Idea in Computer Science [*]
3. March:
   • The Emacs Learning Curve
   • St Patrick’s Day Update on CROMA - An Arc-like Lisp [*]
   • Graphing Directories with Flash and CL
   • Summmary of lispvan March 2006 meeting: DSL’s and Lisp Work
4. April:
   • The Best Open Source CL Implementation [*]
   • Fractal Movies in Lisp - Part 2
   • Emacs Nostalgia
   • Summmary of lispvan April 2006 meeting: Wearing Lisp
   • Screen and the Benefit of a Change of Perspective
5. May:
   • CL-MUPROC - Erlang-style Concurrent Programming in CL (Follow-up posted here) [*]
   • Firefox for Emacs users (Follow-up posted here) [*]
6. June:
   • Summary of lispvan May 2006 meeting: Surviving Lisp
   • Elephant and Rucksack - Comparison of two CL Open Source Prevalence packages
   • SBCL, 666, and the Number of the Beast
   • Mac OS X for Emacs Users
   • Emacs Keyboard Customizations [*]
   • Using SLIME to Front-end your App
7. July:
   • MOP Retrospective - Gregor Kiczales speaks to lispvan [*]
8. August:
   • Lisp is the Red Pill
   • Summary of lispvan August meeting - Web Continuations Considered Harmful
   • LispM Manuals Online [*]
9. September:
   • Concurrency-related Updates
   • Summary of lispvan September meeting - Client-side continuations for web programming [*]
10. October:
    • Paul Graham is still working on Arc
    • The Kenny Tilton CLL fortune file
    • Hunchentoot - The CL web server formerly known as TBNL
    • Some MzScheme Interactive Stuff for console/emacs use
    • VM and Gmail Setup for Dummies [*]
11. November:
    • Summary of lispvan October meeting - The PLT Scheme Inference Collection Monday, November 6, 2006
    • Minimal .emacs for Win32
    • We’ll always have Emacs [*]
    • Black Hat and White Hat Hacking with Lisp [*]
    • Macro Stepper for DrScheme
    • SBCL 1.0
12. December:
    • Object Debugger for DrScheme [*]
    • Learning Lisp from Franz - Part 2
    • The Programmer Hierarchy

2005:

1. January:
   • DSL Design Considerations
   • LispWorks Professional/Enterprise with Emacs/SLIME on Win32
   • Audio of Paul Graham’s “Great Hackers” talk
   • Symbolics domain name is #1
   • Parallel Computing in Lisp (Follow-ups were posted here and here and here)
2. February:
   • Escher in Lisp
   • Minion-bot for AIM
3. March:
   • Reading Paul Graham’s essays online
   • CL Implementations for Mac OS X
4. April:
   • Customizing Emacs for Mac OS X (A follow-up was posted here)
   • Zen and the Art of Lisp Programming
5. May:
   • CL, Music and SLIME Tutorials
6. June:
   • Dynamically Edit/Debug Lisp Web Apps with SLIME
   • Lispwire - A New Lisp Software Repository
   • Some useful CL debugging code
   • ILC2005 Conference Photos (Follow-ups were posted here and here)
7. July:
   • Martin Fowler thinks DSL’s are Hot
   • Developing DSL’s in Lisp
   • CLSQL and PostgreSQL on Mac OS X
   • Fractal Movies in Lisp
   • Uncommon Web “Hello World” Tutorial Movie
   • Definitive SLIME Tutorial Movie
   • Continuations in Uncommon Web
8. August:
   • Long Form of define-method-combination in CLOS
   • All Your Closures Are Belong To Us
   • Hints to Macro Writers
   • Some Things Need to be Easy, and Not Just Possible, to Take Advantage of Them
   • OpenMCL Presentation
   • Summmary of lispvan August 2005 meeting - Seaside movie
   • Resistance is Futile - LispWorks Editor Customizations
9. September:
   • SLIME Web Development Workflow
   • Learning CL Web Application Development
   • Return of the Lisp Machine
   • The Holy Grail of Business App Development
   • Doing the Undoable
   • CL’s MOP vs Java’s Reflection
   • What’s so great about jazz?
10. October:
    • MIT Open Sources the LispM Code
    • LispM Links
    • Managing CL Libraries (Follow-up posted here)
    • Now, you too can write a best-selling Lisp book!
    • How are Lisps implemented?
    • ASDF Dependency Graphs
    • Summmary of lispvan October 2005 meeting - Extreme CL Presentation
    • Lisp is the red pill
    • Lisp Logos (A follow-up was posted here)
    • Maxima, SBCL, Emacs, Imaxima, oh my!
11. November:
    • Franz and Macsyma
    • Summmary of lispvan November 2005 meeting - AllegroCache and Dabble movies
12. December:
    • Learning Lisp from Franz
    • Lisp Books
    • LispWorks HTTP Client/Server Movie
    • Using a Lisp Web Server Behind Apache
    • (Re)writing Reddit in Lisp Movie
    • Summmary of lispvan December 2005 meeting: Lisp on Lines movie
    • Remote Lisp Development with SLIME/Emacs
    • Using Circular Structures in CL
    • Creating Stand-Alone EXE’s With CLISP

2004:

1. January:
   • What is the best Open Source Lisp? (A follow-up was posted here)
   • Setting up Emacs for PLT Scheme
   • VisiCalc-like development in Lisp
   • Linux written in Lisp!
   • What is Lisp best suited for?
2. February:
   • Lisp and the future of development environments at the EclipseCon conference
   • The 3 Worlds of Lisp Development
   • How to make money with Lisp
   • Dynamically changing running Lisp code (Follow-ups were posted here and here)
   • New Alternatives for Developing CL code with Emacs
3. March:
   • Using SLIME/Emacs with Allegro CL on Windows
   • Reconnecting to a running Lisp with SLIME
   • Configuring SLIME for 3 Win32 CL Implementations
   • Lisp is slow (NOT!) (A follow-up was posted here)
   • Why Learn Lisp?
   • Using LispWorks Personal with Emacs/SLIME on Windows
4. April:
   • Common Lisp is the Borg of programming languages
   • Modal (Continuation-based) Web Server Framework example
   • Modifying Object behavior in CL
   • Coming to Lisp
   • Parallel Computing in Lisp
   • Thinking in Java/Lisp
5. May:
   • Code Walkers in Lisp
   • Online sources of On Lisp
   • Lisp Books
   • Implementing call/cc in CL
   • Nesting backquotes
   • CL SAX XML Parser Out-Performs Java Xerces
   • Funcallable Macros
6. June:
   • Using MySql with Allegro CL (Follow-ups on CLSQL were posted here and here)
   • Symbolics LispM’s - What might have been
   • CL and Tail-Call Elimination
   • CL proven to be the best programming language
   • Gregory Chaitin, Math, Philosophy and Lisp
   • Genetic Programming in Common Lisp
   • SOAP Web Services in CL
   • CL to Java (Follow-ups were posted here, here, and here)
   • Debugging Approaches in CL (A follow-up was posted here)
   • CL Implementation Benchmarks on Win2000
7. July:
   • Setting Up SLIME for Win32 CL Implementations
   • Hackers & Painters
8. August:
   • Mandelbrot Set ASCII art
   • Initializing structures in CL using BOA Constructors
   • Object Prevalence in CL
   • Printing CLOS class graphs (A follow-up was posted here)
9. September:
   • AllegroCache - Object-Prevalence++
   • Allegro Prolog - A Prolog in Lisp (A follow-up was posted here)
   • Lisp .Net (Follow-ups were posted here and here)
   • Another CL to Java option - Lisplets (A follow-up was posted here)
10. October:
    • Loop extensibility
    • Elephant Object Database now works on Win32
    • Araneida web server now works on Win32
    • CL HTML template languages
    • CL Web Server Options
    • Lisppaste - an interesting program
    • CL Symbols (A follow-up was posted here)
    • Introduction to CL development environments
    • Surviving Emacs (A follow-up was posted here)
    • Lisp Success Stories
    • Trivial Socket programming in CL
11. November:
    • XSLT-like processing in CL
    • Using the Apache Web Server with CL on Win32 (A follow-up was posted here)
    • Re-building stale FASL files after ACL upgrade
    • ACL 7.0 is smokin!
    • Locating ASDF packages on Win32
    • How do people develop code in CL?
12. December:
    • CL Implementations
    • Nested Backquotes considered harmful
    • OS X - My new Lisp platform
    • The Lisp Difference
    • Using LispWorks Personal with Emacs/SLIME on Mac OS X
    • Metaprogramming is hard
    • DSL and Metaprogramming Resources
    • ASDF Build Directories
    • Use continuations to develop complex Web applications

2003:

1. August:
   • First weblog posting! - Lisp Web Server APIs
   • Concise Code and Packages
   • Continuation-based web servers
   • Continuation State Issues
2. September:
   • Continuations and CL Cookbook mods
   • Web Interactions paper
   • On Lisp gems
   • More Continuation stuff
   • Experimenting with Cells
   • JavaScript and Lisp
   • Philip Greenspun’s Epiphany (A follow-up was posted here)
   • Elevator Pitch: Continuations for Web Apps
   • Java/Smalltalk Web Framework comparison
3. October:
   • CL Hyperspec in Info format in Emacs
   • Back from ILC2003
   • Rebel With a Cause
4. November:
   • Using Emacs as a Lisp IDE now on CL Cookbook site
   • I’m Learning Scheme Again
   • R5RS in Info format in Emacs
   • Where is macroexpand in Scheme?
   • CPS transformer that provides a restricted call/cc for Common Lisp
   • Macroexpand in PLT Scheme (A follow-up was posted here)
   • Article about Seaside - a continuation-based Web Framework in Smalltalk
   • Continuation-based Web Framework for CL
5. December:
   • Multi-Paradigm Development
   • A useful function when working with Scheme in Emacs - Eval DWIM
   • Another useful Emacs function - Balanced Comments
   • Some more useful Emacs code - Enable Greek fonts for pretty-lambda - in quack.el
   • Some good intros to Scheme macros

OneTeam for iPhone is a Jabber / XMPP for iPhone that supports a large subset of the XMPP protocol. It is clean, easy to use and to not rely on third party server (it connects directly to your XMPP server).

I think we have reached a point in development where we are really happy with this client. It supports a really large number of XMPP server and authentication method. One of our biggest surprise has been with iChat server that require very unusual authentication methods. OneTeam for iPhone is probably one of the few XMPP clients that now supports it.

We have been quite far today in supporting XMPP features. For example we support gateways discovery and configuration directly from the phone (and gateway contact addition as well). The next big feature is probably be going to be groupchat support.

We are listening to your comments to help us improve this mobile XMPP client. Currently we think it is one of the most usable mobile client, but we are expecting to make it even better. Your feedback is welcome

More details on the product page OneTeam for iPhone.