From not.com at gmail.com  Tue Oct  1 07:26:14 2013
From: not.com at gmail.com (yary)
Date: Tue, 1 Oct 2013 10:26:14 -0400
Subject: [sf-perl] Fwd: Delivery Status Notification (Failure)
In-Reply-To: <CAFfgvXXMa2saUyKCJLNcgKLEbu=m=XmTeWjhKDx-HDO7KoHm7A@mail.gmail.com>
References: <CAJMdQC3a-PuhJ9KpoMQ+580daBM7N=5tidQnme9-0GFDC_FnbQ@mail.gmail.com>
	<089e012949207ad3ce04e7a1abd7@google.com>
	<CAJMdQC0Y=ovNJssYFhd66E8F01y91_s4-+D1qTWiikkSgJxwcg@mail.gmail.com>
	<CAFfgvXXMa2saUyKCJLNcgKLEbu=m=XmTeWjhKDx-HDO7KoHm7A@mail.gmail.com>
Message-ID: <CAG2CFAY-5p2+syBrmy36P4jtcU9Gnx4h=VnQZJruwvtuExYvqw@mail.gmail.com>

Been a while since I've done OO perl, but the last time I did on one
of my personal projects, I used separate getters/setters- can't
remember which format. (As for directly accessing href's, I'm
heretical and often use array-refs when rolling my own objects, with
"use constant" for field names. Only makes sense when your object has
a mostly-fixed set of fields. Should look at Obejct::IndsideOut one of
these days.)

I suspect the common use of same setter-getter is due to it being the
default for many modules (like Moose), and not from thoughtful choice!
And I'd also think those modules were influenced by languages that
have function signatures; languages where having the same name for
getter-setter doesn't mean they call the same function because the
arguments- or lack of- change which gets called.
-y


On Mon, Sep 30, 2013 at 9:20 PM, Joseph Brenner <doomvox at gmail.com> wrote:
> I've always agreed with Rolsky: the getter form is far more common, so you
> should optimize for that.
> And I've always agreed with Conway that separate setters and getters were a
> better idea than "mutators", where you use an undef argument to indicate
> when you want to just do a get.
>
> As far as I can tell, pretty much no one agrees with this, they much prefer
> the "convenience" of the short form that does both functions... and they
> tend to add additional methods in order to clear a field and set it to undef
> (yup, that's convenient all right).
>
> But then, where I work at present, most of the code just accesses the href
> directly, which I gather is common at many places (e.g. Yahoo) and I
> wouldn't swear that this is the wrong thing to do: there are decent
> arguments against it, but they're not as strong as some people pretend.
>
> For example: if you use accessors religiously, you then have the power to
> write funny accessors that slip in magical behavior when someone tries to do
> a simple get or set... but I find that when I do that, I tend to confuse
> myself later: there's some odd code buried in a place where I normally
> wouldn't look for it.
>
>
>
>
>
> On Mon, Sep 30, 2013 at 3:55 PM, Kevin Goess <cpan at goess.org> wrote:
>>
>>
>> Back in 2005 Damien wrote his now-famous Perl Best Practices, and
>> recommended separate get_ and set_ methods for accessors.
>>
>> I just now noticed a post by Dave Rolsky (himself no lightweight)
>>
>> http://blog.urth.org/2011/03/23/reviewing-perl-best-practices-chapter-15-objects/where
>> he opines:
>>
>> ---
>> Damian wants you to write get_name() and set_name(). I don?t think this
>> ever took off. My personal preference is name() and set_name(), though
>> that?s just as unpopular.
>>
>> I think the real recommendation should be to use read-only attributes as
>> much as possible. Mutability adds complexity to your code. Avoid it
>> whenever possible.
>>
>> In that context, I?d avoid the get_name() style. Very little Perl code
>> I?ve
>> seen uses that naming scheme. The naming of writers matters less if
>> they?re
>> rare, but readers will be common, and you should just use the style that
>> everyone else uses.
>> ---
>>
>> I've also rarely seen that naming scheme (and don't use it myself), but
>> haven't done an exhaustive survey.
>>
>> Does anyone else have a sense on how widespread the take-up of that
>> particular Best Practice has been?
>>
>>
>> _______________________________________________
>> 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 frimicc at gmail.com  Tue Oct  1 09:41:04 2013
From: frimicc at gmail.com (Michael Friedman)
Date: Tue, 1 Oct 2013 09:41:04 -0700
Subject: [sf-perl] Delivery Status Notification (Failure)
In-Reply-To: <CAG2CFAY-5p2+syBrmy36P4jtcU9Gnx4h=VnQZJruwvtuExYvqw@mail.gmail.com>
References: <CAJMdQC3a-PuhJ9KpoMQ+580daBM7N=5tidQnme9-0GFDC_FnbQ@mail.gmail.com>
	<089e012949207ad3ce04e7a1abd7@google.com>
	<CAJMdQC0Y=ovNJssYFhd66E8F01y91_s4-+D1qTWiikkSgJxwcg@mail.gmail.com>
	<CAFfgvXXMa2saUyKCJLNcgKLEbu=m=XmTeWjhKDx-HDO7KoHm7A@mail.gmail.com>
	<CAG2CFAY-5p2+syBrmy36P4jtcU9Gnx4h=VnQZJruwvtuExYvqw@mail.gmail.com>
Message-ID: <3C10A969-2DAC-42D1-BA5D-B310E1FADD33@gmail.com>

I agree with both of these opinions. In my last job, we had explicit get_title() and set_title() methods, but what we found was that we hardly ever called the set methods -- the values were almost always set when we got the item out of the DB. So optimizing for the get is a much better approach. 

In my current job, we don't do much OO Perl, but when we do we leave the get methods as just field name, title(), and make the set methods have some other name. We don't usually use set_title(), though, because we're setting it a particular way. set_title_from_feed() or set_title_from_clip() and so on, so that we can encapsulate different data-prep behaviors and have the function names be self-documenting. 

-- Mike Friedman

On Oct 1, 2013, at 7:26 AM, yary <not.com at gmail.com> wrote:

> Been a while since I've done OO perl, but the last time I did on one
> of my personal projects, I used separate getters/setters- can't
> remember which format. (As for directly accessing href's, I'm
> heretical and often use array-refs when rolling my own objects, with
> "use constant" for field names. Only makes sense when your object has
> a mostly-fixed set of fields. Should look at Obejct::IndsideOut one of
> these days.)
> 
> I suspect the common use of same setter-getter is due to it being the
> default for many modules (like Moose), and not from thoughtful choice!
> And I'd also think those modules were influenced by languages that
> have function signatures; languages where having the same name for
> getter-setter doesn't mean they call the same function because the
> arguments- or lack of- change which gets called.
> -y
> 
> 
> On Mon, Sep 30, 2013 at 9:20 PM, Joseph Brenner <doomvox at gmail.com> wrote:
>> I've always agreed with Rolsky: the getter form is far more common, so you
>> should optimize for that.
>> And I've always agreed with Conway that separate setters and getters were a
>> better idea than "mutators", where you use an undef argument to indicate
>> when you want to just do a get.
>> 
>> As far as I can tell, pretty much no one agrees with this, they much prefer
>> the "convenience" of the short form that does both functions... and they
>> tend to add additional methods in order to clear a field and set it to undef
>> (yup, that's convenient all right).
>> 
>> But then, where I work at present, most of the code just accesses the href
>> directly, which I gather is common at many places (e.g. Yahoo) and I
>> wouldn't swear that this is the wrong thing to do: there are decent
>> arguments against it, but they're not as strong as some people pretend.
>> 
>> For example: if you use accessors religiously, you then have the power to
>> write funny accessors that slip in magical behavior when someone tries to do
>> a simple get or set... but I find that when I do that, I tend to confuse
>> myself later: there's some odd code buried in a place where I normally
>> wouldn't look for it.
>> 
>> 
>> 
>> 
>> 
>> On Mon, Sep 30, 2013 at 3:55 PM, Kevin Goess <cpan at goess.org> wrote:
>>> 
>>> 
>>> Back in 2005 Damien wrote his now-famous Perl Best Practices, and
>>> recommended separate get_ and set_ methods for accessors.
>>> 
>>> I just now noticed a post by Dave Rolsky (himself no lightweight)
>>> 
>>> http://blog.urth.org/2011/03/23/reviewing-perl-best-practices-chapter-15-objects/where
>>> he opines:
>>> 
>>> ---
>>> Damian wants you to write get_name() and set_name(). I don?t think this
>>> ever took off. My personal preference is name() and set_name(), though
>>> that?s just as unpopular.
>>> 
>>> I think the real recommendation should be to use read-only attributes as
>>> much as possible. Mutability adds complexity to your code. Avoid it
>>> whenever possible.
>>> 
>>> In that context, I?d avoid the get_name() style. Very little Perl code
>>> I?ve
>>> seen uses that naming scheme. The naming of writers matters less if
>>> they?re
>>> rare, but readers will be common, and you should just use the style that
>>> everyone else uses.
>>> ---
>>> 
>>> I've also rarely seen that naming scheme (and don't use it myself), but
>>> haven't done an exhaustive survey.
>>> 
>>> Does anyone else have a sense on how widespread the take-up of that
>>> particular Best Practice has been?
>>> 
>>> 
>>> _______________________________________________
>>> 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
>> 
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm


From earl at ruby.org  Tue Oct  1 12:30:07 2013
From: earl at ruby.org (Earl Ruby)
Date: Tue, 1 Oct 2013 12:30:07 -0700
Subject: [sf-perl] Delivery Status Notification (Failure)
In-Reply-To: <3C10A969-2DAC-42D1-BA5D-B310E1FADD33@gmail.com>
References: <CAJMdQC3a-PuhJ9KpoMQ+580daBM7N=5tidQnme9-0GFDC_FnbQ@mail.gmail.com>
	<089e012949207ad3ce04e7a1abd7@google.com>
	<CAJMdQC0Y=ovNJssYFhd66E8F01y91_s4-+D1qTWiikkSgJxwcg@mail.gmail.com>
	<CAFfgvXXMa2saUyKCJLNcgKLEbu=m=XmTeWjhKDx-HDO7KoHm7A@mail.gmail.com>
	<CAG2CFAY-5p2+syBrmy36P4jtcU9Gnx4h=VnQZJruwvtuExYvqw@mail.gmail.com>
	<3C10A969-2DAC-42D1-BA5D-B310E1FADD33@gmail.com>
Message-ID: <CAPBkEsgPCZCe-81ga8CXCXhWJ4zUV2YVmAUOUbWhB5tVycLCLw@mail.gmail.com>

At my job we auto-generate set_, get_, and validate_ methods for the
attributes of an object. validate_ methods are based on the db
definitions, $self->validate calls all validate_ methods (before
writing to the db -- so we can handle any exceptions), and we use
$self->read_from_db(%args) and $self->write_to_db methods for
retrieving and storing data. We also differentiate between attributes
that are storable vs. in-memory-only. Any method explicitly created in
code is not auto-generated on the fly, so you can override get_, set_
or validate_ methods by simply creating the method in the object's .pm
file.

I've used other libraries that don't use set_ and get_, but I prefer
the separate set_ and get_ methods because you can easily override one
or the other without overriding both, and setting an attribute to
undef is no problem. I also think they make my code more readable.


On Tue, Oct 1, 2013 at 9:41 AM, Michael Friedman <frimicc at gmail.com> wrote:
> I agree with both of these opinions. In my last job, we had explicit get_title() and set_title() methods, but what we found was that we hardly ever called the set methods -- the values were almost always set when we got the item out of the DB. So optimizing for the get is a much better approach.
>
> In my current job, we don't do much OO Perl, but when we do we leave the get methods as just field name, title(), and make the set methods have some other name. We don't usually use set_title(), though, because we're setting it a particular way. set_title_from_feed() or set_title_from_clip() and so on, so that we can encapsulate different data-prep behaviors and have the function names be self-documenting.
>
> -- Mike Friedman
>
> On Oct 1, 2013, at 7:26 AM, yary <not.com at gmail.com> wrote:
>
>> Been a while since I've done OO perl, but the last time I did on one
>> of my personal projects, I used separate getters/setters- can't
>> remember which format. (As for directly accessing href's, I'm
>> heretical and often use array-refs when rolling my own objects, with
>> "use constant" for field names. Only makes sense when your object has
>> a mostly-fixed set of fields. Should look at Obejct::IndsideOut one of
>> these days.)
>>
>> I suspect the common use of same setter-getter is due to it being the
>> default for many modules (like Moose), and not from thoughtful choice!
>> And I'd also think those modules were influenced by languages that
>> have function signatures; languages where having the same name for
>> getter-setter doesn't mean they call the same function because the
>> arguments- or lack of- change which gets called.
>> -y
>>
>>
>> On Mon, Sep 30, 2013 at 9:20 PM, Joseph Brenner <doomvox at gmail.com> wrote:
>>> I've always agreed with Rolsky: the getter form is far more common, so you
>>> should optimize for that.
>>> And I've always agreed with Conway that separate setters and getters were a
>>> better idea than "mutators", where you use an undef argument to indicate
>>> when you want to just do a get.
>>>
>>> As far as I can tell, pretty much no one agrees with this, they much prefer
>>> the "convenience" of the short form that does both functions... and they
>>> tend to add additional methods in order to clear a field and set it to undef
>>> (yup, that's convenient all right).
>>>
>>> But then, where I work at present, most of the code just accesses the href
>>> directly, which I gather is common at many places (e.g. Yahoo) and I
>>> wouldn't swear that this is the wrong thing to do: there are decent
>>> arguments against it, but they're not as strong as some people pretend.
>>>
>>> For example: if you use accessors religiously, you then have the power to
>>> write funny accessors that slip in magical behavior when someone tries to do
>>> a simple get or set... but I find that when I do that, I tend to confuse
>>> myself later: there's some odd code buried in a place where I normally
>>> wouldn't look for it.
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Sep 30, 2013 at 3:55 PM, Kevin Goess <cpan at goess.org> wrote:
>>>>
>>>>
>>>> Back in 2005 Damien wrote his now-famous Perl Best Practices, and
>>>> recommended separate get_ and set_ methods for accessors.
>>>>
>>>> I just now noticed a post by Dave Rolsky (himself no lightweight)
>>>>
>>>> http://blog.urth.org/2011/03/23/reviewing-perl-best-practices-chapter-15-objects/where
>>>> he opines:
>>>>
>>>> ---
>>>> Damian wants you to write get_name() and set_name(). I don?t think this
>>>> ever took off. My personal preference is name() and set_name(), though
>>>> that?s just as unpopular.
>>>>
>>>> I think the real recommendation should be to use read-only attributes as
>>>> much as possible. Mutability adds complexity to your code. Avoid it
>>>> whenever possible.
>>>>
>>>> In that context, I?d avoid the get_name() style. Very little Perl code
>>>> I?ve
>>>> seen uses that naming scheme. The naming of writers matters less if
>>>> they?re
>>>> rare, but readers will be common, and you should just use the style that
>>>> everyone else uses.
>>>> ---
>>>>
>>>> I've also rarely seen that naming scheme (and don't use it myself), but
>>>> haven't done an exhaustive survey.
>>>>
>>>> Does anyone else have a sense on how widespread the take-up of that
>>>> particular Best Practice has been?
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>> _______________________________________________
>> 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



-- 
Earl Ruby
http://earlruby.org/
http://www.linkedin.com/in/earlruby
@earlruby

From maxim4d at gmail.com  Tue Oct  1 12:35:41 2013
From: maxim4d at gmail.com (Maxim Yemelyanov)
Date: Tue, 1 Oct 2013 12:35:41 -0700
Subject: [sf-perl] Delivery Status Notification (Failure)
In-Reply-To: <3C10A969-2DAC-42D1-BA5D-B310E1FADD33@gmail.com>
References: <CAJMdQC3a-PuhJ9KpoMQ+580daBM7N=5tidQnme9-0GFDC_FnbQ@mail.gmail.com>
	<089e012949207ad3ce04e7a1abd7@google.com>
	<CAJMdQC0Y=ovNJssYFhd66E8F01y91_s4-+D1qTWiikkSgJxwcg@mail.gmail.com>
	<CAFfgvXXMa2saUyKCJLNcgKLEbu=m=XmTeWjhKDx-HDO7KoHm7A@mail.gmail.com>
	<CAG2CFAY-5p2+syBrmy36P4jtcU9Gnx4h=VnQZJruwvtuExYvqw@mail.gmail.com>
	<3C10A969-2DAC-42D1-BA5D-B310E1FADD33@gmail.com>
Message-ID: <CACxjE6rA=PEk_ciB=3mUkpYYMRbgtj_CCuDnUj-m6Q9Tn+Lc1g@mail.gmail.com>

We're using Class::Accessor, hence we have

$value = $foo->thing;
$foo->thing($value);

which clearly differentiates the set/get syntax.

- Max


On Tue, Oct 1, 2013 at 9:41 AM, Michael Friedman <frimicc at gmail.com> wrote:

> I agree with both of these opinions. In my last job, we had explicit
> get_title() and set_title() methods, but what we found was that we hardly
> ever called the set methods -- the values were almost always set when we
> got the item out of the DB. So optimizing for the get is a much better
> approach.
>
> In my current job, we don't do much OO Perl, but when we do we leave the
> get methods as just field name, title(), and make the set methods have some
> other name. We don't usually use set_title(), though, because we're setting
> it a particular way. set_title_from_feed() or set_title_from_clip() and so
> on, so that we can encapsulate different data-prep behaviors and have the
> function names be self-documenting.
>
> -- Mike Friedman
>
> On Oct 1, 2013, at 7:26 AM, yary <not.com at gmail.com> wrote:
>
> > Been a while since I've done OO perl, but the last time I did on one
> > of my personal projects, I used separate getters/setters- can't
> > remember which format. (As for directly accessing href's, I'm
> > heretical and often use array-refs when rolling my own objects, with
> > "use constant" for field names. Only makes sense when your object has
> > a mostly-fixed set of fields. Should look at Obejct::IndsideOut one of
> > these days.)
> >
> > I suspect the common use of same setter-getter is due to it being the
> > default for many modules (like Moose), and not from thoughtful choice!
> > And I'd also think those modules were influenced by languages that
> > have function signatures; languages where having the same name for
> > getter-setter doesn't mean they call the same function because the
> > arguments- or lack of- change which gets called.
> > -y
> >
> >
> > On Mon, Sep 30, 2013 at 9:20 PM, Joseph Brenner <doomvox at gmail.com>
> wrote:
> >> I've always agreed with Rolsky: the getter form is far more common, so
> you
> >> should optimize for that.
> >> And I've always agreed with Conway that separate setters and getters
> were a
> >> better idea than "mutators", where you use an undef argument to indicate
> >> when you want to just do a get.
> >>
> >> As far as I can tell, pretty much no one agrees with this, they much
> prefer
> >> the "convenience" of the short form that does both functions... and they
> >> tend to add additional methods in order to clear a field and set it to
> undef
> >> (yup, that's convenient all right).
> >>
> >> But then, where I work at present, most of the code just accesses the
> href
> >> directly, which I gather is common at many places (e.g. Yahoo) and I
> >> wouldn't swear that this is the wrong thing to do: there are decent
> >> arguments against it, but they're not as strong as some people pretend.
> >>
> >> For example: if you use accessors religiously, you then have the power
> to
> >> write funny accessors that slip in magical behavior when someone tries
> to do
> >> a simple get or set... but I find that when I do that, I tend to confuse
> >> myself later: there's some odd code buried in a place where I normally
> >> wouldn't look for it.
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Sep 30, 2013 at 3:55 PM, Kevin Goess <cpan at goess.org> wrote:
> >>>
> >>>
> >>> Back in 2005 Damien wrote his now-famous Perl Best Practices, and
> >>> recommended separate get_ and set_ methods for accessors.
> >>>
> >>> I just now noticed a post by Dave Rolsky (himself no lightweight)
> >>>
> >>>
> http://blog.urth.org/2011/03/23/reviewing-perl-best-practices-chapter-15-objects/where
> >>> he opines:
> >>>
> >>> ---
> >>> Damian wants you to write get_name() and set_name(). I don?t think this
> >>> ever took off. My personal preference is name() and set_name(), though
> >>> that?s just as unpopular.
> >>>
> >>> I think the real recommendation should be to use read-only attributes
> as
> >>> much as possible. Mutability adds complexity to your code. Avoid it
> >>> whenever possible.
> >>>
> >>> In that context, I?d avoid the get_name() style. Very little Perl code
> >>> I?ve
> >>> seen uses that naming scheme. The naming of writers matters less if
> >>> they?re
> >>> rare, but readers will be common, and you should just use the style
> that
> >>> everyone else uses.
> >>> ---
> >>>
> >>> I've also rarely seen that naming scheme (and don't use it myself), but
> >>> haven't done an exhaustive survey.
> >>>
> >>> Does anyone else have a sense on how widespread the take-up of that
> >>> particular Best Practice has been?
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20131001/7c3abb1c/attachment.html>

From doomvox at gmail.com  Tue Oct  1 13:38:08 2013
From: doomvox at gmail.com (Joseph Brenner)
Date: Tue, 1 Oct 2013 13:38:08 -0700
Subject: [sf-perl] Fwd: Delivery Status Notification (Failure)
In-Reply-To: <CAG2CFAY-5p2+syBrmy36P4jtcU9Gnx4h=VnQZJruwvtuExYvqw@mail.gmail.com>
References: <CAJMdQC3a-PuhJ9KpoMQ+580daBM7N=5tidQnme9-0GFDC_FnbQ@mail.gmail.com>
	<089e012949207ad3ce04e7a1abd7@google.com>
	<CAJMdQC0Y=ovNJssYFhd66E8F01y91_s4-+D1qTWiikkSgJxwcg@mail.gmail.com>
	<CAFfgvXXMa2saUyKCJLNcgKLEbu=m=XmTeWjhKDx-HDO7KoHm7A@mail.gmail.com>
	<CAG2CFAY-5p2+syBrmy36P4jtcU9Gnx4h=VnQZJruwvtuExYvqw@mail.gmail.com>
Message-ID: <CAFfgvXUNzs=VJoY+eP_vykjyKa82j6oFpLt9tbJLJPRDPPyJSw@mail.gmail.com>

> Should look at Obejct::IndsideOut one of these days.)

The inside-out object fad seems to have cooled quite a bit.   Objects with
perfect encapsulation sound like a good idea at first, until you realize
that you can't debug them by just doing a

   print Dumper( $obj );

The Moose-heads seem to be winning the day, though party because there are
lighter-weight workalikes around like Mouse and Moo.







On Tue, Oct 1, 2013 at 7:26 AM, yary <not.com at gmail.com> wrote:

> Been a while since I've done OO perl, but the last time I did on one
> of my personal projects, I used separate getters/setters- can't
> remember which format. (As for directly accessing href's, I'm
> heretical and often use array-refs when rolling my own objects, with
> "use constant" for field names. Only makes sense when your object has
> a mostly-fixed set of fields. Should look at Obejct::IndsideOut one of
> these days.)
>
> I suspect the common use of same setter-getter is due to it being the
> default for many modules (like Moose), and not from thoughtful choice!
> And I'd also think those modules were influenced by languages that
> have function signatures; languages where having the same name for
> getter-setter doesn't mean they call the same function because the
> arguments- or lack of- change which gets called.
> -y
>
>
> On Mon, Sep 30, 2013 at 9:20 PM, Joseph Brenner <doomvox at gmail.com> wrote:
> > I've always agreed with Rolsky: the getter form is far more common, so
> you
> > should optimize for that.
> > And I've always agreed with Conway that separate setters and getters
> were a
> > better idea than "mutators", where you use an undef argument to indicate
> > when you want to just do a get.
> >
> > As far as I can tell, pretty much no one agrees with this, they much
> prefer
> > the "convenience" of the short form that does both functions... and they
> > tend to add additional methods in order to clear a field and set it to
> undef
> > (yup, that's convenient all right).
> >
> > But then, where I work at present, most of the code just accesses the
> href
> > directly, which I gather is common at many places (e.g. Yahoo) and I
> > wouldn't swear that this is the wrong thing to do: there are decent
> > arguments against it, but they're not as strong as some people pretend.
> >
> > For example: if you use accessors religiously, you then have the power to
> > write funny accessors that slip in magical behavior when someone tries
> to do
> > a simple get or set... but I find that when I do that, I tend to confuse
> > myself later: there's some odd code buried in a place where I normally
> > wouldn't look for it.
> >
> >
> >
> >
> >
> > On Mon, Sep 30, 2013 at 3:55 PM, Kevin Goess <cpan at goess.org> wrote:
> >>
> >>
> >> Back in 2005 Damien wrote his now-famous Perl Best Practices, and
> >> recommended separate get_ and set_ methods for accessors.
> >>
> >> I just now noticed a post by Dave Rolsky (himself no lightweight)
> >>
> >>
> http://blog.urth.org/2011/03/23/reviewing-perl-best-practices-chapter-15-objects/where
> >> he opines:
> >>
> >> ---
> >> Damian wants you to write get_name() and set_name(). I don?t think this
> >> ever took off. My personal preference is name() and set_name(), though
> >> that?s just as unpopular.
> >>
> >> I think the real recommendation should be to use read-only attributes as
> >> much as possible. Mutability adds complexity to your code. Avoid it
> >> whenever possible.
> >>
> >> In that context, I?d avoid the get_name() style. Very little Perl code
> >> I?ve
> >> seen uses that naming scheme. The naming of writers matters less if
> >> they?re
> >> rare, but readers will be common, and you should just use the style that
> >> everyone else uses.
> >> ---
> >>
> >> I've also rarely seen that naming scheme (and don't use it myself), but
> >> haven't done an exhaustive survey.
> >>
> >> Does anyone else have a sense on how widespread the take-up of that
> >> particular Best Practice has been?
> >>
> >>
> >> _______________________________________________
> >> 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
> >
> _______________________________________________
> 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: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20131001/74ed7d18/attachment-0001.html>

From doomvox at gmail.com  Tue Oct  1 13:47:47 2013
From: doomvox at gmail.com (Joseph Brenner)
Date: Tue, 1 Oct 2013 13:47:47 -0700
Subject: [sf-perl] Delivery Status Notification (Failure)
In-Reply-To: <CACxjE6rA=PEk_ciB=3mUkpYYMRbgtj_CCuDnUj-m6Q9Tn+Lc1g@mail.gmail.com>
References: <CAJMdQC3a-PuhJ9KpoMQ+580daBM7N=5tidQnme9-0GFDC_FnbQ@mail.gmail.com>
	<089e012949207ad3ce04e7a1abd7@google.com>
	<CAJMdQC0Y=ovNJssYFhd66E8F01y91_s4-+D1qTWiikkSgJxwcg@mail.gmail.com>
	<CAFfgvXXMa2saUyKCJLNcgKLEbu=m=XmTeWjhKDx-HDO7KoHm7A@mail.gmail.com>
	<CAG2CFAY-5p2+syBrmy36P4jtcU9Gnx4h=VnQZJruwvtuExYvqw@mail.gmail.com>
	<3C10A969-2DAC-42D1-BA5D-B310E1FADD33@gmail.com>
	<CACxjE6rA=PEk_ciB=3mUkpYYMRbgtj_CCuDnUj-m6Q9Tn+Lc1g@mail.gmail.com>
Message-ID: <CAFfgvXUYbaB3oWqAEDaRSHxCmzjJhpNt0mmwcb260GrTuCGwbg@mail.gmail.com>

> We're using Class::Accessor, hence we have
>
> $value = $foo->thing;
> $foo->thing($value);

And what do you do if $value is undef?

  if( defined( $value ) ) {
    $foo->thing( $value );
  } else {
    $foo->clear_thing;
  }


But I see Class::Accessor these days has hacks built-in to follow Damien's
"Best Practices" if you like, or alternately to mimic Moose behavior.






On Tue, Oct 1, 2013 at 12:35 PM, Maxim Yemelyanov <maxim4d at gmail.com> wrote:

> We're using Class::Accessor, hence we have
>
> $value = $foo->thing;
> $foo->thing($value);
>
> which clearly differentiates the set/get syntax.
>
> - Max
>
>
> On Tue, Oct 1, 2013 at 9:41 AM, Michael Friedman <frimicc at gmail.com>wrote:
>
>> I agree with both of these opinions. In my last job, we had explicit
>> get_title() and set_title() methods, but what we found was that we hardly
>> ever called the set methods -- the values were almost always set when we
>> got the item out of the DB. So optimizing for the get is a much better
>> approach.
>>
>> In my current job, we don't do much OO Perl, but when we do we leave the
>> get methods as just field name, title(), and make the set methods have some
>> other name. We don't usually use set_title(), though, because we're setting
>> it a particular way. set_title_from_feed() or set_title_from_clip() and so
>> on, so that we can encapsulate different data-prep behaviors and have the
>> function names be self-documenting.
>>
>> -- Mike Friedman
>>
>> On Oct 1, 2013, at 7:26 AM, yary <not.com at gmail.com> wrote:
>>
>> > Been a while since I've done OO perl, but the last time I did on one
>> > of my personal projects, I used separate getters/setters- can't
>> > remember which format. (As for directly accessing href's, I'm
>> > heretical and often use array-refs when rolling my own objects, with
>> > "use constant" for field names. Only makes sense when your object has
>> > a mostly-fixed set of fields. Should look at Obejct::IndsideOut one of
>> > these days.)
>> >
>> > I suspect the common use of same setter-getter is due to it being the
>> > default for many modules (like Moose), and not from thoughtful choice!
>> > And I'd also think those modules were influenced by languages that
>> > have function signatures; languages where having the same name for
>> > getter-setter doesn't mean they call the same function because the
>> > arguments- or lack of- change which gets called.
>> > -y
>> >
>> >
>> > On Mon, Sep 30, 2013 at 9:20 PM, Joseph Brenner <doomvox at gmail.com>
>> wrote:
>> >> I've always agreed with Rolsky: the getter form is far more common, so
>> you
>> >> should optimize for that.
>> >> And I've always agreed with Conway that separate setters and getters
>> were a
>> >> better idea than "mutators", where you use an undef argument to
>> indicate
>> >> when you want to just do a get.
>> >>
>> >> As far as I can tell, pretty much no one agrees with this, they much
>> prefer
>> >> the "convenience" of the short form that does both functions... and
>> they
>> >> tend to add additional methods in order to clear a field and set it to
>> undef
>> >> (yup, that's convenient all right).
>> >>
>> >> But then, where I work at present, most of the code just accesses the
>> href
>> >> directly, which I gather is common at many places (e.g. Yahoo) and I
>> >> wouldn't swear that this is the wrong thing to do: there are decent
>> >> arguments against it, but they're not as strong as some people pretend.
>> >>
>> >> For example: if you use accessors religiously, you then have the power
>> to
>> >> write funny accessors that slip in magical behavior when someone tries
>> to do
>> >> a simple get or set... but I find that when I do that, I tend to
>> confuse
>> >> myself later: there's some odd code buried in a place where I normally
>> >> wouldn't look for it.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Mon, Sep 30, 2013 at 3:55 PM, Kevin Goess <cpan at goess.org> wrote:
>> >>>
>> >>>
>> >>> Back in 2005 Damien wrote his now-famous Perl Best Practices, and
>> >>> recommended separate get_ and set_ methods for accessors.
>> >>>
>> >>> I just now noticed a post by Dave Rolsky (himself no lightweight)
>> >>>
>> >>>
>> http://blog.urth.org/2011/03/23/reviewing-perl-best-practices-chapter-15-objects/where
>> >>> he opines:
>> >>>
>> >>> ---
>> >>> Damian wants you to write get_name() and set_name(). I don?t think
>> this
>> >>> ever took off. My personal preference is name() and set_name(), though
>> >>> that?s just as unpopular.
>> >>>
>> >>> I think the real recommendation should be to use read-only attributes
>> as
>> >>> much as possible. Mutability adds complexity to your code. Avoid it
>> >>> whenever possible.
>> >>>
>> >>> In that context, I?d avoid the get_name() style. Very little Perl code
>> >>> I?ve
>> >>> seen uses that naming scheme. The naming of writers matters less if
>> >>> they?re
>> >>> rare, but readers will be common, and you should just use the style
>> that
>> >>> everyone else uses.
>> >>> ---
>> >>>
>> >>> I've also rarely seen that naming scheme (and don't use it myself),
>> but
>> >>> haven't done an exhaustive survey.
>> >>>
>> >>> Does anyone else have a sense on how widespread the take-up of that
>> >>> particular Best Practice has been?
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >>
>> > _______________________________________________
>> > 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
>>
>
>
> _______________________________________________
> 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: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20131001/d4ecf37c/attachment.html>

From fred at redhotpenguin.com  Wed Oct  9 15:47:52 2013
From: fred at redhotpenguin.com (Fred Moyer)
Date: Wed, 9 Oct 2013 15:47:52 -0700
Subject: [sf-perl] Fwd: [pm_groups] NPW 2013 Call for Papers and Participants
In-Reply-To: <EE196C88-A1F1-4624-B0E4-3ADC067427FD@gmail.com>
References: <EE196C88-A1F1-4624-B0E4-3ADC067427FD@gmail.com>
Message-ID: <CAHrynWDXYU_hsZ2a_TOWmRjgKf3VHjr3V6S+NqnD4zbWh_BPVQ@mail.gmail.com>

This is a great workshop if you haven't been.
---------- Forwarded message ----------
From: "Jonas Br?ms? Nielsen" <jonasbn at gmail.com>
Date: Oct 3, 2013 3:40 PM
Subject: [pm_groups] NPW 2013 Call for Papers and Participants
To: "PM Groups" <pm_groups at pm.org>
Cc:

Dear group leaders,

If you feel this is relevant, please pass this on to your groups:

--

Copenhagen Perl Mongers are proud to announce that we will be hosting
the 2013 edition of the Nordic Perl Workshop in Copenhagen, Denmark.

The workshop will take place on Saturday the 23rd. of November, at
DK Hostmaster in central Copenhagen.

We have now opened for registration and submissions of talks on our
website http://act.yapc.eu/npw2013. We encourage anyone interested
in sharing their experiences or ideas, to submit their proposals.

Important deadlines:

   Submission deadline: Monday 4th. of November
   Confirmation: Friday 8th. of November
   Final program available: Friday 8th. of November

All talks are expected to be accepted, notification of non-acceptance
will only be used if we by no means have room for a presentation
or the topic is diverting so much from the other talks that it would
not have relevance for the workshop.

Accepted formats for presentation abstracts:

   Extended Talks (90 minutes)
   Standard Talks (45 minutes)
   Short Talks (20 minutes)
   Lightning Talks (5 minutes)

All topics are of interest, all levels are welcome and talks in
Danish and English are accepted - you do NOT have to be an experienced
presenter, we emphasize participation as an important ingredient
at the workshop.

We expect to end the day in a lightning talk session and the session
is expected to be ad hoc, but if your have something brief on your
mind already, you can submit it now.

More information can be found on the workshop's website:
http://act.yapc.eu/npw2013

The organizers can be contacted at jonasbn at cpan.org.

How To Submit

Create an account (or, if you have attended an Act-powered conference
before, just log in to your existing account) and join the workshop.
You will then be able to submit talks.

When To Submit

As soon as possible! For lightning talks, we will accept submissions
even during the workshop, provided the sessions have not filled up.
They can be a great way to respond to or comment on other talks
that you have seen.

Speaker Benefits

Since this is a community event, we are not able to pay presenters
for their work, but you will have an audience and you will help
making the workshop a success and as a speaker you are ensured one
of those limited seats.

Copenhagen Perl Mongers are looking forward to welcoming speakers
and attendants for a great day of everything and anything Perl!
--
Request pm.org Technical Support via support at pm.org

pm_groups mailing list
pm_groups at pm.org
http://mail.pm.org/mailman/listinfo/pm_groups
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20131009/db453b22/attachment.html>

From fred at redhotpenguin.com  Thu Oct 10 10:10:51 2013
From: fred at redhotpenguin.com (Fred Moyer)
Date: Thu, 10 Oct 2013 10:10:51 -0700
Subject: [sf-perl] Fwd: [oak perl] BALUG Tu 2013-10-15: Elizabeth Krumbach
 Joseph: Code Review for Systems Administrators; & other BALUG News
In-Reply-To: <20131010070415.13377s7mk69xu6z4@webmail.rawbw.com>
References: <20131010070415.13377s7mk69xu6z4@webmail.rawbw.com>
Message-ID: <CAHrynWBPXpDPdeLCpcOYJUR2PqnXFfQErC2gQM9OeApjJsQxag@mail.gmail.com>

Might be of interest to people here.

---------- Forwarded message ----------
From: Michael Paoli <Michael.Paoli at cal.berkeley.edu>
Date: Thu, Oct 10, 2013 at 7:04 AM
Subject: [oak perl] BALUG Tu 2013-10-15: Elizabeth Krumbach Joseph: Code
Review for Systems Administrators; & other BALUG News
To: Oakland Perl Mongers <oakland at pm.org>


BALUG Tu 2013-10-15: Elizabeth Krumbach Joseph: Code Review for Systems
Administrators; & other BALUG News

------------------------------

items, details further below:
2013-10-15: Elizabeth Krumbach Joseph: Code Review for Systems
Administrators
giveaways (CDs/DVDs, book(s), ...)
volunteering to help BALUG (and add to your resume/experience)
Twitter https://twitter.com/#!/BALUG_**org<https://twitter.com/#!/BALUG_org>

------------------------------

For our 2013-10-15 BALUG meeting, we're proud to present:

Elizabeth Krumbach Joseph[1] on Code Review for Systems Administrators

The OpenStack project uses a public code review system
and automated series of unit and integration tests before merging to
confirm that code submitted is adhering to project standards and
doesn't cause problems for other software in the stack.

The OpenStack Infrastructure team not only manages this system using
all open source tools, like Gerrit and Jenkins for review and testing,
but also uses the system themselves for reviewing and testing changes
being made to systems running the infrastructure itself. Puppet
configuration files, Python scripts and more are subjected to
automated syntax tests and then collaboratively reviewed in public by
community and core team members alike before approval.

This talk will give you a walk through of the actual software used to
accomplish this and how this process has allowed the team to have a
considerably open, collaborative approach to systems administration
for the project infrastructure.

Elizabeth Krumbach Joseph is an Automation and Tools Engineer at
HP[2] working on the OpenStack Infrastructure[3] team.  She is also a
member of the Ubuntu Community Council[4] and on the Board of
Directors for Partimus[5], a non-profit in the San Francisco Bay Area
providing Linux-based computers to schools in need.

1. http://www.princessleia.com/
2. http://www.hp.com/
3. http://ci.openstack.org/
4. https://wiki.ubuntu.com/**CommunityCouncil<https://wiki.ubuntu.com/CommunityCouncil>
5. http://partimus.org/

So, if you'd like to join us please RSVP to:

                       rsvp at balug.org

**Why RSVP??**

Well, don't worry we won't turn you away, but the RSVPs really help
BALUG and the Four Seas Restaurant plan the meal and meeting, and with
sufficient attendance, they also help ensure that we'll be able to eat
upstairs in the private banquet room.

Meeting Details...

                       6:30pm
                       Tuesday, October 15th, 2013 2013-10-15

                       Four Seas Restaurant
http://www.fourseasr.com/
                       731 Grant Ave.
                       San Francisco, CA 94108
                       Easy PARKING:
                         Portsmouth Square Garage at 733 Kearny:
                         http://www.sfpsg.com/

Cost: The meetings are always free, but for dinner, for your gift of $13
          cash, we give you a gift of dinner - joining us for a yummy
          family-style Chinese dinner - tax and tip included (your gift
          also helps in our patronizing the restaurant venue).

------------------------------

We typically have various giveaway items at BALUG meetings.  We'll
likely have at least the below plus additional items.

CDs/DVDs/ISOs, etc. - have a peek here:
http://www.wiki.balug.org/**wiki/doku.php?id=balug:cds_**and_images_etc<http://www.wiki.balug.org/wiki/doku.php?id=balug:cds_and_images_etc>
We may also be able to "burn" images per request or copy to USB flash,
etc.  Donations of blank or +-RW media, USB flash, or funding thereof,
also appreciated.  See the above URL for details (and the inventory
(qty.) of what we specifically have "burned" and available on-hand does
also frequently change).

Book(s)!:
Oracle Solaris 11 System Administration
Thanks to Pearson's User Group program for providing these review
copies.  For details see:
http://lists.balug.org/**pipermail/balug-talk-balug.**
org/2013-July/005034.html<http://lists.balug.org/pipermail/balug-talk-balug.org/2013-July/005034.html>
Pearson User Group member page (member discounts: 35% off print,
45% off eBook):
http://www.informit.com/**usergroupwelcome<http://www.informit.com/usergroupwelcome>

------------------------------

volunteering to help BALUG (and add to your resume/experience)

Not only can you do useful and cool stuff volunteering to help BALUG,
but it can also be a way to gain useful and practical experience, and
could also be something to add to or round out one's resume.

There a quite a variety of opportunities to help BALUG.  Come talk to us
at a meeting and/or drop us a note at:
balug-contact at balug.org
These opportunities may include, among other possibilities:
o assist on speaker coordination/procurement, etc.
o assist on publicity
o chief/assistant cat herder
o Linux Systems Administration (e.g. do/assist/learn, with/under some
  quite experienced and skilled Linux systems administrators).
o webmaster, assistant webmaster, designer, graphic artist
o archivist/history/retrieval/**etc.
o and other various/miscellaneous tasks BALUG "ought" to be doing or
  would be good to do (feel free to suggest ideas!)

------------------------------

Twitter - you can also follow BALUG on Twitter:
https://twitter.com/#!/BALUG_**org <https://twitter.com/#!/BALUG_org>

------------------------------

Feedback on our publicity/announcements (e.g. contacts or lists where we
should get our information out that we're not presently reaching, or
things we should do differently): publicity-feedback at balug.org

------------------------------

http://www.balug.org/

______________________________**_________________
Oakland mailing list
Oakland at pm.org
http://mail.pm.org/mailman/**listinfo/oakland<http://mail.pm.org/mailman/listinfo/oakland>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20131010/47be6354/attachment.html>

From sfpm at vmbrasseur.com  Thu Oct 10 10:15:39 2013
From: sfpm at vmbrasseur.com (VM Brasseur)
Date: Thu, 10 Oct 2013 10:15:39 -0700
Subject: [sf-perl] Fwd: [oak perl] BALUG Tu 2013-10-15: Elizabeth
 Krumbach Joseph: Code Review for Systems Administrators; & other BALUG News
In-Reply-To: <CAHrynWBPXpDPdeLCpcOYJUR2PqnXFfQErC2gQM9OeApjJsQxag@mail.gmail.com>
References: <20131010070415.13377s7mk69xu6z4@webmail.rawbw.com>
	<CAHrynWBPXpDPdeLCpcOYJUR2PqnXFfQErC2gQM9OeApjJsQxag@mail.gmail.com>
Message-ID: <5256E0BB.1020709@vmbrasseur.com>

Wait... OAK.pm is still a going concern? Or is it simply that the 
mailing list is still running?

--V

On 10/10/2013 10:10 , Fred Moyer wrote:
> Might be of interest to people here.
>
> ---------- Forwarded message ----------
> From: *Michael Paoli* <Michael.Paoli at cal.berkeley.edu
> <mailto:Michael.Paoli at cal.berkeley.edu>>
> Date: Thu, Oct 10, 2013 at 7:04 AM
> Subject: [oak perl] BALUG Tu 2013-10-15: Elizabeth Krumbach Joseph: Code
> Review for Systems Administrators; & other BALUG News
> To: Oakland Perl Mongers <oakland at pm.org <mailto:oakland at pm.org>>
>
>
> BALUG Tu 2013-10-15: Elizabeth Krumbach Joseph: Code Review for Systems
> Administrators; & other BALUG News
>
> ------------------------------
>
> items, details further below:
> 2013-10-15: Elizabeth Krumbach Joseph: Code Review for Systems
> Administrators
> giveaways (CDs/DVDs, book(s), ...)
> volunteering to help BALUG (and add to your resume/experience)
> Twitter https://twitter.com/#!/BALUG___org
> <https://twitter.com/#!/BALUG_org>
>
> ------------------------------
>
> For our 2013-10-15 BALUG meeting, we're proud to present:
>
> Elizabeth Krumbach Joseph[1] on Code Review for Systems Administrators
>
> The OpenStack project uses a public code review system
> and automated series of unit and integration tests before merging to
> confirm that code submitted is adhering to project standards and
> doesn't cause problems for other software in the stack.
>
> The OpenStack Infrastructure team not only manages this system using
> all open source tools, like Gerrit and Jenkins for review and testing,
> but also uses the system themselves for reviewing and testing changes
> being made to systems running the infrastructure itself. Puppet
> configuration files, Python scripts and more are subjected to
> automated syntax tests and then collaboratively reviewed in public by
> community and core team members alike before approval.
>
> This talk will give you a walk through of the actual software used to
> accomplish this and how this process has allowed the team to have a
> considerably open, collaborative approach to systems administration
> for the project infrastructure.
>
> Elizabeth Krumbach Joseph is an Automation and Tools Engineer at
> HP[2] working on the OpenStack Infrastructure[3] team.  She is also a
> member of the Ubuntu Community Council[4] and on the Board of
> Directors for Partimus[5], a non-profit in the San Francisco Bay Area
> providing Linux-based computers to schools in need.
>
> 1. http://www.princessleia.com/
> 2. http://www.hp.com/
> 3. http://ci.openstack.org/
> 4. https://wiki.ubuntu.com/__CommunityCouncil
> <https://wiki.ubuntu.com/CommunityCouncil>
> 5. http://partimus.org/
>
> So, if you'd like to join us please RSVP to:
>
> rsvp at balug.org <mailto:rsvp at balug.org>
>
> **Why RSVP??**
>
> Well, don't worry we won't turn you away, but the RSVPs really help
> BALUG and the Four Seas Restaurant plan the meal and meeting, and with
> sufficient attendance, they also help ensure that we'll be able to eat
> upstairs in the private banquet room.
>
> Meeting Details...
>
>                         6:30pm
>                         Tuesday, October 15th, 2013 2013-10-15
>
>                         Four Seas Restaurant
> http://www.fourseasr.com/
>                         731 Grant Ave.
>                         San Francisco, CA 94108
>                         Easy PARKING:
>                           Portsmouth Square Garage at 733 Kearny:
> http://www.sfpsg.com/
>
> Cost: The meetings are always free, but for dinner, for your gift of $13
>            cash, we give you a gift of dinner - joining us for a yummy
>            family-style Chinese dinner - tax and tip included (your gift
>            also helps in our patronizing the restaurant venue).
>
> ------------------------------
>
> We typically have various giveaway items at BALUG meetings.  We'll
> likely have at least the below plus additional items.
>
> CDs/DVDs/ISOs, etc. - have a peek here:
> http://www.wiki.balug.org/__wiki/doku.php?id=balug:cds___and_images_etc
> <http://www.wiki.balug.org/wiki/doku.php?id=balug:cds_and_images_etc>
> We may also be able to "burn" images per request or copy to USB flash,
> etc.  Donations of blank or +-RW media, USB flash, or funding thereof,
> also appreciated.  See the above URL for details (and the inventory
> (qty.) of what we specifically have "burned" and available on-hand does
> also frequently change).
>
> Book(s)!:
> Oracle Solaris 11 System Administration
> Thanks to Pearson's User Group program for providing these review
> copies.  For details see:
> http://lists.balug.org/__pipermail/balug-talk-balug.__org/2013-July/005034.html
> <http://lists.balug.org/pipermail/balug-talk-balug.org/2013-July/005034.html>
> Pearson User Group member page (member discounts: 35% off print,
> 45% off eBook):
> http://www.informit.com/__usergroupwelcome
> <http://www.informit.com/usergroupwelcome>
>
> ------------------------------
>
> volunteering to help BALUG (and add to your resume/experience)
>
> Not only can you do useful and cool stuff volunteering to help BALUG,
> but it can also be a way to gain useful and practical experience, and
> could also be something to add to or round out one's resume.
>
> There a quite a variety of opportunities to help BALUG.  Come talk to us
> at a meeting and/or drop us a note at:
> balug-contact at balug.org <mailto:balug-contact at balug.org>
> These opportunities may include, among other possibilities:
> o assist on speaker coordination/procurement, etc.
> o assist on publicity
> o chief/assistant cat herder
> o Linux Systems Administration (e.g. do/assist/learn, with/under some
>    quite experienced and skilled Linux systems administrators).
> o webmaster, assistant webmaster, designer, graphic artist
> o archivist/history/retrieval/__etc.
> o and other various/miscellaneous tasks BALUG "ought" to be doing or
>    would be good to do (feel free to suggest ideas!)
>
> ------------------------------
>
> Twitter - you can also follow BALUG on Twitter:
> https://twitter.com/#!/BALUG___org <https://twitter.com/#!/BALUG_org>
>
> ------------------------------
>
> Feedback on our publicity/announcements (e.g. contacts or lists where we
> should get our information out that we're not presently reaching, or
> things we should do differently): publicity-feedback at balug.org
> <mailto:publicity-feedback at balug.org>
>
> ------------------------------
>
> http://www.balug.org/
>
> _________________________________________________
> Oakland mailing list
> Oakland at pm.org <mailto:Oakland at pm.org>
> http://mail.pm.org/mailman/__listinfo/oakland
> <http://mail.pm.org/mailman/listinfo/oakland>
>
>
>
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>

From fred at redhotpenguin.com  Thu Oct 10 10:17:33 2013
From: fred at redhotpenguin.com (Fred Moyer)
Date: Thu, 10 Oct 2013 10:17:33 -0700
Subject: [sf-perl] Fwd: [oak perl] BALUG Tu 2013-10-15: Elizabeth
 Krumbach Joseph: Code Review for Systems Administrators; & other BALUG News
In-Reply-To: <5256E0BB.1020709@vmbrasseur.com>
References: <20131010070415.13377s7mk69xu6z4@webmail.rawbw.com>
	<CAHrynWBPXpDPdeLCpcOYJUR2PqnXFfQErC2gQM9OeApjJsQxag@mail.gmail.com>
	<5256E0BB.1020709@vmbrasseur.com>
Message-ID: <CAHrynWAqfZsfHoMuA3TnLWvbvVj5hG69KG7BUznmdg5KkrMz-A@mail.gmail.com>

I think it's just the emailing list. These are the only posts I see on it.


On Thu, Oct 10, 2013 at 10:15 AM, VM Brasseur <sfpm at vmbrasseur.com> wrote:

> Wait... OAK.pm is still a going concern? Or is it simply that the mailing
> list is still running?
>
> --V
>
>
> On 10/10/2013 10:10 , Fred Moyer wrote:
>
>> Might be of interest to people here.
>>
>> ---------- Forwarded message ----------
>> From: *Michael Paoli* <Michael.Paoli at cal.berkeley.**edu<Michael.Paoli at cal.berkeley.edu>
>> <mailto:Michael.Paoli at cal.**berkeley.edu <Michael.Paoli at cal.berkeley.edu>
>> >>
>> Date: Thu, Oct 10, 2013 at 7:04 AM
>> Subject: [oak perl] BALUG Tu 2013-10-15: Elizabeth Krumbach Joseph: Code
>> Review for Systems Administrators; & other BALUG News
>> To: Oakland Perl Mongers <oakland at pm.org <mailto:oakland at pm.org>>
>>
>>
>> BALUG Tu 2013-10-15: Elizabeth Krumbach Joseph: Code Review for Systems
>> Administrators; & other BALUG News
>>
>> ------------------------------
>>
>> items, details further below:
>> 2013-10-15: Elizabeth Krumbach Joseph: Code Review for Systems
>> Administrators
>> giveaways (CDs/DVDs, book(s), ...)
>> volunteering to help BALUG (and add to your resume/experience)
>> Twitter https://twitter.com/#!/BALUG__**_org<https://twitter.com/#!/BALUG___org>
>>
>> <https://twitter.com/#!/BALUG_**org <https://twitter.com/#!/BALUG_org>>
>>
>> ------------------------------
>>
>> For our 2013-10-15 BALUG meeting, we're proud to present:
>>
>> Elizabeth Krumbach Joseph[1] on Code Review for Systems Administrators
>>
>> The OpenStack project uses a public code review system
>> and automated series of unit and integration tests before merging to
>> confirm that code submitted is adhering to project standards and
>> doesn't cause problems for other software in the stack.
>>
>> The OpenStack Infrastructure team not only manages this system using
>> all open source tools, like Gerrit and Jenkins for review and testing,
>> but also uses the system themselves for reviewing and testing changes
>> being made to systems running the infrastructure itself. Puppet
>> configuration files, Python scripts and more are subjected to
>> automated syntax tests and then collaboratively reviewed in public by
>> community and core team members alike before approval.
>>
>> This talk will give you a walk through of the actual software used to
>> accomplish this and how this process has allowed the team to have a
>> considerably open, collaborative approach to systems administration
>> for the project infrastructure.
>>
>> Elizabeth Krumbach Joseph is an Automation and Tools Engineer at
>> HP[2] working on the OpenStack Infrastructure[3] team.  She is also a
>> member of the Ubuntu Community Council[4] and on the Board of
>> Directors for Partimus[5], a non-profit in the San Francisco Bay Area
>> providing Linux-based computers to schools in need.
>>
>> 1. http://www.princessleia.com/
>> 2. http://www.hp.com/
>> 3. http://ci.openstack.org/
>> 4. https://wiki.ubuntu.com/__**CommunityCouncil<https://wiki.ubuntu.com/__CommunityCouncil>
>>
>> <https://wiki.ubuntu.com/**CommunityCouncil<https://wiki.ubuntu.com/CommunityCouncil>
>> >
>> 5. http://partimus.org/
>>
>> So, if you'd like to join us please RSVP to:
>>
>> rsvp at balug.org <mailto:rsvp at balug.org>
>>
>>
>> **Why RSVP??**
>>
>> Well, don't worry we won't turn you away, but the RSVPs really help
>> BALUG and the Four Seas Restaurant plan the meal and meeting, and with
>> sufficient attendance, they also help ensure that we'll be able to eat
>> upstairs in the private banquet room.
>>
>> Meeting Details...
>>
>>                         6:30pm
>>                         Tuesday, October 15th, 2013 2013-10-15
>>
>>                         Four Seas Restaurant
>> http://www.fourseasr.com/
>>                         731 Grant Ave.
>>                         San Francisco, CA 94108
>>                         Easy PARKING:
>>                           Portsmouth Square Garage at 733 Kearny:
>> http://www.sfpsg.com/
>>
>> Cost: The meetings are always free, but for dinner, for your gift of $13
>>            cash, we give you a gift of dinner - joining us for a yummy
>>            family-style Chinese dinner - tax and tip included (your gift
>>            also helps in our patronizing the restaurant venue).
>>
>> ------------------------------
>>
>> We typically have various giveaway items at BALUG meetings.  We'll
>> likely have at least the below plus additional items.
>>
>> CDs/DVDs/ISOs, etc. - have a peek here:
>> http://www.wiki.balug.org/__**wiki/doku.php?id=balug:cds___**
>> and_images_etc<http://www.wiki.balug.org/__wiki/doku.php?id=balug:cds___and_images_etc>
>>
>> <http://www.wiki.balug.org/**wiki/doku.php?id=balug:cds_**and_images_etc<http://www.wiki.balug.org/wiki/doku.php?id=balug:cds_and_images_etc>
>> >
>> We may also be able to "burn" images per request or copy to USB flash,
>> etc.  Donations of blank or +-RW media, USB flash, or funding thereof,
>> also appreciated.  See the above URL for details (and the inventory
>> (qty.) of what we specifically have "burned" and available on-hand does
>> also frequently change).
>>
>> Book(s)!:
>> Oracle Solaris 11 System Administration
>> Thanks to Pearson's User Group program for providing these review
>> copies.  For details see:
>> http://lists.balug.org/__**pipermail/balug-talk-balug.__**
>> org/2013-July/005034.html<http://lists.balug.org/__pipermail/balug-talk-balug.__org/2013-July/005034.html>
>>
>> <http://lists.balug.org/**pipermail/balug-talk-balug.**
>> org/2013-July/005034.html<http://lists.balug.org/pipermail/balug-talk-balug.org/2013-July/005034.html>
>> >
>> Pearson User Group member page (member discounts: 35% off print,
>> 45% off eBook):
>> http://www.informit.com/__**usergroupwelcome<http://www.informit.com/__usergroupwelcome>
>>
>> <http://www.informit.com/**usergroupwelcome<http://www.informit.com/usergroupwelcome>
>> >
>>
>> ------------------------------
>>
>> volunteering to help BALUG (and add to your resume/experience)
>>
>> Not only can you do useful and cool stuff volunteering to help BALUG,
>> but it can also be a way to gain useful and practical experience, and
>> could also be something to add to or round out one's resume.
>>
>> There a quite a variety of opportunities to help BALUG.  Come talk to us
>> at a meeting and/or drop us a note at:
>> balug-contact at balug.org <mailto:balug-contact at balug.**org<balug-contact at balug.org>
>> >
>>
>> These opportunities may include, among other possibilities:
>> o assist on speaker coordination/procurement, etc.
>> o assist on publicity
>> o chief/assistant cat herder
>> o Linux Systems Administration (e.g. do/assist/learn, with/under some
>>    quite experienced and skilled Linux systems administrators).
>> o webmaster, assistant webmaster, designer, graphic artist
>> o archivist/history/retrieval/__**etc.
>>
>> o and other various/miscellaneous tasks BALUG "ought" to be doing or
>>    would be good to do (feel free to suggest ideas!)
>>
>> ------------------------------
>>
>> Twitter - you can also follow BALUG on Twitter:
>> https://twitter.com/#!/BALUG__**_org <https://twitter.com/#!/BALUG___org><
>> https://twitter.com/#!/BALUG_**org <https://twitter.com/#!/BALUG_org>>
>>
>>
>> ------------------------------
>>
>> Feedback on our publicity/announcements (e.g. contacts or lists where we
>> should get our information out that we're not presently reaching, or
>> things we should do differently): publicity-feedback at balug.org
>> <mailto:publicity-feedback@**balug.org <publicity-feedback at balug.org>>
>>
>> ------------------------------
>>
>> http://www.balug.org/
>>
>> ______________________________**___________________
>> Oakland mailing list
>> Oakland at pm.org <mailto:Oakland at pm.org>
>> http://mail.pm.org/mailman/__**listinfo/oakland<http://mail.pm.org/mailman/__listinfo/oakland>
>> <http://mail.pm.org/mailman/**listinfo/oakland<http://mail.pm.org/mailman/listinfo/oakland>
>> >
>>
>>
>>
>> ______________________________**_________________
>> SanFrancisco-pm mailing list
>> SanFrancisco-pm at pm.org
>> http://mail.pm.org/mailman/**listinfo/sanfrancisco-pm<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<http://mail.pm.org/mailman/listinfo/sanfrancisco-pm>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20131010/1ae71158/attachment.html>

From david at fetter.org  Thu Oct 10 11:28:41 2013
From: david at fetter.org (David Fetter)
Date: Thu, 10 Oct 2013 11:28:41 -0700
Subject: [sf-perl] Fwd: [oak perl] BALUG Tu 2013-10-15: Elizabeth
 Krumbach Joseph: Code Review for Systems Administrators; & other BALUG News
In-Reply-To: <CAHrynWAqfZsfHoMuA3TnLWvbvVj5hG69KG7BUznmdg5KkrMz-A@mail.gmail.com>
References: <20131010070415.13377s7mk69xu6z4@webmail.rawbw.com>
	<CAHrynWBPXpDPdeLCpcOYJUR2PqnXFfQErC2gQM9OeApjJsQxag@mail.gmail.com>
	<5256E0BB.1020709@vmbrasseur.com>
	<CAHrynWAqfZsfHoMuA3TnLWvbvVj5hG69KG7BUznmdg5KkrMz-A@mail.gmail.com>
Message-ID: <20131010182841.GB3668@fetter.org>

Same here.

Cheers,
David.
On Thu, Oct 10, 2013 at 10:17:33AM -0700, Fred Moyer wrote:
> I think it's just the emailing list. These are the only posts I see on it.
> 
> 
> On Thu, Oct 10, 2013 at 10:15 AM, VM Brasseur <sfpm at vmbrasseur.com> wrote:
> 
> > Wait... OAK.pm is still a going concern? Or is it simply that the mailing
> > list is still running?
> >
> > --V
> >
> >
> > On 10/10/2013 10:10 , Fred Moyer wrote:
> >
> >> Might be of interest to people here.
> >>
> >> ---------- Forwarded message ----------
> >> From: *Michael Paoli* <Michael.Paoli at cal.berkeley.**edu<Michael.Paoli at cal.berkeley.edu>
> >> <mailto:Michael.Paoli at cal.**berkeley.edu <Michael.Paoli at cal.berkeley.edu>
> >> >>
> >> Date: Thu, Oct 10, 2013 at 7:04 AM
> >> Subject: [oak perl] BALUG Tu 2013-10-15: Elizabeth Krumbach Joseph: Code
> >> Review for Systems Administrators; & other BALUG News
> >> To: Oakland Perl Mongers <oakland at pm.org <mailto:oakland at pm.org>>
> >>
> >>
> >> BALUG Tu 2013-10-15: Elizabeth Krumbach Joseph: Code Review for Systems
> >> Administrators; & other BALUG News
> >>
> >> ------------------------------
> >>
> >> items, details further below:
> >> 2013-10-15: Elizabeth Krumbach Joseph: Code Review for Systems
> >> Administrators
> >> giveaways (CDs/DVDs, book(s), ...)
> >> volunteering to help BALUG (and add to your resume/experience)
> >> Twitter https://twitter.com/#!/BALUG__**_org<https://twitter.com/#!/BALUG___org>
> >>
> >> <https://twitter.com/#!/BALUG_**org <https://twitter.com/#!/BALUG_org>>
> >>
> >> ------------------------------
> >>
> >> For our 2013-10-15 BALUG meeting, we're proud to present:
> >>
> >> Elizabeth Krumbach Joseph[1] on Code Review for Systems Administrators
> >>
> >> The OpenStack project uses a public code review system
> >> and automated series of unit and integration tests before merging to
> >> confirm that code submitted is adhering to project standards and
> >> doesn't cause problems for other software in the stack.
> >>
> >> The OpenStack Infrastructure team not only manages this system using
> >> all open source tools, like Gerrit and Jenkins for review and testing,
> >> but also uses the system themselves for reviewing and testing changes
> >> being made to systems running the infrastructure itself. Puppet
> >> configuration files, Python scripts and more are subjected to
> >> automated syntax tests and then collaboratively reviewed in public by
> >> community and core team members alike before approval.
> >>
> >> This talk will give you a walk through of the actual software used to
> >> accomplish this and how this process has allowed the team to have a
> >> considerably open, collaborative approach to systems administration
> >> for the project infrastructure.
> >>
> >> Elizabeth Krumbach Joseph is an Automation and Tools Engineer at
> >> HP[2] working on the OpenStack Infrastructure[3] team.  She is also a
> >> member of the Ubuntu Community Council[4] and on the Board of
> >> Directors for Partimus[5], a non-profit in the San Francisco Bay Area
> >> providing Linux-based computers to schools in need.
> >>
> >> 1. http://www.princessleia.com/
> >> 2. http://www.hp.com/
> >> 3. http://ci.openstack.org/
> >> 4. https://wiki.ubuntu.com/__**CommunityCouncil<https://wiki.ubuntu.com/__CommunityCouncil>
> >>
> >> <https://wiki.ubuntu.com/**CommunityCouncil<https://wiki.ubuntu.com/CommunityCouncil>
> >> >
> >> 5. http://partimus.org/
> >>
> >> So, if you'd like to join us please RSVP to:
> >>
> >> rsvp at balug.org <mailto:rsvp at balug.org>
> >>
> >>
> >> **Why RSVP??**
> >>
> >> Well, don't worry we won't turn you away, but the RSVPs really help
> >> BALUG and the Four Seas Restaurant plan the meal and meeting, and with
> >> sufficient attendance, they also help ensure that we'll be able to eat
> >> upstairs in the private banquet room.
> >>
> >> Meeting Details...
> >>
> >>                         6:30pm
> >>                         Tuesday, October 15th, 2013 2013-10-15
> >>
> >>                         Four Seas Restaurant
> >> http://www.fourseasr.com/
> >>                         731 Grant Ave.
> >>                         San Francisco, CA 94108
> >>                         Easy PARKING:
> >>                           Portsmouth Square Garage at 733 Kearny:
> >> http://www.sfpsg.com/
> >>
> >> Cost: The meetings are always free, but for dinner, for your gift of $13
> >>            cash, we give you a gift of dinner - joining us for a yummy
> >>            family-style Chinese dinner - tax and tip included (your gift
> >>            also helps in our patronizing the restaurant venue).
> >>
> >> ------------------------------
> >>
> >> We typically have various giveaway items at BALUG meetings.  We'll
> >> likely have at least the below plus additional items.
> >>
> >> CDs/DVDs/ISOs, etc. - have a peek here:
> >> http://www.wiki.balug.org/__**wiki/doku.php?id=balug:cds___**
> >> and_images_etc<http://www.wiki.balug.org/__wiki/doku.php?id=balug:cds___and_images_etc>
> >>
> >> <http://www.wiki.balug.org/**wiki/doku.php?id=balug:cds_**and_images_etc<http://www.wiki.balug.org/wiki/doku.php?id=balug:cds_and_images_etc>
> >> >
> >> We may also be able to "burn" images per request or copy to USB flash,
> >> etc.  Donations of blank or +-RW media, USB flash, or funding thereof,
> >> also appreciated.  See the above URL for details (and the inventory
> >> (qty.) of what we specifically have "burned" and available on-hand does
> >> also frequently change).
> >>
> >> Book(s)!:
> >> Oracle Solaris 11 System Administration
> >> Thanks to Pearson's User Group program for providing these review
> >> copies.  For details see:
> >> http://lists.balug.org/__**pipermail/balug-talk-balug.__**
> >> org/2013-July/005034.html<http://lists.balug.org/__pipermail/balug-talk-balug.__org/2013-July/005034.html>
> >>
> >> <http://lists.balug.org/**pipermail/balug-talk-balug.**
> >> org/2013-July/005034.html<http://lists.balug.org/pipermail/balug-talk-balug.org/2013-July/005034.html>
> >> >
> >> Pearson User Group member page (member discounts: 35% off print,
> >> 45% off eBook):
> >> http://www.informit.com/__**usergroupwelcome<http://www.informit.com/__usergroupwelcome>
> >>
> >> <http://www.informit.com/**usergroupwelcome<http://www.informit.com/usergroupwelcome>
> >> >
> >>
> >> ------------------------------
> >>
> >> volunteering to help BALUG (and add to your resume/experience)
> >>
> >> Not only can you do useful and cool stuff volunteering to help BALUG,
> >> but it can also be a way to gain useful and practical experience, and
> >> could also be something to add to or round out one's resume.
> >>
> >> There a quite a variety of opportunities to help BALUG.  Come talk to us
> >> at a meeting and/or drop us a note at:
> >> balug-contact at balug.org <mailto:balug-contact at balug.**org<balug-contact at balug.org>
> >> >
> >>
> >> These opportunities may include, among other possibilities:
> >> o assist on speaker coordination/procurement, etc.
> >> o assist on publicity
> >> o chief/assistant cat herder
> >> o Linux Systems Administration (e.g. do/assist/learn, with/under some
> >>    quite experienced and skilled Linux systems administrators).
> >> o webmaster, assistant webmaster, designer, graphic artist
> >> o archivist/history/retrieval/__**etc.
> >>
> >> o and other various/miscellaneous tasks BALUG "ought" to be doing or
> >>    would be good to do (feel free to suggest ideas!)
> >>
> >> ------------------------------
> >>
> >> Twitter - you can also follow BALUG on Twitter:
> >> https://twitter.com/#!/BALUG__**_org <https://twitter.com/#!/BALUG___org><
> >> https://twitter.com/#!/BALUG_**org <https://twitter.com/#!/BALUG_org>>
> >>
> >>
> >> ------------------------------
> >>
> >> Feedback on our publicity/announcements (e.g. contacts or lists where we
> >> should get our information out that we're not presently reaching, or
> >> things we should do differently): publicity-feedback at balug.org
> >> <mailto:publicity-feedback@**balug.org <publicity-feedback at balug.org>>
> >>
> >> ------------------------------
> >>
> >> http://www.balug.org/
> >>
> >> ______________________________**___________________
> >> Oakland mailing list
> >> Oakland at pm.org <mailto:Oakland at pm.org>
> >> http://mail.pm.org/mailman/__**listinfo/oakland<http://mail.pm.org/mailman/__listinfo/oakland>
> >> <http://mail.pm.org/mailman/**listinfo/oakland<http://mail.pm.org/mailman/listinfo/oakland>
> >> >
> >>
> >>
> >>
> >> ______________________________**_________________
> >> SanFrancisco-pm mailing list
> >> SanFrancisco-pm at pm.org
> >> http://mail.pm.org/mailman/**listinfo/sanfrancisco-pm<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<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


-- 
David Fetter <david at fetter.org> 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 sfpm at vmbrasseur.com  Wed Oct 16 15:54:10 2013
From: sfpm at vmbrasseur.com (VM Brasseur)
Date: Wed, 16 Oct 2013 15:54:10 -0700
Subject: [sf-perl] We have a new sponsor: Shutterstock!
Message-ID: <525F1912.2070601@vmbrasseur.com>

Shutterstock[0] has offered to sponsor the drinks for our October event. 
This is particularly generous as October's event is one of the largest 
we've ever had, with all RSVPs claimed and a wait list over 30 people 
deep. That Duke can really pack 'em in. :-)

In addition to Shutterstock's generosity, we can't forget that of both 
Obsidian Rook and GeekdomSF. Obsidian Rook will be keeping us well fed 
that evening, for which we're eternally grateful. As well, none of this 
would have been possible without the HUGE space which GeekdomSF offered 
us[1]. This is the first time we've worked together and I'm really 
excited about this event as well as what our mutual future now holds.

I hope you'll be able to join us next Tuesday! Don't hesitate to write 
if you've any questions about what's turning into the must-attend event 
of the season.

Allons y!

--V


[0] Have I mentioned they're hiring? In SF and elsewhere? Check it out: 
http://www.shutterstock.com/jobs.mhtml
[1] Special thanks to Josh Berkus for the introduction to GeekdomSF!

From fred at redhotpenguin.com  Mon Oct 21 19:39:23 2013
From: fred at redhotpenguin.com (Fred Moyer)
Date: Mon, 21 Oct 2013 19:39:23 -0700
Subject: [sf-perl] YAPC::NA 2014 call for speakers
Message-ID: <CAHrynWBGJJwUWF9b-iRdEcCqSDkwUoRU-c7OGRKejJSU=yQptQ@mail.gmail.com>

YAPC::NA 2014 is in Orlando in 2014.

http://blogs.perl.org/users/shadowcat_mdk/2013/10/yapc-na-call-for-speakers.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20131021/1fd60008/attachment.html>

From sfpm at vmbrasseur.com  Tue Oct 22 12:25:14 2013
From: sfpm at vmbrasseur.com (VM Brasseur)
Date: Tue, 22 Oct 2013 12:25:14 -0700
Subject: [sf-perl] Super Secret Squirrel tip for listserv subscribers
Message-ID: <5266D11A.8010000@vmbrasseur.com>

Only for those who subscribe to the mailing list, since we're obviously 
the most devoted SF.pm members and therefore really keen people. :-)

The tip: The venue for tonight's event does NOT check the RSVP list.

Are you waitlisted? Not RSVP'd yet? Didn't think you'd be able to make 
it because of the (now canceled) BART strike? Feel free to drop by. No 
one will turn you away and everyone will be glad to see you.

Especially me. Because you're awesome. Yes, YOU.

1;

--V
   @vmbrasseur
   http://vmbrasseur.com