Seems like there’s really something special about window and document objects in IE. Just as with iterating over window properties, there seems to be some weirdness about deleting the properties in window DOM object.
Read more…
I’m really glad to see Lukas planning to push PDO a step higher. I think it’s already a decent extension, and has a bright future — since I first used the extension I’ve never ever used anything else for any database. It’s object-oriented, has a lean interface, it’s fast, and supports a major feature: prepared statements. I’ve completely forgotten about having to escape, because I always insert/update through these. Seeing mysql_real_escape_string() anywhere in code makes me sad, and seeing $db = mysql_connect() and then passing the resource around makes me sick 
. Yes, you can use a class to wrap this up, but why would you? PDO is just that and more.
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.
I’ve encountered LiveNetLive a few times, it’s a service that runs on top of your website and creates a live community chat. Never had any problems with it, until yesterday, when I tried posting a comment on some blog.
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.
For some reason php|architect’s June issue failed to list Symfony among 6 frameworks that are supposedly worth mentioning. I’m not going to speculate on why, but I will say that it’s wrong from at least one perspective.
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.
When it comes to (un)serializing objects in PHP, some things may surprise you. In this post I show what I’ve found out last week, when I was testing serialization with different class definitions. This is generally a bad practice, and shows one of the biggest drawbacks of using serialization for persistent object storage: the serialized data holds a frozen version of an object. As project evolves, and classes change, the serialized information doesn’t change with them. When objects are unserialized with the new class definition, it can result in unexpected behavior. You should take care when using serialization for persistent or temporary storage (ie caching objects in memcache), because every change in the class definition may affect the unserialized objects, causing numerous bugs and crashes.
Read more…
I keep bumping into articles or presentations where “steep learning curve” is improperly used, so I’ve decided to clear up the confusion. People often think that steep learning curve means something that requires a great deal of effort to learn. Well, it doesn’t.
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.
Most of you probably know about IE6 Update (implementation of which is, in fact, a fork of Activebar2), a movement that is supposed to help us developers force users to move away of the browser that is long past due. Well, while this project has a good intention, things shouldn’t be done that way.
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.
Slovenian government decided that Linux and open-source aren’t appropriate for government usage. The reasons being (a recap from the source):
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.
I’ve read this post about micro-optimization today, and I think many of the listed hints are wrong. Not wrong in way of being false, but in a way that you shouldn’t use them. Sebastian already wrote something about it, but more can be said.
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:
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:
Yesterday I’ve noticed that too many queries are sent to the database server, even though the result should be cached in memcache. After digging into the source and testing, I’ve discovered something like this:
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.