Lisperはプログラムに何を見るか - 八発白中
男子校に通う中学生の僕らにとって「家庭科」の授業は休憩時間のようなものだった。 僕の中学校には家庭科室というものがない。だから、いつもの教室で野菜の種類やそれに含まれる栄養素なんかを教わるというだけの、正直退屈な授業だった。話される内容はどれもただ暗記すればいいものなので、授業を聴かなくても定期試験前に教科書を読み通すだけで九〇点は取れる教科だった。 学校としても文科省の教育課程に沿うがためだけに時間割にねじ込んでいるに過ぎなかったと思う。特別教室がないことでも真面目にこの教科を取り扱う気がないことがわかるし、生徒の方でもその学校の態度を敏感に感じとっていた。 そんなやる気のない男子学生の前に立って話すのは教師にとって楽しいものではなかっただろう。僕らの先生は、落ち着いた雰囲気でどこかしたたかさのある、髪の長い女の先生だった。 その日も彼女はいつも通り、キノコに含まれる何々という栄養素が、
高速なCommon LispのWebサーバ「Woo」を作りました - 八発白中
ここ一ヶ月ほど手掛けていたCommon LispのWebサーバ「Woo」が一応の完成に至りましたのでお知らせします。Clack-compatibleなAPIになっており、現状運用しているClackのWebアプリケーションでそのままお試しいただけます。 高速であることを最優先に設計しており、Hunchentootの4倍、Wookieの3.5倍高速に動きます。現状ではCommon Lispのサーバでは最速ではないでしょうか。*1 Woo by fukamachi | GitHub Benchmarks いくつかのCommon Lispのサーバと、Node.js、Go、Pythonのサーバを比較してみました。縦軸はreq/secで、高いほうが多くのリクエストを捌けることを意味します。 Wooは、PythonのTornadoより約9.5倍、Node.jsの約1.9倍のリクエストを捌けます。一方、G
軽量なCommon LispのDBライブラリ「datafly」を作りました - 八発白中
Common Lispのデータベースライブラリというか、O/Rマッパーとしては3ヶ月前に僕が作ったIntegralがあります。 IntegralはCLOSやMOPなどのCommon Lispの魔術を余すこと無く使い、拡張性や高度なマイグレーション機能もあるライブラリとして他の追随を許しません。 ただ、すべてのアプリケーションでO/Rマッパーのような機能が必要なわけではないでしょう。抽象化レイヤーを薄く保って、極力コントローラブルにしたいという要望もあります。 今回紹介する「datafly」はそういった要求を満たす軽量なDBライブラリです。 dataflyの思想 一般的なO/Rマッパーでは、データベースの「テーブル」と、プログラム言語の「クラス定義」が一対一対応しています。この大きな前提のおかげでデータベースを抽象化でき、まるでクラス定義が(半)永続化しているように錯覚させてくれます。 ただ
Lisp Meet Up #13 に参加しました - 八発白中
1/23の夜開催されたイベント、Lisp Meet Up presented by Shibuya.lisp #13 に参加しました。 Lisp Meet Up presented by Shibuya.lisp #13 毎月やっているLisp Meet Upが1周年を迎えたのはめでたいですね。なわたさんと神田さんは表彰されていいと思う。 参加者 最初に自己紹介タイムがありました。使っているLispはClojureが一番多かったです。Common Lisp回なのにCommon Lisperは一番少なかったんじゃないかな。 Integralの紹介をしました 先日作ったCommon LispのO/RマッパーのIntegral について発表しました。30分くらい話したと思います。 Integral - New O/R Mapper for Common Lisp from fukamachi 既
新しいCommon Lisp方言「CL21」を作ったので意見を募集します - 八発白中
昨晩、神の啓示か何か知りませんが、ふと思い立って新しいLisp方言を作りました。 ほとんどの機能はCommon Lisp互換なので「Common Lisp方言」と言うべきかもしれません。 CLerだけでなく、Common Lispをあまり書いたことがない人やそれ以外の言語を使っている方の意見も伺いたいのでぜひ最後までご覧ください。 名前は「Common Lisp in the 21st Century」の略で「CL21」です。 http://cl21.org 特徴 よりオブジェクト指向に 関数型プログラミング機能を仕様に追加 (composeやcurryなど) MOPを仕様に含む CL21のチュートリアル Common Lispと似ている部分が多いので、わかりやすい異なる部分をいくつか紹介します。 Hello, World! まずはHello, Worldから。 (write-line "
高機能なCommon LispのO/Rマッパー「Integral」を作りました - 八発白中
「O/Rマッパー」や「ORM」と聞くだけで顔をしかめる人もいらっしゃいます。たぶん過去にひどい目にあったんでしょうね。その大きな理由の一つがパフォーマンスでしょう。 一昨年のYAPC::Asiaに参加したとき、ORMは使うなという話を4回くらい聞いたのが印象的でした。DBのデータはハッシュで返すか、DBIをそのまま使うほうが良いと。弊社でもパフォーマンス上の問題をわかりづらくしてしまうことから、ORMを使用しないプロジェクトがいくつかあります。 まあ、そりゃDBI使うほうが高速に動くとは思います。 しかし、僕が使っているのは実用的な言語であるCommon Lispです。実行効率と抽象化がとても得意な言語です。さらに優れたオブジェクトシステムであるCLOSも仕様に含まれています。 そこで、既存のO/RマッパーにCommon Lispらしさを加えてみるとどうだろう。 そう思って作ってみたのが、
あなたがLispを無視することができない理由 - 八発白中
（この記事はLisp Advent Calendar 1日目のためのエントリです。） 禅が好んで用いる比喩がある。月を指すには指が必要である。だが、その指を月と思う者はわざわいなるかな。 — 鈴木大拙「禅」 これをLispに例えるなら、こう言うことができるかもしれない。 Lispを書くには括弧が必要である。だが、その括弧をLispと思う者はわざわいなるかな。 Lispを普段書いている身としてはLispについて括弧がどう、というのは些細なものに思えるが、Lispを知らない人からすると自然な考えだろう。人間は知らないものを理解しようとするとき、自分が今まで見たもの、知っているものと比較して手がかりを得ようとする。Lispが他のプログラム言語と比較してユニークなものは、やはりその括弧で表現されたS式だ。 しかし、Lispが括弧を使った奇妙な構文を用いるのは理由がある。そしてそれがLispの強力さ
Lispユーティリティの新しい解決案「Quickutil」 - 八発白中
今、新婚旅行のためシリコンバレーのSanta Claraというところに1週間ほどいるのですが、途中から妻を無視してステイ先のRobert Smithとハッカソンを始めてしまってまじごめんみたいな感じです。 とはいえ、まあこれも思い出ということで……新しいCommon Lispライブラリ「Quickutil」というものを作ったので紹介します。 http://quickutil.org/ ユーティリティ まとまったプログラムをしているとほぼ必ず使うことになるであろうものは「ユーティリティ」です。 Common Lispプログラマなら以下のようなことを思ったことがあるのではないですかね。 Alexandriaは大きすぎる…… なんでAlexandriaにあの関数ないんだよ…… aandのためだけにarnesi……*1 split-sequence…… そんな微妙な行き違いの結果、みんなオレオレユ
Lispライブラリのドキュメント集約サイト「Quickdocs.org」を作りました - 八発白中
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、および依存ライブラリです
巳年なのでPythonでLESSの自動コンパイルしてみた - 八発白中
これは普通の日記です。 今年は巳年なのでPythonを始めました。 全てのwebエンジニアがPythonを勉強するべき2013年到来 別にこの記事に影響されるほど繊細でもないのですが、Perlは仕事でいくらでも書けるし、Rubyはあんまり好きじゃないので、Pythonやってみるかーという軽い気持ちです。 ただ、Pythonの本はなかなか良いのが見つからなくて、最初は初めてのPythonを読もうと思ったのだけど、読み終えるのに一年くらいかかりそうだったからやめました。 Pythonクックブックにも一度手をつけたけど結局読まず、最終的に読み進めたのはDive Into Pythonだけでした。無料で読めるし、とりあえず完成したPythonコードを突き出して (Diveして)、順に説明するという方式で、他の入門書より速く学べる。実際、文法を多少知らなくてもDiveしたPythonコードは雰囲気で
ILC2012 @ Kyotoに参加して発表しました - 八発白中
10月21〜24日の4日間、International Lisp Conference (国際Lisp会議) 2012 @ 京都に参加してきました。4日目にはClackについて発表してきました。 せっかくなのでレポートがてら、ILCについて少し書いておこうと思います。 ILC2010 @ Reno/Sparks ILCの参加は前回のILC2010 @ Renoが最初でした。 そのときはClojureでAppEngineを使ってWebアプリケーションを作ろうとしたり、プレゼンツールを作っていました。Schemeは少し書けたものの、Common Lispはまだ複雑に思えてほとんど書いたこともありませんでした。 英語も話せず、お金もなかったにも関わらず、行ったこともないアメリカに単身で行くのは今思い返すとかなり無謀ではありました。 なぜ参加しようと思ったかというと、CLtL3 *1 について調べ
Common Lispでシェルを便利に！「Shelly」をリリースしました - 八発白中
先日のKyoto.lisp Tech Talkでご紹介しましたが、「Shelly」というプロダクトを作りました。 Shelly View more presentations from fukamachi まとめると、ShellyはCommon Lispの関数をシェルコマンドのように実行できるユーティリティです。 インストールは以下のコマンドを実行してください。「LISP_IMPL=ccl」の部分は使っている処理系に合わせて変更してください。LISP_IMPL=sbclとか。 $ curl -L http://xrl.us/shly | LISP_IMPL=ccl perl - installもしくはREPLからShellyをロードしてください。 (ql:quickload :shelly) (shelly:install) インストールが成功すると ~/.shelly にファイルがコピー
Common Lispの軽量フレームワーク「ningle」を作りました - 八発白中
Clackベースの軽量Webフレームワーク「ningle」を作りました。 ningle by fukamachi 背景 Clackベースのフレームワークとしては既に「Caveman」がありますが、CavemanはPerlのAmon2に影響を受けたこともあり、プロジェクトの拡大に伴う拡張性を損なわないために多くのことをします。 たとえばCavemanにはprojectという概念があり、開発環境と本番環境でロードするconfigファイルを分けたり、どのようにビルドするかを定義したりできるようになっています。 複数のClackアプリを定義することもでき、最初はPCサイトのみ作っていたけど半年後にスマートフォン用サイトも作ることになった、という場合などにも、アプリの継承などですぐに対応できるようになっています。 Clackのミドルウェア利用も記述を少し追加するだけです。 けれど、これらの拡張性のた
Clack、裏イントロダクション - 八発白中
先日、ClackのTutorialの更新を始めた。ただ、公式チュートリアルということもあって、あまり熱狂的なことも書きづらい。他のプロジェクトの名前を挙げて比較するのも行儀が悪い。そんなことを意識しながら書いたので、割とよくある平凡な文章に落ち着いてしまった。 とは言え、このイントロダクションを見てClack始めたい！と思う人も少なかろうと思う。なので、非公式なイントロダクションをここに書く。 ライブラリ環境の問題点 去年の正月休みはほとんどClackを作っていた。Clackは当初とても小さなものだったけど、開発開始から最初のαリリースまで1ヶ月ほどかかった。それには理由がある。 当時思っていたことは、Common Lispのライブラリ環境の整備はとても遅れているということだった。少ないだけでなく、中には特定の処理系/OSでしか動かないものもあったり *1、ドキュメントがない、その上コード
Common LispプロジェクトをJenkinsで継続的インテグレーション - 八発白中
Clackのバグ報告を定期的にもらいます。ありがたいことなのですが、そのほとんどが○○の処理系でエラーが出てる、などです。具体的に言えば、追加したシンボルがその処理系の標準パッケージのシンボルとコンフリクトする、とかですね。 こういうつまらないものであれば、自動テストを走らせるだけで簡単に見つかるようなものです。けれど、Clackは現在6000行近くあり、一回テストするのに2分くらいかかるので、コードを変更するたびにすべての処理系でテストするなんて現実的じゃありません。かと言っていつの間にかバグ入ってるという状況は避けたい。 なので重い腰をあげて、Clack Project用にJenkinsさんを立てて継続的インテグレーションすることにしました。できたJenkinsサーバは以下のURLで運用しています。 http://ci.clacklisp.org/ せっかくなのでセットアップの流れをま
Shibuya.lisp TT #7 に参加してLTをしました - 八発白中
Shibuya.lispが久しぶりに開催されたので参加してLTをしました。今回で3回目の参加、2回目のLTです。LTの内容は僕がこの1年間でしてきたこと、これからの展望のざっくりしたまとめです。 深町英太郎はどこへ向かっているのか View more presentations from fukamachi あとは、少し今回の感想を書きます。 今回はTTのしょっぱなから id:m2ym がLispを具体的な経験を踏まえながら的確にdisり始めて会場がシーンとなってたときはどうなるかと思いました。 時間が足りずに、本題の「それでもなぜCommon Lispを使っているのか」が伝わりづらかったので勝手に補足しておくと、「Lispは成長可能な言語であり、真の意味で"言語"に最も近い言語。」というのが最も言いたいことだったのだと思います。その後に続く「Lispを書いているとき、人は自由になれる。他
なぜ数ある言語からCommon Lispを選んだのか - 八発白中
はてなに入ってからよく「なんでCommon Lispで書くんですか？」と聞かれます。アリエルにいるときは全く聞かれなかった質問です。今まで当たり前のように受け入れていたことを改めて尋ねられるとはっとさせられます。 「Common Lispが一番書きやすいからです」 「あっ…すいませんでした」 なぜ謝られたし。これではまるで僕が変人扱いです。だけどたぶんこれが普通の感覚で、アリエルは変な人が多かったんでしょう。 こう言われることもあります。 「でも、Lispってカッコが多いじゃないですか」 これもまた久しく忘れていた感覚で、思わず答えに詰まってしまいました。Common Lispのカッコがそれほど多くないということは既に証明されているというのに。 先週末にid:m2ymと会って話をしたときにも同じような話をしました。閉じカッコがたくさん続いているとか、letのカッコの数が1個多いとか、そうい
YAPC::Asia 2011に参加しました - 八発白中
先週の金・土に開催されたYAPC::Asia 2011に参加しました。YAPCはなんだかんだで3回目です。毎年会う人もいて、「Perlはもう書かないって去年言ってましたよね (ニヤニヤ」とか言われました。あれ、そんなこと言ったっけ…。 以下に印象に残っているトークと感想を書きます。 Perl 5.16 and beyond Jesseのトークは毎年面白いですね。これからのPerl5はよりより形で後方互換を捨てる、とか、そろそろ名前を変えてもいいかもしれないなど夢のある話が聞けました。 Hacking with metacpan id:tokuhiromさんのトークです。metacpanは使ったことがないし直近で使うこともなさそうなのであんまりピンときませんでしたが、軽量なCIツールUkigumoは使ってみたいと思いました。 Ukigumoを作る前はテスト結果のログを日付ごとに出力してPla
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アリエルの謎 (Ariel Advent Calendar 3日目) - 八発白中