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.

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).

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.

• 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.

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.

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.

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

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...]]> Tue, 07 Feb 2006 06:53:10 -0600