Ecommerce and Entrepreneurship Blog | About | Contact | Store

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: 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.

PayPal Proves That They Can't Be Relied On

Posted on October 29, 2010 by josh

Back on June 1, 2010, I wrote another post related to PayPal downtimes and, more specifically, why having a backup payment processor is valuable. PayPal proved me right, again, today.

PayPal was basically completely down.
On their live site status page, they said:
Impacted Service/Product:
Live Site
- PayPal APIs
- Website
- Website Payments Standard
- Website Payments Pro Payflow Edition
- Express Checkout

Seriously yuck! But, for us, it was no big deal. In fact, if we hadn’t decided to build an error email when PayPal was returning transaction errors, I never would have noticed they were down. Our backup simply gracefully took the transactions on, with only a minor delay to customers at checkout. For those who are curious, we were affected from about 8:15am to 9:30am and from about 11:30am to 12:00pm.


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.

Google Wave is Dead

Posted on August 9, 2010 by josh

Google recently announced that they will not continue to develop Google Wave as a standalone product. Back in November, 2009, I wrote my first impressions of Google Wave. I have to admit, at the time, I was incredibly excited to get a developer invite. I love to geek out and try new things (naturally I love to try new Google products). I fully expected to use it for collaborative efforts and projects; but honestly, I rarely logged in. The reason? Low adoption. This is the same reason that Google sited for discontinuing development. I wanted to like Google Wave, I even wanted to use Google Wave, but none of my friends or colleagues did. Even when I recommended it as a collaborative platform, others plainly said “No”, instead opting for something that was already comfortable for them.

Google Wave Logo

One of my developer friends, Matt, even said to me in one of my first Waves, “Google Wave will be one of Google's biggest flops yet. This is hopelessly worthless, inefficient, and out of touch. This is NOT what email would look like if we designed it today.” Though I disagree with Matt that Wave is “hopelessly worthless”, I do have to admit that it flopped. However, I have hope for future Google products though, and I can’t wait to see some of the real-time elements introduced to Google Apps.



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...


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.