近況 - 八発白中
ポケットチェンジに入社して2ヵ月が経ちました。 日々Common Lispは書いているものの、なかなか内容をブログという形式にまとめられず、かと言ってこのまま更新せぬのもつまらないので近況報告という形で残しておきます。 Lisp Meetup 3/27にサイボウズスタートアップスさんに会場をお借りしてLisp Meetupがありました。 そこで私が発表した内容自体が、私がポケットチェンジで何をやっているかになっています。 Building GUI App with Electron and Lisp from fukamachi ElectronとCommon Lispを使い、その他デバイスとJSON-RPCで非同期双方向通信を行うという変わったGUIアプリケーションです。 通常のWebアプリならばインターフェースはブラウザだけなのでブラウザイベントだけを考えていればよいのですが、コインを
Day 21: Lack - 八発白中
これは fukamachi products advent calendar 2016 の21日目の記事です。 今日はLackについて話します。Rackではないです。 Clackの高速化 サムライトに入社してWooによるサーバーの高速化を主な課題と取り組んでいましたが、アプリケーション全体で見ればその基盤部分のClackの高速化も重要でした。Wooは十分に高速だけど、Clackに載ることで大きくパフォーマンスが下がるなら残念なことです。 まあ正直、当時でも十分な速度は出ていたんですけどね。ずっと高速化ばっかりやってたので頭がもう高速化脳になっていて、何でも高速でなければ気がすまなくなっていたんでしょう。 疎結合性を確保しつつなのでWooのようにinline化や型宣言などの高速化のテクニックは使えませんが、それでもClackに速度面で改善の余地はありました。 ClackではComponent
Day 20: Dexador - 八発白中
これは fukamachi products advent calendar 2016 の20日目の記事です。 今日はDexadorについて話します。 Drakma Common Lispには古くからDrakmaというHTTPクライアントがあります。Quickdocs によると74のライブラリで利用されており広く使われているようです。 Edi Weitzと言えばCommon Lispをやっている人のほとんどは知っているでしょう。cl-ppcreやHunchentootのようなテクニカルであり高速であり品質の高いライブラリを多く作っています。 そしてDrakmaもEdi Weitzのプロダクトです。 じゃあDrakmaも彼のプロダクトならば信頼できるか、と言うと、実は期待するほどは品質が高くありません。Drakmaを使ってハマったという人も少なくないのではないでしょうか。 たとえばこんな感じ
Day 19: clfreaks - 八発白中
これは fukamachi products advent calendar 2016 の19日目の記事です。 今日はclfreaksについて話します。今回はライブラリではありません。 コミュニティの規模 Common Lispのコミュニティサイズは絶望するほど小さくはありませんが、決して大きくはありません。 以前、佐野さんがGitHub Awardsの世界ランクトップの総スター数を比較すればおおよそのコミュニティ規模がわかるのではないかと言っていました。スターする人の多くはそのコミュニティに属する人だと予想できるので、正確ではなくともあながち間違った指標でもないかもしれません。 この指標で行くと、Common Lispの一位は僕の3040です。 Rubyの一位はHomebrewの75968、二位がthoughtbotの59813です。Homebrewはツールなのでコミュニティ外からのスタ
Day 18: trivial-signal - 八発白中
これは fukamachi products advent calendar 2016 の18日目の記事です。 今日はtrivial-signalについて話します。土日に細かいライブラリ紹介が並んでいるのはただの手抜きです。 Common LIspとスクリプト 継続的なCommon Lispの課題として、スクリプトを書きづらいというものがありました*1。 開発時はREPLなので問題にならないのですが、アプリケーションの起動などを考えればコマンドラインで起動できなければいけません。他のUNIXコマンドとの連携を考えてもCLIから離れられるわけではありません。 これは8日目に紹介したShellyで解決しようとした課題でもありますが、それでもまだその他の軽量プログラム言語ほどの手軽さはありませんでした。 その理由の一つがシグナルハンドリングでした。 POSIX シグナルハンドリング シグナルハン
Day 16: QURI - 八発白中
これは fukamachi products advent calendar 2016 の16日目の記事です。 今日はQURIについて話します。 PURIへの不満 Common LispにはURIを扱うライブラリとしてずっとPURIが使われていました。 僕も詳しい経緯は知らないのですが、元々Allegro CLにあったURIライブラリを処理系可搬にしたのがPURIのようです。元となったAllegro CLのURIライブラリはCopyrightが1998年からになっており、かなり古くからあるようですね。 古くからあり広く使われてきたからと言って、不満がないわけではありません。 最もよくある不満は、Unicode対応がないこと。PURIで、URLエンコードされているUnicode文字列をデコードすると文字化けするのです。 これだけならばURLデコードにPURIを使わなければいい、という話ですが
Day 15: Woo - 八発白中
これは fukamachi products advent calendar 2016 の15日目の記事です。 今日はWooについて話します。 これがあらすじです。 WookieがNodeより遅くね？→プロファイル→http-parseが遅い→PRいくつか投げる→でも遅い→fast-http公開→Wookieまだ遅い→ClackベースのサーバWoo公開→まだ遅い→これってlibevent2で詰まってね？→libuvへ、みたいな流れでした— fukamachi (@nitro_idiot) 2014年11月2日 twitter.com Wookieの高速化 Wookieのボトルネックを解消してもNode.jsのパフォーマンスには今一歩届かない。そこで使っているイベントライブラリのlibevent2が遅いのではないか？という疑念が生まれました。libevent2がボトルネックならば、libev
Day 14: fast-http - 八発白中
これは fukamachi products advent calendar 2016 の14日目の記事です。 今日はfast-httpについて話します。埋め込みツイートが多いですが手抜きではありません。 Common Lispは高速か Common Lispは高速だという話を界隈ではよく聞きます。噂によればC++やCよりも高速なプログラムを書くことができるとさえ言われています。 Cで書くコードの方がCommon Lispで書くより速いって人がいたら、それは彼のCの技量が高すぎるってことだね。 “If you can't outperform C in CL, you're too good at C.” — Eric Naggum 昨日紹介したwebsocket-driverを書いたとき、好奇心からCommon Lispの実行速度というのはどれほどのものだろうと計測してみました。比較対象
Day 13: websocket-driver - 八発白中
これは fukamachi products advent calendar 2016 の13日目の記事です。ようやく折り返し地点ですね。 今日はwebsocket-driverについて話します。 小さなライブラリではありますが、その後の話の発端となるライブラリなので紹介します。 WebSocket Clackにより通常のHTTP通信を行うWebアプリケーションは作れるようになりました。しかし、よりリアルタイム性の強いもの、たとえばチャットやゲームのようなアプリケーションを作るには貧弱です。 たとえばWebSocket。TCP上のプロトコルであり、通信時の不要なオーバーヘッドが少なく効率的でリアルタイム性の高い通信プロトコルです。 ClackでWebSocketを使う方法はなく、使えるとすればHunchensocketというHunchentoot拡張くらいでした*1。 Socket.IO
Day 12: Qlot - 八発白中
これは fukamachi products advent calendar 2016 の12日目の記事です。 今日はQlotについて話します。 背景 はてなを退職することが決まってから、今までできていなかった開発時間を取り戻すかのようにCommon Lispを書き続けました。当時は起業する気でいたのですが、まだまだWebサービスを作るために足りないライブラリはいくつもあったからです。 ここから数日間のアドベントカレンダーのプロダクトはこの期間に作られたものです。どれも必要でありながら手がつけられていなかったものです。 Quicklispをプロジェクト毎に Quicklisp のβリリースから3年以上経ち、もはやQuicklispはCommon Lispの開発にはなくてはならないものにまでなりました。 しかし、問題もあります。アップデートが月に一回なので最新のリリースを使えるようになるまで
Day 7: CL-DBI - 八発白中
これは fukamachi products advent calendar 2016 の7日目の記事です。 今日はCL-DBIについて話します。 フレームワークバトルは次のステージへ Cavemanに一定数のファンがついた頃、Star数がRESTASに並びました。そのとき僕はうれしくて、@snmstsさんに言いました。「佐野さん！CavemanがようやくRESTASを超えたよ！」 すると佐野さんが言ったことはCommon Lispのフレームワークの歴史的な一幕です。 「もうCommon Lispのフレームワーク同士で争っていても仕方がない。他の言語と比較して優位性が出せなければ」 他の言語のフレームワークと比較してCavemanはどういった利点があるのか、ということを言えなければCommon Lispの導入など到底できないということです。 なんでPerlを書いてるの？ はてなで働いている
Day 11: Integral - 八発白中
これは fukamachi products advent calendar 2016 の11日目の記事です。 今日はIntegralについて話します。 このライブラリは現在非推奨ですが、歴史として重要なので取り上げます。 Common Lispとデータベース Cavemanを作ってから課題に感じていたデータベースとの連携についてですが、それまでのCommon Lispコミュニティにもいくつかプロダクトがありました。 一つはElephant。これはバックエンドがBerkeley DBであることが想定された設計で、CLOSオブジェクトを永続化できるという高度な抽象化を行なっています。欠点はBerkeley DBがフリーなライセンスではないこと。バックエンドとしてMySQLやPostgreSQLも選べますが、実行効率は落ちるでしょう。 さらにはRucksack。これもElephantのような永
Day 6: circular-streams - 八発白中
これは fukamachi products advent calendar 2016 の6日目の記事です。 今日はcircular-streamsについて話します。 circular-streamsとは これまでのプロダクトとは違ってcircular-streamsは裏側で使われているライブラリなので知らない人も多いと思います。 Common Lispのストリームはreadを始めて一方向に読み込みを進めます。一度readしたものは基本的に戻すことはできません。ストリームの終端まで来るとEOFになります。 この性質は他の言語でも一般的なものだと思われます。けれど、複数のコードから一つのストリームを共有するような場合に問題になります。なぜなら先に走ったコードがストリームを読み終わってしまうと、もう一方がストリームを読みに行ってもEOFが帰ってきて読み込めないからです。 これはClackのアー
Day 5: ningle - 八発白中
これは fukamachi products advent calendar 2016 の5日目の記事です。 今日はningleについて話します。 Cavemanをもっと小さく CavemanはマイクロWebフレームワークではありましたが、一般的なものと違ってプロジェクト雛形生成機能がついていました。 PerlのAmon2から影響されて作られたので当然と言えば当然なのですが、RubyのSinatraやPythonのFlaskのようにまずは1ファイルでさらっと書いて起動できるといった手軽さに比べると鈍臭く感じてしまいます。 これはCavemanが悪いわけではありません。他のフレームワークがURLディスパッチャしか提供していないのに対し、Cavemanはテンプレートエンジンとの連携や環境による設定の切り替えなども含まれ、プロジェクトのディレクトリ構造がある程度固定されるのです。 けれども仮に、
Day 3: Caveman - 八発白中
これは fukamachi products advent calendar 2016 の3日目の記事です。 今日はCavemanについて話します。 Clackに対するコメント Clack のリリースエントリは僕にとってはかなりの反響がありました。 その当時の記事についたはてなブックマークコメントで面白いものがあるので紹介します。 この id:kdaiba さんのコメントは全く的を射ていて、賞賛でもなく批判でもありません。そして僕自身もClackがゴールだとは微塵も思っていませんでした。 Webフレームワーク 次に必要なのはWebフレームワークです。Clackを直接使うこともできましたが、やはりどのアプリケーションにも共通の部分というのはあります。たとえばURLディスパッチャ。それからテンプレートエンジンとの連携。環境による設定の切り替えなどがそうです。 僕はすぐにWebフレームワークの開
Day 2: Clack - 八発白中
これは fukamachi products advent calendar 2016 の2日目の記事です。 今日はClackについて話します。 YAPC Asia 2010 keynote 僕が最初に学んだプログラム言語はPerlでした。その後PHPでのアルバイトを経験しましたが、好きな言語はやはりPerlでした。 最初に参加したカンファレンスはYAPC::Asia 2009だったと思います。まだPerlを始めて数年の若者で、技術力なんて吹けば飛ぶほどのものです。 当時はPerlにもまだ勢いがあり、YAPCは日本最大規模のカンファレンスでした。いろんな人が入れ替わりでPerlの話をし、ある人は自分のプロダクトのこと、ある人は会社での運用について、またある人はPerlの言語自体のことなど、内容はさまざまでした。そのとき受けた刺激は僕のプログラミング活動に大きく勢いをつけ、いつか自分も壇上に
Day 1: Prove - 八発白中
これは fukamachi products advent calendar 2016 の1日目の記事です。 最初なのでこのアドベントカレンダーの説明をしておくと、僕が今まで作ったプロダクトをネタとして年代を追って話をするというとても気楽なものです。酒でも飲みながら昔話を聴いているというつもりで毎日お付き合いください。 始まりはShibuya.lisp Hackathonで 僕が最初にCommon Lispライブラリを作ったのは2010年の10月でした。 ある日曜日、青山にあるセキュリティの厳重な日本オラクルのオフィスを借りてShibuya.lisp Hackathon #1というイベントが開催されました。主催はShibuya.lispの運営の1人のyshigeruさん。当時はオラクル社員だった@ymotongpooさんが会場の案内をしてくれたことも覚えています。 その頃の僕はCommon
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Day 24: Mito - 八発白中
Day 22: cl-coveralls - 八発白中
Day 17: smart-buffer - 八発白中