Is this some limitation of my BT dongle (I can send and receive with a mobile phone...) or something idiotic on Apple part? Any ideas?

I'm using a Fluid SSB with the "real-time" view, and I disabled all the XMPP updates. This way, I can glance to the SSB from time to time, without the interruption of real real-time notifications.

The only feature I miss, I would like to have an action "Mark as seen" at the top of the page tab (next to the "Pause updates"). This way I could glance at it, mark them as seen (this could make them grey-ish) and later it would be easy to pick up where I left it.

Now where is the feature request button for FriendFeed?

I didn't have Keynote.app on the laptop where I wrote it so I decided to try S5 to write my slides.

The HTML version is great, and with a bit of syntax highlighter even the XML examples look good.

But the PDF version is very basic. I searched around for a better CSS to print S5 slides, but could not find anything. Maybe CSS is just too limited for decent printing control.

I don't know if I'm going to use it again. The lack of a decent PDF output is a big minus. On the plus side, I really like having the full power of HTML/CSS/JS inside my presentations.

As for the code examples, I wrote two:

• a basic HTTP-to-XMPP gateway: post stuff and send it via XMPP to someone;
• synchronize several processes to execute in a sequence (for example, restart a web farm, one web server at a time) using a chat room. Includes an auction (very simple, assumes everybody plays fair) to determine the final sequence.

All examples are written in Perl using the Net::XMPP2 framework. I made a few fixes to some of the Net::XMPP2 modules, you can find them inside the repository to make running the bots easier. I'm going to send Robin Redeker (Net::XMPP2 author) those fixes, so they should appear in a future version.

I used fink a lot in the 10.2 days, and I didn't like it that much, and given that my OSS software needs where either covered on 10.4 and 10.5 or a simple ./configure --prefix=my_local_app_dir && make && make install away, I was always able to stay away from them.

But the installation of CouchDB has a lot of dependencies, and there is no way that I'm going to try and install Erlang OTP and SpiderMonkey from source by hand.

So I downloaded the MacPorts installer and run it only to be greeted with a message like "The following install step failed: run postflight script for MacPorts-1.6.0".

Our friend Google tells me that this is was known problem with the 1.6.0 installer in January of this year, but the mentioned 1.6.1 installer is still not released.

So right now I'm trying to run the postflight script by hand. Lets see how that goes.

And by the way, for all of those that told me that "MacPorts is totally safe, it only install under /opt so a mere rm -rf will remove it from the system", I'll recommend you to lsbom the Archive.bom file inside the package, and stop saying that non-sense.

Update: cd /Volumes/MacPorts-1.6.0/MacPorts-1.6.0.pkg/Contents/Resources/English.lproj && sudo postflight seems to work.

The blog post mentions the usual suspects: XMPP for signaling, RTP for transport and a H264/SVC codec. The implementation uses a browser plugin. Time will tell if this plugin will be bundled with Chrome (most likely) or bundled with Gears (would make sense for Google).

The Mac installer includes a meta-package with two packages: Keystone.pkg and the GoogleVoiceandVideo.pkg.

The Keystone.pkg includes the GoogleSoftwareUpdate.bundle that is installed at /Library/Google. Inside it has a GoogleSoftwareUpdateDaemon but so far I don't have it running on my system.

The GoogleVoiceandVideo.pkg is the real deal. It installs several things:

• two QuickTime components, Google Camera Adapter 0 and Google Camera Adapter 1;
• an Internet plug-in, googletalkbrowserplugin.plugin;
• an GoogleTalkPlugin.app support application.

After installation, it opened my GMail account and detected my iSight camera. I wasn't able to find someone to use it with so far, so I'll report back on the quality of the image. I expect a decent quality given the chosen codec.

I'm focusing on Codebits right now, so not much time to check out the XMPP part of this, but it seems to me that then reused the same signaling already used by the Google Talk client, nothing new there.

The big question for me is this: will other sites be able to use this plugin for their own video-chat features? I need to read the license more carefully.

As for Skype, it still has one advantage: I can use it without opening a browser on my Mac. But if I where them, I would start thinking about XMPP support and interoperability with Jingle, but thats just me.

Skype window of opportunity to be the leading XMPP client is shortening every day.

So get of your collective chair-interface-parts and send your ideas.

Thanks!

Update: uploaded 0.6001, with an attempted fix for some 100% CPU usage cases.

The major change is the renaming of AnyEvent::Mojo to AnyEvent::Mojo::Server.

There are two reasons for this change. The first is to prepare the release of AnyEvent::Mojo::Client in the next release, wrapping the Mojo::Client API.

The second is to free the AnyEvent::Mojo to be used with the new functional API.

Starting a Mojo server inside your AnyEvent apps is now very simple:

use AnyEvent;
use AnyEvent::Mojo;

my $server; $server = mojo_server undef, 4323, sub {
  my ($self, $tx) = @_;

  $tx->res->body('Cool!');  
};

$server->run;

The interface is similar to AnyEvent::Socket.

This is the first beta release. I don't expect to change the API in a backwards incompatible way until 1.0.

I do plan the following for the next releases:

• implement AnyEvent::Mojo::Client and the correspondent mojo_client function;
• implement support for 100 Continue.

Mojo is fun!

Oh, and please vote for the Perl Foundation grant to improve Mojo.

Its nice and all, but it doesn't beat the "Best logo of all times, in the Software category"-contest. That prize is still clearly in the hands of SQL::Translator.

Sorry guys, but bonus points for effort. The color of the first version was a step in the right direction.

The biggest change is the new resumable requests. After your handler is called, you can pause the connection, do other stuff using the AnyEvent asynchrounous nature, and when you are ready to send back the response, you can resume the request.

In pratical terms, this is now possible:

sub my_handler_cb {
    my ($self, $tx) = @_;

  # Pause the connection while we HTTP GET our information
  $tx->connection->pause;

  # This HTTP get is done asynchronously
  http_get $status_url, sub {
      my ($data) = @_;
    my $res = $tx->res;


      if (!defined $data) {
        $res->code(503);
      }
      else {
        $res->body($data);
      }

      # Ok, the response will be sent now
      $tx->connection->resume;
  }

  # We paused the connection so we can return
  return;
}

While the inner http_get is going on, the AnyEvent::Mojo server can handle other requests.

This allows you to keep several thousands of requests going on without any effort at all.

I'm still labeling AnyEvent::Mojo as alpha. The interface will change one last time for 0.6. After that it should be beta time until 1.0.

I need to find a decent WebSockets client implementation (or some sort of long-pooling client) to make a decent application with this. Any recomendations?

I also have a slot to talk about XMPP and this is where you can help.

I don't want to do another abstract talk about XMPP, but instead I want to write code that you would like to see.

So if there is some XMPP-based functionality that you want to see how you can get it done, ping me or email me with the high-level details.

I'll take all the projects I can cover in an hour and present my skeleton or even complete solution at the conference and discuss why it was done that way.

All the code will be available before the presentation so you can also follow along.

Fortunately someone did, and I can just point to it and say "thats what I wanted to say".

Update: and by the way, if you want to see the entire Obama speach that he talks about:

• Go to Obama faith issue section of his website;
• click on the "Watch Videos";
• scroll all the way down on the video selection box. Its the last one.

Direct link to Obama Call to Renewal speech.

You could add a buddy for each router that you have. Or one for each perlbal/memcached admin interface.

The internals are still a bit messy but after a small cleanup, you could even have two users, with their own Jabber ID, sharing a telnet session to a router. A kind of Pair-Configuration session.

Just think of all the devices you have with a Telnet administration console: Rasputine should be able to handle it.

I spent an enormous amount of time there and I still have fond memories of that time, of the people, the stories, everything.

But access to Moosaico (and other MUD's or Talkers) is usually done with Telnet or using a client like TinyFugue or Atlantis. Keeping one of those open to be connected somehow never entered my normal workflow, so I drifted away.

Its amazing that something that I was hooked on 14 years ago is still alive in me.

The friday something happened that will pull me back in.

Another friend, Marcos Marado, commented that he was looking for a XMPP interface to his talker, Selva. I had an headache and didn't feel like working on what I was supposed to, so I took the challenge.

Later that afternoon, Rasputine was born.

Rasputine (or Ras, as Corto Maltese called him) is a generic Moo/MUD/Talker-to-XMPP gateway. You add a buddy to your roster and then you can use it to connect to that world.

For example, to log in to Moosaico, add moosaico@rasputine.simplicidade.org and then type //connect. Presto, the login window of Moosaico should be readily available. The Selva talker is available at selva@rasputine.simplicidade.org.

The code is still very young and feature-less. The copy that I run on my staging server already has per-user status messages and avatars, and next I plan to implement auto-connect (probably even XEP-0100 support).

For now, I'm just enjoying getting back to Moosaico.

Update: by the way, if you want to connect your own talker/MUD/Moo, ping me via XMPP or email and I can set you up. At least to try it out.

To use:

cpan HTML::QRCode
perl -MHTML::QRCode -e 'print HTML::QRCode->new->plot($ARGV[0])' TEXT

Replace TEXT with the string you want to encode. For example, a QR Code for http://www.simplicidade.org/notes/ looks like this in HTML:

Who said tables where dead?

Next step: search for a barcode-in-HTML generator.

I've setup all my feeds into my FriendFeed account and subscribed the usual suspects. Also, I used Fluid to create a SSB just for FriendFeed so it doesn't interfere with my main browser.

The rate of updates is still too large for my comfort zone, specially because of twitter updates. I need to look for a way to hide them for all my contacts. After that, it should be back under control.

My relation with the new social web is still undecided. There is a lot of very cool stuff out there, but mostly is a big black hole on my productivity, so I tend to be mostly offline.

Technically, it is an interesting topic. For example, the messaging core behind the the micro-blogging sites (at least the ones properly designed) is the kind of stuff that I really like to build.

Update: via comments, Marcos Marado saves the day. To hide Twitter updates, go to your FriendFeed homepage, hide one of your Twitter updates, and then a link "hide others like this" will show up and allow you to hide all Twitter updates. To show them again, scroll down to the end of the page, and a "Shown N hidden entries", and click "Un-hide".

With a UNIX background, and with only a brief detour to Windows NT 3.51 (the last Windows version with decent internals), I'm mostly keyboard oriented and never before I used a GUI to solve my SCM needs.

This changed with git-gui. With the Stage chunk and Stage line features, I'm much more productive with git-gui, and my commit history is cleaner and more logical to follow.

These features make it easy for me to commit an hours work into several discrete logical steps, and even do a quick commit to fix a small bug without a full cycle of git-stash/fix/commit/git-stash pop.

Anyway, enough courtship. Enjoy.

git-gui screencast from Pedro Melo on Vimeo.

It is a head-less client that runs on a server somewhere, and you can manage it using a HTTP or telnet interface. It also supports a auto-start directory where all the torrent files you drop in it will be picked up automatically.

What it doesn't have is a way to upload a torrent file programatically.

At least, not until today. Check out my torrent-upload branch of Bitflu. It provides a new HTTP-based API to upload a single torrent file.

To use it, do this:

lwp-request -c 'application/x-bittorrent' -m POST \
  http://your.bitflu.site:4081/new_torrent  < my.torrent

The lwp-request command does not support authentication. I need to hack a Net::Bitflu module to make this easier.

The patch was sent to the author, but I don't know if it is something that he is interested on or not.

The foundations of this setup are:

• a GitHub account: the public face of my repositories. A free account is enough, and although I don't have private repositories at GitHub, I'm using the Micro plan, a mixture of kudos to the GitHub owners, and my preference for HTTPS-based access;
• gitosis: manages all my git repositories, both public and private;
• my x-git-update-to-latest-version: I re-compile git every day with the master branch, to help catch regressions.

For each project I have, I keep the repository on all my computers in the ~/work/ directory. Those repositories are synced between work computers (desktop at the office, and laptop everywhere else) using a Unison profile.

The use of Unison gives me the possibility of leaving work half done in the desktop, and finish up at home if I feel like it, without having to commit and push from one to the other.

On each repository, I have two main remotes configured.

The origin remote points to my gitosis setup. You can use my gitosis install how-to for a painless setup. In addition, I add a Host entry to my ~/.ssh/config like this:

Host git
  HostName hostname.of.server.with.gitosis
  User git

This allows me to use a simple git:melo/repo.git as a remote URL. Short and to the point.

The second remote, named github, is only created on public repositories, and points to my GitHub account.

Manually I add a third remote named all. I copy the other two remotes urls to it. This allows me to git push all and have my changes pushed to both remotes with a single command. For example, for the AnyEvent::Mojo project, I have this .git/config file:

[remote "origin"]
    url = git:perl/anyevent-mojo.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[remote "github"]
    url = git@github.com:melo/anyevent--mojo.git
    fetch = +refs/heads/*:refs/remotes/github/*
[remote "all"]
    url = git:perl/anyevent-mojo.git
    url = git@github.com:melo/anyevent--mojo.git

This setup gives me peace of mind (all my code ends up on 4 different systems), and provides a pretty face (Github) for other to use.

Next step: create a script to make all this a one-step process.

Those who despise science and learning are not anti-elitist. They are morally and intellectually slothful people who are secretly envious of the educated and the cultured

Nothing much to add, really. I don't get to vote on this one.

But for the last week or two, I've been working on my laptop without the battery, and in the process I learned something useful.

If I close the laptop lid, and wait for the light to start glowing, I can then unplug the power cord, move to a new location and plug back it again.

The Macbook will use the hibernation feature so I can keep all my state even without any power.

Much better than the shutdown/startup process I was using until I accidently noticed this.

Sebastian Riedel released version 0.7 of his new HTTP stack Mojo (also includes a tiny web-framework called Mojolicious).

The code is very very nice and clean, and in the future you might be able to run Catalyst apps on top of it.

Given that I was looking for a small web framework to run inside my long-lived AnyEvent daemons, I wrote a small glue module to run Mojo-apps using the AnyEvent::Socket/AnyEvent::Handle goodness.

The module is AnyEvent::Mojo, and I've just uploaded release 0.2, that includes keep-alive support.

There are three features that I want to do before a 1.0 release:

• Support for 100 Continue handling: I don't use it but the other Mojo::Server classes have it;
• Asynchronous processing of requests: you start processing a request, but decide that you need something from a network service somewhere. You can start that request, pause the Mojo transaction, and when you receive the response from the network service, you complete the Mojo transaction;
• build a AnyEvent HTTP client using Mojo::Client.

Fun stuff, specially the second one.

Performance-wyse, I'm happy with the result so far. The most simple Mojo::HelloWorld application is capable of this numbers:

# Start a server
perl -MEV -MAnyEvent::Mojo -e 'AnyEvent::Mojo->new->run' &

# Benchmark
ab -k -c 10 -n 5000 http://127.0.0.1:3000/

# Executive summary
Concurrency Level:      10
Time taken for tests:   6.935770 seconds
Complete requests:      5000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    0
Total transferred:      795000 bytes
HTML transferred:       190000 bytes
Requests per second:    720.90 [#/sec] (mean)
Time per request:       13.872 [ms] (mean)
Time per request:       1.387 [ms] (mean, across all concurrent requests)
Transfer rate:          111.88 [Kbytes/sec] received

# (Quad-core 2.6Ghz, Mac OS X 10.5.4, stock perl 5.8.8)

At 700 requests per second with a 1.3 ms delay, the overhead seems to be pretty low, for a pure Perl based HTTP 1.1 compliant server.