From doom at kzsu.stanford.edu Thu Mar 1 15:52:10 2012 From: doom at kzsu.stanford.edu (Joseph Brenner) Date: Thu, 1 Mar 2012 15:52:10 -0800 Subject: [sf-perl] Mouse, again? Message-ID: Can someone refresh my memory about the problems are supposed to be with using Mouse? At the moment, I feel like the main problem with it is that it's invisible to web searches. From earl at ruby.org Thu Mar 1 16:58:53 2012 From: earl at ruby.org (Earl Ruby) Date: Thu, 1 Mar 2012 16:58:53 -0800 Subject: [sf-perl] Thanks for coming to the meeting In-Reply-To: References: Message-ID: Jeffery: Enjoyed the talk. At the company I currently work for we have to ensure that all of the CPAN module versions installed on 80+ servers are known and tested versions. Our internal code is not packaged up using CPAN-style packaging, we only use CPAN repos for distributing CPAN modules. Our use case is a little simpler than yours, so we just keep the entire CPAN repo rsync'ed to a "/cpan/latest" directory, and we have a locked-in-time "/cpan/production" repo that's been tested and is used by all production servers. When we want to test the latest modules against our code we make a release candidate (rc) using hard links: cp -al /cpan/latest /cpan/rc-20120301235615 Take a set of test servers, tell them to use /cpan/rc-20120301235615 as their CPAN repo, run all tests, verify that all is well, then: mv /cpan/production /cpan/production-archive-20120302030122 mv /cpan/rc-20120301235615 /cpan/production Now all servers pull the latest CPAN files from production. If something goes Terribly Wrong, move the old production repo back into place. If someone wants a special repo for qa or dev they can easily create one with hard links: cp -al /cpan/latest /cpan/qa-20120301235615 cp -al /cpan/latest /cpan/dev-20120301235615 Hard links have the advantage of only using an extra inode on the file system to make a copy of the file, but when /cpan/latest is updated the rc, qa, and dev hard links still point to the old versions of the files. If someone wants to modify their hard-linked CPAN "dev" copy" their changes don't affect the other copies of the repos, and the only additional storage hit is for the changed files, not the whole repo. You'd mentioned that you wanted to offer a way to maintain separate qa, dev, etc. repos. You might take a look at using hard links and see if they give you the functionality you want. One word of warning, depending on the file system you're using you may want to create extra inodes when you format the file system. I typically use ext3 and I add extra inodes when I create the file system. ext4 is supposed to add extra inodes as needed, but I've stayed away from ext4 due to performance issues. YMMV. -- Earl On Wed, Feb 29, 2012 at 12:15 AM, Jeffrey Thalhammer wrote: > Hi everyone- > > I just wanted to thank all of you who came out for the PM meeting tonight. ?I really enjoyed speaking with you, and I hope you found the presentation on Pinto informative. ?I'll let you know when I've posted the slides to Slideshare. > > I'll be presenting Pinto to LA.PM next month and again at YAPC in June. ?So if you have any feedback that would help me make the presentation better, I'd love hear from you. > > Lastly, if you see an opportunity for Pinto to help your team manage their dependencies, I'd be happy to provide you with some consulting services in that area. ?You can reach me via jeff at imaginative-software.com or 415-215-2834. > > Special thanks to Fred Moyer for organizing and Mother Jones for hosting too. > > Cheers! > > -Jeff > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm -- Earl Ruby http://earlruby.org/ @earlruby From doomvox at gmail.com Thu Mar 1 17:08:33 2012 From: doomvox at gmail.com (Joseph Brenner) Date: Thu, 1 Mar 2012 17:08:33 -0800 Subject: [sf-perl] Mouse, again? In-Reply-To: References: Message-ID: Quinn Weaver wrote: > Joseph Brenner wrote: >> Can someone refresh my memory about >> the problems are supposed to be with using Mouse? > "Mouse?" Predictably, all my web searches are returning > the wrong thing. Precisely. Anyway, for those who haven't heard of it: Mouse is a CPAN module, it's intended to be a lightweight alternative to Moose: the syntax is the same as Moose, though by design it only does basic stuff, but does it around 4x faster (or so they claim). There was a brief period there when Mouse was popular as a light-weight Moose, but (as I remember it), then some arguments emerged to shoot it down. By the way: I've thought about it, and concluded that for my purposes I have no interest in using the wrapper module Any::Moose: by design, it's a way of using Mouse without committing to it permanently, if it sees Moose installed it will use that instead. That strikes me as a potentially nasty action-at-a-distance performance bomb I would rather not inflict on whoever needs to maintain this code. From quinn at pgexperts.com Fri Mar 2 00:04:34 2012 From: quinn at pgexperts.com (Quinn Weaver) Date: Fri, 2 Mar 2012 00:04:34 -0800 Subject: [sf-perl] Mouse, again? In-Reply-To: References: Message-ID: On Mar 1, 2012, at 5:08 PM, Joseph Brenner wrote: > Quinn Weaver wrote: >> Joseph Brenner wrote: > >>> Can someone refresh my memory about >>> the problems are supposed to be with using Mouse? > >> "Mouse?" Predictably, all my web searches are returning >> the wrong thing. > > Precisely. Anyway, for those who haven't heard of it: Mouse is a > CPAN module, it's intended to be a lightweight alternative to Moose: > the syntax is the same as Moose, though by design it only does basic > stuff, but does it around 4x faster (or so they claim). Oh, another Perl object system. That's great, I'd really been hoping for one. -- Quinn Weaver PostgreSQL Experts, Inc. http://pgexperts.com/ 1-888-743-9778 (my extension: 510) -------------- next part -------------- An HTML attachment was scrubbed... URL: From not.com at gmail.com Fri Mar 2 06:54:42 2012 From: not.com at gmail.com (yary) Date: Fri, 2 Mar 2012 09:54:42 -0500 Subject: [sf-perl] Mouse, again? In-Reply-To: References: Message-ID: > Joseph Brenner wrote: > > > Can someone refresh my memory about > > the problems are supposed to be with using Mouse? > Quinn Weaver wrote: > > "Mouse?" Predictably, all my web searches are returning > the wrong thing. Seems like the thing to search for is "moose mouse perl", or blekko "mouse /perl " >From an answer to http://stackoverflow.com/questions/980751/should-i-learn-perl-5-oo-or-moose-first "Finally there is no reason to use Mouse (an alternative to Moose) unless you fall into two very specific categories, you have hard start up time constraints or hard dependency requirements. If you don't fall into those two places Moose will almost always be a better answer. Disclosure: I'm a core Moose developer, and have worked on and with Mouse." >From http://blog.jdpfu.com/2011/12/02/of-moose-mouse-moo-and-mo-for-oo-perl (That page also has a chart showing what features the various Moose alternatives provide) "Mouse is a Moose compatible object system. They do warn that Mouse is a little sloppier than Moose, so if you run into weird errors, it could be Mouse causing them. They claim that running s/Mouse/Moose/g on your code will work." >From the comments at http://bugsplat.info/2010-05-09-moose-vs-mouse.html "I've been told the main reason for using Moose over Mouse is that Moose is extensible Mouse isn't... Not sure I really understand it all. But thanks for the tips." Maybe the mouse-squashing is related to a hope Moose's performance will catch up. From https://news.ycombinator.com/item?id=1332571 ----- wazoox 662 days ago | link In my understanding Mouse is to become irrelevant someday, as Moose goes forward. ----- autarch 662 days ago | link That's the long-term goal, but to make that happen is pretty hard. One possibility is implementing some sort of XS for all Moose core features, and using XS to implement Moose-based classes (Mouse already does this). Another project which has been worked on, but has somewhat stalled, is a Moose "compiler" which would generate .pmc files for your classes. Unless you used the meta-model at runtime (most code doesn't), you'd never even need to load Moose. Patches welcome, of course. If anyone's interested in these projects, join us at irc://irc.perl.org/#moose to discuss then. -y From el.dodgero at gmail.com Fri Mar 2 08:21:36 2012 From: el.dodgero at gmail.com (Dodger) Date: Fri, 2 Mar 2012 08:21:36 -0800 Subject: [sf-perl] Mouse, again? In-Reply-To: References: Message-ID: I've never found a reason to use either. But even if I did I would never use them in anything intended for sharing on CPAN. It's one of those "do into others" things. I hate it whenever I find a module that seems to do everything I need, but it uses some other module that isn't important to its functionality, but some developer liked. Like Moose. (Or ten thousand different incompatible test harnesses that I end up with installed because people randomly decided all their tests for a pure perl module needed to be done using Test::Wankish::Obscure::Nonsense) -- Dodger Sent from my iPhone On 01/03/2012, at 3:52 PM, Joseph Brenner wrote: > Can someone refresh my memory about the problems are supposed to be > with using Mouse? > > At the moment, I feel like the main problem with it is that it's > invisible to web searches. > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm From hartzell at alerce.com Fri Mar 2 09:31:55 2012 From: hartzell at alerce.com (George Hartzell) Date: Fri, 2 Mar 2012 09:31:55 -0800 Subject: [sf-perl] Mouse, again? In-Reply-To: References: Message-ID: <20305.1035.984342.132570@gargle.gargle.HOWL> Dodger writes: > I've never found a reason to use either. > > But even if I did I would never use them in anything intended for > sharing on CPAN. > > It's one of those "do into others" things. > > I hate it whenever I find a module that seems to do everything I > need, but it uses some other module that isn't important to its > functionality, but some developer liked. Like Moose. > > (Or ten thousand different incompatible test harnesses that I end > up with installed because people randomly decided all their tests > for a pure perl module needed to be done using > Test::Wankish::Obscure::Nonsense) Just to keep things in perspective, Moose and all of it's dependencies installed from scratch on a macbook pro (with an SSD) in 2 minutes and 20 seconds. Almost a minute of that time was Moose running its tests (time cpanm -L /tmp/moose-test Moose). It installed 22 distributions: Try-Tiny-0.11 Test-Fatal-0.010 Params-Util-1.06 Sub-Install-0.926 Data-OptList-0.107 Sub-Exporter-0.982 List-MoreUtils-0.33 Dist-CheckConflicts-0.02 Test-Requires-0.06 Package-DeprecationManager-0.11 Package-Stash-XS-0.25 Task-Weaken-1.04 MRO-Compat-0.11 Package-Stash-0.33 Module-Runtime-0.013 Module-Implementation-0.06 Class-Load-0.18 Class-Load-XS-0.04 Eval-Closure-0.08 Sub-Name-0.05 Devel-GlobalDestruction-0.04 Moose-2.0402 Some of those, like List-MoreUtils are already pretty common. Others, like Try-Tiny are things that everyone *should* be using, unless they understand and code for the corner cases that eval {...} if ($@) { ... } fail to catch. Task-Weaken papers over various OS distro's packaging misdeeds. Naked old-school code-it-all-myself Perl isn't interesting to me. I've found that putting some energy into learning (and leaning on) a choice set of CPAN tools (libraries, "frameworks", whatever...) has been well worth the investment. One of my challenges with CPAN and Perl is to stay in the "main channel" of the river as it flows along and not get "tricked" into using stuff that doesn't have legs and/or that doesn't have wide applicability. I'm still trying to crack this, but Perl Mongers, YAPC, and the various blogs seem to be giving me a good start. g. From swartz at pobox.com Fri Mar 2 09:58:46 2012 From: swartz at pobox.com (Jonathan Swartz) Date: Fri, 2 Mar 2012 09:58:46 -0800 Subject: [sf-perl] Mouse, again? In-Reply-To: References: Message-ID: <6F60DFBF-B357-43E6-88CB-8E86BFF676CD@pobox.com> I'll give the polar opposite perspective from Dodger. I use Moose whenever I can. As far as I'm concerned it brings Perl into the modern language arena, by finally giving it a powerful, standard OO syntax and feature set. I love it when CPAN module developers use the things they like. Because they'll be more motivated to work on their module, and they'll spend time adding features and fixing bugs instead of reinventing the wheel. For me, it's worth a little extra one-time install cost to get happier module developers. In the limit I'm hoping Moose will just be installed on everyone's system and it'll no longer be seen as an install barrier. :) Joseph: As far as Mouse, I tried to use it for CHI at one point, then backed out. The problem is that it sort of looks lke Moose, but will break in all kinds of funny ways when you try to use advanced features. It especially breaks down when trying to use MooseX extensions. Its only advantage is faster start-up time. If you're writing a command-line script that has to be executed all the time, that might be important. If you're writing anything that's going to run persistently, like web code, then not so important. Jon On Mar 2, 2012, at 8:21 AM, Dodger wrote: > I've never found a reason to use either. > > But even if I did I would never use them in anything intended for sharing on CPAN. > > It's one of those "do into others" things. > > I hate it whenever I find a module that seems to do everything I need, but it uses some other module that isn't important to its functionality, but some developer liked. Like Moose. > > (Or ten thousand different incompatible test harnesses that I end up with installed because people randomly decided all their tests for a pure perl module needed to be done using Test::Wankish::Obscure::Nonsense) > > -- > Dodger > > Sent from my iPhone > > On 01/03/2012, at 3:52 PM, Joseph Brenner wrote: > >> Can someone refresh my memory about the problems are supposed to be >> with using Mouse? >> >> At the moment, I feel like the main problem with it is that it's >> invisible to web searches. >> _______________________________________________ >> SanFrancisco-pm mailing list >> SanFrancisco-pm at pm.org >> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm From simon at thegestalt.org Fri Mar 2 10:09:38 2012 From: simon at thegestalt.org (Simon Wistow) Date: Fri, 2 Mar 2012 18:09:38 +0000 Subject: [sf-perl] Mouse, again? In-Reply-To: <20305.1035.984342.132570@gargle.gargle.HOWL> References: <20305.1035.984342.132570@gargle.gargle.HOWL> Message-ID: <20120302180938.GN75852@thegestalt.org> On Fri, Mar 02, 2012 at 09:31:55AM -0800, George Hartzell said: > Some of those According to CPAN deps it's more like 62 Modules of which approximately 25% are core. http://deps.cpantesters.org/?module=Moose&perl=any+version&os=any+OS Moose Test::Requires Test::More Test::Harness ExtUtils::MakeMaker - Core module Package::DeprecationManager Params::Util Scalar::Util File::Spec File::Path - Core module Test - Core module File::Basename - Core module Carp - Core module Exporter - Core module ExtUtils::CBuilder IO::File - Core module IPC::Cmd Locale::Maketext::Simple Module::Load::Conditional Module::Load version File::Temp Module::CoreList Params::Check Text::ParseWords - Core module Perl::OSType constant - Core module Sub::Install Test::Fatal Try::Tiny List::MoreUtils Package::Stash::XS Sub::Exporter Data::OptList Task::Weaken MRO::Compat Class::C3 Algorithm::C3 Class::Load::XS XSLoader - Core module Class::Load Module::Runtime Module::Build Module::Metadata ExtUtils::Install - Core module CPAN::Meta Parse::CPAN::Meta JSON::PP CPAN::Meta::YAML Data::Dumper - Core module ExtUtils::Manifest - Core module Text::Abbrev Getopt::Long - Core module ExtUtils::ParseXS DynaLoader - Core module Module::Implementation base - Core Module Package::Stash Dist::CheckConflicts Eval::Closure Sub::Name Devel::GlobalDestruction From doomvox at gmail.com Fri Mar 2 10:30:54 2012 From: doomvox at gmail.com (Joseph Brenner) Date: Fri, 2 Mar 2012 10:30:54 -0800 Subject: [sf-perl] Mouse, again? In-Reply-To: References: Message-ID: Quinn Weaver wrote: > Oh, another Perl object system. That's great, I'd really been hoping for one. No, no, not a *new* object system, a sub-set of an existing one. It's, like, a bridge to the glorious Moose future (which in turn is a bridge to glorious Perl 6 future). From hartzell at alerce.com Fri Mar 2 10:48:10 2012 From: hartzell at alerce.com (George Hartzell) Date: Fri, 2 Mar 2012 10:48:10 -0800 Subject: [sf-perl] Mouse, again? In-Reply-To: <20120302180938.GN75852@thegestalt.org> References: <20305.1035.984342.132570@gargle.gargle.HOWL> <20120302180938.GN75852@thegestalt.org> Message-ID: <20305.5610.660940.269259@gargle.gargle.HOWL> Simon Wistow writes: > On Fri, Mar 02, 2012 at 09:31:55AM -0800, George Hartzell said: > > Some of those > > According to CPAN deps it's more like 62 Modules of which > approximately 25% are core. > > http://deps.cpantesters.org/?module=Moose&perl=any+version&os=any+OS > [...] Hmmm. I guess that we're both right, just answering different questions. I was curious about what the overhead of using Moose would be, compared to basic Perl. How many additional distributions would I need to install. I started with my perlbrew'ed perl 5.14.2, then used cpanm's local-lib-contained functionality to install everything that wasn't part of the core (making sure I wasn't cheating by having already installed random bits and pieces). The result was 22 add'l distro's. It wouldn't surprise me if other perl's would pull in a few more/less distro's, depending what's in their core. Moose *is* a bit of a gateway drug, however. There's a *big* step in my mind between using Moose and a tasteful set of MooseX to{ol,y}s versus getting involved with heavier things like MooseX::Declare and it's Devel::Declare underpinnings. Developing taste is a journey. The cpan testers link counts "Modules". That's probably going to cause some difference too. g. From doomvox at gmail.com Fri Mar 2 11:20:33 2012 From: doomvox at gmail.com (Joseph Brenner) Date: Fri, 2 Mar 2012 11:20:33 -0800 Subject: [sf-perl] Mouse, again? In-Reply-To: References: Message-ID: yary wrote: > Seems like the thing to search for is "moose mouse perl", or blekko > "mouse /perl " Hey Yary. Thanks. The blekko "/perl" is a good trick, I'd forgotten about that one. So in summary, the trouble with Mouse is that it is not Moose, and it's "light-weightness" is only a slight advantage over Moose... depending on your circumstances. From doom at kzsu.stanford.edu Fri Mar 2 11:34:33 2012 From: doom at kzsu.stanford.edu (Joseph Brenner) Date: Fri, 2 Mar 2012 11:34:33 -0800 Subject: [sf-perl] Mouse, again? In-Reply-To: References: Message-ID: Dodger wrote: > I've never found a reason to use either. > > But even if I did I would never use them in anything intended for sharing on CPAN. > > It's one of those "do into others" things. Well, I know what you mean. It's a design decision you've got to make up your mind about when you work on a CPAN module. I've put some stuff out there with a heavy stack of dependencies on the theory that we all know how to use CPAN.pm, CPANPLUS, and/or cpanminus these days, and then gotten complaints from users who were apparently into doing it all manually, downloading tarballs and typing "perl Makefile.PL" themselves. It's something you need to at least think about: all perl users are not exactly members of "the perl community" and we often don't have a good grasp of what their lives are like. (I'm also an advocate of a fat perl core... The perl porters seem to have convinced themselves that "let them eat CPAN" is a valid response to user problems.) > (Or ten thousand different incompatible test harnesses that I end up with installed because people randomly decided all their tests for a pure perl module needed to be done using Test::Wankish::Obscure::Nonsense) Well, it's at least possible for cpan authors to classify a dependency as a test requirement, so that your installation tools will have it to run the tests, without actually installing it. ("Incompatible"? They don't actually break each other, do they?) From doom at kzsu.stanford.edu Fri Mar 2 11:50:13 2012 From: doom at kzsu.stanford.edu (Joseph Brenner) Date: Fri, 2 Mar 2012 11:50:13 -0800 Subject: [sf-perl] Mouse, again? In-Reply-To: <6F60DFBF-B357-43E6-88CB-8E86BFF676CD@pobox.com> References: <6F60DFBF-B357-43E6-88CB-8E86BFF676CD@pobox.com> Message-ID: Jonathan Swartz wrote: > Joseph: As far as Mouse, I tried to use it for CHI at one point, then backed out. The problem is that it sort of looks lke Moose, but will break in all kinds of funny ways when you try to use advanced features. It especially breaks down when trying to use MooseX extensions. Yeah, that's a problem I kind-of expected. > Its only advantage is faster start-up time. If you're writing a command-line script that has to be executed all the time, that might be important. If you're writing anything that's going to run persistently, like web code, then not so important. Right. I should explain that at present the reason I'm considering using it is that I've noticed that it's already installed where I work (as is "Class::Accessors", oddly enough), and I will probably start playing with Mouse just because it's there and I don't have to jump through any political hoops to get something else. I'm also happy not to write my own base class (doable, but it feels very stupid). To speculate on why Mouse is installed and not Moose: I would guess that the dev team was interested in trying something new, but was worried about the heavy-weight reputation of Moose. The concern is probably not start-up time (this is a mod_perl shop) but memory usage on the high-traffic web servers... (There are a bunch of things that could be improved about the architecture of this place, notably the fact that there's essentially a single tree of live code, so even though I'm doing intranet/database crunching work that doesn't touch the front end, I have to live with code development processes that are paranoid about taking down a web site and losing a hundred thousand an hour until it's back up.) From matt at lanier.org Fri Mar 2 12:13:22 2012 From: matt at lanier.org (Matthew Lanier) Date: Fri, 2 Mar 2012 12:13:22 -0800 (PST) Subject: [sf-perl] matt moving on, permanently Message-ID: Hey Folks- When David Lowe and I started the SFPUG back in, what was it, 1998, we didn't have a clue that it would still be a going concern in 2012. A lot has changed since then, but what hasn't it that this a smart, good hearted set of people who are passionate about perl and about the greater FOSS community. We have persevered through mutliple "perl is dead" cycles, and are still here. What has changed is that I'm not spending time doing perl, and there's a chance that I won't be any time soon. It's time for me to acknowledge that and make a high level change in organization structure. Since I handed this group off to Quinn back in 2002, I've maintained the role of Chairman if you will, ensuring that a qualified President was on board to keep things running. While you haven't seen me at many meetings, I stay in contact with the current leader, ensure that meetings are happening, and keep a pulse for when it's time to give that leader a break. It has been a fulfilling role to know that my baby, this group, continues to live on and fulfill a need in the perl community. It is now time for me to step away permanently so that I can focus on my growing family (3 kids) a challenging job (running operations at Ooyala) and my vocation (as a musician and liturgician). To that end, as of now Fred Moyer is the supreme leader of the SFPUG, with Joe Brenner as his right hand man. You know how to bother them, so keep it up :-) I'd like to thank the following folks: * to the folks who were at the first meeting or two, and are still here at some level (david fetter, paul makepeace, rich and vicky brown, joe brenner, smurf), you kick ass. * to the folks who have run this group, quinn weaver, fred moyer, and joe brenner, you seriously kick ass. * to all the companies that have sponsored the spfug, including intershop, redhat, six apart, and countless other companies, thanks for your support. Ok folks, I'm out, enjoy your sigils- m@ -- Matthew D. P. K. Lanier From quinn at pgexperts.com Fri Mar 2 12:54:25 2012 From: quinn at pgexperts.com (Quinn Weaver) Date: Fri, 2 Mar 2012 12:54:25 -0800 Subject: [sf-perl] matt moving on, permanently In-Reply-To: References: Message-ID: <11020A41-63CE-448E-B98E-D37F6C95597A@pgexperts.com> Hi, Matt, Thanks for sharing the news. It's been a pleasure working with you. It was hard for me to let go when I got too busy and decided to step down as president, and I imagine it may be the same for you. I wish you the best of success in your endeavors. Fred and Joe have been awesome in the context of SFPUG and elsewhere. I'm confident in their ability to keep producing a great PUG. We've had some really great talks lately. While we're thanking people, I'll chip in what I can remember. ;) We've had talks by many luminaries of the Perl world. I don't dare mention them because I *know* I will forget someone; like CPAN, SFPUG is made of a cast of thousands. A lot of credit is due to past and present hosts like Smurph, Jeff Thalhammer, Ben Trott, and Matt himself, who managed our venues (I'm sure I'm forgetting others, and I apologize). These hosts hung around work late and variously took care of food, conference rooms, tables and chairs, video projectors? I did this for years at BGI, and it was a lot of work. Logistics is always more heavy lifting than people realize. Julian Cash, Brian Hamlin, Joe, and Yary deserve extra credit for helping with our LugRadio booth. And of course Julian has taken some amazing light-painting photos of the Perl community over the years. Enjoy your retirement, Matt! Great work so far, Fred and Joe! I'm looking forward to good events for years to come. On Mar 2, 2012, at 12:13 PM, Matthew Lanier wrote: > Hey Folks- > > When David Lowe and I started the SFPUG back in, what was it, 1998, we didn't have a clue that it would still be a going concern in 2012. A lot has changed since then, but what hasn't it that this a smart, good hearted set of people who are passionate about perl and about the greater FOSS community. We have persevered through mutliple "perl is dead" cycles, and are still here. > > What has changed is that I'm not spending time doing perl, and there's a chance that I won't be any time soon. It's time for me to acknowledge that and make a high level change in organization structure. > > Since I handed this group off to Quinn back in 2002, I've maintained the role of Chairman if you will, ensuring that a qualified President was on board to keep things running. While you haven't seen me at many meetings, I stay in contact with the current leader, ensure that meetings are happening, and keep a pulse for when it's time to give that leader a break. It has been a fulfilling role to know that my baby, this group, continues to live on and fulfill a need in the perl community. > > It is now time for me to step away permanently so that I can focus on my growing family (3 kids) a challenging job (running operations at Ooyala) and my vocation (as a musician and liturgician). To that end, as of now Fred Moyer is the supreme leader of the SFPUG, with Joe Brenner as his right hand man. You know how to bother them, so keep it up :-) > > I'd like to thank the following folks: > > * to the folks who were at the first meeting or two, and are still here at > some level (david fetter, paul makepeace, rich and vicky brown, > joe brenner, smurf), you kick ass. > > * to the folks who have run this group, quinn weaver, fred moyer, and joe > brenner, you seriously kick ass. > > * to all the companies that have sponsored the spfug, including intershop, redhat, six apart, and countless other companies, thanks for your support. > > Ok folks, I'm out, enjoy your sigils- > > m@ > > -- > Matthew D. P. K. Lanier > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm -- Quinn Weaver PostgreSQL Experts, Inc. http://pgexperts.com/ 1-888-743-9778 (my extension: 510) -------------- next part -------------- An HTML attachment was scrubbed... URL: From quinn at pgexperts.com Sat Mar 3 16:18:30 2012 From: quinn at pgexperts.com (Quinn Weaver) Date: Sat, 3 Mar 2012 16:18:30 -0800 Subject: [sf-perl] matt moving on, permanently In-Reply-To: <11020A41-63CE-448E-B98E-D37F6C95597A@pgexperts.com> References: <11020A41-63CE-448E-B98E-D37F6C95597A@pgexperts.com> Message-ID: <4F152539-0B68-43EB-B153-BB2FB87C8974@pgexperts.com> On Mar 2, 2012, at 12:54 PM, Quinn Weaver wrote: > And of course Julian has taken some amazing light-painting photos of the Perl community over the years. I couldn't find links at the time I wrote this, but I asked Julian and he sent these: Perl people photos: http://www.flickr.com/photos/juliancash/sets/72157600711382729 Non-Perl photos: http://juliancash.com/ > > Enjoy your retirement, Matt! Great work so far, Fred and Joe! I'm looking forward to good events for years to come. > > On Mar 2, 2012, at 12:13 PM, Matthew Lanier wrote: > >> Hey Folks- >> >> When David Lowe and I started the SFPUG back in, what was it, 1998, we didn't have a clue that it would still be a going concern in 2012. A lot has changed since then, but what hasn't it that this a smart, good hearted set of people who are passionate about perl and about the greater FOSS community. We have persevered through mutliple "perl is dead" cycles, and are still here. >> >> What has changed is that I'm not spending time doing perl, and there's a chance that I won't be any time soon. It's time for me to acknowledge that and make a high level change in organization structure. >> >> Since I handed this group off to Quinn back in 2002, I've maintained the role of Chairman if you will, ensuring that a qualified President was on board to keep things running. While you haven't seen me at many meetings, I stay in contact with the current leader, ensure that meetings are happening, and keep a pulse for when it's time to give that leader a break. It has been a fulfilling role to know that my baby, this group, continues to live on and fulfill a need in the perl community. >> >> It is now time for me to step away permanently so that I can focus on my growing family (3 kids) a challenging job (running operations at Ooyala) and my vocation (as a musician and liturgician). To that end, as of now Fred Moyer is the supreme leader of the SFPUG, with Joe Brenner as his right hand man. You know how to bother them, so keep it up :-) >> >> I'd like to thank the following folks: >> >> * to the folks who were at the first meeting or two, and are still here at >> some level (david fetter, paul makepeace, rich and vicky brown, >> joe brenner, smurf), you kick ass. >> >> * to the folks who have run this group, quinn weaver, fred moyer, and joe >> brenner, you seriously kick ass. >> >> * to all the companies that have sponsored the spfug, including intershop, redhat, six apart, and countless other companies, thanks for your support. >> >> Ok folks, I'm out, enjoy your sigils- >> >> m@ >> >> -- >> Matthew D. P. K. Lanier >> _______________________________________________ >> SanFrancisco-pm mailing list >> SanFrancisco-pm at pm.org >> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > > > -- > Quinn Weaver > PostgreSQL Experts, Inc. > http://pgexperts.com/ > 1-888-743-9778 (my extension: 510) > > > -- Quinn Weaver PostgreSQL Experts, Inc. http://pgexperts.com/ 1-888-743-9778 (my extension: 510) -------------- next part -------------- An HTML attachment was scrubbed... URL: From cpan at goess.org Sun Mar 4 00:13:26 2012 From: cpan at goess.org (Kevin Goess) Date: Sun, 4 Mar 2012 09:13:26 +0100 Subject: [sf-perl] Mouse, again? In-Reply-To: References: <6F60DFBF-B357-43E6-88CB-8E86BFF676CD@pobox.com> Message-ID: A different point of view that may be illuminating: we wanted to use the cpan module WebService::Solr in our web application, a simple module that took care of the details of posting documents to Solr. It was bringing in Moose, but didn't do anything Moosish except use the shorthand constructor code. We were hesitant to use this as the trigger to bringing in all of Moose to our webapp, with all the installation, testing and support/maintenance that would entail, so we prevailed on the author to switch to Mouse instead. A side note, I wonder how much of a problem non-native English speakers have with "Mouse" versus "Moose." I'm learning Polish myself now and keep blowing mental fuses on things like wej?cie/wyj?cie (entrance/exit) or do??/doj?? (enough/to get somplace). On Fri, Mar 2, 2012 at 8:50 PM, Joseph Brenner wrote: > Jonathan Swartz wrote: > > > Joseph: As far as Mouse, I tried to use it for CHI at one point, then > backed out. The problem is that it sort of looks lke Moose, but will break > in all kinds of funny ways when you try to use advanced features. It > especially breaks down when trying to use MooseX extensions. > > Yeah, that's a problem I kind-of expected. > > > Its only advantage is faster start-up time. If you're writing a > command-line script that has to be executed all the time, that might be > important. If you're writing anything that's going to run persistently, > like web code, then not so important. > > Right. I should explain that at present the reason I'm considering > using it is that I've noticed that it's already installed where I work > (as is "Class::Accessors", oddly enough), and I will probably start > playing with Mouse just because it's there and I don't have to jump > through any political hoops to get something else. I'm also happy not > to write my own base class (doable, but it feels very stupid). > > To speculate on why Mouse is installed and not Moose: I would guess > that the dev team was interested in trying something new, but was > worried about the heavy-weight reputation of Moose. The concern is > probably not start-up time (this is a mod_perl shop) but memory usage > on the high-traffic web servers... > > (There are a bunch of things that could be improved about the > architecture of this place, notably the fact that there's essentially > a single tree of live code, so even though I'm doing intranet/database > crunching work that doesn't touch the front end, I have to live with > code development processes that are paranoid about taking down a web > site and losing a hundred thousand an hour until it's back up.) > _______________________________________________ > 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 swartz at pobox.com Sun Mar 4 04:33:16 2012 From: swartz at pobox.com (Jonathan Swartz) Date: Sun, 4 Mar 2012 04:33:16 -0800 Subject: [sf-perl] Mouse, again? In-Reply-To: References: <6F60DFBF-B357-43E6-88CB-8E86BFF676CD@pobox.com> Message-ID: <60D24C4A-A314-4AC7-8AEA-DF3FFBDB0557@pobox.com> > We were hesitant to use this as the trigger to bringing in all of Moose to our webapp, with all the installation, testing and support/maintenance that would entail Is this a webapp that has to be installed in many places, e.g. by your customers? Or is it installed in a single place? If the latter, then I don't understand. This will install and test it: % cpanm Moose And once a year or whenever you upgrade your CPAN stack, the same command will upgrade and test it. What kind of activities would you have to do to "support/maintain" Moose? Your webapp already depends on a huge stack of code, namely Perl and C/Unix*, including lots of stuff that you never use. I'm assuming that it doesn't bother you or require maintenance. Moose is a biggish module but is vanishingly small compared to that stack. Jon * I assume From not.com at gmail.com Sun Mar 4 06:55:44 2012 From: not.com at gmail.com (yary) Date: Sun, 4 Mar 2012 09:55:44 -0500 Subject: [sf-perl] Mouse, again? In-Reply-To: References: <6F60DFBF-B357-43E6-88CB-8E86BFF676CD@pobox.com> Message-ID: 2012/3/4 Kevin Goess : > ...? It was bringing in > Moose, but didn't do anything Moosish except use the shorthand constructor > code.? ... Now that you mention it, once I used a set of command-line tools that used Class::Accessor. I came across a fork of the tools which had a few minor changes, plus Moose replacing Class::Accessor. The forker preferred Moose (saying so in the commit comment) and it's no-ones business to say otherwise, but I didn't like the start-up delay of that version- so I turned it back to "use Class::Accessor 'antlers'" and all was well. I would use Moose for any new medium-sized or larger project, and I especially respect the authors' attention to both theory of OO principles and practice of programming. But it isn't a tool for all occasions. From quinn at pgexperts.com Sun Mar 4 14:30:23 2012 From: quinn at pgexperts.com (Quinn Weaver) Date: Sun, 4 Mar 2012 14:30:23 -0800 Subject: [sf-perl] Mouse, again? In-Reply-To: <60D24C4A-A314-4AC7-8AEA-DF3FFBDB0557@pobox.com> References: <6F60DFBF-B357-43E6-88CB-8E86BFF676CD@pobox.com> <60D24C4A-A314-4AC7-8AEA-DF3FFBDB0557@pobox.com> Message-ID: On Mar 4, 2012, at 4:33 AM, Jonathan Swartz wrote: > Your webapp already depends on a huge stack of code, namely Perl and C/Unix*, including lots of stuff that you never use. I'm assuming that it doesn't bother you or require maintenance. Moose is a biggish module but is vanishingly small compared to that stack. And it's probably better tested than Mouse! It's certainly more widely used. -- Quinn Weaver PostgreSQL Experts, Inc. http://pgexperts.com/ 1-888-743-9778 (my extension: 510) -------------- next part -------------- An HTML attachment was scrubbed... URL: From fred at redhotpenguin.com Mon Mar 5 12:53:40 2012 From: fred at redhotpenguin.com (Fred Moyer) Date: Mon, 5 Mar 2012 12:53:40 -0800 Subject: [sf-perl] matt moving on, permanently In-Reply-To: References: Message-ID: I've been away from the keyboard for a couple days, but just got back and wanted to say thanks to Matt for all his contributions to the group throughout the years. Thanks Matt! On Friday, March 2, 2012 at 12:13 PM, Matthew Lanier wrote: > Hey Folks- > > When David Lowe and I started the SFPUG back in, what was it, 1998, we > didn't have a clue that it would still be a going concern in 2012. A lot > has changed since then, but what hasn't it that this a smart, good hearted > set of people who are passionate about perl and about the greater FOSS > community. We have persevered through mutliple "perl is dead" cycles, and > are still here. > > What has changed is that I'm not spending time doing perl, and there's a > chance that I won't be any time soon. It's time for me to acknowledge > that and make a high level change in organization structure. > > Since I handed this group off to Quinn back in 2002, I've maintained the > role of Chairman if you will, ensuring that a qualified President was on > board to keep things running. While you haven't seen me at many meetings, > I stay in contact with the current leader, ensure that meetings are > happening, and keep a pulse for when it's time to give that leader a > break. It has been a fulfilling role to know that my baby, this group, > continues to live on and fulfill a need in the perl community. > > It is now time for me to step away permanently so that I can focus on my > growing family (3 kids) a challenging job (running operations at Ooyala) > and my vocation (as a musician and liturgician). To that end, as of now > Fred Moyer is the supreme leader of the SFPUG, with Joe Brenner as his > right hand man. You know how to bother them, so keep it up :-) > > I'd like to thank the following folks: > > * to the folks who were at the first meeting or two, and are still here at > some level (david fetter, paul makepeace, rich and vicky brown, > joe brenner, smurf), you kick ass. > > * to the folks who have run this group, quinn weaver, fred moyer, and joe > brenner, you seriously kick ass. > > * to all the companies that have sponsored the spfug, including intershop, > redhat, six apart, and countless other companies, thanks for your support. > > Ok folks, I'm out, enjoy your sigils- > > m@ > > -- > Matthew D. P. K. Lanier > _______________________________________________ > 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 Mon Mar 5 13:08:33 2012 From: fred at redhotpenguin.com (Fred Moyer) Date: Mon, 5 Mar 2012 13:08:33 -0800 Subject: [sf-perl] Mouse, again? In-Reply-To: References: Message-ID: On Thu, Mar 1, 2012 at 5:08 PM, Joseph Brenner wrote: > By the way: I've thought about it, and concluded that for my purposes > I have no interest in using the wrapper module Any::Moose: by design, > it's a way of using Mouse without committing to it permanently, if it > sees Moose installed it will use that instead. ?That strikes me as a > potentially nasty action-at-a-distance performance bomb I would rather > not inflict on whoever needs to maintain this code. Personally, I'm becoming a big fan of the Any::* modules, especially Any::Moose. Any::* provides loose coupling for your application. If you've worked on an application that tries to use the esoteric features of a module such as Moose (this is an example in name only), and the developer decides to change those 20% features which are the least used, you have a maintenance problem. Plus, while it may take a developer 2 minutes to install Moose on a solid state laptop, it may take sysadmins or release engineers much longer since they are using shared resources. Or production hardware which has test failures in dependent modules, such as 64 bit production environments. Two minutes for a developer can turn into two weeks for a production deployment in larger organizations. I've seriously considered writing Any::ORM to frontend DBIx::Class, Rose::Object, Class::DBI::Sweet (don't use that module for new projects by the way, maintainer here speaking), or any of the other ORMs out there. Some of the faster moving ORMs are not backwards compatible across previous versions, or they have new features which break existing features, or they have intermittently socially unstable development team issues. Any::* is somewhat of an insurance policy against these issues I've mentioned. From quinn at pgexperts.com Mon Mar 5 13:18:18 2012 From: quinn at pgexperts.com (Quinn Weaver) Date: Mon, 5 Mar 2012 13:18:18 -0800 Subject: [sf-perl] Mouse, again? In-Reply-To: References: Message-ID: I haven't used a lot of Any:: modules, except for JSON (where the API is tiny). Is the usual pattern for the Any:: module to implement all of the least common denominator of the underlying modules, or a subset of the LCD, or something else? -- Quinn Weaver PostgreSQL Experts, Inc. http://pgexperts.com/ 1-888-743-9778 (my extension: 510) Sent from my phone; please pardon my brevity. On Mar 5, 2012, at 1:08 PM, Fred Moyer wrote: > On Thu, Mar 1, 2012 at 5:08 PM, Joseph Brenner wrote: >> By the way: I've thought about it, and concluded that for my purposes >> I have no interest in using the wrapper module Any::Moose: by design, >> it's a way of using Mouse without committing to it permanently, if it >> sees Moose installed it will use that instead. That strikes me as a >> potentially nasty action-at-a-distance performance bomb I would rather >> not inflict on whoever needs to maintain this code. > > Personally, I'm becoming a big fan of the Any::* modules, especially > Any::Moose. Any::* provides loose coupling for your application. If > you've worked on an application that tries to use the esoteric > features of a module such as Moose (this is an example in name only), > and the developer decides to change those 20% features which are the > least used, you have a maintenance problem. > > Plus, while it may take a developer 2 minutes to install Moose on a > solid state laptop, it may take sysadmins or release engineers much > longer since they are using shared resources. Or production hardware > which has test failures in dependent modules, such as 64 bit > production environments. Two minutes for a developer can turn into > two weeks for a production deployment in larger organizations. > > I've seriously considered writing Any::ORM to frontend DBIx::Class, > Rose::Object, Class::DBI::Sweet (don't use that module for new > projects by the way, maintainer here speaking), or any of the other > ORMs out there. Some of the faster moving ORMs are not backwards > compatible across previous versions, or they have new features which > break existing features, or they have intermittently socially unstable > development team issues. > > Any::* is somewhat of an insurance policy against these issues I've mentioned. From fred at redhotpenguin.com Mon Mar 5 14:47:45 2012 From: fred at redhotpenguin.com (Fred Moyer) Date: Mon, 5 Mar 2012 14:47:45 -0800 Subject: [sf-perl] Mouse, again? In-Reply-To: References: Message-ID: On Mon, Mar 5, 2012 at 1:18 PM, Quinn Weaver wrote: > I haven't used a lot of Any:: modules, except for JSON (where the API is tiny). Is the usual pattern for the Any:: module to implement all of the least common denominator of the underlying modules, or a subset of the LCD, or something else? I believe the Any:: modules just load modules preferentially in order they are found. For example, I wrote Any::URI::Escape, and it tries to load URI::Escape::XS, and falls back to URI::Escape (pure Perl). http://cpansearch.perl.org/src/PHRED/Any-URI-Escape-0.01/lib/Any/URI/Escape.pm Any::Moose looks like it loads Moose, then Mouse if Moose can't be found: http://cpansearch.perl.org/src/SARTAK/Any-Moose-0.18/lib/Any/Moose.pm So perhaps my Any::ORM theoretical project would be better named Whatever::ORM I see the 'insurance' benefits for ANY:: mostly being development/production platform heterogeneous compatibility. > > On Mar 5, 2012, at 1:08 PM, Fred Moyer wrote: > >> On Thu, Mar 1, 2012 at 5:08 PM, Joseph Brenner wrote: >>> By the way: I've thought about it, and concluded that for my purposes >>> I have no interest in using the wrapper module Any::Moose: by design, >>> it's a way of using Mouse without committing to it permanently, if it >>> sees Moose installed it will use that instead. ?That strikes me as a >>> potentially nasty action-at-a-distance performance bomb I would rather >>> not inflict on whoever needs to maintain this code. >> >> Personally, I'm becoming a big fan of the Any::* modules, especially >> Any::Moose. ?Any::* provides loose coupling for your application. ?If >> you've worked on an application that tries to use the esoteric >> features of a module such as Moose (this is an example in name only), >> and the developer decides to change those 20% features which are the >> least used, you have a maintenance problem. >> >> Plus, while it may take a developer 2 minutes to install Moose on a >> solid state laptop, it may take sysadmins or release engineers much >> longer since they are using shared resources. ?Or production hardware >> which has test failures in dependent modules, such as 64 bit >> production environments. ?Two minutes for a developer can turn into >> two weeks for a production deployment in larger organizations. >> >> I've seriously considered writing Any::ORM to frontend DBIx::Class, >> Rose::Object, Class::DBI::Sweet (don't use that module for new >> projects by the way, maintainer here speaking), or any of the other >> ORMs out there. ?Some of the faster moving ORMs are not backwards >> compatible across previous versions, or they have new features which >> break existing features, or they have intermittently socially unstable >> development team issues. >> >> Any::* is somewhat of an insurance policy against these issues I've mentioned. > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm From doom at kzsu.stanford.edu Mon Mar 5 15:09:44 2012 From: doom at kzsu.stanford.edu (Joseph Brenner) Date: Mon, 5 Mar 2012 15:09:44 -0800 Subject: [sf-perl] Mouse, again? In-Reply-To: References: Message-ID: Fred Moyer wrote: > Any::Moose looks like it loads Moose, then Mouse if Moose can't be found Right, exactly. So if you're writing code intended to be portable to different environments, where you're not sure if Moose or Mouse will be installed, using Any::Moose could be a good idea. The scenario that bothers me is: (a) assume that Moose has some large performance penalty (this may have been exaggerated, but there has to be some or Mouse doesn't make any sense at all). (b) I write a bunch of code that uses Mouse. (c) later, Moose gets installed. Note: the person doing this might not have thought about it very much, it might just be a dependency of something else they're experimenting with. (d) the code that I've written develops some odd performance problems, despite the fact that nothing has apparently changed with it. On Mon, Mar 5, 2012 at 2:47 PM, Fred Moyer wrote: > On Mon, Mar 5, 2012 at 1:18 PM, Quinn Weaver wrote: >> I haven't used a lot of Any:: modules, except for JSON (where the API is tiny). Is the usual pattern for the Any:: module to implement all of the least common denominator of the underlying modules, or a subset of the LCD, or something else? > > I believe the Any:: modules just load modules preferentially in order > they are found. > > For example, I wrote Any::URI::Escape, and it tries to load > URI::Escape::XS, and falls back to URI::Escape (pure Perl). > > http://cpansearch.perl.org/src/PHRED/Any-URI-Escape-0.01/lib/Any/URI/Escape.pm > > Any::Moose looks like it loads Moose, then Mouse if Moose can't be found: > > http://cpansearch.perl.org/src/SARTAK/Any-Moose-0.18/lib/Any/Moose.pm > > > So perhaps my Any::ORM theoretical project would be better named Whatever::ORM > > I see the 'insurance' benefits for ANY:: mostly being > development/production platform heterogeneous compatibility. > > >> >> On Mar 5, 2012, at 1:08 PM, Fred Moyer wrote: >> >>> On Thu, Mar 1, 2012 at 5:08 PM, Joseph Brenner wrote: >>>> By the way: I've thought about it, and concluded that for my purposes >>>> I have no interest in using the wrapper module Any::Moose: by design, >>>> it's a way of using Mouse without committing to it permanently, if it >>>> sees Moose installed it will use that instead. ?That strikes me as a >>>> potentially nasty action-at-a-distance performance bomb I would rather >>>> not inflict on whoever needs to maintain this code. >>> >>> Personally, I'm becoming a big fan of the Any::* modules, especially >>> Any::Moose. ?Any::* provides loose coupling for your application. ?If >>> you've worked on an application that tries to use the esoteric >>> features of a module such as Moose (this is an example in name only), >>> and the developer decides to change those 20% features which are the >>> least used, you have a maintenance problem. >>> >>> Plus, while it may take a developer 2 minutes to install Moose on a >>> solid state laptop, it may take sysadmins or release engineers much >>> longer since they are using shared resources. ?Or production hardware >>> which has test failures in dependent modules, such as 64 bit >>> production environments. ?Two minutes for a developer can turn into >>> two weeks for a production deployment in larger organizations. >>> >>> I've seriously considered writing Any::ORM to frontend DBIx::Class, >>> Rose::Object, Class::DBI::Sweet (don't use that module for new >>> projects by the way, maintainer here speaking), or any of the other >>> ORMs out there. ?Some of the faster moving ORMs are not backwards >>> compatible across previous versions, or they have new features which >>> break existing features, or they have intermittently socially unstable >>> development team issues. >>> >>> Any::* is somewhat of an insurance policy against these issues I've mentioned. >> _______________________________________________ >> SanFrancisco-pm mailing list >> SanFrancisco-pm at pm.org >> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm From not.com at gmail.com Mon Mar 5 15:16:40 2012 From: not.com at gmail.com (yary) Date: Mon, 5 Mar 2012 18:16:40 -0500 Subject: [sf-perl] Mouse, again? In-Reply-To: References: Message-ID: On Mon, Mar 5, 2012 at 6:09 PM, Joseph Brenner wrote: ... > (b) I write a bunch of code that uses Mouse. > > (c) later, Moose gets installed. Note: the person doing this might > not have thought about it very much, it might just be a dependency of > something else they're experimenting with. > > (d) the code that I've written develops some odd performance problems, > despite the fact that nothing has apparently changed with it. "Any::Moose" picks Mouse if it is available, then falls back to Moose. Unless the end user requests Moose. From the docs: "By default, Mouse will be provided to libraries, unless Moose is already loaded -or- explicitly requested by the end-user. The end-user can force the decision of which backend to use by setting the environment variable ANY_MOOSE to be Moose or Mouse. Note that the decision of which backend to use is made only once, so that if Any-Moose picks Mouse, then a third-party library loads Moose, anything else that uses Any-Moose will continue to pick Mouse. So, if you have to use Mouse, please be considerate to the Moose fanboys (like myself!) and use Any-Moose instead. :)" -y From doomvox at gmail.com Mon Mar 5 16:23:42 2012 From: doomvox at gmail.com (Joseph Brenner) Date: Mon, 5 Mar 2012 16:23:42 -0800 Subject: [sf-perl] Mouse, again? In-Reply-To: References: Message-ID: yary wrote: > "Any::Moose" picks Mouse if it is available, then falls back to Moose. Yes, you're right. I just played around with some code (using the perl debugger's "m $object" feature as a probe), and if you have Moose and Mouse both installed, this gets you a Mouse-based object: use Any::Moose; Though this gets you a Moose-based object: use Moose; use Any::Moose; (And interestingly enough, vice-versa throws an error.) So just *installing* Moose isn't enough to suddenly flip the behavior of your Any::Moose code... on the other hand, someone else using your code might see a change if some other code they're using brought in Moose before you did your Any::Moose. This still makes me a bit queasy... and the only thing Any::Moose helps you with is it saves you from the work of manually doing a s/Mouse/Moose/ when you want to upgrade... On Mon, Mar 5, 2012 at 3:16 PM, yary wrote: > On Mon, Mar 5, 2012 at 6:09 PM, Joseph Brenner > wrote: ... >> (b) I write a bunch of code that uses Mouse. >> >> (c) later, Moose gets installed. ?Note: the person doing this might >> not have thought about it very much, it might just be a dependency of >> something else they're experimenting with. >> >> (d) the code that I've written develops some odd performance problems, >> despite the fact that nothing has apparently changed with it. > > > "Any::Moose" picks Mouse if it is available, then falls back to Moose. > Unless the end user requests Moose. From the docs: > > "By default, Mouse will be provided to libraries, unless Moose is > already loaded -or- explicitly requested by the end-user. The end-user > can force the decision of which backend to use by setting the > environment variable ANY_MOOSE to be Moose or Mouse. > > Note that the decision of which backend to use is made only once, so > that if Any-Moose picks Mouse, then a third-party library loads Moose, > anything else that uses Any-Moose will continue to pick Mouse. > > So, if you have to use Mouse, please be considerate to the Moose > fanboys (like myself!) and use Any-Moose instead. :)" > > -y > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm From quinn at pgexperts.com Mon Mar 5 16:25:32 2012 From: quinn at pgexperts.com (Quinn Weaver) Date: Mon, 5 Mar 2012 16:25:32 -0800 Subject: [sf-perl] Mouse, again? In-Reply-To: References: Message-ID: <6804E0DB-D0ED-4FE2-AF0C-4220D7811183@pgexperts.com> On Mar 5, 2012, at 2:47 PM, Fred Moyer wrote: > On Mon, Mar 5, 2012 at 1:18 PM, Quinn Weaver wrote: >> I haven't used a lot of Any:: modules, except for JSON (where the API is tiny). Is the usual pattern for the Any:: module to implement all of the least common denominator of the underlying modules, or a subset of the LCD, or something else? > > I believe the Any:: modules just load modules preferentially in order > they are found. But? RDBO and DBIC have totally different APIs. How would Any::ORM operate without breaking your code? > > For example, I wrote Any::URI::Escape, and it tries to load > URI::Escape::XS, and falls back to URI::Escape (pure Perl). > > http://cpansearch.perl.org/src/PHRED/Any-URI-Escape-0.01/lib/Any/URI/Escape.pm > > Any::Moose looks like it loads Moose, then Mouse if Moose can't be found: > > http://cpansearch.perl.org/src/SARTAK/Any-Moose-0.18/lib/Any/Moose.pm > > > So perhaps my Any::ORM theoretical project would be better named Whatever::ORM > > I see the 'insurance' benefits for ANY:: mostly being > development/production platform heterogeneous compatibility. > > >> >> On Mar 5, 2012, at 1:08 PM, Fred Moyer wrote: >> >>> On Thu, Mar 1, 2012 at 5:08 PM, Joseph Brenner wrote: >>>> By the way: I've thought about it, and concluded that for my purposes >>>> I have no interest in using the wrapper module Any::Moose: by design, >>>> it's a way of using Mouse without committing to it permanently, if it >>>> sees Moose installed it will use that instead. That strikes me as a >>>> potentially nasty action-at-a-distance performance bomb I would rather >>>> not inflict on whoever needs to maintain this code. >>> >>> Personally, I'm becoming a big fan of the Any::* modules, especially >>> Any::Moose. Any::* provides loose coupling for your application. If >>> you've worked on an application that tries to use the esoteric >>> features of a module such as Moose (this is an example in name only), >>> and the developer decides to change those 20% features which are the >>> least used, you have a maintenance problem. >>> >>> Plus, while it may take a developer 2 minutes to install Moose on a >>> solid state laptop, it may take sysadmins or release engineers much >>> longer since they are using shared resources. Or production hardware >>> which has test failures in dependent modules, such as 64 bit >>> production environments. Two minutes for a developer can turn into >>> two weeks for a production deployment in larger organizations. >>> >>> I've seriously considered writing Any::ORM to frontend DBIx::Class, >>> Rose::Object, Class::DBI::Sweet (don't use that module for new >>> projects by the way, maintainer here speaking), or any of the other >>> ORMs out there. Some of the faster moving ORMs are not backwards >>> compatible across previous versions, or they have new features which >>> break existing features, or they have intermittently socially unstable >>> development team issues. >>> >>> Any::* is somewhat of an insurance policy against these issues I've mentioned. >> _______________________________________________ >> SanFrancisco-pm mailing list >> SanFrancisco-pm at pm.org >> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm -- Quinn Weaver PostgreSQL Experts, Inc. http://pgexperts.com/ 1-888-743-9778 (my extension: 510) -------------- next part -------------- An HTML attachment was scrubbed... URL: From doomvox at gmail.com Mon Mar 5 16:32:20 2012 From: doomvox at gmail.com (Joseph Brenner) Date: Mon, 5 Mar 2012 16:32:20 -0800 Subject: [sf-perl] Mouse, again? In-Reply-To: <6804E0DB-D0ED-4FE2-AF0C-4220D7811183@pgexperts.com> References: <6804E0DB-D0ED-4FE2-AF0C-4220D7811183@pgexperts.com> Message-ID: Quinn Weaver wrote: >But? RDBO and DBIC have totally different APIs. How would Any::ORM operate without breaking your code? Obviously, we need an ORMI that provides a consistent interface to any ORM you're interested in using. On Mon, Mar 5, 2012 at 4:25 PM, Quinn Weaver wrote: > On Mar 5, 2012, at 2:47 PM, Fred Moyer wrote: > > On Mon, Mar 5, 2012 at 1:18 PM, Quinn Weaver wrote: > > I haven't used a lot of Any:: modules, except for JSON (where the API is > tiny). Is the usual pattern for the Any:: module to implement all of the > least common denominator of the underlying modules, or a subset of the LCD, > or something else? > > > I believe the Any:: modules just load modules preferentially in order > they are found. > > > But? RDBO and DBIC have totally different APIs. How would Any::ORM operate > without breaking your code? > > > For example, I wrote Any::URI::Escape, and it tries to load > URI::Escape::XS, and falls back to URI::Escape (pure Perl). > > http://cpansearch.perl.org/src/PHRED/Any-URI-Escape-0.01/lib/Any/URI/Escape.pm > > Any::Moose looks like it loads Moose, then Mouse if Moose can't be found: > > http://cpansearch.perl.org/src/SARTAK/Any-Moose-0.18/lib/Any/Moose.pm > > > So perhaps my Any::ORM theoretical project would be better named > Whatever::ORM > > I see the 'insurance' benefits for ANY:: mostly being > development/production platform heterogeneous compatibility. > > > > On Mar 5, 2012, at 1:08 PM, Fred Moyer wrote: > > > On Thu, Mar 1, 2012 at 5:08 PM, Joseph Brenner wrote: > > By the way: I've thought about it, and concluded that for my purposes > > I have no interest in using the wrapper module Any::Moose: by design, > > it's a way of using Mouse without committing to it permanently, if it > > sees Moose installed it will use that instead. ?That strikes me as a > > potentially nasty action-at-a-distance performance bomb I would rather > > not inflict on whoever needs to maintain this code. > > > Personally, I'm becoming a big fan of the Any::* modules, especially > > Any::Moose. ?Any::* provides loose coupling for your application. ?If > > you've worked on an application that tries to use the esoteric > > features of a module such as Moose (this is an example in name only), > > and the developer decides to change those 20% features which are the > > least used, you have a maintenance problem. > > > Plus, while it may take a developer 2 minutes to install Moose on a > > solid state laptop, it may take sysadmins or release engineers much > > longer since they are using shared resources. ?Or production hardware > > which has test failures in dependent modules, such as 64 bit > > production environments. ?Two minutes for a developer can turn into > > two weeks for a production deployment in larger organizations. > > > I've seriously considered writing Any::ORM to frontend DBIx::Class, > > Rose::Object, Class::DBI::Sweet (don't use that module for new > > projects by the way, maintainer here speaking), or any of the other > > ORMs out there. ?Some of the faster moving ORMs are not backwards > > compatible across previous versions, or they have new features which > > break existing features, or they have intermittently socially unstable > > development team issues. > > > Any::* is somewhat of an insurance policy against these issues I've > mentioned. > > _______________________________________________ > > SanFrancisco-pm mailing list > > SanFrancisco-pm at pm.org > > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > > > > -- > Quinn Weaver > PostgreSQL Experts, Inc. > http://pgexperts.com/ > 1-888-743-9778 (my extension: 510) > > > > > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > From fred at redhotpenguin.com Wed Mar 7 14:40:09 2012 From: fred at redhotpenguin.com (Fred Moyer) Date: Wed, 7 Mar 2012 14:40:09 -0800 Subject: [sf-perl] Any::* vs Stable::* [follow up to Mouse/Moose] Message-ID: Following up to the previous thread about Mouse vs Moose, and the Any::* module discussion, I had some new thoughts. There's a quick and dirty Catalyst app I work with which was running on a box that got transitioned to a new environment a few months ago, and that app got moved but not turned on. Today one of the users asked what happened to the app, so I tried to start it up but it needed Catalyst to be installed (the libraries weren't moved). The app was using Catalyst 5.8, but when I used cpanm to install Catalyst, it started installing Catalyst 5.9. Which started installing Moose and company, and in this case it started installing Moose 2. The dependencies are still installing (which is giving me time to write this), and Moose itself took almost 10 minutes to install on this platform. In lieu of setting up a dependency management system such as pinto or carton which would be overkill for this problem, I'm wondering if creating a distribution called Stable::Catalyst would be a good solution. Or perhaps Last::Catalyst. A namespace that installs the previous major version of a module within the last six months to a year, or some other heuristic to identify when major changes occur. Anyway, 30 minutes into it cpanminus is still chugging away install Catalyst 5.9. Having had the chance here to look more in depth at Carton it looks like that might be the right solution for this problem. From hartzell at alerce.com Wed Mar 7 14:53:23 2012 From: hartzell at alerce.com (George Hartzell) Date: Wed, 7 Mar 2012 14:53:23 -0800 Subject: [sf-perl] Any::* vs Stable::* [follow up to Mouse/Moose] In-Reply-To: References: Message-ID: <20311.59107.494622.861041@gargle.gargle.HOWL> Fred Moyer writes: > [...] in this case it started installing > Moose 2. [...] I don't believe that there is anything particularly magical about Moose's "2.0000" release, other than it is the next increment in the progression. To the best of my knowledge, the Moose community does not follow any type of MAJOR.Minor.patch strategy with their release numbers. Does this jibe with others' understandings? g. From swartz at pobox.com Wed Mar 7 14:59:06 2012 From: swartz at pobox.com (Jonathan Swartz) Date: Wed, 7 Mar 2012 14:59:06 -0800 Subject: [sf-perl] Any::* vs Stable::* [follow up to Mouse/Moose] In-Reply-To: References: Message-ID: <83EE14A5-9DDD-41C5-9F8E-E13DB8B98328@pobox.com> Are you running with --notest? Otherwise, 75%-80% of the time is going towards distribution tests that, for your quick and dirty app, is almost certainly extreme overkill (the tests could be run later anyway if you suspect a problem). http://www.openswartz.com/2012/01/31/stop-running-tests-on-install/ (even though I know almost everyone disagrees with me) On Mar 7, 2012, at 2:40 PM, Fred Moyer wrote: > Following up to the previous thread about Mouse vs Moose, and the > Any::* module discussion, I had some new thoughts. There's a quick > and dirty Catalyst app I work with which was running on a box that got > transitioned to a new environment a few months ago, and that app got > moved but not turned on. Today one of the users asked what happened > to the app, so I tried to start it up but it needed Catalyst to be > installed (the libraries weren't moved). > > The app was using Catalyst 5.8, but when I used cpanm to install > Catalyst, it started installing Catalyst 5.9. Which started > installing Moose and company, and in this case it started installing > Moose 2. The dependencies are still installing (which is giving me > time to write this), and Moose itself took almost 10 minutes to > install on this platform. > > In lieu of setting up a dependency management system such as pinto or > carton which would be overkill for this problem, I'm wondering if > creating a distribution called Stable::Catalyst would be a good > solution. Or perhaps Last::Catalyst. A namespace that installs the > previous major version of a module within the last six months to a > year, or some other heuristic to identify when major changes occur. > > Anyway, 30 minutes into it cpanminus is still chugging away install > Catalyst 5.9. Having had the chance here to look more in depth at > Carton it looks like that might be the right solution for this > problem. > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm From fred at redhotpenguin.com Wed Mar 7 15:18:00 2012 From: fred at redhotpenguin.com (Fred Moyer) Date: Wed, 7 Mar 2012 15:18:00 -0800 Subject: [sf-perl] Any::* vs Stable::* [follow up to Mouse/Moose] In-Reply-To: <83EE14A5-9DDD-41C5-9F8E-E13DB8B98328@pobox.com> References: <83EE14A5-9DDD-41C5-9F8E-E13DB8B98328@pobox.com> Message-ID: On Wed, Mar 7, 2012 at 2:59 PM, Jonathan Swartz wrote: > Are you running with --notest? Otherwise, 75%-80% of the time is going towards distribution tests that, for your quick and dirty app, is almost certainly extreme overkill (the tests could be run later anyway if you suspect a problem). I usually do, but this was an updated platform so I ran the tests. Good news is that the app came up with everything working, which is confidence inspiring. > > http://www.openswartz.com/2012/01/31/stop-running-tests-on-install/ > > (even though I know almost everyone disagrees with me) > > On Mar 7, 2012, at 2:40 PM, Fred Moyer wrote: > >> Following up to the previous thread about Mouse vs Moose, and the >> Any::* module discussion, I had some new thoughts. ?There's a quick >> and dirty Catalyst app I work with which was running on a box that got >> transitioned to a new environment a few months ago, and that app got >> moved but not turned on. ?Today one of the users asked what happened >> to the app, so I tried to start it up but it needed Catalyst to be >> installed (the libraries weren't moved). >> >> The app was using Catalyst 5.8, but when I used cpanm to install >> Catalyst, it started installing Catalyst 5.9. ?Which started >> installing Moose and company, and in this case it started installing >> Moose 2. ?The dependencies are still installing (which is giving me >> time to write this), and Moose itself took almost 10 minutes to >> install on this platform. >> >> In lieu of setting up a dependency management system such as pinto or >> carton which would be overkill for this problem, I'm wondering if >> creating a distribution called Stable::Catalyst would be a good >> solution. ?Or perhaps Last::Catalyst. ?A namespace that installs the >> previous major version of a module within the last six months to a >> year, or some other heuristic to identify when major changes occur. >> >> Anyway, 30 minutes into it cpanminus is still chugging away install >> Catalyst 5.9. ?Having had the chance here to look more in depth at >> Carton it looks like that might be the right solution for this >> problem. >> _______________________________________________ >> SanFrancisco-pm mailing list >> SanFrancisco-pm at pm.org >> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > From hartzell at alerce.com Wed Mar 7 15:36:51 2012 From: hartzell at alerce.com (George Hartzell) Date: Wed, 7 Mar 2012 15:36:51 -0800 Subject: [sf-perl] Any::* vs Stable::* [follow up to Mouse/Moose] In-Reply-To: References: Message-ID: <20311.61715.131514.507582@gargle.gargle.HOWL> Fred Moyer writes: > [...] Moose itself took almost 10 minutes to > install on this platform. Just out of curiousity, what is the platform? Someone back in the original thread made a backhanded smack at my "2 minutes to install Moose on my SSD equiped 3 year old laptop" benchmark so I just tried it on my 4 year old spinning-rust Mac Pro. I had 2 installs that finished in 2:20 and 2:30 resp., and three that hung up for > 5 minutes fetching various distributions (the Internet must be maladjusted today...). g. From fred at redhotpenguin.com Wed Mar 7 16:22:04 2012 From: fred at redhotpenguin.com (Fred Moyer) Date: Wed, 7 Mar 2012 16:22:04 -0800 Subject: [sf-perl] Any::* vs Stable::* [follow up to Mouse/Moose] In-Reply-To: <20311.61715.131514.507582@gargle.gargle.HOWL> References: <20311.61715.131514.507582@gargle.gargle.HOWL> Message-ID: On Wed, Mar 7, 2012 at 3:36 PM, George Hartzell wrote: > Fred Moyer writes: > ?> [...] Moose itself took almost 10 minutes to > ?> install on this platform. > > Just out of curiousity, what is the platform? It is a quad core xeon 2.8 p4 running Centos 5.6. It looks like there is a higher than average context switching load going on (~2k) and at least one read blocking process according to vmstat, so it might be a virtual machine (I didn't see a xen kernel though). It is running one active Apache server serving multiple users already. I'm not completely sure of the details though, the sysadmins gave me a login and the box is somewhere offsite. > > Someone back in the original thread made a backhanded smack at my "2 > minutes to install Moose on my SSD equiped 3 year old laptop" > benchmark so I just tried it on my 4 year old spinning-rust Mac Pro. > > I had 2 installs that finished in 2:20 and 2:30 resp., and three that > hung up for > 5 minutes fetching various distributions (the Internet > must be maladjusted today...). > > g. From cpan at goess.org Wed Mar 7 23:55:31 2012 From: cpan at goess.org (Kevin Goess) Date: Thu, 8 Mar 2012 08:55:31 +0100 Subject: [sf-perl] Any::* vs Stable::* [follow up to Mouse/Moose] In-Reply-To: References: <20311.61715.131514.507582@gargle.gargle.HOWL> Message-ID: > It is a quad core xeon 2.8 p4 running Centos 5.6. If you're running Centos, why aren't you installing catalyst from an rpm? That should give you the dependencies, something that's expected to run so you don't need to wait for the unit tests, and a predictable version with no unexpected upgrades. That would be *my* ideal world, where everything across the organization is managed by the native package management system, including in-house software. "Repeatable" is only the second step on the CMM model, but it's still more rare than common. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at imaginative-software.com Thu Mar 8 01:13:30 2012 From: jeff at imaginative-software.com (Jeffrey Thalhammer) Date: Thu, 8 Mar 2012 01:13:30 -0800 Subject: [sf-perl] Any::* vs Stable::* [follow up to Mouse/Moose] In-Reply-To: References: Message-ID: <195B9C02-FFA3-4192-941C-37F4E9EC3A89@imaginative-software.com> On Mar 7, 2012, at 2:40 PM, Fred Moyer wrote: > In lieu of setting up a dependency management system such as pinto or > carton which would be overkill for this problem I disagree. If the "app" is just one distribution (or pile of files) plus dependencies, then carton is a good light-weght solution. If the "app" spans multiple distributions, then you'll need something heavy-duty like pinto (especially if those dists have different release cycles). -Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From fred at redhotpenguin.com Thu Mar 8 05:49:10 2012 From: fred at redhotpenguin.com (Fred Moyer) Date: Thu, 8 Mar 2012 05:49:10 -0800 Subject: [sf-perl] Any::* vs Stable::* [follow up to Mouse/Moose] In-Reply-To: References: <20311.61715.131514.507582@gargle.gargle.HOWL> Message-ID: On Wed, Mar 7, 2012 at 11:55 PM, Kevin Goess wrote: >> It is a quad core xeon 2.8 p4 running Centos 5.6. > > If you're running Centos, why aren't you installing catalyst from an rpm? > That should give you the dependencies, something that's expected to run so > you don't need to wait for the unit tests, and a predictable version with no > unexpected upgrades. I always try to install via rpm when I can, but Catalyst wasn't available via rpm with the repositories setup on that machine for some reason so I used cpanminus. From fred at redhotpenguin.com Thu Mar 8 05:54:42 2012 From: fred at redhotpenguin.com (Fred Moyer) Date: Thu, 8 Mar 2012 05:54:42 -0800 Subject: [sf-perl] Any::* vs Stable::* [follow up to Mouse/Moose] In-Reply-To: <195B9C02-FFA3-4192-941C-37F4E9EC3A89@imaginative-software.com> References: <195B9C02-FFA3-4192-941C-37F4E9EC3A89@imaginative-software.com> Message-ID: On Thu, Mar 8, 2012 at 1:13 AM, Jeffrey Thalhammer wrote: > > On Mar 7, 2012, at 2:40 PM, Fred Moyer wrote: > > In lieu of setting up a dependency management system such as pinto or > carton which would be overkill for this problem > > I disagree. ?If the "app" is just one distribution (or pile of files) plus > dependencies, then carton is a good light-weght solution. This is the solution I would likely use in the future, but I was in one of those situations where the users needed the app back up 'right away' (after not using it for 6 months), so I attempted what I thought was the quickest path to success. It took about 30 minutes from start of perl module installations to login, which I didn't think was too bad. From fred at redhotpenguin.com Sun Mar 11 10:49:45 2012 From: fred at redhotpenguin.com (Fred Moyer) Date: Sun, 11 Mar 2012 10:49:45 -0700 Subject: [sf-perl] 50% off Perl ebooks and videos Message-ID: Saw a tweet that O'Reilly is having a 50% off Perl ebook and video sale until March 16. The books are DRM free. http://shop.oreilly.com/category/deals/perl-programming-power.do From doom at kzsu.stanford.edu Thu Mar 15 07:58:02 2012 From: doom at kzsu.stanford.edu (Joseph Brenner) Date: Thu, 15 Mar 2012 07:58:02 -0700 Subject: [sf-perl] Call for Lightning Message-ID: Lightning talks coming up, next meeting, Tuesday, March 27, 2012. Hit us with your ideas... no idea too small. Mark Jason Dominus on Lightning Talks: http://perl.plover.com/lt/osc2003/lightning-talks.html What can you say in five minutes? Why my favorite module / add-on package is X. I want to do cool project X. Does anyone want to help? Successful Project: I did project X. It was a success. Here's how you could benefit. Failed Project: I did project X. It was a failure, and here's why. Heresy: People always say X, but they're wrong. Here's why. You All Suck: Here's what is wrong with our community. Call to Action: Let's all do more of X / less of X. A Funny Thing happened to me on the Way to the Mailing List / Newsgroup / Web Forum. Wouldn't it be cool if X? Someone needs to do X. Wish List Why X was a mistake. Why X looks like a mistake, but isn't. What it's like to do X. Here's a useful technique that worked. Here's a technique I thought would be useful but didn't work. Why add-on package X sucks. Comparison of similar add-on packages X and Y. Why we should be paying more attention to X. My Favorite Feature On giving Lightning Talks: http://www.perl.com/pub/2004/07/30/lightningtalk.html From fred at redhotpenguin.com Thu Mar 15 08:21:21 2012 From: fred at redhotpenguin.com (Fred Moyer) Date: Thu, 15 Mar 2012 08:21:21 -0700 Subject: [sf-perl] Call for Lightning In-Reply-To: References: Message-ID: Thanks Joe, here's the Meetup link. Location to be announced very soon. http://www.meetup.com/San-Francisco-Perl-Mongers/events/56465502/ I'm in for a lightning talk on Carton. On Thu, Mar 15, 2012 at 7:58 AM, Joseph Brenner wrote: > Lightning talks coming up, next meeting, Tuesday, March 27, 2012. > Hit us with your ideas... no idea too small. > > Mark Jason Dominus on Lightning Talks: > ?http://perl.plover.com/lt/osc2003/lightning-talks.html > > What can you say in five minutes? > > ? ?Why my favorite module / add-on package is X. > ? ?I want to do cool project X. Does anyone want to help? > ? ?Successful Project: I did project X. It was a success. Here's how > you could benefit. > ? ?Failed Project: I did project X. It was a failure, and here's why. > ? ?Heresy: People always say X, but they're wrong. Here's why. > ? ?You All Suck: Here's what is wrong with our community. > ? ?Call to Action: Let's all do more of X / less of X. > ? ?A Funny Thing happened to me on the Way to the Mailing List / > Newsgroup / Web Forum. > ? ?Wouldn't it be cool if X? > ? ?Someone needs to do X. > ? ?Wish List > ? ?Why X was a mistake. > ? ?Why X looks like a mistake, but isn't. > ? ?What it's like to do X. > ? ?Here's a useful technique that worked. > ? ?Here's a technique I thought would be useful but didn't work. > ? ?Why add-on package X sucks. > ? ?Comparison of similar add-on packages X and Y. > ? ?Why we should be paying more attention to X. > ? ?My Favorite Feature > > On giving Lightning Talks: > ?http://www.perl.com/pub/2004/07/30/lightningtalk.html > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm From tomeliaz at gmail.com Thu Mar 15 08:44:40 2012 From: tomeliaz at gmail.com (Tom Eliaz) Date: Thu, 15 Mar 2012 08:44:40 -0700 Subject: [sf-perl] Lightning Talk: WWW::Mixpanel - User and Event Tracking with Mixpanel Message-ID: <2799E401-38F0-4FCE-A052-A57F53E6CCC0@gmail.com> Hi, I'll be happy to give a lightning talk during our next meeting on using WWW::Mixpanel to track users and events with the Mixpanel service. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at fetter.org Thu Mar 15 09:14:42 2012 From: david at fetter.org (David Fetter) Date: Thu, 15 Mar 2012 09:14:42 -0700 Subject: [sf-perl] Call for Lightning In-Reply-To: References: Message-ID: <20120315161441.GA13166@fetter.org> On Thu, Mar 15, 2012 at 07:58:02AM -0700, Joseph Brenner wrote: > Lightning talks coming up, next meeting, Tuesday, March 27, 2012. > Hit us with your ideas... no idea too small. I'm in! Will probably be bringing my offspring, Leo, who usually doesn't sound much like The Offspring. Topic will be on security. Time and slots permitting, I'd like to do one on lightning talks, too :) > Mark Jason Dominus on Lightning Talks: > http://perl.plover.com/lt/osc2003/lightning-talks.html I find the above case disingenuous at best. The lightning structure is one which requires more skill, not less, than the 30-55 minute structure. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter at gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate From fred at redhotpenguin.com Thu Mar 15 17:39:01 2012 From: fred at redhotpenguin.com (Fred Moyer) Date: Thu, 15 Mar 2012 17:39:01 -0700 Subject: [sf-perl] Call for Lightning In-Reply-To: References: Message-ID: We'll be at Mother Jones again this month. If you plan to attend please rsvp by 5pm on the 27th. On Mar 15, 2012 8:21 AM, "Fred Moyer" wrote: > > Thanks Joe, here's the Meetup link. Location to be announced very soon. > > http://www.meetup.com/San-Francisco-Perl-Mongers/events/56465502/ > > I'm in for a lightning talk on Carton. > > On Thu, Mar 15, 2012 at 7:58 AM, Joseph Brenner wrote: > > Lightning talks coming up, next meeting, Tuesday, March 27, 2012. > > Hit us with your ideas... no idea too small. > > > > Mark Jason Dominus on Lightning Talks: > > http://perl.plover.com/lt/osc2003/lightning-talks.html > > > > What can you say in five minutes? > > > > Why my favorite module / add-on package is X. > > I want to do cool project X. Does anyone want to help? > > Successful Project: I did project X. It was a success. Here's how > > you could benefit. > > Failed Project: I did project X. It was a failure, and here's why. > > Heresy: People always say X, but they're wrong. Here's why. > > You All Suck: Here's what is wrong with our community. > > Call to Action: Let's all do more of X / less of X. > > A Funny Thing happened to me on the Way to the Mailing List / > > Newsgroup / Web Forum. > > Wouldn't it be cool if X? > > Someone needs to do X. > > Wish List > > Why X was a mistake. > > Why X looks like a mistake, but isn't. > > What it's like to do X. > > Here's a useful technique that worked. > > Here's a technique I thought would be useful but didn't work. > > Why add-on package X sucks. > > Comparison of similar add-on packages X and Y. > > Why we should be paying more attention to X. > > My Favorite Feature > > > > On giving Lightning Talks: > > http://www.perl.com/pub/2004/07/30/lightningtalk.html > > _______________________________________________ > > 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 Paul.Makepeace at realprogrammers.com Thu Mar 15 17:55:41 2012 From: Paul.Makepeace at realprogrammers.com (Paul Makepeace) Date: Thu, 15 Mar 2012 17:55:41 -0700 Subject: [sf-perl] Call for Lightning In-Reply-To: References: Message-ID: On Thu, Mar 15, 2012 at 07:58, Joseph Brenner wrote: > Hit us with your ideas... no idea too small. I gave a talk to London.pm recently on a bunch of Ruby bits 'n bobs that I could extract into 5 mins, call it "Ruby: Perl's not the only crackhead culture" -- interested? P From doomvox at gmail.com Fri Mar 16 10:22:41 2012 From: doomvox at gmail.com (Joseph Brenner) Date: Fri, 16 Mar 2012 10:22:41 -0700 Subject: [sf-perl] Call for Lightning In-Reply-To: References: Message-ID: Joseph Brenner wrote: > Lightning talks coming up, next meeting, Tuesday, March 27, 2012. > Hit us with your ideas... no idea too small. And by the way, I personally wouldn't take a narrow view of relevance here. There's are talks for perl people, not necessarily "perl talks". Perl people are interested in lots of things... databases, web servers, programmer's tools, other languages, etc. From rdm at cfcl.com Fri Mar 16 20:14:42 2012 From: rdm at cfcl.com (Rich Morin) Date: Fri, 16 Mar 2012 20:14:42 -0700 Subject: [sf-perl] Call for Lightning In-Reply-To: References: Message-ID: On Mar 16, 2012, at 10:22, Joseph Brenner wrote: > And by the way, I personally wouldn't take a narrow view > of relevance here. There's are talks for perl people, not > necessarily "perl talks". Perl people are interested in > lots of things... databases, web servers, programmer's > tools, other languages, etc. In that spirit, I'd like to do a short series of talks: D3 (http://mbostock.github.com/d3) CoffeeScript (http://coffeescript.org) Hive Plots (http://egweb.bcgsc.ca) -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 Tue Mar 20 13:31:57 2012 From: fred at redhotpenguin.com (Fred Moyer) Date: Tue, 20 Mar 2012 13:31:57 -0700 Subject: [sf-perl] [meeting] Lightning Talks next week Message-ID: So far we've got a few speakers lined up for next week's meeting, but could use a few more. Here's the current list of talks. http://www.meetup.com/San-Francisco-Perl-Mongers/events/56465502/ David Fetter david at fetter.org Topics: 1: security 2: lightning Jeffrey Thalhammer jeff at imaginative-software.com Talks: 1 2 Paul Makepeace paul.makepeace at realprogrammers.com Talk: "Ruby: Perl's not the only crackhead culture" Rich Morin rdm at cfcl.com Talks: 1: D3 (http://mbostock.github.com/d3) 2: CoffeeScript (http://coffeescript.org) 3: Hive Plots (http://egweb.bcgsc.ca) Joseph Brenner doom at kzsu.stanford.edu | doomvox at gmail.com Talks: 1: "s{...}{ ... pos() ... }eg;" 2: "Text::Properties" Fred Moyer fred at redhotpenguin.com 1: Carton From doom at kzsu.stanford.edu Tue Mar 20 15:33:09 2012 From: doom at kzsu.stanford.edu (Joseph Brenner) Date: Tue, 20 Mar 2012 15:33:09 -0700 Subject: [sf-perl] [meeting] Lightning Talks next week In-Reply-To: References: Message-ID: And this just in, the titles of David Fetter and Jeffrey Thalhammer's talks: David Vetter 1: "Why Security Sucks (and what to do about it)" 2: "Lightning Talks" Jeffrey Thalhammer 1 "Everything I Know About Software Development" 2 (tentative) Fred Moyer wrote: > So far we've got a few speakers lined up for next week's meeting, but > could use a few more. Here's the current list of talks. > > http://www.meetup.com/San-Francisco-Perl-Mongers/events/56465502/ > > David Fetter > david at fetter.org > Topics: > 1: security > 2: lightning > > Jeffrey Thalhammer > jeff at imaginative-software.com > Talks: > 1 > 2 > > Paul Makepeace > paul.makepeace at realprogrammers.com > Talk: > "Ruby: Perl's not the only crackhead culture" > > Rich Morin > rdm at cfcl.com > Talks: > 1: D3 (http://mbostock.github.com/d3) > 2: CoffeeScript (http://coffeescript.org) > 3: Hive Plots (http://egweb.bcgsc.ca) > > Joseph Brenner > doom at kzsu.stanford.edu | doomvox at gmail.com > Talks: > 1: "s{...}{ ... pos() ... }eg;" > 2: "Text::Properties" > > Fred Moyer > fred at redhotpenguin.com > 1: Carton > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm From doom at kzsu.stanford.edu Tue Mar 20 17:33:46 2012 From: doom at kzsu.stanford.edu (Joseph Brenner) Date: Tue, 20 Mar 2012 17:33:46 -0700 Subject: [sf-perl] [meeting] Lightning Talks next week In-Reply-To: References: Message-ID: Now this is the kind of talk I'd like to see: http://www.wired.com/beyond_the_beyond/ From Paul.Makepeace at realprogrammers.com Tue Mar 20 18:08:34 2012 From: Paul.Makepeace at realprogrammers.com (Paul Makepeace) Date: Tue, 20 Mar 2012 18:08:34 -0700 Subject: [sf-perl] [meeting] Lightning Talks next week In-Reply-To: References: Message-ID: Guessing you meant this one? If not, it's awesome anyway - http://www.wired.com/beyond_the_beyond/2012/03/web-semantics-hacker-humor-veering-into-lovecraftian-nervous-breakdown/ On Tue, Mar 20, 2012 at 17:33, Joseph Brenner wrote: > Now this is the kind of talk I'd like to see: > ?http://www.wired.com/beyond_the_beyond/ > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm From doom at kzsu.stanford.edu Wed Mar 21 07:44:31 2012 From: doom at kzsu.stanford.edu (Joseph Brenner) Date: Wed, 21 Mar 2012 07:44:31 -0700 Subject: [sf-perl] Fwd: [meeting] Lightning Talks next week In-Reply-To: References: Message-ID: Paul Makepeace wrote: > Joseph Brenner wrote: >> Now this is the kind of talk I'd like to see: >> ?http://www.wired.com/beyond_the_beyond/ > Guessing you meant this one? > If not, it's awesome anyway - > http://www.wired.com/beyond_the_beyond/2012/03/web-semantics-hacker-humor-veering-into-lovecraftian-nervous-breakdown/ Correct, that's precisely what I had in mind. From rdm at cfcl.com Wed Mar 21 20:54:46 2012 From: rdm at cfcl.com (Rich Morin) Date: Wed, 21 Mar 2012 20:54:46 -0700 Subject: [sf-perl] pre-meeting dinner/nosh Message-ID: <2EC26FB8-895E-4A59-9240-FAD27E3F54F5@cfcl.com> Vicki & I are planning to stop off for a pre-meeting dinner/nosh: 5:45 - 6:45 pm E&O Trading Co. 314 Sutter Street, SF http://www.eosanfrancisco.com/ Be there or be elsewhere... -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 jeff at imaginative-software.com Mon Mar 26 17:16:41 2012 From: jeff at imaginative-software.com (Jeffrey Thalhammer) Date: Mon, 26 Mar 2012 17:16:41 -0700 Subject: [sf-perl] Slides For My Pinto Presentation Message-ID: <345235B4-7F1D-4400-8672-60CCD3B71112@imaginative-software.com> Hey there- I finally posted the slides from my presentation on Pinto: http://www.slideshare.net/thaljef/pinto-12166763 I hope to see you all at the lightning talks tomorrow! -Jeff From russt at releasetools.org Tue Mar 27 18:22:01 2012 From: russt at releasetools.org (Russ Tremain) Date: Tue, 27 Mar 2012 18:22:01 -0700 Subject: [sf-perl] slides for cado lightning talk Message-ID: I have posted my slides here: http://releasetools.com/cado_slides.pdf see you soon! -Russ From rdm at cfcl.com Wed Mar 28 09:11:51 2012 From: rdm at cfcl.com (Rich Morin) Date: Wed, 28 Mar 2012 09:11:51 -0700 Subject: [sf-perl] slides for my CoffeeScript, D3, and Hive PLot talks Message-ID: <3EA5E1C4-2CA2-4FE3-81BB-739178A2BB95@cfcl.com> This page has some links to information on D3, including links to the slides I used (more or less successfully) last night. http://wiki.cfcl.com/bin/view/Projects/D3/WebHome Each slide set contains additional links which may be useful. Also, feel free to contact me for any problems or questions. -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 doom at kzsu.stanford.edu Wed Mar 28 12:01:31 2012 From: doom at kzsu.stanford.edu (Joseph Brenner) Date: Wed, 28 Mar 2012 12:01:31 -0700 Subject: [sf-perl] "slides" for s{}{ pos }eg and Text::Properties Message-ID: My notes for both of my lightning talks are up here: http://obsidianrook.com/devnotes/talks/rep/TOP.html There's a version of the perl/emacs app I demoed up on CPAN: https://metacpan.org/module/Emacs::Rep Though that one's pretty old, and I'd recommend waiting until I push out 0.8. From david at fetter.org Wed Mar 28 12:12:07 2012 From: david at fetter.org (David Fetter) Date: Wed, 28 Mar 2012 12:12:07 -0700 Subject: [sf-perl] Slides for Threat Modeling and Lightning Talks Message-ID: <20120328191207.GB9742@fetter.org> Folks, Thanks very much for participating, and thanks especially for your forbearance of the extra speaker I brought along. http://www.slideshare.net/davidfetter/threat-modeling-sfperlmongers20130227 http://www.slideshare.net/davidfetter/lightning-sf-perlmongers20120327 Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter at gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate From tomeliaz at gmail.com Sat Mar 31 07:48:10 2012 From: tomeliaz at gmail.com (Tom Eliaz) Date: Sat, 31 Mar 2012 07:48:10 -0700 Subject: [sf-perl] slides for the www::mixpanel lightning talk Message-ID: <0363B92F-F4F8-441D-881B-66F2C7725AAD@gmail.com> Hi folks, Here is a link to the WWW::Mixpanel lightning talk slides: http://tomeliaz.com/share/talks/20120327-sfpm-www-mixpanel-lightning.pdf If anyone wants to talk more about using the module or the service, feel free to send me an email. Thank you, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: