In response to a previous post benchmarking exceptions, Volker Dusch has posted some of his own thoughts and benchmarking results on the same topic.

Some days ago there was a blog post regarding php exception performance in 5.4 and the numbers got reported all over the place. The actually numbers are secondary. The main point is: Don't trust "random" stuff on the Internet when thinking about improving your application performance. You always need to measure things for your self and take care doing so! I've initially trusted the benchmark myself and disgraced the whole post saying: "Well yes, exceptions are slower than if statements but nice that they got faster".

He includes some results with a bit more standardized testing - one run with both 5.3 and 5.4 using XDebug and another with it turned off for both. His results make sense, if you think about them:

So what we learn from that? Running stuff with debugging tools is slower than not doing that. That's why we don't use xDebug in production.

In a recent post to his blog Brian Teeman asks the question of Joomla users and developers - "can you trust your Joomla extensions?"

Sadly in the last 6 months there have been two published circumstances where an extension provider has been hacked and malicious code inserted into the extensions that they offer. This meant that as soon as you installed the extension your site was vulnerable to defacement etc. If there have been two published cases perhaps there have been more that we don't know about. So is there anything we can do to prevent this?

There is a sort of checking system in place with the md5sum matching but it's not widely supported currently. Sites like the Joomla Extension Directory would be prime candidates for sharing this sort of information to help protect those with Joomla installs all across the web.

Brian also suggests a way to make it even more seamless - integrate the md5sum checking into the Joomla code itself to make it even simpler for users to verify they they've gotten the write package from the right source (with the right code inside).

As finding good, qualified local PHP developers becomes harder and harder for some companies, they're slowly realizing that they might need to look outside their area for good talent. If you're a developer and are wanting to promote yourself as someone who can work as a remote employee, you might want to read this post (the first of a series) from Chris Hartjes on telecommuting.

My current position as a "software engineer" for XML Team Solutions is a 100% telecommuting job. [...] Now, when you have a company where none of your fellow employees works in the same city, let alone the same country, you quickly find out what the key issue really is: trust

He goes on to talk about how to build up that trust, not just with the other developers on your team but with the manager you're working with to show them you're the qualified employee they think you are. He also points out one of the big hindrances some companies take issue with on not having all their people in one place - easy meetings/collaboration.

This post was inspired by these thoughts from Cal Evans.

In some of his research into PHP and Windows recently, Cal Evans has come across two surprising things about the (usually dismissed) combination of the two:

• It actually runs well if setup properly

  I don't have a spare computer so I'm not going to discuss performance or show benchmarks. I am talking about ease of use in getting things setup. [...] No, I'm not nearly ready to give up my Linux servers in production and despite Sam Ramji's recent pleas to their open source vendors not to compete on price but compete on value, I can still fail fast and cheap using open source software and operating systems.

• A lot of open source developers just don't trust Microsoft, just because.

  I am, however, willing to give them the benefit of the doubt. I am part of the slim majority on the above poll who thinks they are sincere. The reason I am willing to give them the benefit of the doubt is not because I believe that the core of Microsoft has changed in any way [...] but because I believe that inside of Microsoft, there are pockets of brilliance.

Check out more of Cal's thoughts on the matter and the results of his "unscientific" polls he mentions in the rest of the post.

Keith Casey has a suggestion for budding (PHP) developers out there looking to jump head first into their first project: "Don't trust the users."

Recently I taught a class of bright-eyed, bushy-tailed PHP'ers just getting their start in the world. They haven't done their first production application and we were working in the "safe" confines of a classroom, but there was one concept that I pounded into their heads: Don't Trust the Users.

Generally, as Keith mentions, users aren't malicious/incompetent/ignorant 99 percent of the time, but there's always that off chance that they are and you need to protect you and your application from it by filtering input and escaping all output to prevent any mishaps.

In a new post to his blog, Chris Hartjes, spurred on by an article in the latest edition of php|architect magazine (covering protecting your code), has shared a few opinions starting with a certain paragraph near the end.

To start, I will focus on the paragraph above. What I get out of that is that if only your source was closed and hidden from prying eyes, it would not have bugs in it. Which is, of course, total nonsense. Code has bugs because it's open and they feel safer? There are two kinds of bugs: application bugs (which is the code I would write) and system bugs (in this case, bugs that that appear from PHP itself). I'm sorry, but there is nothing I can do if there is a bug in PHP that causes my application to crash except to point this bug out to the people who have the ability to fix it.

He goes on to talk more about how protection like this (the article talks about using the IonCube Encoder) will not stop someone if they're really determine to get at the code underneath the encryption. His only suggestion is to make an application good enough that people wouldn't want to try to steal it as much and would rather pay for their version.

Encode your stuff if you want, but be aware that the minute you choose to do that you are telling your customers "I don't trust you" and I have a hard time understanding a business model that assumes people are going to want to steal the stuff you sell.

One can never be too secure when it comes to online applications. PHP has its problems, making it a bit too easy sometimes to write back code that makes for insecure applications, but, thankfully, there are some simple steps to be taken to greatly reduce these risks. This article from PHPHacks.com shares some of the easiest.

Their recommendations are:

• Never, Ever, Trust Your Users
• Using Golbal Variables Correctly
• Handling Error Reporting
• Preventing SQL Injection
• Avoiding File Manipulation
• Avoiding Using Defaults
• Not Leaving Installation Files Online
• Avoiding Predictability

Oh, and my personal favorite, which is funny at first glance but seriously true when you really think about it "Be Completely and Utterly Paranoid".

Related to his work on the Services_Trackback PEAR Package he worked on, Tobias Schlitt looks today in this new blog post at some of his more recent thoughts on trackback spam.

It's been a long while since I worked on my PEAR package Services_Trackback, mainly because I was much too busy with work and university. Nevertheless I made up my mind about how to solve the problem of the so-called trackback spam.

Taking for granted, that the idea should work, there are 2 main questions to answer: "How can a sender of a trackback be identified?" and "If and how must the trackback standard be changed to support the identification?" For question #1 there is a simple answer (IMHO): PGP/GPG (further on referred to as GPG, for simplicity).

He suggests that since there is already a "trust relationship" inherent in the system, a PGP/GPG setup might be the most flexible, easy-to-use, constantly adapting method for preventing one of the banes of bloggers' existences...