http://qs1969.pair.com?node_id=110315

Okay, I need some ideas...

I'm trying to come up with creative ways in which to use Perl (or Python) to make my life at work easier. It seems like there must be a way that I can automate some piece(s) of the process and in doing so, perhaps accidentally come off being more productive than I really am (which isn't that hard to do when you get the computer to do your work for you).

My daily routine involves some of the following tasks:

Now, aside from the last point mentioned there, the first thing that might spring into one's mind in a situation like this is to write a <your favorite language> to <sucky language that you work with> converter to make things more fun. In this case however, I would simply get a new job before doing that. :)

Doing my "prototyping" in a language like Perl or Python isn't feasible really either because the app is huge, so the amount of code I'd have to write just to get to the point where I could start prototyping wouldn't be worth the effort.

But what about, for example, all that SQL coding? Has anyone figured out some interesting ways of reducing their workload when faced with writing lots of SQL (an Access-like drag-drop style SQL generator seems like farrrrr too much work)?

What about unit testing? Writing effective unit tests for GUIs seems impractical enough to call "impossible".

What other ways have you found to make your life easier at work? I'm far lazier than Powerbuilder allows me to be, and feel like I'm missing out on ways to do things faster.

Any ideas would be appreciated.

  • Comment on Using Perl with Proprietary Development Tools

Replies are listed 'Best First'.
Re: Using Perl with Proprietary Development Tools
by VSarkiss (Monsignor) on Sep 05, 2001 at 19:44 UTC

    My situation has some similarities: I'm also working on Sybase 11.x databases at a client, where I maintain the data model as well as write a good deal of the back-end SQL code. I have a few cool tools which I wrote for fun and life simplification. You may want to give them a shot.

    Sometimes I need to know if anyone's made changes to a database schema, and if so, what they are. I wrote a tool I called schemadiff that pulls definitions of tables, indices, and views from two databases named on the command line and prints a list of the differences. I do the diff in Perl so I can control the output format. (To see how to read the Sybase catalogs, look at the text of procs like sp_help, sp_helpindex, and so on, with sp_helptext or defncopy. All the system procs are in the sybsystemprocs database.) In your case, you may want to write something that compares the text of stored procedures in your DEV and TST databases rather than relying on the text stored in files. As a matter of fact, you could generalize it so you can compare the text in a file with the one stored in the database.

    Using the same definition-mining code (I really should make it a module ;-) I wrote schemarep, which does a nicely formatted listing of the database's contents. Just some fun with Perl formats.

    I had to write a series of maintenance routines for about a dozen tables with similar structures. Rather than writing a dozen similar procs, I wrote one Perl script in which I described the tables and had it cook up and execute three SQL scripts per table on the fly. That is, the code looks a little like this: 

    my @colgroup1 = qw(foo bar baz);
my @colgroup2 = qw(oop ack);
# ...
my %tables = (
    table1 =>
    {
        KEYS => [qw(colx coly)],
        DATA => [ @colgroup1 ],
    },
    table2 =>
    {
        KEYS => [ qw(cola colb) ],
        DATA => [ @colgroup2 ],
    },
# ....
};
# ...
foreach my $tabname (keys %tables)
{
    my $buddy  = $tabname . '_work';
    my $tabref = $tables{$tabname};
    $sql = qq{
        delete $tabname
        from $tabname t
        where not exists(
            select 1 from $buddy where
        };
    $sql .=
        join("\n and ", 
            map { "t.$_ = w.$_" }
                @{$tabref->{KEYS}};
    $sql .= "\n)";
# ...

    [download]
    In case you're wondering, that last bit of SQL deletes rows from one table where the primary key is not present in another table with the same primary key (the "buddy table"). (I can't post the actual code since my contract with my client stipulates that anything I write here has to stay here. Otherwise I would have posted it to CUFP. But you get the idea.)

    Heh. I'll be watching this thread myself for more cool ideas....

    HTH

[reply]
[d/l]
[select]
Re: Using Perl with Proprietary Development Tools
by clemburg (Curate) on Sep 06, 2001 at 14:22 UTC

    Developing large client/server database GUI programs with Powerbuilder on NT4WS

    Hm. I can't really help you with that one, since I don't know Powerbuilder. For me, the main pain with proprietary builder tools is always that the editors they have suck so unbelievably. Therefore, I have had to come up with a standard method to circumvent this. Basically, it works like this:

    • Install decent editor of your choice.
    • Make macro to copy whole file/buffer to clipboard and bind to key of your choice (e.g., Ctrl-A for interoperability with other Win32 apps, see example code below).
    • Edit only in your editor. Get used to switch to other apps with this sequence (given key binding from above for editor macro): Ctrl-A, Alt-Tab, Ctrl-A, Ctrl-V. (To paste edited text in.)
    • Use cygwin tools to achieve decent command-line productivity.
    • Use a versioning system for all of your code (now that you edit it in a decent editor, this becomes a handy possibility and will save you countless hours).

    Writing zillions of lines of SQL (using the RapidSQL Editor) for stored procedures using a Sybase ASE database

    See procedure from above. Especially the part on the versioning system. CVS works great with Windows Clients, too.

    I am not so much in favor of generating SQL statements with GUI tools. Usually, I am much faster typing them in directly. If it comes down to generating SQL for pre-existing objects (e.g., from GUI specifications), then of course a generator is cool. See Chapter 17 (Template Driven Code Generation) of Advanced Perl Programming. But for real SQL programming, a nice set of editor macros tailored to your needs is much more efficient then a generator, IMHO.

    Routinely having to diff our DEV and TST directories to see which procs we've made changes to on the DEV side that have to be copied to TST and then also compiled on the test database (this one, of course, screams for a program that can manage all of that)

    AHHHH! Horrors! Use CVS! This is exactly what CVS handles very well. And, use automated build procedures (Makefiles, Ant, your own scripts, whatever you want) to rebuild any system state. For me, make (or rather, nmake on Win32 systems) is a real saver. It is easy to program (I think), it is widely available, and coupled with your special scripts (e.g., for a database rebuild) can do almost everything.

    Another thing I found very useful is including a link to the following DOS batch file in the send-to folder (this saves the content of a file in the clipboard): 

    @perl -MWin32::Clipboard -0777 -e "$c=Win32::Clipboard(<>);" "%1"

    [download]

    Example code for editor macro saving whole buffer/file to clipboard:

    Emacs: 

    (fset 'my-copy-whole-buffer "\C-xh\367")

(global-set-key "\C-a" 'my-copy-whole-buffer)

    [download]

    vi (gvim): 

    " this is the mapping created (for command mode)
" like gvim shows it in response to :map command
" <C-A>        yggvG<Esc>

" this is the actual map command as you type it
" less-than and greater-than indicate key to type
" :map <Ctrl-V> <Ctrl-A> yggvG <Ctrl-V> <Escape>

map  yggvG

    [download]

    Christian Lemburg
    Brainbench MVP for Perl
    http://www.brainbench.com

[reply]
[d/l]
[select]

Back to Meditations