Emacsからlemに移行した - 八発白中
ずっとEmacsをメインエディタとしていましたが、先月lemに移行しました。 https://github.com/cxxxr/lem lemはCommon Lispで書かれたエディタです。 「なんでLem使わないの？」って訊かれたから、試してうまく動かなかったところを具体的にリストアップしたら凄い勢いで改善されててだんだん使わない理由がなくなってきてる。外堀埋められてる感ある— fukamachi (@nitro_idiot) 2018年7月9日 そもそも自分はCommon Lisperだしlem使うほうが資産がCL界に降りてきて良いよな、という考えもあり使いたい気持ちはありました。 vi-modeさえまともに動けばまあ他の不便は我慢できるか、という状態だったので、vi-modeのバグを上げて修正と機能追加をしつつ使い始めてみました。 結果、なんとか使い続けられています。 lem使い始め
語らるるべき日本のCommon Lisper達 - 八発白中
Lispのエッセイのようなものを継続的にブログに載せていこうとしたのはいいのだが、立て続けに2つ載せたきりなかなか続かない。これはその3つ目のものである。 今回は「人」に焦点をあてて、Common Lispコミュニティで現状活発に活動している人を紹介する。挙げてみると、どうしてもそれなりに親交のある人に偏っている。またいずれ時をおいて第二弾でも書くかもしれない。 佐野匡俊 佐野さんは僕がLispを始めた頃からの知り合いである。最初に会って話をしたのは2010年に米国のリノというカジノ街で開催されたInternational Lisp Conferenceで、その後も国内外のカンファレンスでよく顔を合わせた。 今回紹介する中では年長で、100kgを超える縦にも横にも大きな体つきをしている。「待ち合わせは佐野さん前」と言われるくらい、人混みの中であろうと遠くから見てすぐ分かる。 だが、兄貴分と
高速な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のO/Rマッパー「Integral」を作りました - 八発白中
「O/Rマッパー」や「ORM」と聞くだけで顔をしかめる人もいらっしゃいます。たぶん過去にひどい目にあったんでしょうね。その大きな理由の一つがパフォーマンスでしょう。 一昨年のYAPC::Asiaに参加したとき、ORMは使うなという話を4回くらい聞いたのが印象的でした。DBのデータはハッシュで返すか、DBIをそのまま使うほうが良いと。弊社でもパフォーマンス上の問題をわかりづらくしてしまうことから、ORMを使用しないプロジェクトがいくつかあります。 まあ、そりゃDBI使うほうが高速に動くとは思います。 しかし、僕が使っているのは実用的な言語であるCommon Lispです。実行効率と抽象化がとても得意な言語です。さらに優れたオブジェクトシステムであるCLOSも仕様に含まれています。 そこで、既存のO/RマッパーにCommon Lispらしさを加えてみるとどうだろう。 そう思って作ってみたのが、
Common LispのWebフレームワーク「Caveman2」を作りました - 八発白中
僕がClackを作ったのは2年9ヶ月前。Webフレームワークの「Caveman」をリリースしたのはその2ヶ月後だった。 Cavemanを作った頃、僕はアリエルネットワーク株式会社にいた。松山さんと開発していた試作プロダクトのために、並行して開発していたWebフレームワークがそれだった。そのときはCommon LispでのWebアプリケーション構築方法は洗練されておらず、アプリケーションを作りながら、手探りでフレームワークを作っていたことを今でも思い出す。 結局作っていた社内プロダクトは世に出なかったのだけど、それから1年後、会社が変わっても僕はCommon Lispでのプロダクトを作っていた。 ある日Cavemanを使っていたとき、一つのアイデアが浮かんできた。Cavemanは最初にプロジェクトのひな形を作る必要がある。けれど、PythonのFlaskのようなフレームワークではそれすら必要
Quickdocs.org で学ぶCommon LispのWebアプリ運用ノウハウ - 八発白中
先日、QuickdocsというWebサービスを作りました。 Lispライブラリのドキュメント集約サイト「Quickdocs.org」を作りました - 八発白中 アプリ部分はほとんどCommon Lispで書かれています。今までもいくつかCommon LispでWebアプリを書いたことはありますが、公開されたWebサービスはこれが初めてです。 公開当初は半日に1回落ちたり、表示が変になったりしていました。そこで2週間ほどかけて、不具合の原因を突き止めたり、それを修正して堅牢にしたり、レスポンス速度を改善したりしてきました。 Common LispのWebアプリの運用ノウハウが少し溜まってきたから車にはねられるなどする前に共有したい 2013-03-06 02:06:20 via web 試行錯誤を繰り返してきており、伝えたいことも多いです。書いてみるとかなり雑然としてしまったのですべての人向
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、および依存ライブラリです
Common Lispの軽量フレームワーク「ningle」を作りました - 八発白中
Clackベースの軽量Webフレームワーク「ningle」を作りました。 ningle by fukamachi 背景 Clackベースのフレームワークとしては既に「Caveman」がありますが、CavemanはPerlのAmon2に影響を受けたこともあり、プロジェクトの拡大に伴う拡張性を損なわないために多くのことをします。 たとえばCavemanにはprojectという概念があり、開発環境と本番環境でロードするconfigファイルを分けたり、どのようにビルドするかを定義したりできるようになっています。 複数のClackアプリを定義することもでき、最初はPCサイトのみ作っていたけど半年後にスマートフォン用サイトも作ることになった、という場合などにも、アプリの継承などですぐに対応できるようになっています。 Clackのミドルウェア利用も記述を少し追加するだけです。 けれど、これらの拡張性のた
Common LispのWebアプリケーションを社内運用してみた - 八発白中
今月の初めに弊社はてなで開発合宿を行いました。2泊3日の合宿の中でチームを組み、テーマを決めて開発をし、最後に各チームがプレゼンをする、というものです。成果物は今後のサービス開発に生かされます。 僕のチームはバックエンドがCommon Lisp、フロントエンドがCoffeeScriptで、お互いが独立していてAPIでのみ通信する設計のWebアプリケーションを作りました。僕とhitode909とswimy1113の3人の最小チームでしたが、最後のプレゼン投票で優勝できました。 ↓ 優勝したときの図。 東北で開発合宿を実施しました - はてな広報ブログ 左の灰色のはてなパーカーを着てるのが僕です。 Common Lispで書かれたアプリケーションが社内1位ってのはかなり夢があります。 合宿が終わってからも継続して開発を続けており、そろそろ数週間が経ちました。ので、この辺りでCommon Lis
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
