content: rename articles to reinforce convention of short URLs

The Go blog started out on Blogger
(http://web.archive.org/web/20100325005843/http://blog.golang.org/).
Later, we moved to the current self-hosted blog server
with extra Go-specific functionality like playground snippets.

The old Blogger posts have very long URLs that Blogger chose
for us, such as "go-programming-language-turns-two" or
"two-go-talks-lexical-scanning-in-go-and", predating
the convention of giving posts shorter, more share-friendly,
typeable names.

The conversion of the old Blogger posts also predated
the convention of putting supporting files in a subdirectory.

The result is that although we've established new conventions,
you wouldn't know by listing the directory - the old Blogger
content presents a conflicting picture.

This commit renames the posts with very long names
to have shorter, more share-friendly names, and it moves
all supporting files to subdirectories. It also adds a README
documenting the conventions.

For example, blog.golang.org/go-programming-language-turns-two
is now blog.golang.org/2years, matching our more recent birthday
post URLs, and its supporting files are moved to the new 2years/ directory.

The old URLs redirect to the new ones.

Change-Id: I9f46a790c2c8fab8459aeda73d4e3d2efc86d88f
Reviewed-on: https://go-review.googlesource.com/c/blog/+/223599
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>

1 files changed, 74 insertions, 0 deletions

diff --git a/content/heroku.article b/content/heroku.article
new file mode 100644
index 0000000..2aa75c2
--- /dev/null
+++ b/content/heroku.article
@@ -0,0 +1,74 @@
+# Go at Heroku
+21 Apr 2011
+Tags: guest
+Summary: _This week’s blog post is written by_ [_Keith Rarick_](http://xph.us/) _and_ [_Blake Mizerany_](http://itsbonus.heroku.com/), _systems engineers at_ [Heroku](http://www.heroku.com/). _In their own words, they "eat, drink, and sleep distributed systems." Here they discuss their experiences using Go._
+OldURL: /go-at-heroku
+
+Keith Rarick
+
+Blake Mizerany
+
+##
+
+_This week’s blog post is written by_ [_Keith Rarick_](http://xph.us/)
+_and_ [_Blake Mizerany_](http://itsbonus.heroku.com/),
+_systems engineers at_ [Heroku](http://www.heroku.com/).
+_In their own words, they "eat, drink, and sleep distributed systems." Here they discuss their experiences using Go._
+
+A big problem that comes with building distributed systems is the coordination
+of physical servers.
+Each server needs to know various facts about the system as a whole.
+This critical data includes locks, configuration data,
+and so on, and it must be consistent and available even during data store failures,
+so we need a data store with solid consistency guarantees.
+Our solution to this problem is [Doozer](http://xph.us/2011/04/13/introducing-doozer.html),
+a new, consistent, highly-available data store written in Go.
+
+At Doozer's core is [Paxos](http://en.wikipedia.org/wiki/Paxos_(computer_science)),
+a family of protocols for solving consensus in an unreliable network of unreliable nodes.
+While Paxos is essential to running a fault-tolerant system,
+it is notorious for being difficult to implement.
+Even example implementations that can be found online are complex and hard to follow,
+despite being simplified for educational purposes.
+Existing production systems have a reputation for being worse.
+
+Fortunately, Go's concurrency primitives made the task much easier.
+Paxos is defined in terms of independent,
+concurrent processes that communicate via passing messages.
+In Doozer, these processes are implemented as goroutines,
+and their communications as channel operations.
+In the same way that garbage collectors improve upon malloc and free,
+we found that [goroutines and channels](https://blog.golang.org/2010/07/share-memory-by-communicating.html)
+improve upon the lock-based approach to concurrency.
+These tools let us avoid complex bookkeeping and stay focused on the problem at hand.
+We are still amazed at how few lines of code it took to achieve something
+renowned for being difficult.
+
+The standard packages in Go were another big win for Doozer.
+The Go team is very pragmatic about what goes into them.
+For instance, a package we quickly found useful was [websocket](https://golang.org/pkg/websocket/).
+Once we had a working data store, we needed an easy way to introspect it
+and visualize activity.
+Using the websocket package, Keith was able to add the web viewer on his
+train ride home and without requiring external dependencies.
+This is a real testament to how well Go mixes systems and application programming.
+
+One of our favorite productivity gains was provided by Go's source formatter:
+[gofmt](https://golang.org/cmd/gofmt/).
+We never argued over where to put a curly-brace,
+tabs vs. spaces, or if we should align assignments.
+We simply agreed that the buck stopped at the default output from gofmt.
+
+Deploying Doozer was satisfyingly simple.
+Go builds statically linked binaries which means Doozer has no external dependencies;
+it's a single file that can be copied to any machine and immediately launched
+to join a cluster of running Doozers.
+
+Finally, Go's maniacal focus on simplicity and orthogonality aligns with
+our view of software engineering.
+Like the Go team, we are pragmatic about what features go into Doozer.
+We sweat the details, preferring to change an existing feature instead of
+introducing a new one.
+In this sense, Go is a perfect match for Doozer.
+
+We already have future projects in mind for Go. Doozer is just the start of much bigger system.