Day 1 Report

Was good. Not too brutal on the getting up in the morning thing, as 7:00am is when I get up to go to the gym. It was relatively easy to get up and get myself awake and alive in the morning, even with making a lunch (well, throwing some leftovers in foil and into a bag). I’m still not exactly sure how it’ll work for going to the gym in the morning as well, but we’ll see.


The people there were all nice and made me feel comfortable. There was a mini-tour and intro to people in other parts of the building, most of whose names I had forgotten by the time I was introduced to the next one. On the up shot, they will probably remember me now, so I won’t get funny looks wandering through the building.


After getting a feel for what was going on I jumped in, getting to know the system without messing things up too badly. There are a couple of very cool perl modules that I didn’t know about before that are tied to EmbPerl2 that bear some looking at all you perl junkies out there. They are DBIx::Recordset and Embperl::Form::Validate. I’ll go through ’em later, now I need to get my morning tea into a travel mug and head on out for day 2!

4 Comments on “Day 1 Report”

  1. I’ve heard of those modules (from the Embperl mailing list) and even looked at the docs for them, but haven’t tried them. Abstraction on top of SQL (which is already very easy and powerful to use) doesn’t seem write to me. The Embperl module that generates Javascript validation code on the fly seems interesting though.
    Speaking of JavaScript, I was looking at some DHTML code today that uses XML data islands, then uses DIV tags, XPath, and a DOM parser to display data. Very powerful, and all using standard browser tools. No table tags, no font tags, no activex controls, etc.

  2. As much as possible, I’ve been trying to use database views instead of putting all the relations in the perl code. That way, the relations, where statements, etc can be defined in the database… so all you need is a one line SQL query in the DBI code. E.g.
    CREATE VIEW cust_adults AS
    SELECT a.name, b.description, a.a_id from a,b where a.b_id = b.b_id AND a.age >= 19;
    Then, in EmbPerl:
    [-
    ($name, $desc) = $dbh->selectrow_array(
    “SELECT * from cust_adults where a_id=?”,
    undef, $fdat{a_id}
    );
    -]
    Advantage is that the details of how the tables are joined and other complicated details… if you have 8 tables with a whole bunch of OUTER joins, it can get messy. Another advantage is that the query is is stored/cached in the database. This means that even if a user doesn’t have permissions to the direct tables, he can still use the view that was created for him. As another bonus, that same query can be called by other perl scripts… or reporting tools… or database apps written in C++/C/VB/Java/etc. Also, not all the DBI functions require preparing…
    Now I shall go read your other note about a DBIx article or something…

  3. While I agree that DBI is already really easy to use, having something that gets rid of the need for me to write sql, and figure out relations, and remember to do a prepare, and an execute, when I can do something like:
    *set = DBIx::Recordset -> Search ({‘!DataSource’ => $dsn,
    ‘!Username’ => $user,
    ‘!Password’ => $password,
    ‘!Table’ => ‘customers’,
    ‘brkrcode’ => $udat{current_broker},
    ‘$order’ => ‘custcode’,
    }) ;
    (plus you add in a !Tabrelation field if you want to do multiple tables, etc.
    The validation module does server side validation as well, not just javascript 🙂