But it throws an exception in IE: Object doesn’t support this action. The same action works on custom objects:

Just like with iterating over properties, it seems as if IE treats window like a special object, and it’s custom properties as something out of reach for certain actions. So I’ve come up with a solution to delete properties that works on all tested browsers:

You can test this here. This issue is present even in IE8, which is supposed to be much better with standards, but this example clearly shows that some very basic behavior is still missing from their Javascript engine.

The only thing I miss is some sort of prepared statement inspection. You prepare it, and you pass the parameters, but you can’t find out what the query actually looks like. This would come in handy for logging, but it may be impossible to implement in the extension, because as I understand prepared statements are assembled by the database itself, unless they’re emulated by the extension.

Seems like LNL steals focus upon loading, which may happen a few seconds after you’ve already started writing a form. Needless to say that this is annoying at least.

But today, I’ve seen the problem in all of its glory. I’ve tried logging in to VideoLectures.net, I focused the username input, entered my username, tabbed to password input, entered password, pressed Enter, and only then realised that it stole the focus just before I typed the first letter of the password. My full password then went public to at least 8 people that were reportedly visiting the same page. What good is strong password hashing, XSS and session protection and whatnot, when you have a feature like this?

Needless to say I’ve changed my password immediately.

Update: I’ve contacted them and they replied promptly that this problematic auto-focus will be fixed soon.

If a serious magazine tries to present itself as a valuable source of PHP information, and half of the issue is dedicated to frameworks, and they put a big caption saying “PHP HAS BEEN FRAMED – A rundown of popular frameworks” on the front cover, but then at least two of the frameworks listed are far from maturity (and userbase, and documentation) of the big players, and you fail to list at least one of the most popular frameworks, then it’s a fail. Whether it be because they couldn’t find anybody that would write an article, or they didn’t try hard enough to find anybody, or they just didn’t think about it, it’s still a fail. They should’ve. And the same could be said for a few other PHP frameworks.

I wonder what were the criteria for the framework selection. Popularity couldn’t be the only one, because that would mean at least three frameworks replaced by others.

Even though, it’s an interesting issue, framework articles included.

Helper functions:

function write_obj($obj)
{
  file_put_contents('obj.data', serialize($obj));
}

function read_obj()
{
  return unserialize(file_get_contents('obj.data'));
}

Example 1
Serializing an object with a public property.

class X
{
  public $a = 'A';
}
obj_write(new X());

read.php declares a blank class.

class X
{
}
$x = obj_read();
print_r($x);
echo $x->a

As you might expect, the public property is restored correctly:

X Object
(
    [a] => A
)
A

Example 2
Adding some protected properties.

class X
{
  public $a = 'A';
  protected $b = 'B';
  protected $c = 'C';
}
obj_write(new X());

read.php declares only one protected variable $c.

class X
{
  protected $c;
}
$x = obj_read();
print_r($x);
echo $x->a;
echo $x->b;
echo $x->c;

An this is the result:

X Object
(
    [c:protected] => C
    [a] => A
    [b:protected] => B
)
A
Notice: Undefined property: X::$b in /home/gasper/phpser/test1-read.php on line 12
Fatal error: Cannot access protected property X::$c in /home/gasper/phpser/test1-read.php on line 13

As you see, print_r correctly prints out the object. Properties $b and $c are both protected. What differs is that when printing out $x->b, PHP reports that $b is undefined property, and it correctly throws a Fatal when accessing $c. The question is, why doesn’t the fatal error already occur when accessing $b? As you can see from print_r output, property $b is present in the $x, and it’s correctly marked as protected, just as is $c. The only difference here is that $b isn’t declared in the class definition, so I guess PHP checks the class definition when accessing properties, rather than actual object information.

Example 3
Now let’s twist up things some more by modifying X definition in read.php:

class X
{
  public $c;
  function getB()
  {
    return $this->b;
  }
  function getC()
  {
    return $this->c;
  }
}
print_r($x);
echo "a: " . $x->a;
echo "b: " . $x->b;
echo "c: " . $x->c;
echo "getB: " . $x->getB();
echo "getC: " . $x->getC();

As you can see, I’ve changed $c visibility to public, and I’ve written two getters. The former is a test whether I can shift visibility of $c upon unserializing, while the second will hopefully allow me to read the variables $b and $c, which are protected in the original definition, and not declared in this one.

Here’s the output:

X Object
(
    [c] =>
    [a] => A
    [b:protected] => B
    [c:protected] => C
)
a: A
Notice: Undefined property: X::$b in /home/gasper/phpser/test1-read.php on line 20
b: c:
Notice: Undefined property: X::$b in /home/gasper/phpser/test1-read.php on line 9
getB:
getC:

The first strange thing is that there are two $c properties declared; one protected and one public. While this might be expected (the serialized information specifically tells PHP to unserialize a protected variable $c), it’s still strange that I now have two variables named $c. I don’t think this is possible to achieve without serialization. If you subclass a class and shift visibility of a variable from private/protected to protected/public, you still only have one single variable, so this behavior may come as unexpected. Still, the $x->c and getC() both return an empty value, because no value for public $c was present in the serialized object.

The other thing is that I still can’t access $b, even through a getter. The property is obviously present in the object (as print_r shows), but even when accessing it through a getter, which has access to instance’s protected variables, PHP reports that it’s undefined. I can’t think of a reasonable explanation for that, but this again shows that care should be taken when serializing objects.

Conclusion
As stated before, serializing and unserializing objects with different versions of classes can be a cause for a lot of trouble. If your classes rarely change, or if you have some means of invalidating the serialized objects (ie flushing the cache, or rewriting the rows in the database), then you’re probably fine, although you should always be aware of possible consequences. Likewise, if you cache object with public properties only, these seem to work fine, whether they’re declared or not.

But if you have classes that change often or rely heavily on persistent storage of serialized objects, you should use another way of doing it. One way I can think of is reading the written object with the old version of the class, and passing them to another script/service, which writes them in the new format. This is possible to achieve, but is quite volatile. Other means include using XML to store persistent object data, perhaps even JSON. In these cases, you don’t store the object itself, just as with serialization, but a subset of its properties that are essential to restoring it correctly. Upon recreating the object, these properties are read one by one into a blank object of a proper class version.

So, that’s it. Take care with serialization!

Given the most common agreement about graphs of functions, we put effort (time, number of trials) on x-axis, and knowledge (skill) on y-axis. Knowledge is a function of effort; this means that f(x) will tell us the amount of knowledge a person has, given the amount of effort the person has put into something.

Let’s take a look at a shallow learning curve.

Gradual (shallow) learning curve

Now let’s take a look at a steep learning curve.

Steep learning curve

So, remember that steep learning curve means easy to learn, and gradual learning curve means hard to learn, and stop misusing the term.

Let’s categorize people in three groups. The first group are the tech-savvy users that know their way around their computers. The second group are people that know how to use a computer and the internet, but still take advice from the first group on matters like what program for recording DVDs is the best, what graphics card to buy etc. The third group are the ones that use computers, but don’t know much. This is the group that installs the most viruses on their computers. If I had to estimate the number of all people that belong to this group, I’d say about 50%, and I’m probably being generous. These are also the folks that we, users from group 1 and 2, are always yelling to: don’t install software from the web! Be careful what you click! You can get your computer infected if you install things from websites! If the website you’re visiting offers you to buy/install something suspicious, close it!

Which of these still use IE6? The third group, obviously, unless somebody from the first or second group installed Firefox on their computer. And who else? The people that work in companies that have more or less strict software-upgrading policies. The upgrades in these companies are performed by system administrators (or their slaves), that in most cases know what they’re doing.

Now let’s throw these people on the web and add this IE6 information bar on the websites they visit. The first and second group won’t see them, because they’re already using a better browser. The only people that will see it are the ones that don’t know what the hell the message is saying and the ones that can’t upgrade their browser by themselves.

If the group 3 does what we’ve been telling them for years, they’re gonna get scared, leave the site, and surely won’t install anything. So, not only the IE6Update didn’t reach its most-targeted users, it actually did worse: it scared the users off of a site that’s most likely a perfectly legitimate company site, a blog, or whatnot. Keep in mind that users from group 3 don’t visit slashdot.org, and the information bar is most likely out of the context of the website they’re visiting.

And what will the people that can’t upgrade their own browsers do? Not much, because they can’t. Most of them won’t even suggest it to their system administrators, because they don’t get to talk to them, and even if they could, they wouldn’t, because system administrators bite. So, another target group missed. Is there anybody left? No. Well, yes, the system admins themselves. Well, this is actually the group that the project should be targeting, but not by making random websites show the message.

To recap this point; the majority of people that will see this notice, will either ignore it, be confused by it, or even be scared off of a website, but they won’t upgrade their browser.

The other thing that’s wrong with this approach is that it’s exploiting (yes, exploiting) the information bar UI. It’s not meant to relay custom messages to users, it’s purpose is to let users know something from the specific tool they’re using — the browser. It should only be used by the browser. By using the information bar to show custom messages, you cross the line between good and bad practices, and are no better than spammers and attackers, which try to disguise their messages to gain users’ attention. Like a chatbox coming from the lower right corner, which is supposed to make you think you’re attractive, because a nice girl wants to talk to you. Or the Windows95 dialogue box that tells you you’ve won a car (probably the seventh car this year).

The Browser Information Bar is so useful only because through it the browser relays self-related important messages to the user. It has a distinctive UI, and lets users immediately know that their browser has something relevant to say. To push this thought further, it sends two messages to the user; the first message is that there is a state of the environment (the browser itself) that the user should be aware of — this is relayed immediately by the bar’s UI. The second message is the message itself. And while “having IE6″ could be considered to be a “defective system state”, this just isn’t a browser-created message, and is not legitimate. Where would we end if we start using this bar for everything? For notifying people they have private messages, for news, for advertisements? Well, it wouldn’t be the end of the world, but the browser’s messages would get lost among these less important ones.

So, even though I strongly agree that IE6 should be burned, and its ashes should be eaten by zombies, which should then also be burned, I strongly disagree with this project. It’s for a very good cause, but that’s a wrong way to achieve it.

1. Using open-source browser instead of horrible MSIE is inappropriate because “MSIE is free anyway, and using other browsers can cause problems with existing applications”. The facts that MSIE is the least secure A-grade browser on the market, and that in Slovenia Firefox has the biggest share apparently aren’t important.
2. OpenOffice is a viable option (wow!)
3. “Linux isn’t appropriate for workstations because it’s code is too open and it can become too vulnerable in case of mass usage.” I’m speechless.
4. Linux is already used on most servers. Impressive.
5. “Security is an issue with OSS, because the source code is available to general public.” Just as for #3, I remain speechless.

Source: slo-tech.com (in Slovene)

This is what you get if uninformed people make decisions. It’s utter non-sense with no solid arguments. Some of the points can in all fairness be called STUPID.

The difference between static and object method call isn’t about speed at all, it’s about what you’re dealing with and what you’re trying to do. If you have an object, you call an object method. If you have a class with a static method, you call the static method. You shouldn’t choose between the two just for the sake of speed. You shouldn’t even have the option of choosing. They’re not interchangeable. And, in most cases you should be using objects, not classes, for testability’s sake.

A similar case can be made for “accessing a global variable is faster then an object property”. If I start developing with this hint in mind, and I start putting object properties in the global scope, what I am going to get? A mess, that’s what. You should never think about putting an object property in the global scope, for any reason, optimization included.

Another example would be “an array is a faster alternative to a class with several fields”. (Should be object, not class.) Again, this makes little sense. An array is a hash-like storage of data, an object is a black box that receives and sends messages, it’s encapsulated data with behavior attached. These two are two different things, and if I change the code to use arrays instead of objects, the change ripples throughout the rest of the code. Again, this leads to messy code. Not to mention that in the spirit of OOP you should be aiming to use objects, not arrays. Sure, there are cases where this hint would be suitable, but optimization like this should be the last thing you think about.

There are more hints like this, but I’m not going to list them all, because I’ve made my point: most of the hints are invalid, because they compare non-interchangeable things. If I push it a little, it’s almost like saying: not using echo is faster than using it. Yes, it’s completely true, but these two options don’t do the same thing.

I can’t help myself, so I’ll say a little something about the famous PHP quotes optimization: single quotes are faster than double quotes. First, these two aren’t the same, so changing one to another ripples out. Second, with quotes it’s only about readability and taste. Third, the speed gain is literally negligible. This is another hint you should forget as soon as possible. A second spent on quotes optimization is a second lost. I just lost a few minutes writing this, but some readers will hopefully gain them by not bothering about optimizing quotes.

A lot can be said about optimization, but most of these hints sure aren’t worth remembering. Even more; forget them as soon as possible. If you have a speed problem, find out where it is, and fix it. In the vast majority of the time it’s IO-related resources: the database and files, maybe network shares, or whatnot. I’ve never seen a real-life problem where for statement was causing problems and foreach solved them. This just doesn’t happen, except maybe if you’re computing Pi in php-cli.

The path to optimization should be:

1. Write working code, no matter how slow it is. It’s a million times better than fast code with bugs.
2. If and only if you undoubtedly have performance issues, profile your code, locate and measure slow code.
3. Optimize the slowest thing. Only the slowest thing.
4. Loop.

Also keep in your mind that by optimizing your code, you reduce readability, and consequently maintainability. This means that you’ll lose more time the next time you come back to update or fix the code.

There are also some good points that Alex makes, so I’ll repeat them here, because these are worth remembering:

• use prepared database statements,
• avoid @ (error control operator),
• avoid notices and warnings in your scripts.

The fetchFromDb() method returned an empty array, which was stored in memcache. But, as it turns out, the bug was in checking of $results. An empty array evaluates to false when checking for true/false. I knew that already, but I missed this one.

So, the script issued a query, even though it already had a result. Luckily, this only happened with empty result sets, so the query was fast, and didn’t overload the server.

The correct code would be:

I’ve lost quite some time over this, so I’m posting this as a reminder: if possible, use strict checking.