I am Cruby!

2012-02-03

RubyのBitmap Marking GCによるメモリ使用量の改善（意訳）

そういえばBitmapMarking GCについて@m_stさんにInfoQで質問をうけました。

だいぶん残念な英語を返したのですが、向こうのインタビュイーさんの方でいろいろ修正していただいたみたいです。感謝感謝。
で、ちと意訳ですが以下に日本語訳も書いておきます。
ちょっとだけ補足したいこともあったので。

InfoQ Japanの方でも日本語訳していただいてます。ありがとうございます。
~~CGの話も追加してもらったみたいですね。~~

RubyのBitmap Marking GCによるメモリ使用量の改善

原文

 Narihiro Nakamuraによって書かれたGCの最大停止時間を短くするLazy Sweep Garbage Collector(参照:InfoQによるレポート) が、Ruby1.9.3には導入されている。
最近、Narihiroはcopy-on-wirte(CoW) friendlyなBitmapMarkingGC（以降、"bmap"と呼ぶ）を実装し、提案した。
これはRuby Enterprise Edition(REE)のcopy-on-write-friendly GCと似たものである。

POSIXのfork()システムコールでは、子プロセスとその親プロセスでメモリを共有しており、メモリ内の一部が変更された場合にその部分を子プロセスにコピーする方式により、メモリ使用量を削減している。
しかし、残念ながら現在のRubyのGCではこの仕組みはうまく動作しない。

Rubyはマーク・スイープGCを採用している。
このGCでは、はじめにすべての生きているオブジェクトを走査し、マークを行う。
マークではオブジェクトのヘッダフィールド上のFL_MARKフラグを立てる。
その後、すべてのオブジェクトをもう一度走査して、すべての死んでいるオブジェクトのマークを外す。
これの問題点は、CoWのセマンティクスを破壊することだ: マークするすべてのページがDirtyになってしまう.

InfoQはNarihiroのbmap実装が現在のLazySweepGCよりも改善されているのかを質問した。

Bitmap Markingアルゴリズムの良い点は以下のとおりです。

 - ビットマップは、オブジェクトヘッダにマークビットを置くよりも、ビットを密集した領域に格納する
   - 高い局所性
 - マークはオブジェクトを変更しない。そして、スイープは生きているオブジェクトを変更しない。
   - CoW friendly, ダーティキャッシュラインが少ない
 - マークビットのクリアにmemset()が使える（訳注: マークビットが一気に消せる）
   - スイープがちょっぴり早い

CRubyの事情ではCoW firendlyがもっとも重要だと思います。
BitmapMarkingはLinuxでfork()を使っているようなプログラムでメモリ使用量を改善するものです。
で、CRubyでは本当の並列のパフォーマンスを得るためにfork()を使わないといけません。
さらに、CRubyはすでにfork()を使った多くのライブラリを持っています（Unicorn, Resqueとか）

（訳注: あんまLazySweepとは関係ないです、とも言いたかったんですけど…深刻な英語力不足が…）

InfoQ:
LazySweepGCはスループットを悪化させますよね。
話によるとbmapもまたスループットを少しだけ悪化させると聞いてます。
bmapは現在のGCを置き換えようとしていますか？　
それともユーザ/開発者が設定で選択できるようなものですか？

私のプランは「Bitmap Marking GCをデフォルトのGCする」ものです。
あなたは「bmapは*少しだけ*遅くなる」と言いましたね。
それはたしかにそうですが、私はその速度低下はすべての人にとって許容範囲だと考えています。
なので、ユーザは設定のようなものをBitmapMarkingに対して必要としない、と考えています。

（訳注: あんまり速度低下ないから、標準にしても困らない。というより、ユーザに選択させる際には何らかの強いデメリット・メリットがある場合に限られると思っていて、今回の場合はデメリットが少ないから標準でいいんでは、と思った次第です）

InfoQ:
あなたはBitmap Markingを組み合わせたParallel Marking GCを作るつもりだとおっしゃってましたね。
大幅にGCが高速化するように思えますが、あなたはこれがどれくらい高速化するか（もしくはどれくらい速度低下するか）について何か考えをもっていますか？

実は、Bitmap Marking抜きのParallel Marking GCは作っています。
2コアのマシンで、いくらかのケースでは、総GC時間を40%くらい改善することできました。
Bitmap MarkingとParallel Marking GCを組み合わせると, たぶん少しだけ改善率は落ちるかもしれません。

すでにParallel Marking GCの詳細についてはRubyConfUS 2011で話しています（ビデオ[1]とスライド[2]）。

MatzはすでにこのGC パッチをtrunkにコミットしている。そのため、これは次のリリース（たぶん2.0）に含まれるだろう。

（訳注: 細かい点ですが実際にはまつもとさんに許可をもらって、私がコミットしました）

Permalink | コメント(0) | トラックバック(0) | 20:46

2011-12-31

ゆく年、くる年

2011年。いい年でしたね。
2012年。いい年ですか？
早いものでもう5年目のブログ納めかぁ。

今年の目標は達成できたか

今の本を書き上げる

おぉ書き上げましたね -> 徹底解剖「G1GC」アルゴリズム編 - 達人出版会

もう1冊書き始める

おぉ書きはじめましたね -> 徹底解剖「G1GC」実装編（執筆中）

CRubyGCの改善パッチを1つ

並列GCのパッチはありますね。出してないけど…。
ビットマップ作ってて、もうそろそろだそうかなぁ。

GC ライブラリに着手

結局着手できなかったなぁ。
というかもうCでGC書きたくないんだよね路線を狙っている。

継続的な英語の勉強

よくがんばりました。

貯金・運用

貯金はできてるけど、運用はあんまりできてないなぁ。
一応やってるけど面倒なんだよねぇ。

RubyKaigiへの参加・発表

達成！！

RubyConfへの参加・発表

おぉ、達成。よくがんばったな。調子に乗って南米にも行ったし！！

楽しく健康に仕事する

個人的にはいろいろ楽になったなぁ。

今年も上のリスト以外にもよくがんばったというか、毎年えらいよねー。

来年の目標

今の本を書き上げる
もう一冊書きはじめる
CRubyGCの改善パッチ出したい
継続的な英語の勉強
『The Art of Multiprocessor Programming』『GC Handbook』読み切りたい
PyPyのGC理解したい
- 自分で一個書いてみたい
ytjitいじってみたい
暇でいたい
札幌RubyKaigiに行く

では、みなさん、よいお年を :D
（ブログ納め）

Permalink | コメント(0) | トラックバック(0) | 00:43

2011-12-28

「寄付が溜まったら本気出す方式」の考察

黙々と執筆する前に。
長めの記事になりましたが、今後同じ事をしたい人のために記録を残しておきます。

やったこと

目標金額決定

20万円という目標金額を立てました。
GC本の総収入から、執筆する予定のページ数分をみて、だいたいこれくらいかなーとざっくり計算しました（が、これはあまりよくないと思ってます）。
「寄付する人は何人くらいになるかなぁ」というのをG1GC本の販売数を見て予想しました。

寄付の受付場所。寄付の目標金額を設定したかったので何がいいかなぁと考えてました。
最初は READYFOR? (レディーフォー) | クラウドファンディングなども検討したのですが、審査とか期間は私には合わないのでやめました。サポートはいいなぁと思ったのですが。
結局、自由度は高いけどサポートのないPledgie — Helping you help others.にしました。

あとで気づくことになるのですが、Pledgieは3%手数料を取るようになっていて、githubとの連携も切れていました。
まぁそれはいいのですが、紹介ページで日本語が書けないのは辛かったです…。

準備したこと

github リポジトリ

https://github.com/authorNari/g1gc-impl-bookを用意しました。
issue登録できて、Web上で編集してpull request送れたりするのでだいぶん便利だなぁと。
最終的に読者の感想とかpull requestでもらえるようにしようかなぁ、とも考えてます。

公開用のWebサイト

徹底解剖「G1GC」実装編（執筆中）
github側と差異がないようにしました。
WebサイトのトップページはREADME.mdと一緒で、サイト上の原稿はgithubのものを同期しています。
同期の方法はWebサイトをgithubで管理してpush時に自動的に同期する方法 - 古橋貞之の日記を参考にしました！

前半分の原稿

とりあえず試してみたかったので、かれこれ2年くらい持ってた書きかけの原稿に手を加えて公開しました。
ある程度書いてからじゃないと信憑性が薄いし、寄付する人もどういうものか想像できず、寄付しづらいのではないかと思います。

epub,pdfなど

Web上のページはgithub上リポジトリと同期してるんですが、epubやpdfなどはそうしてません。
書きかけの途中のものをpdfで見てもなぁと思ったからで、例えば1章書けたとか、ある程度の区切りで公開していく予定です。

宣伝方法

ブログ記事

意図を書いたりしました。
「ある程度寄付が溜まったら本気出す」方式の執筆を試してます！ - I am Cruby!

ついった

私のアカウントで途中からお礼を言うようにしました。
TL上で鬱陶しく感じる人もいるだろうなぁと思って最初は遠慮してたのですが、まず寄付した人に感謝の気持を伝えたかったので、その気持ちを優先しました。
アクセス数を見ると、お礼のついーとを見て本書の存在を知った人が多いようです。

いいねボタンとかそういうやつ

をトップページにおきました。

データ

総人数	38名
総額	￥203,000
手数料(pledgie+paypal)	-￥15,878
手取り	￥187,122
1人平均	￥5,342(!!!)
1万円以上	8名
9999円～5000円	5名
4999円～3000円	7名
2999円～1000円	14名

だいぶん平均がおかしなことになっています。紙の本よりもだいぶん高いですね。

多くの方は千円以上の値段を付けてくださったようです。ありがとうございますッ。
上位人の寄付金は本当にすごくって、特に@yamazさんは目標額の1/4以上あったような…。

ありがとうございます…。

スポンサーの皆様

スポンサーのみなさま
を見ると、かなりの方がGC本購買者であることがわかります（私には見えるッ）。
また、私のGCやRuby関連の活動で知り合った方々がほとんどです。
RubyKaigiやGC本執筆の影響が強いですね。感謝…。

日頃の行いを積み重ねることは大事だなぁと思いました。GCバンザイ！！

推移

1のあたりで公開しました。
2は「ある程度寄付が溜まったら本気出す」方式の執筆を試してます！ - I am Cruby!を書いたタイミングです。
3はわたしが「xxさんに寄付いただきました！」のお礼ツイートをはじめたときです。
4はソーシャルスポンサーゲームが開始した時間です。

ソーシャルスポンサーゲームの熱狂ぶりが…（ごめんなさい）。

目標金額達成するまでもっと時間がかかると私は思っていました。
ま、まさか3日で集まるとは…。

KPT

Keep

Twitter上でスポンサーになってくれた人にお礼する
githubと連携した自動デプロイでWebページがすぐに更新できたのでよかった
スポンサーリストのソート順(RubyKaigi流)
- 寄付しなくてもリストを見るだけでわりと楽しい
  - 私はRubyKaigiのときそうだった
- ソーシャルスポンサーゲーム（！！）
途中でスポンサーリストにアイコン付けたのはよかった
- もっと楽しくなるから

Problem

目標金額の根拠が薄い
スポンサーリストの脳内ソート問題がけっこうつらい
目標金額が高すぎるといつまでたっても執筆に取り掛かれない問題起こりそう

Try

目標金額はちゃんと見積もった方がいい
- 「何がどれくらいかかるから、この金額にしました」という根拠が欲しい
脳内ソートやめてバグを減らす

Permalink | コメント(2) | トラックバック(0) | 11:19

2011-12-27

ある程度寄付が溜まったので本気出します

以下に書いてきた話の続きです。
徹底解剖「G1GC」実装編（執筆中）
「ある程度寄付が溜まったら本気出す」方式の執筆を試してます！ - I am Cruby!

今日、いただいた寄付の総額が目標金額に達しました。
正直まだまだ時間かかかるかなーと思っていたので、驚いています…。

掲題の通り、寄付がある程度溜まったので本気出します！

スポンサーのみなさまありがとうございます！！
みなさんの寄付金に恥じないようなコンテンツを作りたいと思います！！
スポンサーのみなさま

取り急ぎお礼まで。

Permalink | コメント(0) | トラックバック(0) | 23:05

2011-12-26

「ある程度寄付が溜まったら本気出す」方式の執筆を試してます！

「私が昨日公開した書籍は無料だと言ったな、実はあれは嘘だ。」
『徹底解剖「G1GC」実装編（執筆中）』無料公開 - I am Cruby!
徹底解剖「G1GC」実装編（執筆中）

リンクをたどった方はお気づきかと思いますが、本書は寄付を募る形になっています。
「もし続きが読みたかったら寄付をいただけませんか」というやり方です。
そして、寄付者の名前を本に載せて、Contributeとして明記するようにしています。

なので、タダだと思う人はタダだし、そうじゃない人にはそうじゃないみたいな。
# 何をいっているのかわからないと思うが。

すでに寄付いただいた方もいらっしゃいます！本当にありがとうございます！！！
スポンサーのみなさま
# こういうののお礼ってどうするのがいいのかなぁ。
# twitterで直接お礼するのもなんか違うのかなぁと思って…。

この方法は以下から影響をうけてやってみました。

「千人の忠実なファン」: 七左衛門のメモ帳の「大道芸人方式」
大江戸Ruby会議01 - Regional RubyKaigiの「お代は見てのお帰り」
日本Ruby会議2011(7月16日～18日)の「個人スポンサー」

なぜこのような方式をとったかという意図ですけど…。
「とりあえずやってみるか」という実験的な試みなので私自身も暗中模索状態なんですよね。
とはいえ、説明不足感はあるので今のところで吐き出してみます。

技術書についていろいろ思うこと

きっとまとまらないとは思いますが、正直に思っていることを書いてみますね。

諸君、私はマニアックな本が好きだ

『徹底解剖「G1GC」アルゴリズム編』発売！！ - I am Cruby!の備考で書いたことです。
要約すると

私はマニアックな本が好きだ
マニアックな本は需要がないので書いても（あまり）儲からない
ただ書くのはすごく時間がかかる
でも私はそんな本を沢山読んでみたい

となります。

著者に適切な労働の対価が入るだろうか？

ものすごく時間のかかる本の執筆に対し、それに見合う報酬は得られるでしょうか。
私が書いた今までの書籍では時給換算すると大分悲しい感じになります。
これはたぶん私だけじゃなくって、いろんな人がそうなんだと思うのですが。

いやー「コンテンツが悪いからだ。しょうがない」と言われればそれまでなんですけど（テヘヘ）。

レビュアのみなさんにも無償で質の高いレビューをしてもらっているのに、こちらからは何もできなかったしなぁ…とかもありますね。

とてもよい勉強になる

ここまで書くと私が金の亡者すぎて怖くなった方もいらっしゃるでしょう。
ですので、亡者っぽくないことも書いておくと、本を書くことはとても勉強になります。
日本語の勉強や、対象の技術について深く勉強できます。
これはお金では得られない貴重な経験ですし、やりたいと思う人は気軽に体験してもらいものだと思います。

しかも、本を売るとお金も貰えますしオイシイですよね、うっへっへ（あっ）。

本の値段って何だろうか？

ここまで考えると、「じゃあ本の値段を高くしてちゃんと報酬得たろうかい」と思うわけです。
でも、『ほん』の値段ってなんで決まるんでしょうか。

たぶん出版側からすると紙代とか人件費などの経費で決まると思います。

でも、読者側からするとそんな客観的な値段じゃなくて、主観的な値段なんですよね。
つまり「自分にとってこの本はXXXX円」と考えると思うんです。
とすると、読者が買う1冊の値段は読者が決めるのが自然な気がします。

ただ、それだと出版側に確実な報酬が約束されません。
それで出版側が欲しいと思う全体の報酬を定義して、1冊の本代は読者の人に決めてもらう方式がいいのかなぁと思いました。

まとめ

結局うまくまとまりませんでしたが（あぁ、なにがいいたいのか…）。
でも、上記のようなことをいろいろ考えた結果にとりあえずこういうことやってみました。

今回の実験的な試みの成功・失敗・停滞にかかわらず、すくなくとも何らかの結果は出ると思いますので、それを有用なデータとして使ってもらえると嬉しいです :D

こうならないようにがんばります。

Permalink | コメント(0) | トラックバック(2) | 18:33

2011-12-25

『徹底解剖「G1GC」実装編（執筆中）』無料公開

今年はちゃんとプレゼントを用意してみました。
詳細は以下のページをご覧ください。
徹底解剖「G1GC」実装編（執筆中）

メリークリスマス！！

Permalink | コメント(0) | トラックバック(1) | 00:56

2011-12-23

OpenVPN経由のなんちゃら

いろいろほっといたのだが時間ができたので調べてみた。

社内のOpenVPN サーバ経由でインターネッツ上の特定のホストにアクセスしたかった。
tap0でブリッジングなので、以下のコマンドで指定のホストに対するルーティングを変更する。

$ sudo route add -host xxx.xxx.jp gw 192.168.x.x dev tap0

ゲートウェイはOpenVPN サーバに向けた。

あとは会社のSMTP サーバからメールが送信できない件。
いろいろ調べた結果以下のことが判明。

SYN送ってもACK送り返してくれない問題
- そもそもSYNが相手に届いてないんじゃね？
- Outbound Port 25 Blocking - Wikipediaでした orz
SMTPはどうやって認証するんだっけ（前はOpenVPNで社内のメールサーバに繋げてたので）
- 社内wikiを読むとPOP before SMTPが使えるらしい
- Thunderbird8.0でGet before Sendを入れて対応。

届くようになった、わーい！！

Permalink | コメント(2) | トラックバック(0) | 13:31

Ubuntu11.10でReVIEWを使ってPDF生成

まずはLaTexの環境を揃えればならぬ。
ReVIEWで生成するtexファイルはデフォルトでutf-8。いや --outencoding=EUC のオプションが指定できるんだけど誰も試してないので動かないはずだ（ｷﾘｯ

ところがUbuntu11.10で提供されているパッケージはTexLive2009なのだった。
Ubuntu -- Details of package texlive in oneiric
TexLive2009は-kanji=utf-8のオプションを受け付けない。

最近のTexLive(2011)では-kanji=utf-8 オプションを受け付けてくれるそうなので、そっちを導入することにした。
Hashnote - UbuntuにUTF8をサポートしたTeX Live 2010をインストールした日記

install-tl.shを実行。けっこう時間はかかるがちゃんと入るはず。
あとはPATHを通して以下のコマンドを実行すればよい。

$ review-pdfmaker config.yml

config.ymlはReVIEWの話なので自分でちゃんと作れ。
kmuto/review - GitHub

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

2011-12-13

ソースコードを読むときの3カ条

GCを読んでいく上で実際に使っているソースコードの読み方を紹介してみます。
個人的に大事にしているのは以下の3カ条です。

小さい疑問から先に倒すべし
正しいツールを選択するべし
必ずメモするべし

小さい疑問から先に倒すべし

なんとなく読みたい時は疑問の分析から

ソースコードってなんとなく読みたくなるということもありますよね。
ただ、その状態でいきなり対象のソースコードを読みはじめるのはよくないです。
小さなプロジェクトだと問題ないかもしれませんが、大きなプロジェクトだと時間がかかりすぎます。

そういうときは最初にドキュメントなどを読んでみましょう。
そうすると、対象のソースコードが持つ機能が書いてあります。
機能がわかれば「どうやってこれを実装しているのか？」という疑問が浮かびます。

たとえば、G1GCの場合は論文がすでに公開されていたので、最初に論文を読みました。
読み終わったあとに論文内の疑問をメモして「こいつらを倒そう」という目標を立てました。

大きな疑問から小さな疑問へ

上記の例はわりと特殊な例です。
普通はある程度漠然とした疑問があってソースコードを読みはじめますので、大体がまず粒度の洗い「大きな疑問」を持っています。
上記で洗い出したものは、その大きな疑問にあたります。

大きな疑問をメモったら、それからソースコードを読んで行きます。G1GCの場合は

退避はどうやる？

などというすごい漠然とした疑問を何個かもってました。
ソースコードの中にはだいたい大きな疑問を扱う関数があったりするので、そこから読んで行きます。

実際に読みはじめると、関数内で何をやっているのかよく分からない処理がでてきます。
「なぜこの処理が必要なのか？」とか。もっと具体的に「この関数はなんの処理をしている？」とか。
そのようにして「小さな疑問」を沢山メモします。

そして、そうやって出てきた「小さな疑問」を優先して倒します。

小さな疑問をすべて倒すと大きな疑問も倒せている

このように深さ優先的に疑問を倒すと、いつの間にか最初の大きな疑問も倒せています。
簡単にまとめると、以下の流れ図になります。

大きな疑問 =(分析)=> 小さな疑問 =(理解)=> 大きな疑問

小さな疑問は短時間で解決できるので、大きな疑問を解くよりも時間を有効に活用できます。

正しいツールを選択するべし

Emacs（手に馴染んだエディタ）

当たり前ですが、手に馴染んでいるものでコードを読むのがいいでしょう。
私はEmacs使いですから、Emacs上で全部のコードを読んできました。

gtags

関数を探索するのに便利。関数の呼び出し元もわかります。

git grep

gtagsで拾い切れないものもあるので、そういうときはgit grepを使います。
コメントの中の文言とか調べたかったりするので。

動作を調べる必要があるときに使います。
ただし、これは最終手段です。読んですぐに理解できるものなら実際に動かして調べる必要はまったくありません。どうしてもわからないときに使いましょう。
よくわからないプロジェクトのビルドは面倒ですし、対象の関数を動かすのはもっと面倒ですから。

必ずメモするべし

面倒でも読んで理解した部分は必ずメモします。絶対に忘れますよ。絶対に忘れますよ。
忘れるとまたそこから理解しないといけないので、モチベーションが下がります（モチベーション大事）。

私はrubikitchさんのorg-remember-code-readingを使っています。
org-mode + remember-mode でEmacs内で瞬時にメモをする→コードリーディングに生かす・メモ検索する - (rubikitch loves (Emacs Ruby CUI Books))
まず大きな疑問の項目を作って、その下に小さな疑問の項目を作っていき、理解の過程とか結果とか、とにかく自分が忘れてほしくないものをメモします。
あ、この時、日付も書いておくと情報の古さがあとでわかって便利です。

メモしていくと「大きな疑問が解消できた！」という達成感も得られて、モチベーション低下を防げます。
また、メモすることで「俺はもうこれ忘れていい」というよく分からない開放感も得られます。

また、以下の理由から私はorg-modeを使っています。

対象ソースコードの特定の場所へのリンクを貼れる
メモ内の違う項目にリンクを貼れる

「このソースコードのこの部分の説明」とか書けて、あとでメモを見たときにすぐに対象の場所に飛ぶことができます。
さらに、emacs内（手に馴染んだエディタ）で完結して読めるので便利です。

上記と同様の機能があるメモツールであればorg-modeでなくてもいいでしょう。

注意

あくまで個人的なやりかたですから、参考にしてもいいですし、参考にしなくてもいいですよ、と。

追記

2011-12-07

ChipでWebページ上のコードを簡単に扱おう #advent11rb

Ruby

（Ruby Advent Calendar jp: 2011 : ATNDの7日目の記事です。昨日は@sakuroさんの/var/log/messagesでした。明日は@sato_ryuさんの500 Internal Server Errorでした。）

みなさんが有用なTIPSを記事に書いたり書かなかったりする中、私はChipというToolを紹介します。
Chipは私が今日(!!)リリースしたツールで、Webページ上のマイクロコードを管理するものです。

authorNari/chip - GitHub

インストール方法:

$ gem install chip

何に使うか？

Web上に書き捨てているコードは結構あると思います。ブログの記事上とか、gistとか。
そういうのをコマンドラインで管理できたら楽しいだろうと思い、作りました。
ちょっとだけ具体例を書いてみましょう。

「おれだけのモンキーパッチ貼っておきますね」

例えば A monkey patch — Gist をgistに作ったとします。
Chipを使うと以下のように使うことができます。

$ cat a.rb
require "chip"
require_chip "https://raw.github.com/gist/1417282"

p 1.hour

$ ruby a.rb
Installing...
/path/to/.chip.d/https:__raw.github.com_gist_1425982.rb
---
class Fixnum
  def minute; self * 60; end
end
---
Do you install above a program? [yes/no] > yes
60

ChipではWeb上に書き捨てられるモンキーパッチの不満を、それぞれ以下のように解決しています。

名前がない（わざわざつけるの面倒だから） -> URLを名前にすればいいじゃん
どこから拾ってきたものか忘れた -> URLを名前にすればいいじゃん
コピペするの面倒 -> URLを指定するだけ

「おれが作った読みにくいプログラム貼っておきますね」

二年前のmameさんの記事( Ruby とすてきな難読化 - まめめも)を参考にして簡単なRuby スクリプトを難読化するのは「Rubyistの登竜門」と勝手に言っておりますが、難読化したプログラムはやっぱりブログに貼りますよね。

私も以下のようなプログラムを書いてみました。

#chip

  eval(     %w|   put   s("   H3429el
l0     o6   ,_4   C52   h0i   98    62
63          0p2455!!2   952   0".gsub
(/     \\   d/,   '')   .tr   ("
  _",32    .chr   ))|   *''   )#

でも、わざわざコピペしないと動作が見れないというのは面倒です。

Chipを使うとコマンド一発で動作を見ることができます。
※preタグの中の先頭に"#chip"という文字列があるものを実行します。

$ chip run http://d.hatena.ne.jp/authorNari/20111207/1323185562

ライブラリのサンプルコードをブログ記事で見つけたときにchipコマンド一発で実行できたら素敵だなぁとか、考えています。

「おれが作った便利なプラグイン貼っておきますね」

ChipはChip自身によって拡張できます。ChipではWebページ上のコードを取ってくるやつ（Fetcher）を追加することができます。
例としてTwitterの発言をコードとして取得するFetcherを作ってみました。
Twitter status fetcher - GitHub

Install方法は以下の行を~/.chipに追加するだけです。

require_chip "https://github.com/authorNari/chip/wiki/Twitter-status-fetcher"

ほいで、Twitterを以下のコマンドで実行します。

$ chip run http://twitter.com/#!/nari3/status/142788923339444224 -f
Hello, world

おしまい

他にも面白い使い方ができそうです。
gemにするほどでもない極めて小さなライブラリはchipで管理できるなぁと思っています。
バージョン管理？ URLにバージョン情報があればいいんですよ :D

ちなみにChipは最近（←遅い）江渡さんの本を読んで思いつきました（内容とあまり関連がないけど）。
本当に素晴らしい本ですので、ぜひみなさん読んでみてください。

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)

作者: 江渡浩一郎
出版社/メーカー: 技術評論社
発売日: 2009/07/10
メディア: 単行本（ソフトカバー）
購入: 71人クリック: 1,172回
この商品を含むブログ (136件) を見る

Permalink | コメント(0) | トラックバック(0) | 00:32

2011-11-20

Ubuntu11.10に上げた

ubuntu

Thinkpad X220でUbuntu11.10に上げてみた。
Unityは使いたくないのでgnome-panelを入れる。

$ sudo aptitude install gnome-panel

初めて使ったときにフリーズしまくったからあんまりいいイメージがないんだよね…。

Wi-Fi遅い問題があったので、以下で対応。
だらだら備忘録: Ubuntu 11.10のWi-Fiが遅い
うまくいったので /etc/modprove.d/ に上記の設定を追加しておく。

ATOKを何とか使い続けてきたが、64bit環境でUbuntu11.10の対応は結構辛いので、今回をきっかけにmozcに乗り換えた。emacsも設定する。
いままで、ありがとうATOK！！

$ sudo aptitude install ibus-mozc emacs-mozc

AZIKの導入も簡単。
Ubuntu 10.10のuim-mozcでAZIKしてみた

英語環境で使いはじめた。gnome-tweek-toolを使ってフォントなどを変えたり。

おぉ、結構いい感じになった。

rdic周りでUTF-8からeucJPに変換する処理を付け加えた。

begin
  require 'nkf'
  def u2e(chunk)
    NKF.nkf("-e", chunk)
  end
end
...
  def get_selection
...
      str = u2e(str)

大分落ち着いてきた。Ubuntu11.04でたまに起きてたフリーズも今のところ起きていない。
あとはデュアルディスプレイでうまく動けばいいのだけど…。

Permalink | コメント(0) | トラックバック(0) | 16:26

はてなブログはじめました。

もしバッグひとつで海外旅行に行くなら - nari's blog
はてなダイアリーの方が今のところ便利だなぁ。

Permalink | コメント(0) | トラックバック(0) | 11:01