八発白中

シンプルさはスタイルではなく必然性

　Lispの話とデザインの話が交互に出てくるブログって誰得な感じですが、最近自分もデザイン力を身につけなければならないと思い立ってひっそり勉強しています。

　そもそもデザインとは何かについて人に自信を持って言えるほどの知識も何もない状態からのスタートなので、はてブで流れてくる方法やインスピレーションを喚起、もしくは最近流行りのUI/UX系の記事がはてブに流れてくるのをスルーしつつ、地道にデザインの本質を探っているところです。それにつれ、自分の考えも変わったり周りの意見にも懐疑的になるのは面白い体験です。

　たとえば、Appleの影響で、シンプルは良いものだ、という考えが広く受け入れられるようになりました。ただ、この字面だけでは何が良いのかわからない。以前、"シンプル"についてツイートしたことがあります。

　ただ「シンプル」って言うだけでも数多くの意見があって、ただ単に"分かりやすい"っていう意味だったり、"構成物が少ない"という意味だったりしてかなり曖昧な概念だということに気づきました。またその概念自身を何に適用するかによっても話が違い、たとえばメモ帳を作るのと携帯電話を作ることでは考慮すべきことは違うはずです。誰が使うのか、どんな機能があるのかによって作るべきものは変わるはずです。

　昨日、Casa BRUTUSを買ってAppleのジョナサン・アイブのインタビューを読みました。

　そこでジョナサン・アイブが、「シンプルさはスタイルではなく、必然性だ」、と言っているのがとても腑に落ちました。それが解決する問題に極限まで近づくと、こうなるしかなかったという一種の納得感を生むまでに至る、それがシンプルなのだと。

　ただ、そこに至るまでの険しいチャレンジと行ったり来たりの繰り返しは見えないので、製品やその哲学である"シンプル"という上辺だけでAppleのデザインを評価しがちなんだけど、デザインする側に回るのであれば意識すべきですね。

ツイートする

Permalink | コメント(1) | トラックバック(0) | 13:59

Common Lisp用のデータベースライブラリ「CL-DBI」を作りました

Common Lisp用のデータベースライブラリ「CL-DBI」を作りました。

https://github.com/fukamachi/cl-dbi

このエントリではCL-DBIの紹介と、なぜ新しくライブラリを作ろうと思ったかについて書こうと思います。

Common Lispが抱えるDB周りの問題

今までCommon LispでWebアプリケーションを作る際、毎回困るのはデータベースの扱いでした。ClackやCavemanで軽量なWebアプリケーションを作っても、手頃なDBライブラリがなく、素早いWeb開発のネックとなっていました。

おそらく最も使われているライブラリはCLSQLですが、安定性には疑問があります。具体的には以下のような問題がありました。

• 環境によってはうまくロードできないことが多い (特にSBCL)
• 裏側のデータベースの差異を抽象化しきれていない (SQLite3でうまく動かない機能がありハマることが多い)
• CLOSインタフェースを採用しており、APIがリッチすぎる
• フォークしようにも巨大な上、UFFIを使っているなど設計が古くてメンテナンスの継続が難しい

次によく使われているだろうElephantは、そもそもオブジェクトストアなので目的としていることが違うのですが、MySQLに対応してなかったり、保存するレコードの可読性が悪かったり、BerkleyDBでないとパフォーマンスが落ちてしまったり、何よりメンテナンスされてないという致命的な問題があります。

一方で、もっとシンプルなcl-mysqlなどを使うと、今度はアプリケーションがMySQLに依存してしまうことになります。開発時にはSQLite3を使い、デプロイ時にMySQLに切り替える、といった開発手法もできなくなります。

CL-DBIが解決すること

これを解決するために、CL-DBIを作りました。あくまで裏側のデータベース間の差異のみを吸収するシンプルなインタフェースを保っています。現在はSQLite3、MySQL、PostgreSQLのみ対応しています。

主な機能は以下です。

• 文字列SQLの実行
• プリペアードステートメント
• プレースホルダ
• トランザクション

設計はPerlやGaucheのDBI/DBDを参考にしています。

CLSQLのようにCREATE TABLEなどを実行する機能はないです。つける予定もありません。

使い方

先ほど完成したばかりなのでまだQuicklispには取り込まれていません。試すにはまずGitHubからcloneします。

$ git clone https://github.com/fukamachi/cl-dbi.git

ASDFでロードします。

(asdf:load-system :dbi)

以下のように使えます。

;; MySQLの「test」に接続
(defvar *db*
    (dbi:connect :mysql
                 :database-name "test"
                 :username "nobody"
                 :password "1234"))

;; prepare => execute
(let ((query (dbi:prepare *db*
               "SELECT * FROM somewhere WHERE flag = ? OR updated_at > ?"))
      (result (dbi:execute query 0 "2011-11-01")))
  ;; fetchで順番に結果を取り出す。
  ;; rowはProperty List形式。
  (loop for row = (dbi:fetch result)
        while row
        ;; process "row".
        ))

;; トランザクション
;; rollbackしなければ自動でcommitが呼ばれる。
(with-transaction *db*
  (do-sql *db* "INSERT INTO person (id, name) VALUES (2, 'm2ym')")
  (rollback *db*))

簡単でしょ？

まとめ

現在は、とりあえず動くことが確認された、"αリリース"扱いのプロダクトです。今後正式リリースまでの間にAPIが多少変わる可能性があります。ただ、Quicklispには可能なら2月のアップデートで入れてもらう予定です。

今後、CL-DBIをブラッシュアップし、Cavemanや、今後開発予定のフレームワークのスタンダードとして組み込んでいく予定です。どうぞご期待ください。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 21:29

Clack、裏イントロダクション

先日、ClackのTutorialの更新を始めた。ただ、公式チュートリアルということもあって、あまり熱狂的なことも書きづらい。他のプロジェクトの名前を挙げて比較するのも行儀が悪い。そんなことを意識しながら書いたので、割とよくある平凡な文章に落ち着いてしまった。

とは言え、このイントロダクションを見てClack始めたい！と思う人も少なかろうと思う。なので、非公式なイントロダクションをここに書く。

ライブラリ環境の問題点

去年の正月休みはほとんどClackを作っていた。Clackは当初とても小さなものだったけど、開発開始から最初のαリリースまで1ヶ月ほどかかった。それには理由がある。

当時思っていたことは、Common Lispのライブラリ環境の整備はとても遅れているということだった。少ないだけでなく、中には特定の処理系/OSでしか動かないものもあったり *1、ドキュメントがない、その上コードも読めない、みたいなものが多かった。

そんな中で「俺が使いたいライブラリがないから作った」みたいに闇雲にライブラリを増やしても意味がない。そのため、Clackは過去のライブラリを反面教師に多くのことに留意して開発された。

読みやすさ

まず、誰にでも読めるコードを心がけた。本当に。偏執的なまでに。

もちろん、自分だけが読めても意味がない。コードの読みやすさは客観的な指標であるべきで、本人が書いているときは「美しい！」と思って書いてたとしても、他の人や1ヶ月後の自分が見たら「意味不明」って思うかもしれない。

そこで知っておかなければならないのは、読む人間は僕と違ってClackのすべてのコードを知っているわけではないということだった。依存関係は極力少なく、明確にした。「このコードを読むにはこのパッケージのこの関数も知っておく必要がある」ということを明示するために、すべてのdefpackageには:useではなく:import-fromが使われた。

Clackは一気に書き下されて完成したわけじゃない。コードのさまざまな部分々々を切り出して、それが何を表しているかが自明となるように注意が払われた。Tomohiro Matsuyamaには多くの意見をもらいながら、一度書かれたコードは何度も修正が繰り返され、よりよい形に落ち着くまで十分な改善がなされた。興味深いことは、その過程で使われていたマクロの多くは排除されたことだ。

マクロの対比としてWeblocksを例に挙げる*2。Weblocksで重要なコンポーネントの1つに「ウィジェット」がある。僕はこれがどのような役割があるのか本当にはわからない。ただ、Weblocksを使うにはこれが必要らしい、ということだけ知っている。

「ウィジェット」を定義するには「defwidget」を使う。ただ、これが本当に何をするかはわからない。マクロだからだ。その形から、実際はただdefclassに親クラスやメタクラスを埋め込むものだと予想できるが、それにどういった意味があるかはユーザは間接的にしか知ることができない。

実を言うと、Clackの最初期の実装も似たようなものになっていた。これがCommon Lispでは標準的なAPIの提供法だからだ。けれど、それらは徐々に噛み砕かれ、最後にはCLOSクラスをそのまま提供するまでになった。ClackのComponentを定義するには、<component>クラスを継承したクラスを定義するだけで良い。この程度のことにdefcomponentなんてマクロはないほうがいい。

ドキュメント整備

さらに、僕はコードが読みやすいだけでは不十分ということも知っていた。僕にとって他人のコードを読むのは苦痛だった。コードを読んでいるときは、大抵ドキュメントが不十分で、何かわからないことがあるから仕方なく読む、という状況だった。僕は、他人がClackを見て同じ思いをするのはとても耐え難いことだと感じていた。

これを回避するため、Clackは公開時にはすべてドキュメント化されている必要があると考えた。去年の今頃は、Clackのαリリースに向けてほとんどドキュメントの整備ばかりしていた。これにはおよそ2週間ほどかかった。ほとんど動いているプロダクトを抱えて、早く発表したい気持ちを抑えての2週間だ。最初に言ったけれど、ただ作るだけでは意味がないということを僕はよく知っていた。それが使われなきゃ。そのドキュメントはリリースごとに随時更新され、http://clacklisp.org/doc/でいつも確認することができる。

テストの自動化

さらに、Clackは品質も重視した。Clack自身に自動化されたテストがあるのはもちろん、テストの実行はJenkins上で管理されている。複数の処理系で同じテストがすべて通ることを必ず確認しているため、処理系依存で動かないようなことはなくなった。また、Clack自身のテストで使っているWebアプリケーションのテストモジュールClack.Testも同時に提供している。

継続的なリリース

そして最後に、何より重要なのは、メンテナンスが継続的にされていることだ。2011年の6月、Clackを公式リリースしたときのことをよく覚えている。バージョンはYY.MM形式で、今後毎月のリリースをする予定だ、とTomohiro Matsuyamaに言った。すると彼は、それ、大変じゃないですか、続かないですよ。僕は、まあ、頑張るよ、とだけ答えた。そして僕は今まで8ヶ月、毎月必ずリリースを続けてきた。そして今後も続ける予定だ。

おわりに

昔どこかで語ったようなことも含まれているけど、こういうことは定期的に言わないと忘れられてしまう。僕が黙っていると、Clackに自信がないから(もしくは未完成だから)だと思われてしまうことに気づいた。もちろん、全くそんなことはない。

過去最も有力だったWeblocksは継続的にメンテナンスされておらず、最新のHunchentoot 1.2でビルドできないためQuicklispでインストールできない。web4rは日本語ドキュメントがあって始めやすいかもしれないが、こちらもメンテナンスされていないため不安が残る (特に拡張性)。Hunchentootは新しいメンテナを得て、バグの多くが修正されたため使ってもいいかもしれない。teepeedee2はよく知らないけど、GitHub上で最もWatchされているCommon Lispプロジェクトだ。ロシアのLisperが作っているRESTASというフレームワークも興味深い。

ただ、僕がCLのWebアプリケーションを作るなら、ClackかCavemanが唯一の選択肢だね。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 14:08

Design is different from Decoration

最近、Webアプリケーションを全面的に"デザイン"する機会があったので、"デザイン"ってなんだろうと思っていろいろ調べています。

日本で「デザイン」とか「デザイナ」という言葉を使うと絵を描いたり建物を設計したりとかいう人を思い浮かべがちだけど、海外では形作るものを総合して"デザイン"と言います。たぶんこの辺りはSteve Jobsの影響もあって日本でも認識され始めてると思います。

ただ、それでも"デザイン"って何？と聞かれて答えられない。"デザイン"ってなんだろう。

そう思っていろんなデザインの本を読み始め、ようやく合点のいく説明をしてくれる本を見つけました。

小冊子くらいの薄い本で、Paul Randの授業での言葉が生徒との対話形式で書かれている。

Design is relationships. Design is a relationship between form and content.

デザインとは関係である。形と中身の"関係"だ。

これがPaul Randが語るデザインの本質のようで、対話の中で繰り返し出てきます。デザインとは関係性の表現。

Everybody has different ideas about what design is. One person thinks of his father's tie. One person thinks of his mother's nightgown. Another person thinks of the carpet in the living room. Another person is thinking of his wallpaper in his bathroom.

You know? That is not design. That is decorating.

(美術学校では) 皆デザインについて各々の考えを持っている。ある生徒は父親のネクタイを考える。ある生徒は母親のガウン。またある生徒は居間の絨毯。またある生徒はトイレの壁紙を考えている。

気づいたか？ それはデザインじゃない。装飾だ。

装飾とデザインがどう異なるか。そもそも装飾はデザインの一つの過程でしかないはずです。それが目立つのは、ただ最後に目につく部分だからでしょうか。はてブのdesignタグを見ていてもほとんどは装飾のテクニックが多いですね。

さらに、この「装飾とデザインの違い」っていうのは、僕にはもっと示唆に富んだ言葉に見えます。「装飾すること」だけでなく「装飾をなくすこと」もデザインの本質ではないのでは。

エンジニアの中には少なからずシンプリシティこそが善と信じて止まない人もいて、少なければ少ないほどよいという価値観を持っている人もいますが、必ずしもそうとは言えないんじゃないか。デザインは物の多さとか少なさ配置とかに依存しない概念のはずです。本当に重要なのは、「複雑さを減らすこと」。

たとえばスイッチが100個あるラジカセは何がなんだかわからなけれど、スイッチがたった1個のラジカセもシンプルとは言えない。その1個のスイッチを1回押したら再生で、2回押したら停止で、1秒間隔で3回押したら早送りとか言われても使いこなせる気がしない。笑えるけど、たぶんシンプルさに酔ってる人はやりがちなことだと思う。重要なのは、「複雑さを減らすこと」。

最初はノンデザイナーズ・デザインブックとか読んで、最低限のことを理論的にデザインを学ぼうと思ってたけど、時を越えて良いデザインをしようと思ったらどうしてもデザインの本質を知らないといけないと考えなおしていろいろ学んでいる途上です。

なかなか道のりは遠いな、と思ったところで、普段デザイナさんたちが作るものがいかに試行錯誤の上に成り立っていて道なき道を行く人々なのかに気づいて、ただただ敬服するばかりでした。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 21:58

アリエルの謎 (Ariel Advent Calendar 3日目)

はてなの深町です。ようやく昨日で入社4ヶ月目に入りました。

この記事は「Ariel Advent Calendar 2011」の3日目らしいです。なんで僕がアリエルさんの社員Advent Calendarに参加してるのか。それは、弊社の id:antipop が「Hatena::Staff Advent Calendar 2011」やると聞いたのでATNDで参加してみたら間違ってアリエルさんのAdvent Calendarに参加していたというオチでした。冗談のような話ですが、全部嘘です。

ところで、やっぱり会社の名前というのは大事ですね。社員としての立場から見てもそうですが、対外的なアピールでは当然重要になります。たとえば「手嶋屋」とかは聞けば一発で覚えられる名前なので、非常に良いと思います。

その点アリエルはグーグラビリティ低くて、検索すると二次元の人魚の画像がいっぱい出てきます。さらにオフィスの場所で絞りこもうとして「アリエル 五反田」とか「アリエル 六本木」とかで検索すると今度は教育上相応しくないお店が出てきて不快です。

なんでこんな名前にしたのか。しばらく謎だったのですが、前にアリエルCTOの井上さんから聞く機会がありました。

どうやら社名を決める際に「天体に関する名前が良い」と思って探した末、天王星の第1衛星「アリエル」を冠した社名にしたそうです。そう聞くと少しだけ立派な名前に思えるから不思議です。

さらにその衛星の名前はシェイクスピアの戯曲に登場する"空気の精霊"の名にちなんで名付けられたとか。アリエルのキャッチコピーに度々出てくる「空気のように、意識せず使える、ネットワーク・コンピューティング」という言葉にも合致して、なんだかずるい感じです。

明日のAdvent Calendarはアリエルのありえるたんさんが何か書くそうです。正体は謎です。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 17:59