richardlynch's Profile

If you just want a straight hourly -> annual conversion, it would be to multiply by 2000.

That's based on a 52-week year, with 2-week vacation, at 40 hours per week, which is pretty standard in the US. (52 -2) X 40 == 2000

You could adjust that for your own country/cultural standards.

So the $60 per hour is $120,000 per year, no benefits.

Of course, we all know that freelancers can seldom get paid for a full 40 hours per week, 50 weeks per year, even though they often work way more hours than that, when all is said and done.

And, if you want to factor in benefits, well, then the math gets interesting, as you have to decide whether you are calculating cost to business, or value to employee.

It's often interesting to see posts to various mailing lists and their job requirements and the pay rate, when that's listed. Sometimes the mis-match makes me laugh.

One time just the job requirement made me laugh, since it would have required the applicant to have been using PHP since 1993...

The longest, steadiest PHP gig I've ever held pays me in food & beer, doing the website for a restaurant. :-) If I'm hungry, and I got gas in the Jeep, I'm all set!

Ultimately, if you take a gig only because it's "more money", what's the point? More money and miserable is no way to live.

PS Can anybody explain how a professional recruiter could see this:

Full-time, Part-time, or Consulting employment developing dynamic web-sites using PHP, MySQL, PostgreSQL and related technologies in Chicago city limits or telecommuting.

And then cold contact me THREE TIMES over the course of 6 months for a 3-month contract in San Diego?

Sheesh!

Killfile.

Posted in /blog/2007/jan/consulting-rates.

Mon, 05 Feb 2007 at 13:44:29: Link

For those asking Chris to provide an example of how to use his code, here is an untested example:

<?php
 
  require 'chris_shiflett_session_code.inc';
  session_start();
  $_SESSION['counter']++;
  echo "You have visited this page $_SESSION[counter] times.";
 
?>

If this looks remarkably similar to the example in the manual for session_start, well, there ya go...

You have to require Chris' code on each page, and do session_start() on each page, so moving session_start() into his file would be a Good Idea.

Posted in /articles/storing-sessions-in-a-database.

Mon, 16 Oct 2006 at 12:00:31: Link

There's a buttload of other solutions on php.net in str_replace (link above) and other places.

All kinds of "fun" non-standard Windows byte-codes are documented there that you have to convert to something useful for the 'net, cuz your users are sooo windows-centric they think everybody sees what they see.

Posted in /blog/2005/oct/convert-smart-quotes-with-php.

Mon, 02 Oct 2006 at 15:19:32: Link

There are many cases where the beginner has used POST for something that, really, could just as easily be GET without violating the RFC.

In those cases, switching to GET is probably the better solution.

The overhead of the HTTP re-direct headers and the browser thrashing back-and-forth can be painful on a busy server, and more difficult to follow when trying to debug a script.

The only caveat is that some servers limit the amount of data that GET can transmit even more than they limit POST data.

Of course, if the user action DOES change data on the server in a way that web-crawlers, bots, search engines etc should not, you MUST stick with POST.

Posted in /articles/how-to-avoid-page-has-expired-warnings.

Tue, 11 Apr 2006 at 16:22:42: Link

I don't think it's all that tricky to type mysql_real_escape_string.

If it IS that tricky, then you need to get a fancy IDE that can auto-complete for you.

I can see the argument for not doing htmlentities on a username, IF you know it was scrubbed on input and cannot possibly contain any characters that need escaping.

At that point, it would be like doing htmlentities on an integer or float, that you KNOW is a valid integer or float.

That data has an inherent structure and some intrinsic properties that make htmlentities moot.

For that matter, one could even consider running a validation suite on their data which included a test that htmlentities($username) === $username for all usernames.

While I can't think of any Black Hat utility that would take advantage of the difference, that doesn't mean there isn't one out there waiting to bite me, does it?

That said, it might be much easier to code a framework that treats all strings with htmlentities, whether they need it or not, and it wouldn't irk me if my strings with inherent properties known to not need htmlentities() were being passed through it. The performance hit can't be that high.

Posted in /blog/2006/jan/php-security-architecture.

Fri, 27 Jan 2006 at 14:23:27: Link

For those of us who hate templating systems (other than PHP itself)...

The bound parameters solution reminds me of sprintf() for output.

Perhaps some kind of function like sprintf() that treats the first arg as static/safe text, and the remainder as data to be escaped would be good...

You'd still need the discipline to know that this is fine:

$name = safe_print('%s %s', $first_name, $last_name);

$output = safe_print("<p>Hello $name from %s", $location);

echo $output;

This could, perhaps, involve a default function of 'htmlentities' but which could be set to something else with, say:

function htmlentities8 ($data){

return htmlentities($data, ENT_QUOTES, 'UTF-8');

}

safe_print_handler('htmlentities8');

Or maybe the default should be the equivalent of htmlentities8 above -- I'm more concerned that we as a community do something to induce better habits throughout the community, and that it's SIMPLE and PORTABLE enough that it gets into every PHP compilation.

I shouldn't have to install/configure anything "extra" to use fundamental Security principles.

An alarm system may not come with a house you buy, or an apartment you rent, but you pretty much expect a simple dead-bolt, no?

I'm pretty sure it's a law in some communities that an apartment has to have a working dead-bolt.

Surely our base solution for minimal Security should be a fundamental part of the PHP language, not some add-on second thought.

This is not intended as derogatory towards PECL or any other extension system (PEAR, etc)

But I think Security is too important to relegate the basics to anything less than PHP core.

Extended alarm systems and captcha and whatnot, sure.

But input and output filtering?

Core.

jmho

Posted in /blog/2005/nov/zend-framework-update.

Mon, 14 Nov 2005 at 12:52:14: Link

Great work, as always!

"To avoid this unnecessary exposure [Cookies sent for images], you might consider serving all embedded resources from a server with a different domain name."

It may be more practical for more users on inexpensive hosts to put their session/protected content in a different sub-directory, and then tie the Cookie to only that sub-directory, while keeping the images (et al) in a different directory not under the session/protected directory.

Many inexpensive hosts don't make it easy to add/manage sub-domains and tie them to different directories.

But you can always do:

/session -- all session-oriented pages

/images -- images needed for session-oriented pages

If your Cookie is sent only for "/session" directory, rather than the default "/", then the images won't be getting the un-needed Cookie.

Just an idea for my fellow cheap-skates :-)

For the next edition, I'd also suggest pointing out that Session data on a shared server is particularly vulnerable if it is not encrypted.

Posted in /blog/2005/oct/essential-php-security-lives.

Thu, 20 Oct 2005 at 15:44:13: Link

Arnold:

But passing that decryption key around in POST data exposes it.

The only "gain" here is that you're doing something obscure enough that not many people will know it -- but it won't even slow down a determined individual with half a clue.

Security by obscurity is seldom truly effective.

Chris:

I suspect most hosts don't have a user-editable 'include' file in their httpd.conf, even inside their own VirtualHost since that would, in their minds, give WAY too much control over to their client.

So while the PHP Cookbook solution is "Good" I don't think it's being implemented in most shared hosting environments.

Perhaps if Apache provided a way to d this:

<VirtualHost _client_>

<AllowDirective SetEnv>

include /home/client/private/local.httpd.conf

</AllowDirective>

</VirtualHost>

and *ONLY* the SetEnv directive would work.

This would allow the Host to give up only the control they choose, rather than whatever a malicious client can dream up...

Posted in /articles/shared-hosting.

Mon, 31 Jan 2005 at 11:04:50: Link