From agrangaard at rubiconproject.com  Tue Aug  4 16:01:26 2009
From: agrangaard at rubiconproject.com (Andrew Grangaard)
Date: Tue, 4 Aug 2009 19:01:26 -0400
Subject: [LA.pm] July Recap
Message-ID: <A8A3340A1D68D94CB65744935483C877FBC7C8@BE38.exg3.exghost.com>

July Perl Mongers recap(1) 

July Perl Mongers was on Thursday, July 16. We had another great crowd
of about 20 people. I found myself having to shoo people out of the
office at 10:30pm so I could get some post-meeting work done. That's
always a good sign. 

David "Xantus" Davis(2) started us off with a quick look at
mojolicious(3). Mojolicious is an MVC framework built on top of mojo. It
is very new and very hip -- and *very* light on documentation at the
moment, so it was neat to see someone who was having fun using it.
Thanks a lot for volunteering your time to present! 

Mon-Chaio's talk on "Interviewing (Perl) Programming Candidates" was
surprisingly well received. I knew he'd give a polished presentation but
didn't know just how much conversation and debate it would engender. I
liked that it wasn't just a thinly veiled recruiting attempt since we're
hiring(4). And who can forget bringing back the term perler(5). MC: Can
you send me your slides, and I'll link them from here. 

Informal polling showed that "Third Thursday" doesn't work well,
possibly because of Mindshare.la(6) but that people like Thursdays. In
August we'll try "Fourth Thursday", August 27, 2009. See you then! 

Andrew

Links: 
1) http://www.lowlevelmanager.com/2009/08/july-perl-mongers-recap.html
2) http://xant.us
3) http://mojolicious.org
4) http://www.rubiconproject.com/about/hiring
5) http://www.lowlevelmanager.com/2009/07/perler.html	
6) http://mindshare.la



From david.davis at gmail.com  Mon Aug 10 13:38:21 2009
From: david.davis at gmail.com (David Davis)
Date: Mon, 10 Aug 2009 13:38:21 -0700
Subject: [LA.pm] Updating LA.pm's site
In-Reply-To: <87y6q7fb46.wl_rs@pobox.com>
References: <89f5393a0907291301i3876213fpcd6835d8b46f19bd@mail.gmail.com>
	<4A70B45E.80805@rubiconproject.com> <87y6q7fb46.wl_rs@pobox.com>
Message-ID: <89f5393a0908101338o6131d075w9038a14fc8047d6d@mail.gmail.com>

Any news on getting access?  Also MovableType would be a good choice for the
site.

David Davis
? Software Engineer
http://xant.us/
http://xantus.tel/


On Wed, Jul 29, 2009 at 14:11, Robert Spier <rspier at pobox.com> wrote:

>
>
> Andrew Grangaard wrote:
> >
> > I'm in the process of getting access to the site to update it.
>
> I will expedite this later this afternoon.
>
> > I put in a request, it made it to the RT queue, some additional people
> > needed to be contacted, they have now been contacted.  So now we're
> > waiting on volunteer labor to update the RT queue at perl.org /
> > pm.org.
>
> That's the key.  Jay, who handles most of the tickets is a *volunteer*
> (as are all of us who run pm.org and the other perl sites.)  About
> every two weeks he goes through all pending tickets and updates them.
> It's not a sexy job, and we're really happy that Jay has been doing it
> for so long.
>
> > The previous maintainer never gained access to the site, which is why
> > it wasn't updated last fall.  The previous-previous maintainer has
> > left town, but he has given his blessing for the transfer of control.
>
> We always check that, or at least give the previous contact person we
> have a chance to object, in order to prevent hijacking.
>
> >
> > I don't really have a time estimate.  My most recent status update was
> > received a week or two ago.
> >
> > In that vein, if anyone wants to make some spiffy code to run the
> > site, let me know.  As it is currently hosted, we only get flat-text
> > files. It is possible to point the domain elsewhere if we want active
> > content.
> >
> > peace,
> > Andrew
> >
> > David Davis wrote:
> > > Hey everyone,
> > > Does anyone know why http://losangeles.pm.org/ basn't been updated
> > > in over a year?
> > > I know LA.pm is active....I just gave a talk at the last meeting.
> > > Who has access to update the site?
> > > David Davis
> > > ? Software Engineer
> > > http://xant.us/
> > > http://xantus.tel/
> > >
> ------------------------------------------------------------------------
> > > _______________________________________________
> > > Losangeles-pm mailing list
> > > Losangeles-pm at pm.org
> > > http://mail.pm.org/mailman/listinfo/losangeles-pm
> >
> > _______________________________________________
> > Losangeles-pm mailing list
> > Losangeles-pm at pm.org
> > http://mail.pm.org/mailman/listinfo/losangeles-pm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/losangeles-pm/attachments/20090810/8cc12029/attachment.html>

From tommystanton at gmail.com  Mon Aug 10 22:20:59 2009
From: tommystanton at gmail.com (Tommy Stanton)
Date: Mon, 10 Aug 2009 22:20:59 -0700
Subject: [LA.pm] Updating LA.pm's site
In-Reply-To: <89f5393a0908101338o6131d075w9038a14fc8047d6d@mail.gmail.com>
References: <89f5393a0907291301i3876213fpcd6835d8b46f19bd@mail.gmail.com>
	<4A70B45E.80805@rubiconproject.com> <87y6q7fb46.wl_rs@pobox.com>
	<89f5393a0908101338o6131d075w9038a14fc8047d6d@mail.gmail.com>
Message-ID: <2e0b15380908102220u669711bfq21d90b6afa2e70c5@mail.gmail.com>

Has anyone played with Melody yet?  It's an open-source version of MoveableType:

http://openmelody.org/about/

Our own fellow Monger, Todd Presta, mentioned it in his blog a month ago:

http://www.asciiville.com/2009/07/on-using-perl-cgiapplication-module-for-ajax-web-apps.html

-Tommy

2009/8/10 David Davis <david.davis at gmail.com>:
> Any news on getting access?? Also MovableType would be a good choice for the
> site.
>
> David Davis
> ? Software Engineer
> http://xant.us/
> http://xantus.tel/
>
>
> On Wed, Jul 29, 2009 at 14:11, Robert Spier <rspier at pobox.com> wrote:
>>
>>
>> Andrew Grangaard wrote:
>> >
>> > I'm in the process of getting access to the site to update it.
>>
>> I will expedite this later this afternoon.
>>
>> > I put in a request, it made it to the RT queue, some additional people
>> > needed to be contacted, they have now been contacted. ?So now we're
>> > waiting on volunteer labor to update the RT queue at perl.org /
>> > pm.org.
>>
>> That's the key. ?Jay, who handles most of the tickets is a *volunteer*
>> (as are all of us who run pm.org and the other perl sites.) ?About
>> every two weeks he goes through all pending tickets and updates them.
>> It's not a sexy job, and we're really happy that Jay has been doing it
>> for so long.
>>
>> > The previous maintainer never gained access to the site, which is why
>> > it wasn't updated last fall. ?The previous-previous maintainer has
>> > left town, but he has given his blessing for the transfer of control.
>>
>> We always check that, or at least give the previous contact person we
>> have a chance to object, in order to prevent hijacking.
>>
>> >
>> > I don't really have a time estimate. ?My most recent status update was
>> > received a week or two ago.
>> >
>> > In that vein, if anyone wants to make some spiffy code to run the
>> > site, let me know. ?As it is currently hosted, we only get flat-text
>> > files. It is possible to point the domain elsewhere if we want active
>> > content.
>> >
>> > peace,
>> > Andrew
>> >
>> > David Davis wrote:
>> > > Hey everyone,
>> > > Does anyone know why http://losangeles.pm.org/ basn't been updated
>> > > in over a year?
>> > > I know LA.pm is active....I just gave a talk at the last meeting.
>> > > Who has access to update the site?
>> > > David Davis
>> > > ? Software Engineer
>> > > http://xant.us/
>> > > http://xantus.tel/
>> > >
>> > > ------------------------------------------------------------------------
>> > > _______________________________________________
>> > > Losangeles-pm mailing list
>> > > Losangeles-pm at pm.org
>> > > http://mail.pm.org/mailman/listinfo/losangeles-pm
>> >
>> > _______________________________________________
>> > Losangeles-pm mailing list
>> > Losangeles-pm at pm.org
>> > http://mail.pm.org/mailman/listinfo/losangeles-pm
>
>
> _______________________________________________
> Losangeles-pm mailing list
> Losangeles-pm at pm.org
> http://mail.pm.org/mailman/listinfo/losangeles-pm
>

From ask at develooper.com  Tue Aug 11 00:24:16 2009
From: ask at develooper.com (=?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?=)
Date: Tue, 11 Aug 2009 00:24:16 -0700
Subject: [LA.pm] Updating LA.pm's site
In-Reply-To: <2e0b15380908102220u669711bfq21d90b6afa2e70c5@mail.gmail.com>
References: <89f5393a0907291301i3876213fpcd6835d8b46f19bd@mail.gmail.com>
	<4A70B45E.80805@rubiconproject.com> <87y6q7fb46.wl_rs@pobox.com>
	<89f5393a0908101338o6131d075w9038a14fc8047d6d@mail.gmail.com>
	<2e0b15380908102220u669711bfq21d90b6afa2e70c5@mail.gmail.com>
Message-ID: <74ECA592-40DA-4FCC-B97E-439E11E46A28@develooper.com>


On Aug 10, 2009, at 22:20, Tommy Stanton wrote:

> Has anyone played with Melody yet?  It's an open-source version of  
> MoveableType:
>
> http://openmelody.org/about/

I looked at it recently for an upcoming feature on perl.org.  For now  
it is basically just some minor bugfixes on top of a slightly lagged  
version of Movable Type (open source edition).


  - ask

-- 
http://develooper.com/ - http://askask.com/



From kevin+lapm at scaldeferri.com  Wed Aug 12 17:18:43 2009
From: kevin+lapm at scaldeferri.com (Kevin Scaldeferri)
Date: Wed, 12 Aug 2009 17:18:43 -0700
Subject: [LA.pm] Jobs at Gilt Groupe
Message-ID: <F75E47C4-F9A7-46E4-BDF4-468C6A69EA80@scaldeferri.com>

[Let me first acknowledge this is a fairly borderline post for LA.pm,  
since I don't live in LA any more, and the jobs aren't in LA, and the  
jobs don't use Perl.  But, I know there are people on this list who  
are qualified & who have exactly the right sort of experience.  So, I  
apologize to anyone who finds this OT, and hope that most people don't]


I've been working at the Gilt Groupe (http://www.gilt.com/company/careers 
) for about a year now.  We're growing rapidly, both people and  
revenue, just closed a $40mil investment round, and are looking for  
people with a wide range of technical skills: front-end web  
development, back-end server & distributed system development, DBAs,  
sysadmins, and network engineers.

The core technology at Gilt is a platform for flash sales of limited  
inventory at highly discounted prices.  When we start a sale, we can  
see 100x spikes in requests, peaking at Amazon levels.  If this sound  
similar to the problems faced by a certain large employer of Perl  
developers in LA, then you understand why I posted to this list.

If you're interested, please email me and I'll be happy to answer any  
questions and direct your resume in the right direction.


Kevin Scaldeferri
Gilt Groupe, Principal Engineer
(Former Overture/Yahoo)

From agrangaard at rubiconproject.com  Thu Aug 13 18:48:50 2009
From: agrangaard at rubiconproject.com (Andrew Grangaard)
Date: Thu, 13 Aug 2009 18:48:50 -0700
Subject: [LA.pm] August Perl Mongers Announcement -- 8/27/09
Message-ID: <4A84C282.2000803@rubiconproject.com>


    Hello Los Angeles!

    What: Los Angeles Perl Mongers Meeting
    When: 7-9pm
    Date: Thursday, August 27, 2009
    Where: The Rubicon Project HQ - 1925 S. Bundy, 90025
    Theme: Perl!
    Food: Pizza and beverage provided.
    RSVP: Responses always appreciated.

    Open Call for Presenters!!

    What have you done recently with Perl? Come tell your friends and 
let us all learn together!

     Presentations:

     1. Kenny Flegal: unknown presentation. He may be forced to cancel by
        an over-busy work schedule.
     2. You: talking 'bout stuff

     About our speakers:

    Kenny Flegal works at ValueClick, creating a new monitoring 
ubersystem. In his spare time he has a number of ventures to help lift 
others up by their bootstraps.

    You are an awesome perler!

     About your host:

      * Andrew Grangaard is a Senior Software Engineer at the Rubicon
        Project, and long time Perl Monk(ey).
      * The Rubicon Project (http://www.rubiconproject.com)
            The Rubicon Project is an Advertising Technology Company
        headquartered in Los Angeles. Their mission is to automate the
        selling and buying of online advertising.

    See you at 7 on Thursday the 27th

    IFRAME:
 
[1]http://maps.google.com/maps/ms?ie=UTF8&t=h&hl=en&msa=0&msid=116471213422869661926.00046c93dc4ea0b8c84c2&ll=34.034188,-118.457189&spn=0.004425,0.008266&output=embed

    View [2]Rubicon Project in a larger map

    Discuss via comments on my blog [3].  View this information on the 
updated la.pm.org site [4]

References

    1. 
http://maps.google.com/maps/ms?ie=UTF8&t=h&hl=en&msa=0&msid=1164712134228696619
26.00046c93dc4ea0b8c84c2&ll=34.034188,-118.457189&spn=0.004425,0.008266&output=embed
    2. 
http://maps.google.com/maps/ms?ie=UTF8&t=h&hl=en&msa=0&msid=1164712134228696619
26.00046c93dc4ea0b8c84c2&ll=34.034188,-118.457189&spn=0.004425,0.008266&source=embed

    3. 
http://www.lowlevelmanager.com/2009/08/august-la-perl-mongers-meeting.html

    4.
http://la.pm.org

From ehammond at thinksome.com  Tue Aug 18 12:52:05 2009
From: ehammond at thinksome.com (Eric Hammond)
Date: Tue, 18 Aug 2009 12:52:05 -0700
Subject: [LA.pm] LA.pm mailing list not listed on LA.pm web site
Message-ID: <4A8B0665.2080504@thinksome.com>

This page:
  http://losangeles.pm.org/
no longer mentions the LA.pm mailing list.

The Google cache of la.pm.org currently has a mention:
  http://74.125.155.132/search?q=cache:aGgu-sKNSaQJ:la.pm.org/

It looks like the links to neighbor groups was also dropped.

--
Eric Hammond
ehammond at thinksome.com


From ehammond at thinksome.com  Tue Aug 18 13:01:08 2009
From: ehammond at thinksome.com (Eric Hammond)
Date: Tue, 18 Aug 2009 13:01:08 -0700
Subject: [LA.pm] Anthony Curtis presents Perl Stored Procedures for MySQL
Message-ID: <4A8B0884.30502@thinksome.com>

The next Los Angeles MySQL Meetup Group topic might be of interest to
some Perl folks:

  Anthony Curtis presents Perl Stored Procedures for MySQL
  http://www.meetup.com/lamysql/calendar/11002121/

It's happening tomorrow (Wed 19 Aug) at the Sun office in El Segundo.


Less related personal plug: In a couple weeks I will be giving an
extended version of my OSCON 2009 presentation at the same Sun office in
El Segundo for the Unix Users Association of Southern California:

  http://uuasc2009talk.notlong.com

--
Eric Hammond
ehammond at thinksome.com


From david at fetter.org  Tue Aug 18 13:24:38 2009
From: david at fetter.org (David Fetter)
Date: Tue, 18 Aug 2009 13:24:38 -0700
Subject: [LA.pm] Anthony Curtis presents Perl Stored Procedures for	MySQL
In-Reply-To: <4A8B0884.30502@thinksome.com>
References: <4A8B0884.30502@thinksome.com>
Message-ID: <20090818202438.GO14330@fetter.org>

On Tue, Aug 18, 2009 at 01:01:08PM -0700, Eric Hammond wrote:
> The next Los Angeles MySQL Meetup Group topic might be of interest
> to some Perl folks:
> 
>   Anthony Curtis presents Perl Stored Procedures for MySQL
>   http://www.meetup.com/lamysql/calendar/11002121/
> 
> It's happening tomorrow (Wed 19 Aug) at the Sun office in El
> Segundo.

So MySQL is starting to catch up to where PostgreSQL was,
<http://www.postgresql.org/docs/current/static/release-7-0.html>
almost ten years ago?

Congratulations!

Maybe in another ten years, they'll have windowing functions, commonly
used for reporting, and common table expressions, which greatly
simplify trees and other recursive data structures.

Cheers,
David (patient, but a decade is a long time in software)
-- 
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

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

From ask at develooper.com  Tue Aug 18 19:35:36 2009
From: ask at develooper.com (=?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?=)
Date: Wed, 19 Aug 2009 10:35:36 +0800
Subject: [LA.pm] Anthony Curtis presents Perl Stored Procedures for	MySQL
In-Reply-To: <20090818202438.GO14330@fetter.org>
References: <4A8B0884.30502@thinksome.com> <20090818202438.GO14330@fetter.org>
Message-ID: <57734766-6640-45D4-8EE5-ACBB2E7236DA@develooper.com>


On Aug 19, 2009, at 4:24, David Fetter wrote:

> So MySQL is starting to catch up to where PostgreSQL was,
> <http://www.postgresql.org/docs/current/static/release-7-0.html>
> almost ten years ago?

I love how indignant pgsql users often are that anyone would use  
something else; all the while "modern" implementations are moving away  
from having or using any sort of fancy features in the storage  
layer.  :-)


  - ask

-- 
http://develooper.com/ - http://askask.com/



From david at fetter.org  Tue Aug 18 20:01:22 2009
From: david at fetter.org (David Fetter)
Date: Tue, 18 Aug 2009 20:01:22 -0700
Subject: [LA.pm] Anthony Curtis presents Perl Stored Procedures for MySQL
In-Reply-To: <57734766-6640-45D4-8EE5-ACBB2E7236DA@develooper.com>
References: <4A8B0884.30502@thinksome.com> <20090818202438.GO14330@fetter.org>
	<57734766-6640-45D4-8EE5-ACBB2E7236DA@develooper.com>
Message-ID: <20090819030122.GS14330@fetter.org>

On Wed, Aug 19, 2009 at 10:35:36AM +0800, Ask Bj?rn Hansen wrote:
>
> On Aug 19, 2009, at 4:24, David Fetter wrote:
>
>> So MySQL is starting to catch up to where PostgreSQL was,
>> <http://www.postgresql.org/docs/current/static/release-7-0.html>
>> almost ten years ago?
>
> I love how indignant pgsql users often are that anyone would use
> something else; all the while "modern" implementations are moving
> away  from having or using any sort of fancy features in the storage
> layer.  :-)

Here's how it goes, over and over and over again: when MySQL doesn't
have it, it's fluff and nobody could possibly want such frippery, let
alone need it.  When they get some kind of nonstandard, buggy,
hemipygian implementation, it's suddenly the greatest thing and you
can't live without it.

As to this, "storage layer" business, that's what we call the stuff at
the other end of the SCSI (alternate spelling: SAS) cable, or if
you're unlucky, the network cable.

Jim Gray <http://en.wikipedia.org/wiki/Jim_Gray_%28computer_scientist%29>
measured this back in 2003, and those metrics have moved even further
toward his conclusion, which was essentially, "do all the processing
you can as close to where the data lives as you can arrange it."

http://research.microsoft.com/apps/pubs/default.aspx?id=70001

Cheers,
David.
-- 
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

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

From rspier at pobox.com  Tue Aug 18 20:34:25 2009
From: rspier at pobox.com (Robert Spier)
Date: Tue, 18 Aug 2009 20:34:25 -0700
Subject: [LA.pm] LA.pm mailing list not listed on LA.pm web site
In-Reply-To: <4A8B0665.2080504@thinksome.com>
References: <4A8B0665.2080504@thinksome.com>
Message-ID: <87fxboxyri.wl_rs@pobox.com>



Eric Hammond wrote:
> 
> This page:
>   http://losangeles.pm.org/
> no longer mentions the LA.pm mailing list.
> 
> The Google cache of la.pm.org currently has a mention:
>   http://74.125.155.132/search?q=cache:aGgu-sKNSaQJ:la.pm.org/
> 
> It looks like the links to neighbor groups was also dropped.

Looks like it's back now.

Also, Andrew, it would be nice if you'd add the perl.org
site-sponsor-js.html back.

-R

From rspier at pobox.com  Tue Aug 18 20:35:33 2009
From: rspier at pobox.com (Robert Spier)
Date: Tue, 18 Aug 2009 20:35:33 -0700
Subject: [LA.pm] Anthony Curtis presents Perl Stored Procedures for MySQL
In-Reply-To: <4A8B0884.30502@thinksome.com>
References: <4A8B0884.30502@thinksome.com>
Message-ID: <87eir8xypm.wl_rs@pobox.com>


FWIW, 

I work with Antony, and I dare you to try and stump him with a MySQL
related question.  He knows his MySQL, inside, outside, upside down,
and in the twilight zone.

-R


Eric Hammond wrote:
> 
> The next Los Angeles MySQL Meetup Group topic might be of interest to
> some Perl folks:
> 
>   Anthony Curtis presents Perl Stored Procedures for MySQL
>   http://www.meetup.com/lamysql/calendar/11002121/
> 
> It's happening tomorrow (Wed 19 Aug) at the Sun office in El Segundo.
> 
> 
> Less related personal plug: In a couple weeks I will be giving an
> extended version of my OSCON 2009 presentation at the same Sun office in
> El Segundo for the Unix Users Association of Southern California:
> 
>   http://uuasc2009talk.notlong.com
> 
> --
> Eric Hammond
> ehammond at thinksome.com
> 
> _______________________________________________
> Losangeles-pm mailing list
> Losangeles-pm at pm.org
> http://mail.pm.org/mailman/listinfo/losangeles-pm

From adeltac at valueclick.com  Wed Aug 19 11:22:21 2009
From: adeltac at valueclick.com (Aran Deltac)
Date: Wed, 19 Aug 2009 11:22:21 -0700
Subject: [LA.pm] Anthony Curtis presents Perl Stored Procedures for MySQL
In-Reply-To: <20090819030122.GS14330@fetter.org>
References: <4A8B0884.30502@thinksome.com>
	<20090818202438.GO14330@fetter.org><57734766-6640-45D4-8EE5-ACBB2E7236DA@develooper.com>
	<20090819030122.GS14330@fetter.org>
Message-ID: <24CF2B9B9D2BCC4B8F6EA9528B63C8360DF60057@LA-EXCLUST01.corp.valueclick.com>

> -----Original Message-----
> From: losangeles-pm-bounces+adeltac=valueclick.com at pm.org
> [mailto:losangeles-pm-bounces+adeltac=valueclick.com at pm.org] On Behalf
> Of David Fetter
> Sent: Tuesday, August 18, 2009 8:01 PM
> To: Ask Bj?rn Hansen
> Cc: losangeles-pm at pm.org
> Subject: Re: [LA.pm] Anthony Curtis presents Perl Stored Procedures for
> MySQL
> 
> On Wed, Aug 19, 2009 at 10:35:36AM +0800, Ask Bj?rn Hansen wrote:
> >
> > On Aug 19, 2009, at 4:24, David Fetter wrote:
> >
> >> So MySQL is starting to catch up to where PostgreSQL was,
> >> <http://www.postgresql.org/docs/current/static/release-7-0.html>
> >> almost ten years ago?
> >
> > I love how indignant pgsql users often are that anyone would use
> > something else; all the while "modern" implementations are moving
> > away  from having or using any sort of fancy features in the storage
> > layer.  :-)
> 
> Here's how it goes, over and over and over again: when MySQL doesn't
> have it, it's fluff and nobody could possibly want such frippery, let
> alone need it.  When they get some kind of nonstandard, buggy,
> hemipygian implementation, it's suddenly the greatest thing and you
> can't live without it.
> 
> As to this, "storage layer" business, that's what we call the stuff at
> the other end of the SCSI (alternate spelling: SAS) cable, or if
> you're unlucky, the network cable.
> 
> Jim Gray
> <http://en.wikipedia.org/wiki/Jim_Gray_%28computer_scientist%29>
> measured this back in 2003, and those metrics have moved even further
> toward his conclusion, which was essentially, "do all the processing
> you can as close to where the data lives as you can arrange it."
> 
> http://research.microsoft.com/apps/pubs/default.aspx?id=70001

Good info, thanks.

But, I have to agree, the less you do *in* the database, and the more you can shrug off processing to other parts of the system, the better.  I like to treat my database as a very fast flat file storage engine that does very little processing for me.  If I need complex processing, I'll normally create aggregate tables, which are then simple tables that are accessed with simple queries.  Now, this doesn't necessarily contradict the idea of doing data processing as close to where the data lives as possible.  It just rules out the database itself - there are other ways to get close to the DB.  And, of course, there is no one-ring-to-rule them all - sometimes you just have to do it in the database.

This is what Facebook and others do (including my $employer), as much as possible.

Maybe there is truth in your statement that everyone hims-and-haws about how useless features are, and then when MySQL supports it people can't live without it.  But, you should be aware that there is a movement to not do a lot of complex processing within the database itself.  Ignoring that and just assuming that people are being MySQL Zealots isn't going to help anyone.

My 2 cents of opinion.

Aran

> Cheers,
> David.
> --
> 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
> 
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate
> _______________________________________________
> Losangeles-pm mailing list
> Losangeles-pm at pm.org
> http://mail.pm.org/mailman/listinfo/losangeles-pm




This email and any files included with it may contain privileged,
proprietary and/or confidential information that is for the sole use
of the intended recipient(s).  Any disclosure, copying, distribution,
posting, or use of the information contained in or attached to this
email is prohibited unless permitted by the sender.  If you have
received this email in error, please immediately notify the sender
via return email, telephone, or fax and destroy this original transmission
and its included files without reading or saving it in any manner.
Thank you.


From david at fetter.org  Wed Aug 19 11:48:30 2009
From: david at fetter.org (David Fetter)
Date: Wed, 19 Aug 2009 11:48:30 -0700
Subject: [LA.pm] Anthony Curtis presents Perl Stored Procedures for	MySQL
In-Reply-To: <24CF2B9B9D2BCC4B8F6EA9528B63C8360DF60057@LA-EXCLUST01.corp.valueclick.com>
References: <4A8B0884.30502@thinksome.com> <20090818202438.GO14330@fetter.org>
	<57734766-6640-45D4-8EE5-ACBB2E7236DA@develooper.com>
	<20090819030122.GS14330@fetter.org>
	<24CF2B9B9D2BCC4B8F6EA9528B63C8360DF60057@LA-EXCLUST01.corp.valueclick.com>
Message-ID: <20090819184830.GW14330@fetter.org>

On Wed, Aug 19, 2009 at 11:22:21AM -0700, Aran Deltac wrote:
> > Here's how it goes, over and over and over again: when MySQL doesn't
> > have it, it's fluff and nobody could possibly want such frippery, let
> > alone need it.  When they get some kind of nonstandard, buggy,
> > hemipygian implementation, it's suddenly the greatest thing and you
> > can't live without it.
> > 
> > As to this, "storage layer" business, that's what we call the stuff at
> > the other end of the SCSI (alternate spelling: SAS) cable, or if
> > you're unlucky, the network cable.
> > 
> > Jim Gray
> > <http://en.wikipedia.org/wiki/Jim_Gray_%28computer_scientist%29>
> > measured this back in 2003, and those metrics have moved even further
> > toward his conclusion, which was essentially, "do all the processing
> > you can as close to where the data lives as you can arrange it."
> > 
> > http://research.microsoft.com/apps/pubs/default.aspx?id=70001
> 
> Good info, thanks.

Clearly you didn't actually read it, or if you did, you didn't
understand it.

> But, I have to agree, the less you do *in* the database, and the
> more you can shrug off processing to other parts of the system, the
> better.

The more processing you do *as close as possible* to where they data
is actually stored, the better off you are.  Read the paper.

> I like to treat my database as a very fast flat file storage engine
> that does very little processing for me.

Yes, that's a common mistake, but that it's common doesn't make it not
be a mistake.  OO coders are especially prone to this mistake, but
it's far from unknown among other kinds of coders who don't understand
what an RDBMS is or what it does.

> If I need complex processing, I'll normally create aggregate tables,
> which are then simple tables that are accessed with simple queries.
> Now, this doesn't necessarily contradict the idea of doing data
> processing as close to where the data lives as possible.

Actually, it does.

> It just rules out the database itself - there are other ways to get
> close to the DB.  And, of course, there is no one-ring-to-rule them
> all - sometimes you just have to do it in the database.

You've got your assumptions backwards.  There may be times when your
RDBMS simply can't do the work for you, say if you've got a broken
piece of garbage that's at least ten years out of date, and you *have*
to take that network hit, which is massively inefficient.  Even then,
you need to do tremendously many operations on each byte you pull over
the network to make this worthwhile.

> This is what Facebook and others do (including my $employer), as
> much as possible.

Facebook is not making money.  It's losing money, not least because
it's doing things that cost enormous amounts of money like not letting
the RDBMS do what it can.

> Maybe there is truth in your statement that everyone hims-and-haws
> about how useless features are, and then when MySQL supports it
> people can't live without it.  But, you should be aware that there
> is a movement to not do a lot of complex processing within the
> database itself.

I'm aware that there are a bunch of people who've been (usually not
deliberately) misinformed.  That doesn't make them well informed.  It
just makes more work for me when it turns out that approach simply
cannot be made to work.  I suppose if I were more mercenary, I'd
encourage this kind of thing, but I'd rather work on stuff other than
fixing giant systems broken by this kind of misapprehension.

> Ignoring that and just assuming that people are being MySQL Zealots
> isn't going to help anyone.
> 
> My 2 cents of opinion.

Everybody's entitled to an *informed* opinion.  The thing is, Jim Gray
went out and measured in a technology-agnostic way, and he came to the
opposite conclusion.

Perhaps you'll go out and measure something different.  It'll be worth
your very own Turing award if you manage to overturn the result in
that paper.

Cheers,
David.
-- 
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

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

From jbrown at reachlocal.com  Wed Aug 19 12:02:18 2009
From: jbrown at reachlocal.com (Jonathan Brown)
Date: Wed, 19 Aug 2009 12:02:18 -0700
Subject: [LA.pm] Anthony Curtis presents Perl Stored Procedures for	MySQL
In-Reply-To: <20090819184830.GW14330@fetter.org>
References: <4A8B0884.30502@thinksome.com>
	<20090818202438.GO14330@fetter.org><57734766-6640-45D4-8EE5-ACBB2E7236DA@develooper.com><20090819030122.GS14330@fetter.org><24CF2B9B9D2BCC4B8F6EA9528B63C8360DF60057@LA-EXCLUST01.corp.valueclick.com>
	<20090819184830.GW14330@fetter.org>
Message-ID: <39D60072FBFB4E33A94E56F0EBFABCAE@reachloc1d087f>


>> If I need complex processing, I'll normally create aggregate tables, 
>> which are then simple tables that are accessed with simple queries.
>> Now, this doesn't necessarily contradict the idea of doing data 
>> processing as close to where the data lives as possible.

> Actually, it does.

Doing no processing (at least none at query time - but rather offline, so to
speak, by creating aggregate tables) is still faster than doing the
processing at query time but doing it in the db.  That is, it's often more
efficient to do the work once, offline.  Whether that work is done in the db
or slightly above it, it's most likely still faster than doing the word in
the db but at query time.

 

-----Original Message-----
From: losangeles-pm-bounces+jbrown=reachlocal.com at pm.org
[mailto:losangeles-pm-bounces+jbrown=reachlocal.com at pm.org] On Behalf Of
David Fetter
Sent: Wednesday, August 19, 2009 11:49 AM
To: Aran Deltac
Cc: losangeles-pm at pm.org; Ask Bj?rn Hansen
Subject: Re: [LA.pm] Anthony Curtis presents Perl Stored Procedures for
MySQL

On Wed, Aug 19, 2009 at 11:22:21AM -0700, Aran Deltac wrote:
> > Here's how it goes, over and over and over again: when MySQL doesn't 
> > have it, it's fluff and nobody could possibly want such frippery, 
> > let alone need it.  When they get some kind of nonstandard, buggy, 
> > hemipygian implementation, it's suddenly the greatest thing and you 
> > can't live without it.
> > 
> > As to this, "storage layer" business, that's what we call the stuff 
> > at the other end of the SCSI (alternate spelling: SAS) cable, or if 
> > you're unlucky, the network cable.
> > 
> > Jim Gray
> > <http://en.wikipedia.org/wiki/Jim_Gray_%28computer_scientist%29>
> > measured this back in 2003, and those metrics have moved even 
> > further toward his conclusion, which was essentially, "do all the 
> > processing you can as close to where the data lives as you can arrange
it."
> > 
> > http://research.microsoft.com/apps/pubs/default.aspx?id=70001
> 
> Good info, thanks.

Clearly you didn't actually read it, or if you did, you didn't understand
it.

> But, I have to agree, the less you do *in* the database, and the more 
> you can shrug off processing to other parts of the system, the better.

The more processing you do *as close as possible* to where they data is
actually stored, the better off you are.  Read the paper.

> I like to treat my database as a very fast flat file storage engine 
> that does very little processing for me.

Yes, that's a common mistake, but that it's common doesn't make it not be a
mistake.  OO coders are especially prone to this mistake, but it's far from
unknown among other kinds of coders who don't understand what an RDBMS is or
what it does.

> If I need complex processing, I'll normally create aggregate tables, 
> which are then simple tables that are accessed with simple queries.
> Now, this doesn't necessarily contradict the idea of doing data 
> processing as close to where the data lives as possible.

Actually, it does.

> It just rules out the database itself - there are other ways to get 
> close to the DB.  And, of course, there is no one-ring-to-rule them 
> all - sometimes you just have to do it in the database.

You've got your assumptions backwards.  There may be times when your RDBMS
simply can't do the work for you, say if you've got a broken piece of
garbage that's at least ten years out of date, and you *have* to take that
network hit, which is massively inefficient.  Even then, you need to do
tremendously many operations on each byte you pull over the network to make
this worthwhile.

> This is what Facebook and others do (including my $employer), as much 
> as possible.

Facebook is not making money.  It's losing money, not least because it's
doing things that cost enormous amounts of money like not letting the RDBMS
do what it can.

> Maybe there is truth in your statement that everyone hims-and-haws 
> about how useless features are, and then when MySQL supports it people 
> can't live without it.  But, you should be aware that there is a 
> movement to not do a lot of complex processing within the database 
> itself.

I'm aware that there are a bunch of people who've been (usually not
deliberately) misinformed.  That doesn't make them well informed.  It just
makes more work for me when it turns out that approach simply cannot be made
to work.  I suppose if I were more mercenary, I'd encourage this kind of
thing, but I'd rather work on stuff other than fixing giant systems broken
by this kind of misapprehension.

> Ignoring that and just assuming that people are being MySQL Zealots 
> isn't going to help anyone.
> 
> My 2 cents of opinion.

Everybody's entitled to an *informed* opinion.  The thing is, Jim Gray went
out and measured in a technology-agnostic way, and he came to the opposite
conclusion.

Perhaps you'll go out and measure something different.  It'll be worth your
very own Turing award if you manage to overturn the result in that paper.

Cheers,
David.
--
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

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
_______________________________________________
Losangeles-pm mailing list
Losangeles-pm at pm.org
http://mail.pm.org/mailman/listinfo/losangeles-pm


From brucem at dynamicrange.com  Wed Aug 19 12:09:01 2009
From: brucem at dynamicrange.com (Bruce McKenzie)
Date: Wed, 19 Aug 2009 12:09:01 -0700
Subject: [LA.pm] Anthony Curtis presents Perl Stored Procedures for MySQL
In-Reply-To: <87eir8xypm.wl_rs@pobox.com>
References: <4A8B0884.30502@thinksome.com> <87eir8xypm.wl_rs@pobox.com>
Message-ID: <FF9CA6CF-A4F1-4B88-A0DF-7254508415CD@dynamicrange.com>

How many MySQL servers does it take to change a light bulb?

Why did the MySQL developer cross the road?

:-)


On Aug 18, 2009, at 8:35 PM, Robert Spier wrote:
> I work with Antony, and I dare you to try and stump him with a MySQL
> related question.  He knows his MySQL, inside, outside, upside down,
> and in the twilight zone.

---
Bruce McKenzie
brucem at dynamicrange.com




From wdr1 at pobox.com  Wed Aug 19 12:36:16 2009
From: wdr1 at pobox.com (Bill Reardon)
Date: Wed, 19 Aug 2009 12:36:16 -0700
Subject: [LA.pm] Anthony Curtis presents Perl Stored Procedures for	MySQL
In-Reply-To: <39D60072FBFB4E33A94E56F0EBFABCAE@reachloc1d087f>
References: <4A8B0884.30502@thinksome.com>
	<20090818202438.GO14330@fetter.org><57734766-6640-45D4-8EE5-ACBB2E7236DA@develooper.com><20090819030122.GS14330@fetter.org><24CF2B9B9D2BCC4B8F6EA9528B63C8360DF60057@LA-EXCLUST01.corp.valueclick.com>
	<20090819184830.GW14330@fetter.org>
	<39D60072FBFB4E33A94E56F0EBFABCAE@reachloc1d087f>
Message-ID: <4A8C5430.2080001@pobox.com>

Do we really need a Postgres flame war on this list?

Jonathan Brown wrote:
>>> If I need complex processing, I'll normally create aggregate tables, 
>>> which are then simple tables that are accessed with simple queries.
>>> Now, this doesn't necessarily contradict the idea of doing data 
>>> processing as close to where the data lives as possible.
>>>       
>
>   
>> Actually, it does.
>>     
>
> Doing no processing (at least none at query time - but rather offline, so to
> speak, by creating aggregate tables) is still faster than doing the
> processing at query time but doing it in the db.  That is, it's often more
> efficient to do the work once, offline.  Whether that work is done in the db
> or slightly above it, it's most likely still faster than doing the word in
> the db but at query time.
>
>  
>
> -----Original Message-----
> From: losangeles-pm-bounces+jbrown=reachlocal.com at pm.org
> [mailto:losangeles-pm-bounces+jbrown=reachlocal.com at pm.org] On Behalf Of
> David Fetter
> Sent: Wednesday, August 19, 2009 11:49 AM
> To: Aran Deltac
> Cc: losangeles-pm at pm.org; Ask Bj?rn Hansen
> Subject: Re: [LA.pm] Anthony Curtis presents Perl Stored Procedures for
> MySQL
>
> On Wed, Aug 19, 2009 at 11:22:21AM -0700, Aran Deltac wrote:
>   
>>> Here's how it goes, over and over and over again: when MySQL doesn't 
>>> have it, it's fluff and nobody could possibly want such frippery, 
>>> let alone need it.  When they get some kind of nonstandard, buggy, 
>>> hemipygian implementation, it's suddenly the greatest thing and you 
>>> can't live without it.
>>>
>>> As to this, "storage layer" business, that's what we call the stuff 
>>> at the other end of the SCSI (alternate spelling: SAS) cable, or if 
>>> you're unlucky, the network cable.
>>>
>>> Jim Gray
>>> <http://en.wikipedia.org/wiki/Jim_Gray_%28computer_scientist%29>
>>> measured this back in 2003, and those metrics have moved even 
>>> further toward his conclusion, which was essentially, "do all the 
>>> processing you can as close to where the data lives as you can arrange
>>>       
> it."
>   
>>> http://research.microsoft.com/apps/pubs/default.aspx?id=70001
>>>       
>> Good info, thanks.
>>     
>
> Clearly you didn't actually read it, or if you did, you didn't understand
> it.
>
>   
>> But, I have to agree, the less you do *in* the database, and the more 
>> you can shrug off processing to other parts of the system, the better.
>>     
>
> The more processing you do *as close as possible* to where they data is
> actually stored, the better off you are.  Read the paper.
>
>   
>> I like to treat my database as a very fast flat file storage engine 
>> that does very little processing for me.
>>     
>
> Yes, that's a common mistake, but that it's common doesn't make it not be a
> mistake.  OO coders are especially prone to this mistake, but it's far from
> unknown among other kinds of coders who don't understand what an RDBMS is or
> what it does.
>
>   
>> If I need complex processing, I'll normally create aggregate tables, 
>> which are then simple tables that are accessed with simple queries.
>> Now, this doesn't necessarily contradict the idea of doing data 
>> processing as close to where the data lives as possible.
>>     
>
> Actually, it does.
>
>   
>> It just rules out the database itself - there are other ways to get 
>> close to the DB.  And, of course, there is no one-ring-to-rule them 
>> all - sometimes you just have to do it in the database.
>>     
>
> You've got your assumptions backwards.  There may be times when your RDBMS
> simply can't do the work for you, say if you've got a broken piece of
> garbage that's at least ten years out of date, and you *have* to take that
> network hit, which is massively inefficient.  Even then, you need to do
> tremendously many operations on each byte you pull over the network to make
> this worthwhile.
>
>   
>> This is what Facebook and others do (including my $employer), as much 
>> as possible.
>>     
>
> Facebook is not making money.  It's losing money, not least because it's
> doing things that cost enormous amounts of money like not letting the RDBMS
> do what it can.
>
>   
>> Maybe there is truth in your statement that everyone hims-and-haws 
>> about how useless features are, and then when MySQL supports it people 
>> can't live without it.  But, you should be aware that there is a 
>> movement to not do a lot of complex processing within the database 
>> itself.
>>     
>
> I'm aware that there are a bunch of people who've been (usually not
> deliberately) misinformed.  That doesn't make them well informed.  It just
> makes more work for me when it turns out that approach simply cannot be made
> to work.  I suppose if I were more mercenary, I'd encourage this kind of
> thing, but I'd rather work on stuff other than fixing giant systems broken
> by this kind of misapprehension.
>
>   
>> Ignoring that and just assuming that people are being MySQL Zealots 
>> isn't going to help anyone.
>>
>> My 2 cents of opinion.
>>     
>
> Everybody's entitled to an *informed* opinion.  The thing is, Jim Gray went
> out and measured in a technology-agnostic way, and he came to the opposite
> conclusion.
>
> Perhaps you'll go out and measure something different.  It'll be worth your
> very own Turing award if you manage to overturn the result in that paper.
>
> Cheers,
> David.
> --
> 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
>
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate
> _______________________________________________
> Losangeles-pm mailing list
> Losangeles-pm at pm.org
> http://mail.pm.org/mailman/listinfo/losangeles-pm
>
> _______________________________________________
> Losangeles-pm mailing list
> Losangeles-pm at pm.org
> http://mail.pm.org/mailman/listinfo/losangeles-pm
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/losangeles-pm/attachments/20090819/f195168a/attachment.html>

From btilly at gmail.com  Wed Aug 19 12:36:24 2009
From: btilly at gmail.com (Ben Tilly)
Date: Wed, 19 Aug 2009 12:36:24 -0700
Subject: [LA.pm] Anthony Curtis presents Perl Stored Procedures for MySQL
In-Reply-To: <20090819184830.GW14330@fetter.org>
References: <4A8B0884.30502@thinksome.com> <20090818202438.GO14330@fetter.org>
	<57734766-6640-45D4-8EE5-ACBB2E7236DA@develooper.com>
	<20090819030122.GS14330@fetter.org>
	<24CF2B9B9D2BCC4B8F6EA9528B63C8360DF60057@LA-EXCLUST01.corp.valueclick.com>
	<20090819184830.GW14330@fetter.org>
Message-ID: <acc274b30908191236q1fe504d7x462b94b069aa38ee@mail.gmail.com>

2009/8/19 David Fetter <david at fetter.org>:
> On Wed, Aug 19, 2009 at 11:22:21AM -0700, Aran Deltac wrote:
[...]
>> > Jim Gray
>> > <http://en.wikipedia.org/wiki/Jim_Gray_%28computer_scientist%29>
>> > measured this back in 2003, and those metrics have moved even further
>> > toward his conclusion, which was essentially, "do all the processing
>> > you can as close to where the data lives as you can arrange it."
>> >
>> > http://research.microsoft.com/apps/pubs/default.aspx?id=70001
>>
>> Good info, thanks.
>
> Clearly you didn't actually read it, or if you did, you didn't
> understand it.

Are you sure?  Because I read it, and I came to a very different
conclusion than you did.  The conclusion that I came to is that there
is a world of difference between distributing information across the
LAN and across the Internet or a WAN.  In particular his figures show
that the cost of sending data from local hard drive is the same as
sending it across the LAN.  So in a standard client talks to webserver
talks to database scenario, the economics say that pre-processing in
the database is not a big win over sending over raw data and
processing in the webserver.

This assumes, of course, an apples to apples comparison in what you're
doing.  There are many, many factors that can tip your action in
different ways.

>> But, I have to agree, the less you do *in* the database, and the
>> more you can shrug off processing to other parts of the system, the
>> better.
>
> The more processing you do *as close as possible* to where they data
> is actually stored, the better off you are. ?Read the paper.

I did.  His figures indicate that $1 will buy you 10 TB of local disk
access, and 10 TB of local LAN access.  They cost the same amount.  So
moving data to process it then moving it back is an economic loss
(though you may want to do that for performance reasons).  And if data
is moving from database to webserver to client, moving where
processing happens is (assuming all else is equal - sometimes a big
assumption) economically neutral.

>> I like to treat my database as a very fast flat file storage engine
>> that does very little processing for me.
>
> Yes, that's a common mistake, but that it's common doesn't make it not
> be a mistake. ?OO coders are especially prone to this mistake, but
> it's far from unknown among other kinds of coders who don't understand
> what an RDBMS is or what it does.

To clarify, the common mistake is that an OO coder will treat the
database as very fast flat file storage, and then do the equivalent of
a join in code.  If you push work to the database often the database
will come up with a query plan that is a much better algorithm than
the OO coder had come up with.  So by moving processing to the
database you're better off in this case, but that's because databases
are designed to automatically come up with good algorithms, and not
because of the intrinsic economics of the situation.

That's one trade-off saying that we should push work to the database.

An argument for the simple fast flat file storage is that this fits
well with putting a memcached layer in, which moves data to where the
processing happens.

Another argument for moving processing to the database is so that your
business rules are enforced across multiple applications.

Proponents of moving data away can point out that CPU availability on
the database is one of the scalability bottlenecks.  Moving processing
to webservers allows you to scale better.

And so the argument goes back and forth with a variety of subtle
trade-offs.  The real point that we should draw from this is not that
processing should always be pushed to the webserver or the database,
but that there are a lot of trade-offs we need to understand to make a
good choice in any particular case.

[...]
> Everybody's entitled to an *informed* opinion. ?The thing is, Jim Gray
> went out and measured in a technology-agnostic way, and he came to the
> opposite conclusion.
>
> Perhaps you'll go out and measure something different. ?It'll be worth
> your very own Turing award if you manage to overturn the result in
> that paper.

Please step back, re-read the paper, then read what I have said and
see how they compare.  Because from where I sit it appears that you've
oversimplified the message of the paper to an inappropriate degree.

For example read the Caveats section that starts off:

  Beowulf clusters have completely different networking
  economics.  Render farms, materials simulation, and CFD
  fit beautifully on Beowulf clusters because there the
  cost of networking is very inexpensive: a GBps Ethernet
  fabric costs about 200$/port and delivers 50MBps, so
  Beowulf networking costs are comparable to disk
  bandwidth costs ? 10,000 times less than the price of
  Internet transports.

Note that a typical website setups uses the same networking technology
as a Beowulf cluster, and therefore its economics match those of a
Beowulf cluster.  Therefore the conclusions of that paper no more
apply to a typical website than they do a Beowulf cluster.  *UNLESS*,
of course, the website has made the mistake of interactively moving
data over a WAN.

Cheers,
Ben

From adeltac at valueclick.com  Wed Aug 19 13:02:56 2009
From: adeltac at valueclick.com (Aran Deltac)
Date: Wed, 19 Aug 2009 13:02:56 -0700
Subject: [LA.pm] Anthony Curtis presents Perl Stored Procedures for	MySQL
In-Reply-To: <4A8C5430.2080001@pobox.com>
References: <4A8B0884.30502@thinksome.com>
	<20090818202438.GO14330@fetter.org><57734766-6640-45D4-8EE5-ACBB2E7236DA@develooper.com><20090819030122.GS14330@fetter.org><24CF2B9B9D2BCC4B8F6EA9528B63C8360DF60057@LA-EXCLUST01.corp.valueclick.com>
	<20090819184830.GW14330@fetter.org>
	<39D60072FBFB4E33A94E56F0EBFABCAE@reachloc1d087f>
	<4A8C5430.2080001@pobox.com>
Message-ID: <24CF2B9B9D2BCC4B8F6EA9528B63C8360DF60075@LA-EXCLUST01.corp.valueclick.com>

> Do we really need a Postgres flame war on this list?



I don't think it's a flame war - we've mostly been talking about how to properly use databases of any type.  I was really hoping this would be a constructive and informative conversation, which this has mostly been if you can ignore the occasional generalizations.  I've definitely learned a lot this morning, both in ways that affirm my choices, and in ways that make me want to take a second look at other choices.

 

Later,

 

Aran

 

From: William Reardon [mailto:william.reardon at gmail.com] On Behalf Of Bill Reardon
Sent: Wednesday, August 19, 2009 12:36 PM
To: Jonathan Brown
Cc: 'David Fetter'; Aran Deltac; losangeles-pm at pm.org; 'Ask Bj?rn Hansen'
Subject: Re: [LA.pm] Anthony Curtis presents Perl Stored Procedures for MySQL

 

Do we really need a Postgres flame war on this list?

Jonathan Brown wrote: 

		If I need complex processing, I'll normally create aggregate tables, 
		which are then simple tables that are accessed with simple queries.
		Now, this doesn't necessarily contradict the idea of doing data 
		processing as close to where the data lives as possible.
		      

 
  

	Actually, it does.
	    

 
Doing no processing (at least none at query time - but rather offline, so to
speak, by creating aggregate tables) is still faster than doing the
processing at query time but doing it in the db.  That is, it's often more
efficient to do the work once, offline.  Whether that work is done in the db
or slightly above it, it's most likely still faster than doing the word in
the db but at query time.
 
 
 
-----Original Message-----
From: losangeles-pm-bounces+jbrown=reachlocal.com at pm.org
[mailto:losangeles-pm-bounces+jbrown=reachlocal.com at pm.org] On Behalf Of
David Fetter
Sent: Wednesday, August 19, 2009 11:49 AM
To: Aran Deltac
Cc: losangeles-pm at pm.org; Ask Bj?rn Hansen
Subject: Re: [LA.pm] Anthony Curtis presents Perl Stored Procedures for
MySQL
 
On Wed, Aug 19, 2009 at 11:22:21AM -0700, Aran Deltac wrote:
  

		Here's how it goes, over and over and over again: when MySQL doesn't 
		have it, it's fluff and nobody could possibly want such frippery, 
		let alone need it.  When they get some kind of nonstandard, buggy, 
		hemipygian implementation, it's suddenly the greatest thing and you 
		can't live without it.
		 
		As to this, "storage layer" business, that's what we call the stuff 
		at the other end of the SCSI (alternate spelling: SAS) cable, or if 
		you're unlucky, the network cable.
		 
		Jim Gray
		<http://en.wikipedia.org/wiki/Jim_Gray_%28computer_scientist%29> <http://en.wikipedia.org/wiki/Jim_Gray_%28computer_scientist%29> 
		measured this back in 2003, and those metrics have moved even 
		further toward his conclusion, which was essentially, "do all the 
		processing you can as close to where the data lives as you can arrange
		      

it."
  

		http://research.microsoft.com/apps/pubs/default.aspx?id=70001
		      

	Good info, thanks.
	    

 
Clearly you didn't actually read it, or if you did, you didn't understand
it.
 
  

	But, I have to agree, the less you do *in* the database, and the more 
	you can shrug off processing to other parts of the system, the better.
	    

 
The more processing you do *as close as possible* to where they data is
actually stored, the better off you are.  Read the paper.
 
  

	I like to treat my database as a very fast flat file storage engine 
	that does very little processing for me.
	    

 
Yes, that's a common mistake, but that it's common doesn't make it not be a
mistake.  OO coders are especially prone to this mistake, but it's far from
unknown among other kinds of coders who don't understand what an RDBMS is or
what it does.
 
  

	If I need complex processing, I'll normally create aggregate tables, 
	which are then simple tables that are accessed with simple queries.
	Now, this doesn't necessarily contradict the idea of doing data 
	processing as close to where the data lives as possible.
	    

 
Actually, it does.
 
  

	It just rules out the database itself - there are other ways to get 
	close to the DB.  And, of course, there is no one-ring-to-rule them 
	all - sometimes you just have to do it in the database.
	    

 
You've got your assumptions backwards.  There may be times when your RDBMS
simply can't do the work for you, say if you've got a broken piece of
garbage that's at least ten years out of date, and you *have* to take that
network hit, which is massively inefficient.  Even then, you need to do
tremendously many operations on each byte you pull over the network to make
this worthwhile.
 
  

	This is what Facebook and others do (including my $employer), as much 
	as possible.
	    

 
Facebook is not making money.  It's losing money, not least because it's
doing things that cost enormous amounts of money like not letting the RDBMS
do what it can.
 
  

	Maybe there is truth in your statement that everyone hims-and-haws 
	about how useless features are, and then when MySQL supports it people 
	can't live without it.  But, you should be aware that there is a 
	movement to not do a lot of complex processing within the database 
	itself.
	    

 
I'm aware that there are a bunch of people who've been (usually not
deliberately) misinformed.  That doesn't make them well informed.  It just
makes more work for me when it turns out that approach simply cannot be made
to work.  I suppose if I were more mercenary, I'd encourage this kind of
thing, but I'd rather work on stuff other than fixing giant systems broken
by this kind of misapprehension.
 
  

	Ignoring that and just assuming that people are being MySQL Zealots 
	isn't going to help anyone.
	 
	My 2 cents of opinion.
	    

 
Everybody's entitled to an *informed* opinion.  The thing is, Jim Gray went
out and measured in a technology-agnostic way, and he came to the opposite
conclusion.
 
Perhaps you'll go out and measure something different.  It'll be worth your
very own Turing award if you manage to overturn the result in that paper.
 
Cheers,
David.
--
David Fetter <david at fetter.org> <mailto:david at fetter.org>  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter at gmail.com
 
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
_______________________________________________
Losangeles-pm mailing list
Losangeles-pm at pm.org
http://mail.pm.org/mailman/listinfo/losangeles-pm
 
_______________________________________________
Losangeles-pm mailing list
Losangeles-pm at pm.org
http://mail.pm.org/mailman/listinfo/losangeles-pm
  




This email and any files included with it may contain privileged,
proprietary and/or confidential information that is for the sole use
of the intended recipient(s).  Any disclosure, copying, distribution,
posting, or use of the information contained in or attached to this
email is prohibited unless permitted by the sender.  If you have
received this email in error, please immediately notify the sender
via return email, telephone, or fax and destroy this original transmission
and its included files without reading or saving it in any manner.
Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/losangeles-pm/attachments/20090819/89638681/attachment-0001.html>

From agrangaard at rubiconproject.com  Wed Aug 26 23:02:40 2009
From: agrangaard at rubiconproject.com (Andrew Grangaard)
Date: Thu, 27 Aug 2009 02:02:40 -0400
Subject: [LA.pm] (no subject)
Message-ID: <A8A3340A1D68D94CB65744935483C87701050CA3@BE38.exg3.exghost.com>

August LA.PM meeting is tomorrow, Thursday August 27 at 7pm. See you
then. 

LA.PM homepage and directions: [1]

Our two speakers will be: 
* John Beppo 
  John will be talking about a COMET server he wrote in Perl, and 
  integration into existing web applications. 
* Aran Deltac (bluefeet) 
  Aran presents: Destination Moose 
  Aran is an active CPAN developer, a Software Architect and Manager at
ValueClick, 
  the organizer behind the Thousand Oaks Perl Mongers, a member of the
Perl Iron Man
  competition, and an advocate of Modern (aka Enlightened) Perl. 
  cpan: bluefeet [2] | website: bluefeet.net [3]

Thanks guys for agreeing to present! Looking forward to it! 

peace
--Andrew

Feel free to comment via my blog [4]

Links:
1: http://la.pm.org
2: http://search.cpan.org/~bluefeet/
3: http://bluefeet.net
4: http://www.lowlevelmanager.com/2009/08/august-lapm-update.html

From christopher.nielsen at gmail.com  Fri Aug 28 12:38:13 2009
From: christopher.nielsen at gmail.com (Christopher Nielsen)
Date: Fri, 28 Aug 2009 12:38:13 -0700
Subject: [LA.pm] (no subject)
In-Reply-To: <A8A3340A1D68D94CB65744935483C87701050CA3@BE38.exg3.exghost.com>
References: <A8A3340A1D68D94CB65744935483C87701050CA3@BE38.exg3.exghost.com>
Message-ID: <e4ebd7b40908281238t54b8809dpc168e52976253a3f@mail.gmail.com>

> August LA.PM meeting is tomorrow, Thursday August 27 at 7pm. See you then.

> Our two speakers will be:
> * John Beppo
> ?  John will be talking about a COMET server he wrote in Perl, and
> ?  integration into existing web applications.
> * Aran Deltac (bluefeet)
> ?  Aran presents: Destination Moose

This sounds great, how did it go?

(got waylayed by pre-made plans yesterday evening)

-- Chris

-- 
christopher.nielsen at gmail.com
http://rhythm.com/

From migtek at gmail.com  Fri Aug 28 16:01:54 2009
From: migtek at gmail.com (Miguel Hernandez)
Date: Fri, 28 Aug 2009 16:01:54 -0700
Subject: [LA.pm] (no subject)
In-Reply-To: <e4ebd7b40908281238t54b8809dpc168e52976253a3f@mail.gmail.com>
References: <A8A3340A1D68D94CB65744935483C87701050CA3@BE38.exg3.exghost.com>
	<e4ebd7b40908281238t54b8809dpc168e52976253a3f@mail.gmail.com>
Message-ID: <d798c1200908281601j5ada0905y5fe616f4c72babe6@mail.gmail.com>

I'm with Chris in wanting to go but couldn't. Sure sounds like it was a
couple of good topics/presenters.

--miguel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/losangeles-pm/attachments/20090828/028307ca/attachment.html>

From david.davis at gmail.com  Fri Aug 28 16:14:36 2009
From: david.davis at gmail.com (David Davis)
Date: Fri, 28 Aug 2009 16:14:36 -0700
Subject: [LA.pm] (no subject)
In-Reply-To: <d798c1200908281601j5ada0905y5fe616f4c72babe6@mail.gmail.com>
References: <A8A3340A1D68D94CB65744935483C87701050CA3@BE38.exg3.exghost.com>
	<e4ebd7b40908281238t54b8809dpc168e52976253a3f@mail.gmail.com>
	<d798c1200908281601j5ada0905y5fe616f4c72babe6@mail.gmail.com>
Message-ID: <89f5393a0908281614x37069bbfwb04476fd4280005f@mail.gmail.com>

You missed out on some drinking games, texas hold'em and some rock band
action.

We left at 1:30am :)

David Davis
? Software Engineer
http://xant.us/
http://xantus.tel/


2009/8/28 Miguel Hernandez <migtek at gmail.com>

> I'm with Chris in wanting to go but couldn't. Sure sounds like it was a
> couple of good topics/presenters.
>
> --miguel
>
> _______________________________________________
> Losangeles-pm mailing list
> Losangeles-pm at pm.org
> http://mail.pm.org/mailman/listinfo/losangeles-pm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/losangeles-pm/attachments/20090828/5a47e7b7/attachment.html>

From btilly at gmail.com  Fri Aug 28 16:32:39 2009
From: btilly at gmail.com (Ben Tilly)
Date: Fri, 28 Aug 2009 16:32:39 -0700
Subject: [LA.pm] (no subject)
In-Reply-To: <e4ebd7b40908281238t54b8809dpc168e52976253a3f@mail.gmail.com>
References: <A8A3340A1D68D94CB65744935483C87701050CA3@BE38.exg3.exghost.com>
	<e4ebd7b40908281238t54b8809dpc168e52976253a3f@mail.gmail.com>
Message-ID: <acc274b30908281632m66a59e5btf2cbb561d2922478@mail.gmail.com>

On Fri, Aug 28, 2009 at 12:38 PM, Christopher
Nielsen<christopher.nielsen at gmail.com> wrote:
>> August LA.PM meeting is tomorrow, Thursday August 27 at 7pm. See you then.
>
>> Our two speakers will be:
>> * John Beppo
>> ? ?John will be talking about a COMET server he wrote in Perl, and
>> ? ?integration into existing web applications.
>> * Aran Deltac (bluefeet)
>> ? ?Aran presents: Destination Moose
>
> This sounds great, how did it go?

It was good.  And not just the prepared talks and fun and games
afterwards.  We had digressions on things from JavaScript-influenced
Perl coding styles to what roles were.

On the subject of co-routines I mentioned that my favorite paper on
the subject was how they are implemented in C (!) in PuTTY.  That
paper is http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html.
I really like the bit of it which says:

  Any coding standard which insists on syntactic
  clarity at the expense of algorithmic clarity should be
  rewritten. If your employer fires you for using this
  trick, tell them that repeatedly as the security staff
  drag you out of the building.

Cheers,
Ben