Kevin's Weblog

Decided to crash a different tutorial after the break. I’m checking out the Subversion session. Sadly, the wireless is not as good in this room.

Subversion has no connection method that supports something like SSH agents. Either cache username and password, or enter it every time.

Copies are cheap, constant-time operations with minimal additional storage required. Makes branching and tagging cheap too (they are just directories in the repository). Easy to change your mind about repository layout.

Hmm... been here 30 min and we’re still essentially on that point.

svn mkdir http://... can create new directories in the repository directly. Similarly for delete. This is handy for working with branches.

status defaults to local changes. Optional to compare to repository.

cvs annotate renamed to svn blame, but also available as svn praise

svn revert to unmodified version (not necessarily the head version). Requires a target and defaults to non-recursive for safety.

Can set properties on files and directories.

merging is always complex, but Subversion is easier than CVS. svn merge -r 15:16 file2 file6 merges the changes in file2 from change 15 to 16 into file6.

Can’t put an SVN repository on a shared disk if accessing directly. In general, using a local-disk repository has issues (permissions, groups). Maybe easier to just set up Apache.

hot backups possible, thanks to Berkeley DB backend.

Speed

DBI is designed for speed, don’t worry about overhead from the frameword. As for your application, pick the right DB, design the schema right. In terms of division of work between application and DB: keep it close to the data, moving data from DB to application over network is expensive. Do more in SQL and stored procedures. But... sometimes Perl is faster than joining in the DB.

Preparing your statements speeds up execution, but can use a lot of time up-front. You need to understand how your optimizer works to get the best performance. Use hints as a last resort, best to let your optimizer do the job, since your key distribution may (will) change.

Remember the SQL cache. Use placeholders to get better cache hit ratio. But, sometimes the placeholder means you can’t fully optimize.

Selecting fewer columns is faster. Using fetchrow_arrayref improves this a lot. fetchall_arrayref is much faster for small number of columns, slower for more.

binding return columns is faster than dereferencing array.

RaiseError is faster than checking return values.

performance profiling in DBI:

> DBI_PROFILE=1 test.pl    # summary
> DBI_PROFILE=2 test.pl    # breakdown per statement
> DBI_PROFILE=6 test.pl    # breakdown per statement and method

DBI Features and Usage

connect_cached saves database handles. Good for oracle, where starting connections is slow. Safer than connecting and reusing because it handles things smoothly if the database crashes or the network goes down or whatever.

Error handling

Errors happen. Failures happen when you don’t handle errors.

RaiseError will call die for you with informative message. You can eval and examine the results in various ways. Or, you can set an error handler with $h->{HandleError} = sub {...}.

From “The Importance of Being Earnest”: Behaving well and feeling well are typically mutually exclusive. Intuitive coding is dangerous. You should be conscious of coding and only depart from guidelines after consideration.

These are D.C.’s guidelines, which might not be best for you. Most important to pick some rules and stick to them.

Highlights:

verb_noun_preposition, verb_noun_participle for subroutine names allows natural language usage. Ex., build_profile_using().

5.6 and later provide aliases from values. Lexical::Alias lets you do some additional tricks.

Implicit localization in for loops - yikes! You can’t break out of a loop and keep the value of the loop variable in the enclosing scope, because the loops is actually using a localized version of the variable which is hiding the version you thought you were using. Probably you should use a subroutine if you need this

List::Util are fast (written in C), you should use them.

You are a developer and a maintainer. So document your code.

There are lots of things that can kill you in Australia; you should go to YAPC::AU.

Don’t use prototypes. They can create non-standard semantics and they don’t work with OO.

Never return undef. You meant return;. (Returns empty list in list context.)

Don’t use bareword filehandles, use lexical filehandles instead. Then put them in braces: print {$file} $num, $name, "\n"

IO::Prompt (coming soon to a CPAN near you) provides nice features for handling user input.

Regexes:

• Always use the /x flag
• Always use the /m flag (make ‘^$’ the same as every other utility, including Perl 6)
• Use \A and \[Zz]
• Always use the /s flag
• Regexp::Auto can do this for you
• Don’t capture unless you need to
• Don’t use $1, etc. Assign immediately, or match-and-assign
• build up complicated regexes from simple units
• Can greatly speed up alternation by factoring out affixes and by using (?>...) (non-backtracking) if appropriate

Readonly, better than use constant?

croak, don’t die. Makes it easier for the user to figure out where they screwed up.

Never cut-and-paste cut code except into a subroutine. Never cut-and-paste a subroutine except into a module.