Ecommerce and Entrepreneurship Blog | About | Contact | Store

Five Considerations When Hiring IT Staff

Posted on December 6, 2011 by Josh Mc

Hiring an employee to handle IT (Information Technology) responsibilities can feel overwhelming, especially if a business is new and does not have much experience in having an IT department. Hiring a good IT person is a huge asset to the company, while hiring a bad one can actually hurt workplace moral. By keeping in mind the below considerations, you should be on your way to selecting a good IT person for your workplace.

1. Knowledge
In order to find the right IT guy, it is important to consider whether or not they truly understand the business. Do they really know what their responsibilities consist of and what they may be expected to do during certain times of the year? They need to be aware of what they are in for and what skills they will be expected to use at any given time. You will also want to test their knowledge of these skills so that you know you are hiring someone that can walk the talk.

2. Personality
The IT person that will work well with the business needs to have a positive and engaging personality. Other employees, for example, should not be nervous or afraid about approaching them; a negative work environment can only lead to unhappiness and widespread consequences. If the IT staff is full of friendly personalities, people will be more confident about their performance and role in the business. The IT person should be willing to work with others and contribute to the health of the business.

3. Willingness
Any good employee, no matter what their tasks may be or who they are working for, needs to be willing to try new things. If they are presented with a job they have never handled or been exposed to before, they cannot behave as though they are positive they are going to fail. The potential employee needs to be willing to do what they can to handle the new responsibility; not just for their own sake, but for the sake of the IT department and the success and growth of the business as a whole.

4. Flexibility
On top of a willingness to try, it is also important for an employer to consider a potential IT guy that is flexible. They should be able to handle whatever comes their way, be it a computer that simply will not turn on or a virus that has infected the data system in the office. Also, they should be able to change their hours to deal with fixing a computer when an employee has gone for the day or do some late night work if the website has gone down. Often, they will have to be flexible when it comes to helping customers deal with tech products issues, should such a thing apply. An employer needs an IT employee that can adjust what they are doing to handle different problems, especially when it comes to technology.

5. Professionalism
One of the most important considerations to remember is professionalism. No matter how social the IT person may be, or how willing they are to handle new responsibilities on a daily basis, it means little if they are not professional. If they do not appear to take their job seriously, or if they appear to be immature, they should not be hired for any positions.

Hiring an IT guy, for any business, can be seen as a stressful venture. However, by looking at the considerations above, an employer can hope to have a higher success rate. If you have other considerations that you use, make sure to leave them in the comments.

How to Fix a Hacked Site and Make it Safe for the Future

Posted on November 10, 2011 by Josh Mc

Over the last couple of months I have been forced to, twice now, deal with compromised websites. This entails finding the problem, getting them cleaned up, the warnings removed and then back in the Google index. Luckily it was not one of our main sites but cleaning up even a small blog can be a time consuming process. In that I have collected these tips to help when anyone else sees that little message under your site stating “This site may harm your computer." I know for some of you this may be to much on the surface, but for others they may never know to do some of these things.

Google this site may harm your computer

Don’t Panic
I know it is horrible to see your livelihood be infected by malware, but the worst thing you can do is panic and start to desperately run around wondering why something like this would happen to your site. This will not help your site to get cleaned up so the best thing you can do is keep a level head and follow the steps to see how it is happening and how you can quickly address it.

Get the Site Scanned
When working with a hacked site I always head over to a good site scanner, such as the Sucuri SiteCheck and have them scan my site. Most often they will tell you what the issue might be and will give you information on how to fix it. If you are not savvy with htaccess files and other parts of your site you may want to opt for their paid service which will clean your site and monitor it for you to make sure no other infections take place. If you are savvy then run the test, get the details and start implementing their ideas.

Check the htaccess
One of the sites that I was working with had an issue where if you typed in the domain name the site worked fine; however, if you tried to enter the site from a search engine you were directed away from the site to a Canadian drug store. One of the reasons why this is a preferred method for hackers is that many site owners will not search their site in a search engine, they will just type it into a browser. So if you are hit with something like this then it can take people weeks or months to realize it is happening. Here is an example of what the htaccess file looked like for the hacked domain as it may help you to notice what to look for.

hacked htaccess file

Check Google or Bing Webmaster Tools
If your site is doing more than simply taking over the htaccess, then it is a good idea to check webmaster tools and see if Google has any notifications as to what is going on with your website. Many times they will tell you there is malware on it or try to notify you that something weird is happening. They also have a great series of steps you can do to clean up your site here as well.

Fetch as Google Bot
On the second site that was hacked, they were not having the htaccess issues but had a little piece of code that was in the footer of the site which was showing Google bot a whole bunch of links that a normal user would not see. In order to find this I did a fetch as Google bot in webmaster tools and was able to notice that Google was seeing something different then I was. I found the piece of code and removed it from the site and then it stopped giving Google those extra links.

Of course this is just the tip of the iceberg and not all hacks will fall into these types of fixes, but these are a lot of the common things to look for. Now you may ask what to do after you have cleaned it, to which I would recommend these things.

Change your Passwords
I know passwords are hard to remember as is, but you should change them right away, change the FTP, Hosting, Site, Database, etc. This is the most important thing to do right away. If you do not do this then whatever work you do can be just as easily erased as soon as you fix it, by whoever has access too it already.

Set Up Google Webmaster Tools
Setting up Google Webmasters Tools for your site is easy and free. It will give you tons of data for your site such as what users are searching for to get there and who is linking to you. It will also let you know whether your site has been compromised or not. If you do only one thing after reading this blog make sure it’s setting up webmaster tools.

Keep Your Installs Up to Date

By far one of the most often exploited parts of a site is the database or content management system. Whether that is Wordpress, Drupal or something else, making sure it is up to date is the number one way you can combat attacks. The same is true for the plug ins that you use. Keeping all of them up to date can help you stop would be hackers from exploiting your site.

Do Not Share Hosting Access
Having a shared hosting account for multiple sites is fine, but making sure that the other people who are sharing your hosting are keeping their installs up to date is a must. Even if your site is up to date, another site on the hosting account could let in the hackers. Make sure you only share hosting with someone you know and trust will keep up their site.

Keep Backups
This is by far one of the most important things you can do. Even if you don’t back it up every day make sure you are making a backup at least once a month. This way if all else fails at least you can fall back on a time when your site was not infected.

Request Reconsideration
After your site has been cleaned and you have verified that with the scanner that I mentioned above, make sure you file a reconsideration request with Google. This is one of the most forgotten tasks and probably the most important. Google will not bring your site back into the index and remove the warning without having your site cleaned and reconsideration request filed. You can do this through your Google Webmaster tools account and it is very straight forward and easy to use. In my two times doing it I have seen a response and the warning removed within one to two weeks, so make sure you fill it out as soon as your site is fixed.

So there it is, my tips on both fixing a hacked site and then keeping it safe in the long term. Make sure you leave a comment if you have another tip as well.

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.

Communicating Service Outages to Your Team

Posted on July 22, 2010 by josh

If you're in charge of keeping critical systems going for your organization, it will be necessary, from time to time, to explain to your management team (or your customers, if you operate a service) why a service outage occurred. Whether it's your network, your phone system, your payment/checkout system, your website, or your {fill in one of the dozens of services you manage}, it's critical that you communicate what happened, who caused it, when it happened, where it occurred in your infrastructure, and how it affected your operation.

Below, I've created a simple sample of one of these communications (for demonstration purposes only):

Hello Team,

This communication is intended to provide you with a formal explanation for the service interruptions that we experienced on Thursday, July 21, 2010, which resulted in a downtime on our website.

We experienced a downtime on our website from 9:48pm to 9:59pm. No pages could be reached during this period.

Escalation Taken
Alert messages of the downtime were sent to the alert team at 9:48pm that there was a potential downtime. The tech team mobilized and immediately began testing systems to determine a cause.

Root Cause
Upon investigation, it was found that a family of pygmy mouse lemurs had taken refuge in our data center. One of the adorable animals had pressed the power button on our web server, as it was shiny. This turned off our web server.

Corrective Actions
We turned the web server back on by pressing the power button and the web site resumed normal activity within a minute or so. Sadly, we also had to evict the cute but culpable creatures.

Next Steps
In the coming week, we will be installing a mesh screen on the server's rack to deter any new intruders. We've also begun plans to scale our infrastructure to support load balancing and redundancy across multiple web servers in multiple locations to help to mitigate future issues like this.

Should you have any questions, please do not hesitate to email or call us. Sorry for any inconvenience!

Best regards,

Your IT Guy

Issues are going to happen, and they're not always in your control. The key here is to communicate quickly and accurately. As soon as you've got the situation under control, and you have the facts, communicate it out. You want to address concerns quickly, because your team may be wondering why sales dropped between 9:48pm and 9:59pm. You want to be as accurate as possible because you may not realize that your marketing team had scheduled a report to be uploaded to FTP (which lies on another server that may have also been affected) at 9:45pm. Don't worry. Chances are, your team (or your customer) doesn't care as much about being down as they do about how you respond and how well similar future issues are addressed. Try not to use uber-technical language, as you may be communicating with non-technical personnel. Be ready to answer lots of questions and make yourself available to them. You may have satisfactorily resolved the issue, but others may still be left without closure on an issue. Do a great job of communicating what was, what is, and what will be. Your team will appreciate it immensely.


Tips for Managing eCommerce Development

Posted on June 30, 2010 by josh

I have the fortunate duty of building some amazing solutions for our sites and systems. Being honest and up front in your position, with yourself and others, can play a key role in your success as an IT or Development manager. Here is a short list, not comprehensive, on some things you must do as an IT or Development manager:

Have thick skin

You can't make everyone happy... and you won't. The needs of the organization frequently do not meet the perceived needs of all individuals. But your team has to be able to critique you. Listen, and be honest with yourself. Also, you aren't perfect. You will screw something up. How you respond is likely as important to evaluation of your performance as the initial task. So, don't take criticism personally. Take it in, measure it against the organizational needs, discuss it with your management team, and build on it.

Let your management team know, in advance, if you're...

    • going to be making changes that could affect their teams ability to do their job: If you’re up front, chances are they'll be willing to help you meet a deadline or do some testing if it means that their team will get new tools or increased productivity.


    • going to make changes that may affect how your site gets indexed by search engines: If you make major infrastructural changes to your backend architecture, make it clear that it could have short term drawbacks and make the long terms gains that you're shooting for equally clear. Your team will appreciate your candor.


    • going to make changes that may affect conversion: If you're in eCommerce and you're working on, say, your shopping cart, chances are you're going to see some numbers change on whatever reports you and your team pay attention to. Aside from taking a page from Amazon and making smaller, more easily measured, incremental changes, if you are making changes that you think may have an impact, even slight, mention it to the team.


    • going to be releasing something that is 80% tested: In development, there are lots of good reasons for doing this. On some projects 80% tested or 80% complete, yields 98% of the desired functionality. Frequently, the other 20% is easier to address in the wild with real users. Be honest with your team about this and help them to understand why the additional cost of testing or completing the final 20% may not be as cost effective as releasing. Of course, I am NOT making a recommendation to do this on every project. This technique should only be applied when justified and appropriate and when it meets the needs of your organization (and probably when it doesn't display to the public in some embarrassing way).


  • going to do something that affects their work life... {this list goes on forever}

Understand that everything is a priority, even if it isn't

You don't get to make every decision, but you must be sensitive to other's needs. Do your best to make clear what is prioritized and why. Also, know that the members of your management team are, at least in part, judging your work based on what you've done for them. Toss in a quick feature, or fix an easy bug every now and again. Even if it's not next on your priority list, the human element here can be powerful. It can help you to build a better relationship with others, increase morale for an individual or a team, it can even help to make them look better if it helps them to be more productive. Besides, it may buy you some grace the next time you need it (and you will). These things can't always be measured in dollars and cents, but they can be felt in quality of life.

Be vulnerable, you can't solve every problem and you can't do everything all the time

I know you're amazing. You have tremendous problem-solving skills and you have pulled some rabbits out of some hats in your career. But people don't want to hear about how you're going to get everything done perfectly. It's a lie. You can't. Be honest with yourself and others about how well you'll do with the tasks that lie ahead and the resources you've been given. They need this from you and you need this from them.

Don't speak over people

There are two things to pay attention to here. The first thing is that you need to listen. Before many people finish their sentences you've got it more than half worked out in your head. But, you have two ears and one mouth for a reason. Even if you disagree with someone because they are requesting something that you believe is technically infeasible, stop coming up with ways to rebut and force yourself to listen. Don't immediately fire off a "NO". Try to understand the need and let them know that you want to understand the need before you help them by working together to design a solution. The second thing you need is to learn to speak to your audience. It's easy for you to say to another techie that a system update caused a legacy service to crash, causing dependent services to also fail. But not everyone is going to understand what you're talking about. It sounds really simple to you. But you have to help them understand why and how it happened. You don't have to use elementary words, but you do have to use words that your audience will understand. Know your audience.

I'd love to hear some additional thoughts from other IT and Development managers out there...


Why Building a Backup Payment System is Worth It

Posted on June 1, 2010 by josh

PayPal Payment Processor Payment Processor

You may or may not know that on Thursday, May 27, 2010, PayPal suffered from a significant issue. This was nothing like the $2,000 per second outage that PayPal faced in August of 2009. A logic error with PayPal's risk model led to a higher-than-normal chance of transaction decline. According to a source at PayPal, the issue affected PayPal's direct payments system (not PayPal Express Checkout) and their virtual terminal. I was told that this was an "all hands on deck" incident for PayPal.

The issue began just before 8:30AM PST and lasted until about 4PM PST. I was notified by our customer service team that there was an issue with transactions just before 9AM. They came to me to let me know that a number of transactions were declined for, seemingly, no good reason. Later in the day, I received an update that the issue affected approximately 15% of transactions for PayPal. Although, we were likely to see a higher fail rate in our customer service center, since customer's who had experienced an issue were likely to contact us, try again, and fail, again. We saw a fail rate of closer to 50 - 60% during the issue period.

In development, we had already planned to begin development shortly on a backup payment processor process. In August of 2009, we had been directly, and severely, impacted by an downtime. We knew that we would face payment processor issues, again, at some point. Apparently, it's inevitable. Given the number of customers who contacted us about the current issue, and the untold number of customers who did not contact us, and the thousands of dollars in lost revenues, and the poor customer experience, we knew that we would need to bump this project in priority to A1 status. So, at this point we had already had experience transacting securely with two payment processors, and had already begun work in mapping out the new process. The dev began.

By about 4PM we had wrapped up testing the new process and were ready to push it live when I received a contact from PayPal that their risk model issue had been resolved and that transactions had returned to normal. Classic. Well, we didn't beat the PayPal clock, but we did learn some things.

1) Payment processors fail. As much as I'd like to believe that they're committed to five-nines up-time, I know that will never happen.

2) Customers hate getting errors at checkout, especially after they've already entered their credit card information. I know it makes me uneasy when it happens to me; you don't have to have more than one phone call from a panicked customer to know that you've really wrecked the whole experience.

3) It's not a very difficult problem to solve. Chances are you have spent a great deal of time, energy, and resources negotiating rates and developing a system and reading through an API manual and following PCI requirements.

Building a backup system is still likely worth the time and effort, if not for the untold number of lost transactions, for the customer experience. Now I am left wondering, though, 'What happens when both processors fail at the same time?! ... I am kidding, of course; we just direct them to use Google Checkout.



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.

Why Bloggers Can’t Share Everything They Have Learned

Posted on March 25, 2010 by josh

This blog post is one that won't explain, instruct, or enhance any measure of your working life; but there's a good reason for it. Managing two critical departments for an eCommerce company, IT and Development, can be extremely challenging and fun. Often, we come up with incredible solutions for complex problems that I know others are going to traverse. As much as I want to share all of our experiences on how we've navigated some tough roads or saved/made the company thousands, or even tens of thousands, of dollars, I can't. It's not that I want to hoard all of our awesome developments or ground-breaking discoveries or money-saving ideas. It's that I have two very ominous risks ahead of me in sharing: Secret Sauce and Security.  And it's something that other bloggers have to take into consideration when they post as well.

Secret Sauce

How many of your blog readers are your competitors? I know for a fact that the employees of some of our biggest competitors follow our company's, and my personal, Twitter. How much can I say without saying too much and giving away our secret sauce? Well, in some departments, giving a general idea of how to execute high level processes might be ok. But in the world of Development, if we talk too much about how we figured out how to leverage more with less, at very little cost, we potentially give our competitors whatever competitive advantage we've garnered from such an effort. It stinks, because I empathize with other development managers that are out there facing an issue that I know is or will be familiar to them. I want to help them out.


In both IT and Development, the more I speak publicly about the systems we've implemented, the more we put ourselves at risk. If potential hackers, thieves, bandits, jerks, pirates, etc. don't know what we're running, the attack surface is much bigger for them and it makes their nefarious activities much more difficult. If, however, we reduce the security footprint by revealing implemented systems, any Googler can query common vulnerabilities or techniques to leverage our property. Though I realize that it's our job to ensure that such vulnerabilities are covered, it still doesn't make sense to improve their chances for things like zero day exploits.

You likely read this blog because you want to hear about the secret sauce and the awesome systems and I appreciate your ear. The members of my departments and I will do our best to share as much as we can, without letting it create any liabilities.