Ecommerce and Entrepreneurship Blog | About | Contact | Store

Gaming Google's Rankings By Being Bad

Posted on December 6, 2010 by Trevor

The Google ranking mechanism is an interesting topic, as having good organic rankings has become the lifeblood of many businesses. Most people, when searching Google, find what they are looking for on the first page or two, so getting your link at the top can be the most important thing you can do to increase sales. It's always struck me as odd that power over such a large sector of the economy has come to be in the hands of a single company. Not that I think Google is doing a bad job. As a customer, I've always found that Google returns the best search results for my queries. Nevertheless, such a centralized system does have its downsides.

Rather than parsing and ranking sites by hand, an insurmountable task, Google relies on a complex internal algorithm to automatically return appropriate search results. Since this algorithm is at the heart of most of its ventures, Google keeps a careful eye on it, remaining tight-lipped about its internal details and reserving entire teams toward fine-tuning and updating it. Even so, any algorithm can be susceptible to gaming, and the promise of doing so is so great in Google's case that there is no shortage of attempts.

One recent story that's come to light is of a small eye wear company called "DecorMyEyes" that did just that. As it turns out, the owner of the one-man operation did everything in his power to enrage his customers and generate public complaints. Why? Well, there's a saying in show biz that goes, "There's no such thing as bad publicity." It turns out, that saying was literally true online. Many of the posts and articles lambasting the company's service also included a link to its site. Google, noticing the many links but oblivious to the reason for them, happily kicked the site up the rankings until it was near the top. Then visitors, seeing a site near the top of the rankings, would visit and make purchases. It was an ingenious attempt to exploit a loophole in Google's algorithm, and for a while it worked pretty well.

However, due to the additional exposure the company gained through the article I linked, Google itself became aware of the situation. Clearly directing Google visitors to sites that cheat and threaten them is not in Google's best interest, so they quickly set about rectifying the situation. They soon made a blog post announcing that the loophole had been closed. Unfortunately for us, Google remains as tight-lipped as always regarding the details of their solution, mentioning only that they are not specifically blacklisting the site or using some kind of content analysis to detect "negative" links. Presumably, then, they are analyzing the traffic to this and similar sites, and picking up subtle differences from legitimate retailers.

Of course, this is good news for those of us who *are* legitimate retailers and pride ourselves on giving a good customer experience. Presumably this same algorithm should not only eliminate fraudsters, but also lower the rankings of competitors that attempt to maximize volume at the expense of individual customer experience. However, as I said before, any algorithm is susceptible to gaming. This is simply one more step in the fight between Google (who needs to keep visitors coming by serving them relevant and desirable search results) and online businesses (many of whom want to capture as many of Google's visitors as possible, regardless of relevance or desirability). Only time will tell how effective this measure will be, or where the next threat will appear.

Update: After I made this post, one more event in the story has occurred. Vitaly Borker, the owner of DecorMyEyes, has been arrested on counts of fraud and threats. So, as it turns out, there is indeed such a thing as bad publicity for Mr. Borker.


Sinks come in all shapes and sizes. sells everything from bathroom sinks to kitchen sinks and vessel sinks. There has never been a better time to upgrade your sink then now!

Web Development for the Non-Programmer: Sessions, States and Cookies

Posted on November 30, 2010 by Trevor

My last article in this series discussed the process that a server follows to produce a web page. To simplify things for that article, I considered the generation of the page on its own, without interaction from a larger context. However, one of the major needs for any sizable site is to interact with visitors on an individual basis, responding to actions they take and remembering preferences they've indicated. Web developers must use special methods to provide this degree of interactivity.

Web pages operate on what is called a "stateless" protocol. That is, every time a web page is requested, it is treated as an entirely separate event, without indication of former interaction (with certain exceptions I'll mention below). In order to tie the pages in a site into a seamless experience for the visitor, developers have to emulate states (different behavior based on former interactions) using server code and data passed between the server and the client.

States are emulated like this: when a new visitor requests a page for the first time, along with the page the server sends back a unique identifier for that visitor. The next time the visitor requests a page, the identifier is sent back along with the request. The server recognizes the identifier and makes any necessary adjustments in the generation of the page, then sends the new page (and usually the identifier again as well) back to the visitor. This game of tennis continues as long as the visitor keeps requesting pages and the server keeps recognizing the identifier.

There are several forms this identifier can take. One method is to add a hidden form field (similar to the ordinary form fields where you are asked to type in, say, an email address) that is passed along when a visitor submits a form. However, this has the disadvantage that the user must click on specific buttons or links in order to keep this going. To get around this problem, the server can send a "cookie" to the client. A cookie is a piece of data that the client stores and sends back to the server whenever it requests a page. It can be any type of data, but one of the most common is a session identifier. This allows the server to keep track of the visitor whether the page was requested through a form or a link or just typed into the address bar. It's also possible for the server to recognize the client from data that is already available (such as the IP address or previous page), but this is unreliable and is rarely used by itself for establishing sessions.

With a method for establishing the identities of its clients, the server is then able to serve up pages customized for each client. One such application is client accounts. The methods used to set up a session don't require the visitor to log in or verify their identity, but if the developer adds a login page and stores the credentials on the server, the visitor can then log in from any computer and link their session with their account on the server. This allows them to perform private transactions like buying a product or storing sensitive information without fear that others will be able to access their account. Of course, it's also useful for remembering the visitor's preferences between visits.

One issue that developers have to deal with regarding sessions is their use of cookies. Due to both misconceptions and legitimate issues, many people have negative associations about cookies. One misconception is that cookies can compromise a computer. In fact, cookies are only passive pieces of data; they can't "infect" a computer or cause it to perform any actions at all, let alone malicious ones. Neither do they allow servers to gather private data about a computer; they are simply generated on the server and not modified by the client, so any data stored in a cookie was already available to the server when it was generated. Now, this is not to say that cookies cannot be misused. Some advertisers use cookies to track visitors across multiple sites (only the sites that have ads from that advertiser, though) and determine their browsing habits. These are called "third party cookies", and many people consider this an intrusion of privacy. An important responsibility for web developers is to use cookies in a way that is helpful to visitors rather than intrusive.

You can find the other posts in this series below.

Web Development for the Non-Programmer: Web Applications and Servers

Web Development for the Non-Programmer: Browsers and Programming Langauges

Web Development for the Non-Programmer: Introduction


For the best prices, on the largest selection of faucets, from your favorite brands like Kohler, Danze, and American Standard shop 24 hours a day, 7 days a week.

Web Development for the Non-Programmer: Web Applications and Servers

Posted on October 22, 2010 by Trevor

This article is the third in a series on web development for the non-programmer. For the first, go here.

To a visitor, a web page is simply an HTML file (with its associated images and other resources). It doesn't matter where it comes from or how it's made. A web server could act much like a hard drive, simply storing and retrieving HTML files. However, such a server would be static: the pages would always be exactly the same for every visitor. While this is fine for some sites, many sites need features that aren't possible with static pages: features like visitor accounts, changing statuses and online purchasing. To do this, web servers need to create and serve HTML pages dynamically.

In order to dynamically serve web pages, web developers use a suite of server-side applications and tools. At the heart of these is the server itself. This is the application that receives incoming connections, retrieves the web page (either from a file or by calling a program that generates it) and sends it to the client. The server also responds to requests for images and other resources, usually by simply retrieving the file requested. Note: confusingly, the term "server" is applied at several different levels, with context determining whether it references the machine ("The server is down"), the operating system ("Windows Server 2008"), or the actual program. There are currently two popular server applications: Apache, a free, open-source, cross-platform server for general use, and IIS ("Internet Information Services"), Microsoft's server software targeted mainly toward businesses. Both have many features beyond simply passing HTML files, including standard plugin systems that allow them to handle virtually any input or output. Each is able to handle multiple simultaneous requests, running the necessary plugins separately for each request.

Generally web pages are created using a programming language that is specifically adapted to the task. Common languages include PHP (with Apache) and ASP.Net (with IIS), but practically any language for which the server has a plugin can be used. Since HTML files are basically text files, they can be created using any process that generates text. However, most languages use a template-based approach, where the body of the web page is stored as a template, with fields or areas that can be filled in dynamically using code that the web developer writes. This could be something as simple as filling in the visitor's name or as complex as generating a list of products for sale with pictures and "buy" buttons. Large, complex websites have millions of lines of code, all centered around generating the text in the HTML files they serve.

It is possible for a web site to handle all the data involved with creating and serving web pages on its own, either stored in temporary memory or in files on the hard disk. However, most larger web sites use a database for that purpose. A database is a program or system used to quickly and easily store and retrieve large amounts of data. They keep the data safe and secure, and help prevent issues such as two users trying to change the same data at the same time. They aren't limited to web applications, but they are ideally suited for them. There are quite a few different database systems, each targeted at a different usage sector. Microsoft's SQL Server, for example, is aimed at large business applications, while MySQL is generally used for smaller sites and programs, and SQLite is an extremely lightweight database for applications that need only basic functionality. The vast majority of databases use a language called SQL ("Structured Query Language") to store and retrieve data.

To sum up the server-side process, then: When a visitor sends a request to a web server, the server application receives that request. It determines how that request is to be processed and passes it to the appropriate plugin or program. If the web page is to be dynamically generated, the code that the web developer wrote is run, often using templates to create the structure of the page and retrieving page data from a database. The completed page is passed back to the server application, which sends it to the visitor's computer.

The server-side process is the heart of web development, and to attempt a short list of related topics and current events would be foolish. The field changes continually as new program versions are released and new techniques are developed. One of the long-standing debates is between using the open-source Apache server and related technologies versus the closed IIS/ASP.Net system. An open-source .Net platform, Mono, was recently released that promises to mix things up a bit by allowing ASP.Net pages to be run on Apache (and other) servers. Cloud hosting is also gaining ground as a viable option, with pages being created and served from any one of a number of shared servers across the internet.

Stay tuned for next month when we go more in depth on other aspects of web development.


For the best prices, on the largest selection of faucets, from your favorite brands like Kohler, Danze, and American Standard shop 24 hours a day, 7 days a week.

Web Development for the Non-Programmer Part Two

Posted on October 1, 2010 by Trevor

This article is the second in a series on web development for the non-programmer. For the first, go here.

Web developers use web technologies to communicate with others over the internet. Specifically, web developers create the documents that web servers pass to clients, either directly or through software that automatically generates the documents. Servers can create and provide any kind of documents: the client, however, must have software that can read and display the documents. The primary type of software used to display web documents is called a "browser". There are many browsers; several in common use are Firefox, Chrome, Internet Explorer, Safari, and Opera. Most browsers accept several different types of encoded document, such as HTML, CSS, and Javascript, that work together to display a web page. They also accept resources like images and embedded media, and can often be enhanced with "plug-ins" that recognize additional documents like Flash, Quicktime, and Silverlight. One of the web developer's primary jobs is to ensure that web pages can be properly displayed in all of the major browsers.

The basis for a web page in almost all cases is Hyper Text Markup Language (HTML) or a closely related language like XHTML. HTML is a standardized "language": a method for encoding content in a document. It's accessible to both humans and programs; it does this by wrapping human-readable text in "tags" that indicate the role of the text in the document. For example, a paragraph of text could be wrapped in "p" tags that tell the browser it is meant to be displayed as a paragraph. HTML also provides "links" to other documents in the form of URLs that can be retrieved either immediately (for embedded content intended to be displayed as part of the page) or when the user performs an action such as clicking on an link (when accessing a separate document such as another web page that's intended to replace the current page).

HTML provides the content, but it provides only rudimentary control over the formatting of the document. For that, most web pages rely on Cascading Style Sheets (CSS), a language specifically designed for formatting. CSS code can be integrated into the document or linked as a separate document. It provides the browser with descriptions of the elements of the document; for example, the color of a piece of text, or the size of an image. CSS is a more volatile language than HTML, and different browsers often display the same document differently. One of a developer's major skill requirements is the ability to make documents appear the same across disparate browsers, or at least to make them look good.

Increasingly, web pages are becoming "dynamic", providing animation and interaction without requiring a round trip to the server to retrieve another page. CSS provides a very limited amount of interaction, such as changing the format of a link when the cursor hovers over it, but general dynamic content requires a language such as Javascript. Javascript is actually just the most well-known among a family of languages based on the standardized ECMAScript. Unlike HTML and CSS, Javascript is not simply a method of formatting static content. It is a "procedural" language that describes the steps necessary to perform an action, and more closely resembles the languages like C++ that are used to create computer programs. Because of this, Javascript is able to make the web page act like a program, moving and responding to user input.

Internally, browsers use something called the Document Object Model (DOM) to keep track of the elements of a web document. The DOM is a hierarchical organization of page elements that stores all of their names and properties. Each of the technologies we've discussed in this article works by manipulating the DOM. HTML describes the elements on a page, and HTML tags often have a one-to-one correspondence with DOM elements. CSS sets many of the properties on DOM elements. Javascript can directly access and change the DOM, causing the browser to respond by changing what it displays to the user.

All of these technologies occur on the client's machine after it downloads the document(s) from the server. They don't have access to other documents or programs on the server unless the client retrieves them separately. They depend on the browser to understand them correctly and display their content to the user. Because they are visible directly to the user, they take up much of the focus in web development. Issues regarding these technologies often revolve around the changing standards, such as the new CSS3 and HTML5 versions, and support for various features among the browsers.


There are countless possibilities when remodeling your kitchen. Blend style and innovation with a pull out kitchen faucet, upgrade your design with a modern stainless steel Kitchen Sink, help conserve your food waste with an InSinkErator garbage disposer and keep your kitchen free of smoke and odors with Kitchen range hoods.

Web Development for the Non-Programmer

Posted on September 14, 2010 by Trevor

"Web Development for the Non-Programmer" will be a new series of articles I'll be posting (along with my one-off articles). In it, we'll explore the facets of web development on a conceptual level, without going into technical details. This will help you to understand what your developer is doing and better communicate and plan development projects. You shouldn't need more than basic knowledge of computers to understand these articles.

Conceptually, web development is using technology to allow large numbers of dispersed people to communicate. It shares this goal with development in other medias such as radio and television, telephone and cellular technology, and even newspapers and magazines. More specifically, web development uses computer technology to deliver individualized, interactive communication to a large group of people. It does this using the Internet.

The Internet is the name for the worldwide network of computers connected to each other by cable, fiber optic backbone, and satellite using the Internet Protocol (IP), which gives each device a unique address at which it can be found. The internet has a hierarchical structure: large fiber-optic "backbone" cables provide the major links between hubs, and mid-level Internet Service Providers (ISPs) connect individual computers with these hubs. The internet is simply a way for computers to connect with each other, and is used for many different kinds of connections. It can be used to transfer files, play "online" games, send messages and email and even remotely control devices. Often, specialized computers called "servers" are set up whose primary purpose is to automatically provide services over the internet so that other computers (called "clients", and usually human-operated) can access them. There is one service on the Internet that allows certain computers to be referred to by an alias (called a "domain name") rather than their IP address. When using this service, a client will connect to a Domain Name Server (DNS) and pass it the domain name of the computer it wishes to reach (for example, ""). The DNS then sends the client the IP address of the target computer, and the client then connects directly to the target computer. Many different services make use of domain names to make internet addresses more accessible.

One specific type of service that uses the internet is called the World Wide Web (or Web, for short). Web servers provide documents (or "pages") and resources in a specific format that allows them to "link" to each other (and other services). The primary purpose of the web is to display formatted text, but web documents also typically incorporate images, embedded media, and dynamic content. Web documents are human-readable, but are usually displayed in a program called a "browser" (like Firefox or Internet Explorer) that interprets the encoded document and reacts to user input. Each web document is identified by a unique Uniform Resource Locator; a piece of text composed of the domain name of the server and a server-specific path to the document.

To display a web document, first the browser consults the URL, getting the address of the document's server. It then passes the path to the server. The server provides the document, either by retrieving it from storage or by running a program to generate it dynamically. It sends the document to the browser, which builds a visual representation to display to the user (including retrieving any other documents that may be necessary). Often the browser also reacts to user actions such as mouse clicks on various elements of the document by changing how the document is displayed or by retrieving new documents from a server.

The Internet and the Web are the platforms on which web development takes place. Web developers create software and documents for the servers that provide the web pages to clients, and make sure that the clients can view them correctly. Some web developers maintain complete control over every aspect of the server, while others simply write the documents that are to be passed to the client. There are several current topics regarding the internet framework that are of special interest to web developers. One is IPv4 saturation: the current format for IP addresses only has room for a limited number of addresses and is likely to run out of new addresses this year. There is a new format called IPv6 that provides room for many more addresses, but it has not been universally adopted yet. Another issue is net neutrality: the idea that ISPs and backbone servers treat all servers and service types equally (for example, they don't prevent access to certain web pages).

Make sure to come back next month when I talk more in detail about the basis for web pages and online programming languages.


The possibilities are endless with a bathroom remodel. Discover your classic side with a clawfoot tub, experiment with fresh bathroom vanities, select from a wide variety of shower doors and coordinate it all with a matching bathroom faucet. Shop 24 hours a day, 7 days a week for all of your bathroom needs.

Customized Facebook Publishing: Difficult but Doable

Posted on June 16, 2010 by Trevor

In a previous article I discussed integrating your site with Facebook Connect. Unfortunately, shortly after I wrote that article Facebook rolled out their new Graph API and related technologies that made Facebook Connect largely obsolete. There are some valuable features of the new API, but in many cases it will require a rewrite. Today I'd like to discuss publishing to Facebook. As before, I'll try to keep it conceptual, but it will get technical. If you aren't interested in the technical details, the takeaway is that customized Facebook publishing is difficult but doable. 

Below is an example of the Facebook Like Button on one of our retail websites,

Facebook Like Example on


There are three general ways you can insert items into your visitor's feed (or "wall"). First there is the new Facebook Like button.  This is good for basic stream items, but gives very little control over formatting. Second, there is the FBML Share button.  It gives a moderate amount of control over formatting of the item in the feed, but not much over the formatting of the button itself. Finally, there is the API publish function, which gives good control of the formatting of the item but doesn't provide any default formatting, meaning you will have to build it by hand. Details on the first two methods are relatively easy to find, but the third is quite difficult.

The first thing to do to publish to a Facebook feed is to provide the visitor a way to initiate a post. It is possible to post directly to the feed without waiting for the visitor, but that usually creates a bad experience. Instead, we'd like a button similar to the Like or Share buttons Facebook provides, but allowing us more control. Facebook doesn't provide a customizable button, but we can create our own by using Facebook's CSS classes (note that you will have to initialize Facebook on your page before you can do this, a process I won't go into here). To make a link look like a Facebook button, add the classes "fb_button" and "fb_button_small" to the link, and wrap the link's text in a span with the class "fb_button_text". Then set the link to call a Javascript function when clicked (this function is where we'll publish the post).

Now, we need to publish the post. But first, we have to make sure the visitor is logged into Facebook and has given us permission to make posts. According to Facebook's documentation we should simply be able to make a posts to a user's feed using the Graph API; however, that function contains a bug so that if the post fails for any reason, we won't be notified, and nothing will happen. This would be a bad user experience. So instead we have to check the login and permissions first, and then post. To do that, we use the FB.getLoginStatus function, which returns details about the visitor's facebook login (if they are logged in, of course). If they aren't logged in, we can prompt them to log in (and get the right permissions to post) using the FB.login function.  As a side note, if you have implemented some sort of auto-login by subscribing to events, you may need to turn that off when you call the login function to prevent it navigating away from the page. If you don't understand that, it probably doesn't apply to you.

We're almost done, but there's one more issue. There is another bug in the "FB.getLoginStatus" function so that it doesn't always return the right permissions. To get the real permissions, we need to use FQL to query Facebook's permissions table and make sure we have the "publish_stream" permission (note that there are many undocumented permissions in this table: they are in the documentation. If not, we'll have to send them back to the login prompt to make sure we get it. If we do have permission to post, then we can finally make the post to our visitor's feed.

To post, call the FB.api function on the visitor's feed ("/me/feed"). You can pass in a JSON object containing the message, picture, link, name, and description you want posted, and it will show up as if the visitor had made the post. Finally, you should display some sort of notification to let the user know the post was successful.

To recap:

  1. Turn your link into a button using the "fb_button", "fb_button_small", & "fb_button_text" CSS classes.
  2. Find out if the visitor is logged into Facebook using the "FB.getLoginStatus" function. If not, prompt them with the "FB.login" function.
  3. Find out if the visitor has given permissions by querying the FQL "permissions" table. If not, prompt them with "FB.login".
  4. Post to "/me/feed" using the "FB.api" function. If successful, notify the visitor.

Whew! That was complicated, but hopefully it will give you a starting place when creating your own custom Facebook buttons. As always, feel free to respond if you have any questions or comments.


There are countless possibilities when remodeling your kitchen. Blend style and innovation with a pull out kitchen faucet, upgrade your design with a modern stainless steel Kitchen Sink, help conserve your food waste with an InSinkErator garbage disposer and keep your kitchen free of smoke and odors with Kitchen range hoods.

Building an eCommerce Presence on Facebook

Posted on April 28, 2010 by Trevor

If you haven't heard of Facebook, you're probably not actually on the internet. Facebook is the current champion of social sites, a giant community where people post their latest pictures, dialogue with each other, and play simple online games. It's also the hot new thing in eCommerce: sites hoping to capture the attention of that massive audience pouring onto the site.

There are three ways companies can build a presence with Facebook. First, they can put up a "Fan Page". A member of Facebook can create a page associated with a business, posting pictures, links, and comments just like any other user. Instead of becoming "friends", users can become "fans", but it's otherwise virtually identical. The second way to establish a presence on Facebook is to build an "app", a web service integrated into Facebook to provide more advanced services to users. Games are a particularly popular type of app, but there are also more traditional eCommerce platforms like that provide Facebook integration.

The third way to build a presence on Facebook is to integrate Facebook into your own site using Facebook Connect. With Facebook Connect, your eCommerce site can allow a user to login using Facebook, make posts to his or her wall and pages, and more. This allows your presence on Facebook to be spread out among your customers, rather than confined to one page or application. However, integrating Facebook Connect with your site takes a bit of skill, requiring custom code and Facebook's APIs. Recently I got a chance to do some work with Facebook Connect, and I'd like to share some of the issues and solutions I found.

Integral to Facebook Connect is the concept of permissions. Facebook asks the user's permission for any interactions with the site; that way the user probably won't be surprised or angered by something you do. One common action, for example, is to write a post to a user's wall. Each time you do this, Facebook prompts the user with a popup window with a description of what will be posted, giving them a chance to edit or refuse the post. Most of the time this is good. However, sometimes you may wish to post when the user isn't actually present to approve a post. For this, you need to request extended permissions (using "showPermissionDialog"). The two most relevant are "publish_stream", which allows you to post without explicit prompts, and "offline_access", which allows you to take actions for the user (assuming you have permission) even when the user is not logged in. There is some session information you'll need to store, but I won't go into details: you can read more at the Facebook Developer Wiki.

Another thing you might want to do is publish posts to a user's pages as well as his or her wall. This requires a bit more finesse. First, you need to know what pages a user has access to: unlike the user account, these are not given to you when the user logs in. To get them, you need to use the "query" function and FQL, a special API modeled on SQL. You can query the "page_admin" table to get the page IDs, and the "page" table to get any other information you need. Once you get the page ids, you can get permissions and post to them much like you did for the user's wall. To get permissions, you will need to explicitly list the page and user ID’s, even if you're requesting permissions for all of them; otherwise the dialog will present a dropdown to the user with only the user's wall initially selected (most users will simply click "OK", denying permission to all but their own wall). Once you've gotten permission to post to a page, simply substitute the page ID for the user ID in the "streamPublish" function. If you want to post to the page using the user's account instead of as a page self-post, keep the user ID but set "target_id" to the page ID.

As you can see, it gets pretty complicated even to perform simple activities like making posts for a user. In my own research I saw many questions and much confusion on such things as permissions and IDs. Hopefully I've given a few pointers here to get people on the right track. Although Facebook integration can be difficult, it's often worthwhile in terms of connecting with your customers and publicizing your brand.


The possibilities are endless with a bathroom remodel. Discover your classic side with a clawfoot tub, experiment with fresh bathroom vanities and coordinate it all with matching faucets. Shop 24 hours a day, 7 days a week for all of your bathroom needs.

SQL Server 2005 XML Quick Reference

Posted on April 1, 2010 by Trevor

If you've paid attention at all to the technologies behind web platforms recently, you'll know that XML has had a lot of both fanfare and debate surrounding it. XML is a data language, a way to wrap data in order to preserve its structure. It's quite simple and similar to HTML, which led to easy and wide adoption by web developers. However, although XML itself is simple, working with it is not. There are several competing languages intended to translate XML data into documents that can be either viewed by people or parsed by programs. Furthermore, while these secondary languages are standardized, their implementations may not be.

SQL Server is one example of a non-standard implementation. SQL Server 2005 implements XQuery, perhaps the most widely-used XML handling language in the database realm. However, it leaves out many features of XQuery and adds a few of its own. For a SQL Server admin or developer learning about XQuery, this can get very confusing as most resources are targeted at the standard rather than SQL Server's implementation, which means large parts of them don't work or apply. There are a few good resources like MSDN's Introduction, but one of the resources I couldn't find was a quick reference sheet.

Quick reference (or "cheat") sheets condense as much relevant information as possible about a subject onto a limited number of printable pages (usually two: the front and back of a single sheet). They're especially useful when you have the general ideas down but need to look up specific points (say, when you're trying something out that you just learned). There are plenty of good XML and XQuery quick reference sheets (those put out by Mulberry Technologies are especially good), but surprisingly I couldn't find one that specifically addressed the peculiarities of SQL Server's XML handling. So, because it would help me learn it myself, I decided to create one.

The following quick reference sheet is for SQL Server 2005's XML data type. It assumes a working knowledge of SQL Server and XML at least, so if you're not versed in the particulars you may want to pass it off to your developer or database administrator. However, I'm by no means an expert in this field, so if you notice any errors or omissions, please let me know and I'll do my best to update it. Of course, as always, neither I nor Gordian Project can make any guarantees as to support or liability regarding this quick reference sheet.




Little Giant has been hard at work engineering pumps that their most loyal customers have been waiting for. is your destination for the new Little Giant TSW Sump Pump System and their NXTGen Condensate Pumps.

Gmail Considered Harmful

Posted on March 23, 2010 by Trevor

As a developer, it's my job to figure out solutions to other people's problems. So most of the time I don't bother getting annoyed at problems I run across: at least it's a kind of job security! But sometimes there is no good solution to a problem other than to get annoyed and try to make enough of a fuss that somebody does something about it. Sometimes it takes a good old-fashioned rant.

Email. We all get it. From our grandmother's forwards to memos from work to the spam we quickly delete. Hundreds of billions of messages are sent every day to one out of every five people worldwide (out of the entire population; only one in four even has internet access). Obviously, as one of the longest-lasting and most important uses of the internet, a lot of work has gone into both email itself and the technologies surrounding it. Email has gone from simple text with cryptic headers read on a command line to requiring full-fledged multimedia support. One of the most exciting developments has been its transition to web standards.

Early Email Formats

Originally, email was simple text, it got the message across, but any formatting had to be done externally- perhaps sent as an attached word processing document. As technology developed, people wanted to be able to format the contents of their emails themselves, and clients developed various schemes for encoding content other than ASCII text in messages. However, this was quickly remedied as MIME types were established that allowed emails to be sent in many different formats, the most popular of which was HTML. Since then, as HTML and its related standards have progressed, so has email. The ability to format an email as you would a web page has proved vital especially to business communications. One of the primary functions of email clients is to support this formatting and display the email as the sender intended it.

Google's Gmail Behind the Times

However, there is a hitch, and this time it comes from a surprising angle: one of the largest, most standards-compliant companies out there, Google! Google's web-based email client, Gmail, is justifiably popular especially among the tech crowd, but it breaks html email standards in a very annoying manner. I've talked before about web standards and difficulties in keeping them straight among the profusion of browsers. Throw email clients into the mix and you're practically lost. However, Gmail is the big offender, because of the way it handles CSS.

CSS comes in several flavors. You can use "inline" CSS, putting your formatting directly on the elements you wish to format. You can place it in between "<style>" tags, keeping it in the same document but consolidating it into one section. You can also put it in one or more separate documents and link to it. Web developers often prefer the latter, because it allows them to keep the CSS formatting separate from the contents of the site, and makes it easier to edit. However, Gmail doesn't support separate CSS documents. It doesn't even support the "<style>" tag. It ONLY supports inline CSS (and actually, it doesn't support every aspect of that). Why is that a problem? Let me demonstrate. Here is an ordinary piece of code:

h1 { text-align: center; font-size: 3em; font-weight: bold; }
#intro { margin: 1em 0; text-indent 2em; }
.brands { display: block; margin-left: 5em; }
.brands li { list-style-type: none; font-weight: bold; }

<h1>PlumberSurplus Faucets</h1>

<p id="intro">PlumberSurplus provides high-quality faucets at great prices!</p>

<ul class="brands">

As you can see, the CSS is packed inside the "<style>" tags, making both it and the html below easy to read. However, in order to get the same effect in emails viewed with Gmail, that same code would have to look like this:

<h1 style="text-align: center; font-size: 3em; font-weight: bold;">PlumberSurplus Faucets</h1>

<p id="intro" style="margin: 1em 0; text-indent 2em;">PlumberSurplus provides high-quality faucets at great prices!</p>

<ul class="brands" style="display: block; margin-left: 5em;">
    <li style="list-style-type: none; font-weight: bold;">Kohler</li>
    <li style="list-style-type: none; font-weight: bold;">Moen</li>
    <li style="list-style-type: none; font-weight: bold;">Delta</li>

Not only does that make it harder to read and to separate the format from the content, but it also makes it longer and harder to write: look at how the style on the "<li>" tags must be repeated for each of them. That means if I needed to change the way they were formatted, instead of just changing it in one place, I'd have to look throughout the entire document. So inline CSS makes emails larger, harder to write, and more error-prone.

Well, you say, maybe Gmail has good reasons for restricting CSS. After all, we don't want untrusted code having control over our computers. But the thing is, there's no such danger with CSS. It's built strictly as a formatting language: there are few if any possibilities of compromising systems using CSS, and none that depend on separating it out rather than using inline. That choice is primarily a developer convenience, unnoticed by the user. Furthermore, out of the top email clients, Gmail is the ONLY client not to allow some kind of separation of CSS. Over 75% of email clients have this capability with no problems; why can't Gmail? Even if Gmail is concerned with email CSS interfering with the format of their client (since, being a web interface, it too uses CSS), that is easily prevented with sandboxing and checks at the individual tag level: other webmail clients have managed for years without having to put a blanket prohibition on separated CSS.

Gmail, your refusal to bring your standards up to date is a major hassle for developers! You are the only major email client who is so abysmally behind, in marked contrast to other aspects of your company and Gmail itself. I know you can figure this out: please, get with the times. Make developers happy that they don't have to jump through hoops, and make your users happy that their emails aren't broken.

The possibilities are endless with a bathroom remodel. Discover your classic side with a clawfoot tub, experiment with fresh bathroom vanities and coordinate it all with matching faucets. Shop 24 hours a day, 7 days a week for all of your bathroom needs.

Free Email Sending Utility

Posted on March 12, 2010 by Trevor

If you are on the internet, you almost certainly use email. Email was one of the first applications of the internet, and remains (along with the web) one of the most widespread. Online Businesses use email too, for internal communication, customer service, marketing, and general use. So it makes sense that there would be a good set of technical tools to support working with email.

Unfortunately, if there is, it's hard to find. While testing some code intended to automatically send emails on certain events, I needed a simple utility to configure and send test emails. After a few minutes of Googling, I realized it would be a chore to find what I needed. The results I was getting didn't have the interface, the features, or the transparency I needed. Given the simplicity of the application, I realized it would be faster to just to write my own. Twenty minutes later, I had my program.

It's a simple VB.Net application that accepts details about the SMTP server and allows you to write and send an email to that server. It's nothing fancy, but it gets the job done, and I know exactly what its doing. And because I found it useful, I'm sharing it with you. Obviously it's not a full-featured email application, but if you want to do some basic testing, it's a good place to start. To that end, I've also included the source code so you can see what's happening under the hood. Of course, all of this is provided "as is", and neither I nor Gordian Project will be able to offer any support for it. This is primarily for people who already know what they're doing. But if that's you, I hope I've saved you a few minutes, at least!


SMTP (129.24 kb)


Little Giant has been hard at work engineering pumps that their most loyal customers have been waiting for. is your destination for the new Little Giant TSW Sump Pump System and their NXTGen Condensate Pumps.