From Paul.Makepeace at realprogrammers.com  Sun May  1 15:10:37 2011
From: Paul.Makepeace at realprogrammers.com (Paul Makepeace)
Date: Sun, 1 May 2011 23:10:37 +0100
Subject: [sf-perl] last night's meeting
In-Reply-To: <20110430180045.GA22408@fetter.org>
References: <BANLkTi=po1kE_g=ZFcF=5oeRGGDfCFQk-w@mail.gmail.com>
	<BANLkTinvSVvvAcm8tf7B===zWVTFpkmi9Q@mail.gmail.com>
	<20110430180045.GA22408@fetter.org>
Message-ID: <BANLkTimGC=QVFx_ReuSsZhyvhdNx3qD0bw@mail.gmail.com>

On Sat, Apr 30, 2011 at 19:00, David Fetter <david at fetter.org> wrote:
> On Sat, Apr 30, 2011 at 03:12:19AM +0100, Paul Makepeace wrote:
>> On Thu, Apr 28, 2011 at 00:58, Joseph Brenner <doom at kzsu.stanford.edu> wrote:
>> > I was reading some criticism of jquery recently, by Rebecca
>> > Murphey, who essentially argues that it's DOM-centric view of the
>> > world isn't that well suited to real applications (great for
>> > simple stuff, but too hard to get it to do complex stuff):
>> >
>> > ?http://www.dagolden.com/index.php/1446/is-javascript-the-new-perl/
>>
>> Is it just me or is this essentially just saying "mediocre
>> programmers write mediocre code" (regardless of what language)? I
>> don't see how anything jQuery has done has any influence on her
>> argument. What am I missing?
>>
>> I have seen complex apps made out of jQuery that are comprehensible
>> & maintainable so I'm not even convinced of the premise.
>
> The sad reality is that there aren't all that many excellent
> programmers around, and there are few incentives to actually train up
> excellent programmers. ?It takes about a decade under excellent
> tutelage to turn a decent one into an excellent one, and "decade"
> isn't a thing many businesses have incentives to plan for.

Yep, agreed there. I was more puzzled that the source of the apparent
poor code or whatever was something jQuery was doing or not doing.

Paul

From matt at lanier.org  Mon May  2 12:52:35 2011
From: matt at lanier.org (Matthew Lanier)
Date: Mon, 2 May 2011 12:52:35 -0700 (PDT)
Subject: [sf-perl] [job] Polyvore
Message-ID: <alpine.LRH.2.02.1105021251220.9174@aurora.cloudfactory.org>


i'm happy where i am, some of you may be interested in this.  if so, 
contact info is below.  this is indeed a perl job.

m@

---------- Forwarded message ----------
Date: Mon, 2 May 2011 14:41:34 -0500
From: John Schmocker <john at rivierapartners.com>
To: Matt Lanier <matt at lanier.org>
Subject: Following Up - Polyvore

Hi Matt,
?
Thanks for taking the time to speak with me, below is the job description along with a few pitch points about Polyvore.
?
Points:
?
Founded by engineers
Flat engineering structure (CEO codes)
Over 6 million in funding, and profitable as of late 2009
Growing exponentially, and currently around 8 million uniques a month.
Backend is build out in Perl with cassandra and mysql
?
Job Description:
?

About this Job
As the lead for Polyvore's infrastructure and scalability efforts, you'll be responsible for improving our scalability and performance. You will own the architecture, design and implementation of our infrastructure. You'll
troubleshoot scalability and performance issues that may involve hardware, software, applications and network. You will take part in a on-call rotation.

About You
You love building systems that scale. You believe that performance is not only a feature, but one of the most important one for a website. You are metrics-driven and can see the big picture of a system and come up with practical
solutions on an end-to-end basis. You work well in a cross-functional environment and are able to engage in discussions with your peers to gather technical, operational, and business requirements. As a well-rounded software
engineer, you have the following attributes:

  *  Strong customer orientation, both internally and externally
  *  Strategic thinking both technically and business-wise
  *  Personal drive to achieve world-class software development
  *  Desire to work in a fast-paced, evolving, growing, dynamic environment
  *  Love of technical challenges and a sense of pride in solving them

Requirements

  *  BS or MS in Computer Science or equivalent
  *  Substantial experience developing large-scale websites
  *  Expert knowledge of MySQL, Apache, Squid, nginx, memcached
  *  Deep conceptual understanding of scalability, performance, and availability
  *  Authorization to work in the United States
?
?

John Schmocker

290 King Street, Suite 9 | San Francisco, CA | 94107

Direct: 415.848.9227 | Mobile: 310.218.2524 | eFax: 650.319.1007

Riviera Partners | www.rivierapartners.com

This e-mail is a confidential correspondence intended only for the recipient. If you are not the intended recipient, please notify the sender immediately by return e-mail and then delete the e-mail and any attachments or copies from
your system. Any further distribution or dissemination is strictly prohibited. Unless otherwise stated, opinions expressed in this e-mail are those of the author and are not necessarily endorsed by Riviera Partners.

?



File #556D731F0C2F207B?
?

From szabgab at gmail.com  Tue May  3 08:22:05 2011
From: szabgab at gmail.com (Gabor Szabo)
Date: Tue, 3 May 2011 18:22:05 +0300
Subject: [sf-perl] [poll] What Perl IDE do you use?
In-Reply-To: <92438CFD-6F5E-49B3-87F9-98962D7E8A22@highwire.stanford.edu>
References: <BANLkTimtnGNsRfw=cqCzFB3TULx9q45_oA@mail.gmail.com>
	<BANLkTimLMoeyWKmfMN5NTR67F5C4+VxUAQ@mail.gmail.com>
	<92438CFD-6F5E-49B3-87F9-98962D7E8A22@highwire.stanford.edu>
Message-ID: <BANLkTikNiNTcTKtg2MY-UFrSogQh8utfkw@mail.gmail.com>

On Sat, Apr 16, 2011 at 8:23 AM, Michael Friedman
<friedman at highwire.stanford.edu> wrote:

> It's interesting to me that, except for UltraEdit (who might be accused of stuffing the ballot box in 2009), the percentages and order are about the same on both polls, a year apart.
>
> Does that show that we're all set in our ways and don't change editors very often or does it show that there are only a few really good editors out there and all the "new guys" are just wandering around the edges? My guess would be some of both: you find an editor you like and then you spend the next 3 months customizing it and learning it well so you can be highly productive. That is a serious incentive to not switch unless the new editor is much much better. It'd be like having to learn how to drive all over again if you bought a Ford instead of a Toyota -- not many people would switch brands.
> Which brings me to a further question for the group: how much have you customized your editor?
>

When I ran the poll I got a lot of comments. People were complaining
that I mashed together vi and vim while they are a world apart and the
"other" field was also filled with new names.

I also posted a link to the poll on LinkedIn where too I got a lot of
comments. Even months after the poll was already closed.

I think many people, especially in the open source community, are very
attached to their editor.
They get very emotional about it. It might be on par with language
preferences and tab/space preferences.

I would offer a third explanation to your observation. Both the poll
and the survey were very biased to the open source Perl community. I
think the "industry people" were represented a lot less. Either
because they don't care or because we have not managed to reach them.

I believe that the "involved people" would spend a lot more time on
configuring their development environment to their liking (including
the editor) while the "9-5 people" would do a lot less.
The latter expect to have an environment already tailored to the task.

In the case of Padre, that would be programming in Perl.

So with Padre I am not really expecting the "hard core" people to
switch to it but I hope some of them will realize building an
environment that can be easily installed and easily used by people who
do not yet have an environment setup is good for the Perl world.
Specifically I heard from a number of hard-core Perl developers
sentences along this one:
"I won't use Padre but I'd recommend it to my (less experienced) co-workers."

I would love to give a presentation about Padre on one of the SF.pm
meetings but unfortunately
I just missed the last one by 2 hours and now I am already back in my
home country.

In any case I had fun in San Francisco :) I'd recommend the Rocketboat
http://www.rocketboatsf.com/
to anyone. Especially on a windy day.

regards
   Gabor
   ps. I personally use Padre and (g)vim

From josh at agliodbs.com  Thu May  5 12:47:41 2011
From: josh at agliodbs.com (Josh Berkus)
Date: Thu, 05 May 2011 12:47:41 -0700
Subject: [sf-perl] [job] Excel guru wanted for open data project
Message-ID: <4DC2FEDD.509@agliodbs.com>

We're looking for someone who lives and breathes Microsoft Excel to
detangle a large collection of worksheets and work it into a more
generalizable format for publication as part of an environmental open
data project.  We're talking 5-6 years of data collected willy-nilly
into 120 worksheets and held together with links, formulas, and duct
tape. The ideal candidate will be:

* An expert in Excel 10
* Able to consolidate the worksheets down to a single workbook.
* Able to downgrade the worksheet to Excel 97 format
* Able to convert the worksheet to OpenOffice.org or Gnumeric and fix
the breakage
* Available to complete this task before June 15th.
* Has experience and interest in the publication of open data

The ideal candidate will also be within easy driving distance of Santa
Barbara, or at least somewhere in the LA, San Francisco, or Portland areas.

Compensation is negotiable, and is consistent with the expertise and the
deadline pressure.


-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

From fred at redhotpenguin.com  Fri May  6 11:28:32 2011
From: fred at redhotpenguin.com (Fred Moyer)
Date: Fri, 6 May 2011 11:28:32 -0700
Subject: [sf-perl] [meeting] PSGI on DotCloud
Message-ID: <BANLkTinLNtVmc5eFSWEcAzaP8sQtrkqQ3g@mail.gmail.com>

Our May meeting will be hosted at Mother Jones on Tuesday May 24th and
feature Tatsuhiko Miyagawa speaking on deploying PSGI apps on
DotCloud.

DotCloud is a second generation Platform-as-a-service provider with
multiple languages and databases support. DotCloud recently shipped
Perl stack with PSGI web application support. Tatsuhiko Miyagawa, who
works for the company as a software engineer, explains how to develop
your PSGI based web applications and deploy it to DotCloud.

RSVP at Meetup -
http://www.meetup.com/San-Francisco-Perl-Mongers/events/17570183

DotCloud - http://www.dotcloud.com

Miyagawa on CPAN - http://search.cpan.org/~miyagawa/

Miyagawa's blog - http://bulknews.typepad.com/

Announcement posted via App::PM::Announce

From fred at redhotpenguin.com  Tue May 10 21:04:19 2011
From: fred at redhotpenguin.com (Fred Moyer)
Date: Tue, 10 May 2011 21:04:19 -0700
Subject: [sf-perl] Perl 5.8 legacy soon
Message-ID: <BANLkTimzUudaSMLOXEHXUJx5RaJ2b2OZ_A@mail.gmail.com>

It looks like 5.8 will be considered legacy and 5.10 will be end of
lifed when 5.14 is released soonish.

http://code.activestate.com/lists/perl5-porters/162498/

From fred at redhotpenguin.com  Tue May 10 21:41:43 2011
From: fred at redhotpenguin.com (Fred Moyer)
Date: Tue, 10 May 2011 21:41:43 -0700
Subject: [sf-perl] DPAN?
Message-ID: <BANLkTin3K=Si5b0z1VntQi10ck5UxD3zaA@mail.gmail.com>

Has anyone here used DPAN and can share their experience?

http://search.cpan.org/~bdfoy/MyCPAN-App-DPAN-1.28_11/lib/UserManual.pm

From greg at blekko.com  Tue May 10 22:25:55 2011
From: greg at blekko.com (Greg Lindahl)
Date: Tue, 10 May 2011 22:25:55 -0700
Subject: [sf-perl] Perl 5.8 legacy soon
In-Reply-To: <BANLkTimzUudaSMLOXEHXUJx5RaJ2b2OZ_A@mail.gmail.com>
References: <BANLkTimzUudaSMLOXEHXUJx5RaJ2b2OZ_A@mail.gmail.com>
Message-ID: <20110511052554.GA20453@bx9.net>

On Tue, May 10, 2011 at 09:04:19PM -0700, Fred Moyer wrote:

> It looks like 5.8 will be considered legacy and 5.10 will be end of
> lifed when 5.14 is released soonish.

Unfortunately the enterprise distros are a bit farther behind than one
would want. RHEL 6 shipped with 5.10, for example.

-- greg


From friedman at highwire.stanford.edu  Tue May 10 22:31:38 2011
From: friedman at highwire.stanford.edu (Michael Friedman)
Date: Tue, 10 May 2011 22:31:38 -0700
Subject: [sf-perl] Perl 5.8 legacy soon
In-Reply-To: <20110511052554.GA20453@bx9.net>
References: <BANLkTimzUudaSMLOXEHXUJx5RaJ2b2OZ_A@mail.gmail.com>
	<20110511052554.GA20453@bx9.net>
Message-ID: <FDEC2A01-5EA0-44DE-9480-88763DED010A@highwire.stanford.edu>

See also: http://www.modernperlbooks.com/mt/2011/05/2018-is-the-year-of-perl-510.html

End-of-life for software support (luckily) doesn't mean it stops working right away. Otherwise the Perl 5.6 that's still running on one of my company's systems would be utterly worthless. As it is, it's still marginally useful, which is why no one will spend the time to upgrade that system. 

Sometimes it'd be nice if old versions actually *would* stop working. Then you'd have the proper incentive to upgrade...

-- Mike
______________________________________________________________________________
Mike Friedman | HighWire Press, Stanford Univ | friedman at highwire.stanford.edu

On May 10, 2011, at 10:25 PM, Greg Lindahl wrote:

> On Tue, May 10, 2011 at 09:04:19PM -0700, Fred Moyer wrote:
> 
>> It looks like 5.8 will be considered legacy and 5.10 will be end of
>> lifed when 5.14 is released soonish.
> 
> Unfortunately the enterprise distros are a bit farther behind than one
> would want. RHEL 6 shipped with 5.10, for example.
> 
> -- greg
> 
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm


From matt at lanier.org  Tue May 10 22:46:47 2011
From: matt at lanier.org (Matthew Lanier)
Date: Tue, 10 May 2011 22:46:47 -0700 (PDT)
Subject: [sf-perl] DPAN?
In-Reply-To: <BANLkTin3K=Si5b0z1VntQi10ck5UxD3zaA@mail.gmail.com>
References: <BANLkTin3K=Si5b0z1VntQi10ck5UxD3zaA@mail.gmail.com>
Message-ID: <alpine.LRH.2.02.1105102244450.9174@aurora.cloudfactory.org>

yes-

i played around with DPAN a bit recently.  the goal was to create an 
internal mirror of cpan + some extra private modules.  i found that mcpani 
(http://search.cpan.org/dist/CPAN-Mini-Inject/bin/mcpani) was an easier 
package to work with for that particular use case.

m@


On Tue, 
10 May 2011, Fred Moyer wrote:

> Has anyone here used DPAN and can share their experience?
>
> http://search.cpan.org/~bdfoy/MyCPAN-App-DPAN-1.28_11/lib/UserManual.pm
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>

From fred at redhotpenguin.com  Wed May 11 13:37:14 2011
From: fred at redhotpenguin.com (Fred Moyer)
Date: Wed, 11 May 2011 13:37:14 -0700
Subject: [sf-perl] Third party Perl rpms for enterprise Linux distros
Message-ID: <BANLkTi=BdB5-V3ysvQ4ycxwKLx5RiYVZnA@mail.gmail.com>

A repeating theme that I have been seeing with enterprise scale perl
applications is that deploying rpm based versions of Perl modules in
production environments has several problems that seem to remain
unsolved.

For instance, if you are running a Centos/Fedora production
environment, and your application depends on a certain version of
DBIx::Class (used as an example), the following events may happen:

1) An update to that module version may become available which is
incompatible with the version of DBIx::Class that your application is
tested with.

2) If you use CPAN, perlbrew, or cpanminus to install a specific
version of a module, it may cause compatibility issues with modules
installed via yum or rpm (this has been documented publicly by the
Fedora Perl module maintainer).

3) If you need to make a slight change to a module which is installed
as an rpm, that may cause problems as well.

4) Updating a module may break another part of the system which
depended on a specific version, and now you have a broken Linux box.

In addition, there is the consideration that Fedora/Centos ships a
threaded version of Perl as the system perl binary, and that can be
10-25% slower than a non-threaded version (from benchmarks I have
run).

My thinking has gotten me to the point where I believe that installing
a separate perl binary in /opt or somewhere else can solve all of
these problems.  However, building a perl rpm takes some elbow grease,
and additionally one would need a set of rpms built against that
binary that could be managed via yum/rpm.  ActiveState offers their
ppm based modules as an alternative solution, but from what I have
read their set of architectures and support is somewhat limited - you
can't roll a newer ppm version of a module if you really need it.

Has anyone seen a good solution to this problem?  The Ovid module on
CPAN has some rpm generation functionality one can work with, but it
seems that having a non-system perl rpm is needed as a prerequisite.

From quinn at fairpath.com  Wed May 11 14:40:06 2011
From: quinn at fairpath.com (Quinn Weaver)
Date: Wed, 11 May 2011 14:40:06 -0700
Subject: [sf-perl] Perl 5.8 legacy soon
In-Reply-To: <BANLkTimzUudaSMLOXEHXUJx5RaJ2b2OZ_A@mail.gmail.com>
References: <BANLkTimzUudaSMLOXEHXUJx5RaJ2b2OZ_A@mail.gmail.com>
Message-ID: <BANLkTim6D8J4YA0VDpY=YQKC+DSef0qv+Q@mail.gmail.com>

On Tue, May 10, 2011 at 9:04 PM, Fred Moyer <fred at redhotpenguin.com> wrote:
> It looks like 5.8 will be considered legacy and 5.10 will be end of
> lifed when 5.14 is released soonish.

I think it's fantastic that the Perl team has finally started keeping
an explicit contract with users about which versions will be
supported. It means you can use old versions with confidence, and you
can know in advance when to plan migrations (though they've always
been painless for me). Also, it gives programmers another solid
argument they can make to management for moving off of problematically
old Perls.

PostgreSQL has been enforcing this kind of contract for years. My
colleague (and former SF Perl Monger) David E. Wheeler deserves at
least some of the credit for convincing the Perl core team to do the
same. Kudos!

PS: to get around the problem of OSes shipping with old Perls, I
prefer Ubuntu, which provides multiple packages (e.g. a Perl 5.12
package, a Perl 5.14 package, et cetera) that can happily coexist.

When I'm working with a client who uses RHEL (or CentOS, or the like),
and they need something newer than the distro provides, I usually
offer to compile Perl by hand. It's not ideal, and I do wish Red Hat
would use more up-to-date packages and/or become less popular, but
you've got to work with what you have. Compiling by hand lets you make
appropriate choices about features like -Dusemultiplicity and
-Dusrshrplib (both for use with PostgreSQL's PL/Perl) that random
packages from rpmfind.net may or may not make.

-- 
Quinn Weaver Consulting, LLC
Full-stack web design and development
http://quinnweaver.com/
510-520-5217

From fred at redhotpenguin.com  Wed May 11 15:20:59 2011
From: fred at redhotpenguin.com (Fred Moyer)
Date: Wed, 11 May 2011 15:20:59 -0700
Subject: [sf-perl] Third party Perl rpms for enterprise Linux distros
In-Reply-To: <BANLkTin_t=TP5qUNQ4Kj3QaXPTYP_vn5fQ@mail.gmail.com>
References: <BANLkTi=BdB5-V3ysvQ4ycxwKLx5RiYVZnA@mail.gmail.com>
	<BANLkTin_t=TP5qUNQ4Kj3QaXPTYP_vn5fQ@mail.gmail.com>
Message-ID: <BANLkTimKo3wToJGdMOWuR1s+kNgRgLFJRw@mail.gmail.com>

On Wed, May 11, 2011 at 2:14 PM, Joseph Brenner <doomvox at gmail.com> wrote:
> Slightly longer: ?I believe one of the selling points of
> Module::Install was that it would let you package up all your
> dependencies in one easily portable package,

That sounds enough like the purported portability of Java that it
makes me skeptical.

> Long-winded editorial: I think that this is a reflection of a general
> problem with version management that the linux distros haven't really
> confronted: you don't always want just one version of something, in
> fact you often want to have multiple versions available (if only for

I'm not necessarily after being able to have multiple versions of Perl
modules available, just a second 'application' install of perl as
opposed to the system installed perl.  Using the system perl brings up
many problems that cannot be easily solved.

Imagine if we were working on a Python application, and used the
system python binary for running applications.  Upgrades to the system
python binary and associated modules would certainly wreak havoc on
yum and the many other system level tools that use python.  So perhaps
we have it somewhat easier by working with Perl in that the other
applications used by the Linux distro aren't as dependent on Perl.

> (1) I suspect that Fred is right that to be perfectly bullet-proof
> about this one would need to create a custom package to install a
> particular perl binary, but I agree that that's a pain... and I'm not
> sure it's a necessary pain. ?Wouldn't it be easier to test against a
> half-dozen or so major perl versions so you don't need to worry about
> the system binary?

Perhaps it would be easier, but what I'm after here is decoupling the
dependencies between the system perl modules and modules needed by the
application.  To do that completely, you need a second perl binary
which is used only by your application.  Packaging that into an rpm is
painful, but it is only painful once per Centos/Fedora release.

> (2) When you start worrying about the versions of various modules
> you're using, I think you get into a combinatoric explosion that makes
> it very difficult to test all possibilities before shipping. ? I would

I'm only worried about the versions in their interaction with system
Perl modules.  Say the Fedora Perl maintainer updates JSON from 1.4 to
2.x (an example from memory).  It has been tested with applications
that ship with Fedora, but breaks your application.  This upgrade is
done by your IT department because there was a security update
released.  Does anyone from IT notice this detail and check with
development before hand?  Probably not in most cases, as the problem
has not yet manifested itself, and preventative checks such as this
can be too numerous and ephemeral to be practical.

It looks like ActiveState comes closest to what I'm looking for here
(found out they do have rpms), but their implementation seems to
target a wide variety of platforms (windows, os x, solaris, linux) at
the cost of having a lot of recent modules available.

This is assuming of course that most people running multi server Perl
applications are using Fedora / Centos / RHEL.  I think that is a
pretty good bet though.

From friedman at highwire.stanford.edu  Wed May 11 16:28:57 2011
From: friedman at highwire.stanford.edu (Michael Friedman)
Date: Wed, 11 May 2011 16:28:57 -0700
Subject: [sf-perl] Third party Perl rpms for enterprise Linux distros
In-Reply-To: <BANLkTi=BdB5-V3ysvQ4ycxwKLx5RiYVZnA@mail.gmail.com>
References: <BANLkTi=BdB5-V3ysvQ4ycxwKLx5RiYVZnA@mail.gmail.com>
Message-ID: <969BB4F9-159E-4AF9-B6DB-82465B6063B0@highwire.stanford.edu>

Fred,

My office has run into this often. What we ended up doing, finally, is creating a master configuration for an entire server using cfengine, and then cloning it into a VM, and then running that on a RHEL machine. This adds a couple of layers of indirection, but we're not CPU-bound anyway. 

Benefits of this approach for us:
1. We install our own copy of perl and any CPAN modules once, on the master.
2. Because we're only running virtualized servers, we can control exactly what the VM thinks it has: CPU, Memory, Disk, etc. Each and every one is an exact duplicate, so they all work the same way.
3. Running one VM per server doesn't suck away much performance.
4. Running in a VM isolates us from anything the IT group might do to the server itself.
5. cfengine has a way of updating clones that it has created, so when we install a new CPAN module in the master copy it gets distributed out to all the clones automatically. (Or so I hear -- I don't know if we've tested this yet.)
6. You install things once and then can use them on dozens of servers.
7. Bringing up a new machine is really fast. If it can boot, we just copy the VM to it and fire it up, pre-configured.

Downsides:
a. We've got a guy who is working nearly full-time on making cfengine work, defining what goes into the master copy, etc.
b. Virtualization does slow things down a bit. We're IO-bound, though, so the VM is more than fast enough for us.
c. This works best when you're talking dozens of machines. It's overkill for just a few.

In the end, though, it's just a big wrapper around "don't use the system perl, install your own copy". I think it makes that prospect a bit easier to maintain, though.

-- Mike
______________________________________________________________________________
Mike Friedman | HighWire Press, Stanford Univ | friedman at highwire.stanford.edu

On May 11, 2011, at 1:37 PM, Fred Moyer wrote:

> A repeating theme that I have been seeing with enterprise scale perl
> applications is that deploying rpm based versions of Perl modules in
> production environments has several problems that seem to remain
> unsolved.
> 
> For instance, if you are running a Centos/Fedora production
> environment, and your application depends on a certain version of
> DBIx::Class (used as an example), the following events may happen:
> 
> 1) An update to that module version may become available which is
> incompatible with the version of DBIx::Class that your application is
> tested with.
> 
> 2) If you use CPAN, perlbrew, or cpanminus to install a specific
> version of a module, it may cause compatibility issues with modules
> installed via yum or rpm (this has been documented publicly by the
> Fedora Perl module maintainer).
> 
> 3) If you need to make a slight change to a module which is installed
> as an rpm, that may cause problems as well.
> 
> 4) Updating a module may break another part of the system which
> depended on a specific version, and now you have a broken Linux box.
> 
> In addition, there is the consideration that Fedora/Centos ships a
> threaded version of Perl as the system perl binary, and that can be
> 10-25% slower than a non-threaded version (from benchmarks I have
> run).
> 
> My thinking has gotten me to the point where I believe that installing
> a separate perl binary in /opt or somewhere else can solve all of
> these problems.  However, building a perl rpm takes some elbow grease,
> and additionally one would need a set of rpms built against that
> binary that could be managed via yum/rpm.  ActiveState offers their
> ppm based modules as an alternative solution, but from what I have
> read their set of architectures and support is somewhat limited - you
> can't roll a newer ppm version of a module if you really need it.
> 
> Has anyone seen a good solution to this problem?  The Ovid module on
> CPAN has some rpm generation functionality one can work with, but it
> seems that having a non-system perl rpm is needed as a prerequisite.
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm


From Paul.Makepeace at realprogrammers.com  Wed May 11 17:25:56 2011
From: Paul.Makepeace at realprogrammers.com (Paul Makepeace)
Date: Thu, 12 May 2011 01:25:56 +0100
Subject: [sf-perl] Third party Perl rpms for enterprise Linux distros
In-Reply-To: <BANLkTimKo3wToJGdMOWuR1s+kNgRgLFJRw@mail.gmail.com>
References: <BANLkTi=BdB5-V3ysvQ4ycxwKLx5RiYVZnA@mail.gmail.com>
	<BANLkTin_t=TP5qUNQ4Kj3QaXPTYP_vn5fQ@mail.gmail.com>
	<BANLkTimKo3wToJGdMOWuR1s+kNgRgLFJRw@mail.gmail.com>
Message-ID: <BANLkTinoygifhmL4S=Atr0jb1mHsqDLA_w@mail.gmail.com>

On Wed, May 11, 2011 at 23:20, Fred Moyer <fred at redhotpenguin.com> wrote:
> Imagine if we were working on a Python application, and used the
> system python binary for running applications. ?Upgrades to the system
> python binary and associated modules would certainly wreak havoc on
> yum and the many other system level tools that use python.

Python has something call virtualenv,
http://www.virtualenv.org/en/latest/#what-it-does

"virtualenv is a tool to create isolated Python environments.

The basic problem being addressed is one of dependencies and versions,
and indirectly permissions. Imagine you have an application that needs
version 1 of LibFoo, but another application requires version 2. How
can you use both these applications? If you install everything into
/usr/lib/python2.7/site-packages (or whatever your platform?s standard
location is), it?s easy to end up in a situation where you
unintentionally upgrade an application that shouldn?t be upgraded."

What's neat here is that it installs 'pip' too which is somewhat
equivalent to cpan shell.

Messing with the system perl is definitely a recipe for pain.

I agree with Michael F & think there's a lot to be said for using VMs.
If I look back at the hassle of getting my app dev setup working on my
Mac versus running VirtualBox & Ubuntu... Another nice aspect of VMs
is taking a snapshot, doing stuff to some database running on it, then
rolling back. This is usually quicker than doing a dump & restore!

Paul

From cpan at goess.org  Thu May 12 08:29:56 2011
From: cpan at goess.org (Kevin M. Goess)
Date: Thu, 12 May 2011 08:29:56 -0700
Subject: [sf-perl] Third party Perl rpms for enterprise Linux distros
In-Reply-To: <BANLkTi=BdB5-V3ysvQ4ycxwKLx5RiYVZnA@mail.gmail.com>
References: <BANLkTi=BdB5-V3ysvQ4ycxwKLx5RiYVZnA@mail.gmail.com>
Message-ID: <9EE7C86E-5DE4-4D96-BCD4-515A24A44797@goess.org>


On May 11, 2011, at 1:37 PM, Fred Moyer wrote:

> A repeating theme that I have been seeing with enterprise scale perl
> applications is that deploying rpm based versions of Perl modules in
> production environments has several problems that seem to remain
> unsolved.

I would say an enterprise scale perl application shouldn't depend on the system Perl libraries at all, it should install the versions it depends on in its own location using the same mechanism that the application itself is installed by.  Because otherwise, yes, if the OS decides to upgrade Foo::Bar to something that's incompatible with your app, then you're screwed.  Same as if your app upgrades Foo::Bar to something that's incompatible with an OS application.  You have to keep them separate.

Yes, it is more work, but at the scale of "enterprise" it's a drop in the bucket, and the payoff is worth it.

cpan2rpm is very helpful if you're in the land of RedHat/Centos.

You don't *necessarily* need a non-system perl binary to do that.  You can add /my/application/libraries onto the end of PERL5LIB or use local::lib or whatever.  But an enterprise-scale application should really be able to spare the resources to build and maintain its own Perl.


--
Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510) 525-5217





From cweyl at alumni.drew.edu  Thu May 12 10:15:10 2011
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Thu, 12 May 2011 10:15:10 -0700
Subject: [sf-perl] Third party Perl rpms for enterprise Linux distros
In-Reply-To: <BANLkTi=BdB5-V3ysvQ4ycxwKLx5RiYVZnA@mail.gmail.com>
References: <BANLkTi=BdB5-V3ysvQ4ycxwKLx5RiYVZnA@mail.gmail.com>
Message-ID: <BANLkTim5bBsStZRQ6T_9Rb2jpZHnkm0v9g@mail.gmail.com>

On Wed, May 11, 2011 at 1:37 PM, Fred Moyer <fred at redhotpenguin.com> wrote:

> A repeating theme that I have been seeing with enterprise scale perl
> applications is that deploying rpm based versions of Perl modules in
> production environments has several problems that seem to remain
> unsolved.
>

This does come up quite a bit: at my last, current, and next employer, even
:)  Some of the problems here are distro/rpm, some are Perl/CPAN.

Distro problems (from a developer perspective, not meant to be exhaustive):

* no control over how perl is built
* CPAN packages installed outside of RPM to the system perl site shoot RPM
metadata dependency to heck
* dependent packages are not retested when a newer package is built (aka: no
smoke testing) (e.g. perl-Moose is upgraded, but perl-MooseX-* aren't
retested)
* RPM's automatic Perl metadata generation is geared towards the system perl
only (resulting in spurious metadata if not disabled and an independent Perl
package is built)

CPAN problems:

* versioning only specifies a lower bound (e.g. currently not possible to
specify "won't work with Moose > 1.99")

I do[1] a bit of work with Fedora's Perl SIG, as well as in-house for our
servers.  On the Fedora side I've introduced RPM dependency filtering (for
cleaner RPM metadata) and automatic "-tests" subpackages to provide a way,
post-build, to test the installed package.  To date, only the dependency
filtering code has really taken off; I haven't had the time to drive the
-tests subpackages the way I want.

At $work, I've taken to building independent Perl RPMs: put them somewhere
convenient (e.g. %global _prefix /usr/perls/5.xx.yy),  disable metadata
generation, etc.  This works, and is pretty straight-forward, but then what
to do with CPAN packages?  Do we build and install one-by-one as we do in
Fedora, or do we try to cluster them in larger RPMs?  How do we handle
dependency metadata in a way that 1) works(!), 2) doesn't conflict with the
system perl, and 3) makes sense?  How can we take advantage of the (very)
large number of CPAN RPMs already created over in Fedora?

I've also started tinkering with sitecustomize.pl.  This is a little known
feature that causes a properly named/located script to be invoked "very
early" when perl is invoked; I'm looking at it mainly to fiddle with @INC so
we can stay away from other, erm, less-desirable hacks.  It's enabled when
perl is compiled with the -Dusesitecustomize option.

Also...  I really, really miss the git plugin for cpanminus.  Being able to
maintain a stack of modules outside for per-application purposes was quite
nice :)

==

I do find myself going back and forth, but the basic things I now try to
stick to are:

1) don't mess with the system perl -- your SAs or your enterprisey vendor
will hate you
2) use RPM for the biggies -- but maintain a parallel set of packages not
dependent or conflicting with system perl
3) don't use automatic metadata generation, but...
4) use RPM metadata, even if you have to manually add it
5) provide the standalone cpanm/perlbrew scripts as part of the core perl
package (pref. in a subpackage)

                         -Chris

[1] "once and future" work might be a more accurate statement...  I'm
starting to get back into it, but my Real Life intruded rather forcefully
last summer and pretty sharply constrained my free time.

-- 
Chris Weyl
Ex astris scientia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20110512/ec9c4974/attachment-0001.html>

From philiph at pobox.com  Thu May 12 13:54:37 2011
From: philiph at pobox.com (Philip J. Hollenback)
Date: Thu, 12 May 2011 13:54:37 -0700
Subject: [sf-perl] perl popularity, TIOBE index
Message-ID: <1305233677.19924.1451328861@webmail.messagingengine.com>

I'm interested in hearing what people think of the TIOBE programming
community index:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

If their analysis is valid (I have no idea) then the long-term prospects
for perl developers look poor.

P.
--  
Philip J. Hollenback
philiph at pobox.com
www.hollenback.net


From swartz at pobox.com  Thu May 12 14:07:20 2011
From: swartz at pobox.com (Jonathan Swartz)
Date: Thu, 12 May 2011 14:07:20 -0700
Subject: [sf-perl] perl popularity, TIOBE index
In-Reply-To: <1305233677.19924.1451328861@webmail.messagingengine.com>
References: <1305233677.19924.1451328861@webmail.messagingengine.com>
Message-ID: <8E4C2610-7137-47C2-885C-AB41A4942545@pobox.com>

There's a lot on the net about how flawed TIOBE is. But I haven't heard of anything much more useful either.

Here's one starting point:

http://blog.timbunce.org/2008/04/12/tiobe-or-not-tiobe-lies-damned-lies-and-statistics/


On May 12, 2011, at 1:54 PM, Philip J. Hollenback wrote:

> I'm interested in hearing what people think of the TIOBE programming
> community index:
> 
> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
> 
> If their analysis is valid (I have no idea) then the long-term prospects
> for perl developers look poor.
> 
> P.
> --  
> Philip J. Hollenback
> philiph at pobox.com
> www.hollenback.net
> 
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm


From fred at redhotpenguin.com  Thu May 12 14:14:43 2011
From: fred at redhotpenguin.com (Fred Moyer)
Date: Thu, 12 May 2011 14:14:43 -0700
Subject: [sf-perl] perl popularity, TIOBE index
In-Reply-To: <8E4C2610-7137-47C2-885C-AB41A4942545@pobox.com>
References: <1305233677.19924.1451328861@webmail.messagingengine.com>
	<8E4C2610-7137-47C2-885C-AB41A4942545@pobox.com>
Message-ID: <BANLkTim+XE4ZPkjyz6eLCMvLY4hW6R=Kcg@mail.gmail.com>

On Thu, May 12, 2011 at 2:07 PM, Jonathan Swartz <swartz at pobox.com> wrote:
> There's a lot on the net about how flawed TIOBE is. But I haven't heard of anything much more useful either.
>
> Here's one starting point:
>
> http://blog.timbunce.org/2008/04/12/tiobe-or-not-tiobe-lies-damned-lies-and-statistics/

Another is here:

http://contentment.org/2008/04/perl-is-not-going-away.html


Here is how the ratings are calculated.  So every time you open up
'Programming Perl' to look up something, or run 'perldoc -f', TIOBE
does not factor that usage into their calcuations.

http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_definition.htm

The ratings are calculated by counting hits of the most popular search
engines. The search query that is used is

+"<language> programming"
This search query is executed for the top 6 websites of Alexa that
meet the following conditions:

The entry page of the site contains a search facility
The result of querying the site contains an indication of the number
of page hits
Based on these criteria currently Google (32%), YouTube (10%), Yahoo!
(3%), Bing (3%), Wikipedia (16%), Blogger (32%) and Baidu (3%) are
used as search engines.

>
>
> On May 12, 2011, at 1:54 PM, Philip J. Hollenback wrote:
>
>> I'm interested in hearing what people think of the TIOBE programming
>> community index:
>>
>> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>>
>> If their analysis is valid (I have no idea) then the long-term prospects
>> for perl developers look poor.
>>
>> P.
>> --
>> Philip J. Hollenback
>> philiph at pobox.com
>> www.hollenback.net
>>
>> _______________________________________________
>> SanFrancisco-pm mailing list
>> SanFrancisco-pm at pm.org
>> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>

From doom at kzsu.stanford.edu  Thu May 12 16:52:43 2011
From: doom at kzsu.stanford.edu (Joseph Brenner)
Date: Thu, 12 May 2011 16:52:43 -0700
Subject: [sf-perl] perl popularity, TIOBE index
In-Reply-To: <BANLkTim+XE4ZPkjyz6eLCMvLY4hW6R=Kcg@mail.gmail.com>
References: <1305233677.19924.1451328861@webmail.messagingengine.com>
	<8E4C2610-7137-47C2-885C-AB41A4942545@pobox.com>
	<BANLkTim+XE4ZPkjyz6eLCMvLY4hW6R=Kcg@mail.gmail.com>
Message-ID: <BANLkTi=ypYuV6WA2PPqoukF286D+m7JM-w@mail.gmail.com>

Fred Moyer <fred at redhotpenguin.com> wrote:
>Jonathan Swartz <swartz at pobox.com> wrote:

> So every time you open up
> 'Programming Perl' to look up something, or run 'perldoc -f', TIOBE
> does not factor that usage into their calcuations.

Or every time you go straight to search.cpan.org or perlmonks.org.

(It should be called the TIOBE index of popularity among the really clueless.)

> +"<language> programming"

And it's pretty obvious that language with a uniquely spelled name
like "perl" isn't going to need "programming" appended to it so often
to make it clear what you're talking about.

From james at ActionMessage.com  Thu May 12 22:52:00 2011
From: james at ActionMessage.com (James Briggs)
Date: Thu, 12 May 2011 22:52:00 -0700
Subject: [sf-perl] perl popularity, TIOBE index - detailed comments
In-Reply-To: <1305233677.19924.1451328861@webmail.messagingengine.com>
References: <1305233677.19924.1451328861@webmail.messagingengine.com>
Message-ID: <20110513055108.M69400@actionmessage.com>

Just looking at the rankings and percentages, Perl is actually doing ok:

- half of the Top 10 are actually C or derivatives
- the scripting languages after Perl have a long way to go to catch up
- also, most programmers know or work in more than 1 language.

Having said that, Perl does face some long-term problems:

- still no polished IPV6 support, hence some of the Python growth
- spotty Unicode support
- mod_perl is not an answer for hosting companies for acceleration, so
  they've gone with PHP.

If anybody is serious about working together on IPV6 support, let me know.

James.

On Thu, 12 May 2011 13:54:37 -0700, Philip J. Hollenback wrote
> I'm interested in hearing what people think of the TIOBE programming
> community index:
>
> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>
> If their analysis is valid (I have no idea) then the long-term prospects
> for perl developers look poor. 


From merlyn at stonehenge.com  Fri May 13 06:05:13 2011
From: merlyn at stonehenge.com (Randal L. Schwartz)
Date: Fri, 13 May 2011 06:05:13 -0700
Subject: [sf-perl] perl popularity, TIOBE index - detailed comments
In-Reply-To: <20110513055108.M69400@actionmessage.com> (James Briggs's message
	of "Thu, 12 May 2011 22:52:00 -0700")
References: <1305233677.19924.1451328861@webmail.messagingengine.com>
	<20110513055108.M69400@actionmessage.com>
Message-ID: <86zkmqrbsm.fsf@red.stonehenge.com>

>>>>> "James" == James Briggs <james at ActionMessage.com> writes:

James> - still no polished IPV6 support, hence some of the Python growth

Why does this myth persist?  Please don't perpetuate it.

James> - mod_perl is not an answer for hosting companies for acceleration, so
James>   they've gone with PHP.

You mean shared hosting?  Yeah, who cares.  Serious stuff is done on VPS
or dedicated hardware or Amazon-like clouds.

James> If anybody is serious about working together on IPV6 support, let
James> me know.

What else remains to be done?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn at stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

From miyagawa at bulknews.net  Fri May 13 15:44:43 2011
From: miyagawa at bulknews.net (Tatsuhiko Miyagawa)
Date: Fri, 13 May 2011 15:44:43 -0700
Subject: [sf-perl] perl popularity, TIOBE index - detailed comments
In-Reply-To: <20110513055108.M69400@actionmessage.com>
References: <1305233677.19924.1451328861@webmail.messagingengine.com>
	<20110513055108.M69400@actionmessage.com>
Message-ID: <BANLkTimXgdytkSTG45tDCdpKxhFGV-Uktw@mail.gmail.com>

On Thu, May 12, 2011 at 10:52 PM, James Briggs <james at actionmessage.com> wrote:

> Having said that, Perl does face some long-term problems:
>
> - still no polished IPV6 support, hence some of the Python growth

Check out perl 5.14, the actual release coming in a few days.
http://search.cpan.org/~jesse/perl-5.14.0-RC3/pod/perldelta.pod#Improved_IPv6_support

> - spotty Unicode support

To me, Unicode support since perl 5.8.3 has been almost complete, but
again, 5.14 fixed a couple of minor issues around Unicode and regular
expressions.
http://search.cpan.org/~jesse/perl-5.14.0-RC3/pod/perldelta.pod#Unicode

> - mod_perl is not an answer for hosting companies for acceleration, so
> ?they've gone with PHP.

Shared hosting, you mean? At my job we host your Perl/PSGI application
on nginx/uwsgi in a virtualized environment, with no issues. </plug>

Come to the next meeting if you want to hear more about that :)
http://www.meetup.com/San-Francisco-Perl-Mongers/events/17570183/

> If anybody is serious about working together on IPV6 support, let me know.
>
> James.
>
> On Thu, 12 May 2011 13:54:37 -0700, Philip J. Hollenback wrote
>> I'm interested in hearing what people think of the TIOBE programming
>> community index:
>>
>> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>>
>> If their analysis is valid (I have no idea) then the long-term prospects
>> for perl developers look poor.
>
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>



-- 
Tatsuhiko Miyagawa

From fred at redhotpenguin.com  Fri May 13 19:42:57 2011
From: fred at redhotpenguin.com (Fred Moyer)
Date: Fri, 13 May 2011 19:42:57 -0700
Subject: [sf-perl] perl popularity, TIOBE index - detailed comments
In-Reply-To: <86zkmqrbsm.fsf@red.stonehenge.com>
References: <1305233677.19924.1451328861@webmail.messagingengine.com>
	<20110513055108.M69400@actionmessage.com>
	<86zkmqrbsm.fsf@red.stonehenge.com>
Message-ID: <BANLkTikWCTssMjx2azGqiFvMzYWL--Nj9w@mail.gmail.com>

On Fri, May 13, 2011 at 6:05 AM, Randal L. Schwartz
<merlyn at stonehenge.com> wrote:
>>>>>> "James" == James Briggs <james at ActionMessage.com> writes:
> James> - mod_perl is not an answer for hosting companies for acceleration, so
> James> ? they've gone with PHP.
>
> You mean shared hosting? ?Yeah, who cares. ?Serious stuff is done on VPS
> or dedicated hardware or Amazon-like clouds.

I think that most of mod_perl's users are split between hard core
enthusiasts and large companies who have dedicated hardware in house
that they can't outsource because their databases are too big to
migrate to the cloud.  VPS probably comes in second to dedicated
hardware, and clouds third.  I would like to know more though, maybe
we can run another mod_perl users survey; I'll drop that on the
mod_perl list.

From fred at redhotpenguin.com  Sat May 14 18:23:08 2011
From: fred at redhotpenguin.com (Fred Moyer)
Date: Sat, 14 May 2011 18:23:08 -0700
Subject: [sf-perl] [conference] Fwd: Books and News from the O'Reilly User
	Group Program--May
In-Reply-To: <1305317405.5484.0.172306@post.oreilly.com>
References: <1305317405.5484.0.172306@post.oreilly.com>
Message-ID: <BANLkTim9NDvJdwGJDxwggnrAk7Vk98zZjw@mail.gmail.com>

OSCON registration is now open.


---------- Forwarded message ----------
From: Marsee Henon & Jon Johns <usergroups at oreilly.com>
Date: Fri, May 13, 2011 at 1:10 PM
Subject: Books and News from the O'Reilly User Group Program--May
To: fred at redhotpenguin.com



View this information as HTML in your browser, click here:
http://post.oreilly.com/rd/9z1z89mbccv427mobbf4q81nad3iohts71ilag3ack8

Hi there,

We've just opened registration for the O'Reilly Open Source Convention
in Portland, OR July 25-29, 2011. This year we're adding two new
conferences, co-located with OSCON, focusing on key areas where open
source is driving innovation: OSCON Data and OSCON Java.
http://post.oreilly.com/rd/9z1zfrg7j238m16fe6038ghldq2fvgdm4pebt9qv7t0

Don't forget to arrive early to attend the Community Leadership Summit
on July 23-24. We're hoping to get as many user group leaders and other
community contributors as we can to participate at this free annual
event.
http://post.oreilly.com/rd/9z1zu8l0m1o4ku8npp7r8v06gf6lms0te2t3q2d3djg

Are you're an experienced Android developer or a recent newbie? We're
looking for contributions for "Android Cookbook." Create your own
recipe, suggest one you'd like to see, or vote for your favorite by
joining the Android Cookbook community.
http://post.oreilly.com/rd/9z1z47jr6eahf32qq9vdo6ajb628cff28j7rju7p3qg

Stay tuned for more Android goodness coming up soon from O'Reilly.


Thanks,

-- Marsee Henon and Jon Johns


P.S. Want to hang out? Here are the places we'll be. If you're attending
or live in the area and have time to get together, please let us know.

-May 15, INETA Community Leadership Summit Meeting 2011, Atlanta, CA
http://post.oreilly.com/rd/9z1zgnhf5dl8k1gjcp799iecfqmj4d67ghq0a35mh48

-May 16-19, TechEd North America 2011, Atlanta, GA
http://post.oreilly.com/rd/9z1ztfpt7uin5unjfguaoh3a84j3abr1gk2r4rr1ij0

-May 21-22, Bay Area Maker Faire, San Mateo, CA
http://post.oreilly.com/rd/9z1zhv84dc2m3thrthdk540u2ha3gv1ut10475cjjmo

-June 2-3, SharePoint Technology Conference, Boston, MA
http://post.oreilly.com/rd/9z1zt0j0p6qi5904eo2jd50s9jkvnt4mcr9ieauh850
Receive a $100 discount off SPTechCon registration or
get free admission to the exhibits by using code OREILLY.
(First time registrants only/cannot be combined with other
offers.)

---------------------------------------------------------------------
UG Discounts--Ebooks, RailsConf, Velocity, OSCON, and More
---------------------------------------------------------------------

Buy 1 Ebook, Get 1 Free
Go to oreilly.com and use discount code: DSUG2
When you buy ebooks through oreilly.com you get lifetime access to the
book, and whenever possible we provide it to you in five, DRM-free file
formats--PDF, ePub, Kindle compatible .mobi, DAISY, and Android APK--to
use on the devices of your choice. Our ebook files are fully searchable
and you can cut, paste, and print them. We also alert you when we've
updated the files with corrections and additions.


O'Reilly Open Source Convention
July 25-29, 2011
Portland, Oregon
oscon.com/

OSCON Data
July 25-27, 2011
oscon.com/data

OSCON Java
July 25-27, 2011
oscon.com/java

Get 20% off each conference with code os11usrg
Early registration pricing applies until June 6.

RailsConf--The official event of the Ruby on Rails Community
May 16-19, 2011
Baltimore, MD
Get 15% off with code rc11usrg
railsconf.com/

O'Reilly Velocity Conference
June 14-16, 2011
Santa Clara, CA
Get 20% off with code vel11usrg
velocityconf.com/

---------------------------------------------------------------------
UG leaders only--Put Up a Banner; Get a Free Book
---------------------------------------------------------------------
We're looking for user groups to display our discount banners on their
web sites. If you send me your group's site with one or more banners
posted, we'll send you the O'Reilly book(s) of your choice. Choose from
the following list:

OSCON, OSCON Java, OSCON Data
http://post.oreilly.com/rd/9z1zc899kp9sblmtcufb4cs9tg9os4ogojp3kp852fg

Railconf
http://post.oreilly.com/rd/9z1z8up6l6t8lvmpvjlq5tsvdsclrm3rda9gc4s7r0o

Velocity Conference
http://post.oreilly.com/rd/9z1zoeamroaiej953o0fnpid1nlucn3uj6u5fqlo29o


---------------------------------------------------------------------
New Releases
---------------------------------------------------------------------
50 Tips and Tricks for MongoDB Developers
http://post.oreilly.com/rd/9z1z01lv1j08toikchvnr7g2poeqpfmd772lqov4fg8

Microsoft Visio 2010 Step by Step (Microsoft Press)
http://post.oreilly.com/rd/9z1zs0l4fd370uor3jj28e4bcd0170rj71c63ispjno

Microsoft Outlook for Mac 2011 Step by Step (Microsoft Press)
http://post.oreilly.com/rd/9z1z0li929agqdqtij68rjmtqf9vk6uu6g069mn6fn0

JavaScript: The Definitive Guide, Sixth Edition
http://post.oreilly.com/rd/9z1ztr7rlu18are78qqphqcr782o1fr9ji2jitsjm30

iPad 2: The Missing Manual, Second Edition
http://post.oreilly.com/rd/9z1z0vbb3qghmaek69ab0jlg0ug00385mo1i2j9ukqg

Introduction to Search with Sphinx
http://post.oreilly.com/rd/9z1z04fve1k951gemhsf7pbsvb3aun1628pksjveou8

Graphics and Animation on iOS
http://post.oreilly.com/rd/9z1z46jlbhjrja28ehrnm0gho2g11jum3tgv6kt9be0

Documents, Presentations, and Workbooks: Using Microsoft Office to
Create Content That Gets Noticed (Microsoft Press)
http://post.oreilly.com/rd/9z1zk48473q4kth8o3rv5pgmepqv46t9nocka7db3u0

Creating a Website: The Missing Manual, Third Edition
http://post.oreilly.com/rd/9z1z78vtm2c5daq8vaupl4j5mdvdt9303pvjakpcsdg

Beyond Bullet Points, Third Edition (Microsoft Press)
http://post.oreilly.com/rd/9z1zii9h1jcqq2a3lbo6n243phlnufm2f9oav5asmeo

Asterisk: The Definitive Guide, Third Edition
http://post.oreilly.com/rd/9z1zqjc5ka62s14mp9sl3ff26d7nsecf5tn86vj3rrg

App Inventor
http://post.oreilly.com/rd/9z1zehcugb3cvtul3nt4liu26lnlsukkaikdb335dsg

Programming HTML5 Applications: Rough Cuts Version
http://post.oreilly.com/rd/9z1zbhcr60up6m2ddgmepnbm3oifkdcj32tnbk8hhso

JavaScript Web Applications
http://post.oreilly.com/rd/9z1z64tsaponpqhmclce0di4lcloc8pf79pf8rt3ia0

Tim O'Reilly in a Nutshell
http://post.oreilly.com/rd/9z1zfhgud2hujn1sa1ctpifkjquace261ujr3o95ipg

Test Driven Development for Embedded C (Pragmatic Bookshelf)
http://post.oreilly.com/rd/9z1zqib3p5iikmqsb964vvasta07m15a0t3vj1j7pq8

Code in the Cloud (Pragmatic Bookshelf)
http://post.oreilly.com/rd/9z1z5ugqfjj4vv3doihs77b7g7dlp6fa9kfk53vnsgg

Requirements Engineering Fundamentals (Rocky Nook)
http://post.oreilly.com/rd/9z1zh7s1205i7ongsm3uf2qkht22snjgev1bk035nfg

Gamification by Design
http://post.oreilly.com/rd/9z1zcd1spnu57l6tsraeg3ca07gkp5ueqtqgsrboqmo


Until next time--

Marsee Henon & Jon Johns


Forward this announcement -
http://post.oreilly.com/f2f/9z1ztmreojaijdifkju7jdqdalg3ednc7c78hth63g8

================================================================
O'Reilly 1005 Gravenstein Highway North Sebastopol, CA ? 95472
800-998-9938 http://post.oreilly.com/rd/9z1zsq7qs8sb6slkltvldub9djfm03jjdfckv7g50q0
Follow us on Twitter at:
http://post.oreilly.com/rd/9z1zkcipvcca8k7oie77slda028eov91mnaiin37f48

You are receiving this email because you are a User Group contact with
O'Reilly Media. If you would like to stop receiving these newsletters or
announcements from O'Reilly, send an email to usergroups at oreilly.com
================================================================

From fred at redhotpenguin.com  Sat May 14 18:36:27 2011
From: fred at redhotpenguin.com (Fred Moyer)
Date: Sat, 14 May 2011 18:36:27 -0700
Subject: [sf-perl] Perl 5.14 has arrived
Message-ID: <BANLkTimQ5Y7imUHPB3+cea8hkQYqFCe4pA@mail.gmail.com>

http://news.perlfoundation.org/2011/05/perl-514.html

From Paul.Makepeace at realprogrammers.com  Sun May 15 06:48:24 2011
From: Paul.Makepeace at realprogrammers.com (Paul Makepeace)
Date: Sun, 15 May 2011 14:48:24 +0100
Subject: [sf-perl] Perl 5.14 has arrived
In-Reply-To: <BANLkTimQ5Y7imUHPB3+cea8hkQYqFCe4pA@mail.gmail.com>
References: <BANLkTimQ5Y7imUHPB3+cea8hkQYqFCe4pA@mail.gmail.com>
Message-ID: <BANLkTi=2qnxLR+58Z6TM6Ne-dsuPVPWU9Q@mail.gmail.com>

Released on 5/14 - cute

On Sun, May 15, 2011 at 02:36, Fred Moyer <fred at redhotpenguin.com> wrote:
>
> http://news.perlfoundation.org/2011/05/perl-514.html
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm

From doom at kzsu.stanford.edu  Sun May 15 11:22:49 2011
From: doom at kzsu.stanford.edu (Joseph Brenner)
Date: Sun, 15 May 2011 11:22:49 -0700
Subject: [sf-perl] perl popularity, TIOBE index - detailed comments
In-Reply-To: <86zkmqrbsm.fsf@red.stonehenge.com>
References: <1305233677.19924.1451328861@webmail.messagingengine.com>
	<20110513055108.M69400@actionmessage.com>
	<86zkmqrbsm.fsf@red.stonehenge.com>
Message-ID: <BANLkTimqgdgMbPu7dASLcmEQP=hsEdZUEA@mail.gmail.com>

Randal L. Schwartz <merlyn at stonehenge.com> wrote:

>> - mod_perl is not an answer for hosting companies for acceleration, they've gone with PHP.

> You mean shared hosting?  Yeah, who cares.  Serious stuff is done on VPS or dedicated hardware or Amazon-like clouds.

The success of PHP is at least an indirect problem for perl's culture,
because PHP can now draw on a big pool of amateurs who start out with
admittedly cheesy shared hosting.

On the other hand, you could argue that perl had more amateurs than it
could safely absorb, and maybe we're a little better off that they're
writing bad code for Drupal.

From friedman at highwire.stanford.edu  Mon May 16 13:41:12 2011
From: friedman at highwire.stanford.edu (Michael Friedman)
Date: Mon, 16 May 2011 13:41:12 -0700
Subject: [sf-perl] Hypercritical on Perl & other programming languages
Message-ID: <52D7C8CA-143B-416E-B7D0-306126798C53@highwire.stanford.edu>

http://5by5.tv/hypercritical/15

This is a great podcast episode by John Siracusa. He talked about programming languages, why they all suck, how to choose "the right one", and why he programs in Perl. It's not sugar-coated, but it's very interesting stuff. He does finally get around to "the reason to program in Perl is CPAN," but he doesn't put it front and center. 

I have a question, though: Is he right about Perl being a testbed for language design in a way that other dynamic languages aren't? If so, I'm even more excited for the future of Perl. Testbeds live forever. :-)

-- Mike
______________________________________________________________________________
Mike Friedman | HighWire Press, Stanford Univ | friedman at highwire.stanford.edu


From swartz at pobox.com  Mon May 16 14:04:10 2011
From: swartz at pobox.com (Jonathan Swartz)
Date: Mon, 16 May 2011 14:04:10 -0700
Subject: [sf-perl] Hypercritical on Perl & other programming languages
In-Reply-To: <52D7C8CA-143B-416E-B7D0-306126798C53@highwire.stanford.edu>
References: <52D7C8CA-143B-416E-B7D0-306126798C53@highwire.stanford.edu>
Message-ID: <9D324989-F9BC-460B-96AF-D79027337328@pobox.com>

I really enjoyed this as well. I've been trying to articulate to myself why I stick with Perl even against popular momentum, etc. etc., and Siracusa nailed it.

On May 16, 2011, at 1:41 PM, Michael Friedman wrote:

> http://5by5.tv/hypercritical/15
> 
> This is a great podcast episode by John Siracusa. He talked about programming languages, why they all suck, how to choose "the right one", and why he programs in Perl. It's not sugar-coated, but it's very interesting stuff. He does finally get around to "the reason to program in Perl is CPAN," but he doesn't put it front and center. 
> 
> I have a question, though: Is he right about Perl being a testbed for language design in a way that other dynamic languages aren't? If so, I'm even more excited for the future of Perl. Testbeds live forever. :-)
> 
> -- Mike
> ______________________________________________________________________________
> Mike Friedman | HighWire Press, Stanford Univ | friedman at highwire.stanford.edu
> 
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm


From fred at redhotpenguin.com  Mon May 16 17:51:39 2011
From: fred at redhotpenguin.com (Fred Moyer)
Date: Mon, 16 May 2011 17:51:39 -0700
Subject: [sf-perl] Request for comments - Perl rpm builds
Message-ID: <BANLkTi=OwnXe7tu0wX8nhCyebBF6z8CHKw@mail.gmail.com>

I got an itch to build Perl rpms in an attempt to whittle down the
issue discussed in a previous thread of deploying Perl applications in
RPM package environments without using the system installed perl
binary.

Please forgive the name of this github repo, but I had a really
difficult time coming up with a good name for this, since rpm won't
let you have two packages installed with the same name (meaning I
couldn't call it 'perl').  So I came up with Fast RPM Enterprise
Deployment Perl - fredperl.  Got an idea for a better name?  Send it
to me!

https://github.com/redhotpenguin/fredperl


This repo is really nothing more than the Centos 5.6 Perl spec file
carved up with a few different options, such as no threading, a few
compilation optimizations, and a unique install path.  And a unique
name, fredperl_5_14_0 in the case of the 5.14.0 build, so that you can
install different versions side by side in /opt/.


The benchmarks of each build are here, 5.12.3, 5.14.0, and the Centos
5.8.8.  I used PerlBench to compare each of the binaries - 5.14.0 is
looking pretty good.

http://www.redhotpenguin.com/fredperl_bench/


This is just a very rough proof of concept, but if you are running
Centos or Fedora, you should be able to clone this github repo,
install the source rpms, and build your own binaries to try out your
application with.  Comments and feedback are very welcome, both on and
off this list.  I've got a few ideas for additional features, such as
being able to take a Makefile.PL with the proper dependencies and
generate all the rpms needed for the modules in that Makefile.PL.

From doom at kzsu.stanford.edu  Mon May 16 20:04:46 2011
From: doom at kzsu.stanford.edu (Joseph Brenner)
Date: Mon, 16 May 2011 20:04:46 -0700
Subject: [sf-perl] Request for comments - Perl rpm builds
In-Reply-To: <BANLkTi=OwnXe7tu0wX8nhCyebBF6z8CHKw@mail.gmail.com>
References: <BANLkTi=OwnXe7tu0wX8nhCyebBF6z8CHKw@mail.gmail.com>
Message-ID: <BANLkTimcHdb4ma6JKh164p=gdwng8_SFQA@mail.gmail.com>

Sounds like a worthy experiment.  As far as names go, the way these
things are done in the ubuntu/debian world is a version number is
tacked on to the name.  So you might name the binary perl5.14 and call
the package perl5.14-5_14_0-0-i386.rpm.

On Mon, May 16, 2011 at 5:51 PM, Fred Moyer <fred at redhotpenguin.com> wrote:
> I got an itch to build Perl rpms in an attempt to whittle down the
> issue discussed in a previous thread of deploying Perl applications in
> RPM package environments without using the system installed perl
> binary.
>
> Please forgive the name of this github repo, but I had a really
> difficult time coming up with a good name for this, since rpm won't
> let you have two packages installed with the same name (meaning I
> couldn't call it 'perl'). ?So I came up with Fast RPM Enterprise
> Deployment Perl - fredperl. ?Got an idea for a better name? ?Send it
> to me!
>
> https://github.com/redhotpenguin/fredperl
>
>
> This repo is really nothing more than the Centos 5.6 Perl spec file
> carved up with a few different options, such as no threading, a few
> compilation optimizations, and a unique install path. ?And a unique
> name, fredperl_5_14_0 in the case of the 5.14.0 build, so that you can
> install different versions side by side in /opt/.
>
>
> The benchmarks of each build are here, 5.12.3, 5.14.0, and the Centos
> 5.8.8. ?I used PerlBench to compare each of the binaries - 5.14.0 is
> looking pretty good.
>
> http://www.redhotpenguin.com/fredperl_bench/
>
>
> This is just a very rough proof of concept, but if you are running
> Centos or Fedora, you should be able to clone this github repo,
> install the source rpms, and build your own binaries to try out your
> application with. ?Comments and feedback are very welcome, both on and
> off this list. ?I've got a few ideas for additional features, such as
> being able to take a Makefile.PL with the proper dependencies and
> generate all the rpms needed for the modules in that Makefile.PL.
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>

From fred at redhotpenguin.com  Tue May 17 22:46:14 2011
From: fred at redhotpenguin.com (Fred Moyer)
Date: Tue, 17 May 2011 22:46:14 -0700
Subject: [sf-perl] Request for comments - Perl rpm builds
In-Reply-To: <BANLkTimcHdb4ma6JKh164p=gdwng8_SFQA@mail.gmail.com>
References: <BANLkTi=OwnXe7tu0wX8nhCyebBF6z8CHKw@mail.gmail.com>
	<BANLkTimcHdb4ma6JKh164p=gdwng8_SFQA@mail.gmail.com>
Message-ID: <BANLkTi=EA6doMBL3V0u1hhw3QumLN3-iww@mail.gmail.com>

On Mon, May 16, 2011 at 8:04 PM, Joseph Brenner <doom at kzsu.stanford.edu> wrote:
> Sounds like a worthy experiment. ?As far as names go, the way these
> things are done in the ubuntu/debian world is a version number is
> tacked on to the name. ?So you might name the binary perl5.14 and call
> the package perl5.14-5_14_0-0-i386.rpm.

Thanks for the good feedback, I've renamed the rpms to contain the
version, ala perl_5_14_0 which results in
perl_5_14_0-5.14.0-1.i386.rpm

Not ideal, but better than it was.  Rpm couples the source
distribution tarball name with the rpm name tightly.  And rpm appears
to specify the name of the rpm based on the package name, version, and
rel values, hence the 5_14_0 5.14.0 redux.

I came up with a better name also, fredperl is now oysterhead (not to
be confused with the rock band of the same name).

https://github.com/redhotpenguin/oysterhead


>
> On Mon, May 16, 2011 at 5:51 PM, Fred Moyer <fred at redhotpenguin.com> wrote:
>> I got an itch to build Perl rpms in an attempt to whittle down the
>> issue discussed in a previous thread of deploying Perl applications in
>> RPM package environments without using the system installed perl
>> binary.
>>
>> Please forgive the name of this github repo, but I had a really
>> difficult time coming up with a good name for this, since rpm won't
>> let you have two packages installed with the same name (meaning I
>> couldn't call it 'perl'). ?So I came up with Fast RPM Enterprise
>> Deployment Perl - fredperl. ?Got an idea for a better name? ?Send it
>> to me!
>>
>> https://github.com/redhotpenguin/fredperl
>>
>>
>> This repo is really nothing more than the Centos 5.6 Perl spec file
>> carved up with a few different options, such as no threading, a few
>> compilation optimizations, and a unique install path. ?And a unique
>> name, fredperl_5_14_0 in the case of the 5.14.0 build, so that you can
>> install different versions side by side in /opt/.
>>
>>
>> The benchmarks of each build are here, 5.12.3, 5.14.0, and the Centos
>> 5.8.8. ?I used PerlBench to compare each of the binaries - 5.14.0 is
>> looking pretty good.
>>
>> http://www.redhotpenguin.com/fredperl_bench/
>>
>>
>> This is just a very rough proof of concept, but if you are running
>> Centos or Fedora, you should be able to clone this github repo,
>> install the source rpms, and build your own binaries to try out your
>> application with. ?Comments and feedback are very welcome, both on and
>> off this list. ?I've got a few ideas for additional features, such as
>> being able to take a Makefile.PL with the proper dependencies and
>> generate all the rpms needed for the modules in that Makefile.PL.
>> _______________________________________________
>> 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 cweyl at alumni.drew.edu  Wed May 18 10:37:56 2011
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Wed, 18 May 2011 10:37:56 -0700
Subject: [sf-perl] Request for comments - Perl rpm builds
In-Reply-To: <BANLkTi=EA6doMBL3V0u1hhw3QumLN3-iww@mail.gmail.com>
References: <BANLkTi=OwnXe7tu0wX8nhCyebBF6z8CHKw@mail.gmail.com>
	<BANLkTimcHdb4ma6JKh164p=gdwng8_SFQA@mail.gmail.com>
	<BANLkTi=EA6doMBL3V0u1hhw3QumLN3-iww@mail.gmail.com>
Message-ID: <BANLkTi=1MC8+mLvD6czJeqSQyrOvp+YDWg@mail.gmail.com>

On Tue, May 17, 2011 at 10:46 PM, Fred Moyer <fred at redhotpenguin.com> wrote:

> On Mon, May 16, 2011 at 8:04 PM, Joseph Brenner <doom at kzsu.stanford.edu>
> wrote:
> > Sounds like a worthy experiment.  As far as names go, the way these
> > things are done in the ubuntu/debian world is a version number is
> > tacked on to the name.  So you might name the binary perl5.14 and call
> > the package perl5.14-5_14_0-0-i386.rpm.
>
> Thanks for the good feedback, I've renamed the rpms to contain the
> version, ala perl_5_14_0 which results in
> perl_5_14_0-5.14.0-1.i386.rpm
>
>
A couple thoughts from a cursory once-over:

You can use the canonical source package and location, and cause tell rpm
what directory to change into by:

%prep
%setup -q -n perl-%{version}

You're going to want to strip or rename the metadata given in the Provides
lines (e.g. the perl(Foo)), as that will conflict with the metadatasystem
provided by the system Perl package.

Automatic Perl metadata generation should be disabled, for the same reason
(conflicts with the system Perl package).  Generally speaking, this does the
trick without impacting other metadata generation:

%global __perl_requires %{nil}
%global __perl_provides %{nil}

Similarly, you're going to want to remove the "Obsoletes" lines.

%global vs %define: %define was the standard approach for years, but
eschewing %define for %global has become the norm in the Fedora/RHEL world
at this point.  (AFAICT the difference is in lazy evaluation -- %global is
evaluated and set as it's read, %defined as used.)

I generally set %_prefix to /usr/perl-%{version} instead of /opt/... as I'm
given to understand that /opt is reserved for packages completely
independent from the system itself (e.g. self-satisfying to just about all
dependencies) and the non-system Perl packages I build still leverage parts
of the installed system (e.g. shared libraries) and express RPM dependency
information.  I suspect this might get a touch religious, however. :)

I'm going on the assumption here that you don't want to replace the system
Perl package.  If this is the case, then you're going to want to steer clear
of the existing RPM/Perl metadata system (autogeneration of deps of the form
perl(Foo)), or you'll run into no end of trouble.  If you're building RPMs
to deliver CPAN package as well, you're going to need a way to declare
dependencies to RPM that satisfies their needs and doesn't conflict with the
system Perl dependency system.

Whew!  Now I'm feeling an itch to get back into reviewing Fedora packages
:-D

                           -Chris

-- 
Chris Weyl
Ex astris scientia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20110518/06ac4bf5/attachment.html>

From fred at redhotpenguin.com  Wed May 18 12:03:05 2011
From: fred at redhotpenguin.com (Fred Moyer)
Date: Wed, 18 May 2011 12:03:05 -0700
Subject: [sf-perl] [meeting] Reminder, PSGI and DotCloud next Tuesday
Message-ID: <BANLkTi=ztNR3VV30tLw-A4Whzybagi53-Q@mail.gmail.com>

Just a quick reminder, PGSI and DotCloud is next Tuesday at Mother Jones.

http://www.meetup.com/San-Francisco-Perl-Mongers/events/17570183/

From fred at redhotpenguin.com  Wed May 18 14:00:03 2011
From: fred at redhotpenguin.com (Fred Moyer)
Date: Wed, 18 May 2011 14:00:03 -0700
Subject: [sf-perl] Request for comments - Perl rpm builds
In-Reply-To: <BANLkTi=1MC8+mLvD6czJeqSQyrOvp+YDWg@mail.gmail.com>
References: <BANLkTi=OwnXe7tu0wX8nhCyebBF6z8CHKw@mail.gmail.com>
	<BANLkTimcHdb4ma6JKh164p=gdwng8_SFQA@mail.gmail.com>
	<BANLkTi=EA6doMBL3V0u1hhw3QumLN3-iww@mail.gmail.com>
	<BANLkTi=1MC8+mLvD6czJeqSQyrOvp+YDWg@mail.gmail.com>
Message-ID: <BANLkTinhC=x4zQemTbxuT2SSX97dRMQMTQ@mail.gmail.com>

On Wed, May 18, 2011 at 10:37 AM, Chris Weyl <cweyl at alumni.drew.edu> wrote:
> A couple thoughts from a cursory once-over:
>
> You can use the canonical source package and location, and cause tell rpm
> what directory to change into by:
>
> %prep
> %setup -q -n perl-%{version}

Oh nice - thank you.

>
> You're going to want to strip or rename the metadata given in the Provides
> lines (e.g. the perl(Foo)), as that will conflict with the metadatasystem
> provided by the system Perl package.

The filter-depends.sh program seems to have taken care of most of the
troublemakers so far, but thanks for the spot, I'll implement that.


> Automatic Perl metadata generation should be disabled, for the same reason
> (conflicts with the system Perl package).? Generally speaking, this does the
> trick without impacting other metadata generation:
>
> %global __perl_requires %{nil}
> %global __perl_provides %{nil}
>
> Similarly, you're going to want to remove the "Obsoletes" lines.
>
> %global vs %define: %define was the standard approach for years, but
> eschewing %define for %global has become the norm in the Fedora/RHEL world
> at this point.? (AFAICT the difference is in lazy evaluation -- %global is
> evaluated and set as it's read, %defined as used.)

Thanks for the protips.


> I generally set %_prefix to /usr/perl-%{version} instead of /opt/... as I'm
> given to understand that /opt is reserved for packages completely
> independent from the system itself (e.g. self-satisfying to just about all
> dependencies) and the non-system Perl packages I build still leverage parts
> of the installed system (e.g. shared libraries) and express RPM dependency
> information.? I suspect this might get a touch religious, however. :)

What do you mean by 'completely independent'?  Perhaps /usr/local/ is
a good approach here.

> I'm going on the assumption here that you don't want to replace the system
> Perl package.? If this is the case, then you're going to want to steer clear
> of the existing RPM/Perl metadata system (autogeneration of deps of the form
> perl(Foo)), or you'll run into no end of trouble.? If you're building RPMs
> to deliver CPAN package as well, you're going to need a way to declare
> dependencies to RPM that satisfies their needs and doesn't conflict with the
> system Perl dependency system.

That's right, I don't want to replace it.

Ah, this brings back memories of building RPMs for the separate perl
binary rpm.  It is looking like I will need to prefix the binary and
associated module rpms with a namespace to differentiate them from the
system Perl module rpms.


>
> Whew!? Now I'm feeling an itch to get back into reviewing Fedora packages
> :-D
>
> ?????????????????????????? -Chris
>
> --
> Chris Weyl
> Ex astris scientia
>

From cweyl at alumni.drew.edu  Wed May 18 14:27:49 2011
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Wed, 18 May 2011 14:27:49 -0700
Subject: [sf-perl] Request for comments - Perl rpm builds
In-Reply-To: <BANLkTinhC=x4zQemTbxuT2SSX97dRMQMTQ@mail.gmail.com>
References: <BANLkTi=OwnXe7tu0wX8nhCyebBF6z8CHKw@mail.gmail.com>
	<BANLkTimcHdb4ma6JKh164p=gdwng8_SFQA@mail.gmail.com>
	<BANLkTi=EA6doMBL3V0u1hhw3QumLN3-iww@mail.gmail.com>
	<BANLkTi=1MC8+mLvD6czJeqSQyrOvp+YDWg@mail.gmail.com>
	<BANLkTinhC=x4zQemTbxuT2SSX97dRMQMTQ@mail.gmail.com>
Message-ID: <BANLkTimv_o-txX=6Bo09adeQzfqu0qAY=Q@mail.gmail.com>

On Wed, May 18, 2011 at 2:00 PM, Fred Moyer <fred at redhotpenguin.com> wrote:

> On Wed, May 18, 2011 at 10:37 AM, Chris Weyl <cweyl at alumni.drew.edu>
> wrote:
>
> I generally set %_prefix to /usr/perl-%{version} instead of /opt/... as
> I'm
> > given to understand that /opt is reserved for packages completely
> > independent from the system itself (e.g. self-satisfying to just about
> all
> > dependencies) and the non-system Perl packages I build still leverage
> parts
> > of the installed system (e.g. shared libraries) and express RPM
> dependency
> > information.  I suspect this might get a touch religious, however. :)
>
> What do you mean by 'completely independent'?  Perhaps /usr/local/ is
> a good approach here.
>

This is actually something I've avoided by not ever installing anything into
/opt -- Fedora guidelines prohibit its use in any rpms.  The FHS addresses
it[1], but I've only ever seen things such as Java or various IBM Tivoli
products install in there.  My understanding of "independent" means that
they're either statically linked or only link to the standard libraries that
are (hand-waving here) guaranteed to be on every system.  The FHS says one
thing, but vendors do what they want here, essentially.

/usr/local is similarly restricted -- it's reserved for site or system
adminstrators to install into, not anything delivered by a Fedora/RHEL
rpm.[2]  If you were building Perl locally, this is where you'd want to put
it.  (Or at least where the FHS wants you to want to put it :))

Strictly speaking, my use of /usr directly (e.g. /usr/perl-x.y.z) is also
prohibited by the FHS... and the definitions for /opt seem more in line with
the usage we're talking about.  Hm, interesting.  I might need to rethink my
avoidance of /opt here.

> I'm going on the assumption here that you don't want to replace the system
> > Perl package.  If this is the case, then you're going to want to steer
> clear
> > of the existing RPM/Perl metadata system (autogeneration of deps of the
> form
> > perl(Foo)), or you'll run into no end of trouble.  If you're building
> RPMs
> > to deliver CPAN package as well, you're going to need a way to declare
> > dependencies to RPM that satisfies their needs and doesn't conflict with
> the
> > system Perl dependency system.
>
> That's right, I don't want to replace it.
>
> Ah, this brings back memories of building RPMs for the separate perl
> binary rpm.  It is looking like I will need to prefix the binary and
> associated module rpms with a namespace to differentiate them from the
> system Perl module rpms.
>

Yeah -- it gets exciting otherwise :)

                              -Chris

[1]
http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES
[2] http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY


-- 
Chris Weyl
Ex astris scientia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20110518/a32323f4/attachment.html>

From fred at redhotpenguin.com  Mon May 23 18:11:24 2011
From: fred at redhotpenguin.com (Fred Moyer)
Date: Mon, 23 May 2011 18:11:24 -0700
Subject: [sf-perl] [meeting] Please RSVP by 4pm tomorrow if you are coming
	to PSGI and DotCloud
Message-ID: <BANLkTi=oEt=qejDmOpwxSwz5DjDPo8M-4Q@mail.gmail.com>

We need to hand the RSVP list to security tomorrow before 5, so please
RSVP by 4pm if you are planning to attend.  If you are unsure, just
RSVP yes.  Thanks!

http://www.meetup.com/San-Francisco-Perl-Mongers/events/17570183/

From friedman at highwire.stanford.edu  Tue May 24 11:56:19 2011
From: friedman at highwire.stanford.edu (Michael Friedman)
Date: Tue, 24 May 2011 11:56:19 -0700
Subject: [sf-perl] why I love CPAN (and Plack)
Message-ID: <340F694B-9597-46D9-93FB-E30BC3C1B6EB@highwire.stanford.edu>

I had to make an iPhone-compatible version of a third-party website at work recently, so I searched CPAN. What did I find, but a perl one-liner iPhone-rewriting web proxy!

plackup -MPlack::App::Proxy -e 'builder {enable iPhone; Plack::App::Proxy->new(remote => "http://search.cpan.org/") }'

(Plack::Middleware::iPhone)

Wow. This is why I love CPAN. I installed one module (well, with dependencies it installed a few more), ran one single-line script, and it's all working just fine. 

Thanks to everyone who made a potential week's worth of work into a single hour! (Especially Patrick Donelan and Tatsuhiko Miyagawa. Awesome work!)

-- Mike
______________________________________________________________________________
Mike Friedman | HighWire Press, Stanford Univ | friedman at highwire.stanford.edu


From miyagawa at bulknews.net  Tue May 24 14:34:38 2011
From: miyagawa at bulknews.net (Tatsuhiko Miyagawa)
Date: Tue, 24 May 2011 14:34:38 -0700
Subject: [sf-perl] why I love CPAN (and Plack)
In-Reply-To: <340F694B-9597-46D9-93FB-E30BC3C1B6EB@highwire.stanford.edu>
References: <340F694B-9597-46D9-93FB-E30BC3C1B6EB@highwire.stanford.edu>
Message-ID: <BANLkTikH6Ba+sGAQSL6nDXCWLc_St5zAcA@mail.gmail.com>

Very nice :)

Applying middleware to remote websites using Proxy app is probably one
of the greatest things you can do with Plack. You can also do the same
to your legacy app using WrapCGI, or with PHP FastCGI application
using FCGIDispatcher, etc. etc.

Mind if I "reblog" this on my Plack/perl blog, Michael?

On Tue, May 24, 2011 at 11:56 AM, Michael Friedman
<friedman at highwire.stanford.edu> wrote:
> I had to make an iPhone-compatible version of a third-party website at work recently, so I searched CPAN. What did I find, but a perl one-liner iPhone-rewriting web proxy!
>
> plackup -MPlack::App::Proxy -e 'builder {enable iPhone; Plack::App::Proxy->new(remote => "http://search.cpan.org/") }'
>
> (Plack::Middleware::iPhone)
>
> Wow. This is why I love CPAN. I installed one module (well, with dependencies it installed a few more), ran one single-line script, and it's all working just fine.
>
> Thanks to everyone who made a potential week's worth of work into a single hour! (Especially Patrick Donelan and Tatsuhiko Miyagawa. Awesome work!)
>
> -- Mike
> ______________________________________________________________________________
> Mike Friedman | HighWire Press, Stanford Univ | friedman at highwire.stanford.edu
>
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>



-- 
Tatsuhiko Miyagawa

From miyagawa at gmail.com  Tue May 24 21:02:17 2011
From: miyagawa at gmail.com (Tatsuhiko Miyagawa)
Date: Tue, 24 May 2011 21:02:17 -0700
Subject: [sf-perl] Links
Message-ID: <BANLkTimygr7n8eKMoDc-u6PCas+asFr_Cw@mail.gmail.com>

Hi,

Thank you all for coming today. Here are the links mentioned in today's talks:

DotCloud
http://www.dotcloud.com/

reddit: The PSGI is the limit (Beware: annoying to read!)
http://www.reddit.com/r/perl/comments/h6qqr/the_psgi_is_the_limit/

Plack Interactive Debugger
https://github.com/miyagawa/Plack-Middleware-InteractiveDebugger

Plack::Middleware::REPL
http://search.cpan.org/~miyagawa/Plack-Middleware-REPL-0.01/

Prack
https://github.com/leedo/Plack-App-Prack

Pow
http://pow.cx/

Plack blog
http://blog.plackperl.org/



-- 
Tatsuhiko Miyagawa

From fred at redhotpenguin.com  Wed May 25 12:13:50 2011
From: fred at redhotpenguin.com (Fred Moyer)
Date: Wed, 25 May 2011 12:13:50 -0700
Subject: [sf-perl] Links
In-Reply-To: <BANLkTimygr7n8eKMoDc-u6PCas+asFr_Cw@mail.gmail.com>
References: <BANLkTimygr7n8eKMoDc-u6PCas+asFr_Cw@mail.gmail.com>
Message-ID: <BANLkTin2a0Fud7wgS9QTbVwSn2Wp-b9o9A@mail.gmail.com>

Thanks for the great talk, really enjoyed it!

On Tue, May 24, 2011 at 9:02 PM, Tatsuhiko Miyagawa <miyagawa at gmail.com> wrote:
> Hi,
>
> Thank you all for coming today. Here are the links mentioned in today's talks:
>
> DotCloud
> http://www.dotcloud.com/
>
> reddit: The PSGI is the limit (Beware: annoying to read!)
> http://www.reddit.com/r/perl/comments/h6qqr/the_psgi_is_the_limit/
>
> Plack Interactive Debugger
> https://github.com/miyagawa/Plack-Middleware-InteractiveDebugger
>
> Plack::Middleware::REPL
> http://search.cpan.org/~miyagawa/Plack-Middleware-REPL-0.01/
>
> Prack
> https://github.com/leedo/Plack-App-Prack
>
> Pow
> http://pow.cx/
>
> Plack blog
> http://blog.plackperl.org/
>
>
>
> --
> Tatsuhiko Miyagawa
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>

From friedman at highwire.stanford.edu  Wed May 25 23:55:38 2011
From: friedman at highwire.stanford.edu (Michael Friedman)
Date: Wed, 25 May 2011 23:55:38 -0700
Subject: [sf-perl] auto-generated web app?
Message-ID: <399F0C9D-8B3E-410D-83ED-FF7C00075909@highwire.stanford.edu>

After the demo of dotCloud yesterday, I decided that I want to try out a database-driven webapp. Nothing special, just a couple of tables and a relationship or two. 

Here's the rub: I don't have hardly any free time to work on this. (If I can get the app working in under 4 hours, that'd be about right.) So I'm looking for something that will let me define the table structure and then will automatically take care of:
- routes/URLs
- CRUD
- webpage generation
- display templates

so that I can then focus on adding features to an existing, working, database view and update site. 

I have looked at a lot of web frameworks today. I found one that looks like it can do what I want: Catalyst::Plugin::AutoCRUD. 
	http://search.cpan.org/~oliver/Catalyst-Plugin-AutoCRUD-1.110731/lib/Catalyst/Plugin/AutoCRUD.pm

However, I'm sure TIMTOWTDI. 

Does anyone else know of or have experience with this kind of auto-generated database-backed site? The more it can do for me, the better, as far as I'm concerned. 
Thanks for any and all advice!
-- Mike
______________________________________________________________________________
Mike Friedman | HighWire Press, Stanford Univ | friedman at highwire.stanford.edu


From ddascalescu at gmail.com  Fri May 27 14:01:46 2011
From: ddascalescu at gmail.com (Dan Dascalescu)
Date: Fri, 27 May 2011 14:01:46 -0700
Subject: [sf-perl] auto-generated web app?
In-Reply-To: <399F0C9D-8B3E-410D-83ED-FF7C00075909@highwire.stanford.edu>
References: <399F0C9D-8B3E-410D-83ED-FF7C00075909@highwire.stanford.edu>
Message-ID: <BANLkTi=ZwvHV8vdaBreWzj08WjTVknXTWA@mail.gmail.com>

Check out Catalyst::Example::InstantCRUDStylish ?

You create the database, then it extracts relationships and creates the
scaffold app.

Dan

On Wed, May 25, 2011 at 23:55, Michael Friedman <
friedman at highwire.stanford.edu> wrote:

> After the demo of dotCloud yesterday, I decided that I want to try out a
> database-driven webapp. Nothing special, just a couple of tables and a
> relationship or two.
>
> Here's the rub: I don't have hardly any free time to work on this. (If I
> can get the app working in under 4 hours, that'd be about right.) So I'm
> looking for something that will let me define the table structure and then
> will automatically take care of:
> - routes/URLs
> - CRUD
> - webpage generation
> - display templates
>
> so that I can then focus on adding features to an existing, working,
> database view and update site.
>
> I have looked at a lot of web frameworks today. I found one that looks like
> it can do what I want: Catalyst::Plugin::AutoCRUD.
>
> http://search.cpan.org/~oliver/Catalyst-Plugin-AutoCRUD-1.110731/lib/Catalyst/Plugin/AutoCRUD.pm
>
> However, I'm sure TIMTOWTDI.
>
> Does anyone else know of or have experience with this kind of
> auto-generated database-backed site? The more it can do for me, the better,
> as far as I'm concerned.
> Thanks for any and all advice!
> -- Mike
>
> ______________________________________________________________________________
> Mike Friedman | HighWire Press, Stanford Univ |
> friedman at highwire.stanford.edu
>
> _______________________________________________
> 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/20110527/72498cf5/attachment.html>