This time I'm reviewing a book by Andy King. Unlike High Performance website by Steve Souders, it doesn't solely focus on the speed side of optimization, but it adds the art of Search Engine Optimization to form a compelling mix in a single book.

If you have a website that underperforms your expectations, this single book can be your one-stop shop to get all the knowledge you need.

Andy uses interesting examples of how he succeeded in improving his clients' pages that illustrate well what he describes in theory before. He not only focuses on how to make your website show up at high ranks in search engines (what he calls "natural SEO"), but also discusses in detail how to use pay per click (PPC) ads to drive even more people to one's site. I especially liked how Andy describes how to find the best keywords to pick and also describes how to monitor success of PPC.

The part about the optimization for speed feels a little too separated in the book. It is a good read and provides similar content as Steve Souders book, though the level of detail feels a little awkward considering how different the audience for the SEO part of the book is. Still, programmers can easily get deep knowledge about how to get that page load fast.

Unfortunately Andy missed out a little on bringing this all into the grand picture. Why would I want to follow not only SEO but also optimize the speed of the page? There is a chapter meant to "bridge" the topics, but it turns out to be about how to properly do statistics and use the correct metrics. Important, but not enough to really connect the topics (and actually I would have expected this bridging beforehand).

Altogether I would have structured things a little different. For example: It's the content that makes search engines find the page and makes people return to a page, yet Andy explains how to pick the right keywords for the content first whereas he tells the reader how to create it only afterwards.
Everything is there, I had just hoped for a different organization of things.

All in all, the book really deserves the broad title "Website Optimization." Other books leave out SEO which usually is the thing that people mean when they want to optimize their websites (or have them optimized).

I really liked that the topics are combined a book and I highly recommend the book for everyone who wants to get his or her website in shape.

The book has been published by O'Reilly in July 2008, ISBN 9780596515089. Also take a look at the Website Optimization Secrets companion site.

Thanks to Andy for providing me a review copy of this book.

I have been attending this year's Future of Web Apps Expo in London's ExCeL centre.

There were a ton of interesting speakers and I enjoyed listening a lot. Amongst others there were Steve Souders of Yahoo (High Performance Web Sites), Paul Graham of Y Combinator (The future of web startups), Matt Mullenweg of WordPress.com (The architecture of WordPress.com, he was the only one to go into some detail) and Kevin Rose of digg (Launching Startups).

I also enjoyed Robin Christopherson's talk very much. He is vision impaired and showed how he browses the web (amazing how fast he had set the speed of his screen reader --- I know why and guess that most vision impared people turn up the speed, yet it still feels awkward to listen to it) and which challenges therefore arise. Unfortunately Chris Shiflett only held a workshop which I was not attending.

The conference was clearly not so much for developers (at some points I would have greatly enjoyed some delving into code), so I am trying to keep my eyes open for even nerdier conferences :) Any suggestions?

On the evening of the first day there was a "live" diggnation recorded which was pretty fun.

According to Ryan Carson, he will be publishing audio files of the talks on www.futureofwebapps.com soon. Thanks to Carsonified for installing this great conference. I hope I will be able to return next year.

I have posted more photos to flickr.

fowa, fowa 2007

Usually you see something like int(11) in CREATE TABLE statements, but you can also change it to int(4).

So what does this size mean? Can you store higher values in a int(11) than in an int(4)?

Let's see what the MySQL manual says:

INT[(M)] [UNSIGNED] [ZEROFILL]
A normal-size integer. The signed range is -2147483648 to 2147483647. The unsigned range is 0 to 4294967295.

No word about the M. The entry about BOOL suggests that the size is not there for fun as it is a synonym for TINYINT(1) (with the specific size of 1).

TINYINT[(M)] [UNSIGNED] [ZEROFILL]
A very small integer. The signed range is -128 to 127. The unsigned range is 0 to 255.

BOOL, BOOLEAN
These types are synonyms for TINYINT(1). A value of zero is considered false. Non-zero values are considered true: [...]

So TINYINT(1) must be different in some way from TINYINT(4) which is assumed by default when you leave the size out¹. Still, you can store for example 100 into a TINYINT(1).

Finally, let's come to the place of the manual where there is the biggest hint to what the number means:

Several of the data type descriptions use these conventions:

M indicates the maximum display width for integer types. For floating-point and fixed-point types, M is the total number of digits that can be stored. For string types, M is the maximum length. The maximum allowable value of M depends on the data type.

It's about the display width. The weird thing is, though², that, for example, if you have a value of 5 digits in a field with a display width of 4 digits, the display width will not cut a digits off.

If the value has less digits than the display width, nothing happens either. So it seems like the display doesn't have any effect in real life.

Now² ZEROFILL comes into play. It is a neat feature that pads values that are (here it comes) less than the specified display width with zeros, so that you will always receive a value of the specified length. This is for example useful for invoice ids.

So, concluding: The size is neither bits nor bytes. It's just the display width, that is used when the field has ZEROFILL specified.

If you see any more uses in the size value, please tell me. I am curious to know.

¹ See this example:
mysql> create table a ( a tinyint );
Query OK, 0 rows affected (0.29 sec)
mysql> show columns from a;
+-------+------------+------+-----+---------+-------+
| Field | Type       | Null | Key | Default | Extra |
+-------+------------+------+-----+---------+-------+
| a     | tinyint(4) | YES  |     | NULL    |       |
+-------+------------+------+-----+---------+-------+
1 row in set (0.26 sec)

² Some code to better explain what I described so clumsily.
mysql> create table b ( b int (4));
Query OK, 0 rows affected (0.25 sec)

mysql> select * from b;
+--------+
| b      |
+--------+
| 010000 |
+--------+
1 row in set (0.00 sec)

mysql, field size

The answer is simple: I have created a Spreadshirt shop.
So if you want to get one for yourself (or someone else), go ahead and get it :)

There is also a German version available (I am a native German speaker :), if you'd like to translate it to your language, I can add it there with no problem.

The list that Spamhaus provides is actually something good: it allows mail server administrators to automatically block mails arriving from servers that are known to be operated by phishers.

At this point Spamhaus took the wrong term, though. They demanded from the Austrian Registry to delete 15 domains that they consider to be used by phishers, apparently without providing (enough) evidence to nic.at. So nic.at responded that --- because of Austrian law --- they cannot just delete domains without proof of bogus WHOIS addresses.

I cannot judge who is ultimately right in this dispute (like did Spamhaus provide enough evidence or not), but I can definitely judge that Spamhaus took the wrong decision when they started to block the IP addresses of nic.at in their list.

Welcome to the Kindergarten, guys.

nic.at is bound to Austrian law, and as a foreign company you can't just come along and ask them to remove certain domains. What if someone would go to your registry and request deletion of spamhaus.org without providing any legitimate reason.

Dear Spamhaus, you need to stick to your policy. Your block list is about phishers, and nic.at did not send out any phishing mails. You can't just put someone on there because you want to pressure them.

As a result, mail server administrators should no longer rely on block lists of such a provider who misuses his own list for trying to put other companies/organizations under pressure. So this is the right moment to remove sbl-xbl.spamhaus.org from your server configuration.

Coverage on the German Heise.de.

Update 2007-06-20: They have stopped listing nic.at. Finally they see reason. (They have changed the IP address block to 193.170.120.0/32 which matches no addresses); also see german futurezone.

nic.at, spamhaus, sbl

In the first place, they announced inline editing which is very slick. You just click on "edit" on the "your bookmarks" page and you can edit the item right away.

They also updated the URL page which looks very nice and tidy now.

These updates don't affect blummy, you can still use it to add your bookmarks from any page. If you haven't seen it, give it a try.

The announcement also says that private bookmarking (one of the big missing features) will be released next week.

digg it, add to del.icio.us

del.icio.us, interface, update

A typical request to a webserver looks like this: Client browser opens connection to server port 80, server sends back the data through that connection. For the time of the transfer the server "loses" one child process. So if a client with a slow connection requests a large file this can take some minutes. If many slow clients block child processes, eventually too few will be left for "ordinary" clients.

A solution for this is to prepend a proxy server to the HTTP server. The proxy server is lightweight and does the communication with the client browser. The communication with the web server is done via a high speed interface (either loopback when it's just one server or an lan with 100(0) mbit), so almost no time is spent waiting for a transfer to finish.

Setup is easy, and I've covered this in my thesis already.

But I've got some more real-life info for you.

There are two usual ways for setting this up.

1. Set the web server to listen on port 81, Squid on 80.
2. Web server still listens on port 80 but just for 127.0.0.1, the loopback interface. Squid listens on port 80 on the external interface.

What makes number two the favourable is that you are not haveing a server process listening on an unconventional port, and, for redirects (Location: /somewhereelse) the port number is correct (see the corresponding question in the Squid FAQ). For existing configurations with virtual hosts there is no need to change a < VirtualHost *:80> to < VirtualHost *:81>.

So in ports.conf of Apache, for example, you change this:

# Listen 80
Listen 127.0.0.1:80


In squid.conf you do these changes (apart from those listed in my thesis):

# http_port 3128
http_port ip.add.re.ss:80


So this works nice already, but there is one more thing. Now the source address for a http request is 127.0.0.1. So if you want to do some processing with the REMOTE_ADDR, for example in PHP, you'd have to insert something like this before you'd could use the address again.

if (isset($_SERVER["HTTP_VIA"])) {
        // squid http accel
        $_SERVER["REMOTE_ADDR"] = $_SERVER["HTTP_X_FORWARDED_FOR"];
}


Also in the log files there is now a 127.0.0.1 as source instead of the real ip address. The following changes things back to normal (in apache2.conf):

# LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combined
LogFormat "%{X-Forwarded-For}i %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combined


This should be all for now. Happy speed-boosting ;)

go on, go on, go on. that's what i want. i don't like reading on the screen very much. i waste tons of paper just for printing internet pages and reading them, e.g. while travelling around through vienna by tram.

unfortunately the e-book device development seems to have stopped in 2002. i hope that this will push forward new products, although i believe there wouldn't be an affordable one within 2 years. in the u.s. give europe another year. :o/

an additional note to the hardware developers: don't even think about a two-display/double-page e-book device. that's what i always hated about books. when reading while lying the next page is always uncomfortable to read.

still one more: don't mess around with supporting a lot of document formats. just pdf will do (flexible os'es let you save any printed document as pdf).

ahh. one more: underlining words on such a device would be too much comfort for the beginning. needing a touchable display it would be too much work. postpone it. please.

now for the last point: use e-ink. it only needs energy for displaying new pages. this will make the battery as long lasting as i want it to be.

e-ink, e-book, pdf