Notes on setting meteor up on Ubuntu

I’ve been curious about trying comet and a look at http://cometdaily.com/maturity.html suggests meteor is the obvious choice for me given my love of perl.

I’ve only scratched the surface so far but it seems really easy to use and potentially pretty powerful.  Having just taken it out of the box I figured I’d note down the tweaks I needed to make to install it on my ubuntu box.  I followed the installation instructions and they’re pretty good, just tailored to Fedora it appears.

1. Execute permissions.  The two main scripts once untarred didn’t appear to have execute permissions.  Just chmod +x /etc/init.d/meteord and meteord.
2. The /etc/init.d references some init helper scripts that are presumably specific to fedora or that general flavour of linux.  Commenting out the . /etc/init.d/functions line doesn’t do any harm.  That stuff presumably just provides nicer gui stuff.  Without it you don’t see a ‘started’ message when you start, but a quick check of the log at /var/log/meteord shows whether it’s loaded or not.  I suppose the one thing they could do to make things smoother is to add a test for that script and simply not execute it if not found.
3. The init script truncates the log every time the server runs.  I’m not entirely sure if I like that or not.
4. If you don’t install to the default /usr/local directory you need to add the SubscriberDocumentRoot parameter yourself manually to the config.

Now I have the shiny new technology to play with I have a few questions to ponder.  Mainly to do with setting up things for intranet type sites where everything is done by logged in users.  Like how do I do security so only valid people see the stuff they are meant to?  Can I put comet on ssl?  For that last one I’m wondering if it’s worth trying to run the comet server through apache as a fastcgi server so I can make use of it’s ssl handling and also solve the problem of needing two domain names.

Piping a really large variable dump to a file

Sometimes I’m looking at a really large variable dump in the perl debugger and I want to be able to look at it in something with more control.

To view the dump in less simply add a | in front of the dump command.  For example,

| x $var

If the control less gives you isn’t enough you can then use that to dump it to a file by doing this from less,

|$ cat > var_dump.txt

 

Test::DBIx::Class and create_ddl_dir

I just realised there is an odd ‘feature’ that comes into effect if you happen to combine Test::DBIx::Class and create_ddl_dir. It’s not technically a bug because it’s technically legitimate features but it causes some odd side effects in my test code.  Warnings about drop statements when no table existed.

$ /opt/perl5/bin/prove -l t
t/02-xmlcheck.t .... DBIx::Class::Storage::DBI::__ANON__(): DBIx::Class::Schema::deploy(): DBI Exception: DBD::SQLite::db do failed: no such table: phonenumbers [for Statement "
--
-- Table: phonenumbers
--
DROP TABLE phonenumbers"] at /opt/perl5.10.1/lib/site_perl/5.10.1/Test/DBIx/Class/SchemaManager.pm line 169
(running "
--
-- Table: phonenumbers
--
DROP TABLE phonenumbers") at /opt/perl5.10.1/lib/site_perl/5.10.1/Try/Tiny.pm line 98
t/02-xmlcheck.t .... ok
All tests successful.

I’ve been using Test::DBIx::Class to test my model code and by default it creates an SQLite database in memory so a drop statement at the start didn’t make sense. The actual error messages didn’t actually cause my tests to fail but they weren’t desirable. It turns out that the reason I was getting them was because I’d also done a create_ddl_dir to create schema files for databases, including SQLite and left the files in the dir I was running the tests from. The DBIx::Class code was detecting them and using them to generate the tables. They contained drop statements because they were standard schema’s intended for use with real databases.

As soon as I realised that and moved the schema files into a different directory the drop errors disappeared. As I say, I don’t think this is a bug, more a couple of features interacting in a way that wasn’t what I wanted. I’m just documenting what I found so that when I encounter it again in a couple of months and have forgotten the reason I’ll be able to read why.

Test::DBIx::Class is a really useful module and it makes doing tests of the data layer really simple. It’s worth checking out if you are using DBIx::Class because it makes the cost of doing data tests a lot lower. It’s possible to switch to using a real db if necessary but by default I use the in memory tests most of the time because it means there is no reason not to run the data tests wherever I deploy modules to.

Git revert

I’ve finally figured out what the rough equivalent to a revert in subversion is. It’s a git reset --hard. It’s not quite equivalent but it’s probably what I want most of the time I want to clear out my working directory of temporary changes.