From tuon1 at netzero.net  Thu Mar  3 00:09:32 2011
From: tuon1 at netzero.net (tuon1 at netzero.net)
Date: Thu, 3 Mar 2011 05:09:32 GMT
Subject: [nycphp-talk] talk Digest, Vol 52, Issue 10
Message-ID: <20110302.230932.7996.0@webmail03.dca.untd.com>

On 2/27/2011 8:57 AM, ?? wrote:
> I'm a php developer (beginning level) and I really want to join a
> community or a group to discuss php or do trouble-shooting.
>
> Any recommendation?

Welcome, 
You might want to check out the PHP developing resources at http://www.ZeroNilZilch.com also since it offers a lot of programming resources for beginners.
Thanks!
Paul Tuon


---------- Original Message ----------
From: talk-request at lists.nyphp.org
To: talk at lists.nyphp.org
Subject: talk Digest, Vol 52, Issue 10
Date: Sun, 27 Feb 2011 12:00:01 -0500

Send talk mailing list submissions to
talk at lists.nyphp.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.nyphp.org/mailman/listinfo/talk
or, via email, send a message with subject or body 'help' to
talk-request at lists.nyphp.org

You can reach the person managing the list at
talk-owner at lists.nyphp.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of talk digest..."


Today's Topics:

  1. Could anyone recommend one or more popular php community,
     please? (??)
  2. Re: Could anyone recommend one or more popular php community,
     please? (David Krings)
  3. Re: Could anyone recommend one or more popular php community,
     please? (tedd)


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

Message: 1
Date: Sun, 27 Feb 2011 21:57:34 +0800
From: ?? <zhangji87 at gmail.com>
To: talk at lists.nyphp.org
Subject: [nycphp-talk] Could anyone recommend one or more popular php
community, please?
Message-ID:
<AANLkTimPybJ+H6KYPDp80o6LD1Ja6hC8WMpD2rTGLocL at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

I'm a php developer (beginning level) and I really want to join a
community or a group to discuss php or do trouble-shooting.

Any recommendation?


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

Message: 2
Date: Sun, 27 Feb 2011 09:10:00 -0500
From: David Krings <ramons at gmx.net>
To: NYPHP Talk <talk at lists.nyphp.org>
Subject: Re: [nycphp-talk] Could anyone recommend one or more popular
php community, please?
Message-ID: <4D6A5B38.6070304 at gmx.net>
Content-Type: text/plain; charset=UTF-8; format=flowed

On 2/27/2011 8:57 AM, ?? wrote:
> I'm a php developer (beginning level) and I really want to join a
> community or a group to discuss php or do trouble-shooting.
>
> Any recommendation?

Yea, the NYPHP talk list. Welcome!


David


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

Message: 3
Date: Sun, 27 Feb 2011 11:12:44 -0500
From: tedd <tedd.sperling at gmail.com>
To: NYPHP Talk <talk at lists.nyphp.org>
Subject: Re: [nycphp-talk] Could anyone recommend one or more popular
php community, please?
Message-ID: <p06240804c9902736b2f9@[192.168.1.4]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 9:57 PM +0800 2/27/11, =?UTF-8?B?5byg5ZCJ?= wrote:
>I'm a php developer (beginning level) and I really want to join a
>community or a group to discuss php or do trouble-shooting.
>
>Any recommendation?

Yes, you could join the php General user List -- it has a lot more traffic.

http://php.net/mailing-lists.php

Cheers,

tedd

-- 
-------
http://sperling.com/


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

_______________________________________________
talk mailing list
talk at lists.nyphp.org
http://lists.nyphp.org/mailman/listinfo/talk

End of talk Digest, Vol 52, Issue 10
************************************


____________________________________________________________
Get Free Email with Video Mail & Video Chat!
http://www.netzero.net/freeemail?refcd=NZTAGOUT1FREM0210
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20110303/4fb589e0/attachment.html>

From garyamort at gmail.com  Fri Mar  4 14:30:25 2011
From: garyamort at gmail.com (Gary Mort)
Date: Fri, 04 Mar 2011 14:30:25 -0500
Subject: [nycphp-talk] The user table
Message-ID: <4D713DD1.2080801@gmail.com>

After a number of....odd fights with user tables I'm coming the 
conclusion that Mitch is right.

The typical user table starts with 3 bits of information:
A userid
A username
An email address.
A one way encrypted password

Maybe....MAYBE some user status info...

And it demands that the first three of those fields be unique.  If you 
don't make those fields unique, Bad Things will happen when other apps 
that assume their unique find out their not.

If you have 3 fields, userid, username, and email address - and they 
each need to be unique....well then, that is completely redundant and 
there is no need for it.

Get rid of 2 of them.  And the one that makes the most sense to keep is 
username.

Oh, and get rid of that password as well.  It doesn't need to be in that 
table and because it is assumed to be there, I have to do some really 
hackish things when one wants to authenticate in some other way.


"But, but but.....  what if they want to receive a password reset 
request?" - take that email address and put it in a contacts table.  Tie 
it to their username and flag it as the primary.

What if they want to change their username?
Keep an aka table and timestamp it.  Everytime a username is set, mark 
it in the aka table with a start time and a null end time.  Get in the 
habit of checking the also known's when checking user data.   Oh, and to 
make things not take forever, when a user updates their username, set 
their new name immediately and fire off a queue process to check through 
the database and clean up existing data.

What?  No password?  - yes, no password.  Instead, have an "access key" 
table tied to....you guessed it, username!  An access key table can 
specify the username, the process to use to verify access, and any 
supplemental information you may need.  This means you can handle API 
keys, REST keys, user passwords, etc all from one set of data.    I've 
had to fight a number of times to prevent an existing system from using 
the default password/username method of logging users on because a 
client wanted a different authentication method.   And it's always 
frustrating not knowing if some /other/ app that will be installed might 
bypass the API and check directly.  By moving this data out of the user 
table, you make it so everyone has to explicitly check for 
authentication methods.


Lastly, in there is one problem with getting rid of userid's.   When a 
dumb American is trying to troubleshoot a user problem, sometimes it is 
very difficult over the phone to get correct spelling.   But that is 
easily handled by the aka table.   Assign everyone an identifier in that 
table for those times when you need something short and easy.  Just make 
sure if you do that to make it something easily communicated over the phone.


From rmarscher at beaffinitive.com  Fri Mar  4 14:41:53 2011
From: rmarscher at beaffinitive.com (Rob Marscher)
Date: Fri, 4 Mar 2011 14:41:53 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <4D713DD1.2080801@gmail.com>
References: <4D713DD1.2080801@gmail.com>
Message-ID: <3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>

Some nice thoughts.  Thanks for sharing.

On Mar 4, 2011, at 2:30 PM, Gary Mort wrote:
> Get rid of 2 of them.  And the one that makes the most sense to keep is username.

There's probably some sites where people don't even want to bother creating a username and just use an email address.  But then again... if you're using something like Facebook login and don't want to ask for extra permissions, then you don't have an email and then what...

So maybe it's good to take the email address and auto-generate a username from it just like you could take the person's first name and last name from Facebook and create a username from that -- even if your site doesn't actually display the username anywhere to the person on the site.




From dj at waletzky.com  Fri Mar  4 15:07:13 2011
From: dj at waletzky.com (D. J. Waletzky)
Date: Fri, 04 Mar 2011 15:07:13 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>
References: <4D713DD1.2080801@gmail.com>
	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>
Message-ID: <1299269233.1684.60.camel@saltworthy>

The problem with eliminating "redundant" info in a user table is that it
may not scale terribly well. I always take care to give any user table
an auto_incremented row number/uid, because the user's handle and
e-mail, though unique, may change. Without an independent index
changing either of these columns in the user table will cause all kinds
of headaches in other linked tables. With a row number you can save
space and CPU cycles by using numeric IDs for foreign keys.

You also have to look at the number of tables you want to have; for a
small user base, it may make more sense to keep the number of discrete
tales to a minimum and retain more info in a smaller number of tables
(say, one of them). 

I'd say that unless you have more than 4000 users (depending on the
limits of your db host) you can probably get away with keeping the
number of tables small and the numbers of columns somewhat high. It's
always best to run some sample queries to get a sense of how long they
might take.

Just my two cents!

--
D. J. Waletzky
dj at waletzky.com
646.209.0004
http://dj.waletzky.com/
"Non sunt multiplicanda entia praeter necessitam."



On Fri, 2011-03-04 at 14:41 -0500, Rob Marscher wrote:
> Some nice thoughts.  Thanks for sharing.
> 
> On Mar 4, 2011, at 2:30 PM, Gary Mort wrote:
> > Get rid of 2 of them.  And the one that makes the most sense to keep is username.
> 
> There's probably some sites where people don't even want to bother creating a username and just use an email address.  But then again... if you're using something like Facebook login and don't want to ask for extra permissions, then you don't have an email and then what...
> 
> So maybe it's good to take the email address and auto-generate a username from it just like you could take the person's first name and last name from Facebook and create a username from that -- even if your site doesn't actually display the username anywhere to the person on the site.
> 
> 
> _______________________________________________
> New York PHP Users Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
> 
> http://www.nyphp.org/Show-Participation




From paul at devonianfarm.com  Fri Mar  4 15:15:06 2011
From: paul at devonianfarm.com (Paul A Houle)
Date: Fri, 04 Mar 2011 15:15:06 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <4D713DD1.2080801@gmail.com>
References: <4D713DD1.2080801@gmail.com>
Message-ID: <4D71484A.3050704@devonianfarm.com>

  On 3/4/2011 2:30 PM, Gary Mort wrote:
>
> Oh, and get rid of that password as well.  It doesn't need to be in 
> that table and because it is assumed to be there, I have to do some 
> really hackish things when one wants to authenticate in some other way.
>
     I've kept the password in a separate table for a long time.  This 
makes it easy to send somebody (like a developer) a copy of the database 
with the password redacted.

     In the latest system I've built I have a 'credential' table that 
can represent credentials of different kinds.  This can be a password 
for local login or it can be whatever information is needed to validate 
someone as a Facebook Connect,  Twitter or OpenId user.  Users can have 
multiple credentials.  I think that user-facing web sites in 2011 and 
beyond are going to want to have the option of federated login.

> Keep an aka table and timestamp it.  Everytime a username is set, mark 
> it in the aka table with a start time and a null end time.  Get in the 
> habit of checking the also known's when checking user data.   Oh, and 
> to make things not take forever, when a user updates their username, 
> set their new name immediately and fire off a queue process to check 
> through the database and clean up existing data.
>
     I think you should always use the internal id in anything that 
appears in the database,  although you might show the username in the UI 
at times.  If changing the username involves anything other than 
changing one column in the table,  there's malpractice going on.  (Like 
the hard-coded URLs in Wordpress)

>
> Lastly, in there is one problem with getting rid of userid's.   When a 
> dumb American is trying to troubleshoot a user problem, sometimes it 
> is very difficult over the phone to get correct spelling.   But that 
> is easily handled by the aka table.   Assign everyone an identifier in 
> that table for those times when you need something short and easy.  
> Just make sure if you do that to make it something easily communicated 
> over the phone.
     My eight year old has a lisp,  so I've trained him in the 
international phonetic code (Alfa, Bravo, Charlie, ...)  People always 
understand what you're saying,  and if you're speaking and can't 
remember the word you can ad-lib it.


From paul at devonianfarm.com  Fri Mar  4 15:17:45 2011
From: paul at devonianfarm.com (Paul A Houle)
Date: Fri, 04 Mar 2011 15:17:45 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <1299269233.1684.60.camel@saltworthy>
References: <4D713DD1.2080801@gmail.com>	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>
	<1299269233.1684.60.camel@saltworthy>
Message-ID: <4D7148E9.10709@devonianfarm.com>

  On 3/4/2011 3:07 PM, D. J. Waletzky wrote:
> I'd say that unless you have more than 4000 users (depending on the
> limits of your db host) you can probably get away with keeping the
> number of tables small and the numbers of columns somewhat high. It's
> always best to run some sample queries to get a sense of how long they
> might take.
     In some systems I've built that operate (or may operate) in the 
N>100,000 range,  I have a 'hot' table that contains a small number 
fixed length fields that change often,  such as

* date/time of last login
* date/time of second last login
* total number of logins

     Updates to this table should be quick because this table can become 
a bottleneck on a heavily used system.



From garyamort at gmail.com  Fri Mar  4 16:30:08 2011
From: garyamort at gmail.com (Gary Mort)
Date: Fri, 04 Mar 2011 16:30:08 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>
References: <4D713DD1.2080801@gmail.com>
	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>
Message-ID: <4D7159E0.1020302@gmail.com>

On 3/4/2011 2:41 PM, Rob Marscher wrote:
> Some nice thoughts.  Thanks for sharing.
>
> On Mar 4, 2011, at 2:30 PM, Gary Mort wrote:
>> Get rid of 2 of them.  And the one that makes the most sense to keep is username.
> There's probably some sites where people don't even want to bother creating a username and just use an email address.

In that case, email address is the username.  :-)  Username for the 
database is just some transitory unique value used to identify an 
individual.

The thing is, once you start really really thinking like that, there are 
all sorts of hackish things you can stop doing.  For example, everyone 
who visits the website is automatically assigned a 'username' and while 
you still treat them as anonymous, you let them do many things on the 
website a normal user can do[make comments, put stuff in carts, 
etc]...you just don't finalize/publish that stuff.

Then when they "logon", you just merge their two accounts.  Their phony 
username is registered to the aka database, and everything they did can 
become 'live'.




From garyamort at gmail.com  Sat Mar  5 13:27:10 2011
From: garyamort at gmail.com (Gary Mort)
Date: Sat, 05 Mar 2011 13:27:10 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <1299269233.1684.60.camel@saltworthy>
References: <4D713DD1.2080801@gmail.com>	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>
	<1299269233.1684.60.camel@saltworthy>
Message-ID: <4D72807E.1060006@gmail.com>

On 3/4/2011 3:07 PM, D. J. Waletzky wrote:
> The problem with eliminating "redundant" info in a user table is that it
> may not scale terribly well. I always take care to give any user table
> an auto_incremented row number/uid, because the user's handle and
> e-mail, though unique, may change. Without an independent index
> changing either of these columns in the user table will cause all kinds
> of headaches in other linked tables. With a row number you can save
> space and CPU cycles by using numeric IDs for foreign keys.

I am no longer convinced that the cpu cycles saved by using a numeric id 
are sufficient to justify doing so with todays computers.  By the time 
you get to an app that is sizable enough to be looking to shave those 
few microseconds, your going to be dealing with a large number of ways 
to save space....and your likely going to want to stick the user mapping 
data into a cache in memory somewhere anyway, so the time saved is not 
that big of a deal.

Also, my main thinking is not from "your custom app written to satisify 
the needs of Woot on a Woot off day"...  I'm thinking more about "your 
open source project designed to be installed on mom and pop systems".

When you have to design to scale, you can go back through and make 
changes for that and afford it.  But trying to design the ideal user 
table structure for a general purpose app and sticking to "good design 
practices" from decades ago is not the best call.

Check the Joomla! or Drupal forums and you will find many people going 
in and doing very hackish things to get the user database to work the 
way they want it.   Not all users of all sites have/want to give you 
their email address[think actual face to face clubs], but both systems 
not only demand one, they demand a unique one.  So the simple solution 
of just assigning all these users the owners email address does not 
work.  I forget which one, I think it was Joomla! , does not recognize 
valid email addresses with a + in them, so you can't even use the common 
trick of <emailname>+<uniqueid>@<domain> .  Well, you can, but you have 
to hack into core code to do it.

Using the outline I specified, you can switch from using "username" as 
the key display to "userid" when and if you need to scale[create an 
update script to map all those names to integers and do it in a batch].

The main thing I'm looking at though is that it is better, in my mind, 
to design a less efficient, more flexible system that everyone can use - 
and place the cost on "tuning" it for scalability on those who can most 
afford it[since if you need to scale and can't afford to pay for it, you 
have a problem], than to make things a little easier for scalability at 
the cost of making more people pay to customize/hack it.




From ramons at gmx.net  Sat Mar  5 16:54:55 2011
From: ramons at gmx.net (David Krings)
Date: Sat, 05 Mar 2011 16:54:55 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <1299269233.1684.60.camel@saltworthy>
References: <4D713DD1.2080801@gmail.com>	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>
	<1299269233.1684.60.camel@saltworthy>
Message-ID: <4D72B12F.3030406@gmx.net>

On 3/4/2011 3:07 PM, D. J. Waletzky wrote:
> The problem with eliminating "redundant" info in a user table is that it
> may not scale terribly well. I always take care to give any user table
> an auto_incremented row number/uid, because the user's handle and
> e-mail, though unique, may change. Without an independent index
> changing either of these columns in the user table will cause all kinds
> of headaches in other linked tables. With a row number you can save
> space and CPU cycles by using numeric IDs for foreign keys.

 From my experience it isn't worth the effort to remove "redundant" info, what 
I assume is meant as normalizing tables. I don't think the numeric key is the 
culprit in scaling issues, but the many joins one has to make across tables. 
Also, when something goes wrong and you need to dig through the tables it is a 
pain in the you know where to hangle from one table to the other to gather up 
all the information that you need.
Stick everything into one table and if it makes sense duplicate partial data 
in a different table to minimize joins. Not only are the queries much simpler 
then and get executed faster, figuring out what goes on is also much easier. 
As a side effect you can find data inaccuracies easier and fix them as well. 
The downside is drive space usage, which will go up. But the times where a 
120MB hard drive cost 800$ are long gone - and so is the prime reason for 
normalization.


David


From rmarscher at beaffinitive.com  Sun Mar  6 08:33:41 2011
From: rmarscher at beaffinitive.com (Rob Marscher)
Date: Sun, 6 Mar 2011 08:33:41 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <4D72B12F.3030406@gmx.net>
References: <4D713DD1.2080801@gmail.com>	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>
	<1299269233.1684.60.camel@saltworthy> <4D72B12F.3030406@gmx.net>
Message-ID: <3442BF77-76F5-4105-BE0F-B2D3809F1348@beaffinitive.com>


On Mar 5, 2011, at 4:54 PM, David Krings wrote:
> Stick everything into one table and if it makes sense duplicate partial data in a different table to minimize joins. Not only are the queries much simpler then and get executed faster, figuring out what goes on is also much easier. As a side effect you can find data inaccuracies easier and fix them as well. The downside is drive space usage, which will go up. But the times where a 120MB hard drive cost 800$ are long gone - and so is the prime reason for normalization.

This pretty much sums up why "nosql" databases have become so popular lately.

From tedd.sperling at gmail.com  Sun Mar  6 15:46:13 2011
From: tedd.sperling at gmail.com (tedd)
Date: Sun, 6 Mar 2011 15:46:13 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <4D72B12F.3030406@gmx.net>
References: <4D713DD1.2080801@gmail.com>
	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>
	<1299269233.1684.60.camel@saltworthy> <4D72B12F.3030406@gmx.net>
Message-ID: <p06240803c9999fbfea87@[192.168.1.4]>

At 4:54 PM -0500 3/5/11, David Krings wrote:
>On 3/4/2011 3:07 PM, D. J. Waletzky wrote:
>>The problem with eliminating "redundant" info in a user table is that it
>>may not scale terribly well. I always take care to give any user table
>>an auto_incremented row number/uid, because the user's handle and
>>e-mail, though unique, may change. Without an independent index
>>changing either of these columns in the user table will cause all kinds
>>of headaches in other linked tables. With a row number you can save
>>space and CPU cycles by using numeric IDs for foreign keys.
>
>From my experience it isn't worth the effort to remove "redundant" 
>info, what I assume is meant as normalizing tables. I don't think 
>the numeric key is the culprit in scaling issues, but the many joins 
>one has to make across tables. Also, when something goes wrong and 
>you need to dig through the tables it is a pain in the you know 
>where to hangle from one table to the other to gather up all the 
>information that you need.
>Stick everything into one table and if it makes sense duplicate 
>partial data in a different table to minimize joins. Not only are 
>the queries much simpler then and get executed faster, figuring out 
>what goes on is also much easier. As a side effect you can find data 
>inaccuracies easier and fix them as well. The downside is drive 
>space usage, which will go up. But the times where a 120MB hard 
>drive cost 800$ are long gone - and so is the prime reason for 
>normalization.
>
>David


You won't have any "redundant" info if you use email as unique -- 
after all, email *IS* unique.

You can use id's as an index so that MySQL can find the records 
quicker, but removing redundant data  is not "normalizing". 
"Normalizing" is using remote keys to reduce data redundancy.

For example, if you have table containing people Names and their 
Professions, you might be well advised to have two tables, namely: 
One holding the names of the people (i.e., People Table); and One 
holding the type of professions (i.e., Profession Table), such as:

Profession-Table
ID  Type
1.  Mailman
2.  Fireman
3.  Policeman

People-Table
ID  Name  Profession_ID
1.   tedd   1
2.  Sam   1
3.   Jane   3
4.   Bill   2
5.   Joe   1

and so on --You see,  that is "normalized".

Cheers,

tedd

-- 
-------
http://sperling.com/


From ramons at gmx.net  Sun Mar  6 18:46:36 2011
From: ramons at gmx.net (David Krings)
Date: Sun, 06 Mar 2011 18:46:36 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <p06240803c9999fbfea87@[192.168.1.4]>
References: <4D713DD1.2080801@gmail.com>	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>	<1299269233.1684.60.camel@saltworthy>
	<4D72B12F.3030406@gmx.net> <p06240803c9999fbfea87@[192.168.1.4]>
Message-ID: <4D741CDC.8020805@gmx.net>

On 3/6/2011 3:46 PM, tedd wrote:
> You won't have any "redundant" info if you use email as unique -- after all,
> email *IS* unique.

Unique yes, but it can change. You'd need to change the primary key of a 
record if a user wants to use a different email address. Not sure if that is a 
smart thing to do. You'd need to update all related records, which wouldn't be 
necessary when using an integer as primary key that is only data and not 
information.

As far as normalization goes, I represented it the way it was once explained 
to me, which I do not insist on being correct. In any case, I think I got the 
point across of the practical benefit of not splitting up related data across 
multiple tables. There are many ways to do it and some say it is right to do 
it that way, others say it is better to do it this way. In my experience the 
approach I detailed is what works for us best for an enterprise product. Of 
course, Celko probably calls us all idiots and has a totally different opinion 
on how to do things.

David


From rmarscher at beaffinitive.com  Sun Mar  6 19:04:55 2011
From: rmarscher at beaffinitive.com (Rob Marscher)
Date: Sun, 6 Mar 2011 19:04:55 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <4D741CDC.8020805@gmx.net>
References: <4D713DD1.2080801@gmail.com>	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>	<1299269233.1684.60.camel@saltworthy>
	<4D72B12F.3030406@gmx.net> <p06240803c9999fbfea87@[192.168.1.4]>
	<4D741CDC.8020805@gmx.net>
Message-ID: <6E58C458-5A54-40F2-8B30-FCB611F8B1F5@beaffinitive.com>


On Mar 6, 2011, at 6:46 PM, David Krings wrote:
> On 3/6/2011 3:46 PM, tedd wrote:
>> You won't have any "redundant" info if you use email as unique -- after all,
>> email *IS* unique.
> Unique yes, but it can change.

I think in Gary's original post, he was talking about having an alias table to account for the username (or email or whatever) changing.  But I guess once it changes, those primary keys are no longer useful data and you might as well have used an id in the first place.




From matt at atopia.net  Sun Mar  6 22:26:05 2011
From: matt at atopia.net (Matt Juszczak)
Date: Sun, 6 Mar 2011 22:26:05 -0500 (EST)
Subject: [nycphp-talk] The user table
In-Reply-To: <3442BF77-76F5-4105-BE0F-B2D3809F1348@beaffinitive.com>
References: <4D713DD1.2080801@gmail.com>
	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>
	<1299269233.1684.60.camel@saltworthy> <4D72B12F.3030406@gmx.net>
	<3442BF77-76F5-4105-BE0F-B2D3809F1348@beaffinitive.com>
Message-ID: <alpine.BSF.2.00.1103062225200.4227@venus.atopia.net>

> This pretty much sums up why "nosql" databases have become so popular lately.

Yes, but most nosql databases aren't designed for durability or reliable 
persistence.  Remember -- one can always use MySQL as a "noSQL" DB by 
simply de-normalizing, or applying the "schemaless" patch.


From andrew at plexpod.com  Sun Mar  6 22:56:20 2011
From: andrew at plexpod.com (Andrew Yochum)
Date: Sun, 06 Mar 2011 22:56:20 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <alpine.BSF.2.00.1103062225200.4227@venus.atopia.net>
References: <4D713DD1.2080801@gmail.com>	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>	<1299269233.1684.60.camel@saltworthy>
	<4D72B12F.3030406@gmx.net>	<3442BF77-76F5-4105-BE0F-B2D3809F1348@beaffinitive.com>
	<alpine.BSF.2.00.1103062225200.4227@venus.atopia.net>
Message-ID: <4D745764.5090606@plexpod.com>

On 3/6/11 10:26 PM, Matt Juszczak wrote:
>> This pretty much sums up why "nosql" databases have become so popular 
>> lately.
>
> Yes, but most nosql databases aren't designed for durability or 
> reliable persistence.  Remember -- one can always use MySQL as a 
> "noSQL" DB by simply de-normalizing, or applying the "schemaless" patch.
I'm quite familiar with means of using MySQL in NoSQL ways, but what is 
this "schemaless" patch you speak of?

Regards,
Andrew

-- 
Andrew Yochum
Plexpod
andrew at plexpod.com
office: 718-360-0879
mobile: 347-688-4699
http://twitter.com/plexpod
http://fb.com/plexpod





From matt at atopia.net  Sun Mar  6 23:46:35 2011
From: matt at atopia.net (Matt Juszczak)
Date: Sun, 6 Mar 2011 23:46:35 -0500 (EST)
Subject: [nycphp-talk] The user table
In-Reply-To: <4D745764.5090606@plexpod.com>
References: <4D713DD1.2080801@gmail.com>
	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>
	<1299269233.1684.60.camel@saltworthy> <4D72B12F.3030406@gmx.net>
	<3442BF77-76F5-4105-BE0F-B2D3809F1348@beaffinitive.com>
	<alpine.BSF.2.00.1103062225200.4227@venus.atopia.net>
	<4D745764.5090606@plexpod.com>
Message-ID: <alpine.BSF.2.00.1103062346170.4923@venus.atopia.net>

> I'm quite familiar with means of using MySQL in NoSQL ways, but what is this 
> "schemaless" patch you speak of?

Not sure if this was the one I used originally, but a quick google pulled 
this one up:

http://www.igvita.com/2010/03/01/schema-free-mysql-vs-nosql/


From tedd.sperling at gmail.com  Mon Mar  7 10:06:14 2011
From: tedd.sperling at gmail.com (tedd)
Date: Mon, 7 Mar 2011 10:06:14 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <4D741CDC.8020805@gmx.net>
References: <4D713DD1.2080801@gmail.com>
	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>
	<1299269233.1684.60.camel@saltworthy>	<4D72B12F.3030406@gmx.net>
	<p06240803c9999fbfea87@[192.168.1.4]> <4D741CDC.8020805@gmx.net>
Message-ID: <p06240803c99aa0d32a4f@[192.168.1.4]>

At 6:46 PM -0500 3/6/11, David Krings wrote:
>On 3/6/2011 3:46 PM, tedd wrote:
>>You won't have any "redundant" info if you use email as unique -- after all,
>>email *IS* unique.
>
>Unique yes, but it can change.

If that is the case, then change it -- I don't see a problem. I do 
see a problem IF one wants to keep both email addresses as indexes 
for that record. An index must be unique.

The main point here is that you must have a unique identifier for 
each record. Some way to access *that* record. You may choose 
anything you wish -- such as: email address, social security number, 
time of record entry with a random extension, or an auto-increment 
id. The choice is yours, but the final choice should be unique. You 
must be able to find the record without ambiguity.

----
>You'd need to change the primary key of a record if a user wants to 
>use a different email address.

No, you are misunderstanding what a "primary key of a record" of a 
record is -- it is simply unique. As said before, it can be anything 
you want provided that it is unique.

----
>Not sure if that is a smart thing to do. You'd need to update all 
>related records, which wouldn't be necessary when using an integer 
>as primary key that is only data and not information.

You are misunderstanding the process. There is no "update [of] all 
related records" -- you are simply changing a single record. That 
record contains all data necessary for that record including all keys 
to remote tables -- there is *NO* reason to change any remote key.

----
>As far as normalization goes, I represented it the way it was once 
>explained to me, which I do not insist on being correct. In any 
>case, I think I got the point across of the practical benefit of not 
>splitting up related data across multiple tables. There are many 
>ways to do it and some say it is right to do it that way, others say 
>it is better to do it this way. In my experience the approach I 
>detailed is what works for us best for an enterprise product. Of 
>course, Celko probably calls us all idiots and has a totally 
>different opinion on how to do things.

Normalization of a database is simply moving redundant data to remote 
tables and replacing that data with remote keys to those tables, as I 
demonstrated in my last post.

People can often over-think this process. but it is a very simple concept.

Cheers,

tedd

-- 
-------
http://sperling.com/


From paul at devonianfarm.com  Mon Mar  7 14:28:45 2011
From: paul at devonianfarm.com (Paul A Houle)
Date: Mon, 07 Mar 2011 14:28:45 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <alpine.BSF.2.00.1103062225200.4227@venus.atopia.net>
References: <4D713DD1.2080801@gmail.com>	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>	<1299269233.1684.60.camel@saltworthy>
	<4D72B12F.3030406@gmx.net>	<3442BF77-76F5-4105-BE0F-B2D3809F1348@beaffinitive.com>
	<alpine.BSF.2.00.1103062225200.4227@venus.atopia.net>
Message-ID: <4D7531ED.1040100@devonianfarm.com>

  On 3/6/2011 10:26 PM, Matt Juszczak wrote:
>
> Yes, but most nosql databases aren't designed for durability or 
> reliable persistence.  Remember -- one can always use MySQL as a 
> "noSQL" DB by simply de-normalizing, or applying the "schemaless" patch.
     I've had a serious eye on mongodb,  but I'd say that schemaless 
operation has its advantages and disadvantages.  Proper organization of 
data in a schema can improve performance by a factor of 100 or so vs 
something that's disorganized.  Even if I did use mongodb for the use 
I'm considering it for,  I'd be adding a layer that imposes some 
structure on top of it.


From rmarscher at beaffinitive.com  Mon Mar  7 14:34:39 2011
From: rmarscher at beaffinitive.com (Rob Marscher)
Date: Mon, 7 Mar 2011 14:34:39 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <4D7531ED.1040100@devonianfarm.com>
References: <4D713DD1.2080801@gmail.com>	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>	<1299269233.1684.60.camel@saltworthy>
	<4D72B12F.3030406@gmx.net>	<3442BF77-76F5-4105-BE0F-B2D3809F1348@beaffinitive.com>
	<alpine.BSF.2.00.1103062225200.4227@venus.atopia.net>
	<4D7531ED.1040100@devonianfarm.com>
Message-ID: <127033EC-2D91-48BA-8CE7-0F156B4DE315@beaffinitive.com>


On Mar 7, 2011, at 2:28 PM, Paul A Houle wrote:
> On 3/6/2011 10:26 PM, Matt Juszczak wrote:
>> 
>> Yes, but most nosql databases aren't designed for durability or reliable persistence.  Remember -- one can always use MySQL as a "noSQL" DB by simply de-normalizing, or applying the "schemaless" patch.

> Proper organization of data in a schema can improve performance by a factor of 100 or so vs something that's disorganized.  Even if I did use mongodb for the use I'm considering it for,  I'd be adding a layer that imposes some structure on top of it.

Another thing is that since mongo let's you dump any data in it, a typo in your code could make you accidently insert or search for something with the wrong key name or collection name and you wouldn't get an obvious error like in mysql.

The Lithium framework allows you to define a schema for your document models.  Probably exactly what you're looking for: http://lithify.me/docs/lithium/data/Model::$_schema



From rmarscher at beaffinitive.com  Mon Mar  7 14:39:22 2011
From: rmarscher at beaffinitive.com (Rob Marscher)
Date: Mon, 7 Mar 2011 14:39:22 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <127033EC-2D91-48BA-8CE7-0F156B4DE315@beaffinitive.com>
References: <4D713DD1.2080801@gmail.com>	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>	<1299269233.1684.60.camel@saltworthy>
	<4D72B12F.3030406@gmx.net>	<3442BF77-76F5-4105-BE0F-B2D3809F1348@beaffinitive.com>
	<alpine.BSF.2.00.1103062225200.4227@venus.atopia.net>
	<4D7531ED.1040100@devonianfarm.com>
	<127033EC-2D91-48BA-8CE7-0F156B4DE315@beaffinitive.com>
Message-ID: <F7A9C80A-C772-42F4-9D64-75B8A0EE379B@beaffinitive.com>

>> On 3/6/2011 10:26 PM, Matt Juszczak wrote:
>>> Yes, but most nosql databases aren't designed for durability or reliable persistence.

The MongoDB developers seem to be tackling this problem (and in general, seem to be committed to make their db the best of both worlds).  They recommend always having at least two servers with master-slave replication which does a lot to prevent potential data loss.  But there's also things you can do with mongo to confirm that your data got written disk before the client moves on to the next command.  So if there are operations where speed is the most important factor (like logging) then you don't do this... but if it's more critical data, then it's worth having the client wait a moment to confirm the write was successful or otherwise retry.

http://www.mongodb.org/display/DOCS/Verifying+Propagation+of+Writes+with+getLastError




From edwardpotter at gmail.com  Mon Mar  7 14:36:32 2011
From: edwardpotter at gmail.com (Edward Potter)
Date: Mon, 7 Mar 2011 14:36:32 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <4D7531ED.1040100@devonianfarm.com>
References: <4D713DD1.2080801@gmail.com>
	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>
	<1299269233.1684.60.camel@saltworthy> <4D72B12F.3030406@gmx.net>
	<3442BF77-76F5-4105-BE0F-B2D3809F1348@beaffinitive.com>
	<alpine.BSF.2.00.1103062225200.4227@venus.atopia.net>
	<4D7531ED.1040100@devonianfarm.com>
Message-ID: <AANLkTi=kzBgmzU7nwJ8A0MZbxGkh6nRg4AMZe7m6ugRT@mail.gmail.com>

CPUs are some gosh darn fast, I suspect at one point all the rules of the
last 25 years will go out the door. Just throw your data here, who cares
about normailization, rules, joins, or anything. Just dump it here. We'll
figure it out.

I LOVE the SQLite things for iPhone.

So, how many people have contributed to this Open Source SQLite project
besides you the developer?
Oh, NOT A SINGLE person. NO one.  Just me. And you are the number 1 DB in
the world based on installs.

Yep.  Just me.

What a genius this guy is!  :-))))))))



On Mon, Mar 7, 2011 at 2:28 PM, Paul A Houle <paul at devonianfarm.com> wrote:

>  On 3/6/2011 10:26 PM, Matt Juszczak wrote:
>
>>
>> Yes, but most nosql databases aren't designed for durability or reliable
>> persistence.  Remember -- one can always use MySQL as a "noSQL" DB by simply
>> de-normalizing, or applying the "schemaless" patch.
>>
>    I've had a serious eye on mongodb,  but I'd say that schemaless
> operation has its advantages and disadvantages.  Proper organization of data
> in a schema can improve performance by a factor of 100 or so vs something
> that's disorganized.  Even if I did use mongodb for the use I'm considering
> it for,  I'd be adding a layer that imposes some structure on top of it.
> _______________________________________________
> New York PHP Users Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> http://www.nyphp.org/Show-Participation
>



-- 
IM/iChat: ejpusa
Links: http://del.icio.us/ejpusa
Follow me: http://www.twitter.com/ejpusa
Karma: http://www.coderswithconscience.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20110307/71d9b2f0/attachment.html>

From paul at devonianfarm.com  Mon Mar  7 14:41:59 2011
From: paul at devonianfarm.com (Paul A Houle)
Date: Mon, 07 Mar 2011 14:41:59 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <4D72807E.1060006@gmail.com>
References: <4D713DD1.2080801@gmail.com>	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>	<1299269233.1684.60.camel@saltworthy>
	<4D72807E.1060006@gmail.com>
Message-ID: <4D753507.7080601@devonianfarm.com>

  On 3/5/2011 1:27 PM, Gary Mort wrote:
> I am no longer convinced that the cpu cycles saved by using a numeric 
> id are sufficient to justify doing so with todays computers.  By the 
> time you get to an app that is sizable enough to be looking to shave 
> those few microseconds, your going to be dealing with a large number 
> of ways to save space....and your likely going to want to stick the 
> user mapping data into a cache in memory somewhere anyway, so the time 
> saved is not that big of a deal.
>
     It's not cpu cycles that matter here,  but I/O bandwidth,  seek 
time,  and RAM for cache on your  database server.  Although MySQL in an 
impressive product,  it's remarkably easy to put enough data into a 
database that you'll have performance problems,  particularly if you're 
importing data from public sources or if you develop a successful 
community site.

     32-bit integer identifiers are easy to use for both small systems 
and systems that need to handle up to a billion or so data items.  
Although you can possibly convert some other kind of identifier into an 
int in the future,  this is the last thing you're going to want to do 
when your system gets big,  because changing all of your identifiers 
will then require extended downtime and leaves you with the risk of 
dropping something on the floor.

     For one system I'm working on,  identifiers are fully 
encapsulated,  so at some point I can upgrade my identifiers to 
BINARY(5) if I ever run out of 32-bit id's.  (I'm about 5% of the way 
there now.)


From rmarscher at beaffinitive.com  Mon Mar  7 15:06:43 2011
From: rmarscher at beaffinitive.com (Rob Marscher)
Date: Mon, 7 Mar 2011 15:06:43 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <4D753507.7080601@devonianfarm.com>
References: <4D713DD1.2080801@gmail.com>	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>	<1299269233.1684.60.camel@saltworthy>
	<4D72807E.1060006@gmail.com> <4D753507.7080601@devonianfarm.com>
Message-ID: <969F89AB-DF1F-40DA-8846-198862F1340E@beaffinitive.com>

On Mar 7, 2011, at 2:41 PM, Paul A Houle wrote:
> It's not cpu cycles that matter here,  but I/O bandwidth,  seek time,  and RAM for cache on your  database server.
...
> it's remarkably easy to put enough data into a database that you'll have performance problems,  particularly if you're importing data from public sources or if you develop a successful community site.

Agreed... I/O bottlenecks are a pain.  But still, things are on the up.  RAM is cheap and I/O bandwidth and seek times seem to be getting major upgrades later this year with cheaper SSD drives and technology like Intel Thunderbolt.

The Facebook engineering team has had some nice posts recently that I think are relevant to this conversation.

Being a "full-stack programmer":
http://www.facebook.com/note.php?note_id=461505383919

Man... I can't find it for the life of me right now, but they had a post detailing how they generate unique ids for all content across their entire system.  If I remember right, it's just a super powerful mysql cluster with an auto-increment bigint column.  All of their different pieces make a REST request to the id system to get their unique id.  But I could be wrong on the exact details since I can't find the original post.



From garyamort at gmail.com  Tue Mar  8 13:09:46 2011
From: garyamort at gmail.com (Gary Mort)
Date: Tue, 08 Mar 2011 13:09:46 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <4D753507.7080601@devonianfarm.com>
References: <4D713DD1.2080801@gmail.com>	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>	<1299269233.1684.60.camel@saltworthy>	<4D72807E.1060006@gmail.com>
	<4D753507.7080601@devonianfarm.com>
Message-ID: <4D7670EA.5080608@gmail.com>

On 3/7/2011 2:41 PM, Paul A Houle wrote:
>  On 3/5/2011 1:27 PM, Gary Mort wrote:
>> I am no longer convinced that the cpu cycles saved by using a numeric 
>> id are sufficient to justify doing so with todays computers.  By the 
>> time you get to an app that is sizable enough to be looking to shave 
>> those few microseconds, your going to be dealing with a large number 
>> of ways to save space....and your likely going to want to stick the 
>> user mapping data into a cache in memory somewhere anyway, so the 
>> time saved is not that big of a deal.
>>
>     It's not cpu cycles that matter here,  but I/O bandwidth,  seek 
> time,  and RAM for cache on your  database server.  Although MySQL in 
> an impressive product,  it's remarkably easy to put enough data into a 
> database that you'll have performance problems,  particularly if 
> you're importing data from public sources or if you develop a 
> successful community site.


I highly doubt that unless you are Facebook, Google, or Amazon that you 
can put enough "user records" into your database for this to matter.  
Note, I am specifically referring to the user table - not any other bit 
of data but where you need to identify a user uniquely.

I see no point in placing the added burden of using integer identifiers 
for userids on all applications in order to accomodate "but what if 
someone has hundreds of thousands of users or more!" - if they have 
hundreds of thousands of users, they can afford customizing - why should 
everyone else pay for those few people's convenience?

What do I mean by "pay"?

Take any mysql application used by a mom and pop store.   For whatever 
reason, there is no canned report to retrieve some aspect of data from a 
table[could be the order table, could be the payment table, or here is 
one that often occurs, the SHOPPING cart table to see how many abandoned 
shopping carts there are].

There are a plethora of tools that the owner of the data can use to view 
the data, Navicat, PHPMyAdmin, export it to CSV and look in excel, 
etc.   And the data tends to be very nicely laid out so it the primary 
bits are understandable.....and then you come to "what actual person did 
this?" - and it all breaks down.  Sitting there is some number....  Now 
suddenly from viewing an individual table[which is easy] the person 
needs to join and link the data to another table.   So he has to pay a 
programmer everytime he wants a report to figure out these linkages.

So all the little websites of the world pay a premium just so that open 
source applications can say their "scalable" and that the few big 
businesses which could have afforded to pay to tune the system don't 
have to.

That to me is a poor business decision.  Making many other people pay so 
that your code can be "scalable" and "good coding practices" and "well 
engineered" is not the sign of a good coder - it's the sign of an 
artistic one.

So, what happens if you do it the other way around?  What if you put the 
users name in every one of those records and used that as the key?

Well, performance for those little sites doesn't take any significant 
hit.  On the rare occassion that someone wants to change their name, you 
do have to either go and change it in every existing table - or you have 
to maintain some sort of history table that you can link through so the 
program can say:
This order was placed on December 15th at 2:00pm and at that time, the 
userid garyamort referred to the user who is garyamort today.

Again, for the mom and pop's of the world, take the hit and update it in 
all tables.

It's a different paradigm.  Throwing "art" out the window and replacing 
it by practicality.  Of course, it also means "know your market".  If 
you are coding a specific app for a specific person who is planning on 
growing exponentially, then designing something for him which has to be 
changed later is a poor choice.  But if your making an app for tens of 
thousands of people to use - make simplicity for the end user the 
driving force.   Do stupid ass things that would never scale....and then 
note what they are and how you change it[if you scale past 10,000 users 
convert all usernames to integer keys and always use the aliases 
table.... here is the high level overview on how to do it.  if your not 
a coder, make it your business model to be able to afford to pay for a 
coder when you reach that point.]

The key point, for me, is it should not be so difficult for me to change 
an application so email addresses can be used instead of usernames.  Or 
to make it possible for multiple usernames to use the same email 
address.  Or to change the rules on usernames to allow different 
charectors.   And truely, it is easy to make that change for the one bit 
of core code....it's tracking down all those other bits of code that 
worked on the assumption of those rules...merely because those where the 
rules....that I find troublesome....   and it bothers me greatly to 
charge for this coding time because I am basically fixing the mistaken 
design decisions made by people who are applying rules by rote.  "Always 
use an auto-incrementing primary id"




From grafixwerks at gmail.com  Tue Mar  8 14:03:09 2011
From: grafixwerks at gmail.com (Andy Pearson)
Date: Tue, 8 Mar 2011 14:03:09 -0500
Subject: [nycphp-talk] The user table
In-Reply-To: <4D7670EA.5080608@gmail.com>
References: <4D713DD1.2080801@gmail.com>
	<3DA53AA6-1D32-4B5C-9A3A-AF6A6297DF03@beaffinitive.com>
	<1299269233.1684.60.camel@saltworthy> <4D72807E.1060006@gmail.com>
	<4D753507.7080601@devonianfarm.com> <4D7670EA.5080608@gmail.com>
Message-ID: <AANLkTim_xtES=euJ+1T4VaMVUW+TTZvNsGGEonbSwm1Q@mail.gmail.com>

I think most mom and pop biz use a shared hosting provider, so their site
would be stitting on a server with 100 copies of Wordpress or whatever;
therefore those 100 installs need to be optimized.

On Tue, Mar 8, 2011 at 1:09 PM, Gary Mort <garyamort at gmail.com> wrote:

> On 3/7/2011 2:41 PM, Paul A Houle wrote:
>
>>  On 3/5/2011 1:27 PM, Gary Mort wrote:
>>
>>> I am no longer convinced that the cpu cycles saved by using a numeric id
>>> are sufficient to justify doing so with todays computers.  By the time you
>>> get to an app that is sizable enough to be looking to shave those few
>>> microseconds, your going to be dealing with a large number of ways to save
>>> space....and your likely going to want to stick the user mapping data into a
>>> cache in memory somewhere anyway, so the time saved is not that big of a
>>> deal.
>>>
>>>     It's not cpu cycles that matter here,  but I/O bandwidth,  seek time,
>>  and RAM for cache on your  database server.  Although MySQL in an
>> impressive product,  it's remarkably easy to put enough data into a database
>> that you'll have performance problems,  particularly if you're importing
>> data from public sources or if you develop a successful community site.
>>
>
>
> I highly doubt that unless you are Facebook, Google, or Amazon that you can
> put enough "user records" into your database for this to matter.  Note, I am
> specifically referring to the user table - not any other bit of data but
> where you need to identify a user uniquely.
>
> I see no point in placing the added burden of using integer identifiers for
> userids on all applications in order to accomodate "but what if someone has
> hundreds of thousands of users or more!" - if they have hundreds of
> thousands of users, they can afford customizing - why should everyone else
> pay for those few people's convenience?
>
> What do I mean by "pay"?
>
> Take any mysql application used by a mom and pop store.   For whatever
> reason, there is no canned report to retrieve some aspect of data from a
> table[could be the order table, could be the payment table, or here is one
> that often occurs, the SHOPPING cart table to see how many abandoned
> shopping carts there are].
>
> There are a plethora of tools that the owner of the data can use to view
> the data, Navicat, PHPMyAdmin, export it to CSV and look in excel, etc.
> And the data tends to be very nicely laid out so it the primary bits are
> understandable.....and then you come to "what actual person did this?" - and
> it all breaks down.  Sitting there is some number....  Now suddenly from
> viewing an individual table[which is easy] the person needs to join and link
> the data to another table.   So he has to pay a programmer everytime he
> wants a report to figure out these linkages.
>
> So all the little websites of the world pay a premium just so that open
> source applications can say their "scalable" and that the few big businesses
> which could have afforded to pay to tune the system don't have to.
>
> That to me is a poor business decision.  Making many other people pay so
> that your code can be "scalable" and "good coding practices" and "well
> engineered" is not the sign of a good coder - it's the sign of an artistic
> one.
>
> So, what happens if you do it the other way around?  What if you put the
> users name in every one of those records and used that as the key?
>
> Well, performance for those little sites doesn't take any significant hit.
>  On the rare occassion that someone wants to change their name, you do have
> to either go and change it in every existing table - or you have to maintain
> some sort of history table that you can link through so the program can say:
> This order was placed on December 15th at 2:00pm and at that time, the
> userid garyamort referred to the user who is garyamort today.
>
> Again, for the mom and pop's of the world, take the hit and update it in
> all tables.
>
> It's a different paradigm.  Throwing "art" out the window and replacing it
> by practicality.  Of course, it also means "know your market".  If you are
> coding a specific app for a specific person who is planning on growing
> exponentially, then designing something for him which has to be changed
> later is a poor choice.  But if your making an app for tens of thousands of
> people to use - make simplicity for the end user the driving force.   Do
> stupid ass things that would never scale....and then note what they are and
> how you change it[if you scale past 10,000 users convert all usernames to
> integer keys and always use the aliases table.... here is the high level
> overview on how to do it.  if your not a coder, make it your business model
> to be able to afford to pay for a coder when you reach that point.]
>
> The key point, for me, is it should not be so difficult for me to change an
> application so email addresses can be used instead of usernames.  Or to make
> it possible for multiple usernames to use the same email address.  Or to
> change the rules on usernames to allow different charectors.   And truely,
> it is easy to make that change for the one bit of core code....it's tracking
> down all those other bits of code that worked on the assumption of those
> rules...merely because those where the rules....that I find troublesome....
>   and it bothers me greatly to charge for this coding time because I am
> basically fixing the mistaken design decisions made by people who are
> applying rules by rote.  "Always use an auto-incrementing primary id"
>
>
>
> _______________________________________________
> New York PHP Users Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> http://www.nyphp.org/Show-Participation
>



-- 
Regards,
Andy Pearson

Grafixwerks Design
Where technology and creativity meet
www.grafixwerks.com

andy at grafixwerks.com
office: 718-874-6381
mobile: 347-743-0716

http://www.linkedin.com/in/grafixwerks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20110308/fbe18d0d/attachment.html>

From yitzchak.schaffer at gmx.com  Thu Mar 10 09:51:51 2011
From: yitzchak.schaffer at gmx.com (Yitzchak Schaffer)
Date: Thu, 10 Mar 2011 09:51:51 -0500
Subject: [nycphp-talk] Meeting Wed Mar 16: intro to web frameworks
Message-ID: <4D78E587.6060304@gmx.com>

Hello all,

I am going to be co-hosting a web frameworks workshop Wednesday morning 
10am at METRO (Metro. NY Library Council) on E. 11th Street. It will not 
be library-specific, and will be geared to folks who have some 
experience with web backends, but little or none with frameworks and 
architecture design.

It will be language-agnostic in theory, but I will be speaking about 
symfony. (Bad timing means it'll be symfony 1.4 and not 2)

The event is free, but registration is required. More details at
http://www.metro.org/en/cev/59

-- 
Yitzchak Schaffer
Systems Manager
Touro College Libraries
212.742.8770 ext. 2432
http://www.tourolib.org/


From bruce.amick at gmail.com  Thu Mar 10 13:25:48 2011
From: bruce.amick at gmail.com (bruce amick)
Date: Thu, 10 Mar 2011 13:25:48 -0500
Subject: [nycphp-talk] Meeting Wed Mar 16: intro to web frameworks
In-Reply-To: <4D78E587.6060304@gmx.com>
References: <4D78E587.6060304@gmx.com>
Message-ID: <AANLkTinKdWtAE5QBeFsFQi+i7saz6wQ5F-kfEgz-YZYy@mail.gmail.com>

I'd really like to attend but cannot because of day job commitments.  Would
you consider sharing note or presentation slides after the session?

Thank you.

Bruce Amick
On Mar 10, 2011 9:52 AM, "Yitzchak Schaffer" <yitzchak.schaffer at gmx.com>
wrote:
> Hello all,
>
> I am going to be co-hosting a web frameworks workshop Wednesday morning
> 10am at METRO (Metro. NY Library Council) on E. 11th Street. It will not
> be library-specific, and will be geared to folks who have some
> experience with web backends, but little or none with frameworks and
> architecture design.
>
> It will be language-agnostic in theory, but I will be speaking about
> symfony. (Bad timing means it'll be symfony 1.4 and not 2)
>
> The event is free, but registration is required. More details at
> http://www.metro.org/en/cev/59
>
> --
> Yitzchak Schaffer
> Systems Manager
> Touro College Libraries
> 212.742.8770 ext. 2432
> http://www.tourolib.org/
> _______________________________________________
> New York PHP Users Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> http://www.nyphp.org/Show-Participation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20110310/5556259d/attachment.html>

From y2rob at aol.com  Mon Mar 14 13:23:48 2011
From: y2rob at aol.com (Rob)
Date: Mon, 14 Mar 2011 13:23:48 -0400
Subject: [nycphp-talk] Date conversion from Java timestamp to PHP date
Message-ID: <8CDB083B6F5A6AC-1254-A4AA4@Webmail-m107.sysops.aol.com>


 

 Hello,
I was wondering if anyone has a way to convert a Java timestamp into a proper PHP date format.  I am plugging into an API, and what i thought was a Unix timestamp appears to be a Java timestamp, which there is a difference in the conversion.  All posts I've read so far says, there a difference with milliseconds, but I was wondering if anyone else has found a solution to this.

Forums say to plug the timestamp into the normal PHP date() function, but though I get a proper month and day, the year is really obviously wrong.

Thanks in advance,
~Rob


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20110314/ba207cb7/attachment.html>

From dorgan at donaldorgan.com  Mon Mar 14 13:34:34 2011
From: dorgan at donaldorgan.com (Donald J. Organ IV)
Date: Mon, 14 Mar 2011 13:34:34 -0400 (EDT)
Subject: [nycphp-talk] Date conversion from Java timestamp to PHP date
In-Reply-To: <8CDB083B6F5A6AC-1254-A4AA4@Webmail-m107.sysops.aol.com>
Message-ID: <24746290.14.1300124074235.JavaMail.root@mail.twoguyshosting.com>

I believe java is epoch time and is returned in milliseconds.... 
so just take that value and divide it by 1000 then use that in your date function 






$seconds = $java_time / 1000; 


$date = date('Y-m-d H:i:s', $seconds ); 




----- Original Message -----
From: "Rob" <y2rob at aol.com> 
To: talk at lists.nyphp.org 
Sent: Monday, March 14, 2011 1:23:48 PM 
Subject: [nycphp-talk] Date conversion from Java timestamp to PHP date 




Hello, 
I was wondering if anyone has a way to convert a Java timestamp into a proper PHP date format. I am plugging into an API, and what i thought was a Unix timestamp appears to be a Java timestamp, which there is a difference in the conversion. All posts I've read so far says, there a difference with milliseconds, but I was wondering if anyone else has found a solution to this. 

Forums say to plug the timestamp into the normal PHP date() function, but though I get a proper month and day, the year is really obviously wrong. 

Thanks in advance, 
~Rob 


_______________________________________________ 
New York PHP Users Group Community Talk Mailing List 
http://lists.nyphp.org/mailman/listinfo/talk 

http://www.nyphp.org/Show-Participation 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20110314/e8f0e6ec/attachment.html>

From dorgan at donaldorgan.com  Mon Mar 14 13:35:39 2011
From: dorgan at donaldorgan.com (Donald J. Organ IV)
Date: Mon, 14 Mar 2011 13:35:39 -0400 (EDT)
Subject: [nycphp-talk] Date conversion from Java timestamp to PHP date
In-Reply-To: <24746290.14.1300124074235.JavaMail.root@mail.twoguyshosting.com>
Message-ID: <32398266.17.1300124139990.JavaMail.root@mail.twoguyshosting.com>

Another note I believe epoch time is always GMT based so you may need to convert this to your current Time Zone. 




----- Original Message -----
From: "Donald J. Organ IV" <dorgan at donaldorgan.com> 
To: "NYPHP Talk" <talk at lists.nyphp.org> 
Sent: Monday, March 14, 2011 1:34:34 PM 
Subject: Re: [nycphp-talk] Date conversion from Java timestamp to PHP date 


I believe java is epoch time and is returned in milliseconds.... 
so just take that value and divide it by 1000 then use that in your date function 






$seconds = $java_time / 1000; 


$date = date('Y-m-d H:i:s', $seconds ); 




----- Original Message -----
From: "Rob" <y2rob at aol.com> 
To: talk at lists.nyphp.org 
Sent: Monday, March 14, 2011 1:23:48 PM 
Subject: [nycphp-talk] Date conversion from Java timestamp to PHP date 




Hello, 
I was wondering if anyone has a way to convert a Java timestamp into a proper PHP date format. I am plugging into an API, and what i thought was a Unix timestamp appears to be a Java timestamp, which there is a difference in the conversion. All posts I've read so far says, there a difference with milliseconds, but I was wondering if anyone else has found a solution to this. 

Forums say to plug the timestamp into the normal PHP date() function, but though I get a proper month and day, the year is really obviously wrong. 

Thanks in advance, 
~Rob 


_______________________________________________ 
New York PHP Users Group Community Talk Mailing List 
http://lists.nyphp.org/mailman/listinfo/talk 

http://www.nyphp.org/Show-Participation 
_______________________________________________ 
New York PHP Users Group Community Talk Mailing List 
http://lists.nyphp.org/mailman/listinfo/talk 

http://www.nyphp.org/Show-Participation 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20110314/a76c0dd0/attachment.html>

From y2rob at aol.com  Mon Mar 14 13:38:22 2011
From: y2rob at aol.com (Rob)
Date: Mon, 14 Mar 2011 13:38:22 -0400
Subject: [nycphp-talk] Date conversion from Java timestamp to PHP date
In-Reply-To: <24746290.14.1300124074235.JavaMail.root@mail.twoguyshosting.com>
Message-ID: <8CDB085BFD2E60C-1254-A4E50@Webmail-m107.sysops.aol.com>

Hello Donald,
It worked!! Awesome, for some reason i didn't think i would be that simple, but definitely appreciate the help here!!

 

 Sincerely,
~Rob


 

 

-----Original Message-----
From: Donald J. Organ IV <dorgan at donaldorgan.com>
To: NYPHP Talk <talk at lists.nyphp.org>
Sent: Mon, Mar 14, 2011 1:34 pm
Subject: Re: [nycphp-talk] Date conversion from Java timestamp to PHP date


I believe java is epoch time and is returned in milliseconds....
so just take that value and divide it by 1000 then use that in your date function






$seconds = $java_time / 1000;


$date = date('Y-m-d H:i:s', $seconds );





From: "Rob" <y2rob at aol.com>
To: talk at lists.nyphp.org
Sent: Monday, March 14, 2011 1:23:48 PM
Subject: [nycphp-talk] Date conversion from Java timestamp to PHP date


 

 Hello,
I was wondering if anyone has a way to convert a Java timestamp into a proper PHP date format.  I am plugging into an API, and what i thought was a Unix timestamp appears to be a Java timestamp, which there is a difference in the conversion.  All posts I've read so far says, there a difference with milliseconds, but I was wondering if anyone else has found a solution to this.

Forums say to plug the timestamp into the normal PHP date() function, but though I get a proper month and day, the year is really obviously wrong.

Thanks in advance,
~Rob



_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk

http://www.nyphp.org/Show-Participation

 
_______________________________________________

New York PHP Users Group Community Talk Mailing List

http://lists.nyphp.org/mailman/listinfo/talk



http://www.nyphp.org/Show-Participation


 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20110314/01f4bf3f/attachment.html>

From y2rob at aol.com  Mon Mar 14 13:40:00 2011
From: y2rob at aol.com (Rob)
Date: Mon, 14 Mar 2011 13:40:00 -0400
Subject: [nycphp-talk] Date conversion from Java timestamp to PHP date
In-Reply-To: <32398266.17.1300124139990.JavaMail.root@mail.twoguyshosting.com>
Message-ID: <8CDB085F9F9BD4C-1254-A4EC1@Webmail-m107.sysops.aol.com>

definitely thanks again, and sorry for the brain fart moment :)


 ~Rob

 


 

-----Original Message-----
From: Donald J. Organ IV <dorgan at donaldorgan.com>
To: NYPHP Talk <talk at lists.nyphp.org>
Sent: Mon, Mar 14, 2011 1:35 pm
Subject: Re: [nycphp-talk] Date conversion from Java timestamp to PHP date


Another note I believe epoch time is always GMT based so you may need to convert this to your current Time Zone.





From: "Donald J. Organ IV" <dorgan at donaldorgan.com>
To: "NYPHP Talk" <talk at lists.nyphp.org>
Sent: Monday, March 14, 2011 1:34:34 PM
Subject: Re: [nycphp-talk] Date conversion from Java timestamp to PHP date


I believe java is epoch time and is returned in milliseconds....
so just take that value and divide it by 1000 then use that in your date function






$seconds = $java_time / 1000;


$date = date('Y-m-d H:i:s', $seconds );





From: "Rob" <y2rob at aol.com>
To: talk at lists.nyphp.org
Sent: Monday, March 14, 2011 1:23:48 PM
Subject: [nycphp-talk] Date conversion from Java timestamp to PHP date


 

 Hello,
I was wondering if anyone has a way to convert a Java timestamp into a proper PHP date format.  I am plugging into an API, and what i thought was a Unix timestamp appears to be a Java timestamp, which there is a difference in the conversion.  All posts I've read so far says, there a difference with milliseconds, but I was wondering if anyone else has found a solution to this.

Forums say to plug the timestamp into the normal PHP date() function, but though I get a proper month and day, the year is really obviously wrong.

Thanks in advance,
~Rob



_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk

http://www.nyphp.org/Show-Participation

_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk

http://www.nyphp.org/Show-Participation

 
_______________________________________________

New York PHP Users Group Community Talk Mailing List

http://lists.nyphp.org/mailman/listinfo/talk



http://www.nyphp.org/Show-Participation


 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20110314/b5ad2ee1/attachment.html>

From atistler at gmail.com  Wed Mar 16 09:11:58 2011
From: atistler at gmail.com (Adam Tistler)
Date: Wed, 16 Mar 2011 09:11:58 -0400
Subject: [nycphp-talk] Full-time mid-level PHP/jQuery developer (I am not a
	recruiter)
Message-ID: <A52158DE-6809-4C83-A482-303D0ED5ADF9@gmail.com>

Hello,

I would like to preface this by saying I am NOT a recruiter and NOT in HR, I will personally be doing the interviewing/hiring for this position. 

I am looking for a mid-level PHP developer with strong web design skills.  The candidate should also have good RDMS skills (postgresql would be nice) and 
at least a passing knowledge of NoSQL solutions (MongoDB, CouchDB).  The project that you would be working on is a fairly complicated MVC based web application
that handles ticketing, inventory, domain management, and accounting.  The framework is a homegrown, in-house solution however knowledge of at least one existing PHP framework
would probably be helpful (Zen, Symfony, etc.).  We are also responsible for a few small Drupal sites and perl based applications so knowledge in those areas would be a plus. 

One of the best parts about this position is that you will be given free range to research new technologies and design projects on your own, in fact I encourage it.  I really want someone
who is willing to learn and wants to take ownership of new projects.

The company is a small managed hosting company (50 employees) located in Soho NYC.  Salary would depend on experience.

Please let me know if you are interested.

Adam Tistler
Lead Software Engineer
e: atistler at gmail dot com

From david at davidmintz.org  Thu Mar 17 12:35:53 2011
From: david at davidmintz.org (David Mintz)
Date: Thu, 17 Mar 2011 12:35:53 -0400
Subject: [nycphp-talk] autovivification/style question
Message-ID: <AANLkTinnDBs_10KeAxPObUZ22KWfjm7qn5S+EkgAVAu2@mail.gmail.com>

Is there anything wrong with something like...

  $data = array();
 $results = $db->query($sql);

  while ($row = $results->fetch()) {
       // ... this right here:
       $data[$row->id][] = $row->someStringValue
 }

You can see I am trying to build up an array of arrays whose the keys are id
numbers and whose values are arrays of strings. I have tried it and it works
fine. I just wonder if it's kosher as a matter of cleanliness and style.

-- 
David Mintz
http://davidmintz.org/
It ain't over:
http://www.healthcare-now.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20110317/c5f3a4e5/attachment.html>

From chsnyder at gmail.com  Thu Mar 17 12:43:09 2011
From: chsnyder at gmail.com (Chris Snyder)
Date: Thu, 17 Mar 2011 12:43:09 -0400
Subject: [nycphp-talk] autovivification/style question
In-Reply-To: <AANLkTinnDBs_10KeAxPObUZ22KWfjm7qn5S+EkgAVAu2@mail.gmail.com>
References: <AANLkTinnDBs_10KeAxPObUZ22KWfjm7qn5S+EkgAVAu2@mail.gmail.com>
Message-ID: <AANLkTikwbHaZmOghGgYQh1PNeLpDgD99W0gRNwgsfB=O@mail.gmail.com>

On Thu, Mar 17, 2011 at 12:35 PM, David Mintz <david at davidmintz.org> wrote:
> Is there anything wrong with something like...
>
> ? $data = array();
> ?$results = $db->query($sql);
>
> ? while ($row = $results->fetch()) {
> ?????? // ... this right here:
> ?????? $data[$row->id][] = $row->someStringValue
> ?}
>
> You can see I am trying to build up an array of arrays whose the keys are id
> numbers and whose values are arrays of strings. I have tried it and it works
> fine. I just wonder if it's kosher as a matter of cleanliness and style.

To avoid future warnings, I'd probably throw an if ( !isset($data[
$row->id ]) ) { $data[ $row->id ] = array(); } in there.


From garyamort at gmail.com  Mon Mar 21 17:01:13 2011
From: garyamort at gmail.com (Gary Mort)
Date: Mon, 21 Mar 2011 17:01:13 -0400
Subject: [nycphp-talk] PHP caching options
Message-ID: <4D87BC99.5040306@gmail.com>

Before I go an re-invent the wheel, I figured I'd ask here first.

Does anyone know of a PHP cache system[like APC and XCache] which has 
the following features:

1) Saves the cached files to a tmpfs drive instead of using their own 
shared memory pool?
2) Saves evals as well as files?
3) Keeps track of cached files[via inotify or some other means] and when 
new copies are saved, updates the cache
4) For files that exist in the cache to begin with, when updating the 
cache if the PHP file fails to compile[syntax errors, etc], keep using 
the cached file and wait until a 'good' copy of the file is saved
5) Logging options so that alerts can be generated when a file has an error.


Basically, it strikes me that most of the popular systems are somewhat 
based on being 'universal' and do not take advantage of current Linux 
features which can save time.  For example, by using a tmpfs drive all 
the cached data can be "shared" between multiple systems by doing a 
simple rsync between the systems.  In fact, you can even rsync it over 
to disk storage on one system for 'permanent' storage and then if you 
reboot your PHP server, you can preload your cache by pulling data from 
the central server.  All using basic file system access.

With inotify, the cache server can keep an eye on the source of the 
files and automatically update the cache.

If your planning your cache to contain most of your active PHP code to 
begin with, there really is no reason to cache buggy code.  If there is 
a good copy in the cache, reject updates until they at least compile.

And of course, the cache server might as well log problems so you can 
get them via email, instant message, sms, etc right away.

A sidebit is caching evals, since it does not seem that many systems do 
this....which is understandable as it is beneficial to avoid evals to 
begin with.  However, CMS systems often use Evals to allow configuration 
of code without needing to have files on the server.   With all that 
code stored in the database, it just makes sense to pre-compile and 
cache it.

Since APC and XCache are open source, it is easy enough to pull the 
logic for compiling/caching files when included from them...so really 
it's just the other stuff that needs to be built.




From garyamort at gmail.com  Wed Mar 23 12:29:33 2011
From: garyamort at gmail.com (Gary Mort)
Date: Wed, 23 Mar 2011 12:29:33 -0400
Subject: [nycphp-talk] Eaccelerator
Message-ID: <4D8A1FED.9050402@gmail.com>

As a followup to my post...  Rolling my own seems that the best solution 
to start with is bcompiler from PECL as it gets rid of all the shared 
memory management options.

However, happily EAccellerator http://eaccelerator.net/ has a fine set 
of configuration options where looking it over, it can be used as the 
basis of my thoughts - by setting the php filesize to 1 byte for shared 
memory, I can force all opcode caching to be used.

It also has a good management API, so I can disable built in management 
and instead hand that process over to a PHP server process to 
periodically clean out old files as well as refreshing files in the 
cache when they change on disk.

I also like the fact that you can disable caching on an individual file 
basis, so if there are files you don't want cached it is easy to fix that.

The one downside is it means no caching for eval.... however that is 
easily fixed by using include instead of eval[using Streams, one can 
define a "variable" stream and then include the variable...

So instead of

$evalphp_query = "select mycode FROM my_code_table where code_select = 
'criteria'";
$result = mysql_query($evalphp_query);
while ($row = mysql_fetch_object($result)) {
     eval($row->mycode);
}

Instead one could run it as:
$evalphp_query = "select mycode, SHA(mycode) as myfilename, 
created_timestamp, changed_timestampe FROM my_code_table where 
code_select = 'criteria'";
$result = mysql_query($evalphp_query);
while ($row = mysql_fetch_object($result)) {
     $pretendfile[$row->myfilename] = $row;
     include('pretendfile://'.$row->myfilename);
}

Register a pretendfile stream handler to provide all the needed file 
data[change date, created date, size, etc] using the $pretendfile array 
and not only can all the old eval'd code now be cached by the opcode 
cacher, but you also gain the ability to use the change timestamp to 
know when to refresh it.

So I'm curious, while this looks good for hacking/having fun with..  for 
"real world use" is eaccelerator currently considered stable?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20110323/63fb0c70/attachment.html>

From danielc at analysisandsolutions.com  Wed Mar 23 22:13:17 2011
From: danielc at analysisandsolutions.com (Daniel Convissor)
Date: Wed, 23 Mar 2011 22:13:17 -0400
Subject: [nycphp-talk] php community conference
Message-ID: <20110324021316.GA28994@panix.com>

Hi Folks:

I'm sure some folks here will be interested to know about the PHP
Community Conference.  This is a down-to-earth event by and for people
who love PHP, the stuff we make with it and the people in the community.

It takes place in Nashville, TN on April 21 and 22.

http://phpcon.org/

Enjoy,

--Dan

-- 
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
            data intensive web and database programming
                http://www.AnalysisAndSolutions.com/
 4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409


From sbritton at gmail.com  Wed Mar 23 22:24:42 2011
From: sbritton at gmail.com (Stephen Britton)
Date: Wed, 23 Mar 2011 22:24:42 -0400
Subject: [nycphp-talk] php community conference
In-Reply-To: <20110324021316.GA28994@panix.com>
References: <20110324021316.GA28994@panix.com>
Message-ID: <AANLkTinrySbQOqfeoRei4PtHKDeythfPwFqpGvpJOzNn@mail.gmail.com>

Speaking of conferences, does anyone know if NYPHP plans to revive
it's conference?

This would be a good year to have a conference seeing there are a lot
of  active NYC user groups that use PHP and PHP-based CMS's and
frameworks, like CakePHP, Drupal, Joomla, WordPress, etc. It would
make a great weekend event.

On Wed, Mar 23, 2011 at 10:13 PM, Daniel Convissor
<danielc at analysisandsolutions.com> wrote:
> Hi Folks:
>
> I'm sure some folks here will be interested to know about the PHP
> Community Conference. ?This is a down-to-earth event by and for people
> who love PHP, the stuff we make with it and the people in the community.
>
> It takes place in Nashville, TN on April 21 and 22.
>
> http://phpcon.org/
>
> Enjoy,
>
> --Dan
>
> --
> ?T H E ? A N A L Y S I S ? A N D ? S O L U T I O N S ? C O M P A N Y
> ? ? ? ? ? ?data intensive web and database programming
> ? ? ? ? ? ? ? ?http://www.AnalysisAndSolutions.com/
> ?4015 7th Ave #4, Brooklyn NY 11232 ?v: 718-854-0335 f: 718-854-0409
> _______________________________________________
> New York PHP Users Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> http://www.nyphp.org/Show-Participation
>



-- 
Stephen Britton
Technology Consultant
sbritton at gmail.com
ph: 914-661-0040


From aarong at thinkcomputer.com  Sat Mar 26 20:14:10 2011
From: aarong at thinkcomputer.com (Aaron Greenspan)
Date: Sat, 26 Mar 2011 20:14:10 -0400
Subject: [nycphp-talk] Pay with your phone using FaceCash
Message-ID: <201103270014.p2R0EAA3013108@kermit.thinkcomputer.com>

I use FaceCash to pay with my phone. It's more convenient than plastic and it even works with a paper card if you don't have an iPhone, Android or BlackBerry. Take a look!

-Aaron

Stop carrying plastic with you everywhere you go. Learn more about FaceCash mobile payments here:

http://www.facecash.com/index.html?x=1&y=59115876de

This message was sent to you by Aaron Greenspan. If you would prefer not to receive such mailings in the future, click here:

http://www.facecash.com/signup/optout.html?x=3163&email=talk%40lists.nyphp.org

Think Computer Corporation / 3260 Hillview Avenue / Palo Alto, CA 94304-1226 / http://www.thinkcomputer.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20110326/5b416bb9/attachment.html>

From bulk at zaunere.com  Sun Mar 27 09:42:12 2011
From: bulk at zaunere.com (Hans Zaunere)
Date: Sun, 27 Mar 2011 09:42:12 -0400
Subject: [nycphp-talk] DO NOT Pay with your phone using FaceCash
Message-ID: <022301cbec84$c7490240$55db06c0$@zaunere.com>

Aaron, this is not an appropriate posting.  This is not a list for advertising.

Thank you.

---
   Hans Zaunere /     Bootup    / New York PHP
Managing Member / www.bootup.io / www.nyphp.org



> FaceCash 
> Pay with your phone using FaceCash
> 




From marystock107 at hotmail.com  Sun Mar 27 11:50:53 2011
From: marystock107 at hotmail.com (Mary Stock)
Date: Sun, 27 Mar 2011 11:50:53 -0400
Subject: [nycphp-talk] DO NOT Pay with your phone using FaceCash
In-Reply-To: <022301cbec84$c7490240$55db06c0$@zaunere.com>
References: <022301cbec84$c7490240$55db06c0$@zaunere.com>
Message-ID: <SNT128-W562DDDE63D13A52728054A9EBB0@phx.gbl>


Hans - 

I DID NOT SEND THAT E-MAIL. My e-mail list must have been hacked! I have no interest in FaceCash, whatever that is. 

Sorry that someone has hacked me, but you can be sure that if you get anything other than legitimate postings from me, my address is being used by others on their own servers to send their own mail.

Mary

> From: bulk at zaunere.com
> To: aarong at thinkcomputer.com
> Date: Sun, 27 Mar 2011 09:42:12 -0400
> CC: talk at lists.nyphp.org
> Subject: Re: [nycphp-talk] DO NOT Pay with your phone using FaceCash
> 
> Aaron, this is not an appropriate posting.  This is not a list for advertising.
> 
> Thank you.
> 
> ---
>    Hans Zaunere /     Bootup    / New York PHP
> Managing Member / www.bootup.io / www.nyphp.org
> 
> 
> 
> > FaceCash 
> > Pay with your phone using FaceCash
> > 
> 
> 
> _______________________________________________
> New York PHP Users Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
> 
> http://www.nyphp.org/Show-Participation
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20110327/1cf9fdfe/attachment.html>

From matt at atopia.net  Sun Mar 27 11:53:52 2011
From: matt at atopia.net (Matt Juszczak)
Date: Sun, 27 Mar 2011 15:53:52 +0000
Subject: [nycphp-talk] DO NOT Pay with your phone using FaceCash
In-Reply-To: <SNT128-W562DDDE63D13A52728054A9EBB0@phx.gbl>
References: <022301cbec84$c7490240$55db06c0$@zaunere.com><SNT128-W562DDDE63D13A52728054A9EBB0@phx.gbl>
Message-ID: <1015332545-1301241233-cardhu_decombobulator_blackberry.rim.net-2028033745-@bda205.bisx.prod.on.blackberry>

Mary,

Are you sure Hans was referring to you?

Matt

-----Original Message-----
From: Mary Stock <marystock107 at hotmail.com>
Sender: talk-bounces at lists.nyphp.org
Date: Sun, 27 Mar 2011 11:50:53 
To: <talk at lists.nyphp.org>
Reply-To: NYPHP Talk <talk at lists.nyphp.org>
Subject: Re: [nycphp-talk] DO NOT Pay with your phone using FaceCash

_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk

http://www.nyphp.org/Show-Participation



From bulk at zaunere.com  Sun Mar 27 12:23:12 2011
From: bulk at zaunere.com (Hans Zaunere)
Date: Sun, 27 Mar 2011 12:23:12 -0400
Subject: [nycphp-talk] DO NOT Pay with your phone using FaceCash
In-Reply-To: <SNT128-W562DDDE63D13A52728054A9EBB0@phx.gbl>
References: <022301cbec84$c7490240$55db06c0$@zaunere.com>
	<SNT128-W562DDDE63D13A52728054A9EBB0@phx.gbl>
Message-ID: <024a01cbec9b$457b8500$d0728f00$@zaunere.com>

Hi Mary,

> I DID NOT SEND THAT E-MAIL. My e-mail list must have been hacked! I have
> no interest in FaceCash, whatever that is.
> 
> Sorry that someone has hacked me, but you can be sure that if you get
> anything other than legitimate postings from me, my address is being
> used by others on their own servers to send their own mail.

I believe you - which is why I addressed my reply to Aaron :)

H


> > Aaron, this is not an appropriate posting. This is not a list for
> > advertising.
> >
> > Thank you.
> >
> > ---
> > Hans Zaunere / Bootup / New York PHP
> > Managing Member / www.bootup.io / www.nyphp.org





From aarong at thinkcomputer.com  Sun Mar 27 13:12:15 2011
From: aarong at thinkcomputer.com (Aaron Greenspan)
Date: Sun, 27 Mar 2011 10:12:15 -0700
Subject: [nycphp-talk] Apologies
Message-ID: <4D8F6FEF.1000809@thinkcomputer.com>

Hi,

My apologies for the e-mail that went out earlier from my account. It 
was not supposed to go to lists, and despite my best efforts it went out 
to this one anyway.

The reason I'm on the list at all is not random; I started using PHP in 
2000 and my company's products are all built in PHP. I've done my best 
to contribute to and support the language, but obviously marketing 
material doesn't belong on a development list.

Thanks for your help over the years and my apologies once again.

Aaron

------------------------------------------------------------------------
Think Computer Corporation 	

*Aaron Greenspan*
President & CEO
Think Computer Corporation

/telephone/ +1 415 670 9350
/toll free/ +1 888 815 8599
/fax/ +1 415 373 3959
/e-mail/ aarong at thinkcomputer.com
/web/ http://www.thinkcomputer.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20110327/83c7430f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1806 bytes
Desc: not available
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20110327/83c7430f/attachment.gif>