先日、QuickdocsというWebサービスを作りました。

• Lispライブラリのドキュメント集約サイト「Quickdocs.org」を作りました - 八発白中

アプリ部分はほとんどCommon Lispで書かれています。今までもいくつかCommon LispでWebアプリを書いたことはありますが、公開されたWebサービスはこれが初めてです。

公開当初は半日に1回落ちたり、表示が変になったりしていました。そこで2週間ほどかけて、不具合の原因を突き止めたり、それを修正して堅牢にしたり、レスポンス速度を改善したりしてきました。

Common LispのWebアプリの運用ノウハウが少し溜まってきたから車にはねられるなどする前に共有したい

2013-03-06 02:06:20 via web

試行錯誤を繰り返してきており、伝えたいことも多いです。書いてみるとかなり雑然としてしまったのですべての人向けにおすすめできるものではなくなってしまいましたが、少しでも他にCommon Lispの運用をしている人や後に続く人の助けになれば良いと思います。

ちなみに以前にも似たような記事を書きました。いくつかやり方が変わっていますが、少しは参考になるかもしれません。

• Common LispのWebアプリケーションを社内運用してみた - 八発白中

Overview

Quickdocsの構成はシンプルです。

• ningle (Webアプリケーションフレームワーク)
• Nginx (フロントサーバ)
• Supervisord (死活監視)
• SBCL 1.0.58

Webフレームワークとしてningleを使い、ClackのFastCGIバックエンドを使っています。フロントサーバにはNginxを置いています。

レスポンスのキャッシュにSquidの導入も考えましたが、Nginx自身にキャッシュの機能がついていたのでそれを使っています。

Quickdocsの特殊なところではあるのですが、DBはありません。ユーザからの投稿を受け付ける機能がなく、トランザクションが不要なので、必要なデータはすべてS式でファイルに記録しておいて、サーバ起動時にロードするようにしています。

サーバはさくらVPSのメモリ1Gを使っています。1台でJenkinsやQuickdocsのステージング環境、バッチ処理なども行なっています。まだリソースには余裕はありますが、1台でなんでもこなすので、お互いの処理が干渉しないように注意する必要があります。この方法は後ほど紹介します。

以下では主にこの構成を前提に話を書きます。

サーバを起動

Common Lispでプロセスをdaemon化する方法はいくつかありますが、僕は使っていません。単純に--evalをつけてワンライナーでサーバを立ちあげています。

毎回起動するのを楽にするために、Makefileを書きました。

Makefile

以下はQuickdocsで使っているMakefileの抜粋です。sbclというマクロを作って、ワンライナーを書きやすくしています。

SERVER_PORT=8080
SWANK_PORT=4005
PROJECT_ROOT=$(abspath $(dir $(lastword $(MAKEFILE_LIST))))

define sbcl
sbcl --noinform --disable-debugger \
--eval '(pushnew #P"$(PROJECT_ROOT)/" asdf:*central-registry*)' \
--eval '(progn $1)' \
--eval '(progn $2)'
endef

start:
$(call sbcl, \
(ql:quickload :quickdocs) (ql:quickload :swank), \
(quickdocs.server:start-server :mode :production :debug nil :server :fcgi :port $(SERVER_PORT)) \
(swank:create-server :port $(SWANK_PORT) :style :spawn :dont-close t))

swank:create-serverは必須ではありませんが、デバッグや、後述するホットデプロイに必要です。

これで以下のように実行すればサーバが起動できます。

make -f /srv/www/quickdocs/Makefile start SERVER_PORT=10080 SWANK_PORT=4025

どのディレクトリにいるときでも大丈夫なように、PROJECT_ROOTはカレントディレクトリではなくMakefileがあるディレクトリにする必要があります。

もしHunchentootを使いたいなら、:serverの部分を:fcgiではなく:hunchentootなどにしないといけません。

Nginx

Hunchentootを使って直接リクエストを捌く気なら、SERVER_PORT=80を指定すればNginxなどは必要ありません。別ポートで起動して、リバースプロキシを使ったり、上記のようにFastCGIバックエンドを使うならNginxやApacheが必要です。

以下はNginxの設定の抜粋です。

server {
    listen 80;
    server_name quickdocs.org;
    access_log  /var/log/nginx/quickdocs_access.log;
    error_log   /var/log/nginx/quickdocs_error.log;

    error_page 500 502 503 504 /html/50x.html;

    location = /html/50x.html {
        root /srv/www/quickdocs/static/;
    }
    location ~* ^/(css|images|js)/(.+)$ {
        root /srv/www/quickdocs/static/;
        access_log off;
        expires max;
        break;
    }
    location ~* ^/(favicon.ico|robots.txt|apple-touch-icon) {
        log_not_found off;
        access_log off;
        root /srv/www/quickdocs_stage/static;
    }

    location / {
        fastcgi_pass 127.0.0.1:10080;
        fastcgi_connect_timeout 300;
        include fastcgi_params;
    }
}

ここでは以下のことを行なっています。

• 50x系エラーが出たときに静的なエラーページを表示
• 静的ファイルは直接配信
• それ以外はFastCGIサーバに投げる

server_nameには自分が持っているドメインを指定し、DNSレコードを適切に設定しておきます。

上記のファイルを/etc/nginx/sites-available/quickdocsに置いてsites-enabledにシンボリックリンクを貼り、Nginxを再起動します。

これでサーバの80番ポートにアクセスしてサイトが表示されれば成功です。

死活監視

そのまま起動しておくと、いくらエラーハンドリングをしていても、メモリ不足などの致命的なエラーが出ればサービスが落ちてしまいます。そのための死活監視です。

僕は Supervisord を使いましたが、daemontoolsなど自分が慣れたものを使えばいいと思います。

Supervisorでは以下のようにcommandのところでmake startするようにすれば良いです。

[program:quickdocs]
command=make -f /srv/www/quickdocs/Makefile start SERVER_PORT=10080 SWANK_PORT=4025
numprocs=1
autostart=true
autorestart=true
user=quickdocs
redirect_stderr=true
stdout_logfile=/var/log/supervisor/quickdocs.log

良いことなのかどうかわかりませんが、僕はSupervisorでサーバの再起動も行なっています。

sudo supervisorctl restart quickdocs

起動時にプロセスIDとか記録しておいてkillするの面倒ですからね。

デプロイ

デプロイするのに毎回サーバにSSHするのは面倒なので、途中からデプロイツールを導入しました。

Fabric

僕はFabricを使いましたが、Rubyが好きな人はCapistranoが良いかもしれません。

以下はfabfile.pyの抜粋です。

from fabric.api import sudo, run, env, cd
env.hosts = ['yourquickdocs.org']
env.user = 'quickdocs'
env.directory = '/srv/www/quickdocs'
env.project_name = 'quickdocs'

def update():
    with cd(env.directory):
        run('git pull')

def restart():
    sudo('supervisorctl restart %s' % env.project_name, shell=False)

def deploy():
    update()
    restart()

def tail_access():
    run('tail -f /var/log/nginx/%s_access.log' % env.project_name)

def tail_error():
    run('tail -n 100 -f /var/log/apps/%s_error.log' % env.project_name)

これで fab deploy などとすればデプロイできます。

ホットデプロイ

始めの頃はデプロイするとき、素直にプロセスを再度立ちあげていたため、デプロイするたびに5秒くらいダウンタイムがありました。

けれど、せっかくのLispなのでサーバを無停止でデプロイしたいです。

サーバ起動時にswankサーバを立ち上げるようにしていれば、swank-clientというライブラリを使ってサーバに繋いで任意のコードを実行させられます。これを利用して以下のようにMakefileとfabfile.pyに追記します。

hot_deploy:
$(call $(LISP), \
(ql:quickload :swank-client), \
(swank-client:with-slime-connection (conn "localhost" $(SWANK_PORT)) \
(swank-client:slime-eval (quote (handler-bind ((error (function continue))) (ql:quickload :quickdocs))) conn)) \
(sb-ext:quit))

def hot_deploy():
    with cd(env.directory):
        run('make hot_deploy SWANK_PORT=%s' % env.swank_port)

fab update hot_deploy などとすればホットデプロイできます。

サーバにテスト環境を立てる

ローカルでは動いたのにデプロイすると動かないみたいなことがあります。Lisp処理系の違いだったり、OSの違いだったり、依存パッケージが足りなかったり。そこで同じサーバか似たサーバにテスト環境を置いて一通りテストします。

このとき、テスト環境用に新しくユーザを作る (たとえばquickdocs_dev) か、Quicklispのdistを分けるほうが賢明です。これはテスト環境だけQuicklispの新しいバージョンを試してちゃんと動くかをチェックしたりするのに使います。

同じユーザでQuicklispのディレクトリだけを分けたいというときは、.sbclrcを複数用意して、--userinitの指定を変更すれば実現できます。

試してはいませんが、quicklispのディレクトリ自身をリポジトリに含めればRubyのBundlerやPerlのCartonのような使い方ができるかもしれません。

パフォーマンス改善

NginxでFastCGIキャッシュを使えばアプリ側にビューキャッシュの機構を作ったりSquidなどキャッシュサーバを導入せずに済みます。

ただ、ページ単位でのキャッシュの削除機能がデフォルトでついていないため、ngx_cache_purgeというプラグインを含めてNginxをビルドすると扱いやすくなります。

以下はキャッシュを利用するときのNginxの設定の抜粋です。

    # HEADアクセスはキャッシュを使わない
    if ($request_method = "HEAD") {
        set $do_not_cache 1;
    }

    location / {
        fastcgi_pass 127.0.0.1:9080;
        fastcgi_connect_timeout 30;
        fastcgi_cache qd_cache;
        fastcgi_no_cache $do_not_cache;
        fastcgi_cache_bypass $do_not_cache;
        fastcgi_cache_key $scheme://$host$request_uri;
        fastcgi_cache_valid  200 1d;
        fastcgi_cache_valid  301 1d;
        fastcgi_cache_valid  any 15m;
        include fastcgi_params;
    }

Quickdocsの場合は内容が変更されることが基本的にないので、キャッシュの期間を長めにしています。アプリによって3hなどに変更すると良いと思います。

LispとShell

シェルコマンドを使う

Common Lisperなら堂々とすべてのコードをCommon Lispで完結すべきだ、という意見もあると思いますが、実際にアプリケーションを書いていると、やはり理想論だと感じます。

Common Lispのライブラリは有名なスクリプト言語と比べればずっと少ないですし、無いものを自前で一から作ってそれなりのクオリティで保守し続けられるほどLispコミュニティは成熟していません。必要な部分はうまく他の言語の力を借りたほうが現状ではうまくいきます。

具体例をあげます。たとえば、Common LispでImageMagickを使いたい、と思ったときにlisp-magickというImageMagickのCLバインディングを使おうとしたことがあります。

けれど、Quicklispでインストールして試してみるも、素直に動かず、調べてみると長くメンテナンスもされていないようなので使うのを諦めました。そんな怪しいライブラリを使うよりは、標準でついてるconvertコマンドをasdf:run-shell-commandで叩くほうがずっと良いです。

Quickdocsでは他にMarkdownからHTMLへの変換にHaskellのPandocを使っています。CL-Markdownはよく出来たライブラリですが、GitHub Flavored Markdownに対応していなかったので使うのをやめました。

Lisp内でシェルを叩くときの注意

Common Lispでシェルコマンドを実行するときに注意すべき点ももちろんあります。もしそのシェルコマンドの実行にかなり時間がかかるケースがある場合は、適切にタイムアウト処理をしなければいけません。

trivial-timeoutというライブラリがありますが、使い物になりません。タイムアウトはしますが、例外を投げるだけでシェルプロセスがそのままゾンビ化してしまうからです。

これは普通にtimeoutコマンドを使えば良いです。

timeout 5 pandoc /path/to/README.markdown

また、別プロセスで実行されたシェルコマンドがリソースを食いつぶしてしまって、Webサーバのレスポンスに影響が出ることがあります。これを防ぐためにulimitやcpulimitを適切に使うと良いです。

まあ、毎回実行する必要もないものはキャッシュしておいたり、あらかじめバッチ処理で生成しておくほうが確実とは思います。

おわりに

いくつか抜粋して紹介しましたが、Quickdocsの全ソースコードはGitHubに上がっています。

• fukamachi/quickdocs ? GitHub

Clackを使っていて実際に公開され動いているWebアプリケーションとしては初めてかもしれません。参考にしていただければと思います。

長々と書きましたが、僕はCommon LispでのWebアプリの運用に長けているわけではありませんし、もちろん運用を長く経験された方からみると拙い解決方法が多いと思います。

とはいえ、Common Lispのような小さい言語コミュニティでは、開発も運用もとりあえずやってみて、まず道を作っていくことが重要だと思いました。

何かわからないことがあれば遠慮なくTwitterやE-mail (e.arrows@gmail.com) などで聞いてください。

逆に、他にもCommon Lispのアプリケーションの運用をしている方はぜひノウハウを教えてください！

Quicklispに登録されているCommon Lispライブラリの情報をWebで見られるサイト「Quickdocs.org」を作りました。

• http://quickdocs.org/

さくらVPS 1Gで動いてます。この2日で突貫で作ったみたいな感じなのであまりいじめないでください。

機能

とてもシンプルなので、見ていただいたほうがわかりやすいかもしれません。

たとえばClackのプロジェクトページは以下です。

• http://quickdocs.org/clack

右上にはWebサイトやリポジトリへのリンクを置きました*1。

本文にはREADMEを表示しています。最近はGitHubにホストされているライブラリが多いので見慣れていると思いますけどね。

下のほうには.asdに記述されている情報を表示しています。Author, Maintainer と License、および依存ライブラリです。

また、一番下にはAPIリファレンスへのリンクを置きました。

APIリファレンス

Quickdocsで特筆したいところとしてはAPIリファレンスの自動生成機能があることです。

APIリファレンスというのは、プロジェクトに含まれるパッケージやその変数・関数・マクロやクラスなどを一覧で表示するものです。

例としてAlexandriaを挙げます。

• http://quickdocs.org/alexandria/api

シンボル名や関数の引数の表示、およびdocstringがあればそれも表示しています。今はexportされているシンボルのみ表示しています。

気づく方もおられるかもしれませんが、その表示順序にもこだわりがあります。

Common Lispのドキュメント生成ライブラリの気に入らないところは、どれもこれも、パッケージのシンボルを全部一緒くたにしてアルファベット順に並べていることです。確かに、リファレンスとしてはアルファベットのほうが引きやすいかもしれませんが、ざっくりライブラリの概要を見るには向きません。

QuickdocsのAPIリファレンスは、実際にソースコードをパースしているので、ソースコードで定義されている順番にシンボルを表示しています。非常にリーズナブルです。

欠点としては、表示がちょっと遅いことでしょうか。大きめのライブラリになると返ってくるのに5秒くらいかかることもあります。じきに改善します。

Quicklisp登録のライブラリのメンテナの方はぜひご自分のライブラリのページを確認してみてください。

おわりに

Pythonを学んでアプリケーションを作ってみる過程で、Common Lispにはまだまだ足りないものが非常に多いなぁという実感があります。

特に、Pythonのコミュニティはドキュメントを書くことを推奨しており、多くのライブラリを、実際にインストールする前にWeb上で概要を知ることができます。

Common Lispで何かをやるライブラリを探したいとき、とりあえずql:system-aproposしてみて、それっぽいライブラリがなければググってみて、出て来なかったらCLiki.netで検索してみて、なかったらGitHubで検索してみて、なかったらPerlで書くみたいなことを繰り返して来ました。今後はQuickdocsでの検索で完結できることを目指します。

たとえCommon Lispのライブラリが見つかったとしても、まともな情報がWebになく、とりあえずインストールしてみたけどどう使ったらいいかわからないからソース読む、みたいなことも多々ありました。今後はQuickdocsのAPIリファレンスが助けになりそうです。

Common Lisperの方はぜひ使ってみてメールなどでフィードバックをいただけるとありがたいです。

プログラムを書くのに使うのはもちろんEmacsなのですが、最近はプログラムだけでなく長文ドキュメントや本なんか読むことが多いです。そういうとき、どうしてもEmacsから離れてChromiumで開いたり、長文になるとKindleに転送したりしてしまう。

だけど、Kindleはカスタマイズ性が低くて、ちょっとしたことをやりたいと思ってもできない。

たとえば、調べた英単語の履歴とか出せない。こういうハッカビリティの低さには憤りを感じます。

それなら全部Emacsでやってしまえばええやん、と思ってコツコツと改良し続け、そろそろノウハウが溜まってきたのでついでに紹介します。

Kindly Mode

Kindly Modeは、EmacsのバッファをKindle風の表示にしてくれるマイナーモードです。ほとんど見た目だけのことですが、以下の機能があります。

• 見た目がかっこよくなる
  • 具体的には、明朝体になってフォントサイズが大きくなって行間が少し空く
• viライクなキーバインドが有効
• 自動でしおりを挟んでくれる

GitHubにpublishしたので、試したい人はAuto Installとかでインストールすると良いと思います。

• https://github.com/fukamachi/kindly-mode

(auto-install-from-url "https://raw.github.com/fukamachi/kindly-mode/master/kindly-mode.el")

その後、.emacsに以下のコードを書きます。

(require 'kindly-mode)

スクリーンショット

下のがChromium上のKindle Cloud Reader。



そして下のがEmacs。



左側がKindly Modeで、右側は普通のバッファです。フォントと行間を似せました。

自動しおり機能

手間かかった割に意外とどうでもよかった機能ですが、Emacsの操作が止まったタイミングで自動でブックマーク(しおり)を打ってくれる機能がついています。

アイドルであれば常にしおりを打つのではなく、Kindleと同じで、既にあるブックマークより進んだ位置にカーソルがあったときだけしおりをつけてくれます。

つけたしおりはファイルに保存されるので、再びファイルを開いたときに「もっと先の位置にしおりをつけた場所があるけど、移動しはりますか？」と聞いてくれるので、y と答えると移動します。

おわりに

Emacsで読めることの利点は、Lispやシェルとの連携ができることです。

たとえば、僕はEmacsからM-x dictで英単語の意味を調べられるようにしています。辞書を引いたときはそれをログに書き出すようにしているため、あとで見直すことも可能です。

また、本の内容をコピペしたり、ツイートしたりブログに引用するのも楽かもしれないですね。あんまり活用してないけど。

これ作ったときに、「M-x follow-modeすると二画面でいい感じになるのでは！」と思ったけど、行間をいじってるといい感じに表示してくれなくて残念だった。

久しぶりにEmacs Lispを書いて思ったのは、やっぱLispめっちゃ書きやすいな〜、ということでした。おわり。

これは普通の日記です。

今年は巳年なのでPythonを始めました。

• 全てのwebエンジニアがPythonを勉強するべき2013年到来

別にこの記事に影響されるほど繊細でもないのですが、Perlは仕事でいくらでも書けるし、Rubyはあんまり好きじゃないので、Pythonやってみるかーという軽い気持ちです。

ただ、Pythonの本はなかなか良いのが見つからなくて、最初は初めてのPythonを読もうと思ったのだけど、読み終えるのに一年くらいかかりそうだったからやめました。

Pythonクックブックにも一度手をつけたけど結局読まず、最終的に読み進めたのはDive Into Pythonだけでした。無料で読めるし、とりあえず完成したPythonコードを突き出して (Diveして)、順に説明するという方式で、他の入門書より速く学べる。実際、文法を多少知らなくてもDiveしたPythonコードは雰囲気で何をしたいのかわかるし、読みやすさを売りにしたPythonらしい本だと思います。

既にプログラム経験がある人にはDive Into Pythonおすすめです。



もしくはこっちのほうがいいかな？？？

• Lisp プログラマのための Python 人門

LESSの自動コンパイル

最初はFlaskでWebアプリケーションを書いていたのですが、LESSを使いたいと思って、lesscについて調べてたら、LESSファイルの変更を監視して自動でCSSにコンパイルするスクリプトを書いていました。

作ったのは下のスクリプトです。実行にNode.jsとlesscが要ります。

import os
import re
import shutil
import time
import sys

from watchdog.observers import Observer
from watchdog.tricks import Trick


class FileCompileHandler(Trick):

    def output_path(self, path):
        return re.sub(r"([^\.]+)(\..+?)?$", r"\1-compiled\2", path)

    def compile_file(self, file):
        pass

    def compile_path(self, path):
        if os.path.isdir(path):
            for file in os.listdir(path):
                self.compile_path(file)
        else:
            self.compile_file(path)

    def on_created(self, event):
        if not event.is_directory:
            self.compile_path(event.src_path)
        else:
            os.mkdir(self.output_path(event.src_path))

    def on_modified(self, event):
        if not event.is_directory:
            self.compile_path(event.src_path)

    def on_moved(self, event):
        self.on_deleted(event)
        self.compile_path(event.dest_path)

    def on_deleted(self, event):
        to_delete_path = self.output_path(event.src_path)
        if event.is_directory:
            shutil.rmtree(to_delete_path)
        else:
            os.remove(to_delete_path)
        print "Deleted: " + to_delete_path


class LESSCompileHandler(FileCompileHandler):

    def __init__(self,
                 patterns=['*.less'],
                 source_directory='.',
                 destination_directory=None,
                 lessc='lessc'):
        super(LESSCompileHandler, self).__init__(patterns=patterns)

        self.source_directory = os.path.abspath(source_directory)
        if destination_directory is not None:
            self.destination_directory = os.path.abspath(destination_directory)
        else:
            self.destination_directory = self.source_directory

        self.lessc = lessc

    def output_path(self, path):
        return re.sub(
            r"\.less$", '.css',
            path.replace(self.source_directory, self.destination_directory))

    def compile_file(self, file):
        output_file = self.output_path(file)
        os.system(' '.join([self.lessc, file, output_file]))
        print '[LESS] Compiled: %s -> %s' % (file, output_file)


def watch_and_compile(source_directory, destination_directory=None):
    event_handler = LESSCompileHandler(
        source_directory=source_directory,
        destination_directory=destination_directory)

    observer = Observer()
    observer.schedule(
        event_handler,
        path=event_handler.source_directory,
        recursive=True)
    observer.start()
    try:
        while True:
            time.sleep(1)
    except KeyboardInterrupt:
        observer.stop()
    observer.join()


if __name__ == "__main__":
    watch_and_compile(*sys.argv[1:])

importしてもいいし、そのままスクリプトとして実行できます。以下のように実行すると、「static/less」以下にある".less"のファイルを監視し、コンパイル結果を「static/css」の同じ階層に出力します。

$ python less_compile.py static/less static/css

watchdog.tricks.Trickを継承しているので、tricks.yamlで設定を管理することもできます

# tricks.yaml
tricks:
  - less_compile.LESSCompileHandler:
      source_directory: static/less/
      destination_directory: static/css/

実行はwatchmedoコマンドです。

$ watchmedo tricks tricks.yaml

結構試行錯誤したので、2日くらいかかりました。

Python雑感

最後に、この10日くらいPythonを学んでみての雑感です。

読みやすい

自分が書いたコードにしても、他人のコードにしても、PerlやCommon Lispより圧倒的に読みやすいです。これは言語の優劣の問題ではなく、たぶんPythonがシンタックス上の制限が多いためでしょう。書くのには自然と気を遣わせられて、きれいなコードを強制的に書かされているような感じです。大規模なプロジェクトだと活きそうですね。

前からClackやCavemanのコードを読んだ外人に「Pythonっぽすぎるだろ」と渋い顔で言われることがままあって気になっていたのですが、実際に学んでみて理由がわかった気がします。なんでしょうか。とりあえず褒め言葉として受け取っておきます。

ちょっとしたことでもクラス定義しないといけないのが不便

僕はPerlやCommon Lispでプログラムを書くときは、まずプロトタイプを作る目的でsubやlambdaを書いてとりあえず動かしてみる、というところから始めます。

今回のLESSの監視自動コンパイラを書こうと思ったときもそうしようと思ったのですが、Pythonではlambdaに複数の式を書くことはできないし(確かにひどい)、簡単な名前付き関数を書いていても煩雑になるばかりで、もういきなりクラス定義から始める有様でした。書きながら、いきなり泥沼に足を突っ込んだような心持ちでした。

メソッドコンビネーションがないのが不便

ファイルをコンパイルしたときのログなんかは、まとめて親クラスで定義してしまいたかったのですが、PythonにはCLOSのような高級なオブジェクトシステムがないのでbeforeとかafterメソッドを定義することができなさそうです。

何か専用のモジュールがあるんでしょうか？ ちょっと不便です。

おわり

以上、日記でした。Pythonistaの方々、よろしくお願いします。

これはLisp Advent Calendarの10日目です。

先日、HappyElementsさんで行われたLiveCoding #11にライブコーダとして参加させていただきました。そのときの話をしようと思います。

LiveCodingとは

一人の"LiveCoder"が、20分の制限時間で何かソフトウェアを作り、デモをします。 LiveCoderがどのようにコーディングしているかの全てがプロジェクターで大画面に映し出され、 さらに解説役が常にLiveCoderの挙動を説明します。

A 「コンパイル中です・・・、お、おおお、なんと、Syntax error!」

B 「これは恥ずかしい…!」

LiveCoder 「(/// 」

LiveCoderが何を作るかについては、自分で決めた上でそれをLiveCoding前に告知します。 ただし、観客の要望で仕様が強制的に変更になることがあります。 もっとも、客観的に20分以内に実装できないことが明らかな場合、仕様変更要望は無視できます。

一人のLiveCoderに対して二人の解説役が付くことがうまくいくという経験則があります。
LiveCoderは過去に作ったものと全く同じものをLiveCodingで作ることが禁止されています。 もはやそれはLiveCodingではなく、たんなる動画の再生と見なされます。

参加のきっかけはILCでお会いしたyharaさんに勧められたことだ。

「Common Lispでいいですか」
「はい、むしろCommon Lispでお願いします。」

Common Lispでいいならなんとかなるだろう。

作るもの

今回、Common Lispで何かを作るということだけはあらかじめ決まっていたものの、何を作るかは未定だった。

何か風変わりなものを作ろうとも考えたが、Lispに詳しい方なんてほとんど来ないので、むしろ普通のものを作ってみては、という助言をいただいたので、普通にWebサービスを作ることにした。

Webサービスなら自分のホームグラウンドでもある。20分で現実的に作れるもので、誰もが知っているようなサービス──ブログ。20分でブログを作ることに決めた。

方針

持ち時間は20分と非常に短い。Common Lispがいかに高速な開発を可能にするとしても、20分で完璧なものを作るのは無理だ。いくらか手を抜かなければならない。

とりあえず動くものを作るのが最優先だろう。パフォーマンスは気にしない。セキュリティも、まあいいだろう。CSSなんて書いている暇はない。とにかく短いコード、短時間で動くものを作る、そのために必要なことだけに注力することにした。

1. プロジェクト作成

まずはプロジェクトを作る。Common Lispだとプロジェクトを作らずにいきなりREPLで始めることもできるが、途中でEmacsがクラッシュしない保障はない。プロジェクトはファイルに書き出しておくのが賢明だ。

(ql:quickload :cl-project)
(cl-project:make-project #P"~/Programs/web/hatenablog/" :description "Write the story of your life.")

• CL-Project

2. サーバ起動

さて、ブログに最も必要な機能はなんだろう？

ブログなのでWebブラウザ上で見られないと使ってもらえない。まずはサーバを起動してみよう。

今回はインタラクティブで高速な開発が必要なため、Webフレームワークとしてningleを使うことにした。ningleより今回の目的に合ったフレームワークはないだろう。

(ql:quickload :ningle)
(defvar *app* (make-instance 'ningle:<app>))
(clack:clackup *app*)
;-> Hunchentoot server is started.
;   Listening on localhost:5000.
;=> #<CLACK.HANDLER:<HANDLER> #x3020061A081D>

これでHunchentootをバックエンドとしてブラウザ上で見られるようになった。⌘-Tabを押してChromiumに移動して http://localhost:5000 に移動する。



う、何も表示されてない……。

あっ。

思い当たることあって⌘-⌥-Iを押して開発ツールを開く。



404だった。何もルーティングルール書いてないんだからそりゃそうだ。とりあえず動いてはいるようなので安心した。

3. ルーティング設定

トップページが404のWebサービスというのは斬新だが、早々に解決しなければならない。

ルーティングルールを書いて小粋な挨拶をさせてみよう。

(setf (ningle:route *app* "/")
      #'(lambda (params)
          "Hello, I'm Hatena Blog."))

ブラウザに戻ってリロード。



順調。

4. データ定義

このブログサービスはまだ生まれたばかりなので、ブログを書くことができない。これでは誰にも使ってもらえない。次はエントリを書けるようにしてみよう。

Common Lispは完全なオブジェクト指向言語なので、まずはクラス定義をする。

(defclass <entry> ()
    ((title :type 'string :initarg :title :initform "")
     (body :type 'string :initarg :body :initform "")))

とりあえずタイトルと本文があれば十分だろう。エントリを作るための関数も用意しておく。

(defvar *entries* nil)
(defun create-entry (&key title body)
  (pushnew (make-instance '<entry>
              :title title
              :body body)
           *entries*))

とにかく僕には時間がない。既に10分が経過しようとしている。残り10分ほどで動くものにしなければならない。DBスキーマを作ってエントリをDBに入れている暇なんてない。すべてオンメモリだ！ 生まれて10分と少しのWebサービスということで甘んじることにする。

(create-entry :title "Hi" :body "This is my first blog entry. Hehe.")
;=> (#<<ENTRY> #x3020061CC9CD>)

これでエントリを作れた。よし。

5. ブラウザに表示

次はエントリをブラウザに表示させよう。

新しく /entries というページを作って、そこで時系列でエントリ一覧を見られるようにする。

テンプレートエンジンにはCL-EMBを使うことにした。これはHTMLの中に独自構文で変数を展開したりループできたりするよくあるテンプレートエンジンだ。複雑なHTMLを吐くのは面倒だが、ただ表示するだけなら十分だろう。

templatesディレクトリ以下に entries.tmpl というファイルを作っておく。

<html xmlns="http://www.w3.org/1999/xhtml" lang="ja" xml:lang="ja">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <title>All your blog entries</title>
</head>
<body>
<% @loop entries %>
  <h3><% @var title %></h3>
  <p><% @var body %></p>
<% @endloop %>
</body>
</html>

あとは entries という名前でエントリのリストを渡してあげればいい。

(ql:quickload :cl-emb)

(setf (ningle:route *app* "/entries")
      #'(lambda (params)
          (emb:execute-emb
           #P"entries.html"
           :env
           (list :entries
            (loop for entry in *entries*
                  collect
                  `(:title ,(slot-value entry 'title)
                    :body ,(slot-value entry 'body)))))))

少し冗長。とはいえこれでエントリ一覧が見れるはずだ。



できてる。1個だとわかりづらいからもう1個くらいエントリを作っておこう。⌘-TabでEmacsに戻り、REPLでcreate-entryを打ち込む。

(create-entry :title "Yippee!" :body "Hatena Blog is already working!")

Chromiumに戻ってリロード。



都合がいいことにpushnewすると新しいものが上に来るようになっている。素晴らしい。

6. エントリを書くフォーム

これでREPLからエントリを書けるというLisperフレンドリなブログシステムが完成した。思いついたときに即座にREPLを立ちあげ、create-entry。クール。

しかし、ユーザ様の中にはCommon Lispをインストールしていない方もおられるかもしれない。ブラウザ上でもエントリを書けるに越したことはないだろう。

この時点で残りは5分もない。行けるか……。完成が危ういが、このまま5分間観客と談話して過ごすつもりもない。仕方ない。やってみよう。

/post というページを新しく作って投稿フォームを表示することにする。

今回もCL-EMBでやろうと思ったが、悠長にしてられない。CL-Markupで少し楽をする。

試しにREPLでmarkupマクロを呼び出して、ちゃんと求めるHTMLが返ってくるか確かめてみる。

(ql:quickload :cl-markup)

(markup:markup
 (:form :method "POST"
  (:input :type "text" :name "title")(:br)
  (:textarea :name "body" nil)))
;=> "<form method=\"POST\"><input type=\"text\" name=\"title\" /><br /><textarea name=\"body\"></textarea></form>"

良さそうだ。タイトルと本文を入力するだけのシンプルなHTML。

これをルーティングルールに組み込んでやれば良い。HTML全体を出力するにはmarkupマクロをxhtmlマクロに変更すればいい。

(setf (ningle:route *app* "/post")
      #'(lambda (params)
          (markup:xhtml
           (:form :method "POST"
            (:input :type "text" :name "title")(:br)
            (:textarea :name "body" nil)))))

あまりに簡単過ぎて恐ろしくなってくるが、Chromiumに戻ってリロード



しまった。submitボタンを忘れてた。これでは投稿できない。

急いでinputタグを追加して再評価する。

;; 再評価
(setf (ningle:route *app* "/post")
      #'(lambda (params)
          (markup:xhtml
           (:form :method "POST"
            (:input :type "text" :name "title")(:br)
            (:textarea :name "body" nil)(:br)
            (:input :type "submit" :value "投稿！")))))

投稿フォームが完成。でもまだPOST先を作れてない。投稿ボタンを押すと404。残り時間はあと2分。急いだほうがいい。

POSTのときに反応するルーティングは :method :post を追加するだけでいい。

(setf (ningle:route *app* "/post" :method :post)
      (lambda (params)
        (let ((title (getf params :|title|))
              (body (getf params :|body|)))
          (create-entry :title title :body body)
          "投稿成功！")))

POSTされたら単純にcreate-entryする。これでいけるはず。アドレナリンが噴出する。30秒のコールはすでに過ぎていたが、まだ時間はあるか。

ブラウザから投稿を試す。





きた！ 果たしてちゃんとエントリが作られたか。

⌘-Lを押してロケーションバーに素早くカーソルを合わせ、/entries を開く。



一番上に表示された！ 残り時間は ―― 4秒。Common Lispの勝利である。

おわりに

ご覧のように、Common Lispは高速なプロトタイピングが可能な言語です。REPLで一発でサーバを起動し、インタラクティブにルーティングルールを定義、再定義、確認のサイクルが回せるのが強みです。

他の言語でもREPLと呼ばれているようなものはあるかもしれませんが、そのプロセスを環境として試しながら組み立てるみたいな使い方はされていないようですし、ライブラリ側もそういった使い方を考慮して設計されていません。インタラクティブ性はLispが持つ強みの1つです。

もちろん、今回のプロトタイピングには出て来なかった、解決すべき問題も多くあります。

たとえばDBアクセス。今回はすべてオンメモリで済ませることにしましたが、実運用までにDBに入れなければいけません。ただ、その場合もPostmodernやElephantのようなObjectStoreを使えばクラス定義をそのまま使え、プロトタイピングからあまりコードを書き換えずに永続化できるはずです。

高速なプロトタイピング、そして最速なリリースを目指すならCommon Lispが最良の選択です。

ちなみにはてなブログは以下のリンクから開設することができます。どうぞご利用ください。

• http://hatenablog.com

※これは実話を元にしたフィクションです。はてなブログはCommon Lisp以外の言語で動いています。