From philiph at pobox.com Thu Dec 1 07:52:24 2011 From: philiph at pobox.com (Philip J. Hollenback) Date: Thu, 01 Dec 2011 07:52:24 -0800 Subject: [sf-perl] Starting sysadvent 2011 out with a perl article Message-ID: <1322754744.3792.140661006085997@webmail.messagingengine.com> Here's something I wrote for this year's SysAdvent, about using perl modules to capture process output: http://sysadvent.blogspot.com/2011/12/day-1-dont-bash-your-process-outputs.html P. -- Philip J. Hollenback philiph at pobox.com www.hollenback.net From frimicc at gmail.com Thu Dec 1 10:24:15 2011 From: frimicc at gmail.com (Michael Friedman) Date: Thu, 1 Dec 2011 10:24:15 -0800 Subject: [sf-perl] Starting sysadvent 2011 out with a perl article In-Reply-To: <1322754744.3792.140661006085997@webmail.messagingengine.com> References: <1322754744.3792.140661006085997@webmail.messagingengine.com> Message-ID: That's a great article. I'd never heard of IO::CaptureOutput before, but I have seen the pain of open2() firsthand... Thanks for sharing! -- Mike _________________ Michael Friedman frimicc at gmail.com On Dec 1, 2011, at 7:52 AM, Philip J. Hollenback wrote: > Here's something I wrote for this year's SysAdvent, about using perl > modules to capture process output: > > http://sysadvent.blogspot.com/2011/12/day-1-dont-bash-your-process-outputs.html > > P. > -- > Philip J. Hollenback > philiph at pobox.com > www.hollenback.net > > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm From peter at thoeny.org Thu Dec 1 13:26:01 2011 From: peter at thoeny.org (Peter Thoeny) Date: Thu, 1 Dec 2011 13:26:01 -0800 Subject: [sf-perl] Starting sysadvent 2011 out with a perl article In-Reply-To: References: <1322754744.3792.140661006085997@webmail.messagingengine.com> Message-ID: Good article indeed, thanks Philip! A while back I wrote a blog on how to run a long background process in a web app, where I also cover the IO::CaptureOutput module, http://twiki.org/cgi-bin/view/Blog/BlogEntry201109x2 Cheers, Peter On Dec 1, 2011, at 10:24 AM, Michael Friedman wrote: > That's a great article. I'd never heard of IO::CaptureOutput before, > but I have seen the pain of open2() firsthand... > > Thanks for sharing! > -- Mike > _________________ > Michael Friedman > frimicc at gmail.com > > > > On Dec 1, 2011, at 7:52 AM, Philip J. Hollenback wrote: > >> Here's something I wrote for this year's SysAdvent, about using perl >> modules to capture process output: >> >> http://sysadvent.blogspot.com/2011/12/day-1-dont-bash-your-process-outputs.html >> >> P. >> -- >> Philip J. Hollenback >> philiph at pobox.com >> www.hollenback.net -- * Peter Thoeny Peter[at]Thoeny.org * http://twiki.net - Twiki, Inc. - Enterprise Agility * http://twiki.org - is your team already TWiki enabled? * Knowledge cannot be managed, it can be discovered and shared * This e-mail is: (_) private (_) ask first (x) public From philiph at pobox.com Sat Dec 3 20:35:00 2011 From: philiph at pobox.com (Philip J. Hollenback) Date: Sat, 03 Dec 2011 20:35:00 -0800 Subject: [sf-perl] Starting sysadvent 2011 out with a perl article In-Reply-To: References: <1322754744.3792.140661006085997@webmail.messagingengine.com> Message-ID: <1322973300.600.140661007091969@webmail.messagingengine.com> I love writing blog posts because I feel like I always learn more from the comments. In this case, it appears that Capture::Tiny is even better than IO::CaptureOutput. Others have suggests IPC::Run. I think if I were redoing that article I would probably just use Capture::Tiny for everything. Thanks for the kind words. P. On Thursday, December 01, 2011 1:26 PM, "Peter Thoeny" wrote: > Good article indeed, thanks Philip! > > A while back I wrote a blog on how to run a long background process in > a web app, where I also cover the IO::CaptureOutput module, > http://twiki.org/cgi-bin/view/Blog/BlogEntry201109x2 > > Cheers, > Peter > > > On Dec 1, 2011, at 10:24 AM, Michael Friedman wrote: > > > That's a great article. I'd never heard of IO::CaptureOutput before, > > but I have seen the pain of open2() firsthand... > > > > Thanks for sharing! > > -- Mike > > _________________ > > Michael Friedman > > frimicc at gmail.com > > > > > > > > On Dec 1, 2011, at 7:52 AM, Philip J. Hollenback wrote: > > > >> Here's something I wrote for this year's SysAdvent, about using perl > >> modules to capture process output: > >> > >> http://sysadvent.blogspot.com/2011/12/day-1-dont-bash-your-process-outputs.html > >> > >> P. > >> -- > >> Philip J. Hollenback > >> philiph at pobox.com > >> www.hollenback.net > > -- > * Peter Thoeny Peter[at]Thoeny.org > * http://twiki.net - Twiki, Inc. - Enterprise Agility > * http://twiki.org - is your team already TWiki enabled? > * Knowledge cannot be managed, it can be discovered and shared > * This e-mail is: (_) private (_) ask first (x) public > > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > -- Philip J. Hollenback philiph at pobox.com www.hollenback.net From earl at ruby.org Tue Dec 6 14:28:43 2011 From: earl at ruby.org (Earl Ruby) Date: Tue, 6 Dec 2011 14:28:43 -0800 Subject: [sf-perl] [job] Senior Linux Sys Admin with strong Perl skills Message-ID: The company where I've been working the past 8 years is looking for a Senior Linux Sys Admin with strong Perl skills. We also use Perl for all of our web applications, but this job is more focused on sys admin tasks. If you're looking, or know someone who's looking, here are the details: http://sfbay.craigslist.org/sfc/sad/2737936661.html Senior Linux Sys Admin with strong Perl skills WebCDR.com is a privately-held telecom software company providing operations support services (OSS) to the international wholesale telecom industry. We are looking for a senior linux systems administrator with strong Perl skills for a full-time position in San Francisco. We have 90 servers running OpenSUSE Linux. We have OpenSUSE Linux servers for our custom applications, as well as web, database, firewalls, load-balancing, and other tasks. These systems are automatically built and configured using our custom configuration management tool called "apply-config" written in Perl. About 95% of our in-house tools are written in Perl, the rest are mostly bash scripts. We are looking for someone who can help us keep our systems secure, available, and up to date. We are not the kind of organization that is always fighting fires, and we like to hire excellent people so we can keep it that way. Job Description Maintain the system images on our install/build server. Create/test new versions of OpenSUSE, using our "apply-config" tool to create different classes of servers. Create test harnesses to verify that new servers are running as expected. Troubleshoot and fix problems with our Perl build scripts. Extend our Perl build/configuration scripts to handle new services and software. Primary on-call (pager) duty one week in four (based on staffing levels). Initial work to be performed at our San Francisco offices 5 days/week (M-F) until you get familiar with our systems. After that we are open to telecommuting some days each week if you wish. Must be able to drive to our Santa Clara data center on an as-needed basis. (Typically twice a month or less.) Required Technical Skills 7+ years Linux sys admin experience. Proven troubleshooting skills. Strong Perl and bash skills. Understanding of setting up, configuring, and using: iptables ipsec ipvs Nagios RT Network security tools Mail servers (we use Postfix and CourierIMAP) Xen hypervisor Understanding of CVS and Git version control systems. Experience in a network operations environment. Proven ability to document what you do. Desired Technical Skills Our preferred candidate will have skills in one or more of the following areas, and a desire to learn the rest on the job: Understanding of setting up and configuring ospf, bonding, BGP, managed switches. FreeRADIUS configuration/setup Corosync / Pacemaker HA clustering tools. Telecom/SIP/VoIP knowledge. Cassandra (or similar) NoSQL database installation, setup, and tuning. SAN/fiberchannel setup and configuration. Oracle database installation and setup. Cyclades console server setup. Professional Excellent spoken and written English. This position requires providing written documentation of problems found and actions to take. Highly productive; revenue aware. Ability to accept direction and instruction from management. Ability to track and communicate status of your projects to management on a recurring basis. Personal Highly intelligent, innovative problem-solver. Detail oriented with strong follow-through. Ability to learn new concepts quickly. Happy working solo or in a team. Reliable, trustworthy, honest. Sense of humor a must. We require three professional references from candidates at the preliminary interview. We perform credit and criminal background checks on candidates after the second interview per our corporate security policy. No phone calls or visits without prior invitation. Absolutely no agents or third party inquiries. If you're interested, please reply to this ad via e-mail with your resume and a cover letter introducing yourself. -- Earl Ruby http://earlruby.org/ From jeff at imaginative-software.com Wed Dec 7 12:19:21 2011 From: jeff at imaginative-software.com (Jeffrey Thalhammer) Date: Wed, 7 Dec 2011 12:19:21 -0800 Subject: [sf-perl] [announce] Pinto-0.026 Message-ID: Hi everyone- A few months ago, I was tasked with building a private CPAN for a new client. I had already done this a couple times before using CPAN::Site or CPAN::Mini, but I was never really happy with the results. So this time, I started from scratch. The result is called Pinto, and it is now available on CPAN. Pinto is inspired by CPAN::Mini, CPAN::Mini::Inject, and OrePAN, but adds several interesting features (listed below). So I invite you to kick the tires on Pinto and give me your feedback. Beware that Pinto has a lot of dependencies, and I'm still not sure what the minimum versions should be. So I recommend brewing a fresh perl or using the -L option with cpanm(1) to install Pinto into a clean (and separate) sandbox. Pinto is still alpha code and subject to change in incompatible ways. Thanks for your time. Let me know what you think. -Jeff * Pinto supports several usage patterns: With Pinto, you can create a repository that mirrors all the latest distributions from CPAN. Or you can create a repository with just your own private distributions. Or you can create a repository that has all the distributions required for a particular project. Or you can combine any of the above patterns. * Pinto supports adding and removing distributions in the repository: Pinto gives you the power to precisely tune the contents of your repository. For example, you can add your own locally patched CPAN distribution, and then remove it when the original author releases a fixed version. * Pinto helps you avoid breakage due to upgrades: Pinto lets you pin your repository index to a particular version of a package, so that you can hold that package at the last know working version, while allowing other packages to be upgraded. * Pinto can be integrated with your version control system: Pinto can automatically commit to your version control system whenever the contents of the repository changes. This gives you reproducible and identifiable snapshots of your dependencies, and a mechanism for rollback when things go wrong. * Pinto makes it easier to build several local repositories: Creating new Pinto repositories is easy, and each has its own configuration. So you can have different repositories for each department, or each project, or each version of perl, or each customer, or whatever you want. * Pinto can pull distributions from multiple remote repositories: Pinto can mirror or import distributions from multiple sources, so you can create private (or public) networks of repositories that enable separate teams or individuals to share distributions. * Pinto supports team development: Pinto is suitable for small to medium-sized development teams, where several developers might contribute new distributions at the same time. Pinto ensures that concurrent users don't clobber each other. * Pinto has a robust command line interface: The pinto-admin(1) command line tool has options to control every aspect of your Pinto repository. It is well documented and behaves in a DWIM fashion. * Pinto can be extended: You can extend Pinto by creating Pinto::Action subclasses to perform new operations on your repository, such as extracting documentation from a distribution, or grepping the source code of several distributions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From moseley at hank.org Wed Dec 7 20:57:05 2011 From: moseley at hank.org (Bill Moseley) Date: Thu, 8 Dec 2011 10:42:05 +0545 Subject: [sf-perl] [announce] Pinto-0.026 In-Reply-To: References: Message-ID: 2011/12/8 Jeffrey Thalhammer > Hi everyone- > > A few months ago, I was tasked with building a private CPAN for a new > client. I had already done this a couple times before using CPAN::Site or > CPAN::Mini, but I was never really happy with the results. So this time, I > started from scratch. The result is called Pinto, > and it is now available on CPAN. Pinto is inspired by CPAN::Mini, > CPAN::Mini::Inject, and OrePAN, but adds several interesting features > (listed below). > Good timing. I was just about to post a question asking how people manage their in-house modules. So, I'll take a look at this soon as I have some time. What I'm interested in is how others in an environment that includes a dozen or so developers manage their in-house modules. Most of our developers work on just a few "dev" boxes and currently (mostly) using a shared Perl library. I think either perlbrew or local::lib is the best solution for individual developers, but we also have a number of in-house modules in svn that our apps depend on. It would be very handy to have a local CPAN so that checking out an app and running "make" would bring in in-house dependencies just as if they were on CPAN. Currently, some developers just check-out from svn the in-house module they need and install in local::lib, but mostly they get installed system-wide, which isn't a great approach. Can anyone offer comments on how this is done in your organization? -- Bill Moseley moseley at hank.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From fred at redhotpenguin.com Wed Dec 7 21:09:12 2011 From: fred at redhotpenguin.com (Fred Moyer) Date: Wed, 7 Dec 2011 21:09:12 -0800 Subject: [sf-perl] [meeting] December social Message-ID: The 4th Tuesday of this month is December 20th. Some people will be out of town that week, but who is interested in a December social on the 20th at 7pm? Joe, does CellSpace or NoiseBridge have facilities we could use? If anyone here with a space would be willing to host, that would be great. There's also Quetzal where we got a decent amount of people last time. From rdm at cfcl.com Thu Dec 8 00:18:13 2011 From: rdm at cfcl.com (Rich Morin) Date: Thu, 8 Dec 2011 00:18:13 -0800 Subject: [sf-perl] [meeting] December social In-Reply-To: References: Message-ID: At 9:09 PM -0800 12/7/11, Fred Moyer wrote: > The 4th Tuesday of this month is December 20th. ... How about a Chinese Banquet? Find one of the Grande Dame restaurants and pay them $20 a head to feed us... -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm at cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation From Paul.Makepeace at realprogrammers.com Thu Dec 8 03:27:19 2011 From: Paul.Makepeace at realprogrammers.com (Paul Makepeace) Date: Thu, 8 Dec 2011 11:27:19 +0000 Subject: [sf-perl] [announce] Pinto-0.026 In-Reply-To: References: Message-ID: 2011/12/8 Bill Moseley > Currently, some developers just check-out from svn the in-house module > they need and install in local::lib, but mostly they get installed > system-wide, which isn't a great approach. > One approach I've seen is someone builds a virtual machine with a bunch of perl modules and other bits then leaves that image on a shared disk. There is a tendency for it to diverge but usually it's not that bad, and as a way to get a number of people working right away (esp new hires) is hard to beat. Any non-trivial project is usually more than just perl modules: Apache/lighttpd/etc, database, EC2, redis, etc Puppet is useful but a learning curve. (Nothing to stop combining this with local::lib etc) Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From swartz at pobox.com Thu Dec 8 12:08:54 2011 From: swartz at pobox.com (Jonathan Swartz) Date: Thu, 8 Dec 2011 12:08:54 -0800 Subject: [sf-perl] [announce] Pinto-0.026 In-Reply-To: References: Message-ID: <6F08E599-A932-48F2-A976-B550943A32DE@pobox.com> > > > 2011/12/8 Jeffrey Thalhammer > Hi everyone- > > A few months ago, I was tasked with building a private CPAN for a new client. I had already done this a couple times before using CPAN::Site or CPAN::Mini, but I was never really happy with the results. So this time, I started from scratch. The result is called Pinto, and it is now available on CPAN. Pinto is inspired by CPAN::Mini, CPAN::Mini::Inject, and OrePAN, but adds several interesting features (listed below). > > Good timing. I was just about to post a question asking how people manage their in-house modules. So, I'll take a look at this soon as I have some time. > > What I'm interested in is how others in an environment that includes a dozen or so developers manage their in-house modules. Most of our developers work on just a few "dev" boxes and currently (mostly) using a shared Perl library. I think either perlbrew or local::lib is the best solution for individual developers, but we also have a number of in-house modules in svn that our apps depend on. It would be very handy to have a local CPAN so that checking out an app and running "make" would bring in in-house dependencies just as if they were on CPAN. > > Currently, some developers just check-out from svn the in-house module they need and install in local::lib, but mostly they get installed system-wide, which isn't a great approach. > > Can anyone offer comments on how this is done in your organization? > I like keeping the CPAN install dirs in svn. On each machine we check out these directories into a known location, e.g. /opt/vendor/perl/lib/site_perl. That way when you install a new CPAN module or upgrade an existing one, you just commit the changes and then check out on other machines. Doesn't work as well when you've got different architectures but there are ways around that too. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at imaginative-software.com Thu Dec 8 14:44:09 2011 From: jeff at imaginative-software.com (Jeffrey Thalhammer) Date: Thu, 8 Dec 2011 14:44:09 -0800 Subject: [sf-perl] [announce] Pinto-0.026 In-Reply-To: References: Message-ID: On Dec 7, 2011, at 8:57 PM, Bill Moseley wrote: > Can anyone offer comments on how this is done in your organization? At least one organization that I know of uses Pinto to keep snapshots of CPAN in Subversion. They have a text file that just lists the packages they want to have installed in their site_perl. Then they point cpanm at the Pinto repository (or directly at the snapshots in Subversion) and feed the package list to cpanm. So it looks something like this: $> cpanm --mirror /path/to/pinto/repos --mirror-only < wanted_packages.txt And voila! They can stamp out a new perl environment with precisely the right dependencies each and every time. If someone just wants to make a sandbox environment, they can just use the -L=some/directory option to create the environment in some/directory. Or they could brew a fresh perl and install there (after bootstrapping cpanm). The also publish their in-house distributions to the same Pinto repository, so the environment includes both third-party CPAN packages and their own stuff too. You can also store the "pre-built" modules in Subversion as Jon suggested (I've done that too). But the advantage of using Pinto is that it stores the actual distributions. So you can easily rebuild your dependency stack on a new architecture or with a different perl, and you get a full smoke test each time. In addition, Pinto provides you with tools for upgrading your stack in a controlled manner, so you can handle new packages from the CPAN that aren't compatible with your code. And if you use the built-in VCS capabilities of Pinto, you can rollback when things go wrong. I do like Paul's suggestion of keeping machine images, especially for large systems that require more than just a bunch of Perl modules. But you can still use Pinto to build the Perly bits of those images in a controlled, reproducible fashion. In fact, you could even use the OS packaging system (e.g. debian or rpm) on top of Pinto, to combine Perl modules, web servers, databases, and whatever infrastructure you need. Personally, I strive to make every system reproducible and isolated. I want to be able to stamp out the whole wad at any time with the push of a button. And I want to be able to have as many wads on the machine as I want. For the Perl parts, Pinto gives you the ability to use the CPAN toolchain to assemble modules (including your own) in a reliable and predictable way. -Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From hartzell at alerce.com Fri Dec 9 08:29:03 2011 From: hartzell at alerce.com (George Hartzell) Date: Fri, 9 Dec 2011 08:29:03 -0800 Subject: [sf-perl] [announce] Pinto-0.026 In-Reply-To: References: Message-ID: <20194.14159.8415.649338@gargle.gargle.HOWL> Jeffrey Thalhammer writes: > Hi everyone- > > [...] > So I invite you to kick the tires on Pinto and give me your feedback. > [...] > Thanks for your time. Let me know what you think. Jeff has done *great* work. I'm using the penultimate release Pinto at work and am quite happy. I'm looking forward to the current one. Our PAN lives in a subversion repository. We have a cron job that updates and tags it with fresh CPAN content several times a day. We override broken CPAN modules with our own fixed copies and (eventually) back them out when the CPAN copy gets repaired (e.g. WWW::Mechanize, Alien::SVN, various BioPerl tarballs, etc...). We package our own code using Dist::Zilla (and a local PluginBundle, which gives us a very short dist.ini...) and insert it into the PAN. We have a pair of tasks that install all of our "standard" distributions (one that pulls in various missing/mis-specified dependencies we've identified and one that pulls in what we actually want). These tasks are conveniently built using Dist::Zilla and ...::TaskWeaver, then deposited into the PAN. At regular intervals we tag the PAN and then install our standard set of modules with something like cpanm -L.../5.14.2/2011-12-06 \ --mirror http://foo/the_pan/tags/2011-12-06 --mirror-only \ Task::Our::Perl::Modules::MissingPrereqs Task::Our::Perl::Modules cpanm -L.../5.12.4/2011-12-06 \ --mirror http://foo/the_pan/tags/2011-12-06 --mirror-only \ Task::Our::Perl::Modules::MissingPrereqs Task::Our::Perl::Modules Getting a set of content that works is quite simple, something or other on CPAN always refuses to build or otherwise gives one a headache. But once we have it wrangled and tagged it's easy to recreate the environment. Pinto's a great contribution to the Perl/CPAN ecosystem. g. From hartzell at alerce.com Fri Dec 9 08:44:56 2011 From: hartzell at alerce.com (George Hartzell) Date: Fri, 9 Dec 2011 08:44:56 -0800 Subject: [sf-perl] [announce] Pinto-0.026 In-Reply-To: <20194.14159.8415.649338@gargle.gargle.HOWL> References: <20194.14159.8415.649338@gargle.gargle.HOWL> Message-ID: <20194.15112.380308.599231@gargle.gargle.HOWL> George Hartzell writes: > Jeffrey Thalhammer writes: > > Hi everyone- > > > > [...] > > So I invite you to kick the tires on Pinto and give me your feedback. > > [...] > > Thanks for your time. Let me know what you think. > > Jeff has done *great* work. > > I'm using the penultimate release Pinto at work and am quite happy. > I'm looking forward to the current one. > > Our PAN lives in a subversion repository. [...] > We package our own code using Dist::Zilla (and a local PluginBundle, > which gives us a very short dist.ini...) and insert it into the PAN. > [...] I should have added a bit more to that last sentence: ... and insert it into the PAN as part of our Dist::Zilla release process using a Pinto-aware Dist::Zilla plugin. g. From doom at kzsu.stanford.edu Fri Dec 9 15:03:55 2011 From: doom at kzsu.stanford.edu (Joseph Brenner) Date: Fri, 9 Dec 2011 15:03:55 -0800 Subject: [sf-perl] [meeting] December social In-Reply-To: References: Message-ID: Fred Moyer wrote: > The 4th Tuesday of this month is December 20th. Some people will be > out of town that week, but who is interested in a December social on > the 20th at 7pm? > > Joe, does CellSpace or NoiseBridge have facilities we could use? If > anyone here with a space would be willing to host, that would be > great. There's also Quetzal where we got a decent amount of people > last time. NoiseBridge does their weekly meetings on Tuesday nights, and while the anarchist consensus "decision"-making process is always fascinating to watch, it could be a little crowded for a perl event. We could probably use the upstairs classroom at Cellspace, though down in the mainspace D. Miles (aka "The Godfather of Skate") will be holding his Roller Skating Class, so everyone would need to make sure that their Disco inoculations are up-to-date. I'd say Quetzal or Chinese food, From philiph at pobox.com Sat Dec 10 15:05:44 2011 From: philiph at pobox.com (Philip J. Hollenback) Date: Sat, 10 Dec 2011 15:05:44 -0800 Subject: [sf-perl] lack of perl in config management - problem? Message-ID: <1323558344.24432.140661010035253@webmail.messagingengine.com> Something I'm thinking about - a lot of sysadmins these days are becoming programmers via their need to use config management. The two big config management tools are Chef and Puppet. Both are ruby-based. So you have lots of people coming to scripting for the first time, and they are using ruby. Is that a problem? Does this mean that a generation of sysadmins is coming of age _not_ using perl? I don't have any firm data on this, but it's my sense that a lack of config management tools based in perl is actively hurting the perl community. Oh and yes, I'm aware of Slaughter, but I don't think it is enough of a major player to count. Also, it's not very actively maintained. Anyway, what do people think about this issue? Has anyone analyzed it? Final question: perl is such a wonderful glue language - why isn't there a major config management tool based in perl? I'm hoping I'm wrong about all of this of course. P. -- Philip J. Hollenback philiph at pobox.com www.hollenback.net From rdm at cfcl.com Sat Dec 10 15:44:17 2011 From: rdm at cfcl.com (Rich Morin) Date: Sat, 10 Dec 2011 15:44:17 -0800 Subject: [sf-perl] lack of perl in config management - problem? In-Reply-To: <1323558344.24432.140661010035253@webmail.messagingengine.com> References: <1323558344.24432.140661010035253@webmail.messagingengine.com> Message-ID: At 3:05 PM -0800 12/10/11, Philip J. Hollenback wrote: > Something I'm thinking about - a lot of sysadmins these > days are becoming programmers via their need to use > config management. The two big config management tools > are Chef and Puppet. Both are ruby-based. > > So you have lots of people coming to scripting for the > first time, and they are using ruby. ... FWIW, the Ruby web development (eg, Rails) community tends to feel that developers are responsible for the full stack, including configuration management. I'm not sure how many Ruby web shops actually _have_ sysadmins, per se. One question I'd have is whether Perl is as facile as Ruby at the kinds of metaprogramming and internal DSL creation that (say) Chef uses). If not, the result of a Perl rework might not be very pretty. Some of this stuff might make good fodder for a meeting... -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm at cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation From philiph at pobox.com Sat Dec 10 16:34:49 2011 From: philiph at pobox.com (Philip J. Hollenback) Date: Sat, 10 Dec 2011 16:34:49 -0800 Subject: [sf-perl] lack of perl in config management - problem? In-Reply-To: References: <1323558344.24432.140661010035253@webmail.messagingengine.com> Message-ID: <1323563689.6999.140661010054849@webmail.messagingengine.com> On Sat, Dec 10, 2011, at 03:44 PM, Rich Morin wrote: > One question I'd have is whether Perl is as facile as Ruby at the > kinds of metaprogramming and internal DSL creation that (say) Chef > uses). If not, the result of a Perl rework might not be very pretty. I agree - what is it about ruby that makes it so attractive for config management? I know nothing about ruby at all. And frankly, that's probably becoming a liability. Experience with puppet or chef is quickly becoming a requirement for virtually all sysadmin jobs. P. -- Philip J. Hollenback philiph at pobox.com www.hollenback.net From merlyn at stonehenge.com Sat Dec 10 16:43:26 2011 From: merlyn at stonehenge.com (Randal L. Schwartz) Date: Sat, 10 Dec 2011 16:43:26 -0800 Subject: [sf-perl] lack of perl in config management - problem? In-Reply-To: <1323563689.6999.140661010054849@webmail.messagingengine.com> (Philip J. Hollenback's message of "Sat, 10 Dec 2011 16:34:49 -0800") References: <1323558344.24432.140661010035253@webmail.messagingengine.com> <1323563689.6999.140661010054849@webmail.messagingengine.com> Message-ID: <86vcpoaqfl.fsf@red.stonehenge.com> >>>>> "Philip" == Philip J Hollenback writes: Philip> On Sat, Dec 10, 2011, at 03:44 PM, Rich Morin wrote: >> One question I'd have is whether Perl is as facile as Ruby at the >> kinds of metaprogramming and internal DSL creation that (say) Chef >> uses). If not, the result of a Perl rework might not be very pretty. Philip> I agree - what is it about ruby that makes it so attractive for config Philip> management? I know nothing about ruby at all. The ruby config management grew out of the ruby-on-rails camp. Now that RoR has lost some steam, I imagine the next big config thing won't be ruby. In fact, "salt" looks like it has some steam (remote execution based on zeromq). Too bad it's Python. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion From hartzell at alerce.com Sat Dec 10 16:44:54 2011 From: hartzell at alerce.com (George Hartzell) Date: Sat, 10 Dec 2011 16:44:54 -0800 Subject: [sf-perl] lack of perl in config management - problem? In-Reply-To: References: <1323558344.24432.140661010035253@webmail.messagingengine.com> Message-ID: <20195.64774.991954.440786@gargle.gargle.HOWL> Rich Morin writes: > [...] > One question I'd have is whether Perl is as facile as Ruby > at the kinds of metaprogramming and internal DSL creation > that (say) Chef uses). If not, the result of a Perl rework > might not be very pretty. > > Some of this stuff might make good fodder for a meeting... I'd love to hear more about this. Perl seems to be able to create some pretty strong DSL's (e.g. Moose). What's going on in a Ruby based tool that's so special? Is it something about Ruby or the Ruby community? g. From merlyn at stonehenge.com Sat Dec 10 17:08:34 2011 From: merlyn at stonehenge.com (Randal L. Schwartz) Date: Sat, 10 Dec 2011 17:08:34 -0800 Subject: [sf-perl] lack of perl in config management - problem? In-Reply-To: <1323563689.6999.140661010054849@webmail.messagingengine.com> (Philip J. Hollenback's message of "Sat, 10 Dec 2011 16:34:49 -0800") References: <1323558344.24432.140661010035253@webmail.messagingengine.com> <1323563689.6999.140661010054849@webmail.messagingengine.com> Message-ID: <86r50bc3u5.fsf@red.stonehenge.com> >>>>> "Philip" == Philip J Hollenback writes: Philip> On Sat, Dec 10, 2011, at 03:44 PM, Rich Morin wrote: >> One question I'd have is whether Perl is as facile as Ruby at the >> kinds of metaprogramming and internal DSL creation that (say) Chef >> uses). If not, the result of a Perl rework might not be very pretty. Philip> I agree - what is it about ruby that makes it so attractive for config Philip> management? I know nothing about ruby at all. Also see http://code.ticketmaster.com/index.php?page=spine-getting-started That's a huge config manager written in *Perl*. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion From extasia at extasia.org Sat Dec 10 17:23:20 2011 From: extasia at extasia.org (David Alban) Date: Sat, 10 Dec 2011 17:23:20 -0800 Subject: [sf-perl] [OT] shameless plug Message-ID: but consider buying your tickets from http://stubhub.com/ where 90% of the release engineering tools are written in perl. (i work in the release engineering group). On Sat, Dec 10, 2011 at 5:08 PM, Randal L. Schwartz wrote: > Also see > > ?http://code.ticketmaster.com/index.php?page=spine-getting-started > > That's a huge config manager written in *Perl*. -- Live in a world of your own, but always welcome visitors. *** Rule of law is for the little people. http://www.amazon.com/Liberty-Justice-Some-Equality-Powerful/dp/0805092056 From shantanu at cpan.org Mon Dec 12 01:10:46 2011 From: shantanu at cpan.org (Shantanu Bhadoria) Date: Mon, 12 Dec 2011 17:10:46 +0800 Subject: [sf-perl] There are more !! Message-ID: > Oh and yes, I'm aware of Slaughter, but I don't think it is enough of a > major player to count. Also, it's not very actively maintained. > > Slaughter's not the only one! Here's a list from the wiki I just found : http://en.wikipedia.org/wiki/Comparison_of_open_source_configuration_management_software -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at ActionMessage.com Mon Dec 12 17:35:01 2011 From: james at ActionMessage.com (James Briggs) Date: Mon, 12 Dec 2011 17:35:01 -0800 Subject: [sf-perl] lack of perl in config management - problem? In-Reply-To: <1323558344.24432.140661010035253@webmail.messagingengine.com> References: <1323558344.24432.140661010035253@webmail.messagingengine.com> Message-ID: <20111213013301.M22173@actionmessage.com> > Final question: perl is such a wonderful glue language - why isn't there > a major config management tool based in perl? Hundreds, if not thousands, of system configuration build systems have been written in Perl. Usually they are one-off and not Open Sourced. (I use Perl with Redhat's Anaconda/Kickstart system for building systems for my CentOS servers.) Puppet and Chef happen to be Open Sourced and supported by companies. Traditional sysdmin work with Puppet installed is a hassle actually. Any changes you make on the machine are overwritten by Puppet, so you have to make a Puppet config change and push that out. Fine with web clusters, but annoying with onesie and twosie database or mail servers. Thanks, James Briggs From fred at redhotpenguin.com Wed Dec 14 13:12:14 2011 From: fred at redhotpenguin.com (Fred Moyer) Date: Wed, 14 Dec 2011 13:12:14 -0800 Subject: [sf-perl] [meeting] December social In-Reply-To: References: Message-ID: <9061588EC01B4E1280F96550C930F787@redhotpenguin.com> Let's go for Chinese food. Suggested locations? Rich where did you host the beer and scripting sig? Remember, tomorrow next Tuesday Dec 20 at 7pm! On Friday, December 9, 2011 at 3:03 PM, Joseph Brenner wrote: > Fred Moyer wrote: > > The 4th Tuesday of this month is December 20th. Some people will be > > out of town that week, but who is interested in a December social on > > the 20th at 7pm? > > > > Joe, does CellSpace or NoiseBridge have facilities we could use? If > > anyone here with a space would be willing to host, that would be > > great. There's also Quetzal where we got a decent amount of people > > last time. > > > > NoiseBridge does their weekly meetings on Tuesday nights, and while > the anarchist consensus "decision"-making process is always > fascinating to watch, it could be a little crowded for a perl event. > > We could probably use the upstairs classroom at Cellspace, though down > in the mainspace D. Miles (aka "The Godfather of Skate") will be > holding his Roller Skating Class, so everyone would need to make sure > that their Disco inoculations are up-to-date. > > I'd say Quetzal or Chinese food, > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org (mailto:SanFrancisco-pm at pm.org) > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm From rdm at cfcl.com Wed Dec 14 14:13:49 2011 From: rdm at cfcl.com (Rich Morin) Date: Wed, 14 Dec 2011 14:13:49 -0800 Subject: [sf-perl] [meeting] December social In-Reply-To: <9061588EC01B4E1280F96550C930F787@redhotpenguin.com> References: <9061588EC01B4E1280F96550C930F787@redhotpenguin.com> Message-ID: At 1:12 PM -0800 12/14/11, Fred Moyer wrote: > Let's go for Chinese food. Suggested locations? > Rich where did you host the beer and scripting sig? We used to go to Wild Pepper: http://wildpeppersf.com/ Parking is generally available within a block or two. It's also a short walk from a BART station. It's not a huge place, but if we can make it at 6:30, we should be able to grab or pull together a large table. Late- comers can find seating in the periphery... -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm at cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation From fred at redhotpenguin.com Wed Dec 14 14:23:33 2011 From: fred at redhotpenguin.com (Fred Moyer) Date: Wed, 14 Dec 2011 14:23:33 -0800 Subject: [sf-perl] [meeting] December social In-Reply-To: References: <9061588EC01B4E1280F96550C930F787@redhotpenguin.com> Message-ID: <5B017EA1A4C347C6A2A96AB8EABF1B3B@redhotpenguin.com> On Wednesday, December 14, 2011 at 2:13 PM, Rich Morin wrote: > At 1:12 PM -0800 12/14/11, Fred Moyer wrote: > > Let's go for Chinese food. Suggested locations? > > Rich where did you host the beer and scripting sig? > > > > We used to go to Wild Pepper: > > http://wildpeppersf.com/ > Thanks Rich. Everyone - it is on for next Tuesday December 20th. Official start time 6:30 pm. Meetup link coming soon. > > Parking is generally available within a block or two. > It's also a short walk from a BART station. It's not > a huge place, but if we can make it at 6:30, we should > be able to grab or pull together a large table. Late- > comers can find seating in the periphery... > > -r > -- > http://www.cfcl.com/rdm Rich Morin > http://www.cfcl.com/rdm/resume rdm at cfcl.com (mailto:rdm at cfcl.com) > http://www.cfcl.com/rdm/weblog +1 650-873-7841 > > Software system design, development, and documentation > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org (mailto:SanFrancisco-pm at pm.org) > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm From fred at redhotpenguin.com Wed Dec 14 17:24:31 2011 From: fred at redhotpenguin.com (Fred Moyer) Date: Wed, 14 Dec 2011 17:24:31 -0800 Subject: [sf-perl] [meeting] December social In-Reply-To: <5B017EA1A4C347C6A2A96AB8EABF1B3B@redhotpenguin.com> References: <9061588EC01B4E1280F96550C930F787@redhotpenguin.com> <5B017EA1A4C347C6A2A96AB8EABF1B3B@redhotpenguin.com> Message-ID: <7691E68FE59F4A589006D84083ECBB70@redhotpenguin.com> Ok the meetup link is here - http://www.meetup.com/San-Francisco-Perl-Mongers/events/44505082/ Please RSVP and come eat Chinese Food at Wild Pepper to celebrate a great 2011. Optional pub attendance after dinner to talk about Perl and how we can handle the logistics of hosting an event in the spring which hopefully some of our recent renowned guests will be able to attend. On Wednesday, December 14, 2011 at 2:23 PM, Fred Moyer wrote: > On Wednesday, December 14, 2011 at 2:13 PM, Rich Morin wrote: > > At 1:12 PM -0800 12/14/11, Fred Moyer wrote: > > > Let's go for Chinese food. Suggested locations? > > > Rich where did you host the beer and scripting sig? > > > > > > > > > > > > We used to go to Wild Pepper: > > > > http://wildpeppersf.com/ > Thanks Rich. Everyone - it is on for next Tuesday December 20th. Official start time 6:30 pm. Meetup link coming soon. > > > > > Parking is generally available within a block or two. > > It's also a short walk from a BART station. It's not > > a huge place, but if we can make it at 6:30, we should > > be able to grab or pull together a large table. Late- > > comers can find seating in the periphery... > > > > -r > > -- > > http://www.cfcl.com/rdm Rich Morin > > http://www.cfcl.com/rdm/resume rdm at cfcl.com (mailto:rdm at cfcl.com) > > http://www.cfcl.com/rdm/weblog +1 650-873-7841 > > > > Software system design, development, and documentation > > _______________________________________________ > > SanFrancisco-pm mailing list > > SanFrancisco-pm at pm.org (mailto:SanFrancisco-pm at pm.org) > > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > From moseley at hank.org Thu Dec 15 02:37:34 2011 From: moseley at hank.org (Bill Moseley) Date: Thu, 15 Dec 2011 16:07:34 +0530 Subject: [sf-perl] [announce] Pinto-0.026 In-Reply-To: References: Message-ID: 2011/12/8 Jeffrey Thalhammer > > So I invite you to kick the tires on Pinto and > give me your feedback. Beware that Pinto has a lot of dependencies, and > I'm still not sure what the minimum versions should be. So I recommend > brewing a fresh perl or using the -L option with cpanm(1) to install Pinto > into a clean (and separate) sandbox. Pinto is still alpha code and subject > to change in incompatible ways. > I'm trying to understand the big picture. Any primer or "getting started" docs to help the impatient? Or maybe just a walk-through of typical workflow? How could developers on different machines all access a single "repo" of distributions? My goal at this point is to have a private CPAN-style repo available on our LAN where we can add our in-house modules and run "cpan Our::Module" and have it automatically install from our local repo (or from CPAN, if it lives there). I don't think we want to check out an "installed" Perl lib (say a copy of a local::lib library) due to different architectures. We too often get developers blocked due to some common module dependency issue using shared libs -- I think developers with their own local::lib or even perlbrew is the easiest way for everyone to get along on the same machine. Frankly, I don't think it's that hard to svn checkout the module and install it manually using local::lib, but some our of code has so many in-house dependencies that it's somewhat of a pain to do that if some time has passed since last working on the code. Plus, svn may have the module in an unstable state and not "release" ready. Just running Makefile.PL && make on one of our apps to bringi in all the in-house dependencies would make it much less painful. And make preparing RPMs for a release simpler, too. Thanks, -- Bill Moseley moseley at hank.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From hartzell at alerce.com Thu Dec 15 09:44:56 2011 From: hartzell at alerce.com (George Hartzell) Date: Thu, 15 Dec 2011 09:44:56 -0800 Subject: [sf-perl] [announce] Pinto-0.026 In-Reply-To: References: Message-ID: <20202.12824.9605.990518@gargle.gargle.HOWL> Bill Moseley writes: > 2011/12/8 Jeffrey Thalhammer > > > > > So I invite you to kick the tires on Pinto and > > give me your feedback. Beware that Pinto has a lot of dependencies, and > > I'm still not sure what the minimum versions should be. So I recommend > > brewing a fresh perl or using the -L option with cpanm(1) to install Pinto > > into a clean (and separate) sandbox. Pinto is still alpha code and subject > > to change in incompatible ways. > > > > I'm trying to understand the big picture. Any primer or "getting started" > docs to help the impatient? Or maybe just a walk-through of typical > workflow? How could developers on different machines all access a single > "repo" of distributions? > [...] [I'm still running the previous release of Pinto, 0.24. Some details may not apply to the most recent release] [Ricardo, thought you might enjoy the Dist::Zilla tale] We keep our PAN in subversion, with a copy of the trunk checked out in e.g. /our/PAN/trunk. We update and tag it from CPAN regularly with a cron job: # update the mirror at /our/PAN/trunk.... pinto-admin -r /our/PAN/trunk update \ --force --quiet \ --tag 'http://svnhost/pan/tags/pinto-cpan-updates/%Y%m%d.%H%M%S' We have a pinto server running on a well known host with something like the following command line (note that "repos" is awkwardly named, it is *not* the path in the svn repository but rather the path to a checked out/working-dir copy) running persistently: pinto-server --repos /our/PAN/trunk We can add local distributions (either our stuff or cpan modules we want to override) from a client machine like this: pinto-remote -r http://ourpan.example.com:3000 add \ -m 'commit message goes here' ~/tmp/Acme-Widget-0.018.tar.gz But in reality we usually push things into the pan using the Pinto::Add Dist::Zilla plugin as part of our group's PluginBundle. At notable timepoints "someone" will tag the trunk of the repository and various teams will install from that tag, e.g: http://svnhost/pan/tags/perl-modules/2011-12-06 Given that you have your mirror of CPAN with your local stuff inserted and broken stuff overridden, then cpanm -L/dir/to/install/into \ --mirror http://svnhost/pan/tags/20111215.081019 --mirror-only Acme::Widget will install Acme::Widget and all of it's dependencies (assuming everything is probably listed in various prereqs) into /dir/to/install/into. The icing on the cake is that I have a Task that specifies all of the modules that we want to install in our standard deployment, which we generate using Dist::Zilla and its TaskWeaver, stick into the our PAN using Dist::Zilla and the Pinto::Add plugin, and then deploy from a datestamped tag in the svn repo like this: env ORACLE_USERID='schema/passwd' ORACLE_DSN='dbi:Oracle:biodev1' \ cpanm -L /place/to/install/stuff \ --mirror http://svnhost/pan/tags/perl-modules/2011-12-06 \ --mirror-only \ Task::Our::Perl::Modules::MissingPrereqs Task::Our::Perl::Modules We actually have two Tasks, one that lists various prerequisites that broken CPAN modules don't specify, explicitly listing them in the main task doesn't cut it because the order in which things are installed from a Task seems to be unspecified. Since we let cpanm run tests as it installs things (we expect them to pass and "fix" CPAN modules that are failing) and since we include DBD::Oracle in our standard install we need to set some environment variables that its tests require). Other folk have argued for installing w/out tests. YMMV. From jeff at imaginative-software.com Thu Dec 15 10:56:15 2011 From: jeff at imaginative-software.com (Jeffrey Thalhammer) Date: Thu, 15 Dec 2011 10:56:15 -0800 Subject: [sf-perl] [announce] Pinto-0.026 In-Reply-To: References: Message-ID: <48F1802C-4F33-4CF4-A58E-464419DFDE8A@imaginative-software.com> On Dec 15, 2011, at 2:37 AM, Bill Moseley wrote: > I'm trying to understand the big picture. Any primer or "getting started" docs to help the impatient? Or maybe just a walk-through of typical workflow? Yes, that is on my TODO list. For now, let me give you a quick demonstration (below) > My goal at this point is to have a private CPAN-style repo available on our LAN where we can add our in-house modules and run "cpan Our::Module" and have it automatically install from our local repo (or from CPAN, if it lives there). That is precisely what Pinto is designed to do. Here's what it would look like using a repository on a shared drive: # Create a Pinto repository on some shared storage pinto-admin -r /some/shared/directory create # Put some of our private distributions in the Pinto repository pinto-admin -r /some/shared/directory add My-Stuff-1.2.tar.gz More-My-Stuff-0.03.tar.gz # Install our code from the Pinto repository, falling back to the CPAN for any missing dependencies cpanm --mirror file:///some/shared/directory My::Stuff More::My::Stuff If you don't like the idea of shared storage, then you can use pinto-server and pinto-remote (sold separately) to communicate over HTTP: # Create a Pinto repository on some networked server. ssh myserver pinto-admin -r some/directory create pinto-server -d -r some/directory exit # From another machine, put a private distribution into the remote Pinto repository pinto-remote -r myserver add My-Stuff-1.2.targ.z # Install our code from the remote Pinto repository, falling back to the CPAN for dependencies cpanm --mirror http://myserver:3000 My::Stuff These are probably the simplest ways to use Pinto. But you can do some fairly sophisticated things with too. For example, you can make snapshots of the CPAN, so you get the same set of distributions every time you build. And then you can systematically evolve those snapshots by upgrading some modules while holding other modules constant. Also, you can connect multiple Pinto repositories together and create a network for sharing modules across teams or departments. And Dist::Zilla::Chef is an experimental set of DZ plugins that create a workflow for using Pinto in the development process (similar to Miyagawa's Carton). > I don't think we want to check out an "installed" Perl lib (say a copy of a local::lib library) due to different architectures. We too often get developers blocked due to some common module dependency issue using shared libs -- I think developers with their own local::lib or even perlbrew is the easiest way for everyone to get along on the same machine. local::lib and perlbrew definitely go a long way toward making sandboxes. But installing into them from the CPAN is a risky game. The CPAN is not stable and modules are constantly coming and going, so you may never be able to build the same sandbox twice. Pinto can solve this problem, giving you predictable, reproducible sandboxes. > Frankly, I don't think it's that hard to svn checkout the module and install it manually using local::lib, but some our of code has so many in-house dependencies that it's somewhat of a pain to do that if some time has passed since last working on the code. Plus, svn may have the module in an unstable state and not "release" ready. Just running Makefile.PL && make on one of our apps to bringi in all the in-house dependencies would make it much less painful. And make preparing RPMs for a release simpler, too. Yup -- that is the goal (in essence). -Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlb at cfcl.com Fri Dec 16 09:44:04 2011 From: vlb at cfcl.com (Vicki Brown) Date: Fri, 16 Dec 2011 09:44:04 -0800 Subject: [sf-perl] Seeking new position on the game board of Work Message-ID: <6C0CF12B-7521-4A73-992D-77DCA9F7BB65@cfcl.com> (It looks like this never made it to the list; trying again.) Back in October, Rich Morin posted a note about his friend "Lee" who was looking for a new job. Lee is me. At the time, I was hedging my bets. Unfortunately, just after Thanksgviving, I was told that my "position has been eliminated" (a fancy phrase for "you landed in our team and we don't know what to do with you so we're letting you go"). Now I am looking much more seriously. My passion is to help others to be more productive. My focus is more on solving a problem, not writing a program (although I often write programs to solve problems). For the past 5 years, I've been providing high-end TWiki support -- answering questions, troubleshooting problems, developing TWiki apps -- for anyone at Yahoo! who needed my services. I wasn't a TWiki expert when I joined Yahoo! (although I was a TWIki users) but I became an expert to meet the need. One co-worker told me: "I really don't think TWiki is your thing -? it's something you're good at, but not your most valuable quality. Nor is programming. You solve problems in a way that meets peoples' needs, and work with them to provide tools that enable them to do their work well." Another said: "Vicki is THE go-to person ... for all things TWiki. But her most important contribution is sometimes missed...she's an excellent information architect. She always asks 'what are you trying to accomplish? Who is this for?' This inquiry leads to data tailored to the purpose and audience." My skills and interests lie in the areas of: * Problem solving and troubleshooting. * Information architecture and content management. * Scripting languages (mostly Perl, but also Awk, Make, Shell, TWiki, etc.). I'm reading up on Ruby; it's not all that different from Perl. * Technical writing and editing (eg, copy editing, formatting, organizing, proofreading, word-smithing). * Web weaving (eg, CSS, HTML, JavaScript). * Scientific programming, data filters, knowledge management, and social media. * Code review, code cleanup, and bug hunting. * Writing how-tos and tutorials, organizing documentation, and training. I prefer to work directly for the person or team who needs my services, i.e. developing internal tools vs marketed applications, creating internal documentation vs external publications, etc. I would rather be the sole (or one of a few) programmer supporting a non-programming team, than one of many people working on a large application. If you know of a company that could use someone like me, please let me know! Vicki Brown www.linkedin.com/in/vlbrown http://www.philtres.com/vlb/VLBrown_resume.html http://www.philtres.com/vlb/testimonials.shtml From earl at ruby.org Fri Dec 16 11:18:17 2011 From: earl at ruby.org (Earl Ruby) Date: Fri, 16 Dec 2011 11:18:17 -0800 Subject: [sf-perl] lack of perl in config management - problem? In-Reply-To: <1323558344.24432.140661010035253@webmail.messagingengine.com> References: <1323558344.24432.140661010035253@webmail.messagingengine.com> Message-ID: When my company first started building servers en masse about 8 years ago we knew we needed a configuration management tool and looked at what open source tools were available at that time. At that time none met our needs, so we ended up writing our own, mostly in Perl with some bash. Our goals were: * We wanted to be able to easily integrate new configuration scripts into the framework. * We wanted to be able to stage changes on staging/QA servers and then move them into production. * We wanted a class hierarchy, so that we could assign a server to multiple classes (e.g. "base", "base-sanfrancisco", "apache-server", "admin-tools"). * Each class can override configurations in the parent class, so "apache-server" would build a base Apache server, and "admin-tools" would install web-based administration tools, some of which might override the settings in the apache-server class. * Each host can also have host-specific settings which override the base classes, so if you need to tweak settings on just one host you can. * We wanted to be easily able to tell what configuration had been applied to any host, and to keep all of the configurations in one place. If you want to understand why something is set up in a certain way on a host, it's easy to find the configuration and see what script made which changes. * We wanted to be able to lock down specific versions of an OS, its patch set, CPAN tools, and our own packages, so that every server is built using the exact same versions of all software packages. * We wanted new servers to automatically plug themselves into our Nagios monitoring system. * We wanted to be able to take any server, reboot it, type 'inst-auto' at the boot: prompt, and have it go from bare metal to fully-configured without any additional manual intervention. We built all that, but maintaining it takes time, and it's not our core competency, so we looked at moving to Chef or Puppet. What we found is that neither Chef nor Puppet implements classes the way we have and neither one gives us the one-button build capability that we wanted. Chef scales and scales, but is a huge undertaking to set up and maintain. Puppet runs out of steam somewhere between 100 and 1000 servers, and is difficult to scale beyond that. Our system scales infinitely, and it's dead-simple to set up an understand. We looked at extending Chef or Puppet using the tools we'd written, then realized that what we'd written was actually pretty damn good. We are currently working to strip out the company-specific parts of the framework, clean up the code, and release it as open source. We hope that by doing so that other system engineers can extend it and add capabilities that we would like to have but don't have time to add ourselves. We will probably be doing an initial release in about 3 months. I'd be happy to do a demo for Perl Mongers when it's released. On Sat, Dec 10, 2011 at 3:05 PM, Philip J. Hollenback wrote: > Something I'm thinking about - a lot of sysadmins these days are > becoming programmers via their need to use config management. ?The two > big config management tools are Chef and Puppet. ?Both are ruby-based. > > So you have lots of people coming to scripting for the first time, and > they are using ruby. ?Is that a problem? ?Does this mean that a > generation of sysadmins is coming of age _not_ using perl? > > I don't have any firm data on this, but it's my sense that a lack of > config management tools based in perl is actively hurting the perl > community. > > Oh and yes, I'm aware of Slaughter, but I don't think it is enough of a > major player to count. ?Also, it's not very actively maintained. > > Anyway, what do people think about this issue? ?Has anyone analyzed it? > > Final question: perl is such a wonderful glue language - why isn't there > a major config management tool based in perl? > > I'm hoping I'm wrong about all of this of course. > > P. > -- > Philip J. Hollenback > philiph at pobox.com > www.hollenback.net > > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm -- Earl Ruby http://earlruby.org/ From philiph at pobox.com Fri Dec 16 11:27:11 2011 From: philiph at pobox.com (Philip J. Hollenback) Date: Fri, 16 Dec 2011 11:27:11 -0800 Subject: [sf-perl] lack of perl in config management - problem? In-Reply-To: References: <1323558344.24432.140661010035253@webmail.messagingengine.com> Message-ID: <1324063631.4447.140661012579929@webmail.messagingengine.com> Your ideas are intriguing to me and I wish to subscribe to your newsletter. I look forward to your presentation! P. On Fri, Dec 16, 2011, at 11:18 AM, Earl Ruby wrote: > When my company first started building servers en masse about 8 years > ago we knew we needed a configuration management tool and looked at > what open source tools were available at that time. At that time none > met our needs, so we ended up writing our own, mostly in Perl with > some bash. > > Our goals were: > > * We wanted to be able to easily integrate new configuration scripts > into the framework. > * We wanted to be able to stage changes on staging/QA servers and then > move them into production. > * We wanted a class hierarchy, so that we could assign a server to > multiple classes (e.g. "base", "base-sanfrancisco", "apache-server", > "admin-tools"). > * Each class can override configurations in the parent class, so "apache- > server" would build a base Apache server, and "admin-tools" would > install web-based administration tools, some of which might override > the settings in the apache-server class. > * Each host can also have host-specific settings which override the > base classes, so if you need to tweak settings on just one host > you can. > * We wanted to be easily able to tell what configuration had been > applied to any host, and to keep all of the configurations in one > place. If you want to understand why something is set up in a > certain way on a host, it's easy to find the configuration and see > what script made which changes. > * We wanted to be able to lock down specific versions of an OS, its > patch set, CPAN tools, and our own packages, so that every server is > built using the exact same versions of all software packages. > * We wanted new servers to automatically plug themselves into our > Nagios monitoring system. > * We wanted to be able to take any server, reboot it, type 'inst-auto' > at the boot: prompt, and have it go from bare metal to fully- > configured without any additional manual intervention. > > We built all that, but maintaining it takes time, and it's not our > core competency, so we looked at moving to Chef or Puppet. What we > found is that neither Chef nor Puppet implements classes the way we > have and neither one gives us the one-button build capability that we > wanted. Chef scales and scales, but is a huge undertaking to set up > and maintain. Puppet runs out of steam somewhere between 100 and 1000 > servers, and is difficult to scale beyond that. Our system scales > infinitely, and it's dead-simple to set up an understand. > > We looked at extending Chef or Puppet using the tools we'd written, > then realized that what we'd written was actually pretty damn good. We > are currently working to strip out the company-specific parts of the > framework, clean up the code, and release it as open source. We hope > that by doing so that other system engineers can extend it and add > capabilities that we would like to have but don't have time to add > ourselves. > > We will probably be doing an initial release in about 3 months. I'd be > happy to do a demo for Perl Mongers when it's released. > > > On Sat, Dec 10, 2011 at 3:05 PM, Philip J. Hollenback > wrote: > > Something I'm thinking about - a lot of sysadmins these days are > > becoming programmers via their need to use config management. ?The > > two big config management tools are Chef and Puppet. ?Both are ruby- > > based. > > > > So you have lots of people coming to scripting for the first time, > > and they are using ruby. ?Is that a problem? ?Does this mean that a > > generation of sysadmins is coming of age _not_ using perl? > > > > I don't have any firm data on this, but it's my sense that a lack of > > config management tools based in perl is actively hurting the perl > > community. > > > > Oh and yes, I'm aware of Slaughter, but I don't think it is enough > > of a major player to count. ?Also, it's not very actively > > maintained. > > > > Anyway, what do people think about this issue? ?Has anyone > > analyzed it? > > > > Final question: perl is such a wonderful glue language - why isn't > > there a major config management tool based in perl? > > > > I'm hoping I'm wrong about all of this of course. > > > > P. > > -- > > Philip J. Hollenback philiph at pobox.com www.hollenback.net > > > > _______________________________________________ > > SanFrancisco-pm mailing list SanFrancisco-pm at pm.org > > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > > > > -- > Earl Ruby http://earlruby.org/ > _______________________________________________ > SanFrancisco-pm mailing list SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > -- Philip J. Hollenback philiph at pobox.com www.hollenback.net From james at ActionMessage.com Fri Dec 16 16:29:38 2011 From: james at ActionMessage.com (James Briggs) Date: Fri, 16 Dec 2011 16:29:38 -0800 Subject: [sf-perl] lack of perl in config management - problem? In-Reply-To: References: <1323558344.24432.140661010035253@webmail.messagingengine.com> Message-ID: <20111217001056.M9698@actionmessage.com> For the benefit of those who don't know the high-level difference between this system and Puppet or Chef, the former just builds a server, while the latter both builds a server and maintains/enforces the configuration on the server over time. (ie. almost all of the internal ones "run out of gas" compared to the new public config projects.) If you're using a redhat-flavored system, then most of what is mentioned below can be done with a few lines of Perl added to kickstart/anaconda. (Testing and tweaking it is time-consuming though.) Also, most sysadmins can configure kickstart/anaconda, but Puppet or Chef is more of a Ruby programming project once you get away from the canned recipes (sample scripts.) James Briggs. On Fri, 16 Dec 2011 11:18:17 -0800, Earl Ruby wrote > When my company first started building servers en masse about 8 years > ago we knew we needed a configuration management tool and looked at > what open source tools were available at that time. At that time none > met our needs, so we ended up writing our own, mostly in Perl with > some bash. > > Our goals were: > > * We wanted to be able to easily integrate new configuration scripts > into the framework. > * We wanted to be able to stage changes on staging/QA servers and > then move them into production. * We wanted a class hierarchy, so > that we could assign a server to multiple classes (e.g. "base", > "base-sanfrancisco", "apache-server", "admin-tools"). * Each class > can override configurations in the parent class, so "apache-server" > would build a base Apache server, and "admin-tools" would install > web-based administration tools, some of which might override the > settings in the apache-server class. * Each host can also have host- > specific settings which override the base classes, so if you need to > tweak settings on just one host you can. * We wanted to be easily > able to tell what configuration had been applied to any host, and to > keep all of the configurations in one place. If you want to > understand why something is set up in a certain way on a host, it's > easy to find the configuration and see what script made which > changes. * We wanted to be able to lock down specific versions of an > OS, its patch set, CPAN tools, and our own packages, so that every > server is built using the exact same versions of all software packages. > * We wanted new servers to automatically plug themselves into our > Nagios monitoring system. > * We wanted to be able to take any server, reboot it, type 'inst- > auto' at the boot: prompt, and have it go from bare metal to fully- > configured without any additional manual intervention. > > We built all that, but maintaining it takes time, and it's not our > core competency, so we looked at moving to Chef or Puppet. What we > found is that neither Chef nor Puppet implements classes the way we > have and neither one gives us the one-button build capability that we > wanted. Chef scales and scales, but is a huge undertaking to set up > and maintain. Puppet runs out of steam somewhere between 100 and 1000 > servers, and is difficult to scale beyond that. Our system scales > infinitely, and it's dead-simple to set up an understand. > > We looked at extending Chef or Puppet using the tools we'd written, > then realized that what we'd written was actually pretty damn good. > We are currently working to strip out the company-specific parts of the > framework, clean up the code, and release it as open source. We hope > that by doing so that other system engineers can extend it and add > capabilities that we would like to have but don't have time to add > ourselves. > > We will probably be doing an initial release in about 3 months. I'd > be happy to do a demo for Perl Mongers when it's released. From fred at redhotpenguin.com Fri Dec 16 22:17:58 2011 From: fred at redhotpenguin.com (Fred Moyer) Date: Fri, 16 Dec 2011 22:17:58 -0800 Subject: [sf-perl] [announce] Pinto-0.026 In-Reply-To: References: Message-ID: [late to the discussion] 2011/12/7 Bill Moseley : > 2011/12/8 Jeffrey Thalhammer > > Currently, some developers just check-out from svn the in-house module they > need and install in local::lib, but mostly they get installed system-wide, > which isn't a great approach. > > Can anyone offer comments on how this is done in your organization? I try to develop using a locally installed copy of perl via perlbrew if possible when in a shared development. This has the disadvantage of taking a couple hours to get a full set of needed Perl modules installed, but does return some long term benefits such as being able to install whatever module you want whenever you want without breaking modules that are shared between developers. Where it tends to run up against a wall though is if there is XS or swig code local to the organization. Usually it doesn't compile because that code is developed in a different environment by C developers, and they don't always package it with the neatness of CPAN modules. This also requires you build your own versions of Apache and mod_perl if you develop against a mod_perl based web server. Which can be a hindrance to some developers, even mod_perl maintainers like myself. I'm referring mostly to making sure that perl is compiled with -fPIC through perlbrew, and then compiling against that. However, that detail usually doesn't come to light until you're already built perl without -fPIC. Given my druthers, I use perlbrew and develop locally on my own machine with mod_perl and postgresql built from scratch, but sometimes you work with code where the database is either too unwieldy to setup, or not something anonymized enough that it won't have to be a concern if my laptop is stolen, so you have to connect to a remote database. Pretty happy with that compromise, as you still get the low latency benefits from working in a localhost environment. From earl at ruby.org Sat Dec 17 12:20:53 2011 From: earl at ruby.org (Earl Ruby) Date: Sat, 17 Dec 2011 12:20:53 -0800 Subject: [sf-perl] lack of perl in config management - problem? In-Reply-To: <20111217001056.M9698@actionmessage.com> References: <1323558344.24432.140661010035253@webmail.messagingengine.com> <20111217001056.M9698@actionmessage.com> Message-ID: No, the system I just described ("the former") both builds the system (like kickstarter), does the initial configuration, and maintains the configuration over time. If you're just buying VMs from a cloud host you don't need the build portion, but you do need the initial configuration and maintenance portions. On Fri, Dec 16, 2011 at 4:29 PM, James Briggs wrote: > For the benefit of those who don't know the high-level difference > between this system and Puppet or Chef, the former just builds a server, > while the latter both builds a server and maintains/enforces the > configuration on the server over time. > > (ie. almost all of the internal ones "run out of gas" compared > to the new public config projects.) > > If you're using a redhat-flavored system, then most of what is > mentioned below can be done with a few lines of Perl added to > kickstart/anaconda. (Testing and tweaking it is time-consuming though.) > > Also, most sysadmins can configure kickstart/anaconda, but Puppet or Chef > is more of a Ruby programming project once you get away from the canned > recipes (sample scripts.) > > James Briggs. > > On Fri, 16 Dec 2011 11:18:17 -0800, Earl Ruby wrote >> When my company first started building servers en masse about 8 years >> ago we knew we needed a configuration management tool and looked at >> what open source tools were available at that time. At that time none >> met our needs, so we ended up writing our own, mostly in Perl with >> some bash. >> >> Our goals were: >> >> * We wanted to be able to easily integrate new configuration scripts >> into the framework. >> * We wanted to be able to stage changes on staging/QA servers and >> then move them into production. * We wanted a class hierarchy, so >> that we could assign a server to multiple classes (e.g. "base", >> ?"base-sanfrancisco", "apache-server", "admin-tools"). * Each class >> can override configurations in the parent class, so "apache-server" >> would build a base Apache server, and "admin-tools" would install >> web-based administration tools, some of which might override the >> settings in the apache-server class. * Each host can also have host- >> specific settings which override the base classes, so if you need to >> tweak settings on just one host you can. * We wanted to be easily >> able to tell what configuration had been applied to any host, and to >> keep all of the configurations in one place. If you want to >> understand why something is set up in a certain way on a host, it's >> easy to find the configuration and see what script made which >> changes. * We wanted to be able to lock down specific versions of an >> OS, its patch set, CPAN tools, and our own packages, so that every >> server is built using the exact same versions of all software packages. >> * We wanted new servers to automatically plug themselves into our >> Nagios monitoring system. >> * We wanted to be able to take any server, reboot it, type 'inst- >> auto' at the boot: prompt, and have it go from bare metal to fully- >> configured without any additional manual intervention. >> >> We built all that, but maintaining it takes time, and it's not our >> core competency, so we looked at moving to Chef or Puppet. What we >> found is that neither Chef nor Puppet implements classes the way we >> have and neither one gives us the one-button build capability that we >> wanted. Chef scales and scales, but is a huge undertaking to set up >> and maintain. Puppet runs out of steam somewhere between 100 and 1000 >> servers, and is difficult to scale beyond that. Our system scales >> infinitely, and it's dead-simple to set up an understand. >> >> We looked at extending Chef or Puppet using the tools we'd written, >> then realized that what we'd written was actually pretty damn good. >> We are currently working to strip out the company-specific parts of the >> framework, clean up the code, and release it as open source. We hope >> that by doing so that other system engineers can extend it and add >> capabilities that we would like to have but don't have time to add >> ourselves. >> >> We will probably be doing an initial release in about 3 months. I'd >> be happy to do a demo for Perl Mongers when it's released. > > > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm -- Earl Ruby http://earlruby.org/ From jeff at imaginative-software.com Sat Dec 17 14:35:43 2011 From: jeff at imaginative-software.com (Jeffrey Thalhammer) Date: Sat, 17 Dec 2011 14:35:43 -0800 Subject: [sf-perl] [announce] Pinto-0.026 In-Reply-To: References: Message-ID: <74F4EE37-1AAB-41DA-A707-AA2A45C2B265@imaginative-software.com> On Dec 16, 2011, at 10:17 PM, Fred Moyer wrote: > This has the disadvantage of taking a couple hours to get a full set of needed Perl modules installed, but does return some long term benefits such as being able to install whatever module you want whenever you want without breaking modules that are shared between developers. Carton or Dist::Zilla::Chef can help with that. Both of them will stash all the required CPAN dists _inside_ your project. So all you need to do is checkout the project from the VCS system, fire some carton or dzil commands, and it will build everything into a local::lib sandbox (without going over the network, and without "accidentally" upgrading to the latest version on the CPAN). For example, I have 2 or 3 different versions of perl (via perlbrew) that I can switch between, but I never install any modules in them. Each of my projects has its own private slice of CPAN that installs into its own local::lib. This means I never contaminate my environment for one project with the modules from another project. All is neat, clean, and reproducible. -Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at imaginative-software.com Sat Dec 17 17:57:23 2011 From: jeff at imaginative-software.com (Jeffrey Thalhammer) Date: Sat, 17 Dec 2011 17:57:23 -0800 Subject: [sf-perl] Presentation Suggestions Message-ID: <80D45E2B-543E-4BE7-B61E-DF3A3D000601@imaginative-software.com> Hi everyone- I'm working on a technical presentation that involves looking at a lot of directory structures. Some techniques I've used in the past are: Screenshots of Finder (I use a Mac). Screenshots of "ls" commands in a terminal. Both of these are adequate, but not very exciting. And I think it is hard to convey the relationship between directories as you move from one directory to another. Have you seen or used any other techniques that you like? -Jeff From james at ActionMessage.com Sun Dec 18 00:32:45 2011 From: james at ActionMessage.com (James Briggs) Date: Sun, 18 Dec 2011 00:32:45 -0800 Subject: [sf-perl] lack of perl in config management - all singing, all dancing In-Reply-To: References: <1323558344.24432.140661010035253@webmail.messagingengine.com> <20111217001056.M9698@actionmessage.com> Message-ID: <20111218082748.M89147@actionmessage.com> Hi Earl. Then that's very cool and welcome indeed. I'd consider testing it in my environment and providing feedback. (For organizations that already heavily use Perl, it would be great to skip Ruby and reduce the language dependency count by one.) Thanks, James. On Sat, 17 Dec 2011 12:20:53 -0800, Earl Ruby wrote > No, the system I just described ("the former") both builds the system > (like kickstarter), does the initial configuration, and maintains the > configuration over time. > > If you're just buying VMs from a cloud host you don't need the build > portion, but you do need the initial configuration and maintenance > portions. > > On Fri, Dec 16, 2011 at 4:29 PM, James Briggs > wrote: > > For the benefit of those who don't know the high-level difference > > between this system and Puppet or Chef, the former just builds a server, > > while the latter both builds a server and maintains/enforces the > > configuration on the server over time. > > > > (ie. almost all of the internal ones "run out of gas" compared > > to the new public config projects.) > > > > If you're using a redhat-flavored system, then most of what is > > mentioned below can be done with a few lines of Perl added to > > kickstart/anaconda. (Testing and tweaking it is time-consuming though.) > > > > Also, most sysadmins can configure kickstart/anaconda, but Puppet or Chef > > is more of a Ruby programming project once you get away from the canned > > recipes (sample scripts.) > > > > James Briggs. > > > > On Fri, 16 Dec 2011 11:18:17 -0800, Earl Ruby wrote > >> When my company first started building servers en masse about 8 years > >> ago we knew we needed a configuration management tool and looked at > >> what open source tools were available at that time. At that time none > >> met our needs, so we ended up writing our own, mostly in Perl with > >> some bash. [ ... ] From ddascalescu at gmail.com Mon Dec 19 16:55:20 2011 From: ddascalescu at gmail.com (Dan Dascalescu) Date: Mon, 19 Dec 2011 16:55:20 -0800 Subject: [sf-perl] Presentation Suggestions In-Reply-To: <80D45E2B-543E-4BE7-B61E-DF3A3D000601@imaginative-software.com> References: <80D45E2B-543E-4BE7-B61E-DF3A3D000601@imaginative-software.com> Message-ID: Live demo, with as much as possible offline, and rehearsed 10 times. Dan -- CIO, Blueseed Visa-free offshore startup incubator On Sat, Dec 17, 2011 at 17:57, Jeffrey Thalhammer < jeff at imaginative-software.com> wrote: > Hi everyone- > > I'm working on a technical presentation that involves looking at a lot of > directory structures. Some techniques I've used in the past are: > > Screenshots of Finder (I use a Mac). > Screenshots of "ls" commands in a terminal. > > Both of these are adequate, but not very exciting. And I think it is hard > to convey the relationship between directories as you move from one > directory to another. > > Have you seen or used any other techniques that you like? > > -Jeff > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > -- Dan Dascalescu Founder, The Quantified Self Forum Ambassador, The Seasteading Institute -------------- next part -------------- An HTML attachment was scrubbed... URL: From fred at redhotpenguin.com Mon Dec 19 17:03:57 2011 From: fred at redhotpenguin.com (Fred Moyer) Date: Mon, 19 Dec 2011 17:03:57 -0800 Subject: [sf-perl] Fw: [meeting] December social In-Reply-To: <7691E68FE59F4A589006D84083ECBB70@redhotpenguin.com> References: <9061588EC01B4E1280F96550C930F787@redhotpenguin.com> <5B017EA1A4C347C6A2A96AB8EABF1B3B@redhotpenguin.com> <7691E68FE59F4A589006D84083ECBB70@redhotpenguin.com> Message-ID: Reminder, the December Social is tomorrow at 6:30: http://www.meetup.com/San-Francisco-Perl-Mongers/events/44505082/ Forwarded message: > From: Fred Moyer > To: Rich Morin > Cc: sanfrancisco-pm at pm.org > Date: Wednesday, December 14, 2011 5:24:31 PM > Subject: Re: [sf-perl] [meeting] December social > > Ok the meetup link is here - http://www.meetup.com/San-Francisco-Perl-Mongers/events/44505082/ > > Please RSVP and come eat Chinese Food at Wild Pepper to celebrate a great 2011. > > Optional pub attendance after dinner to talk about Perl and how we can handle the logistics of hosting an event in the spring which hopefully some of our recent renowned guests will be able to attend. > > > On Wednesday, December 14, 2011 at 2:23 PM, Fred Moyer wrote: > > > On Wednesday, December 14, 2011 at 2:13 PM, Rich Morin wrote: > > > At 1:12 PM -0800 12/14/11, Fred Moyer wrote: > > > > Let's go for Chinese food. Suggested locations? > > > > Rich where did you host the beer and scripting sig? > > > > > > > > > > > > > > > > > > > > > > > > We used to go to Wild Pepper: > > > > > > http://wildpeppersf.com/ > > Thanks Rich. Everyone - it is on for next Tuesday December 20th. Official start time 6:30 pm. Meetup link coming soon. > > > > > > > > Parking is generally available within a block or two. > > > It's also a short walk from a BART station. It's not > > > a huge place, but if we can make it at 6:30, we should > > > be able to grab or pull together a large table. Late- > > > comers can find seating in the periphery... > > > > > > -r > > > -- > > > http://www.cfcl.com/rdm Rich Morin > > > http://www.cfcl.com/rdm/resume rdm at cfcl.com (mailto:rdm at cfcl.com) > > > http://www.cfcl.com/rdm/weblog +1 650-873-7841 > > > > > > Software system design, development, and documentation > > > _______________________________________________ > > > SanFrancisco-pm mailing list > > > SanFrancisco-pm at pm.org (mailto:SanFrancisco-pm at pm.org) > > > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > > > > From quinn at pgexperts.com Tue Dec 20 00:25:18 2011 From: quinn at pgexperts.com (Quinn Weaver) Date: Tue, 20 Dec 2011 00:25:18 -0800 Subject: [sf-perl] Presentation Suggestions In-Reply-To: <80D45E2B-543E-4BE7-B61E-DF3A3D000601@imaginative-software.com> References: <80D45E2B-543E-4BE7-B61E-DF3A3D000601@imaginative-software.com> Message-ID: <0A2D5F0E-59FE-43DB-9C29-89683B5BF1CD@pgexperts.com> On Dec 17, 2011, at 5:57 PM, Jeffrey Thalhammer wrote: > Hi everyone- > > I'm working on a technical presentation that involves looking at a lot of directory structures. Some techniques I've used in the past are: > > Screenshots of Finder (I use a Mac). > Screenshots of "ls" commands in a terminal. > > Both of these are adequate, but not very exciting. And I think it is hard to convey the relationship between directories as you move from one directory to another. > > Have you seen or used any other techniques that you like? On Sat, Dec 17, 2011 at 5:57 PM, Jeffrey Thalhammer wrote: > Hi everyone- > > I'm working on a technical presentation that involves looking at a lot of directory structures. Some techniques I've used in the past are: > > Screenshots of Finder (I use a Mac). > Screenshots of "ls" commands in a terminal. Maybe I'm an outlier, but I really like the output of find(1), for hierarchical directory structures with mangeable numbers of files. In my interactive shell use, I tend to do 'find .' instead of 'ls -lr'. > And I think it is hard to convey the relationship between directories as you move from one directory to another. You can put the full path in your bash prompt: export PS1="\w\\$ " I do this in my prompt (along with some other info). If you do this, it's helpful to use ANSI color codes to make your prompt visually distinct from command output. But Terminal.app's ANSI support is broken, so, if you're on a Mac, you have to go to the trouble of downloading and configuring something else. I use iTerm2, which works great. Here's an example. It's the same prompt as above, in a sort of cobalt blue. As you might guess, the part before the "\w\$ " is ANSIese for "be blue now" and the part after it is ANSIese for "stop being blue." export PS1="\[\e[34;m\]\w\$ \[\e[0m\] -- Quinn Weaver PostgreSQL Experts, Inc. http://pgexperts.com/ 1-888-743-9778 (my extension: 510) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at imaginative-software.com Tue Dec 20 09:10:40 2011 From: jeff at imaginative-software.com (Jeffrey Thalhammer) Date: Tue, 20 Dec 2011 09:10:40 -0800 Subject: [sf-perl] Presentation Suggestions In-Reply-To: <0A2D5F0E-59FE-43DB-9C29-89683B5BF1CD@pgexperts.com> References: <80D45E2B-543E-4BE7-B61E-DF3A3D000601@imaginative-software.com> <0A2D5F0E-59FE-43DB-9C29-89683B5BF1CD@pgexperts.com> Message-ID: On Dec 20, 2011, at 12:25 AM, Quinn Weaver wrote: > I do this in my prompt (along with some other info). > > If you do this, it's helpful to use ANSI color codes to make your prompt visually distinct from command output. But Terminal.app's ANSI support is broken, so, if you're on a Mac, you have to go to the trouble of downloading and configuring something else. I use iTerm2, which works great. > > Here's an example. It's the same prompt as above, in a sort of cobalt blue. As you might guess, the part before the "\w\$ " is ANSIese for "be blue now" and the part after it is ANSIese for "stop being blue." Thanks for the suggestions for enhancing the prompt. Those are good ideas. I also discovered tree(1): http://shaunchapmanblog.com/post/329270449/how-to-install-the-tree-command-on-mac-os-x `tree -CA some/directory` makes a pretty decent color-coded ASCII-art representation of a directory. I think I'll try using this for the presentation. -Jeff From Paul.Makepeace at realprogrammers.com Wed Dec 21 05:41:51 2011 From: Paul.Makepeace at realprogrammers.com (Paul Makepeace) Date: Wed, 21 Dec 2011 13:41:51 +0000 Subject: [sf-perl] Presentation Suggestions In-Reply-To: References: <80D45E2B-543E-4BE7-B61E-DF3A3D000601@imaginative-software.com> <0A2D5F0E-59FE-43DB-9C29-89683B5BF1CD@pgexperts.com> Message-ID: On Tue, Dec 20, 2011 at 17:10, Jeffrey Thalhammer wrote: > `tree -CA some/directory` makes a pretty decent color-coded ASCII-art representation of a directory. ?I think I'll try using this for the presentation. What do you like about `tree` over Finder screenshots? The latter you can color with labels which could help narrate movement around it There are several handy key shortcuts in OS X for very quickly taking screenshots leaving them on the Desktop, e.g. Shift-Cmd-4 (Sys Prefs -> Keyboard -> Keyboard shortcuts) Paul From jeff at imaginative-software.com Wed Dec 21 10:34:31 2011 From: jeff at imaginative-software.com (Jeffrey Thalhammer) Date: Wed, 21 Dec 2011 10:34:31 -0800 Subject: [sf-perl] Presentation Suggestions In-Reply-To: References: <80D45E2B-543E-4BE7-B61E-DF3A3D000601@imaginative-software.com> <0A2D5F0E-59FE-43DB-9C29-89683B5BF1CD@pgexperts.com> Message-ID: <9DF09DB4-5469-48B4-9B68-AAD6EBDB84E3@imaginative-software.com> On Dec 21, 2011, at 5:41 AM, Paul Makepeace wrote: > What do you like about `tree` over Finder screenshots? The latter you > can color with labels which could help narrate movement around it The Finder screenshots are generally ok -- just looking for fresh ideas. The labels are a good suggestion (I don't normally use those). The general flow of the presentation is... [type command] -> [look at output on console] -> [view resulting directory structure] And that sequence of slides is repeated several times. I think `tree` fits nicely into the console-oriented theme. But I'm not committed to it yet. > There are several handy key shortcuts in OS X for very quickly taking > screenshots leaving them on the Desktop, e.g. Shift-Cmd-4 (Sys Prefs > -> Keyboard -> Keyboard shortcuts) That reminds me, I also want to record console sessions as movies and play them back in the presentation. I'm sure there is a shortcut key for that too. Or can anyone recommend a screencast capturing tool that they like (I see lots of them on Google). -Jeff From Paul.Makepeace at realprogrammers.com Wed Dec 21 10:39:34 2011 From: Paul.Makepeace at realprogrammers.com (Paul Makepeace) Date: Wed, 21 Dec 2011 18:39:34 +0000 Subject: [sf-perl] Presentation Suggestions In-Reply-To: <9DF09DB4-5469-48B4-9B68-AAD6EBDB84E3@imaginative-software.com> References: <80D45E2B-543E-4BE7-B61E-DF3A3D000601@imaginative-software.com> <0A2D5F0E-59FE-43DB-9C29-89683B5BF1CD@pgexperts.com> <9DF09DB4-5469-48B4-9B68-AAD6EBDB84E3@imaginative-software.com> Message-ID: On Wed, Dec 21, 2011 at 18:34, Jeffrey Thalhammer wrote: > That reminds me, I also want to record console sessions as movies and play them back in the presentation. ?I'm sure there is a shortcut key for that too. Quicktime Player (oddly enough) -> New screen recording. Quite decent > Or can anyone recommend a screencast capturing tool that they like (I see lots of them on Google). Camtasia is great if a bit pricey. Once you have that you probably won't want anything else though. Paul From garth.webb at gmail.com Wed Dec 21 10:40:45 2011 From: garth.webb at gmail.com (Garth Webb) Date: Wed, 21 Dec 2011 10:40:45 -0800 Subject: [sf-perl] Presentation Suggestions In-Reply-To: <9DF09DB4-5469-48B4-9B68-AAD6EBDB84E3@imaginative-software.com> References: <80D45E2B-543E-4BE7-B61E-DF3A3D000601@imaginative-software.com> <0A2D5F0E-59FE-43DB-9C29-89683B5BF1CD@pgexperts.com> <9DF09DB4-5469-48B4-9B68-AAD6EBDB84E3@imaginative-software.com> Message-ID: For screen capture / video, I'd recommend Jing: http://www.techsmith.com/jing.html?gclid=CNSvv8nnk60CFRBphwodhgu2oA Its free, works on Mac and Windows and the images/videos can be loaded directly to their site returning you a URL you can paste into IM / email, etc. Garth On Wed, Dec 21, 2011 at 10:34 AM, Jeffrey Thalhammer < jeff at imaginative-software.com> wrote: > > On Dec 21, 2011, at 5:41 AM, Paul Makepeace wrote: > > > What do you like about `tree` over Finder screenshots? The latter you > > can color with labels which could help narrate movement around it > > The Finder screenshots are generally ok -- just looking for fresh ideas. > The labels are a good suggestion (I don't normally use those). > > The general flow of the presentation is... > > [type command] -> [look at output on console] -> [view resulting > directory structure] > > And that sequence of slides is repeated several times. I think `tree` > fits nicely into the console-oriented theme. But I'm not committed to it > yet. > > > There are several handy key shortcuts in OS X for very quickly taking > > screenshots leaving them on the Desktop, e.g. Shift-Cmd-4 (Sys Prefs > > -> Keyboard -> Keyboard shortcuts) > > That reminds me, I also want to record console sessions as movies and play > them back in the presentation. I'm sure there is a shortcut key for that > too. > > Or can anyone recommend a screencast capturing tool that they like (I see > lots of them on Google). > > -Jeff > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doom at kzsu.stanford.edu Wed Dec 21 12:26:41 2011 From: doom at kzsu.stanford.edu (Joseph Brenner) Date: Wed, 21 Dec 2011 12:26:41 -0800 Subject: [sf-perl] Presentation Suggestions In-Reply-To: References: <80D45E2B-543E-4BE7-B61E-DF3A3D000601@imaginative-software.com> <0A2D5F0E-59FE-43DB-9C29-89683B5BF1CD@pgexperts.com> Message-ID: Jeffrey Thalhammer wrote: > `tree -CA some/directory` makes a pretty decent color-coded ASCII-art representation of a directory. ?I think I'll try using this for the presentation. tree seems pretty good (there's an ubuntu package for it, by the way), though it's too bad you need to manually craft strategies to ignore uninteresting files: tree -I '*~|*,v|#*|RCS' "ack -f " or "ack -af" does things like that by default, though doesn't (yet) have a way of pretty-printing directory tree output. Myself, I'm inclined to take "find" output and massage it into an ascii art diagram using emacs picture-mode. And ascii art can be embedded in html using perpetually underused
 tags.

(There's no difficulty with doing screen captures, right?  Unix/X
Windows style is to just use the oddly named "import" command, e.g.
"import this_window.png" plus a click on the window.)

(And now I'm thinking about what the right way would be to convert a
directory listing to a graphviz diagram...
Hint: GraphViz.pm or even GraphViz2.pm probably aren't the right way to do it.)

From rdm at cfcl.com  Wed Dec 21 13:06:04 2011
From: rdm at cfcl.com (Rich Morin)
Date: Wed, 21 Dec 2011 13:06:04 -0800
Subject: [sf-perl] FYI/OT - revolights
Message-ID: 

At least three of the folks at last night's feed are
seriously into bicycling.  Here's something cool to
add to your bike at some point...

-r


http://www.kickstarter.com/projects/revolights/revolights-join-the-revolution
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Software system design, development, and documentation

From quinn at pgexperts.com  Wed Dec 21 14:48:50 2011
From: quinn at pgexperts.com (Quinn Weaver)
Date: Wed, 21 Dec 2011 17:48:50 -0500
Subject: [sf-perl] FYI/OT - revolights
In-Reply-To: 
References: 
Message-ID: <79082098-35E1-4E68-AF1B-6E6BE82EDBB0@pgexperts.com>

On Dec 21, 2011, at 4:06 PM, Rich Morin wrote:

> At least three of the folks at last night's feed are
> seriously into bicycling.  Here's something cool to
> add to your bike at some point...

Thanks for sharing; that is awesome. I trust this thread isn't too off-topic. If you disagree, you may want to skip this post (or this whole thread). :)

Anyway, cool. I were to build a Tron-style lightcycle (which I just miiight be dorky enough to do someday), that is something I'd want.

The key to safe lighting, I've learned, is to make yourself visible from all angles. For the present, the best tech I know is 1) screaming neon yellow outerwear and 2) electroluminescent wire (EL wire). Unidirectional LED lamps are good for lighting your way, but not so good for alerting cars to your presence[1].

You can buy preassembled kits of EL wire, zipties, and a battery pack at most local bike stores. You just spiral the wire around your frame, ziptying it into place, and mount the pack somewhere. It's really easy. The stuff runs forever on a couple of AAs.

If you want t be slightly more ambitious, you can cut and solder your own EL wire. This is good for sewing EL wire to your clothing. http://www.coolneon.com/ is a good place to get supplies. They're in Oakland, FWIW, and very occasionally they teach classes: http://www.coolneon.com/el-wire-soldering/soldering-party/ (Noisebridge might be a better place to learn; dunno).

Hope this helps someone,

1. Helmet-mounted LED lamps are an exception. They're nice in that you can turn your head to aim them, so just looking at a driver who's about to pull out of a driveway at you, for instance, can give them the heads-up they need to see you. I have a helmet mounted light that recharges via USB.

--
Quinn Weaver
PostgreSQL Experts, Inc.
http://pgexperts.com/
1-888-743-9778 (my extension: 510)



-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From fobispo at isc.org  Thu Dec 22 08:47:09 2011
From: fobispo at isc.org (Francisco Obispo)
Date: Thu, 22 Dec 2011 08:47:09 -0800
Subject: [sf-perl] [off-topic] Invitation to BIND open Day
Message-ID: 

http://www.isc.org/bind-day-2012-Jan

If you or your colleagues are using BIND (DNS server) and are in the bay area, please feel free to drop by for an open day.

Francisco Obispo 
email: fobispo at isc.org
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
Key fingerprint = 532F 84EB 06B4 3806 D5FA  09C6 463E 614E B38D B1BE