RubyForge: XML::Simple (with my experiences as updates)

RubyForge: XmlSimple: Project Info

Rather short after discovering this module, I made use of it with my FRITZ!Box call monitor in order to read my Google Contacts as XML. With this approach, that was a rather easy piece of cake.

Update 2011-03-29:
If an element has not attributes, the (text) content of that element simply gets appended as string to the list at the hash field by the name of that element.
Now if the element has attributes, the (text) content goes together with the attributes to a hash list, that gets appended to that list instead. The (text) content actually goes into a hash field by the name of "content".
Example:

text -> "e"=>[            "text"]text -> "e"=>[{"content"=>"text","a"=>"v"}]

My Ruby code operates like this:

x.instance_of?(Hash) ? x['content'] : x

my call monitor software is going jruby

My FRITZ!Box call monitor is written in ruby-1.9. So far I am running it using MRI-ruby-1.9.

This call monitor is a FRITZ!Box call monitor, it does not monitor the calls on my smartphone yet (which is rather, rather sad). Most of the year (for economical reasons) I should sit in a customer's office quite a little away from my place – receiving calls on my smartphone. So it makes much sense to get my call monitor software to monitor the calls on my smartphone one day (rather sooner than later).

Just recently (with the help of RVM) I delved into the the jruby world, and of course I am trying to run my call monitor software also with "jruby --1.9".
My current problems with "jruby-1.6.0.RC2 --1.9" are with I18N and encodings, so I cannot open my gmail address book with "r:UTF-16LE:UTF-8". My evasive strategy is to let it read a UTF-8 version of it.
The ruby CSV module, that parses my address book using regular expressions, seems to give the runtime system yet unseen tasks.
Maybe I am not too far away from running a slightly adapter version of my call monitor in jruby and therefore on a JVM.

Of course, IronRuby (a .Net ruby implementation) is also an option.

There are not that many different smartphone operating systems, that run JVM-s, so we are mainly talking about Android.
Does Android allow non-core software to (sort of) monitor the incoming and outgoing calls?

Once jruby successfully runs my call monitor, the way is free to go for an Android implementation. I am rather hot for it.

Update 2011-03-07:
After a couple of postings on user@jruby.codehouse.org and especially with the support of Thomas E. Enebo, my software now runs just as well with the very, very latest jruby, that I produced through "rvm install jruby-head".

Update 2011-03-28:

Now it runs reading the XML Google Contacts, which is more comfortable, as I can download it on the command line.

your Google Contacts address book as XML

Today I came across a rather interesting thread on the googlecl-discuss mailing list, it's subject was "Backing up contacts", and it thrilled me instantly. With this command line, you get your address book dumped as completely, as it currently can get:

$ google contacts list --title='' --fields=xml

Of course you must have an up-to-date gdata-python-client and googlecl installation. But you do have that anyway, don't you? I updated mine today.

Yes, the XML misses an enclosing top-level element – but you can add that easily.

I would also love to see the groupMembershipInfo in a rather "accessible" way, but I guess, that will also come sooner or later.

This lists alls groups (and not in XML for currently trivial reasons), but I am not able to relate the groups to the (group) URIs mentioned in the contacts XML:

$ google contacts list-groups --title='' --fields=xml --verbose ".*"

…

My FRITZ!Box call monitor software will make use of the XML Google Contacts rather soon. That way I can skip all the current JRuby CSV and m17n problems. Its also more comfortable to download, because I can do that on the command line. And if it's more comfortable, you do it more often. Backing up your address book frequently isn't a bad idea either, right?!

Update 2011-03-28:
Task accomplished for my FRITZ!Box call monitor software, also if executed through jruby-1.6.0.

perlfork - Perl's fork emulation

perlfork - Perl's fork emulation

Picked this up on twitter from a conversation between 2 rather well-known hard-core Rubyists (and both certainly former hard-core Perl Mongers):
my mate James Edward Gray II (author of the Textmate book, author of the Ruby CSV library modules, renowned I18N guru, contributor to my FRITZ!Box call monitor, …) and Yehuda Katz (member of Engine Yard, Rails core contributor, …).

SYNOPSIS

Perl provides a fork() keyword that corresponds to the Unix system call of the same name. On most Unix-like platforms where the fork() system call is available, Perl's fork() simply calls it.

On some platforms such as Windows where the fork() system call is not available, Perl can be built to emulate fork() at the interpreter level. While the emulation is designed to be as compatible as possible with the real fork() at the the level of the Perl program, there are certain important differences that stem from the fact that all the pseudo child ``processes'' created this way live in the same real process as far as the operating system is concerned.

This document provides a general overview of the capabilities and limitations of the fork() emulation. Note that the issues discussed here are not applicable to platforms where a real fork() is available and Perl has been configured to use it.

Wanderlust, Michael Lopp, and my FRITZ!Box call monitor

Just the way Michael Lopp describes it in his book Being Geek -- The Software Developer's Career Handbook in the section on Wanderlust, I have carried around that idea with me for quite a while, that I would like to be able to see on my phones, from which company somebody is calling, in case I don't have a specific entry for him/her in my address book.

Today I got up and I knew, the feature is actually already implemented. I do maintain a list of country calling codes, which my call monitor actually reads, when it starts up. Today I just understood, that a company's core phone number is just a little longer than a country calling code, but actually my software doesn't mind that. So I started adding company core phone numbers to that list.

And from now on, that should only be rare occasions, where I don't know, from which recruiting company and which location, the recruiter is calling from. I love it.

a call monitor for the FRITZ!Box, using a gmail address book and an area code directory

The FRITZ!Box family of routers also provide telephony services, actually all my phones go through my 7390. They are built using Linux and Busybox. On its TCP/IP port 1012 it offers event records on all telephony actions. Last Christmas I implemented a ruby script dealing with these event records and the "call threads". Yes, there is even a notion of "call threads". At that time I already decided I wanted to use my gmail address book as the data base for looking up all telephone numbers. Now I completed this task. There is a directory of area codes for Germany ("ONB"). I also make use of that one now: For every caller, whose telephone number is not listed in my gmail address book, I show at least from which area he called. I am rather glad with this software.
Initially I also wanted to make this ruby script an OS X cocoa ruby script with a colorful GUI, maybe to run on my iPhone. I'm not sure, whether I will ever be able to work on this.

Update 2010-07-02:
Having my script running now stably for quite a while, it was time for a new feature – somehow.
I have been using procmail for splitting my incoming e-mail for like 13 years or so now.
The procmail rules obviously derive from the addresses I am expecting e-mail messages from.
In former times I had a plug-in for emacs's BBDB, that created raw procmail rules from my emacs address book.
Now with my new approach it makes sense to generate procmail rules from the gmail address book.
Tonight I was in the mood for an little programming excercise, and I implented this feature rather spontaneously. I like it very much.
Right …, generating procmail rules isn't really a proper task for a call monitor, I do know that.

Update 2011-03-28:
This software now makes use of an XML Gmail address book. If you want to find out more on this issue, filter this blog using the tags shown below!