High Performance Web Sites by Steve Saunders is an attempt at teaching people how to best go about optimizing their web sites. No I do not mean optimizing for search engines, I mean optimizing for the best user experience (and believe me it is a relief to have a book aimed at giving the user a better experience rather than the search engines).

The book is split into 15 different chapters. All chapters bar chapter 15 are all based around a rule that will help optimize your web site. Most of the topics covered are based upon how to lower loading times so that a user has the best experience on your web site (with the exception of a couple). Some of these rules range from the obvious such as ensuring you use GZIP compression as and when needed through to the ones you may not think about such as increasing your DNS TTL (time to live) values.

Most of the rules are very self explanatory and are presented in quite a good manor. Although some of the rules are in fact obvious and should not need explaining it is sometimes best to be reminded of such things. Other rules (such as the TTL rule previously mentioned) are not so obvious and (even for the most seasoned web developer) easily overlooked.

Steve Sounders has gathered his knowledge (as is evident in the book) from his extensive knowledge and work in Yahoo and their optimizing endeavors. The book works hand in hand with their Y-Slow addon for the Firebug firefox extension. As well as the Y-Slow addon the book also suggests a few other useful tools (including ones for Internet Explorer) that can come in handy.

All throughout the book Steve uses a list of top 10 websites as case studies and demonstrates those that follow the rule in question as well as sometimes showing how they can improve. As previously mentioned rule 5 is not a rule in itself but is actually a chapter dedicated at deconstructing the top 10 sites used throughout the book. It is good to see some constructive criticism on them and to see how they could improve which this chapter achieves to perfection.

The book as a whole is a very good read and I highly recommend it to anyone who deals with websites regardless of whether as a hobby or in a professional manner.

ShareThis

Fraud and theft have of course always been a problem within the industry but it seems in recent times the matter has multiplied.

In the past few months several forums have found their user base have been fooled by phishing scams (Namepros, DNF etc etc). This is not a problem with the forums themselves but more to do with the education of their users. As usual with anything the weak point is the users.

The phishing scam was a particular problem as it gave scammers credibility and they were able to buy and sell with ease as people thought they were dealing with reputable long standing members.

Another problem that is related as such is the stealing and selling on of domain names. Sometimes this is an easy thing to check. As can be seen from some recent cases you can contact the person who is listed in the whois (provided they do not use whois privacy, see not using whois privacy can be a good thing) to see if they are in fact selling the domain name. Of course if the domain has been stolen and the person who stole it managed to change the whois details this will not help.

This is where another technique can help. Sites such as Domain Tools offer a whois history search which can be extremely handy. If you check the whois history and it has recently changed hands it *may* be a sign that something has happened and may need closer inspection.

SO WHAT CAN BE DONE

Unfortunately at the moment scammers and thieves have got the upper hand. Their is no formal cooperation between the different venues for buying and selling domain names. Each has their own way of dealing with things and each keep a fair bit of information to themselves.

So how can this be stopped? Well like many crimes it will never be stopped 100% however we can try to make the crime harder for them to accomplish. The industry needs to have a shake up and for forums of business to cooperate with each other more. A recent incident on DNF could have been avoided if a proactive approach of cooperation had been sought. This is not a fault of DNF nor Namepros, the matter could quite as easily been the other way around.

Each site has made efforts in the past to help ensure the safety of their members but it was in essence an internal thing. As the efforts were internal to a particular forum it was met with suspicion from the other forum so not embraced.

The only thing I believe that can be done is to have a completely independent site that most (if not all) forums and places of domain business where reports of banned members are stored (of course only banned members who were banned for fraudulent activity rather something like swearing etc). The site would need complete cooperation from the domain forums to ensure that records were kept upto date (maybe for example have 1 staff member who sits on a board and is responsible for such cooperation). The site could also be used for example to keep track of domains that have *known* to have been stolen.

If such cooperation had been sought in the past and had actually taken place it could quite easily have stopped many fraudulent transactions from taking place.

What do you think?

Do you agree with this?

Do you think it could work?

ShareThis

Some people seem to believe that using the $_POST, $_GET… global arrays that they have protected themselves from the effects of register globals.

They couldn’t be further from the truth.

What Is Register Globals?

Register globals is a directive (or a group of directives to be more precise) which determines how information passed to a script an be accessed. If magic quotes is enabled for example and you pass a form field called ‘name’ to it using the POST method then the data is not only available in $_POST['name'] but also in $name.

Why Is This Bad?

This is bad for a number of reasons. Firstly you should always be aware where the data is coming from. Register Globals stops this from happening. In my instance $name could quite easily have came from a cookie of a form GET method.

The second reason is the cause for this article.

Consider the following piece of code

<?php
if ($is_admin == true)
{
echo ‘I am an admin’;
}
else
{
echo ‘I am not an admin’;
}
?>

This is nothing out of the ordinary. I am simply checking whether $is_admin is true. I would expect maybe a previous routine to set this if I am an admin. With register globals disabled this would work as expected with no quarrels. But what if I now call this script like the following :-

http://www.domain.com/script_name.php?is_admin=1

If global variables are enabled we have a problem. The $is_admin variable now contains 1 (which if you know PHP you will realise evaluates to true as PHP is a loosely typecast language).

So What Can Be Done About This?

This is quite simple, if you have the possibility of the server running the script having register globals enabled (or do not have control over the configuration) then you should guard against this.

The easiest way to guard against this is to ensure that you always declare important variables before you use them. So in my previous example you could do:-

<?php
$is_admin = false;
// Now check if I am an admin.
if ($is_admin == true)
{
echo ‘I am an admin’;
}
else
{
echo ‘I am not an admin’;
}
?>

As register globals carries out its process before our script starts running our variable will over write the variable the user tried to set.

But Isn’t Register Globals Disabled In PHP 5?

The default installation of PHP 5 does indeed have register globals disabled. Unfortunately however there is a need for many hosts to actually enable it as too many scripts wrongly rely on it. PHP 6 goes 1 step further than having register globals disabled in a default installation. In PHP 6 the directive is removed completely.

A Word Of Caution

1 word of caution. The PHP manual states that register globals can be set (and I quote) PHP_INI_ALL. This indicates that you can set the directive anywhere including within a script using the ini_set() function. Although technically correct you can indeed set the directive in a script, it will not have any effect what so ever. The work register globals carried out is actually already carried out before the directive would have been changed.

If you are going to change the directive do so in a .htaccess file (if you can) or in the php.ini file (the same goes for magic quotes).

Hopefully this has been helpful to you. I am hoping that it will have cleared up any misunderstanding on what register globals is and what it does.

If you have any questions please feel free to ask and I will do my best to answer them.

ShareThis

Wikia is of course only in beta mode at the moment but I already have a couple of problems with it.

Firstly try a search for anything you wish. Do you actually get decent results? No the results received are absolutely atrocious. I noticed on a blog I am a regular on that if you carry out a search for George Bush (1 of the most well known names in the world at the moment) the top result is a site telling me that George Bush is a crack whore. They also display pictures if you search for a name and they could only find 1 picture of the real George Bush.

Secondly I visited this page. I tried a search.

I was presented with an error stating that the server could not be found. Looking at the address bar I find that it is looking for http://http//re.search.wikia.com/search#seo. Notice the http://http://. That would certainly account for a server not found error. I went back to the page I tried the search from to find why this happened. Looking at the javascript for the page I find the following:-

function search(){
window.location='http://http://re.search.wikia.com/search#'+$('q2').value;
return false;
}

As you can see they have actually hard coded an incorrect search URL within the javascript. Come on wikia if you cannot actually handle something so simple how are you going to manage a search engine?

Wikia has got a long way to go before it is going to be any use to anyone.

ShareThis

My second plugin which I have just released in a beta state (and have applied for inclusion on the Wordpress site) is a cool plugin that will show you how many people are on your blog. It displays a handy link on the top right of your admin pages as well as having an added page within the Users section of the admin panel which shows who is online as well as what they are looking at. If you think this is an interesting plugin take a look at the Who’s Online Plugin page for more information.Now of course I am not making this post to tell you about the plugins I have already made. The reason for this post is that I want your ideas. What features do you wish Wordpress had, what features do you think could enhance it’s functionality.

If you can think of anything no matter how easy or how hard it sounds why not post a comment and you never know it might be the next plugin I make.

ShareThis

This of course caused problems with regards to sitemaps as the sitemap had to be placed within the domain/subdomain that it was being used under. And Google treated subdomains as if they were different domain names.

Things have recently changed however. Google now supposedly treat subdomain as if it were a sub folder. Subfolders are perfectly legal within a sitemap (as long as the sitemap is housed in a lower directory).

This brings up the question. Does Google now allow multiple subdomains within the same sitemap?

I have tried a couple o tests by injecting an address for a subdomain with the sitemap of the parent domain. Google have in fact downloaded the sitemap and at the moment are not reporting any problems.

The question is does this mean it is allowed or not? Did Google report this as an error in the past or did they simply ignore the address in question?

If anyone know be sure to let me know. I will of course keep you updated on any outcomes that I get.

ShareThis

At 00:30 or so Friday morning we found the server behaving erratically and finally becoming unreachable. Even a reboot would not fix it.

It turned out we had a rootkit on the server. We have now subsequently reformatted the server and are securing it to try to ensure it never happens again.

Here’s hoping for a smooth ride for a while.

ShareThis

The webinar is entitled “Seven Steps To Better PHP Code” and is split up into 2 separate webinars.

Part 1 will look at the following:-

1. Format source code consistently
2. Establish naming conventions
3. Create API documentation
4. Elimimate redundant and duplicated code

ENROLL HERE for part 1.

Part 2 will look at the following:-

1. Shorten code blocks
2. Separate different concerns
3. Replace implementations

ENROLL HERE for part 2.

These Zend webinars are free and anyone can enroll. I have attended a few and I am almost always learning nes things from them.

The webinars are live and you use a flash application that they provide to view them so almost anyone can attend without having problems.

ShareThis

The blog in question is Chris Schiflett’s blog. Anyone who has not heard of Chris obviously has not delved around the PHP world much. Chris is a prolific author, webinar host, interviewee etc etc. His main expertise comes from Security in the PHP world.

However the interesting part at the moment is not the posts Chris is writing for his blog. Chirs is currently hosting posts in the form of an advent calender. Every day another PHP coder is invited to share their tips on how to improve yourself as a PHP programmer.

So far we have had posts from Sean Coates (PHP Architect Editor), Sebastian Bergmann (PHPunit) and Cal Evans (Zend Developer Zone Editor In Chief) to name just a few. These posts are well worth a read.

If you are not already a subscriber Of Chris’ blog why the hell not go subscribe now

ShareThis

When choosing a programmer or coder (of anyone else that you wish to hire to do some work for that matter), there are several things that you need to do to ensure that you are hiring the best person for the job.

1) When preparing to hire someone. Ensure that you make a clear and detailed list of what you want. For example if you wish for a site to be made ensure that you list the main things that you wish for your visitors to be able to do. You may have a clear understanding of what you want but unless you can convey that properly to the programmer they will not understand your needs properly. Having a detailed brief will help the programmer when they are making a quote. Remember if you do not list something then suddenly add it to the project you may have problems as it has not been accounted for when the programmer has worked out how long it will take and how much it will cost.

2) Always ask for examples of the programmers past work. You can learn a lot from someone’s previous work. The examples can be either in the form of code they give you or links to sites they have worked on. If they provide links ask for details on what they actually did on the site. Some people would provide you with a link saying they built the site when in fact they may, for example, have only built the login system or the mailing system. If the programmer is unwilling to provide examples you have to wonder what they are hiding.

3) Before accepting a quote always ask for a time frame in which you can expect the work to be completed. If someone claims they can do it in a couple of hours and everyone else states days then ask questions on why they think they can achieve it so fast. Do not assume they can. They may have exaggerated how quickly they can do it just to get the contract.

4) Do not always go on price. The cheapest quote is not always the best quote (and for that matter nor is the most expensive). If you have a look around the script lance type sites you will find many instances of complex jobs getting pitifully low quotes. There are several possibilities here.

• The programmer is doing work cheap to get a good portfolio of work.
• The programmer is not actually aware of what is involved. Either due to the fact they have not read the brief or they have a lack of understanding.
• The programmer is low balling. Once he has the job suddenly things will become apparent that may increase the price

Of course there are other reasons as well but these are the main ones. Do not immediately believe that someone is capable of doing a job because they say they can. All too often this is the cause of problems. This is where point 1 comes into play as well. If the programmer has only ever worked on small scripts and never worked on a substantial project, be a bit weary for example if you are asking for a complete CMS to be made and they give you a quote.

5) Agree on a price BEFORE the work has started. As well as agreeing on price. You should also make an arrangement of what will happen if for example problems are found on the way. Problems do occur and this can cause conflict especially when the programmer feels the problems were out of the remit for the project. If you make prior agreements then this can be minimized. An agreement of this nature usually entails an upper limit on what you will pay on the finding of problems. Of course understand, that if the problem is too big a new agreement may need to be made. The agreement should also include other expenses that may be incurred. For example if you are having a site made and currently do not have hosting or a domain, this is an added expense that may not be included in the agreed budget. If this is the case insist that you are involved in the buying, or at least ensure that you receive invoices for these services. Ensure also that the programmer did not purely buy this service/product because of some affiliation they have with them.

6) Under no circumstances pay the full amount before the work has been completed. Like many people, programmers tend to lose interest when they have been paid. Most programmers will insist on a payment before the work starts. If this is the case make a payment of maybe 20%. If the job is a large job you may have to agree on paying in increments so that the programmer does not have to wait for the job to be completed before they get any more money. You may for example agree to make another instalment at each 20% completion interval. So you would pay a 20% (of the remaining 80% that needs paying of course) when the project is 20% complete then again at 40% and again at 60% until the project is complete. This ensures that the programmer is still keeping an interest and so that you still have a budget if the programmer walks away from the project.

7) Keep track of where on the project the programmer is at. All too often problems occur because the programmer may not have understood properly how you wish things to be and has ended up going off on a tangent.

These are of course only basic guidelines but if you follow them you have eliminated most barriers people have when working with contractors of any kind.

Can you think of any more guidelines that should be followed? If so let me know.

ShareThis