Last week, I was doing some research about my upcoming trip to Tanzania. I was browsing the web, looking for good deals on trip packages, reading feedback and comments from people who went on a similar trip, checking prerequisites (shots, visas)–basically general research anyone would do when going on a trip to a place where they’ve never been, or looking to buy a new product and trying to choose from the selections. Later that week I was checking my Gmail account, and, what do you know? The news ticker above the email showed me: NYT Travel – Next Stop: Off Tanzania, Serene Mafia Island. Obviously the article was targeted specifically to me, based upon my research over the few previous days, and it did provide me with some new information. But, is it a valuable service that companies provide, or an invasion of privacy–an abuse of the collected data that was never meant to be public?

Over the past few years, the issue of online privacy has become more acutel. With the emergence of social web and data services, such as geolocation of web users, more and more information about the user is transparently available for web pages and applications. And, as always, the companies that can directly utilize the data available (and frankly those who benefit from it the most) are marketing and advertising companies. Personalized ads have become a common occurrence, and that scares some users. People believe that anonymity is a core benefit of Internet, and behavioral advertisement violates the privacy that users are expecting.

Personally, I don’t fully understand people who cling to the idea of anonymity online for a couple of reasons. First, it sounds a little naive to argue against, for example, having your location available to the ad services when anyone can find out a ridiculous amount of “public” information about any given person. Nowdays anyone, with a few clicks of the mouse, can find out where you live and work, what you eat, who is in your immediate and extended family, how much you paid for your house, and much, much more. In perspective, disclosing your current location doesn’t sound like a big deal by comparison. Secondly, people don’t correlate the same actions on- and off-line because, even still, they view the Internet as completely anonymous channel, often with no repercussions for their actions. However, online marketing is not much different from it’s ancestral, offline counterpart. You are being targeted for advertisement daily, based upon your “personal” information. When you are walking down the street, the shoe shiner will not ask you if you need his services if you’re wearing tennis shoes or flip flops. You are being targeted, based upon what you wear. New Chinese restaurant staff may not leave their menu at your door handle if you live outside of a 10 mile radius from the restaurant. You are being targeted, based upon where you live. If you are a male and walking through the mall, the staff will not ask you to try a new perfume. You are being targeted, based upon your gender. There are many more examples of daily targeting, based upon profile or behavior, yet those instances are tolerated much better than similar advertisements presented online.

Perhaps the issue lies in the fact that online data collection goes far beyond what can be derived from the information available outside of it. The Internet allows users to seamlessly switch between different activities in single browser. Average users spend more and more time on the Internet watching movies, doing research, shopping, reading news and much more. Below is a breakdown for an average U.S. user, condensed into one hour.

All the activities listed provide valuable data points that can be correlated into a “user profile,” and if analyzed properly, allowing very accurate assumptions about the products and services that will interest that particular user. Amazon can be considered a pioneer in creating their related products section, which enjoys a very high conversion rate, based upon users’ past purchasing and browsing history. Facebook’s targeted advertisements analyze user preferences, likes and comments to promote products and services to match that user’s interests. And although these services provide valuable offerings, some people argue that online advertising is unnecessary, and ads diminish the value of the content or service that companies provide, because they distract from, or are irrelevant to, the main content.

Internet advertising has to exist in order for companies to provide free quality content. This is an axiom. In order for the advertisement to be effective and attract customers, it must be relevant. In order for marketing to be relevant, appropriate messaging must be communicated to the target audience. And, in order to assemble an appropriate message, a company must know the audience being targeted.

There are two types of targeted advertisements that have been adopted on the web: contextual and behavioral. Contextual ads market products based upon the content that is being presented to the user. For example, if a visitor is looking at user-submitted images on National Geographic My Shot, presenting an ad for Nikon camera would probably yield a higher clickthrough rate than a generic “You have been selected to win an iPod” ad, that so many people have come to hate, as this approach assumes that people viewing the content on this particular page would be uniformly interested in a random product. Contextual ads target a particular group of people with a common interest, and bank on the similarities within the target group. Behavioral ads are targeted by using the historical data collected while the user views multiple pieces of content. Companies that employ behavioral advertisements collect data from various sources and preferences of a user–on average several hundred times a month–and use that information to tailor the offering to an individual user viewing the content. This is where users concern about privacy violation comes in.

There is no question that available information can be abused. On the other hand, users may not want some of their Internet activity associated with their profile. They may look for advice for their real-life problems or diseases without wanting to expose themselves, or having that information being associated with their profile (which may contain unique information identifying them). At the end of the day, the issue comes down to the mission, values and reputation of the company running the campaigns. A company collecting data and using it to provide a better user experience for its users, is much different from a company purchasing profile data from other places and using it to exploit or trick users. “Find [something] in [your city], [state]” is the most common example of deceiving people into registering for questionable services. Unfortunately, there is no silver bullet for the problem. The Internet went through the same process when companies began to require an email address in order to register for, well, pretty much anything online. Volumes of spam increased exponentially, and it took years for ESPs to devise sound, anti-spam solutions. However, it required users also to make a responsible decision about which services were reputable enough, and to provide their personal information. Behavior targeting, if proven successful, will have to go through a similar trial-and-error process before it matures. We can only hope that the cycle will be quicker, as companies and users alike are more educated regarding online operations than they were 10 years ago.

So the marketing expansion can’t (and based upon marketing survey responses, shouldn’t) be stopped. However, with all the data available for consumption, there are steps that must be taken to maintain a necessary privacy level for concerned consumers, and a lot of major companies are taking steps toward implementing those policies. AOL, for example, lets users opt out of some targeted advertisements; Google lets users edit the search histories that are linked to their profiles; Microsoft says it does not link any of its visitors’ behavior to their user names, even if those people are registered; and Mozilla released a proposed “Do Not Track” header to provide users with a deeper understanding of, and control over, the flow of personal information online.

The bottom line is: The Internet is evolving, expanding and becoming it’s own ecosystem, and behavioral marketing on the Internet is here to stay. With the rapid emergence of the mobile web, we are quickly moving toward “futuristic” advertisement, a la the movie, “Minority Report”, where sale offers will be customized for individual users walking into the store, based upon their preferences and taste data collected online. If you are happy to receive relevant advertising that may even give you new, useful information, be happy. If you fall on the other side of the privacy coin and you don’t want your surfing habits tracked, you can employ available tools and methods to restrict the the outgoing information.

So let’s examine a real problem. A large e-commerce company called and said that they are seeing less money coming in from web transactions. They have a pretty complex system with a lot of different revenue generation points, so this observation shed very little light on the root cause of the problem. Luckily, both systems and business processes were being monitored with Circonus, so the data was available to review.

As any engineer knows – step one of troubleshooting the problem is to confirm the problem, so looking at the revenue trends seemed like a good starting point.

The graph clearly shows that, starting around April 30th, the trend looked abnormal in comparison to the previous few weeks. So it seemed like there was an actual problem, and potentially, the issue could lie in payment processor itself or somewhere in the system, preventing certain users from making a purchase. So let’s overlay the traffic trends, collected from Google Analytics, against revenue graph and see if there are any common trends.

Even though the traffic showed a clear drop at the same time as revenue, the ratio remained the same, allowing us to exclude payment processor and other application logic from the equation (for now).

Note: This is the first potential breaking point in the process. It is very tempting to look at the ratios, attribute revenue decrease to traffic decrease, and stop the investigation. 99% of the time, unfortunately, nothing “just” happens, so on we go.

Now for the next step – what would be a logical cause for a drop in overall traffic to the site? Response time is probably the first thought that should come to mind. So let’s look at what the HTTP checks collected.

Load times didn’t seem to be deviating from the norm, but the HTTP response metric doesn’t provide full visibility into the load times for a dynamic application, so let’s check the health of the database and CPU usage on the server(s), to validate that the underlying platform is not the bottleneck. There are numerous metrics to monitor database and system health that should be, and in this case, are collected, but when researching the root cause of the elusive problem, diving deep into a specific component can waste time early in the process.

Both of the metrics appear well within norm, so at first glance, it seems like the problem is not a systems issue.

Note: This is the second point of the investigation where the process can break down. A lot of technical folks will either report that there is no confirmation to the problem reported; the reported problem is just an anomaly because the system monitors don’t exhibit any issues. This is exactly why understanding of the business by the technology team is vital.

With that said, what would be the next logical process to validate? It is not uncommon for an e-commerce site to see a drop in purchases if they either stop promoting or if their marketing campaign is ineffective: traffic to the site slows down, subsequently decreasing the number of transactions. This company, in particular, sends out tens of millions of emails a day which bring in new users, and subsequently, new conversions. So let’s take a look at the email deliverability and bounce rates collected from the company’s MTAs.

Bingo! The bounce rates sky rocketed at the same time as the drop in traffic and revenue stream occurred. Upon closer investigation, it appeared that one of the major ESPs accidentally blocked the delivery domain, and the emails did not go through to the recipients. The issue was resolved (after some discussions with the ESP) and the trends returned back to the expected level.

Keep in mind, if email deliverability was not the issue – there are multiple other metrics that were on a list to be verified, both system (operational and development alike) and business. The amazing part of all of this is that I was able to view the whole system at a glance in just one graph. Granted, stacking everything on one graph is probably not the most optimal every day approach, but it is very useful in a certain cases when the direct overlay correlation is needed. For everything else – a real-time dashboard that displays all the vital points of the business at any given moment is a must-have for anyone responsible for business and/or system health.

Everyone responsible for the success of a business, regardless of the role, needs an ability to see the status of the whole business at a glance at any given point. System engineers don’t need to know all the ins and out of marketing, but they should be aware of the overall organizational goals, and should be able to spot irregularities in the business trends. Similarly, CEOs don’t need to know how systems work in the background, but should be able to correlate high email bounce rates (if it’s critical to the business) to a decrease in purchases.

The point of all of this is that everything should be monitored, and to suggest some tools and methods that can enable users in all roles–within any organization–to ensure the success of the business. Get ‘em, learn ‘em, use ‘em! You will thank me later.

Designing Great Websites That Sell (Part 1)

Designing Great Websites That Sell (Part 2)

Unfortunately, over the past decade, the term “CMS” has become a buzz word, a commodity if you will. Everything web-related (short of social media, and that’s changing nowdays as well) has been rolled into those three characters. Originally (loosely) defined as “web application to create, edit, store and publish online content”, CMS has transformed into a much larger beast, covering e-commerce inventory management, SEO tool, workflow creator, and much much more. There are a lot (and I mean A LOT) of “How to choose CMS” articles out there, all composed from different perspectives, starting from a designer usability stand and ending with a CFO financial point of view. This article is not one of them. The goal here is to separate the term “CMS” into two very distinct components, and analyze the impact and/or the importance of each in a context of selecting a system to support your business.

There are two primary functions that people should be looking at when evaluating CMS, which I will refer to as “the engine” and “the workflow”. The best analogy to define the separation could be drawn from looking into the world of video games. In 1998 Epic Games developed a game engine that powered their newly released game Unreal. Since then – dozens of very different games, from a number of developers and publishers, were built on top of that engine; games that have nothing in common on a surface (really, who would compare Adventure Pinball and Tom Clancy’s Rainbow Six game?) All those games have completely different types of gameplay, different target audiences, but they all share a common engine under the hood to accomplish those very different goals. The same can (and should) be applied to the Content Management Systems.

The engine

Even with all the new bells and whistle in the current systems, the main purpose of the CMS is still to publish and serve the content. With that said – publishing content is easy. Publishing and serving the right type of content consistently is a bit more challenging, but this problem has been solved (with varying success) in all of the CMS products out there. Ultimately, the selection comes down to two simple questions: “will the product run in my infrustructure?” and “will the product perform well based on my current traffic, and scale with my business?”

Having said that – in no way, shape, or form, I want to downplay the importance of selecting the underlining CMS engine. Too often I see VPs of Technology and CIOs put a cart before the horse and start comparing products instead of evaluation the compatibility of them with business needs and the architecture in place. A couple of things to consider when selecting the engine, in no particular order:

Scalability – will the engine be able handle current and future traffic patterns?
Integration methods – what protocols does the engine offer for integration for both user-facing applications, as well as “the workflow”?
Technology stack – will the technology that engine is built on fit within the current architecture, and will it match the skill set of the staff?
Extensibility – how would the engine integrate with third-party business applications and support business-specific data models?
Content delivery – will the engine match the content delivery strategy of the business? (multichannel publishing, content availability, etc)

Although there is still a level of research required to identify the engine that would serve business needs the best, the availability of products makes the decision nothing but time consuming. After all – the engine is just a tool to support your business on the web.

The workflow

The workflow, however, is you business. And that’s where the available products usually fall very short of the mark, no matter how much they push the “flexibility” and “usability” pitch.

There are a lot of articles and product briefs (primarily from the designer standpoint) preaching the importance of having an intuitive interface, to give users full creative control over the content. And although I don’t want to downplay the importance of the usability of the web-based systems (in fact, it’s one of the more important aspects of the process implementation), the differentiators preached are mainly irrelevant to the business needs. Listing a WYSIWYG editor as one of the primary selling points in evaluating of the system for your business is ridiculous. It’s 2011, and there is a usability level of any web based system that’s expected out of any product. However, no matter how intuitive and usable the interface and the flow may be in the off-the-shelf product, chances are, unless you’re in media publishing business (articles, images, videos, etc) it will not match the flow that’s intuitive for your business.

Every business has a unique model/approach/flow, and that flow needs to be represented by the CMS. One of the pitfalls of any CMS product out there (thought no fault of the product, but rather the conceptual design) is that it is catered to serve a specific types of content. The creators of the products try to accommodate every need, but, as with any attempt to please everyone, unsuccessfully. There are two reasons for the failure.

Catering to everyone means catering noone

Every CMS, no matter how flexible it is (or is claimed to be) can’t foreseeably cover every use case, even for a single type of business. If it was possible – we’d have one and only all-purpose CMS used by everyone. Therefore, the authors of the product try to either specialize on a niche business model (i.e. blogging, product store, etc) and/or try to cover the use-cases that they feel are most significant to generic business flows. There are obvious problems with that approach.

A classic argument for build vs buy – generic flow is just that – generic. Which means there is going to be a certain level of modification of the core product in order to get your business needs accommodated, which would vary based on complexity of the features you need. But let’s leave alone this argument for a minute, and not go into the maintenance cost, skilled staff needs, upgrade paths, etc. that are covered in lengths in other articles. Let’s assume that you managed to find a product with an exact feature set that’s perfect for your business. One thing that most people don’t consider is the product road map. As I mentioned, the feature set of the product is the vision of the creator(s), Product Manager, or CEO, depending on the product. That vision may not include the features you need in the next release, either because of the change in product direction, lack of demand, or many other reasons that drive any business. As an example, Firefox 4.0 removed RSS feed icon from the address bar, because it was only used by a small percentage of users. Logical business decision, why support the feature that’s not in high demand. However, what happens if you’re in that small group of users who used the RSS icon religiously? Now, we are talking about individuals here. Now consider the effect on the business if the core feature, that was a reason for CMS selection,and that’s a driving force behind your business, is discontinued.

Lack of subject matter expertise

So why is it so hard to find an off-the-shelf CMS product that fits your business? The short answer is actually pretty simple – creators and developers of the products don’t know your business. Internet is very young, and the demands for the online businesses change daily. The original concept behind the content management was to allow easy creation and publishing of the content that was predominant on web 10 years ago. The internet has changed. It’s no longer a medium for wiki-style information; the content nowdays is dynamic, personalized, and more importantly, it’s not uniform. Whereas before internet could’ve been viewed as a single purposed business vertical, like newspaper or magazine industry, it is now an ever-growing tool for running your business in a different channel, and as such, it has to comply to individual requirements of the business needs – in the same fashion as the businesses operate offline. Noone in a right state of mind, when opening a restaurant, would buy retail store cash register software for the bar. Even though both run on cash registers to ring our purchases, the process is very, very different between the two. And everyone knows it. And yet, people are buying into “one size fit all” CMS. So why wouldn’t people apply the same philosophy for the online businesses? Why would anyone think CMS product built specifically to create and publish media content would be good to back live sports scoreboard site?! Content type, methods for publishing, workflow, and even data model do not resemble the use cases of the available products. So why do people still try to push a square peg through a round hole?

Again, the Internet is young. And so is the concept of web content management. Right now, the products available are created, designed, and built by web generalists, who are very web-savvy, but lack knowledge of any industry specific standards. You can see the trends are shifting just a little recently, with the emergence of e-commerce specific CMS products, like Magento, designed specifically to manage the content of online stores. I envision that in the near future we’ll see a surge of industry vertical specific CMS products (finance, sports, travel, etc) lead by the experts in the field. This would provide a much-needed steam of products that would enable business to successfully operate online. Until then – unless your business overlaps close with the media angle of the available CMS – consider building a tool that’s right for your business.

First of all, let me make a blanket statement here: the sentence “the project is late – but [it looks better/it is easier to maintain/the code is cleaner]” (pick any that apply) is inherently flawed. If the project is late – it’s not done. Period. There is no way to justify being late by using code quality/elegance as an argument. If the client needs a Christmas promotion, and you deliver a best product in a history of promotions on December 29th – it’s worthless.

Now, let’s address the “best practices” argument. I will keep using this phrase in quotes because the standards vary across the board, despite some common misconceptions, short of the most common Best Practices 101 that every programmer should have imprinted in their brain before the first “Hello World” is written. With that said, “best practices”, however you define it, should be a natural coding standard for any decent developer. If you need to bake more time into the project time-line to make your code comply – you are, at best, new to the programming scene. To trivialize the example, any seasoned programmer should instinctively know not to call the variables $a, $b, $c, etc., and properly indents the code lines. Granted, there are more advanced “best practices” standards that one might argue, but the point stands. And to expand on it, a veteran programmer knows when and, most importantly, how to cut corners, if needed, to meet the deadline. Which brings me to my next point – over-engineering.

I understand the desire to build the best, most flexible and robust system for every project worked on. I do. But I also understand the usual business constraints of every project: time and money. Most projects have a definite deadline and/or a specific budget that need to be met and, often times, building something grand is not feasible within either. This is where the developer needs to make a conscious decision to limit the creativity to meet the goals. There is no excuse to spend a week to setup a “proper” caching layer for the database queries operating on a 20-row table, that are only used from the administrative panel by three publishers. Understand the use-cases. And as cool as it may be to build a flexible and expendable XHR framework to support variable simultaneous requests; you don’t need to invest into it if the only feature that will be using it, is an update to a visitors counter on one page. Understand the scope. I cannot stress it enough – a good developer is not the one who knows how to build the most advanced system, a good developer is the one who knows when not to build that system.

In the world of software development, time to market is the driving force of the business. In a world of internet application development it’s even more apparent because of the dynamics of the web. The simplest solution is not often the best solution. It is always the best solution.

Perhaps the best analogy of my philosophy on the topic was made by my co-worker, when he heard my rant for the N-th time, by using a parkour reference. Assuming the goal of the competition is to get to the roof of the high-rise – some people will jump from balcony to balcony to get to the end, some will climb fire ladders, some will form a human pyramid. Me? I would take an elevator.

# select a list of items
$sth = $dbh->prepare("select id from items where ....");
$sth->execute();
foreach ($hreh = $sth->fetchtow_hashref()) {
  # create an array of item objects with all the properties
  push @items, Module::Item->new($href->{id});
}

foreach (@items) {
  # render item list
  print "ID: ".$_->id."\n";
  print "Properties: ".join(",",@{$_->properties})."\n";
  ....
}

If you didn’t spot the problem right away – I may have to borrow Theo’s stick and come over for a visit.

It’s the classic n+1 problem. The application is hitting a database to get the properties n(number of items) times, plus the hit from the initial query to get a list of items. Why?! There is absolutely no reason to do that. Ever. Yet, I see the same issue over and over again in variety of applications, running on different systems, written in different languages. Granted, one of the biggest offenders are the apps using a framework or an ORM (example above actually assumes Module::Item to know how to retrieve all the object data needed, including going to the database to get it). Maybe the excuse is that the developer doesn’t know what happens under the hood of ORM, although if you don’t know the benefits and limitations of a tool – you shouldn’t be using it. But I’ve also seen an alarming number of applications not using an ORM that have the same issue, and it’s even more obvious since you yourself are defining all the actions.

# select a list of items
$sth = $dbh->prepare("select id from items where ...");
$sth->execute();
foreach ($hreh = $sth->fetchtow_hashref()) {
  # create an array of items with all the properties
  $sth_properties = $dbh->prepare("select * from item_properties
                                   where item_id = ?");
  $sth_properties->execute($href->{id});
  $item->{properties} = $sth_properties->fetchrow_arrayref();
  $item->{id} = $href->{id};
  push @items, $item;
}

foreach (@items) {
  # render item list
  print "ID: ".$_->{id}."\n";
  print "Properties: ".join(",",@{$_->{properties}})."\n";
  ....
}

If nothing else – having a $dbh->prepare("SELECT ....") and $sth->execute inside a loop should raise a whole lot of red flags right away (this approach has more than one issue, but let’s concentrate on the problem at hand). There are different variations of the extent of, or lack of, ORM usage (as example, instead of initial SELECT you may use something like Module::Item->get_all) but it doesn’t change the sequence of logic, and subsequently, the performance.

I hope by this point of my rant everyone realized the “right” way of coding this bit of functionality, but just in case – here’s a code that produces exactly the same result with only 1 database query.

# select a list of items WITH properties
$sth = $dbh->prepare("select p.* from items i, item_properties p
                              where i.id = p.id
                              and i. .....");
$sth->execute();
foreach ($hreh = $sth->fetchtow_hashref()) {
  # create an array of item objects with all the properties
  # without going back to the database
  push @items, bless $href, 'Module::Item';
}

foreach (@items) {
  # render item list
  print "ID: ".$_->id."\n";
  print "Properties: ".join(",",@{$_->properties})."\n";
  ....
}

So pretty please, with sugar on top, don’t create performance problems where there should be none!

In this day and age, more and more companies operating online businesses try to break into the social media realm by leveraging existing services to increase visibility and loyalty of the brand, to bring more people to the sites, and consequently, increase the conversions, whether it’s visits, purchases, or participation. I’ve seen many incarnations of social networking implementations, from the basic simplified authentication with Facebook Connect augmenting regular process (for ease of registration/login) to full blown applications relying heavily on multiple features available from the services’ APIs. Now, personally, I am all for having the services available, and used strategically throughout the applications. It provides a tremendous benefit not only in brand familiarity and content, but also in cost saving, considering you’re leveraging years of someone else’s work for your gain. Consider Flickr. The storage, CDN, and REST APIs to present the assets are all developed and tested for you; all you need to do is to integrate the functionality within the content of your site. The same services are available to everyone, and it’s a business decision which features would be beneficial to the company’s strategy. The implementation of the features, however, varies significantly.

One of the major risks when implementing a third party service is the reliance on the availability of that third party service. The service that you have no control over. And no matter how large or successful the service that you’re using is – it will go down at one point or another. Just look at the intro image with a log from my Twitter client. Now, imagine what happens during the downtime if your site heavily relies on Twitter API.

On a side note, I talked at length before about the need for application monitors to assist both development and operations teams with monitoring the health of the application, because a lot of times just monitoring system health is not enough. To offer a piece of advice, a good metric to track against your system and application performance is a commit log. It allows you to correlate you version control commits and deployments to irregularities in trending patterns. It also lets you identify the problematic piece of code when something goes wrong. But I digress.

So let’s examine a situation. A large online media company decided to switch to Facebook Connect as an exclusive authentication method for their site. (To prevent the discussion about the viability of this choice, let me just note that there was a business reason for choosing this route.) This is where the fun starts. The graph below represents HTTP load time for the pages on the site at every stage of the process. Even without the captions on the graph (given the tone of this post), everyone should be able to pin-point the exact time when the changeset went live, and the load time of the pages tripled. The project owners were notified, but since the load times were extremely low to begin with (thank you caching) the load speed was deemed acceptable, and the changes remained in production. Time passed. And then some more. And then the dark day came – the day when Facebook went down. And the page load times on the media site tripled again, for a very brief period of time (while Facebook servers were just lagging), and then dropped to 0, i.e. “users are unable to see the site”. Just like that – Facebook’s problem became the company’s problem.

Upon closer code investigation the problem was identified and solved quickly, also reducing the page load time to it’s original threshold as a byproduct of the change, but it shows how dependent your site can become on a third party service availability if the features are not implemented correctly.

So how can these issues be avoided? There are a few common sense rules, that for some reason often get ignored during the development, which should help with the integration of external services without effecting your site’s performance.

1. Only connect to a third-party service where needed. Don’t try to connect to Facebook on every page load to validate that user is still the user you displayed the previous page to.  Cache the results locally.

2. Don’t make connections to a third-party service in the critical path of the page load. Don’t load Google Analytics as a first thing on your page, you will delay the display of the content that actually matters.   Make the connections after your content is loaded, or better yet – connect asynchronously.

3. Trap time-outs and errors. You do it with your database connections, why would you treat external connections differently?

4. Create a fallback plan. You have no control over external services, but you do have the control over the content presented to your users. If Flickr feed is the essential feature of your site – store the displayed history locally, so you can fall back to the latest available content in case Flickr is unavailable. Remember, sometimes stale content is better then no content at all.

To make a blanket statement — don’t jump to using social media features without identifying a need for them, use them to support your primary business model. At the end of the day, when integrating any third party service, you are trying to leverage the benefits of the available functionality to enhance the experience for your own users, not to inherit the services’ availability problems. Integrate smartly, not blindly.

OmniLogger

package OmniLogger;
use Symbol;

sub import {
  my $self = shift;
  foreach (@_) {
    if ($_ eq 'stdout') {
      *STDOUT = $self->new;
    } elsif ($_ eq 'stderr') {
      *STDERR = $self->new;
    }
  }
  $self->init(@_);
}

sub new {
  my $self = shift;
  my $sym = gensym;
  tie *$sym, $self;
  bless $sym, $self;
}

sub TIEHANDLE { bless {}, shift }

sub PRINT { shift->log(shift)}

sub init { return; }

sub log { return; }

sub DESTROY { return; }

1;

That’s it. log() function is for implementing logging mechanics, and init() and DESTROY() are for methods that require constructor/destructor actions.

Let’s assume, for the example sake, that the goal is to print “Hello World!” to the file. First, let’s subclass Logger as Logger::File and define the output.

OmniLogger::File

package OmniLogger::File;
use base 'OmniLogger';
use Filehandle;

my $_fh;

sub init {
    my $self = shift;
    $_fh = FileHandle->new("/var/tmp/logger.log","a+");
}

sub log {
    my $self = shift;
    my $msg = shift;
    if (defined $_fh) {
        $_fh->printf("%s","$msg\n");
    }
}

sub DESTROY { $_fh->close; }

1;

And now, let’s use it. The module allows two types of usage: standard function call and the full override of outputs.

Standard call

#!/usr/bin/perl
use OmniLogger::File;

my $logger = OmniLogger::File->new;
$logger->log("Hello World!");

Global Override

#!/usr/bin/perl
use OmniLogger::File  qw(stdout);

print "Hello World!";

Both examples will yield the same result. The major difference is that every print call in the script in the second example will be printed to the file. This allows to avoid those long annoying debugging print FILEHANDLE lines in the code and just use oh-so-familiar print.

In addition, override of STDERR is also allowed, in case logging all the errors in the script is a goal.

#!/usr/bin/perl
use OmniLogger::File  qw(stderr);

die "Goodbye Cruel World!";

Disclaimer: This trick will not work within frameworks, like Mungo, that already override print.

Are you tired of the same boring web fonts?

Look at any website. Look closely. Now go to another website. Rinse and repeat. Again. What you see is a same set of fonts used over and over across vast majority of the websites. Arial, Helvetica, Times New Roman. Not much of a variation there, is it? Didn’t you wish that your website could do something different? Well, now you can! Fontdeck offers fonts for your website that, up until now, you were only able to use offline!

But what about all the websites that use cool fonts for their logos?

What an excellent question! There are websites that try to mimic unique fonts on the web by creating text images in Photoshop or using Flash to display the fonts. Those techniques are nothing but hacks in order to circumvent inadequacies of the browsers. By using any of the media techniques those sites are limiting their flexibility to manipulate fonts (scaling, as example), increasing production time (making new images), or having to deal with SEO and accessibility issues (Flash).

So how does Fontdeck solve these problems?

Fontdeck is using CSS @font-face technique to provide a true text to the user that can be scaled, translated and searched. No JavaScript? No Flash? No problem!

I don’t know, It sounds complicated…

It’s not! It takes minutes to add the needed fonts to your web site! Of course, you could spend much more time browsing for that perfect font that would represent a picture of your cat.

BUT WAIT, THERE IS MORE!

Actually, no, there isn’t. I just wanted to show off yet another font. Sign up for Fontdeck news and check out the fonts used for this blog.

And to finish off this rant, let me quote Theo Schlossnagle, for those of you who are interested in the technology magic behind the service.

Fontdeck is powered by our friends: Apache, PostgreSQL, OpenSolaris, a bit of Linux here and there, a sprinkling of both asymmetric and symmetric cryptography and an ancient dialect of computer-speak called Perl.