Notes

This last Saturday, I was at Barcamp PT and started to talk with Nuno Moreno about games, specially online quest-style games.

I remembered an old game, the Heineken Challenge, that was very popular at least here in Portugal. I'm not sure when it was online but it seems 1996 is the correct year.

The problem is that 1996 is like 1BG (1 year Before Google), so I can only find about the new Heineken set of lame flash games.

Anyway, if anybody here can find a reference to this game, please leave a comment, thanks!

Posted by Pedro Melo at 12:02 PM | Permalink | Comments (view)

I've updated the small contact box at the top of the right sidebar.

With a single click you can now contact me with:

• XMPP;
• email;
• voice call (both PTSN and Skype address).

The PTSN number is actually a SIP-based VoIP number. I'm now using the amazing telephone SIP client for Mac OS X. Kudos to Celso for a nice how-to to use with my current provider.

Posted by Pedro Melo at 01:30 PM | Permalink | Comments (view)

This is probably basic stuff for some of you but it was a surprise for me.

Your ssh command line client can work as a SOCKS server. Its actually very simple to use:

ssh -D 5566 remote.server

The -D 5566 will make ssh start a SOCKS (v4 and v5 supported) server at port 5566. You can now set your SOCKS server for your preferred apps as 127.0.0.1:5566.

The connections will be made by the remote.server to the destination host.

Very useful indeed.

Posted by Pedro Melo at 12:23 PM | Permalink | Comments (view)

Some days ago, I forked qpsmtp repository on Github/ to fix a small RFC compliance bug. It was a simple fix, and Ask pulled it the next day.

I was left with my fork of qpsmtpd without any practical reason for it.

Github makes it easy to fork, but not that easy to know if I can remove my fork. It would be nice to have a way safely cleanup my forks.

It would also be great to list forks separate from my own projects in my public page.

I think its time for a couple of feature requests...

Posted by Pedro Melo at 05:39 PM | Permalink | Comments (view)

I've pushed a new tool to my scripts repository at GitHub, x-test-continuous.

This script watches changes in the ./lib and ./t directories, and executes the command given as argument on any changes. Right now, I've hardcoded a one second delay.

My usual command while I'm writing a new Perl module is this one:

x-test-continuous prove -l -v -r t

Now, my tests are a single "Save all" away.

An even better usage, in case you are using TextMate. First, open your TextMate preferences and enable Advanced > Saving > Save files when focus is lost. Then, run this command on a tall terminal window:

x-test-continuous 'clear; prove -l -v -r t'

Now you can just click or Cmd-Tab between TextMate and your Terminal window.

This script only runs on Mac OS X 10.5.x for now. Need to learn how to use inotify on Linux.

Posted by Pedro Melo at 01:46 PM | Permalink | Comments (view)

I'm a bit sick of hearing applications call themselves "feed aggregators" when they simple show me a chronological sequence of unrelated articles.

Sure, I guess that 4 or 5 years ago that was enough and worthy of the word, but in between I jumped from 20 or 30 to 354 feeds (I usually prune to 250 each 6 months).

I think its time to move up the goal post: you cannot call yourself a aggregator without actually doing it - finding relations between articles and presenting them in useful ways.

Let me give you some examples.

You follow feeds A, B and C. If article X from feed A is referenced by article Y in B and Z in C, at the very least I should have a "See also" section while seeing X on my feed reader. A link back inside the feed reader, from Y and Z back to X wouldn't also be out of the question.

And it makes sense to place Y and Z right next to X. I would first read X, and then the next one would be Y and Z in some order (a graph-theory-lover would expect that all articles in your feed reader should be read in a breadth-first order, actually.)

Also, feed reader companies seem interested on getting from you your activity stream. Such valued commodity is taken from you (with your consent in most cases) without giving nothing in return. They don't allow me to say "I like this article" so that I can influence a Baysean classification system. Sure, because I do expect the feed reader to suggest to me what are the articles I will like the most after some time.

This are just some ideas. I bet you'll be start to seeing them of them in the future, but with a magical new name. Marketing people like to create new names for features that should be part of the natural evolution of products.

In the meantime, if you have a feed reader that runs on Mac OS X, and that I can use on several Macs, please leave a comment.

Posted by Pedro Melo at 12:38 PM | Permalink | Comments (view)

Yesterday, Jaiku was turned off for a 24 hour maintenance. The goal: move it to the Google App Engine.

The site is now back, and the announced future is here: Jaiku is now a community maintained project called JaikuEngine (to be seen, really, its not there yet).

There are a couple of changes: SMS (as any sane cost-consciencius person would expect) are gone for all but US networks, and they will no longer pool your feeds (this was a surprise for me, and I think a lot of Jaiku'ers will be unhappy).

Also, the XMPP bot is still supported, so it seems that the announced support for XMPP and background processes on Google App Engine is working.

I don't know what is the future of Jaiku, but it will be interesting to see it unfold.

Posted by Pedro Melo at 08:28 AM | Permalink | Comments (view)

Today, Amazon AWS announced a new pricing tier for EC2 instances.

If you commit to 1 year or 3 years, with prices $325 or $500 respectively, you'll get a small EC2 instance for as low as $49-$35/month. Compare that with the current $75 per month, and it sounds like a very good deal if you have a constant set of EC2 instances.

The other interesting announcement is already a couple of months old, the new Amazon S3 Requester Pays Model.

This model should allow companies like DropBox to offer a lower-priced service with zero storage, and the end user uses its own S3 key for storage and transfer costs.

If this is a good deal for the end-user remains to be seen. A $100/year service from Dropbox gives you 50Gb, a $92 cost with the current S3 pricing structure. Of course, most people will use less than 50Gb, so that difference reverts to Dropbox. But on the other hand, you don't pay any data transfer costs, the risk is on their side.

But at least in terms of clear ownership of the data, it is much more reasonable for my data to be under my own key.

Posted by Pedro Melo at 12:29 PM | Permalink | Comments (view)

Rui linked to an article about excessive EU regulation on roaming charges and its impact on competition.

Its a very interesting article, highly recommended, but the opposite side of this coin is not as clear cut as it seems.

Yes, excessive regulation does prevent competition, and can cause more harm than good.

But expecting that unregulated competition between providers will benefit customers in the long run is not right either.

Competition will benefit consumers in the short run, while telcos really work for market share. But as soon as dominance is achieved, corporate greed will always win. Its part human nature, part investor pressure.

So, the question is the level of regulation and not its presence or absence. I particularly feel that anti-cartel regulation is even more important than controlling the pricing.

Just my €0.01.

Posted by Pedro Melo at 12:15 PM | Permalink | Comments (view)

Some weeks ago, Johannes Schindelin talked about the UGFWIINI (Use Git For What It Is Not Indended) contest. You can read the initial candidates in the git mailing list thread.

A couple of months ago, I had this idea of writting a script that would constantly watch over a directory (including subdirectories) and commit the changes every time anything would change.

At the time, the tought of battling the FSEvents interface was not appealing at all, and it was just a joke anyway. But in the since then several things happened:

• Andy Grundman released Mac::FSEvents to CPAN: a working interface to the FSEvents system, with a extremely nice API;
• João Pedro, a friend at SAPO, IM'ed me asking for such a script: I pointed him to the new Perl module;
• A script, Flashbake, by Thomas Gideon made it to the contest.

So I had no chance but to write such a script.

My version is a quick hack, but already works perfectly. It watches a specific directory, and commits all the changes to a standalone Git repository.

To use just do:

cacm --repo dir_of_git_repo --watch dir_to_watch

and it will start recording your changes with git commits.

Right now, it commits at most once per 5 seconds, but you can tweak that using the command line option --latency latency_in_seconds.

I've uploaded version 0.01 to CPAN. To install just do cpan App::CMAM (it might take 24 hours to spread to your CPAN mirror).

For version 0.02 I'll clean some small details:

• ignore .git and other common directories;
• cleanup git invocation: all the output should be hidden from you.

Fun!

Posted by Pedro Melo at 05:09 PM | Permalink | Comments (view)

One of my favorite XMPP clients is under a new^H^H^Hold management. Kevin is stepping down, and Justin is back to the driver seat. I've been lurking in the Delta mailing list, so I'm very excited with the developments there and the possibilities that they open up for Psi.

But Kevin is not out of the XMPP client world. He and Remko announced a new cross-platform client called Swift.

Not much is known for now about Swift but I expect a bit more news over the weekend.

While we wait, I'll leave here my wish list for my next client. I don't know if Swift is going in this direction or not, this is just me thinking out loud:

• C/C++ minimal core: the core is responsible for XMPP connections and stanza parsing;
• HTML-based UI: all windows are HTML-based. If they choose to use Qt, they would be WebKit views. The DOM of those views would be extended with XMPP-oriented objects;
• JavaScript-based application: the IM logic is written with JavaScript, manipulating the XMPP DOM objects and the HTML-based UI;
• Plugins: all features should be written as plugins. I should be able to drop a directory with HTML, CSS, images and JavaScript files and hook that into the XMPP dispatcher. It should be possible to hook using XPath expressions, so that I can build new protocols with ease.

We can dream, right?

Posted by Pedro Melo at 11:35 AM | Permalink | Comments (view)

In a decent sized session of yak shaving, I found a new beautiful tool: git-cpan-init. If need to hack on a CPAN Perl module, git-cpan-init will:

1. init a new git repository in the current directory;
2. fetch the module tarball;
3. unpack it, and commit that version to git, tagging it with the version number.

This leaves you with a ready-to-hack git repo. But it doesn't end there. After you added your fix or feature, you can use git-cpan-sendpatch and this will:

1. create a patch with your modifications;
2. create a RT ticket with the patch.

Instant gratification!

So I had no excuse to patch Net::Libdnet to use dnet-config to find the location of the libraries and include files. It was easy as pie.

In the process I also fixed a warning with git-cpan-import, but yannick was already using git to host Git::CPAN::Patch, so it was even easier.

Posted by Pedro Melo at 12:31 PM | Permalink | Comments (view)

While we wait for the new O'Reilly book, XMPP: The Definitive Guide, Peter and Remko published their latest slides from FOSDEM.

Good intro, solid presentation. Go, read.

Posted by Pedro Melo at 10:59 AM | Permalink | Comments (view)

I admit that I really like D. J. Bernstein software. I use on a daily basis qmail, dbjdns, daemontools and ucspi-tcp. I also know that he can be a bit difficult sometimes. I've seen him on the qmail mailing list in the late 90's and he could be very hard on people (case in point, Brad Knowles). But I never saw him on the wrong side of reason.

Thats why I'll be watching with pleasure the next battle on the horizon. Everybody who has read DJB on DNS security (scroll down, to "Under the hood: DNS problems") know that he really doesn't believe in DNSSEC. But now, we have his answer to the problem.

Yesterday his site was updated with a link to his secure DNS solution (top and bottom of the page), dnscurve. I haven't read it yet, but I'm sure I'm going to enjoy it.

Posted by Pedro Melo at 06:49 AM | Permalink | Comments (view)