With yesterday’s announcement about the general availability of its Compute Engine, Google has rounded its service-rich computing Cloud Platform into a full-on competitor to the elite and powerful handful of existing providers.

Behind every notable online service or app, from Netflix to Angry Birds to Snapchat, is that set of backend processes requiring gobs (mega-gobs, peta-gobs) of digital storage and computing power. Until relatively recently, this required a tech startup to quickly come up with millions of dollars to build and test the systems that could accommodate growing user demand.

Amazon, having invested their tremendous resources to support their own retail enterprise, was the first to turn that infrastructure into a publicly available, cloud-based set of products and services. While they remain the biggest provider, other players have entered the field, including Microsoft and IBM.

With yesterday’s release, Google has lowered the price of some services and are probably playing to their strengths by exceeding the industry’s benchmark performance guarantees (“Monthly Uptime Percentage to Customer of at least 99.95%,” according to the Google Compute Engine Service Level Agreement). One way they plan to keep their promises is with their new, built-in live-migration technology: interruptions owing to scheduled maintenance will never happen.

Tech watchers insist that the offering hasn’t completely arrived, due in part to the need for better integration between the different products. Still, with their deep pockets, as well as the equipment and experience they’ve amassed to deliver their pervasive and heavily-used email, search and video services, the potential is very promising.

Google’s Cloud Platform could give its competitors a run for their money, sparking more innovation as they vie for the market. And while the number of companies offering cloud computing services isn’t likely to ever get very big, having one more solid option is welcome news.

For a more indepth look at Google’s entry into the cloud computing industry, see Quentin Hardy’s great piece in the New York Times. Check out the Google Cloud Platform blog for a detailed post about the Compute Engine General Availability status and features.

Do you use Amazon’s cloud service? Would you consider switching to Google? Let us know your thoughts in the comments.

The Designer’s Complete Holiday Bundle – only $19!

UMBC’s ACM student chapter has a new website that will be used to announce its activities and events as well as news about computing related opportunities and resources. The chapter is open to both undergraduate and graduate students interested in computing from all majors. Joining is free and is a great way to meet other students interested in computing and to participate in activities that will help you grow as a professional.

ACM, the Association for Computing Machinery, is the the world’s largest educational and scientific computing society. It provides members with resources that advance computing both as a science and a profession. UMBC’s chapter meetings are open to all undergraduate and graduate students of any major. While you do not need to join ACM to be a part of the local chapter, the annual membership dues for students is only $19, heavily discounted from the non-student rate. See the ACM site for more information on student membership and its benefits.

For more information contact us at acmofficers AT lists.umbc.edu.

Digital Fabrication Pioneer Potomac Photonics Expands to New Facility at BWTech@UMBC

Imagine that you have just written a post on your blog, tweeted about it and watched it get retweeted by some popular Twitter users, sending hundreds of people to your blog at once. Your excitement at seeing so many visitors talk about your post turns to dismay as they start to tweet that your website is down — a database connection error is shown.

Or perhaps you have been working hard to generate interest in your startup. One day, out of the blue, a celebrity tweets about how much they love your product. The person’s followers all seem to click at once, and many of them find that the domain isn’t responding, or when they try to sign up for the trial, the page times out. Despite your apologies on Twitter, many of the visitors move on with their day, and you lose much of the momentum of that initial tweet.

These scenarios are fairly common, and I have noticed in my own work that when content becomes popular via social networks, the proportion of mobile devices that access that content is higher than usual, because many people use their mobile devices, rather than desktop applications, to access Twitter and other social networks. Many of these mobile users access the Web via slow data connections and crowded public Wi-Fi. So, anything you can do to ensure that your website loads quickly will benefit those users.

In this article, I’ll show you Varnish Web application accelerator, a free and simple thing that makes a world of difference when a lot of people land on your website all at once.

Introducing The Magic

For the majority of websites, even those whose content is updated daily, a large number of visitors are served exactly the same content. Images, CSS and JavaScript, which we expect not to change very much — but also content stored in a database using a blogging platform or content management system (CMS) — are often served to visitors in exactly the same way every time.

Visitors coming to a blog from Twitter would likely not all be served exactly the same content — including not only images, JavaScript and CSS, but also content that is created with PHP and with queries to the database before being served as a page to the browser. Each request for that blog’s post would require not only the Web server that serves the file (for example, Apache), but also PHP scripts, a connection to the database, and queries run against database tables.

The number of database connections that can be made and the number of Apache processes that can run are always limited. The greater the number of visitors, the less memory available and the slower each request becomes. Ultimately, users will start to see database connection errors, or the website will just seem to hang, with pages not loading as the server struggles to keep up with demand.

This is where an HTTP cache like Varnish comes in. Instead of requests from browsers directly hitting your Web server, making the server create and serve the pages requested, requests would first hit the cache. If the requested page is in the cache, then it is served directly from memory, never touching Apache or the database. If the page is not in the cache, then the request is handed over to Apache as usual, whereupon Apache will create and serve the page, which is then stored in the cache, ready for the next request.

Serving a page from memory is a lot faster than serving it from disk via Apache. In addition, the page never needs to touch PHP or the database, leaving those processes free to handle traffic that does require a database connection or some processing. For example, in our second scenario of a startup being mentioned by a celebrity, the majority of people clicking through would check out only a few pages of the website — all of those pages could be in the cache and served from memory. The few who go on to sign up would find that the registration form works well, because the server-side code and database connection are not bogged down by people pouring in from Twitter.

How Does It Work?

The diagram below shows how a blog post might be served when all requests go to the Apache Web server. This example shows five browsers all requesting the same page, which uses PHP and MySQL.

Every HTTP request is served by Apache — images, CSS, JavaScript and HTML files. If a file is PHP, then it is parsed by PHP. And if content is required from the database, then a database connection is made, SQL queries are run, and the page is assembled from the returned data before being served to the browser via Apache.

If we place Varnish in front of Apache, we would instead see the following:

If the page and assets requested are already cached, then Varnish serves them from memory — Apache, PHP and MySQL would never be touched. If a browser requests something that is not cached, then Varnish hands it over to Apache so that it can do the job detailed above. The key point is that Apache needs to do that job only once, because the result is then stored in memory, and when a second request is made, Varnish can serve it.

The tool has other benefits. In Varnish terminology, when you configure Apache as your Web server, you are configuring a “back end.” Varnish allows you to configure multiple back ends. So, you might want to run two Web servers — for example, using Apache for PHP pages while serving static assets (such as CSS files) from nginx. You can set this up in Varnish, which will pass the request through to the correct server. In this tutorial, we will look at the simplest use case.

I’m Sold! How Do I Get Started?

Varnish is really easy to install and configure. You will need root, or sudo, access to your server to install things on it. Therefore, your website needs to be hosted on a virtual private server (VPS) or the like. You can get a VPS very inexpensively these days, and Varnish is a big reason to choose a VPS over shared hosting.

Some CMS’ have plugins that work with Varnish or that integrate it in the control panel — usually to make clearing the cache easier. But you can put Varnish in any CMS or any static website, without any particular integration with other systems.

I’ll walk you through installing Varnish, assuming that you already run Apache as a Web server on your system. I run Debian Linux, but packages for other distributions are available. (The paths to files on the system will vary with the Linux distribution.)

Before starting, check that Apache is serving your website as expected. If the server is brand new or you are trying out Varnish on a local virtual machine, make sure to configure a virtual host and that you can view a test page on the server using a browser.

Install Varnish

Installation instructions for various platforms are in Varnish’s documentation. I am using Debian Wheezy; so, as root, I followed the instructions for Debian. Once Varnish is installed, you will see the following line in the terminal, telling you that it has started successfully.

    [ ok ] Starting HTTP accelerator: varnishd.
    

By default, Apache listens for requests on port 80. This is where incoming HTTP requests go, because we want Varnish to essentially sit in front of Apache. We need to configure Varnish to listen on port 80 and change Apache to a different port — usually 8080. We then tell Varnish where Apache is.

Reconfigure Apache

To change the port that Apache listens on, open the file /etc/apache2/ports.conf as root, and find the following lines:

    NameVirtualHost *:80
    Listen 80
    

Change these lines to this:

    NameVirtualHost *:8080
    Listen 8080
    

If you see the following lines, just change 80 to 8080 in the same way.

    NameVirtualHost 127.0.0.1:80
    Listen 80
    

Save this file and open your default virtual host file, which should be in /etc/apache2/sites-available. In this file, find the following line:

    <VirtualHost *:80>
    

Change it to this:

    <VirtualHost *:8080>
    

You will also need to make this change to any other virtual hosts you have set up.

Configure Varnish

Open the file /etc/default/varnish, and scroll down to the uncommented section that starts with DAEMON_OPTS. Edit this so that it looks like the following block, which will make Varnish listen on port 80.

    DAEMON_OPTS="-a :80 \
    -T localhost:1234 \
    -f /etc/varnish/default.vcl \
    -S /etc/varnish/secret \
    -s malloc,256m"
    

Open the file /etc/varnish/default.vcl, and check that the default back end is set to port 8080, because this is where Apache will be now.

    backend default {
    .host = "127.0.0.1";
    .port = "8080";
    }
    

Restart Apache and Varnish as root with the following commands:

    service apache2 restart
    service varnish restart
    

Check that your test website is still available. If it is, then you’ll probably be wondering how to test that it is being served from Varnish. There are a few ways to do this. The simplest is to use cURL. In the command line, type the following:

    curl http://yoursite.com --head
    

The response should be something like Via: 1.1 varnish.

You can also look at the statistics generated by Varnish. In the command line, type varnishstat, and watch the hit rate increase as you refresh your page in the browser. Varnish refers to something it can serve as a “hit” and something it passes to Apache or another back end as a “miss.”

Another useful tool is varnish-top. Type varnishtop -i txurl in the command line, and refresh your page in the browser. This tool shows you which files are being served by Varnish.

Purging The Cache

Now that pages are being cached, if you change an HTML or CSS file, you won’t see the changes immediately. This trips me up all of the time. I know that a cache is in front of Apache, yet every so often I still have that baffled moment of “Where are my changes?!” Type varnishadm "ban.url ." in the command line to clear the entire cache.

You can also control Varnish over HTTP. Plugins are available, such as Varnish HTTP Purge for WordPress, that you can configure to purge the cache directly from the administration area.

Some Simple Customizations

You’ll probably want to know a few things about how Varnish works by default in order to tweak it. Configuring it as described above should cause most basic assets and pages to be served from the cache, once those assets have been cached in memory.

Varnish will only cache things that are safe to do so, and it might not cache some common things that you think it would. A good example is cookies.

In its default configuration, Varnish will not cache content if a cookie is set. So, if your website serves different content to logged-in users, such as personalized content, you wouldn’t want to serve everyone content that is meant for one user. However, you’d probably want to ignore some cookies, such as for analytics. If the website does not serve any personalized content, then the only cookies you would probably care about are those set for your admin area — it would be inconvenient if Varnish cached the admin area and you couldn’t see changes.

Let’s edit /etc/varnish/default.vcl. Assuming your admin area is at /admin, you would add the following:

    sub vcl_recv {
       if ( !( req.url ~ ^/admin/) ) {
         unset req.http.Cookie;
       }
     }
    

Some cookies might be important — for example, logged-in users should get uncached content. So, you don’t want to eliminate all cookies. A trip to the land of regular expressions is required to identify the cookies we’ll need. Many recipes for doing this can be found with a quick search online. For analytics cookies, you could add the following.

    sub vcl_recv {
      // Remove has_js and Google Analytics __* cookies.
      set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_[_a-z]+|has_js)=[^;]*", "");
      // Remove a ";" prefix, if present.
      set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", "");
    }
    

Varnish has a section in its documentation on “Cookies.”

In most cases, configuring Varnish as described above and removing analytics cookies will dramatically speed up your website. Once Varnish is up and running and you are familiar with the logs, you can start to tweak the configuration and get more performance from the cache.

Next Steps

To learn more, go through Varnish’s documentation. You should understand enough of Varnish’s basics by now to try some of the examples. The section on “Achieving a High Hit Rate” is well worth a read for the simple tips on tweaking your configuration.

Keep calm and try Varnish to optimize mobile websites. (Image source)

(al, ea, il)

© Rachel Andrew for Smashing Magazine, 2013.

A post on Google’s research blog lists the major datasets for NLP and KB processing that Google has released in the past year. They include datasets to help in entity linking, relation extraction, concept spotting and syntactic analysis. Subscribe to the the Knowledge Data Releases mailing list for updates.

Berger cookies - those fudgey, fatty delights we can’t resist. 

These things have been around since 1835, when the recipe came to Baltimore from Germany via the Berger brothers. The cookies are now iconic to the area.

Last year, DeBaufre Bakeries, maker of the cookie, made $2.5 million in sales. Not too shabby for a hometown hero. But is the 187 year reign of Berger about to come to an end?

The FDA is proposing a ban on partially hydrogenated oils, a major source of trans fats, that could come into play as early as next year. Margarine, a main ingredient in Berger’s fudgy topping, has plenty of partially hydrogenated oils that have been linked to heart disease. Can’t DeBaufre just make a healthier cookie, free of the fatty margarine?

Apparently, the recipe is hard to break… it seems the margarine gives the cookie it’s extra-irresistible creaminess.

“I just know that when we tried the substitutes, without making any additions ourselves, it tasted nasty” - Charles DeBaufre, owner

What’s next for the cookie?

A healthier substitute? The black market? Or is it bye-bye Berger?

Public health experts have condemned trans fats for a long time, and New York City already banned the oils from restaurants back in 2007.

“The FDA deserves great credit for taking this step, which will help Americans live longer, healthier lives,” Mayor Bloomberg said.

Do you think the FDA ban is a step in the right direction? Let us know.

Just a few short years ago the majority of web designers wouldn’t have been able to spell skeuomorphism, much less provide an accurate definition. Now, skeuomorphism is set up as the pantomime villain; the Wicked Witch of the East to flat design’s Dorothy.

Flat design has come to define itself as ‘not skeuomorphic’, but this is misleading; skeuomorphism isn’t the polar opposite of flat design, in fact flat design is frequently skeuomorphic.

What skeuomorphism (really) is

A simple definition of skeuomorphism is as follows: a decorative feature that imitates a functional aspect of an earlier technology. For example, decorative arches are often used in architecture, mimicking the functional arches of earlier centuries; this is skeuomorphism.

Design movements — in fact, movements in most cultural fields — have a tendency to reject the previous generation’s values. Consequently culture progresses as a series of revolutions and counter-revolutions. Skeuomorphism frequently occurs when technology or fashion turns full circle and old values become popular again.

A neo-modernist working in the early twenty first century may well find themselves imitating the qualities forced upon modernists by the limits of the technology a century ago; we frequently see posters designed with simple flat color, not because we can’t print gradients, but because we’re imitating the style of poster designers like Toulouse-Lautrec whose style was imposed by the printing technology he had commercially available to him.

What skeuomorphism (really) isn’t

An oft-cited example of skeuomorphism in website design is a button styled with bevels and a drop shadow. The current trend is to make the button ‘flat’ by removing the bevels and the drop shadow, which supposedly removes the skeuomorphic nature of the button; in fact it does nothing of the sort.

A button remember, is a mechanical lever which changes state when one applies pressure. We don’t create buttons on web pages, we create an image of a button that we can touch or click and which mimics the function of the older technology. Any button, on any web page, is inherently skeuomorphic, regardless of its styling.

Another frequently cited example of skeuomorphism is the leather texture and stitching used for certain apps on older versions of Apple’s iOS. The argument is that the texture is carried over from traditional personal organizers and is therefore skeuomorphic.

I question whether this is in fact skeuomorphism. Certainly the leather texture imitates the earlier technology, but it’s decoration imitating decoration. You could perhaps argue that leather is hard-wearing and the texture is functional in the original design, but I think that would be laboring the point. The leather texture in early iOS apps isn’t skeuomorphic, it’s something much worse: it’s lazy design.

Skeuomorphism and flat design

Microsoft’s Windows famously embraced flat design and rightly received the plaudits for having the guts (if not the chops) to pursue a new direction. Apple followed suit with iOS7 and, if rumors are to be believed, will continue on a similar path with their next major OS.

Window’s initial jump, and iOS’ capitulation are widely seen as the first, and last nails in the coffin of skeuomorphism.

However Windows 8, MacOS Mavericks, and in all probability the next generation of both platforms are inherently skeuomorphic; they use the concept (and likeness) of files and folders; something borrowed from centuries old filing systems. Many people choose not to interact with data in this way and instead rely on the command line or terminal; but it’s very rare to find someone who doesn’t do at least a little dragging and dropping.

You might remove some superficial aspects of a design which are skeuomorphic, but you’re still looking at a web ‘page’, through a browser ‘window’, that sits on your ‘desktop’.

Flat design then, impacts very little on the amount of skeuomorphic design that we experience on a daily basis.

The inevitability of skeuomorphism

Arguably the biggest rejection of a skeuomorphic web occurred when we stopped clinging to the idea of web sites being screen-based versions of print design and embraced responsive design. However, unless we develop a William Gibson-esque internet, in which information is seen as it is — infinitely extensible, editable streams of interconnected data — then we’ll continue to treat the Web as a metaphor for real-world documents and the Web will remain skeuomorphic.

Just as uppercase letters are derived from stone carving, and old-style serifs are derived from cursive scripts, so too is all culture based on what preceded it. As Sir Isaac Newton said, “If I have seen further it is by standing on the shoulders of giants.”

One day in the not too distant future, print will cease to be anything but an historic process. The materials that we print now will be replaced by surfaces, the molecules of which will change their color to create text, images and movies — imagine a sheet of paper with the interactive abilities of a tablet. In that exciting future, you’ll still find the echoes of a medieval monk, ensconced in a library somewhere in northern Italy, painstakingly illuminating a copy of the Bible.

In this, we find skeuomorphism’s salvation: skeuomorphism isn’t a design trend particular to the Web, it’s a characteristic of all human culture. Without skeuomorphism our ability to experience the Web is substantially diminished. Without skeuomorphism every leap in technology would be accompanied by a learning curve so steep, it would be prohibitive. Without skeuomorphism, I wouldn’t be typing this, I’d be in a forest somewhere hitting a nut with a stick.

The non-skeuomorphic web

This is not to say that all aspects of the Web are skeuomorphic, or that there is no progress without skeuomorphism.

Take for example the hover state of buttons. Whilst buttons themselves are deeply skeuomorphic, the change in the visual nature of the button, not when it is pressed, but when the user is considering pressing it, is (to my knowledge) unprecedented.

Some cutting edge developments are equally unique. Take for example the experiments with gaze-tracking that scroll a page up and down based on the motion of your eyes or head.

One of the truly great achievements of the Web is the distribution of information to the visually impaired. Text readers have made billions of pages of data available to those with visual disabilities. No books, magazines, or print of any kind ever had a function that read content to you. The development of text readers, and more recently speech control is a genuinely new technology and as such carries with it no skeuomorphic decoration.

The future of skeuomorphism

Skeuomorphism exists, and will continue to exist because it guides our paths into new technologies and new experiences.

Skeuomorphism is a positive force within design, it teaches new interfaces in the same way that children learn: if ‘a’ means ‘b’ in ‘c’ situation, then in all probability ‘a’ means ‘b’ in ‘d’ situation. Imagine a world in which the cold faucet in the bathroom was colored blue and the cool cycle on a washing machine was colored orange — skeuomorphism accelerates communication.

What then is the problem with skeuomorphism and why are so many people keen to reject it? The answer is twofold. Firstly, people rarely reject skeuomorphism, what they reject is lazy design and superfluous decoration; secondly, as with most design techniques, if users notice it you’re overdoing it.

So it’s wise to drop the bevels and drop shadows if they’re drawing attention to themselves, but be aware that everything you design on screen uses skeuomorphism to some degree.

As is so often the case, don’t blame skeuomorphism, blame the designer who over uses it.

Is flat design the antithesis of skeuomorphism? Does skeuomorphism still have a role to play in web design? Let us know your opinions in the comments.

Featured image/thumbnail, skeuomorphic button image via Shutterstock.

Sketch iPhone or Website Mockups with UI Stencils Kits – only $25!