cbrooks's Journal http://use.perl.org/~cbrooks/journal/ cbrooks's use Perl Journal en-us use Perl; is Copyright 1998-2006, Chris Nandor. Stories, comments, journals, and other submissions posted on use Perl; are Copyright their respective owners. 2012-01-25T02:26:41+00:00 pudge pudge@perl.org Technology hourly 1 1970-01-01T00:00+00:00 cbrooks's Journal http://use.perl.org/images/topics/useperl.gif http://use.perl.org/~cbrooks/journal/ Shameless plug: podcast any RSS feed http://use.perl.org/~cbrooks/journal/25114?from=rss <p> I thought I'd plug my new project on use.perl as some of you might find it interesting. </p><p> <a href="http://www.talkr.com/">Talkr</a> is a service that allows you to create a podcast of any RSS feed. </p><p> If you point Talkr to an RSS feed (your own or someone else's), Talkr will give you an RSS feed that points to an mp3 file for each article. You can configure your computer to download those audio files as they become available and drop them directly onto your iPod (or other mp3 player). </p><p> Here are links to a couple of BoingBoing articles if you want to hear what it sounds like: </p><ul> <li> <a href="http://www.talkr.com/audio/b/o/i/n/83657.mp3">Smile for the Google 3D mapping truck</a> (27 seconds)</li><li> <a href="http://www.talkr.com/audio/b/o/i/n/83341.mp3">Bluetooth PIN crack: not a good thing, say researchers.</a> (1:42 seconds)</li></ul><p> Talkr runs on mod_perl, of course. If you are interested in trying Talkr out with your own blog, you can sign up <a href="http://www.talkr.com/app/partners_inquiry.app">here</a>. </p><p> &lt;full_disclosure&gt;<br> &nbsp;&nbsp;&nbsp;&nbsp;Talkr is not affiliated with <a href="http://www.boingboing.net/">BoingBoing</a> in any way. They just write about interesting stuff.<br> &lt;/full_disclosure&gt; </p> cbrooks 2005-06-09T13:22:44+00:00 journal Consumer VOIP http://use.perl.org/~cbrooks/journal/10725?from=rss We just signed up for <a href="http://www.vonage.com/">Vonage</a>'s consumer voice over ip service, and I thought I'd give it a quick review<br> <br> The good: <ul> <li>$39.99 a month, flat fee, unlimited usage anywhere in the US and Canada. That includes call-waiting, voice mail, caller id, etc. They have a $25 plan as well, which has some limitations on the number of minutes you can use.</li><li>Configuration was simply plug and play. The only problem that I had was that I left the ringer off on the phone that I initially used -- so I mistakenly thought that I was not receiving incoming calls.</li></ul><p> The bad: </p><ul> <li>You need broadband internet access. A minimum of 90 kbps up and down is required.</li><li>Although they can let you keep your existing phone number in some cities, we couldn't keep ours. In fact, although we were able to keep our area code, we couldn't even keep our local exchange. (Their customer support folks claim that this will change in the next few months.)</li><li>You have to dial all 10 digits to dial any number (even local calls).</li><li>They don't support 911.</li><li>I occassionally notice a slight echo of my own voice, and (occassionally) you can't hear sounds from the other end of the line while you are speaking. (I have 1.4 mbps down / 300 kbps up.)</li><li>I have to buy a new wireless expansion phone, because my LynkSys switch is on the 3rd floor, and we want a phone on the 1st floor.</li></ul><p> That's a substantial number of drawbacks, but it's still worth it to me, considering that our phone bill was $170 last month.</p> cbrooks 2003-02-21T14:55:19+00:00 journal Security bug in CGI::Lite::escape_dangerous_chars() http://use.perl.org/~cbrooks/journal/10542?from=rss It doesn't look like anyone else has posted this to use.perl yet. A security <a href="http://msgs.securepoint.com/cgi-bin/get/bugtraq0302/94.html">flaw</a> in CGI::Lite was posted to bugtraq yesterday. Essentially, the escape_dangerous_chars() method fails to escape a number of metacharacters.<br> <br> The impact statement says:<blockquote><div><p>If the CGI::Lite::escape_dangerous_chars() function is used within (for example) a web CGI script, a remote attacker may be able to read and/or write local files on the attacked web server and/or may be able to gain shell-level access to the attacked web server, via the CGI script, as the user-id under which the CGI script is executed (typically, but not always the `nobody' user).</p></div> </blockquote><blockquote><div><p>The potential exists for remote root compromise (or other privileged access) if a CGI script using CGI::Lite::escape_dangerous_chars() is installed as set-uid (root) or set-gid.</p></div> </blockquote><p> As noted by the white hat who found the flaw, CGI::Lite's maintainer has not responded with a patch (and the lastest version of the module available on CPAN is from 8-20-2000).</p> cbrooks 2003-02-12T13:10:14+00:00 journal Cross-Site Tracing (XST) security vulnerability http://use.perl.org/~cbrooks/journal/10132?from=rss Ilya has already mentioned <a href="http://use.perl.org/~IlyaM/journal/10127">this</a>, but he has comments disabled, so I thought I'd make an entry as well.<br> <br> XST is a newly-<a href="http://www.whitehatsec.com/press_releases/WH-PR-20030120.txt">reported</a> vulnerability that combines traditional XSS (cross-site-scripting) attacks with HTTP TRACE. The traditional XSS part of the attack is that a blackhat could embed a malicious JavaScript (or other client-side scripting language) function in a web application that does not properly screen client input. The JavaScript function in turn can craft an HTTP TRACE request (using the XMLHTTP ActiveX control in IE or XMLDOM in Mozilla). HTTP TRACE simply echoes your HTTP request, including HTTP Basic Authentication strings (which are passed as base64-encoded cleartext), which apparently makes this new attack noteworthy. XSS attacks could not previously access Authentication strings.<br> <br> The tone of commentary on Bugtraq generally seems to downplay the severity of this vulnerability for two reasons: (1) very few people have ever seen XSS attacks in the wild; and (2) the vulnerability would be largely mitigated were Microsoft to simply remove XMLHTTP's ability to send an HTTP TRACE request.<br> <br> If you use HTTP Basic Authentication on your server, you can protect against this method of reading authentication strings by disabling TRACE requests. Disabling TRACE on Apache is trivial, assuming that you have compiled Apache with mod_rewrite:<br> <br> ##########################<br> #<br> #This rule is in response to http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf<br> #<br> RewriteEngine On<br> #Test the server variable REQUEST_METHOD to see if it matches the pattern ^TRACE<br> RewriteCond %{REQUEST_METHOD} ^TRACE<br> #<br> #Match 0 or more of any character, No substitution, return FORBIDDEN (403)<br> RewriteRule<nobr> <wbr></nobr>.* . [F]<br> #<br> #########################<br> <br> (Comments are mine, mod_rewrite directives are from the white paper mentioned above.) cbrooks 2003-01-23T05:06:03+00:00 journal The future of computer programming in the US of A http://use.perl.org/~cbrooks/journal/10118?from=rss <a href="http://digitalmass.boston.com/bottom_nav/scott_kirsner.html">Scott Kirsner</a> is the author of @Large, a weekly tech column for the Boston Globe. In this week's <a href="http://digitalmass.boston.com/news/globe_tech/at_large/2003/0120.html">column </a> he suggests that a substantial portion of the technical and programming jobs currently performed in the United States will be outsourced to India and Russia over the next 15 - 20 years. This would leave mostly management and project management positions here in the states. Good news for those English-speaking progammers abroad, not so good for those of us here.... <br> <br> This cheery news brings to mind a long-standing question that I have: Most of the perl programmers that I know work for someone else. A few work for themselves as consultants / trainers, but I don't know anyone who uses Perl to run a non-technical business for themselves.* I mean, do any techies (for example) start bike shops and then use Perl to automate everything and allow order fulfillment over the web? I have the impression that techies tend not to be entrepreneurs -- is that impression correct? If yes, why? Are the talent sets required for entrepreneurs simply at odds with technical talent sets? <br> <br> * Hmmm. Actually, that's not quite right. I met a guy at YAPC this year whose primary source of income came from a running a skate-boarding website. cbrooks 2003-01-22T13:10:29+00:00 journal Build and Release System, version 0.2.0 http://use.perl.org/~cbrooks/journal/10024?from=rss As mentioned in my <a href="http://use.perl.org/~cbrooks/journal/9848">previous</a> journal entry, I am developing a build and release system for use at work. I had two goals for the first stage: (1) to develop and document a version numbering system; and (2) to publish the current stable version in the script that we use to report tech stats. This journal entry relates some of the issues that I ran into while implementing this first step.<br> <br> <strong>Motivation</strong> <br> Before diving into the details, you might well ask why developing a version numbering system is an interesting enough (or difficult enough) task to justify more than 10 minutes of thought (let alone a journal entry). Why not simply place the site under CVS, and track versions using CVS version numbers? In fact what does it mean to have a single number that represents a website's "version" at all?<br> <br> The most useful analogy is probably the concept of a Linux distribution. If you think about RedHat Linux version 7.3, for example, it contains thousands of files. Although each of those files maintains an internal version, the end user (the sysadmin) one rarely cares about the version of the individual files. (They certainly care if their OS has a journaling filesystem, and they care if it incorporates a version of ssh that has the latest patches applied, but who wants to be bothered with tracking the individual versions of the thousands of files that live underneath<nobr> <wbr></nobr>/?). RedHat can talk about "Sunsetting version 7.0", managers can talk about upgrading to version 8 when it stabilizes: the distribution number is an important shorthand to summarize the versions of thousands of individual files. Aside from a means to summarize the state of many files, a version number can provide hints or clues to its users. Many programmers, for example, discourage production use of their code until it achieves a 1.0 release. (For example, they may not guarantee that an API will be stable before 1.0.) Furthermore, Perl (and many other open source projects), declares that odd-numbered minor releases are development versions, while even-numbered minor releases are production-worthy. Finally, a number that summarizes the overall state of a website's code can link to a CVS tag so that you can automate the checkout of a particular version of each of your CVS projects. All in all, applying a thoughtful and consistent version numbering system allows you to summarize a great deal of information in a very concise manner.<br> <br> <strong>Design</strong> <br> So, enough introduction, what issues did I run into during design? The first issue was simply to choose a set of rules for how and when a version could increment. The version is the concatenation of three integers: one representing the major version, one the minor version, and one the release. The version string is generated by concatenating major.minor.release. The initial version, for example, is 0.0.0. The major version number is incremented to indicate the release of major new features and enhancements. The minor version number is incremented to indicate minor features and enhancements, and the release is incremented to indicate bug fixes. Major and release version numbers begin at 0 and increment by 1. The minor version level begins at 0, but an even minor version indicates a stable production release, while an odd minor version indicates a development release. So, it is perfectly reasonable to say "I am developing a feature for 2.3", and anyone hearing that statement would understand that the feature is intended for the production version 2.4. Each version number can increment past 9 (for example, 2.6.22 is a valid version).<br> <br> The second issue was whether to incorporate the concept of a build. Builds are typically used with compiled languages since compiling the source code into a binary can take a non-trivial amount of time. Since we do not distribute our perl code in binary form, the build process is not strictly necessary. However, there are a number of other concepts associated with a "build" that make its inclusion quite handy. For example, smoke tests ensure that the codebase as a whole continues to compile as developers check in new code. This integrates nicely with the goal of running all of the unit and regression tests on a nightly basis. Another goal for this system is to package the entire codebase into a single file on a nightly basis, for ease of compression, distribution and release. So some of the original meaning of the "build" is retained. All in all, recording the status of the nightly build seems like a good idea.<br> <br> So, if the build is recorded in addition to the version, how are the two numbers related? Although I am not entirely settled on this issue, I have decided that the build number will be closely tied to the release version. That is, every time the release version increments (say from 1.4.5 to 1.4.6), the build will re-set to 0. Along with recording the build number, the nightly build will also record whether or not the smoke tests were run, and whether or not they all passed.<br> <br> <strong>Implementation</strong> <br> The final issue was simply defining the interface to set and retrieve the version. I decided on a simple OO class with a few straight-forward methods:<br> <br> my $ver = new Company::Version;<br> <br> $ver-&gt;set_version( '2.0.4' ); #returns old version<br> $ver-&gt;increment_build #returns old build<br> <br> print $ver-&gt;get_version; #prints 2.0.4<br> print $ver-&gt;get_major; #prints 2<br> print $ver-&gt;get_minor; #prints 0<br> print $ver-&gt;get_release; #prints 4<br> print $ver-&gt;get_build; #prints, for example, 43.<br> print $ver-&gt;get_qa_tested; #prints 'Y' || 'N'<br> print $ver-&gt;get_qa_passed; #prints 'Y' || 'N'<br> print $ver-&gt;get_increment_date( '1.2.0' ); #prints 10/15/2001, for example<br> <br> The class is simply a wrapper around a database table. Each build (and its associated version numbers) is a row in that table. The get_version() method simply returns the most recent row that has an even minor release version. This means that rollbacks will require deleting the latest row, but it makes for a straightforward implementation, and doesn't introduce any awkward corner cases. There are other methods that will need to be implemented at some point, for example, to connect a particular version to a CVS tag, to delete versions, to increment the major, minor and release versions, to rollback to a previous version, etc. However, this was enough functionality to consider the first iteration of the Version class complete.<br> <br> Anyway, if you made it this far, thanks for reading. Version 0.4.0 integrates nightly smoke testing. I would appreciate any feedback. cbrooks 2003-01-16T22:09:00+00:00 journal Implementing a Build and Release System http://use.perl.org/~cbrooks/journal/9848?from=rss For the better part of the last year, I have intended to implement a build and release system for the company at which I work. I wanted to do this project the "right" way -- i.e. specify the functionality; design the modules, define the interface to CVS, etc. However, I have finally accepted that I will never start this project (much less finish it) if I build it this way.<br> <br> So, In the middle of December, I decided to take a different approach. I decided that the only way I would actually finish the project was to break it into small, incremental steps. I wouldn't have to understand exactly how the entire system works before beginning -- it is enough to build the pieces that I do understand, and gradually fill in the gaps.<br> <br> The project will be successfully completed when the following two criteria are met: <ol> <li>I can copy a stable version of our code base from our staging server to our production server and release it without an interruption in service.</li><li>I can roll-back to the previous stable version without an interruption in service.</li></ol><p> I then defined the following intermediate versions: </p><ol> <li>Version 0.0.0: Current codebase</li><li>Version 0.2.0: Versioning (01/01/03) <ul> <li>I would establish and document a version and build numbering system.</li><li>I would begin logging version changes</li><li>I would report the current production version in our tech_stats.pl script, which is the central dashboard for stats for the Tech Department.</li></ul></li><li>Version 0.4.0: Testing (01/15/03) <ul> <li>Run nightly smoke tests</li><li>Ensure that all tests pass</li><li>I would report the previous night's testing status in the tech_stats.pl script</li></ul></li><li>Version 0.6.0: 95% sync-up between production and staging (02/15/03) <ul> <li>Sync all CPAN modules on staging and production server</li><li>Make sure all application files are the same on the staging server and the production server</li><li>Make sure there are no files that exist on the production server but not the staging server</li></ul></li><li>Version 1.0.0: First automated stable release (03/31/03) <ul> <li>Integrate w/CVS tags using trunk and branches methodology</li><li>Remove deprecated functionality and database tables</li></ul></li></ol><p> I am happy to report that I released version 0.2.0 on 01/03/03, and am proceeding on version 0.4.0.</p> cbrooks 2003-01-08T20:19:59+00:00 journal Bill Joy and the Apocalypse http://use.perl.org/~cbrooks/journal/9529?from=rss I have been following Bill Joy's <a href="http://www.wired.com/wired/archive/8.04/joy.html"> comments</a> on a coming biotech / nanotech / robotics apocolypse for the last year and a half -or so. His premise is that the potential for extreme violence on a global scale is extremely high, due to the democratization of destructive power that these three technologies offer.<br> <br> I have to say, first, that I find his comments disquieting, at a minimum. Essentially, he believes that the only realistic option open to us is to choose not to develop these technologies. What I find interesting, though, is the similarity between these arguments and an older apocalyptic argument presented in The Limits to Growth (1972) and Beyond the Limits (1992). These books draw an analogy between over-population-induced die-offs in other animals and (so they claim) a soon to arrive massive die-off in the human population caused by ever-expanding resource consumption. The weakness in the Limits argument, I think, is that they inadequately model the influence of technology, and ironically, I think Bill Joy makes the same mistake. He (reasonably) points out the immense dangers that these technologies make possible, without pointing out that they also make possible immensely more powerful defenses.<br> <br> So, for example, when he talks about the possibility of very nasty terrorist-engineered viruses which could hone in on weaknesses in the human genome, he doesn't talk about the possibility of white-hat engineered monitors that could scan for, and counter, these viruses in real time. (Norton Anti-Virus personal edition 2025 might have a very different meaning.)<br> <br> I suppose I have to hope that those sorts of developments will happen, because I firmly believe that widespread rejection of these new technologies has a vanishingly small probability of occurring. We do not live under the kinds of economic and political systems that would make that a feasible solution to the dystopia that Joy envisions. cbrooks 2002-12-18T14:43:33+00:00 journal Using XWindows remotely http://use.perl.org/~cbrooks/journal/9411?from=rss As part of my new eternal commute, I have started working a bit from home -- an hour here, an hour there. One of the annoying aspects of this is managing email. If I check company email from home, I either see the same messages twice (once from home and once at work), or I can choose to have the messages deleted from the server as soon as I delete / move them at home. Neither approach is ideal. <br> <br> My new approach is to have a single mail client located at work. I fire up Cygwin on my Windows box at home, invoke ssh, and interact with Mozilla remotely using X Windows. (Actually, I'm fibbing a little. So far, I have a Linux box at work running my mail client, and I'm just shelling in from my Windows / Cygwin box across the office.) But, it's a neat trick, and it will greatly simplify any future work from home. <br> <br> Here are the steps that I took, in case anyone is interested in trying something similar. <ol> <li>Get Linux configured on the box that you are going to run your mail client on. (You could also run Cygwin on top of Windows, I suppose.) Make sure that you can use X on this box, and make sure that you have the latest openssh daemon configured and listening to port 22. I suppose you should also make sure that you can access this box remotely over ssh.</li><li>Install Cygwin on the Windows box that you will use remotely. (Cygwin, BTW, is free as in speech, and free as in beer for most purposes.) The Cygwin installation process is quite straightforward, once you get used to its somewhat non-intuitive interface. You can download the setup program from www.cygwin.com. I chose to install the following packages (which take up about 250 MB of disk space): <ul> <li>All: Default</li><li>Doc:Man and Texinfo</li><li>Editors: ed, mc and vim (because vi is the one true editor, okay, the two true editors, because it uses ed under the hood)</li><li>Net: Openssh and rsync (rsync isn't necessary for this project)</li><li>Text: more, less</li><li>XFree86: pretty much everything. Make sure you have fvwm and base</li></ul></li><li>Follow the instructions at <a href="http://www.shadlen.org/sl/windows/WinXServer.htm">www.shadlen.org</a>. I found these to be pretty good, although the startwin.sh script mentioned was actually in<nobr> <wbr></nobr>/usr/X11R6/bin/startxwin.sh, rather than<nobr> <wbr></nobr>/usr/X22T6/bin/startwin.sh.</li><li>At this point, I was able to shell into the Linux box that would host my mail client. However, when I tried to invoke a utility (such as xclock) that relied on X, I got the following error: "authentication failed - cannot start X server - perhaps you do not have console ownership". I was able to fix that thanks to the following usenet post: <a href="http://archives.neohapsis.com/archives/pam-list/2000-10/0064.html">http://archives.neohapsis.com/archives/pam-list/2000-10/0064.html</a>.</li><li>I made a minor change to my ~/.ssh/config file (on the remote Cygwin box), setting "ForwardX11 yes". (You could also just pass the "-X" option to ssh at the command line.)</li><li>From cygwin, I fire up an xterm, and invoke ssh with the following options: "ssh -n ip_addr mozilla", and lo and behold, Mozilla pops up.</li></ol><p> I have not been able to launch startx successfully (remotely), though I can launch it on the local box directly. I think that my ssh client is configured correctly, which makes me suspect that the problem has something to do with inadequate libraries on the Cygwin box. (For example, if I shell from the local Linux box back to itself, I can run startx successfully.) I believe this suggests that if the remote box had the correct software, the X11-forwarding would work correctly. Does anyone have any brainstorms?</p> cbrooks 2002-12-12T14:12:59+00:00 journal The Future of the Operating System http://use.perl.org/~cbrooks/journal/9309?from=rss I just moved to NH and earned myself an excruciatingly long commute to work (approx 3 hours a day). The upside is that I have a lot of time to listen to books on tape and, most recently, MP3s. If you are in a similar situation, check out technetcast.com -- the site is presented by Dr. Dobb's Journal, and it has lots of (free) technical conference presentations available on MP3. <br> <br> Yesterday, I listened to Richard Rashid, VP of Research at Microsoft give a very interesting <a href="http://www.technetcast.com/tnc_play_stream.html?stream_id=698">presentation </a>on the future of the OS. He argues that the essential concepts of the modern OS: hierarchical file systems and user-initiated execution of programs are artifacts of the computers that we had 30 years ago. Computers today are some 40 million times more powerful, and storage capacity is approaching the point that a person could record and store every conversation that they have from birth to death on a single hard drive. Rashid envisions a shift towards interacting with your OS primarily through google-style query mechanisms, rather than a filesystem. The OS would be smart enough to initiate programs on its own, rather than waiting for user input. Obviously, OSes would have a host of new (or at least dramatically improved) input devices, such as speech recognition and handwriting recognition. Perhaps more dramatically, broad spectrum language parsers would have an increasing role in the background to prioritize and categorize documents, email, spoken conversations, etc., and then react without an explicit request from the user. <br> <br> Anyway, it is a thoughtful talk -- certainly worth a listen. cbrooks 2002-12-06T14:24:09+00:00 journal Perhaps it's time to upgrade my servers.... http://use.perl.org/~cbrooks/journal/9022?from=rss Hmmm. Looks like Red Hat may not support version 6.2 much longer. I noticed because the latest <a href="http://linuxtoday.com/news_story.php3?ltsn=2002-11-17-006-26-SC-KN-RH">Red Hat Advisory</a> does not include information for versions earlier than 7.1. <br> <br> Red Hat's <a href="http://www.redhat.com/apps/support/errata/">Errata</a> page (which lists Security Alerts and Bug Fixes) still claims support for version 6.2, but the stated policy is to support the "two most recent major product releases" -- 7 and 8. <br> <br> I called customer support, and they said that Red Hat Network (the up2date utility) and Errata support for 6.2 will go away "very, very soon". <br> <br> So, if you're running version 6.2, and the possibility of running an OS for which security patches are no longer released scares you, you might want to upgrade. cbrooks 2002-11-19T16:57:56+00:00 journal Stale mirrors in CPAN http://use.perl.org/~cbrooks/journal/8930?from=rss This might be helpful to someone else -- the last few times that I've tried to install modules using CPAN.pm, the installation has hung as LWP tried to retrieve the source files across FTP. It turns out that the problem is with stale CPAN mirrors -- a simple lynx ftp://ftp.insert-your-mirror-here.com showed that over half of the mirrors in my $CPAN::Config-&gt;{ 'urllist' } were not accessible. Once I removed the non-responding URLs, I was able to install modules again. cbrooks 2002-11-13T15:34:22+00:00 journal Best Practices: Software Configuration Management http://use.perl.org/~cbrooks/journal/7751?from=rss Perforce Software has released an interesting <a href="http://www.perforce.com/perforce/bestpractices.html">white paper</a> on "Best Practices" for software configuration management. Since Perforce is in the business of selling SCM software there is a (small) marketing component. But it is an interesting (and quick) read if you are interested in issues of automated releases, source code versioning and nightly builds. <br> <br> One of the points that I found interesting was a possible approach to the "stability" issue that I have mentioned before. (i.e. How do you determine (in an automated fashion) whether or not a particular script is "stable" and ready to be released into production.) The authors recommend different "codelines": <br> <br> <i> <b>Development codeline</b>: interim code changes may be checked in; affected components must be buildable. <b>Release codeline</b>: software must build and pass regression tests before check-in; check-ins limited to bug fixes; no new features or functionality may be checked in; after check-in, branch is frozen until entire QA cycle is completed. <b>Mainline</b>: all components must compile and link, and pass regression tests; completed, tested new features may be checked in.</i> cbrooks 2002-09-16T12:17:21+00:00 journal Perl and Daily Builds http://use.perl.org/~cbrooks/journal/7367?from=rss I've been reading a few articles on integrating daily builds into the software development process:<ul> <li> <a href="http://www.joelonsoftware.com/articles/fog0000000023.html">JoelOnSoftware</a> </li><li> <a href="http://www.construx.com/stevemcc/bp04.htm">Steve McConnell</a> </li><li> <a href="http://freshmeat.net/articles/view/392/">FreshMeat Editorial</a> </li></ul><p> It sounds like many folks see substantial benefits, especially on teams. <br> <br>So, I was wondering what a nightly build process might look like to a team using Perl. <br>Here are a few thoughts: </p><ul> <li>Do a complete checkout from cvs of html pages and scripts</li><li>Run a link checker for static html pages</li><li>Run all unit tests</li><li>Run all regression tests</li><li>Any errors break the build</li><li>tar / gzip everything, and save with a datestamp / build number</li></ul><p> The nightly build then becomes the tool for syncing the staging and production servers, rather than using cvs update to sync the servers. The benefit of this is that you can cvs commit files that are not 100% functional / stable, and not worry that they will be released into production on a nightly update, while still maintaining a record of each night's build and smoke test. <br> <br>Is anyone working on a Perl project and doing nightly builds? Do you find it useful?</p> cbrooks 2002-08-28T15:44:38+00:00 journal The Factory Pattern http://use.perl.org/~cbrooks/journal/6475?from=rss I am trying to find an elegant method of solving the following (recurring) problem: I have a class (Facility.pm) that represents eldercare facilities that is used in the following way: <br> <br>my $facility = new Facility( unique_id, facility_type ); <br>print $facility-&gt;get_name; <br> <br> The constructor for this class can accept either: <ul> <li>a unique id and the type of facility to be instantiated (in which case the constructor knows how to pull the relevant information from a database)</li><li>a hash ref with the data used to instantiate the object</li></ul><p> The class is quite useful when dealing with a single facility, but I would like to make it more useful. Rather than having to know a unique id, or the actual values that will be used by the object, I'd like to be able to pass in (for example) a city and a state, and get an arrayref of Facility objects for every facility in that city and state. <br> <br> Now, I have noticed that the class names for many classes in Java match the pattern &lt;Classname&gt;Factory, and I thought "Aha! I could create a FacilityFactory class, which might have the following usage:" <br> <br> my $factory = new FacilityFactory( <br>&nbsp;&nbsp;&nbsp;&nbsp;facility_type =&gt; 'NursingHome', <br>&nbsp;&nbsp;&nbsp;&nbsp;city =&gt; 'Birmingham', <br>&nbsp;&nbsp;&nbsp;&nbsp;state =&gt; 'AL' <br>); <br> <br>foreach my $facility ( @$factory ) { <br>&nbsp;&nbsp;&nbsp;&nbsp;print $facility-&gt;get_name; <br>} <br> <br>FacilityFactory would know how to translate its parameters into valid SQL, query the database, and return an arrayref of instantiated Facility objects. <br> <br> Well, okay that would work, but then I decided to go see if this was actually consistent with the &lt;Classname&gt;Factory pattern that I have seen used in Java. And wouldn't you know, it isn't. The Factory pattern is used when you can't know until runtime which type of class you need to instantiate. The Factory class encapsulates the logic for selecting one of these child clases, is implemented as an abstract base class. Kind of a different beast than what I was attempting. <br> <br> So here's my question. What is the best way to crack this nut? Here are my options as I see them: </p><ul> <li>Ignore the formal definition of the Factory pattern because hey, this does what I need;</li><li> <i>Essentially</i> ignore the formal definition, rename my class FacilitySet and move on</li><li>Make the Facility class more flexible, so that it represents one or more facilities, rather than just one;</li><li>Punt, and hope that one of you will pick up the ball....</li></ul><p> Thanks for any comments.</p> cbrooks 2002-07-19T12:56:47+00:00 journal Perl jobs http://use.perl.org/~cbrooks/journal/6370?from=rss &lt;disclaimer&gt;I'm not actually looking for a job right now.&lt;/disclaimer&gt; <br> <br> But, why are there so few Perl jobs out there? <br> <br> Here's a stat that might illuminate the point: Sr. Software Engineer finds 103 hits on jobs.boston.com. Sr. software engineer perl returns 3. (Java and C++ return 12 and 11 respectively). Of those Perl positions, two expect Java / C++ as well. The third is actually a technical writer position. <br> <br> Perhaps the lesson is that you have to have solid experience in multiple languages to be marketable today. Perl isn't a bad language to have, as long as you have Java or C++ as well. (For example, 48 positions on jobs.boston.com mention Perl in some context -- but compare that with 130 that mention Java and 89 that mention C++.) cbrooks 2002-07-15T18:48:13+00:00 journal Automating the release of new functionality http://use.perl.org/~cbrooks/journal/6330?from=rss I would like to automate our company's process of releasing new web functionality into production. <br> <br>Here's a brief description of our architecture: <ul> <li>RH Linux</li><li>MySQL database on the back end.</li><li>All HTML and Perl source code is stored in a CVS repository. Images are not stored under CVS.</li><li>Each developer has their own local source tree with an Apache server listening to a high-numbered port.</li><li>We also have a staging server that we use for testing</li><li>We have a separate production server visible to the outside world.</li><li>HTML pages are static files.</li><li>We write mod_perl handlers and cgi scripts that run under Apache::Registry.</li></ul><p> At its simplest, you could imagine a release process scheduled to run every night at 1:00 am that looked something like this: <br>cvs update <br>/usr/local/apache/bin/apachectl stop <br>/usr/local/apache/bin/apachectl start <br> <br> However, this approach is likely to prove unsatisfactory for several reasons: </p><ul> <li>Since images are not stored under CVS, new images might not get loaded when needed.</li><li>Some development involves creating new database tables, altering existing tables, or populating existing configuration tables with new data.</li><li>New modules should be tested before stopping the web server. Should a module fail some of its tests during installation, the update should be rolled back so that the server can start successfully.</li><li>Some files get committed to the repository before they are stable and/or approved. Only stable, approved files should get released.</li><li>A related (but distinct) issue is that stable files should not necessarily be released as soon as they are stable. A simple example of such a case is a (stable) HTML file which includes a link for another HTML file which is not yet ready to be launched.</li></ul><p> Given this description, it is possible to rough out a simple spec for The Release System (TRS): </p><ul> <li>TRS needs to interact with CVS. This will allow releases to be customized by directory hierarchy, CVS module, and / or tag. This will also ensure that master copies will be released, rather than local copies.</li><li>TRS needs to be able to execute simple scripts. This will allow TRS to run tests, execute arbitrary SQL, log results, etc.</li><li>TRS needs to be able to perform a rollback should unit tests fail during release. It should only stop and start the web server if all tests pass.</li><li>TRS needs to interact with some system that knows (1) whether a particular file is stable; and (2) whether a particular file is approved for release.</li><li>TRS should have logging facilities that keep a record of when all changes were made, error messages and warnings that were encountered, etc.</li><li>Although a fully automated and regularly scheduled system is nice, it is not necessary. However, a release should be possible with very little interaction on the part of the system administrator.</li><li>TRS should be able to run the regression testing suite after release.</li></ul><p> A few questions: </p><ul> <li>Who has cracked this nut before?</li><li>Can anyone recommend pointers to good articles that tackle part or all of this?</li><li>make is certainly a candidate for some of the logic -- would anyone recommend a different installation utility?</li><li>Parts of this sound like a Content Management System -- does anyone care to comment on the applicability of Bricolage or a similar open source CMS product?</li><li>CVS does not seem to have as robust a system for tracking stability as I would like -- i.e. you can set tags on groups of files, as in "STABLE-06012002", but you can't flip a bit per file. (Unless you set a tag per file -- which isn't necessarily good since a file might go through various iterations of stability / instability.) Can anyone venture an opinion as to whether the per-file "stable" flag is a good idea or a cluster-f*ck?</li></ul><p> Thanks for any and all help.</p> cbrooks 2002-07-13T22:55:38+00:00 journal Yet Another YAPC entry http://use.perl.org/~cbrooks/journal/6259?from=rss I've been thinking back over the presentations that I saw at YAPC this year. Here are two techincal insights that will stay with me: <br>1. Inline::C isn't really a replacement for XS. It's a replacement for h2xs. <br>2. Two actual uses for closures: memoize (uses closures internally) and strong object encapsulation. <br> <br> And my personal YAPC Awards: <br>1. Best argument for why we need Perl 6: Adam Turoff -- Perl 6 has re-energized the Perl community. <br>2. Rudest YAPC attendee: perhaps I shall refrain from naming names, but STOP INTERUPTING PEOPLE just because they're criticizing the usability of CPAN. <br>3. Coolest hair: easy one. Michael Schwern. <br>4. Best presenter: hmmm. Tie between Dominus (Secrets of the Wizards) and Kevin Lenzo's (the auction). <br>5. Most entertaining session: Lightning talks <br>6. Most eloquent explanation of the power of Perl 6: Allison Randal, if Dr. Seuss were a Perl 6 hacker cbrooks 2002-07-10T18:51:58+00:00 journal Thoughts on YAPC http://use.perl.org/~cbrooks/journal/6158?from=rss This was my first YAPC. Quite an interesting time. What I enjoyed most was putting faces / personalities to names. Larry, Damian, Mark Jason Dominus, Simon, Nat, Schwern, Abigail. The whole bunch. <br> <br> What I don't quite understand, though, is how these people make a living. Or, more to the point, what kind of living can you make it if you get into the high Perl Priesthood? <br> <br> Here's my best guess as to where their income comes from: (And hey, no offense to these folks -- maybe they don't want their incomes discussed. I don't mean it personally, I'm just curious about what the income possibilities are for our most lauded wizards.) <br> <br> Perl Foundation Grants: <ul> <li>Larry, Damian and Dan Sugalski are all on 2002 Perl Foundation grants. Those pay a $60,000 stipend and a $20,000 travel allowance (but they are only 52% funded to date, and I believe Dan and Damian's expire at the end of July.)</li></ul><p> Book Royalties: </p><ul> <li>Larry, Damian and Nat presumably have ongoing royalties from their books.</li><li>Simon has a book out next month (http://www.manning.com/jenness/).</li><li>Mark Jason Dominus seems to be perennially working on a book due out next year some time (http://perl.plover.com/book/).</li></ul><p> Day Jobs: </p><ul> <li>Schwern works as a contractor.</li><li>Nat and mjd work as trainers for the Tom Christianson Perl Consultancy.</li></ul><p> Presentation Fees: </p><ul> <li>Let's see, YAPC-NA offered free conference attendance to presenters. There's a whopping $85 value.</li><li>mjd asks for $25 and a plane ticket to give a talk in any city.</li></ul><p> And I can't seem to figure out what Abigail does. <br> <br> So, is that it? Is that what getting to the top of your profession looks like? Book deals and Perl training? Do you get a 401k with that?</p> cbrooks 2002-07-03T18:21:46+00:00 yapc