Showing posts from May, 2010

FlashBlock for Chrome (and Firefox)

There's been a lot of discussion in blog circles about Apple's move to virtually block all Flash content from their iPod/iPhone/iPad products. Apple's claim is that Flash is buggy, insecure and kills the battery. Meanwhile, a full Flash player still hasn't been released on any Mobile phone OS to date (Android 2.2 has the 10.1 beta, which hasn't been overly successful).
I'm not sure where I stand on the issue. On one hand, Flash seems almost necessary for something like that iPad, that's supposed to be the ultimate browsing device. Without it, much of the existing rich web content cannot be viewed, and in many cases there are no alternatives other than getting off the couch and turning on your proper PC. On the other hand, Apple can choose to do whatever they want with their platform. If Symbian didn't have Flash, or LiMo, or some other obscure manufacturer specific phone OS, would anyone kick up such a storm? It seems people are either annoyed at the omi…

Facebook users still crying over privacy settings

I quit Facebook over a year ago for what I thought were obvious reasons. Yet every news source I read these days seems to have at least one post about how Facebook is sharing user data, or Facebook privacy settings being too complex, or settings not being fine-grained enough, etc, etc.

I realize this is just a band-wagon effect: one big news source writes a post about it, then all the others follow, and all of a sudden it's the biggest news of the month, until the next pre-release iPhone gets 'found' and dissected.

Facebook seems like a good idea at first: an easy way to find old friends, get connected and stay in touch. This works great when you have 5 people on your list. But soon your work buddies request to be on that same list, as does your boss, your cousin, your mum, your girlfriend, your girlfriend's mum, and her mum's uncle. You can't really reject any of these invitations due to social pressures.
So now you have 50 or 100 people on your list part of you…

Non-Blocking Asynchronous Google Analytics

Adding Google Analytics to your website is an easy way to get detailed visitor stats. All you have to do is sign up for a free Analytics account, and copy-paste a small Javascript snipped on every page of your website (or better still in a common header include file).
Originally, the only problem with this approach was that it added some overhead to your page rendering. That is, if you included the code snipped in your page HEAD section, the page would not continue loading or rendering until the Analytics code was retrieved from Google and executed. People worked around this by putting it just above the closing BODY tag, so it would be the last thing that gets processed in the document and hence would not hold back the rendering of other page elements.
This is a good enough approach for all client-static pages. That is, pages which don't run any client-side Javascript. Otherwise what happens is that whilst the Analytics script is loading and executing, all other Javascript actions,…

WAMP 2.0i and PostgreSQL on Windows

The WAMP project is an excellent Windows development stack. Simply download the latest package, run the installer and within minutes you have a full PHP/MySQL/Apache development environment. If using PostgreSQL however, you need to do a tiny little bit more configuration:Left-click the WAMP systray icon, go to PHP/Extensions and make sure php_pgsql and php_pdo_pgsql are ticket (or you can do this manually in the php.ini file)Go into the wamp/php/bin folder and copy libpq.dll, paste it into wamp/apache/binAlso install PostgreSQL if you're connecting locally (duh).Nothing to it really, just the second step is a bit cryptic. Failing to copy the libpq.sql into the Apache/bin directory will result in a PHP error along the lines of 'pgsql driver not loaded'. Checking phpinfo() will reveal no mention of pgsql. Also, the Apache error log may have something along the lines of "PHP Warning: PHP Startup: Unable to load dynamic library 'c:/wamp/bin/php/php5.2.6/ext/php_pdo_pg…

Upgrading to PHP 5.3 on Debian/Ubuntu

PHP 5.3 final release has been out for almost a year now. You can read up about all the new features and changes here. Important considerations in upgrading from PHP 5.2 are listed here, including a list of backwards incompatibilities (nothing too worrying).
Even though PHP 5.3 has been out for a while now, it's still a little hard to find in Debian repositories as it hasn't bubbled up to the main stable streams yet. This means if you use apt-get or aptitude or any related package managers, you'll only be able to get 5.2.x using the standard config.
To get access to 5.3 follow these steps: Backup your php.ini configuration file.Edit /etc/apt/sources.list and add the following line: "deb squeeze main">>apt-get update>>apt-get install php5locate the new php.ini file and transfer your settings from the old file if requiredRestart apache (/etc/init.d/apache2 restart)I upgraded a significantly large project using this method and…

Zend Framework Controller Actions with Function Parameters

This guide assumes you already know the basics of the Zend Framework Controller Actions. A typical Controller class with a default Index action may look as follows:

class IndexController extends Zend_Controller_Action {
public function indexAction() {
//get a 'name' param from the request (could be GET or POST, etc.)
$name = $this->getRequest()->getParam($name);

//make this parameter available to the default view for rendering
$this->view->name = $name;

This is a very simple example of how most actions will function. That is, the action retrieves a number of parameters from the request object, usually performs some logic on these parameters, then sets data to be used by the view. There's nothing wrong with this approach and it works.
But wouldn't it be cleaner if we could define parameter names and default values in the action function signature directly and have these available without needing to manually pu…

Simple PHP anti-brute-force login

You may have a simple site protected by a simple PHP username/password login script. The site may be so simple that the actual username/password and all other configuration settings are stored in plain-text files on the backend server and you don't even make use of a database.
How do you protect your site from someone that's trying to break your login though? Someone that writes a script and tries thousands of different username/password pairs per second? Well for one it helps if the username is something other than just 'admin'. But also, you want to prevent scripted login attempts by restricting the number of invalid attempts per hour. That is, after 3 incorrect login attempts, lock out the user account for 10 minutes. This means a hacker can try at most 18 password combinations per hour.
But if you lock by username, the hacker can use this to discover valid users, then try to crack the password. You can alternatively lock out after 3 invalid login attempts from a par…