Probably the best example is to simply go to the site and click on “About itty bitty.” That page is itself encoded in its own URL. If you then click on the App link, you’ll see a calculator, showing that this isn’t just for snippets of text. While this does depend on the itty.bitty.site web host to provide the decoding framework, the decoding is done totally in your browser and the code is open source. What that means is you could host it on your own server, if you wanted to.
At first, this seems like a novelty until you start thinking about it. A small computer with an Internet connection could easily formulate these URLs to create web pages. A bigger computer could even host the itty.bitty server. Then there’s the privacy issue. At first, we were thinking that a page like this would be hard to censor since there is no centralized server with the content. But you still need the decoding framework. However, that wouldn’t stop a sophisticated user from “redirecting” to another — maybe private — decoding website and reading the page regardless of anyone’s disapproval of the content.
Continue reading “Tiny Websites have no Server”
Last month we posted a tutorial from Hub City Labs on making your own PCBs at home. At the time, Hub City was hosting their hackerspace web site on a tiny vps graciously provided by a member. As you might expect, the throngs of Hackaday readers turned Hub City Labs’ server into a pile of molten slag and made their admin’s hair a little more gray. Their web site is up again, and Hub City provided a tutorial on protecting your server from the ravages of being Slashdotted, Farked, Reddited, and even Hackaday’d.
The solution for the first few hours was to transfer Hub City Labs’ site to an Amazon EC2 instance. Since then, they’ve moved over to a Debian EC2 instance that is able to handle half a million pageviews an hour for a WordPress site.
This amazing capability required a good bit of optimizations. A WordPress installation is set to run cron tasks on every page load; not good if you’re going to see thousands of hits every minute. The guys added define(‘DISABLE_WP_CRON’, true) to their wp-config.php file and set all the background tasks – checking to see if a page should be updated – to a fixed schedule every minute or so. Along with an increase in the WordPress cache, these optimizations increased the number of pageviews an hour from 1500 to 60000.
To get up to half a million pageviews an hour, the EC2 instance was loaded up with Varnish, a front-end cache that really speeds things up.
The result – 375 million pageviews for $15 a month – is more than Hub City Labs will probably ever need. The nature of hackerspace web sites, though – light load until Hackaday, Slashdot, or Reddit figure out you did something cool – means hosting on an expandable EC2 instance is probably the way to go.