Bugzappy's Blog

Read on slashdot: how Amazon is still filing patents on the obvious, hoping to get a last few into the USPTO before the patent officers are finally told to reject this kind of “fluff”:

A method of providing fixed computer-displayable content in response to a consumer request for content, the method comprising:obtaining a digital image corresponding to the requested content;selecting an advertisement to be included in an on-demand electronic content corresponding to the requested content;including the advertisement the digital image corresponding to the requested content;generating fixed computer-displayable content corresponding to the requested content; andproviding the computer-displayable content to the consumer.

from United States Patent Application 20090171750

see also United States Patent Application 20090171751

Nothing in there would be new in any way shape or form, if it were not for the word “fixed”. So basically the patent applications are on the idea that you have an electronic book with pre-allocated spaces for advertisement. When you order your e-book, the publisher (Amazon) plugs in ads-du-jour, tailored to your interests/profiles/secret-Amazon-file.

This idea is a hybrid between newspaper advertisement and adsense.  There are so many examples of publications that come so close to Amazon’s patent claims, that it is hard to imagine how they could get through the patent examiner’s net, especially given the current crack-down on “business method” patents. If all goes well, soon this kind of patent application will be a dying breed; and our children will laugh at us for letting this kind of thing happen in the first place.

Shame on Amazon for filing this literal piece of c**p. I hope none of their claims make it through; it will be such a waste of money and intelligence to challenge them — and yet surely win.

Shame on the inventors, Zhou; Hanning; (Seattle, WA) ; Liang; Jian; (Seattle, WA) ; Yacoub; Sherif M.; (Seattle, WA).

I personally would not write home about having “invented” anything here. The way it happened is probably something like this: 3 guys had a meeting, someone said “hey let’s make e-books with ads in them”, another one said “yeah right, just like AdSense but with books, and then we target users with ads based on their profiles, right?” and the third one said “let’s file a patent on it”.

I wonder if one of these guys has a tie that curls up in a funny way, another one is bald and wears square glasses, and the third one has pointed hair on each side of his head. Because this story might have been copyrighted by Scott Adams already. Or perhaps they licensed the rights.

About 4 weeks ago I posted a blog entry with a long list of things to think about before exposing your code, data and CPU’s to the masses. My list is really written for people whose head is on the block if things go wrong, and is really concerned with “have you thought about all the categories of things that can go wrong?”

In this month’s FREE php|architect issue (available only in PDF), Eric David Benari provides a list of much more specific things to check on the implementation side. It almost sounds like “did you brush your teeth before going to bed?” (I say this in a good way), with things such as having your 404 and 403 pages set up properly, ensuring browser-side caching is specified correctly, serving data and files from RAM not from disk as much as possible, and more. It’s a useful list with good sample code, I recommend it to new web developers as an overview of what aspects of coding for performance deserve attention, and to more experienced coders as a handy cheat sheet.

Now for a bit of a critique. Some of these coding techniques will help a site’s quality a lot, but frankly, if you are testing, then you’ll find out about these issues earlier than at the time of going through the checklist. 

Others will increase your site’s performance by a lot, but if you are benchmarking your app to meet a specific demand, then you’ll know there is a problem (or not) before you look at the checklist.

What really matters is that (a) the way you’ve coded your app and deployed it, it will provide the expected quality of service, and (b) when you need to improve performance, you have a solid idea of how to do so (improve the code, re-code, add hardware resources.) The techniques outlined in Eric’s article are key to both.

So I’m going to stay with my more abstract checklists, along which I have very concrete toolboxes such as the “coding checklist” in Eric’s php|architect article.

So you’ve coded it, tested it, debugged it, and your client likes it. Time to go live. NOT.

Going live is a point of no turning back. Once the application is live, the whole thing goes from debug-mode to *operations* mode. You must react in *real time* to anything bad that happens to it. 

Thus before turning the big switch on, it helps to have a sense of what you are getting into, and it is also your responsibility to let your client know where the risks are. 

Here is a list of questions, some of them pointed, and others just to make you think about what else might go wrong and what the cost of that would be. I don’t claimed the list to be complete. At the same time the list is too long to apply to most smaller projects. Use it as a source of ideas to build your own checklist.

General risk management

1. Have we documented the client’s disaster scenarios?
2. Have we documented how we mitigate these risks, how we recover from them?
3. Have we tested the recovery processes?
4. Have we implemented and deployed all elements of risk mitigation and recovery?

Application hosting

1. Is the control pannel disabled if that’s possible?
2. Is SSH access set up to use a public key encrypted password?
3. Is SSH access (port 22) restricted to IP addresses belonging to the client or and/or Logimake?
4. Is “root” user barred from using SSH?
5. Are the usernames and passwords which can access SSH random strings?
6. Is firewall set up? Does it allow access to ports other than 80, 20, 21, 22, 443, and any ports above port number 1024 which are needed for testing?
7. Is the process for deploying the application on a “fresh” OS documented?
8. Has this process been tested?
9. Does the client know the time required to deploy the application on a new server?
10. Have we benchmarked the hosting services tech support (responsiveness and quality)
11. How long will it take us to recover from a complete and permanent meltdown at our hosting provider

Database

1. What data in the database is sensitive in the commercial and legal sense?
2. Have we documented how difficult it is for a hacker to access this data?
3. If db transactions are used (commit / rollback), is the db engine for all the tables set to InnoDB?
4. Is the database accessible on a TCP port or only on a socket?
5. Can the database host, port, username, password and database name be guessed easily?
6. Is there a need for the application to use multiple db users with different privileges on the db tables depending on the part of the application accessing the db?
7. Have the usernames and passwords been changed to random strings?
8. Do these db users have limited provileges, and only on the application db?
9. Change the root username to a random string
10. Is the root password set to a random string?
11. Is the frequency of the backups sufficient?
12. Are the backups sent offline instantly?
13. Has the recovery process been documented?
14. Has the recovery process been tested?
15. Is the client aware of the potential loss of data between the last backup and the time of failure?

Storage

1. What local files are sensitive in the commercial and legal sense?
2. List all processes in the application which require hard-drive storage, and on which partition (Apache, MySQL, etc)
3. Compare to available storage on each partition
4. What are the means for notifying admins that storage space is running low?
5. When these processes run out of storage space, do they corrupt data?
6. When these processes run out of storage space, do they fail elegantly as seen by the user?
7. Same questions about off-site storage (e.g. S3)

Error handling

1. List all types of errors and exceptions that can be generated by each sub-system
2. Are all types or errors and exceptions caught and handled in a way that the user or admins can recover from the error manually?

Response Time and Throughput

1. Have we listed all I/O channels (I/O ports, HD access), their capacity, and the expected average and peak traffic?
2. Have we load tested the application from each I/O channel?
3. Are the test results documented and approved by the client as acceptable?
4. Have we verified that the load balancers and load balanced resources have the expected I/O statistics?
5. Have we verified that session handling is done as we expect by front-end load-balancers?
6. Have we benchmarked replication / synchronization b/w database instances?

3^rd-Party Systems

1. Have we listed all the 3^rd party systems?
2. Have we documented information to access the following resources for each: administration panel, tech support, billing support, developer’s documentation
3. When will each 3^rd-party system be up for next payment? For renewal? Who will have the decision and purchasing power?
4. What are the scheduled system outages?
5. How do we deal with each of them?
6. Have we listed all scenarios where an external system fails, and how our system handles that?
7. Is the client aware of the risks presented by 3^rd-party system failures?

Development and test data

1. Is there any trace in the deployed code and/or data of development and/or test activity?

Security

1. Have we listed the various types of data that are subject to security breaches (theft, fraud, etc)
2. Have we documented the risks associated with each type of data being compromised?
3. Have we reviewed the code for security using our internal security guide?
4. Have we had the code audited by an external security expert?
5. What means do we have for rapidly stopping and/or reverting damage being done by an ongoing security breach?
6. Can we tell when data has been compromised, and which data?
7. Does the client have a plan for controlling the damage resulting from security breach?
8. Is the developer’s liability in case of a security breach documented, understood by the client, and accesptable to the client and to the developer?