Terry Chay’s profile

PHP Terrorist

Latest Comments

1

The article you reference (original SmashingMag) article reminds me of this 10 security tips article published on a web development site I had to do a takedown of in the comments :-(

Fortunately, I remembered to exhibit more tact than is my wont in my reply.

Posted in Smashing PHP.

Sun, 05 Apr 2009 at 05:57:59 GMT


2

By the way, read Paul's post today about output handling

http://shiflett.org/blog/2007/dec/p...calendar-day-15

Posted in PHP Advent Calendar Day 13.

Sun, 16 Dec 2007 at 04:58:48 GMT


3

@John Campbell

I see your point, but a problem is that data on one level is code on another level. Many PHP developers don't realize, for instance, how data on the level of application server output treated as code on the level of the browser input (XSS). It is not all places where the front end developer and the app developer are the same person or even in the same team—in fact, I believe it is better if they aren't the same person as good Javascript seems to be better among those who don't know C++/Java/PHP style object syntax.

Similarly, code on the level of output from a browser is often treated as data on the input into the application server. Not understanding that this data could have come from anywhere (CSRF) is the basis of many Ajax holes on Web 2.0 sites.

The changing together of attacks forms the basis of most exploits.

Many people see the adding of CSRF protection into the latest Ruby framework as a good thing. I tend to see it as being overly abstracted from understanding simple security protocol. It is that same abstraction that causes people to miss the SQL injection questions (most people are far abstracted from it using persistence patterns in things like Active Record in Rails or Hibernate).

The costs are similarly hidden. This is why they end up eventually paying companies like OmniTI and Thoughtworks to come fix their shit if they've achieved a modicum of success.

@Lody

Thanks for the compliment. Though my friends tell me it would have been easier and shorter to just write a book. :-D

Posted in PHP Advent Calendar Day 13.

Sun, 16 Dec 2007 at 04:56:46 GMT


4

Don't feed the egos. :-)

BTW, there is a "typo" chmod 511 should be chmod 311. ;-)

Posted in PHP Advent Calendar Day 13.

Fri, 14 Dec 2007 at 18:30:29 GMT


5

Another reason to document your code inside the code instead of externally is you get version control (and the whole related toolchain) for free. Especially if the comments are in Javadoc.

The anecdotes were very amusing. In keeping with the holiday season I'll recount a story I read once (can’t find the reference but here is where I copy and pasted it:

<blockquote>A child was watching her mother prepare a rolled rump roast before putting it in the oven. When the mother cut off both edges of the roast and threw them away, the child asked why she was throwing away good meat. The mother replied: "My mother taught me how to cook, and that's the way she always did it. I'm sure thata there's a good reason for doing it. I'll go and ask grandma."

So the woman went and asked her mother what the reason was for cutting off the ends of a rump roast before roasting it. The mother replied: "My mother taught me how to cook, and that's the way she always did it. I'm sure that there's a good reason for doing it that way. Let's go and ask grandma."

So the women went to ask their 80-year old progenitor why she cut off the edges of the roast before cooking it. And the old woman replied:

"Oh my! You remember that I used to do that? Well, we were very poor and only had one small square roasting pan and the roasts I would buy somehow would never fit into the pan, so I had to cut the ends off to make them fit into the pan."</blockquote>

Imagine how much poorly-documented, but usable code is like that rump roast. If only Grandma had documented why the recipe called for cutting both ends off! ;-)

Posted in PHP Advent Calendar Day 2.

Tue, 11 Dec 2007 at 22:10:53 GMT


6

Onur,

Hmm putting Shiflett's stuff quotes huh? Well let's take Facebook as an example:

Server #: 2000-3000 on the front end.

PHP frameworks used: home grown

PHP extensions: APC certainly, :-D

Pages served: tens of billions of dynamic pages/month.

How about the company I work for?

Server #: 100-200 on the front end

PHP frameworks used: home grown, a tiny bit of PEAR

PHP extensions: Zend Platform currently + the default stuff in PHP 5.1

Pages served: a billion of dynamic pages/month

Digg? Go see Eli's talk.

Flickr? Go see Cal's talk.

wikipedia? del.icio.us? I never asked, but I can do some good dead reckoning. Wikipedia uses Wikimedia framework, btw. ;-)

When SmugMug (written in PHP, a Flickr style photo sharing site for professionals) switched to using Amazon S3 last year, they accounted for half of the objects stored in the entire S3.

Here's a hint: Reserve the quote marks for the ones that have no servers, no traffic, use Ruby on Rails, and actually call themselves "Web 2.0."

(P.S. I think the del.icio.us switch to Symfony is stupid. But I guess I'm in the minority. Then again, I was in the minority thinking Friendster's switch to PHP was dumb. So I guess being wrong is just mean reversion.)

Posted in Delicious PHP.

Tue, 30 Oct 2007 at 23:03:52 GMT


7

I'm not a PHP programmer, and heck, I've never heard about dynamic SQL or the fact that earlier versions of MySQL didn't support bind variables, but let me proceed to lecture you and why the language you use that powers a good portion of the internet is crap.

Posted in The Unexpected SQL Injection.

Mon, 01 Oct 2007 at 16:02:32 GMT


8

Kevin,

Did you ever know that you’re my HERRRROOO~~~

You’re everything I wish I could be~~~~

I can flyer than an (Colbert) EAAAAGLLEEE~~~

You are the wind beneath my wings~~~

*bows*

Thank you, thank you! I'll be here tomorrow

http://terrychay.com/blog/article/m...-php-hero.shtml

Posted in Terry Chay on Rails.

Tue, 10 Jul 2007 at 21:13:10 GMT


9

Oh poor baby! Did I touch a nerve there?

If you actually listened to the segment you’d see that I correct myself and use the term “Ruby on Rails” correctly. Besides, what the fuck do you think I’m talking about? When ThoughtWorks posts this ad are you going to tell me that they mean Ruby or RoR?

FUD indeed, but it seems to be coming from the Java/Ruby world instead of the PHP world where (if you listened to the Podcast) it’s developers realize that the “web problem” emperor has no clothes. (For you Neanderthals out there, I said that you can develop great web applications in any language.)

As for evidence. Listen to the talk! I give at three or four I think (Wikipedia, WordPress, SugarCRM, Joomla). Yeah, I’m sure TaDa! List and BaseCamp stack up really well against those four which I pulled out of my ass only because the previous four people interviewed before me on Pro::PHP Podcast were the inventors of those applications, all written in… What language was that?

All together now…

P

H

P

Posted in Blood, Sweat, and Swear: Terry Chay on Pro-PHP Podcast.

Sat, 26 Aug 2006 at 02:16:56 GMT


10

Chris, I believe the restriction on PEAR (the politics) comes from the lack of namespacing in PHP. This means that it should be important to revisit the problem after PHP6.

The idea is the lack of namespacing, like with any large PHP installation, is going to cause conflicts because the only thing keeping your libraries sane is a naming convention that you tightly control. This is one of the major weaknesses of a scopeless paradigm of PHP (which caused the lack of namespacing).

In any case, Greg Beaver and others found a great way around some of this crap. The addition of channel subscriptions. It solves the problem of the politics, but makes PEAR very fragmented (at least if your stuff is languishing in an obscure channel somewhere).

It may seem like Theo’s rant is “trashing” but it really isn’t. These were honest design decisions that led PHP in a different direction than other languages. I think we have only to point to PHP’s huge marketshare to know that in many ways, these design decisions were good (or at least, not terribly bad).

User comments, the PEAR library, lack of namespacing, lack of lexical scoping. These are all the strength of PHP.

But sometimes it is fun to poke at when they can be a weakness.

Posted in Six Reasons PHP Sucks.

Fri, 11 Aug 2006 at 17:29:01 GMT


About

  • Twitter: @tychay
  • Location: San Francisco
  • Joined: March 2006
  • Comments: 14