I “think” better early in the morning, and again late in the evening – after I’ve had some down time (a nap or reading) to recharge. Now I understand why.
This is not the kind of outlier the United States should be.
Only $55,000.
The Strange Powers of the Placebo Effect →
He rides a bike across a rope. Unbelievable.
An iPad application for translating conversations. Very cool.
One of the primary reasons for switching to a static site generator was improved response time. Any site that relies upon dynamically created pages will be slower than one using static pages. The question is, “how much slower?”
Today on Hacker News there was a link to Coderholic and an article about Invaluable Command Line Tools for Web Developers.
One of the tools is Siege, a “HTTP benchmarking tool.” From the examples given in the article I realized I could quickly and easily compare two of my blogs to see the difference between static pages and dynamic pages.
This site, zanshin.net is now statically served. My cello blog, Solfège, is based on WordPress and is therefore dynamically served. Both sites are hosted on the same hardware at Bluehost
Installing Siege was simple with brew, just type:
$ brew install siegeWith Siege installed I first ran a test against the static site. The test simulates twenty (20) concurrent connections for thirty (30 seconds). Here are the results:
○ siege -c20 zanshin.net -b -t30s
** SIEGE 2.70
** Preparing 20 concurrent users for battle.
The server is now under siege...
HTTP/1.1 200 0.57 secs: 50339 bytes ==> /
HTTP/1.1 200 0.67 secs: 50339 bytes ==> /
HTTP/1.1 200 0.71 secs: 50339 bytes ==> /
... (cropped for brievity)
HTTP/1.1 200 1.75 secs: 50339 bytes ==> /
HTTP/1.1 200 6.05 secs: 50339 bytes ==> /
HTTP/1.1 200 2.80 secs: 50339 bytes ==> /
Lifting the server siege... done.
Transactions: 612 hits
Availability: 100.00 %
Elapsed time: 29.76 secs
Data transferred: 29.38 MB
Response time: 0.82 secs
Transaction rate: 20.56 trans/sec
Throughput: 0.99 MB/sec
Concurrency: 16.93
Successful transactions: 612
Failed transactions: 0
Longest transaction: 6.28
Shortest transaction: 0.53612 hits in 29.76 seconds, 100% of which were available.
Now here are the results against the dynamically served site:
○ siege -c20 cello.zanshin.net -b -t30s
** SIEGE 2.70
** Preparing 20 concurrent users for battle.
The server is now under siege...
HTTP/1.1 500 0.95 secs: 263 bytes ==> /
HTTP/1.1 500 0.65 secs: 358 bytes ==> /
HTTP/1.1 500 1.95 secs: 358 bytes ==> /
HTTP/1.1 200 2.07 secs: 30498 bytes ==> /
HTTP/1.1 200 2.10 secs: 30498 bytes ==> /
HTTP/1.1 200 2.98 secs: 30498 bytes ==> /
... (cropped for brevity)
HTTP/1.1 500 0.34 secs: 358 bytes ==> /
HTTP/1.1 200 5.39 secs: 30498 bytes ==> /
HTTP/1.1 500 1.28 secs: 358 bytes ==> /
HTTP/1.1 200 4.95 secs: 30498 bytes ==> /
HTTP/1.1 200 2.68 secs: 30498 bytes ==> /
HTTP/1.1 200 1.32 secs: 30498 bytes ==> /
Lifting the server siege... done.
Transactions: 98 hits
Availability: 37.40 %
Elapsed time: 29.09 secs
Data transferred: 2.91 MB
Response time: 5.50 secs
Transaction rate: 3.37 trans/sec
Throughput: 0.10 MB/sec
Concurrency: 18.54
Successful transactions: 98
Failed transactions: 164
Longest transaction: 9.93
Shortest transaction: 0.26Only 98 hits in 29.09 seconds, and only 37.40% availability. For those 98 successful hits there were 164 failed hits. It is worth noting that the number of bytes returned for the static site is 50,339 per transaction, whereas for the dynamic site is it only 30,498 – when the access was successful.
Having only just discovered this tool I cannot vouch for its accuracy or validity. But, seeing the results side-by-side like this makes a compelling case for static pages over dynamic pages, particularly if you have a high volume of visitors to your site.
There are any number of zsh tutorials and getting started guides, and this one is mine.
Zsh is an alternative to the venerable bash shell. It is a superset of the functionality included in bash along with some additional features that make it a very attractive choice.
Here’s how I installed zsh and set it up for use on my MacBook Pro. As always with Internet how-tos, proceed at your own risk, make back up copies along the way, and know that only you are responsible for wiping out all your files with an errant rm -rf / *.
Review your current bash setup. In my case I have three primary machines: my personal MacBook Pro, a work assigned MacBook Pro, and a work provided iMac. The work provided machines are still running Snow Leopard as my employer hasn’t yet sorted out buying mass licenses. My personal machine has been running Lion since the Saturday after it was released. In addition to these physical machines I have access to a number of servers and make use of several virtual machine images. These servers and VMs are all using some variant of Unix as there operating system.
Each of these environments has some derivate of a .bash_profile, .bashrc, and optionally a .bash_aliases file. Once upon a time these files were all the same, having started from the same source. Over time they have grown independently of each other. I started by examining the configuration on each machine I used and combining the differences into a set of master files, one each for .bash_profile, .bashrc, and .bash_aliases.
Once the master set was done I created a dotfiles directory in Dropbox and copied the files, leading dots and all, to that location. Next I created symbolic links in the home directories of each of my machines to the ur-files. Like so:
$ cd
$ ln -s /Users/mark/Dropbox/dotfiles/.bash\_profile .bash\_profile
$ ln -s /Users/mark/Dropbox/dotfiles/.bashrc .bashrc
$ ln -s /Users/mark/Dropbox/dotfiles/.bash\_aliases .bash\_aliasesNow all my machines have the same capabilities (bash-wise) as each other. Plus, changes made in one environment are immediately available elsewhere through Dropbox syncing.
Install oh-my-zsh. Most modern Unix-based operating system should support (if not outright have already) zsh. You can fiddle around with it from your current bash shell simply by issuing a “zsh” command at the prompt. This will create a minimally configured zsh environment. Or, you can install oh-my-zsh, which includes an extensive set of plugins, numerous themes, and an active community effort.
The oh-my-zsh installer is fairly slick as it looks at your current set up (primarily your PATH statement) and migrates it for you to the new .zshrc file. This is why Step One above pays off. Well, that and having a nice tidy bash configuration as a fall-back just in case you and zsh don’t take to each other.
Select a theme and customize. I made good used of this Intredia.com article about zsh to get my environment configured to my liking. I’m using iTerm and the Solarized Dark color scheme, and I liked the looks of the Soliah theme. Under my bash environment I had a two-line prompt with a leading blank line. Purists may squawk at the idea of using up three lines for each new prompt, but I find a cluttered console easier to read with a blank line before the prompt, a nice current working directory listed on line two, and a lonely “$” ready for a command on line three.
The default prompt that came with Soliah had a similar look, but without the extra leading line. I also changed some of the colors to suit my aesthetics. And I set up a right-prompt, something bash hasn’t got, to display which Ruby version was active for the current directory.
For lack of a better, more polished solution, I copied my aliases and functions from .bashrc and .bash_aliases so I would still have my shortcuts. Eventually I’ll go through these and make them more zsh-like.
Once I had my theme working and my .zshrc file configured I use the same Dropbox dotfiles directory I described earlier to share them between my machines and environments.
Explore. There are tons of goodies to explore in zsh. Try typing “..” instead of “cd ..”. Or “-” instead of “cd - “. The Intredia.com article article also has a table with quite a few new shortcuts and aliases to use.
Here is my oh-my-zsh theme file. It is “git aware” and when in a directory containing a Git repository displays useful information about the current state of the repository. The time calculation, which shows how long it has been since the last commit, is nice, but it does slow the prompts response down. I’m thinking about taking it out.
{% gist 1142716 %}
And here is my .zshrc file:
{% gist 1142739 %}
For the past several years my site has been produced by using a self-hosted instance of WordPress. WordPress is a wonderful tool, with hundreds of themes to choose from, dozens of plugins to add functionality with, and a massive community to draw support from. After converting zanshin.net to WordPress in December 2007 I started accumulating self-hosted and WordPress.com hosted sites. Currently I have or maintain six WordPress sites.
However I was ready for something different for this, my primary site. I wanted to fiddle with the look and feel without having to delve into the templates and PHP code that is the backbone of WordPress. I wanted something closer to the early days of this site when I hand rolled all the pages and used FTP to publish the results. In the past few months I’ve been reading more and more about “baked websites”, where baking means your site is served from a set of static pages rather than being assembled in a template after a flurry of database calls.
Brent Simmons wrote A plea for baked weblogs back in March 2011 where he talks about one of the biggest downsides to dynamically constructed websites, that of your site being overrun by enormous numbers of requests. Should you be fortunate enough (or unfortunate enough, depending on your view) to be linked to by a site with huge visitor volume, your MySQL database behind WordPress could become swamped resulting in your site being unavailable to anyone. Brent follows up with a second posting, More on baked blogs where he lists several sites that are baked, and some of the tools used to create a static site.
One of the tools in particular caught my eye, Jekyll. While I was fascinated by the idea I wasn’t quite prepared to abandon what I knew for something with much less of a safety net. Paul Stamatiou wrote a lengthy and very detailed How To: WordPress to Jekyll posting that convinced me that Jekyll, or something like it, was what I wanted for my site.
About three weeks ago there was a link on Hacker News about a new blogging framework for hackers called Octopress. Octopress is a framework around Jekyll. It does some of the low-level grunt work for you, and simplifies the process of getting everything setup and working. After downloading and installing Octopress and playing around with it for a couple of hours ten days ago, I decided to take the plunge. Over the last ten days I’ve created the site you are reading right now, complete with the now nearly 13 year archive of entries, in Octopress. There are still a few rough spots that need ironing out (font sizes being the biggest wrinkle), but I am very pleased with this next iteration in the life of Zanshin.net.
What started out as a hand rolled site in 1996 became a weblog in late 1999, and hand rolling morphed into Blogger and then MoveableType followed by WordPress and now (basically) hand rolling again.
Over the next couple of days I hope to put together a posting or two about the process I used to get from WordPress to Octopress, and some of the tools I used along the way.
Both the Haskell Free Library and Opera House and Büsingen am Hochrhein are somewhat geographically unique. The Free Library straddles the United States - Canada border, and Büsingen is a Germany town completely surrounded by Switzerland.
Büsingen am Hochrhein