In Thinking, Fast and Slow, Daniel Kahneman breaks down thinking into 2 modes. The slow mode is a deliberate and conscious mode; it’s the kind of thinking you do when you’re in control and are accutely aware of the choices you’re making. The fast mode, is a “reactive” mode driven by our nature and our insticts; it’s the kind of thinking you do when you need to quickly asses a situation and react to it immediately.

Slow thinking, then, is the kind of thinking you do when deciding what vehicle to purchase. Fast thinking, is the kind of thinking you do when you wake up at night and need to go to the bathroom.

And here, again, is the reason why I half-wish compilers were slower. Writing code is not the kind of task you can do in fast thinking mode. Even with years of prior experience writing software, you can’t code thinking fast.

Writing software is a tough beast: it takes a lot of research, discovery, and prototyping. Clearly, writing code is slow thinking.

It’s easy, however, to feel like systems you’ve developed before are similar to the software you’re currently writing. It’s tempting to think you can just go with prior knowledge, make some assumptions, do things just like you’ve done them before. It’s easy to think you can use some heuristics and think fast.

But you can’t. There are too many details and too many dependencies that you need track. There are too many unknowns and too many side effects that you need to consider. In other words, you’ll never achieve quality software by thinking fast.

So, just take a minute and slow down. Think. Design. Prototype. Test. Then throw away all the code you’ve written and start all over again. It’s surprising how much even just a little design helps.

Even if all you do is grab some paper and draw a couple of diagrams; even if all you do is just talk to a few people about some of your ideas, you’ll be better off.

We need to reason about the code we write; we need to think slowly and carefully about the changes we make.

And if compilers were slower, we might just be forced to think slow. :)

Most of the guidance you’ll find on the internet regarding REST, however, focuses on GETs (reads) and POSTs (inserts). Today, therefore, I want to offer advice on how to do updates.

Gimme The Skinny

Let the consumers of your API update resources by appylying deltas instead of forcing them to replace the entire resource.

I know this isn’t strictly related to REST APIs; it’s more of a data API recommendation, but partial updates really do work better than full resource updates.

Why? Well, there are several reasons of course, but most of them revolve around:

• Partial updates ease update concurrency problems.

• Partial updates let you more accurately express the changes you want to make and this simplifies your code.

One final recommendation regarding REST: use the HTTP PATCH method instead of PUT to do partial updates. PATCH was specifically introduced in March 2010 to allow partial resource modification.

Gimme More Detail

OK, you’ve decided to keep reading (thanks!). So here’s the deal: Full resource updates (replacements) have the following problem:

Pretty ugly, huh?

There’s a good chance the user wasn’t even trying to update the “conflicting” fields. And if he was updating the conflicting fields, does the knowledge that the data changed matter to him? Why are we showing him an error? What is he supposed to do about it? Really, there’s not a lot of good solutions here.

And then there’s even more problems. As soon as your user can make changes you’re going to get requirements like the following:

1. When the customer address is updated, notify accounting.
2. Make sure only fields x, y and z are updatable on Foo.
3. Keep a history of changes on fields a, b, and c on Bar.

How are you going to do that if all you get from you client is an entirely “new” resource? Are you going to diff it and derive what changed? That’s hard and usually ends up being really messy.

Again, just have your API consumers be explicit about the fields they’re changing and all your problems will go away, your life will be better, and your co-workers will be super impressed by your simple and intelligent code. :) Just kidding, you’ll never impress another programmer, so don’t even bother. :P

Gimme Me Some Code

You should check out the samples and the tests in Voodoo. Scott Brown and I recently added some cool code to support partial enitity with automatic validation in Jersey.

We decided to take a rather informal representation of the data by accepting a dictionary where only the fields to be updated are present. Our Jersey endpoint therefore looks something like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

@Path("/person")
public class PersonResource {
    // Other endpoints omitted.

    @PATCH
    @Path("/{id}")
    public Response updatePerson(@PathParam("id") String id, @Editable(type = Person.class,
        fields = {"name", "age"}) Map personUpdates) {
        // Note: In Voodoo @Editable makes sure only the editable
        // fields defined here are being updated.
        // Voodoo also validates the values passed according to the
        // 'javax.validation` annotations on the Person class.

        // Build your query to update person here.
        // You can also raise events, based on the properties being updated here.

        // It's a good idea to return the latest representation of the entity.
        Person updatedPerson = personStore.getById(personUpdates.get(id));
        return Response.ok(updatePerson).build();
    }
}

As you can see, the approach is rather straightforward. I think the @Editable annotation actually turned out pretty well: it abstracts away all the validation code from your endpoint.

A few parting thoughts

Of course not everything is perfect with this approach; there are a few minor drawbacks. Chief among these is the fact that there’s a good chunk of tooling that doesn’t quite support PATCH yet.

Backbone for example, has recently added support for PATCH (in IE) but hasn’t put it into any of their releases yet. We’ve had similar problems with Swagger; the method isn’t really supported there either.

One other minor consideration is that if you don’t really need any intelligence around what’s changing, the code to do a full resource update is usually simpler.

So there you go: if you want to be awesome, start using PATCH and supporting partial resource updates. Otherwise, you can keep doing the same old thing you’ve been doing. :)

Well, I have. This is what I discovered about the git object store.

In the begining there was nothing.

Not really. In fact, there’s quite a bit of stuff in an empty repo. On your command line, create a new repo and list its contents.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

# Create the repository
$ mkdir mygitrepo && cd mygitrepo
$ git init
Initialized empty Git repository in /Users/earaya/Projects/gitrepo/.git/

# Show all files
$ find .
.
./.git
./.git/config
./.git/description
./.git/HEAD
./.git/hooks
./.git/hooks/applypatch-msg.sample
./.git/hooks/commit-msg.sample
./.git/hooks/post-update.sample
./.git/hooks/pre-applypatch.sample
./.git/hooks/pre-commit.sample
./.git/hooks/pre-rebase.sample
./.git/hooks/prepare-commit-msg.sample
./.git/hooks/update.sample
./.git/info
./.git/info/exclude
./.git/objects
./.git/objects/info
./.git/objects/pack
./.git/refs
./.git/refs/heads
./.git/refs/tags

As you can see, there’s quite a bit of stuff there to begin with.

Something we learn right off the bat is that Git supports hooks. Take a look at some of the samples. At work, we use a pre-commit hook to run our linting before letting you commit. But I digress, I want to talk about the object store.

You’ll see that initially, the objects directory is empty.

So, let’s create a git object. In order for this to work, you have to type the commands as shown:

1
2

$ echo "git rocks" > test.txt
$ git add test.txt

As a result of adding the above object you should now see:

1
2
3
4
5
6

$ find .git/objects
.git/objects
.git/objects/f6
.git/objects/f6/8ce0a31a54e37649ee417d60e90911258f1043
.git/objects/info
.git/objects/pack

And then there was a (SHA1) hash

You might now be wondering how I was so confident you’d get the same output I got on my machine.

The answer is simple: Git is, at its core, just a key-value store. Git doesn’t care what you call your objects; Git only cares about the content of those objects.

To store an object, Git first peforms a few operations on the data. One of these operations is to calculate the SHA1 hash of the data and then store the data in the object store with a filename representing the hash.

At this point we have to make a brief but important aside. SHA1 has two properties that make it really useful for Git’s use:

1. It’s extremely unlikely that 2 different objects will have the same hash value.
2. Identical objects will always the same hash representation.

And so, 8ce0a31a54e37649ee417d60e90911258f1043 represents the SHA1 hash of “git rocks”. That’s how I knew you’d get exactly the same output I got.

And finally, there was a tree.

So now that our file is tucked away in the object store, we have to wonder: What happened to its filename? After all, Git wouldn’t be that useful if it didn’t preserve folder structure and if it didn’t let us find our files by name.

Git tracks pathnames through a tree.

Go back to your command line and type:

1
2
3
4
5
6
7
8
9
10

$ git write-tree
81cbaf28bc31ce9218d51b685e35a08bfea99599
$ find .git/objects
.git/objects
.git/objects/81
.git/objects/81/cbaf28bc31ce9218d51b685e35a08bfea99599
.git/objects/f6
.git/objects/f6/8ce0a31a54e37649ee417d60e90911258f1043
.git/objects/info
.git/objects/pack

git write-tree (a low level command) saves the state of the index (your staged files) to the object store. Thus, we now see a new object in the store: .git/objects/81/cbaf28bc31ce9218d51b685e35a08bfea99599. This new object is our tree.

Once you peek into the tree object, it’ll immeidately make sense. You’ll be able to see the file contents by typing the following git command:

1
2

$ git cat-file -p 81cbaf
100644 blob f68ce0a31a54e37649ee417d60e90911258f1043    test.txt

You might already have guessed it, but the first section of the file, the 100644 represents the file permissions (in octal). f68ce0 represents the filename of the blob in the store, and test.txt is the filename.

Directory hierarchies are represented in a similar manner, of course.

Conclusion

And there you have it folks. That’s pretty much all there is to how Git stores objects. Pretty simple, huh?

I think it’s amazing how Linus built such a powerful and useful system by elegantly using a simple hashmap. I wish my software was more like Git.

I hope you too gain an appreciation for using simple constructs in your own code.

In the last few years we’ve seen a shift to the “cloud”. With that, there has been a resurgence of the web. We’re now doing things with HTML and HTTP that no one would have thought possible just 5 years ago. We now render data on the client, we push data from the server to the browser to have real time interactions like a native application would. Heck, we can even do 3D rendering on the browser… and if you have a modern browser, it works well!

In a few words, we’re doing what Java Applets promised to do but never accomplished.

This re-birth of the web, however, has been bumpy. Developing for the browser is plagued with problems. You have to target multiple (old) browsers, on multiple OSes, with multiples displays; you have to deal with disparate hardware, internet connections, etc. I think you get the point: you really don’t know where and how your app is going to run. And to make all of this worse, the tooling for writing browser applications is still maturing; there’s not a lot of help out there.

Imagine, for example, if you had to write a Java server application and you didn’t have a good compiler; or if you had to add a bunch of conditionals to detect what OS you’re running on – it’d be crazy, right?

But that’s not even the worse of it; imagine Java the language provided no mechanism for modularizing your code: not JARs, no classes, no nothing. And of top of that everything was globally scoped. Scary, huh?

Well, to some extent that’s the situation we find ourselves in when we write Javascript applications. Javascript has no supports for modules. And of top of that, everything in the browser is globally scoped. Now, I’m aware that we developers have been playing games for years to diminish the global scoping problem, but we really haven’t had a good solution. Unitl now, at least. Now we have AMD… and it changes everything.

AMD stands for asynchronous module definition. The goal of the AMD format is to provide a solution for modular Javascript that we can use right now (while we wait for harmony).

The genius in AMD is that it proposes a format where both the module and its dependencies are asynchronously loaded. If you’re working on the browser, the async nature of AMD provides advantages over other module systems (such as CommonJS) that really make it enjoyable to code in Javascript.

But enough talk, let’s get to some code. I don’t want to write a full tutorial on AMD, so the code samples will be brief. I’m just hoping that when you’re done reading this, you won’t write a single line of code withouth using RequireJS.

Here’s how you define a module:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

define(['jquery', 'backbone'], function ($, Backbone) {

  // At this point your dependencies are loaded (jquery and backbone).

  // Let's do some setup. Anything here is private to the module.
  var privateVariable = 5;

  // This what consumers of your module will get when they require your module.
  return Backbone.View.extend({
    id: privateVariable,
    initialize: function () {
      // Some view init code.
    },

    // The rest of your public methods.
  });


});

I don’t know about you, but the first time I saw an AMD module I immediately fell in love. Finally I saw an easy way to have private members. Finally there was a cleaner way to scope modules and their dependencies. I could go on and on, but I think the benefits I’ve listed, should be enough to convince you.

Or at least, I hope this has at least made you aware of AMD and piqued your interest. Writing Javascript apps on the browser doesn’t have to be a pain anymore. In fact, I rather enjoy.

I know, however, I haven’t done this topic justice. Please go look at the RequireJS site and look at the samples and the documentation – espeically the the optmizer section. Go look at this post by James Burke where he talks about the many reasons developers are now using AMD. And then when you’re done reading that, come join the fun.

My initial reaction was to dismiss Merrick’s statement as “just marketing fluff”. However, after playing with the language a bit, I’m convinced Scala is really the way forward on the JVM.

As a side note – if you can take the Functional Programming Principles In Scala course by Martin Odersky on Coursera, I’d highly recommend it. I just finished the class and really enjoyed it. The course is a little on the tough side (specially the last 3 assignments), but it’s a great introduction to Scala and to functional programming.

Why Scala Matters

The JVM is a superb platform. It runs everywhere and it’s just solid.

Furthermore, the Java ecosystem is fantastic. Everything from the IDEs, to the build tools, to the Servlet containers, to the OSS projects that run on Java are first class, well documented and well supported by a fantastic community of excellent developers.

Java the language, however, has failed to keep with the times. The lack of anonymous functions and closures, the lack of type inference, the lack of object and array literals, and the lack of many other constructs make the language feel archaic. Unfortunately it’s not just that the language is arcane, it’s verbose and it gets in the way; it’s not that all of this is annoying, it gets in the way of productivity. If often wish C# would run on the JVM.

In summary, the JVM is a great platform, but it just needs a better statically typed language.

How Scala Truly Scales

The thing about Scala is that it has a low barrier to entry. If you’re not used to functional languages, you can write imperative code and get started anyhow. Classes are also first class citizens, so if you’re coming from Java, you’ll feel right at home.

If you’ve written C# and used some of the newer features such as LINQ, anonymous functions, etc., the transition will be even easier.

And then, when you’re starting to get comfortable, you can write truly idiomatic Scala. It’s simple, uncluttered, and succinct. Here’s a short sample:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

  /**
   * This function decodes the bit sequence `bits` using the code tree `tree` and returns
   * the resulting list of characters.
   */

  def decode(tree: CodeTree, bits: List[Bit]): List[Char] = {
    def decode0(tree0: CodeTree, bits: List[Bit], acc: List[Char]): List[Char] = {
      tree0 match {
        case Leaf(c, w) => decode0(tree, bits, acc :+ c)
        case Fork(l, r, cs, w) => {
          if (bits.isEmpty) acc
          else if (bits.head == 0) decode0(l, bits.tail, acc)
          else decode0(r, bits.tail, acc)
        }
      }
    }
    decode0(tree, bits, List())
  }

(Note, I’m not claiming to write idiomatic Scala. In fact, as mentioned before, I’ve just barely started using the language. This snippet, however, demonstrates some good features).

If you’re like me, it may take you a bit to get used to they syntax. In fact, I thought I’d never get used to the implicit returns and the optional semicolons – but now I wish I’d never have to type those extra characters ever again.

Pattern matching and case classes are a fantastic features. I wish more languages (I’m looking at you C#) would offer such capabilities. In the snippet above you can also see functions are first class citizens, and how to type variables.

Things you can’t see in the sample, but that are just as important:

1. The List class you see above, is immutable. This means most operations on it actually return a new list instead of mutating it.

2. Types are optional; if the compiler can figure out the type, you can omit it.

It’s hard to explain, but I felt like Scala was really forgiving and let me grow into the language. For example, as I learned, I realized more and more that I really didn’t need mutable types. This of course, has a nice side effect of making parallelization of your code much easier.

In summary Scala scales with you. As you learn the language, you can express more interesting thoughts in simpler ways. Furthermore, the language pushes to clean, elegant solutions.

Final Thoughts

If Scala required it’s own runtime, I’d have to say it’d be just another functional language. But because Scala runs on the JVM, and because it can use all the Java code you currently depend on, Scala really does have a bright future.

I hope in 5 or so years we’re all writing Scala instead of Java.

User Sign In

One of the cool things about using HMACs for authentication is that you can keep your current sign in process. Validate user credentials however you see fit, and then, upon credential validation, hand your user something like the following token:

<userId, timestamp, hmac(userId + timestamp)>

The idea behind this is that once a user has proved his identity, we can hand them the above token as an authentication code that will be able to prove their identity going forward. The client, of course, will have to submit the token on every subsequent request to the server so, if your client is a browser, you may want to consider sending the token down in a cookie.

A note of caution: If an attacker is able to intercept or sniff the token when sent to the client, all bets are off and this, and just about any other authentication scheme, provides no protection. Please make sure you encrypt your client connection when using the ideas describe here.

While you have to worry about safely delivering the token, you don’t have to worry about legitimate users trying to modify the token. This is because even though clients will have access to the token, they can’t recalculate the HMAC of the data handed to them; they don’t have the key that your server used to calculate the hash.

Request Authentication

Now that your client has the necessary token to make authenticated requests, all you have to do is verify the token. This is accomplished by recalculating the HMAC of the token they’ve sent you and comparing it to the one produced on your server for authentication purposes. Here’s some pseudocode to make the point clearer:

1
2
3
4

HmacToken clientToken = HmacToken.parse(stringWithTokenFromClient);
HmacToken serverToken = HmacTokenGenerator.generateToken(clientToken.getUserId(), clientToken.getTimestamp());

return clientToken.getSignature() == serverToken.getSignature();

You can adjust the above code to also validate the timestamp and reject the token if it’s too old (and require the user to sign in again), but you get the point.

One of the best things of using this idea for authentication is that you can now validate requests without keeping any sort of state: every request contains all the information you need to validate it. No need to keep any sort of session tokens around, and no need to do any kind of lookups; you’re completely stateless. Pretty awesome, huh?

Some Recommendations

Don’t write your own cryptography code. Use a well known (preferably open source) library to calculate your HMACs. It’s hard to get cryptography right, so this is an area were relying on the experience of experts is well worth it.

Also, make sure you have an effective key management and rotation strategy. If your HMAC key is compromised, you’re toast: people will be able to create tokens illegitimately. I’d recommend you generate a new random key every time you deploy so that no one has knowledge of it and it is changed often. If you can’t do that, at least make sure the key is never checked in anywhere in code and just very few individuals have access to it.

I really like this authentication scheme: the HMAC key is never sent to the client, so there’s no key sharing and negotiation to get wrong. Furthermore, with very few changes to any authentication process, you can get a stateless, distributed authentication mechanism that is simple to write and easy to understand.

Give this a try and let me know what you think. Or if you see any big gaping holes, please let me know.

The reason is simple: some people feel that using a char[] is safer since you can “wipe out” the array after you’re done with the data (eg. the password). String being an immutable type does not allow this precaution; once you’re done with the String it’ll live in memory until garbage collection decides to claim it at an undetermined time in the future.

The implication, of course, is that an attacker may read the contents of the memory before the String is garbage collected and steal the password.

This, however, seems a moot to me. Switching to a char[] does not really solve the problem; it only reduces the time window in which the memory contents are available to an attacker. This is even worse than security through obscurity; really, this is just giving up and pretending to do something to address the problem. I’ll also say that if someone is able to read the contents of your memory space, you have bigger problems than using a String for your password.

Nonetheless, there is one slight advantage in using character arrays for sensitive data: you’re less likely to accidentally print the contents of an Array (to a log, or console, etc.) than the contents of a String.

1
2

char[] secret = "Secret".toCharArray();
System.out.println("Value: " + secret);

The above code, for example, does not print “Secret”. Rather, it prints the @ character followed by the unsigned hexadecimal representation of the hash code of the object. This is because Array does not override Object’s implementation of toString, so you just get the default behavior (see documentation). Still, I don’t think this is enough “security” to warrant using a character array.

The real solution, would be to implement something like .NET’s SecureString. A SecureString object behaves a lot like a regular String object except that its memory contents are automatically encrypted. Furthermore, a SecureString instance is immediately discarded when no longer in use. This approach offers real security and it gives developers are more appropriate API when handling strings.

If it wasn’t for the fact that it sucks to handle strings as character arrays, I’d say that the marginal security benefits of using a char[] are worth it. But really, there’s no way to rationally justify this. Just keep using a String, or if you really care, find a good SecureString implementation.

It Rocks!

1. You can have your blog up and running in under 10 minutes. Furthermore, if you use GitHub pages to host your blog, you get a deployment process out of the box with very little effort.

2. The HTML template that Brandon Mathis has setup is fantastic. My favorite part about the template is how responsive it is, and how well it works in mobile devices. Go ahead, give this site a try on your phone; the template works really well there.

3. The product really makes it a joy for hackers to blog. I’ve never had so much fun setting up my blog and writing posts.

Yet

Howerver, there are a few things I wish were a bit different.

1. On version 2.0, it seems like JS is a second class citizen. Scripts are not compiled, minified, and stitched into a single file.

   I know there’s an effort to change in this in version 2.1, but I disagree with the direction Brandon has taken. He really should be using RequireJS.

2. I wish there was tighter integration with S3. There have been several pull requests to add this feature, but they have yet to be merged.

   It’d be nice, for example, to get a deployment process that also uploads gzipped files (sets the headers on S3 for them) and also sets reasonable cache headers for different file types.

   Little side note here: s3cmd is awesome. The sync command will compare the files you’re trying to upload and only upload changes. Can’t recommend it enough.

3. A matter of preference, but I wish Mustache or Handlebars was the templating language. Now, to be fair, I think this is a Jekyll dependency, so it’s not really an issue with Octopress directly.

The Veredict

If you love tinkering, Octopress is for you. You’ll have an awesome blog quickly and you’ll enjoy tweaking it to your heart’s content.

S3

The first thing you’ll have to do to host your static content is create an S3 bucket to upload your content. This is straight forward, but there are three things you must make sure are setup correctly:

1. Make sure the bucket’s name matches the URL you want to use. For example, for this blog, the bucket’s name is blog.earaya.com.

2. Enable website browsing.

   This is done by clicking the “Properties” button for your bucket (up on the right hand corner) and then clicking on the “Website” tab. You’ll then just have to check the “Enabled” checkbox, and choose your Index and Error Documents.

   

   This step allows you to create an HTTP endpoint through which your assets can be accessed. It’s important to note this endpoint as we’ll be using it later to setup CloudFront.

3. Setup a bucket policy allowing the “GetObject” action to anonymous users. You’ll want to make sure you do this at the bucket level so you don’t have to set ACLs for every new file you upload.

Again, this is done by clicking on the “Properties” button, then on the “Permissions” tab, and then adding the following bucket policy:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

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

It’s important not to miss this step as you’ll get an “AccessDenied” error on your documents if try to browse the website endpoint.

That’s it as far as S3 goes. You’re now ready to setup CloudFront.

CloudFront

The only thing worth noting here is that while you’re going through the wizard that creates your distribution, you DO NOT want to use your S3 bucket as your “Origin Domain Name”. Rather, you want to use the “Endpoint” URL you got while setting up S3 as described in Step 2 above.

When you’re done with the wizard, note the domain name for your CloudFront distribution. You’ll need it to setup DNS.

DNS (Route 53)

Add a CNAME, and point it to the domain name of your CloudFront distribution. This blog, for example, points “blog.earaya.com” to d31e45oz3360lh.cloudfront.net (which is what I got when I finished setting up my CF distribution as described above).

You don’t necessarily have to setup DNS on AWS; your domain name registrar can likely add a CNAME record and point it to the CloudFront URL as well.

I mostly ended up using Route53 because I felt like trying it out. Your registrar probably has decent DNS service, so you could just use that instead.

Performance Tips

S3, being just a store, won’t compress files for you. If you want to serve compressed content (which you should), you’ll have to jump through quite a few hoops to get that working. Look at the “Serving Compressed Files From Amazon S3” in this guide here.

Also, S3 won’t set any caching headers by default. You’ll have to make sure you set the appropriate headers manually on each file you want cached. The good news is that although setting this up is tedious, CloudFront will respect your caching headers and evict content appropirately.

Summary

Hopefully you’ve gotten a good idea of how to setup your static site on S3 and CloudFront. It’s really not hard to do at all.

Considering, however, that you can get a micro linux instance for free on EC2, I’d say it’s worth exploring using a good web server to serve your content instead of using S3. That way, you could get caching and compression for free.

I feel like my old blog just didn’t fit me anymore; I certainly don’t feel like I’m “a dotnet dude” anymore.

I’ve also been itching to build a blog just out of static files, host them on S3 and serve them through CloudFront. So I finally bit the bullet and got it all done; I’ll be writing a bit about how to host your own Octopress blog on S3 later.

One last thing: I’d like to thank Erik Zaadi for his awesome Solarized Octopress Theme; it’s a great theme, don’t you think?