Hosting a static website on AWS

Here's a quick guide to hosting a static website on Amazon Web Services. In this guide we set up a root domain for your site content, a www subdomain that redirects to the root domain, and a cdn subdomain that uses Amazon CloudFront as a content distribution network to make your site load faster.

Setting up S3 buckets for hosting the files

First off, go to aws.amazon.com and either log in or sign up for an AWS account. You'll need a credit card for that, mind. Now that you're logged in, go to the S3 console. There? Great!

The second step is to create a new bucket for your site content. Click on the big blue button that says Create Bucket. For the name, enter the domain of your website. Pick the region closest to your intended audience.

Now let's upload the site content into the bucket. Click on the name of the bucket to enter it. Now click the blue Upload button at the top of the page and add the files you want to upload.

As an aside, if you want a nice programmable way to upload files, install this aws shell script and maybe use this automagical hacky upload script of mine. You can also use one of the graphical clients like 3Hub.

Now go back to the S3 console buckets list and click on the magnifying glass next to the bucket name. Look to the right side of the page and select Static Website Hosting from the properties. Click Enable website hosting, write index.html to the Index Document field and click Save. Almost online now! You can see the URL for the bucket endpoint above the website hosting toggling. But if you try to visit the bucket endpoint URL now, it will give you an access denied error.

To make the site publicly visible, we need to edit the permissions for the bucket. Click on Permissions under the bucket Properties. Now click on Add bucket policy and paste in the following policy (remember to change MYBUCKET to the name of your bucket).

{
  "Version":"2008-10-17",
  "Statement":[{
 "Sid":"AddPerm",
        "Effect":"Allow",
   "Principal": {
            "AWS": "*"
         },
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::MYBUCKET/*"
      ]
    }
  ]
}

Click on Save and then the blue Save button. Done! We're online! You can go to the bucket endpoint URL now and see your site load.

Using your own domain with Route 53

To use your own domain for the site, you can create a CNAME record from www.your_domain to the bucket endpoint URL. Now requests to the www.your_domain go to the bucket, zing! To make the root domain (your_domain with no www) go to the bucket as well, you either have to use Amazon's Route 53 to host your domain's DNS records or (if your DNS provider supports it) set up a redirect page to the www.your_domain from the root domain.

To use Route 53 for hosting your domain's DNS, go to the AWS Console and select Route 53 from Services. Click on Create Hosted Zone, enter your domain name and click on the Create button at the bottom of the form. Ok, now see the four server names in the Delegation Set? Go to your domain registrar and set those servers as the name servers for your domain.

Now tick your hosted zone to select it and click on the Go to Record Sets button. Click on Create Record Set. Leave the subdomain field empty, create an A-record, set Alias to yes and pick your bucket. Now requests to your domain will be served from the bucket. To make www.your_domain go to the bucket as well, create a CNAME record that points to your_domain.

Content delivery network using CloudFront

Let's turn on the CDN now. Go to Services in the AWS console and click on CloudFront. To create a CDN for your bucket, click on Create Distribution. Select Download as the type of the distribution. Type the name of your bucket into the Origin Domain Name field and pick your bucket from the list of completions. Most of the form is alright as-is, so scroll down to Distribution Settings. Enter cdn.your_domain as the CNAME. Set default root object to index.html. Scroll to the bottom of the page and click Create Distribution.

To set up the cdn.your_domain subdomain for the CloudFront distribution, copy the distribution domain name (click on the [i] -button if you're in the list of distributions) and create a new CNAME record that directs cdn.your_domain to the distribution domain name. There we go, your CDN should be live now.

Now when you have images on your website, remember to use point them to your CDN server for best loading performance. Instead of src="http://my_domain/image.jpg", use src="http://cdn.my_domain/image.jpg". The CDN works best for content that change rarely if ever. For frequently changing files it's best to use regular S3, otherwise your edits take anywhere from a few minutes to an hour to appear on the site.

If you need to force a file to be reloaded on the CDN, you can go to Distribution Settings for the distribution (the [i]-icon). On the settings panel, go to the Invalidations tab. Click on Create Invalidation and enter the filenames in the bucket that you want to invalidate. The invalidation takes a few minutes to work and forces the CDN to refresh the invalidated files. You can do it a couple times a month for free, but if you do it a lot it's going to start costing money.

Using CSS to make printed links readable

The problem: When you print your fancy HTML resume, the links don't show their URLs.
The solution: CSS!

Here's a link with a special print stylesheet. If you try to print this page, you'll see something like this: a link.

This magic trick uses a couple of different features in CSS. First of all, it uses CSS media types to apply a different stylesheet to printed documents. Second, it uses the :after selector to inject some content after each link. Finally, it uses the new CSS attr()-function to fill the :after content with the href of the link.

Putting all of the above together, we get a stylesheet that adds the href of a link after it, but only in printed documents. Here's what my stylesheet looks like:

@media print {
  a:after {
    content: "[" attr(href) "]";
    font-size: smaller;
    position: relative;
    top: -0.1em;
    left: 0.25em;
    padding-right: 0.15em;
    display: inline-block;
    color: black;
  }
}

Using Swiffy to create HTML animations in Flash

Introduction

The above animation was drawn in Flash but runs in pure HTML5, so it works on your mobile as well. Go on, try it out! Magic, no? Keep reading to find out how to make your own HTML animations in Flash.

First off, get Flash. The easiest way is to get a Creative Cloud subscription and download it from there. Done? Ok. Now, draw your animation. Don't know how? No problem.

Creating your animation

Here's a five-line tutorial to creating Flash animations: Create a new ActionScript 2.0 project, go to the timeline pane, click the onion skin button (looks like two squares), hammer F6 to create new keyframes, use comma and period to move back and forward in the animation, use the brush tool to draw each frame. For more details, you could check out this Adobe tutorial for Flash basics, Drawn to Life for animation lessons, or for more advanced workflow, the Foundation Flash Cartoon Animation book.

Installing the Swiffy extension

Go to the Swiffy project page, download the Swiffy Extension and open it. The extension opens in the Adobe Extension Manager, which walks you through the installation process. Now the next time you open Flash, you should have an "Export to HTML5" menu item in the Commands menu.

Exporting your animation

To export your animation, go to the Commands menu and click on "Export to HTML5". You get a small HTML file with your animation in it, ready for use.

Embedding your animation on your website

The easiest way to use your animation is to put it in an IFRAME. The name of the Swiffy animation file is <your animation name>swf.html, so if you had a file MyAnimation.fla, the HTML file would be MyAnimation.swf.html. And to use it on your page you'd make an IFRAME like this <iframe src="MyAnimation.swf.html" width="500" height="400">.
As the animation is now plugin-free, all the usual CSS transforms and animations should work perfectly on it.

Done!

Now go forth to make your own HTML animations and wow the world!

The source is available on GitHub.

Why HCO?

The question is, why are you primarily made out of hydrogen, carbon and oxygen? Wouldn't some other combination do as well? Hydrogen is understandable, right. It's the lightest and most common element in the universe. So it makes sense that you've got a lot of hydrogen in you. But carbon and oxygen?

Carbon has an atomic number of 6. Hydrogen has an atomic number of 1. Why jump all the way to 6 instead of using one of the elements between? Let's look at them in order. Number two is helium. Helium is a noble gas and doesn't really react all that much. So it's unlikely that you would have much helium bound into your molecules. Number three is lithium. Lithium nuclei verge on unstable, so they get broken easily. For that reason, there's not much lithium around in the solar system. Number four is beryllium, another rare element that's produced primarily through cosmic rays punching heavier nuclei and knocking out protons. It appears in stellar nucleosynthesis, but gets fused away rapidly. Number five is boron. Boron is only produced through cosmic ray spallation, so it's very rare.

Then we get to number six, carbon. Carbon is the fourth most common element in the universe, and can form a massive amount of different compounds. It's produced in stellar nucleosynthesis by the triple-alpha process where two helium nuclei fuse into a highly unstable beryllium nucleus, followed by a third helium nucleus fusing with the beryllium to produce a carbon nucleus. Additionally, if a fourth helium nucleus fuses with the carbon nucleus, they produce oxygen. If carbon gets fused with a hydrogen nucleus instead, the result is nitrogen. Much of the carbon gets further fused into neon, which breaks up into helium and oxygen in neon-burning conditions.

So you get the five most common elements: hydrogen, helium, oxygen, carbon and nitrogen. Helium is not very reactive, but the other four are. And so you too are made up of hydrogen, oxygen, carbon and nitrogen, in that order (by atomic count).

The funny way to think about it is that plants and animals are solids made out of gases. Burn hydrogen and oxygen to get water, add in some carbon dioxide and nitrogen and bake in sunlight.

[Sources: Wikipedia]

Carbonated air

[copypasta from G+]

The problem is one of controlling the amount of carbon in the atmosphere. Which would be a very handy technology to have. Bye bye ice ages, etc.

There was a bunch of carbon under the ground. People dug it up and put it into the air by coupling it with oxygen, creating an airborne CO2 molecule and releasing a decent amount of heat in the process. The amount of carbon moved from underground into the atmosphere is around 10 GT per year, and it's rising as more and more people want to have heat and heat-byproducts like electricity. A small portion (~2.5%) of CO₂ is created in the production of concrete, where the shells of long-dead marine organisms are decomposed from CaCO₃ to CaO + CO₂.

To break the carbon away from the CO₂ molecules, you'd probably have to expend more energy than the act of putting them together released. The other option is to move the CO2 out of the atmosphere.

To move the CO₂ out of the atmosphere, we have to separate it from the rest of the air and move it into a place where it can't escape from. To successfully do this, we have to move at least as much carbon out of the atmosphere as we're putting in there.

Trees are one option. A tree is mostly solidified air and water. It takes CO₂ from the atmosphere and with the power of sunshine turns it into cellulose, growing a little bit in the process. One square kilometer of forest generates around 300 cubic meters of tree biomass per year, which contains around 75 tons of carbon. To capture 10 GT of carbon per year, we'd have to plant 133 million square kilometers of new forest and bury all the new growth back underground. The land area of the world is 148 million square kilometers.

Another option is chemical weathering to bind the CO2 into silicate rocks. This happens naturally and triggers ice ages. But it's kinda slow and requires exposing a whole lot of rock.

These guys http://pubs.acs.org/doi/full/10.1021/es0701816 propose a method to do a sort of oceanic acid switch. Put the CO₂ into the ocean and take HCl out so that the ocean acidity doesn't change. Then get rid of the HCl by using it to weather silicate rocks, a reaction that's much faster than the CO₂ weathering. The problem here is that it takes 100-400 kJ per 12 grams of carbon. To take out 10 GT of carbon per year would use 2.5-10 TW of energy (or 15-60% of the world's annual energy production. Which might be a useful number for an atmospheric carbon tax.)

Anyway, the stuff is up there and the current biosphere can't use it up fast enough. Industrial-level use of carbon put it there, and it's going to take an industrial-level solution to get it back.

The really nice solution would be a chemical reaction that releases energy and binds CO₂ into a heavier-than-air compound that's easy to store. Like http://pubs.acs.org/doi/abs/10.1021/jp205499e . Then you could take the CO₂ exhaust, react it further to generate more energy, and put the solid exhaust into a pile. The problem with the Li₃N + CO₂ reaction is that lithium is pretty rare. Total worldwide production is measured in thousands of tons, compared to the billions of tons required for getting rid of CO₂.

[new words]

You could also react CO₂ with something else to produce a solid exhaust. Photosynthesis turns CO₂ and water into sugar and oxygen. Another possibility might be burning magnesium in CO₂, producing MgO and carbon soot, CO₂ + 2Mg => 2MgO + C.  The resulting MgO turns to MgCl₂ + H2O in HCl, which can be electrolysed to separate out the magnesium. The captured magnesium can be used to burn the next batch of CO₂. Anyway, the energy required to electrolyse the magnesium is likely going to be more than the energy released in burning the C and Mg in the first place. Say, the electrolysis might require around 18 MJ per kg of Mg. You need 2Mg @ 24 g/mol to burn 1C @ 12g/mol, or about 40 Gt of Mg to burn 10 Gt of C. At that kind of energy use, you'd need around 22 terawatts for the electrolysis. Global energy production is around 15 TW, natch.

As for usable liquid exhausts, CO₂ reacts with hydrogen to produce methanol. Methanol is a fuel and can be burned to produce CO2. This is the basis of Methanol Economy.

Other alternatives include capturing CO₂ at the factory pipe, using a portion of the generated power to store the CO₂ in a tank. Where the tank may be the bottom of the ocean or a drilled gas deposit, as you're going to need a lot of volume. 10 GT of carbon means 36 GT of CO₂. Stored as uncompressed gas, 36 GT of CO₂ would take 18 thousand cubic kilometers of space. If you freeze the CO₂ solid, it'd still take up 23 cubic kilometers. As liquid, around double that. The biggest LNG storage tank in the world is 200,000 cubic meters. You'd need to build 115,000 of those every year to fit 23 cubic kilometers of solid CO₂.

Deep ocean waters contain something like 38,000 gigatons of CO₂. You could pump all the fossil carbon in the world – around 1,000 gigatons – there and cause just a 3% increase. That's kind of a silly way to go about it though. Carbon is valuable. Today, 90% of the world's energy production is from carbon oxidation (France is the major anomaly here, they're producing 80% of their electricity with nuclear power.) Likewise, control over atmospheric carbon is valuable. Ice age coming? Crank up the CO₂. Too much heat in the atmosphere? Sequester some away.

Dealing with carbon is going to require a lot of energy though. You'd want to build a lot of wind, solar or nuclear to produce enough energy to power the carbon capture mechanisms. In the long term, hydrocarbons might work as a battery technology for continuable energy production. Continuable? Why yes, there's a limited amount of carbon readily available. Putting it all into the atmosphere or into the oceans isn't really going to help you keep burning it. Putting the carbon into trees and relying on tree-driven solar power to turn it back into burnable carbon requires lots of trees. In 2010, we moving 9 Gt of carbon into the atmosphere. The current estimated worldwide reserves of carbon are around 800 Gt. The carbon gasification growth rate between 1990 and 2010 was 2% annually. At that rate, all the carbon reserves known to energy companies would be up in the atmosphere and down in the oceans by 2060.

Hi-res trouble

Retina displays, mobile phones, zoomable browsers. Whatever you call it, the days when you could assume a single image pixel to be displayed on a single display pixel are gone.

Nowadays a normal web site has images that are too big for mobiles and too small for hi-res desktops. The mobile shows your 800x600 image on 588x441 display pixels and the hi-res desktop shows it on 1600x1200 display pixels.

And it's not just images. The <canvas> element suffers from the same issues. Safari renders the <canvas> at display resolution and scales down when zooming out, Chrome uses a layout resolution <canvas> that gets scaled to display resolution. By comparison, SVG scales gracefully.

The issue with <canvas> is that if you think of it as a pixel drawing surface, you think layout pixels should be drawing surface pixels. If you think of it as a vector drawing surface with some pixel manipulation commands, you think display pixels should be drawing surface pixels.

What I'd like to have as a web developer is a way to not care. I'd just make my website look good on tablets and desktops using <img src="foo.bar"> like always and use getImageDataHD for hi-res <canvas> pixel manipulation. For mobiles I'd have to make a custom UI as always, but I'd like to use the same photos as on the large-screen site.

Technology-wise I'd want the browser to load enough of each image to fill all the display pixels with at least one image pixel. And stop loading there. For huge images, I'd like the browser to load only the portion of the image that's visible on the screen.

And this all should happen with a single HTTP request per image, have no bandwidth overhead and require no server-side support.

The single request requirement means that either the image element or the image filename need to contain enough information to load the image at the optimal size. The no bandwidth overhead requirement means that the loaded file should contain only the optimal size image. The requirement for no server-side support means that the image should be a static file or a directory.

The <picture> element and <img> srcset-attribute are ways to add more information to the image element. The problem with them is that I want to use my regular <img src="foo.bar"> and not type more stuff.</picture>

Making a custom image file format with multiple image sizes would get you <img src="foo.bar">. On the downside you either end up with bandwidth overhead from loading several versions of the image, or require two HTTP requests: one to load the list of image sizes, second to load the wanted image.

With server-side support the browser can send display resolution in the request and the server will pick the appropriate image to send back. That needs server-side support though.

If you have the image stored as a directory with multiple sizes of the image and tiled versions for large images, and you name the image versions by their display resolution, the browser can directly request the optimal resolution image. By having the image name contain the maximum image size, the browser can limit itself to loading only up to that resolution. For backward compatibility, the <img> src-attribute can point to a valid image inside the directory. If you implement that in JavaScript you end up with an extra request for the <img> src-attribute though.

Hosting static web pages on App Engine

http://github.com/kig/app-engine-demo-static

How to host your website on Google App Engine:
1. Sign up to http://appengine.google.com
2. Create a new application (I named mine webtest-12345).
3. Install the Python SDK https://developers.google.com/appengine/downloads
4. Create a new directory with an app.yaml file like this:
   https://github.com/kig/app-engine-demo-static/blob/master/app.yaml
   (replace webtest-12345 with the name of your app).
5. Create a subdir www/ and put your site there, remember to have index.html.
6. Start the Google App Engine Launcher and do "Add Existing Application...",
   pointing it to the directory with the app.yaml file.
7. Test locally.
8. When happy, click deploy.
9. Done! (Check it out: http://webtest-12345.appspot.com/)

If you want to have a more automatic experience, here's a small script:

  export MY_APP_NAME=your-app-name-here;
  git clone https://github.com/kig/app-engine-demo-static.git;
  cd app-engine-demo-static;
  sed -e "s/webtest-12345/$MY_APP_NAME/" -i '' app.yaml;
  appcfg.py update .

To host the site from your own domain:
1. Go to the Application Dashboard (easiest way is to click the Dashboard
   button in App Engine Launcher)
2. Go to Administration > Application Settings.
3. Go to Domain Setup and click on Add Domain...
4. If you're on Google Apps, enter your domain.
5. Otherwise click on "Sign up to Google Apps"
  5.1. Enter your details and optionally register your domain.
  5.2. Go through the rest of the sign up process.
  5.3. Create your website app with your new Google Apps account
       following the instructions above. Or juggle accounts (you need to be
       logged in to Google App Engine to add the app to your domain and you
       need to be logged in to Apps to accept the addition.)
  5.4. Done? Ok, let's continue!
6. Click the "Yes I want to add this app to my domain"-button.
7. Now you're on the Apps app settings page. Click on "Add new URL",
   enter www and click "Add".
8. If you registered your domain via Google Apps:
   Go to go to "Domain Settings" > "Domain Names" > "Redirect your naked domain"
   Continue >> I've completed these steps >> Save Changes
   (You don't need to change any settings at the DNS, they're all
    correct already)
8.1 Otherwise log into your DNS service provider and
   add a CNAME record from www.YOURDOMAINNAME to ghs.google.com and
   do the "Redirect your naked domain" bit above and in your DNS add
   the four A records for YOURDOMAINNAME. Click Save Changes on the
   Google Apps page.
9. Done! (http://webtest-12345.com)

Wait for a couple minutes for all the DNS changes to settle.