Notes

A nice tool that you can use to receive XMPP notification on incoming mails. Some facts: uses inotify to detect new emails, so Linux only;Maildir-based deliveries only;Perl script.My personal attempt at this was not as simple as this one. The current idea is based on qpsmtpd and ActiveMQ but its still in the "back of the brain"-stage.

I just wrote this: $value =~ s/(\s)\s+/$1/g; # Highlander filter for white-space Yeah, sleep deprivation does that to you...

So my kids are 1.3 and 3 years old now, and the oldest one loves a computer game that the place we have breakfast at on weekends has, based on a touch screen interface. It has a set of games, like painting black and white layouts, filling the spaces with colors, basic memory games (6 cards down, with pictures, pick two alike to make them stick), and differences between pictures games.

Two things to make your week start ok: Implementation detail;Skype problems.I needed that. The rest of my week, work related, is not going to be easy or fun.

This has been on my mind for quite some time, but during an email reply to Adam Nemeth today, I found myself putting it into words I like. Jabber will not succeed outside geekdom by selling the IM part of XMPP. That's my gloom point of view. I think that XMPP can be pushed to the clients as an enabler, as infrastructure, on top of which you build several services, in particular notification, but in general a always-on-presence, that all the usual services (email, blogs, social networking sites) can leverage to make their own services better.

Clarification: it seems, reading the comments, that people think that I'm talking about Wikipedia and their choices. I'm not. I'm using Wikipedia as an example as how this system could work and the benefits. Now back to our regular program.... I've always had a love/hate relationship with Wikis. On one hand, I like the perceived easy updating with the direct access provided by those edit links on all the pages. But on the other hand, using a browser to drive the whole experience is a limiting factor.

ejabberd is getting better and better every day. You can look over the developments in the last 6 months following the Process One blog: Millions Users Instant Messaging;Building Large Scale AJAX Chat System;ejabberd roadmap updated;Introducing FlexArch;plugin-based publish and subscribe is a huge leap toward rich presence.The last one is the one. This will make it trivial (for those fortunate enough to be using a publish-subscribe-type system already as one of the tools in their business) to publish via XMPP business-side events, like blog posts, comments, uploaded photos, new classified ads in your area, job offers, and much much more.

Most of my time, I program inside async event loops like Danga::Socket or POE. Accessing DBI inside those loops is not a straight forward thing. Most solutions involve forking worker threads and using pipes to communicate between my script and those workers. There are a couple of components for POE that do most of the work out of the box, like POE::Component::EasyDBI, but still, it feels a lot like an hack.

In a project I was working on, I had some performance problems to startup a DBIx::Class schema with about 75 sources. It took about 19 seconds to startup. After a quick thread in the mailing list, the startup time is now 2 seconds. The two-part solution is this: move all your load_components() into a common class and use that class as the base for your sources;use the schema provided load_classes(), its very fast.

If you have Growl installed, and you use the Terminal.app a lot, then make sure you also install the growlnotify command line tool. This will allow you to send Growl notifications from the command line. The most useful script I have, that I use constantly is this: #!/bin/sh # # Runs script, and prints a notification with growl when it finishes # $* growlnotify -m "Script '$*' completed" -s "Background script notification" & My version is called n, just the single letter n.