komagataのブログ

アクトインディ株式会社では自社Webサービスを作っています。

営業の谷くん「komagataさん、xxxをxxxする機能をサイトに追加することってできますかね？」

俺「（手のひらを上にし、人差し指と親指で輪を作り）コレ、さえ積めば思いのままだよ・・・。」

最低の大人や・・・。

JSAN - Joose.Manual
Joose is based in large part on the Moose system, which in turn borrows a lot of from Perl 6 object system, as well as drawing on the best ideas from CLOS, Smalltalk, and many other languages.

ジュース・・・だと・・・？

JSAN自体もそうだけどあまりにPerlフレンドリー過ぎると他の人には取っ付き辛くなってしまうかも。

JAUSEでのライブラリアップロードやパッケージングも最初は

「おー、CPANと同じだｗ」

と楽しんだけど、糞面倒臭くてそれ以降やってないもんなぁ・・・。

jonesforthを見てますが、分からないことが沢山あるのでまだ具体的に進んで無いです。

64bit版はquekさんが既に作られてるということで、JavaのJVMかFlashのAVM2への移植を取り敢えずの目標にしてやっていこうと思います。quekさんのchocoforthはnasmで書かれていて、実装方法がjonesforthはIndirect Threaded Codeなのに対してDirect Threaded Codeというので実装されてるところが違うみたいです。さっぱり分かりませんが、gasとnasmとがあると比べて見れるのでとても参考になります。

まず真っ先に疑問に思ったのが、helloworldはコンパイルできるのに、jonesforthは何故asでコンパイルするとエラーが出まくるのかということ。

$ as -o jonesforth.o jonesforth.S

大量に出るので先頭だけ見てみる。

$ as -o jonesforth.o jonesforth.S 2> error.log
$ head -n 3 error.log 
jonesforth.S: Assembler messages:
jonesforth.S:502: Error: too many positional arguments
jonesforth.S:503: Error: junk `//%eax points to codeword' after register

502行目付近はこんな感じ。

498 /* DOCOL - the interpreter! */
499         .text
500         .align 4
501 DOCOL:
502         PUSHRSP %esi            // push %esi on to the return stack
503         addl $4,%eax            // %eax points to codeword, so make
504         movl %eax,%esi          // %esi point to first data word
505         NEXT

.macroや//のコメントが怪しい気がしたけど、helloworldに入れても動くしgasのちゃんとした機能だそうです。何がいけないのかな？

一旦それは諦めてgccでのコンパイル時のオプションの意味を調べてみた。

$ gcc -m32 -nostdlib -static -Wl,-Ttext,0 -Wl,--build-id=none -o jonesforth jonesforth.S

gccは-v --helpとやるとサブプロセスのオプションも全部だしてくれるそうなので一つずつ調べる。

$ gcc -v --help | grep m32
(...)
  -m32                        Generate 32bit i386 code
(...)

$ gcc -v --help | grep nostdlib
(...)
  -nostdlib                   Only use library directories specified on
                                the command line
(...)

$ gcc -v --help | grep static
(...)
  -Bstatic, -dn, -non_shared, -static
                              Do not link against shared libraries
(...)

$ gcc -v --help | grep Wl
(...)
  -Wl,            Pass comma-separated  on to the linker
(...)

$ gcc -v --help | grep build-id
(...)
elf_i386: 
  --build-id[=STYLE]    Generate build ID note
(...)

他は分かるけど最後のbuild ID noteって何だろう？

ldのオプションでelf_i386と書いてあるのでELFのフォーマットの中にそういう部分があるんだろうか？BINARY HACKSのELF入門やreadelf -aの出力を見てみたけどbuildなんたらというのは見つからなかった。

jonesforthインタプリタは-Wl,--build-id=noneというオプション無しでも普通に動いてしまう。

$ gcc -m32 -nostdlib -static -Wl,-Ttext,0 -o jonesforth jonesforth.S
$ cat jonesforth.f - | ./jonesforth
JONESFORTH VERSION 47 
14499 CELLS REMAINING
OK 
1 2 + .
3

謎だ・・・。

参照：

儲からない勉強は業務時間外の2時間までと決めてたんですが、Macのバッテリーが1時間50分ぐらいしか持たないのが切ないkomagataです。

jonesforthを読んでるんですが、まずはGASのhello worldとのコンパイル方法の違いが分からないとしょうがないので勉強。

$ gcc -m32 -nostdlib -static -Wl,-Ttext,0 -Wl,--build-id=none -o jonesforth jonesforth.S

UNIXの部屋コマンド検索:info (*BSD/Linux)
どうでもいいが、当ページ管理人が一番嫌いな UNIX コマンドが info である。有益な情報が info 内にあるのに、見づらいし、操作しづらいから。info2html の吐く HTML も嫌い。世の人々は info に満足しているのだろうか?

GCCのマニュアルにはinfo見ろと書いてある。でも上記にもとても共感してる。

jonesforthをasでコンパイルしようとすると沢山エラーが出る。違いを知るために、hello worldにjonesforthで使われてるものを少しずつ足して行くことに。まずは毎回as, ldが面倒なのでMakefileを書く。

PROGRAM = helloworld
SRCS = helloworld.s
OBJS = $(subst .s,.o,$(SRCS))

ASFLAGS = -a=$(PROGRAM).lst
LDFLAGS = -Ttext 0 -e main

$(PROGRAM): $(OBJS)
        $(LD) $(LDFLAGS) -o $@ $<

.PHONY: clean
clean:
        $(RM) $(OBJS) $(PROGRAM)

こんな感じで良いのかな？substとかmakeの関数なんて知らなかった。viからは:makeでmakeできるんですね。

それとちょっと気になったのでvimのgasのsyntaxを入れてみた。

apt-cacheで適当に探してたらintel2gasという面白そうなものを見つけた。

Package: intel2gas
Priority: optional
Section: devel
Installed-Size: 340
Maintainer: Alexander Zangerl 
Architecture: i386
Version: 1.3.3-12
Depends: libc6 (>= 2.3.6-6), libgcc1 (>= 1:4.1.1-12), libstdc++6 (>= 4.1.1-12)
Filename: pool/main/i/intel2gas/intel2gas_1.3.3-12_i386.deb
Size: 30456
MD5sum: a7b336eb691b3391211cc20b8a29d2e5
SHA1: 6afaec8b0505b3fc1d2b862fdf38de3d63ab1abd
SHA256: 0d8f32134c862b032f7bcf0c4a0bfe0d32a480edfcd7ae30fe25d5839bc91bc5
Description-ja: NASM アセンブラ言語から GAS への変換プログラム
 Intel2GAS は、i386 プラットホーム上で、NASM 用に書かれたアセンブラソー
 スファイルを GNU Assembler (GAS) を使ってアセンブル可能なファイルに変換
 するプログラムです。基本的な MMX 命令への対応も提供します。
 .
 ホームページ: http://www.niksula.cs.hut.fi/~mtiihone/intel2gas/
Tag: devel::machinecode, interface::commandline, role::program, scope::utility, use::converting

ホームページを見るとgas2intelも出来るみたい。後で試してみたい。

Cookieセッション

そもそもセッションという言葉自体が複数の処理をまとめた単位という広義の意味とWebアプリケーションで複数リクエストにまたがってサーバー側に保存されるデータという狭義の意味が混在して使われているという事情があってWeb上でのテキストコミュニケーションを阻害している。

RailsのCookieセッションと言った場合は広義のセッションだが、狭義のセッションは存在しないと断言すると分り易い気がする。

RailsはHTTP（RESTアーキテクチャスタイル）の原則に従う形で何も共有しないという設計上のポリシーを持っている。

そもそもCookieと言う仕様はステートレスなHTTPプロトコルに広義のセッションを構築する上でNetscapeが考え出した上手い抜け穴だ。

CookieのデータはHTTPヘッダーに記載されて全データが送受信される訳だからHTTPリクエストの内容だけで全ての情報を表現するという原則からはみ出していない。

狭義のセッションに関しては言語仕様やアプリケーションサーバーの実装に委ねられていて、例えばPHP（言語仕様に狭義のセッションが含まれている）とJavaのTomcatとでは全然違う。

殆の実装でそうなっているんだけど、Cookie内の一意のIDをキーにしてサーバー上に（メモリであれ、ファイルであれ）狭義のセッションデータを持っている。

単体のHTTPリクエストやレスポンスで全ての情報を表現できなくてはHTTPの原則であるステートレスとは言えない。（Cookie内のIDがサーバー上のセッションデータを対応しているとしてもそれは単体のHTTPリクエストやレスポンスだけで判断出来ない、/tmp/sess_IDファイルの中にシリアライズされてるとかいった暗黙のルールが含まれている。）

RailsのCookieセッションは広義のセッションの維持はCookieによってのみ維持され、クライアントPCに保存され、それを元にしてステートレスなHTTPリクエストとして送出される。

認証

Rails2.x以降、Cookieセッションに移行すると同時に、認証は「restful_authenticationプラグインを使ってね！」という風にあっさりと変わった。

これは使う側やユーザーにとっては大した違いに見えないが、内部的には認証方式がBASIC認証に変わっている！

これまたファイルやDBに保存するステートフルな認証からステートレスな認証に思い切り変わっている。こんなもん土台をそっくりすり替えちゃう程の大変更だと思うんだけど、上位レイヤーに住んでる人には殆気付かれずに行った。

AtomPP策定のIETFの話し合い内でもあった、「APIと認証関係ねーだろう。認証はHTTPプロトコルの仕事」という身も蓋もない結論をあっさり採用する。そこに痺れる、あこがれる！

HTTPの原則を守る利点

ここまで過激にHTTPの原則を守る最大の利点は、Railsの設計方針としても上げられている「何も共有しない」からもわかるように非常にスケールアウトし易いところだ。そもそも、HTTP（の元のRESTアーキテクチャースタイル）はWebのような大きな分散環境を想定して作られたものである。

シンプルかつスケーラビリティの高いシステムを作るにはREST原則に従うのは理にかなっている。

何故ドラスティックな変更が可能なのか

Ruby界隈では標準仕様を決めてから実装するのではなく、「勝手に実装して、良いものだったら標準にしようか」というノリというか文化がある用に思う。

言語や周辺ツール・ライブラリの整備によって使い物になる実装が出来るまでの時間が恐ろしく短いため、整った仕様よりも、動くコードや自動テストが重視される傾向があるため、時間のかかる抽象的な議論が少なめになるせいではないだろうか。

例としては、最近各言語でxSGIと呼ばれてる仕様も通常、仕様とリファレンス実装を明確に分けるところをRubyではRackが実装を持って標準仕様を決めてしまった。そして実際にRack::RequestとRack::Responseはデファクトとしてあっという間に広まった。

不満

何が俺にこんな長文を書かせるかというと、

「Cookieセッション、BASIC認証を他の言語・環境でも使いたいんだよ！面倒臭くて仕方がない！」

というストレスが爆発したからである・・・。

最近、フィードリーダーで購読してるブログを全部読めている。

iPhoneのせいかと思ったけど、どうやらTwitterのお陰でいろんな人々のブログポスト数が減ってるからのようです。だからどんどん購読ブログは増やしていってるのに全部読める。そのせいか、フィードリーダーの１エントリーあたりの内容が面白まって来ている気がする。面白い。

Twitterのお陰で技術系じゃない人のブログもいつの間にか購読するようになって読むジャンルが増えたのも面白まってる要因かもしれない。

大山倍達のように（イメージ的に）山篭りしてるかのように外界と断絶した内容を書いてる人。どこから読んでも意味不明なのに精力的にポストを続ける人。無自覚に静かに狂っている人。高度な内容を平易な文章で書いてくれる人。

お宝ブログが多くて嬉しいです。

このブログのCSSを少し弄った。

弄る度にtext/plainに近づいてる気がするが、フォームとかリンクは必要なのでやはりhtmlは便利。

そもそも技術系ブログにはUIとかあんまり関係無いと思う。この文章も殆はフィードリーダーで読まれるだろう。PVやUUも全く当てにならない。Analyticsに分かるのはGoogleからパーマリンクに直接入ってくる人の傾向ぐらい。技術ブログにとって本当に大事なお客様はフィードリーダーで購読してくれる人だ。

実際の感触とAnalyticsが乖離してからかなり経つ。フィードリーダーで読んでくれる人の動向を簡単につかむ方法はないだろうか。

右上の検索をGoogleのサイト内検索に変えてみました。

SEO的にはいろんなパターンがあるハズの検索結果ページをGoogleドメインに持ってかれるのは良くないことだと思うんですが、仕事のサイトではないのでそんなん知らん。

変えた一番の理由は、今はドリホ上のRailsで動かしてるこのブログをapp engineに移行したときに日本語全文検索が面倒臭そうだからです。（今は面倒なのでタイトルと本文をLIKE '%foo%'してる。）

カテゴリとかタグとか構造化しない代わりに全文検索で補うというのがコンセプトなので楽して行きたいです。

持ってるMacBookの型番：MB466J/A

MacBook 2.0GHz Core 2 Duo/13.3"/2G/160G/8xSuperDrive DL/Gigabit/802.11n/BT/Mini DisplayPort

VirtualBoxをいちいち立ち上げるのが面倒なので、windowsのservice + coLinuxみたいに自動起動がしたい。

それには今まで避けてきたlaunchdを使わなくてはいけない。

Mac OS X 10.4（Tiger）から標準になったlaunchdは要はinit + inetd + daemontoolと理解。システム起動時にroot権限で動くLaunchDaemonsとログインしたときにユーザー毎に動くLaunchAgentsがあるそうです。（厳密には少し違うけど）

それぞれ指定のディレクトリにplist（プロパティリスト）というXMLの設定ファイルを作って、launchctlでloadするという流れ。

VirtualBoxはCUIでもVBoxManageコマンドでほとんどの操作が出来るのでLaunchAgentsで、

% VBoxManage startvm "仮想マシン名" --type headless

が動くようにしてやれば良いハズ。

~/Library/LaunchAgents/org.komagata.balloon.virtualbox-debian.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>  
        <key>Label</key>
        <string>org.komagata.balloon.virtualbox-debian</string>
        <key>ProgramArguments</key>
        <array>
                <string>/usr/bin/VBoxManage</string>
                <string>startvm</string>
                <string>debian</string>
                <string>--type</string>
                <string>headless</string>
        </array>
        <key>RunAtLoad</key>
        <true/>
</dict>
</plist>

基本、ProgramArgumentsにargvを渡すだけみたいです。

% launchctl load ~/Library/LaunchAgents/org.komagata.balloon.virtualbox-debian.plist

これで設定が読み込まれたので再起動してみる。

すると立ち上がってはいるけど何故か"中断"の状態。

OnDemandをfalseにすると立ち上がるが、監視して終了しても自動的に起動する状態になるので、固定でメモリを確保するVirtualBoxでは気軽に落としたりしたいのでちょっと面倒。メモリが2Gなので増設すれば256MBぐらい気にならなくなるかな？

参照：Undocumented Mac OS X：第1回　initを置き換えるlaunchd【前編】 (1/3) - ITmedia エンタープライズ

komagataのブログ

ハリー・ポッターと最低のおっさん

JavaScript - Joose

ELFのbuild ID noteって何？

make, gas.vim, jonesforth

Cookieセッション、BASIC認証マジパネー

Cookieセッション

認証

HTTPの原則を守る利点

何故ドラスティックな変更が可能なのか

不満

面白いブログが増えてる気がする

技術ブログではAnalyticsが役に立たない

検索を変更

Macの型番調べ辛い

launchdでVirtualBoxの仮想マシンを自動起動