I needed to retrieve some HTML from another site, and feed that into WordPress. Found this little gem -- the PHP Simple HTML DOM Parser by S.C. Chen. It's an HTML DOM parser written in PHP5, which lets you find and modify tags on an HTML page with selectors just like jQuery.

Complete manual here (the link is not too obvious on the homepage).

This is the easiest way I have found, to search and mogrify foreign site's content into something useful. Highly recommended.

Last night we heard "Hardening a VPS [Virtual Private Server]" from Jess Hires. A good intro or refresher on the first steps after setting up something like a Linode. Disable root login, lock down the first few services, set iptables firewall rules, ...a very good start. Stepping back and reviewing security on all our existing systems is a good thing every few months.

The Jacksonville (Florida) LUG is stepping up its game, may go after a 501(c)3 tax-exempt corporation status, perhaps under the umbrella of a group of free software groups, to better orchestrate the growing activity here on the First Coast.

Domenic Denicola wrote earlier this year about how the upcoming introduction of "promises" ...well, promises to make writing non-trivial code in JavaScript, and nodejs, actually possible.

Right now, code in nodejs with its emphasis on non-blocking callbacks, is just about impossible to write for anything involving, let's say, databases. For decades we have been writing code like "get a value from the database, check it, look one of the fields up in another database, then..." and so on. We depend on the operating system, or the language constructs, to let other processes operate while the background I/O and computation happen. NodeJS forces us to confront all that nastiness ourselves, and "yield" operation with a callback happening upon completion. This is the way Macintosh 1.0 programs had to be written, and it is as much a nightmare now as it was thirty years ago.

Promises, though, hide the asynchronous nastiness and let values and errors propagate in a sane way.

Once JavaScript gets something like this in core, I might try writing something useful in NodeJS again.

We will be using a module from CPAN for this. A bit tricky to find, but quite simple once you've got it. Code mostly taken from the CPAN documents, but with a few holes filled in.

Here is test1.pl:

# Daemon version
use JSON::RPC::Server::Daemon;

# see documentation at:
# http://search.cpan.org/~dmaki/JSON-RPC-1.03/lib/JSON/RPC/Legacy.pm

my $server = JSON::RPC::Server::Daemon->new(LocalPort => 8080);
$server -> dispatch({'/test' => 'myApp'});
$server -> handle();

1;

And test2.pl:

#!/usr/bin/perl

use JSON::RPC::Client;

my $client = new JSON::RPC::Client;

my $uri = 'http://localhost:8080/test';
my $obj = {
method => 'sum', # or 'MyApp.sum'
params => [10, 20],
};

my $res = $client->call( $uri, $obj );

if($res){
if ($res->is_error) {
print "Error : ", $res->error_message;
} else {
print $res->result;
}
} else {
print $client->status_line;
}

# or

#$client->prepare($uri, ['sum', 'echo']);
#print $client->sum(10, 23);
#

And myApp.pl which is called by the server:

package myApp;

#optionally, you can also
use base qw(JSON::RPC::Procedure);  # for :Public and :Private attributes

sub sum : Public(a:num, b:num) {
my ($s, $obj) = @_;
return $obj->{a} + $obj->{b};
}

1;

Connecting to wireless networks can be a bit of a trial-and-error thing, and the "number of bars" indicator does not tell you the whole story. Here's a single command-line for Linux that pings the current gateway -- so you can try rotating or moving your computer to see how the reception changes.

ping `route -n | grep "^0.0.0.0" | tr -s ' ' | cut -d ' '  -f2`

Here we are nesting the output of a command with the back-quotes. We get the current route table which looks something like this:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     2      0        0 wlan0
0.0.0.0         192.168.1.254   0.0.0.0         UG    0      0        0 wlan0

and then use grep to extract just the line that starts with the universal destination 0.0.0.0, the next field being the IP address of the gateway. Then tr compresses multiple spaces to one, and cut selects just the second field... returning that to ping.

The end result looks like:

$ ping `route -n | grep "^0.0.0.0" | tr -s ' ' | cut -d ' '  -f2`
PING 192.168.1.254 (192.168.1.254) 56(84) bytes of data.
64 bytes from 192.168.1.254: icmp_seq=1 ttl=64 time=2.01 ms
64 bytes from 192.168.1.254: icmp_seq=2 ttl=64 time=1.52 ms
64 bytes from 192.168.1.254: icmp_seq=3 ttl=64 time=1.42 ms
64 bytes from 192.168.1.254: icmp_seq=4 ttl=64 time=1.34 ms

so you get an immediate feedback of times, and timeouts, duplicate packets, and so on. Press Ctrl+C to exit ping.