Kanazawa.rb meetup #18でLTしてみませんか

来る 2/15(土) Kanazawa.rb meetup #18 にて LT 大会が開かれます。

これを書いている時点でまだまだ参加は余裕です。

あなたも発表してみませんか

Kanazawa.rb の LT はこわくないです。別にウケを取らなくても技術的に新しい内容が入っていなくてもいいんです。自己紹介で終わっても時間が余ってもいいんです。すでに実績があります！

ルールは1本5分まで、それだけです。

Kanazawa.rbはコミュニティスピーカーデビューを応援します

まだ発表したことのない方、あなたもこの機会にコミュニティスピーカーとなりませんか？ Kanazawa.rb でスピーカーデビューを果たした方が

  • 2012年は6人
  • 2013年は7人

います。地方の技術コミュニティにしてはこれはそこそこな人数だと思います。

我々 Kanazawa.rb はどんな発表にも全力で笑い、全力で感嘆し、全力で拍手できます！ LT を名刺代わりに一緒においしいビールを飲みましょう！

例えば過去にどんな発表があったの

一部抜粋してみます。

  • PacketiX VPNの紹介
  • TypeScript PlayGround作った話
  • mruby
  • 価値駆動からビジョン駆動へ
  • Emmet ( feat. Kiyohara )
  • Sass, Compass ( feat. Sasaki )
  • Jekyll ( feat. Kiyohara )
  • MacRuby
  • SWIG
  • 憧れの人を作ってパクるといいよ
  • 初めてLTする話
  • Javaの入門書の話
  • UMLの話
  • で、アジャイルって何？
  • 2012年ドヤりんぐ
  • 2013年ドヤりんぐ
  • rvm
  • bundler
  • bcrypt
  • ハッカソンの紹介

硬派な内容も案外ありますね。とは言え一貫したものは何もないです。Kanazawa.rb の LT はそんなもんです。特にテーマはありません。

Ruby 縛りなんてありません。大丈夫、好きなラーメンの話でも好きな酒の話でもいいです。

どうぞお気楽にご参加ください。

待ってるぜ。

実はCapybaraってよく分からないんです

というか、この辺の用語がいつも混乱してとても困っていたのでいったん整理。今回のターゲットは何やら最近 JavaScript を含む Web アプリのテストでよく名前を聞く

capybara-webkit

からスタート。

間違ってたら突っ込んでください！ 間違ってなかったら褒めてください！

名前

capybara-webkit
Capybara の driver. Capybara のテストを WebKit を通じて実行できる。WebKit と言えばみんな大好き、Google Chrome や Safari のエンジンですね。
capybara
テスティングフレームワークに対して Web アプリのテストを書きやすくする語彙を提供してくれる( DSL や Driver で実装されている )。driver は default で rack_test で、JavaScript を含む場合は Selenium になる。1
cucumber
語彙の定義をしてあれば日本語でもテストを記述できる BDD フレームワーク。主に受け入れテスト用として人気？

ここまで全部 Ruby 製。

links

ただし

Cucumber を PHP アプリに対して本当に使えることが分かった

に書いたように、アプリケーションは Ruby 製である必要はない。その場合は

jeroenvandijk/capybara-mechanize - GitHub

を使う。mechanize については今回は端折ります。

もう一度まとめると

  • capybara の default driver である rack_test は rack アプリしかテストできない
  • default の javascript_driver である selenium は remote server にアクセス可能
  • rack_test を capybara-mechanize に差しかえると non-JavaScript の部分も remote server へアクセス可能

みたい。ということは rack_test 使ってる間は本物の http request は飛ばないのか…。

ちなみに capybara は Web アクセスをシミュレートしてくれるので、これは外から Web アプリをテストするためのものですね2。純粋に JavaScript のユニットテストを行う場合は QUnit, Jasmine, 最近だと Mocha なんかを使います。

ところでなんでCapybaraなんだろう

たぶんだけど提供してくれる API がステキなんじゃないかなぁという印象。Ruby でテストを書きたいだけなら他にも選択肢はあるし。Selenium じゃないのはブラウザ部分を取っ替えてより速く実行できるのがみんな好きみたい。

Capybaraってテスティングフレームワークですか？

違います。

Web のアクセスをシミュレートするヘルパーです。

だから実際のテストは Cucumber や RSpec なんかで書きます。

おまけ

Jasmine にも Web サーバ起こすだけのやつと Selenium 使うやつがあったけど、WebKit 使うやつはないのかなぁと思ったらこれが見つかった。

jasmine-headless-webkit – The fastest way to run your Jasmine specs!

ブラウザ立ち上げっぱなしで guard-livereload で回してもいいけど、CLI で完結するのもステキ。何らかのサーバで動いているであろう CI に向いてますね。もちろん Selenium と違って起動も速いので普段使いにもオススメです。

これは今度試そう。

こんな感じか。

余談

レガシーなコードもたくさんあるのでそういうときにせめて外からテスト揃えておくと安心だよねぇと調べてから思ったけど、それって

Rails での spec:requests にも同じことが言えるんじゃ？

と思い始めた。今まで request を元に内部で分岐する部分のテスト以外は真面目に書いてなかったけど、

単にちゃんとページが返ってくる

ことを spec でガードしておくのも大事だなと急に思い直した。初期の頃にはほとんど意味を感じない spec だけど、ある程度複雑になってきたときに予想していなかったところに影響が出てしまったことを素早く検知するために、

「ページが表示されて当たり前じゃん」と思っていても spec:requests は書いておいた方がいい

んだな。たぶん。なるほど。なんか Model や Helper やらに意識がいきすぎてた。

参考

JavaScriptのテスト事情-ダイジェスト版- 2011年10月13日

あとで見つけたんだよ！ ほんとだよ！

  1. yet another webrat の意味で capybara って名前になったんじゃないかなぁと思ってるんだけど真相は知らない。 ↩

  2. rack_test の場合は云々というのはとりあえず置いておく ↩

GDのグレースケールPNGバグを踏んだ

GD 使ってたんですよ。ぺちぱーですから。そしたら画像を縮小してるつもりなのに、なんか

縦は縮小されてるけど横は切り取られてる

じゃないですか。えーなにこれーと思ったけど、どうもグレースケール画像の扱いに問題があるっぽい。簡単に試してみたところ

グレースケールPNG×
グレースケールJPEG○

だったんだけど、これって有名なバグなんですかね。GD は全然詳しくないので1今まで知らなかったけど、バージョンにもよるのかなぁ。バグだ！って記事は見たことないのでたまたまかもしれないし、PHP の開発の様子やソースの確認はしてないのでデマかもしれないけど、念のためメモ。

まぁ、グレースケールの画像を Web で使うことなんてそんなにないとは思いますけど。

今回はなんか試しに作った画像がたまたまグレースケールだっただけで、特別グレースケールの画像を扱いたいという要求があったわけじゃないのでそのままスルーしてしまいました。運用で回避、または

仕様です。

  1. というか画像ライブラリは全部詳しくない ↩

一発採血

健康診断だった。例年採血で手こずるのだが、今年はそのことを告げたら最終兵器、卓上ヒーターが出てきた。これで手を温めてから採血に望んだら一発で採れたよ！

ちなむと、毎年健康診断はこの時期の朝イチに行っているので、

  • 寒い
  • 起き抜けで血が巡っていない
  • おまけに朝ご飯も食べていない

という状態で、末端冷え性の自分はまずまともに採血できないのであった。一発で採れるなんてすごい快挙。

Capistrano と Rake の比較

実は最初 Capistrano の記事を書いたときは大真面目に一部 Rake の機能を使っていると思っていた。コードも読んでなかったし、task 定義の構文が似ているというだけでそう思い込んでしまった。

でも実は全然ベツモノだったことにあとで気づいた。とは言え似ているのは実際に似ているので、自分の気づいた似ている点、同じように使える点、違っている点をちょっと挙げてみようと思う。

あくまで task 定義、実行時に使えるところの話で、中身の違いについてはほとんど言及していないのであしからず。

似ている点

  • task do; end によるタスク定義
    • まぁこれが基本ですね
  • namespace do; end による namespace 定義
  • コマンドラインオプションもよく似ている

異なる点

コマンド名、デフォルトの定義ファイル名が違う

ツールコマンドデフォルトの定義ファイル名
RakerakeRakefile
CapistranocapCapfile

default/file/directory task がない

実は自分は Rake をビルドツールとして使っていないためか、この default task の動作はイマイチ馴染めずにいた。Capistrano はこれがなくなっただけですっきりした感じで、好感を持ったりしている。

依存タスクの定義方法

rake では

task TASK => depends do
  ...
end

という形で depends の位置に依存 task を書くことができ、file task, directory task ではこの機能を使うことで関係するファイル群を簡潔に記述することができる。しかし Capistrano ではこういった書き方はできない1。Capistrano では以下のように依存 task ではなく、trigger に別の task を登録していく形になっている。

task :taskA do
  ...
end

task :taskB do
  ...
end
before :taskA, :taskB

before だけでなくいろいろ trigger があり、これらの trigger 用のメソッドに task を追加していく。最初ちょっと面倒だなと思ったが、これはこれで読みやすく、すぐに慣れることができた。

接続先サーバの記述

Rake で依存タスクを書く位置には接続先のサーバ群を記述することができるようになっている。

task :taskA, :roles => :ROLENAME do
  ...
end

という形で記述する。:roles に書ける role は

role :ROLENAME, hostname1, hostname2, ...

という形で定義しておく。

task の呼び出し

Rake の場合は他の task の呼び出しは depends に書く以外に方法がない。しかし Capistrano では他の task をメソッドと同じように呼ぶことができる。

まぁ凝った処理をする場合は task ではなく独自に module や class を定義していくことになっていくだろうから、この機能はあまり使わないと思うけど。

スコープ

Rake の場合は「地の文」も namespace も task も Global なというか main のメソッドなので、例えばそこで定義した変数は main に属しており、それが分かっていれば値のやりとりはそれほど大きな苦労がない。

しかし Capistrano の場合は Rake で main に当たる部分が Capistrano::Configuration となり、namespace も task もすべて別々の階層に属すオブジェクトとなっている。2そこで Capistrano では set というメソッドを使って独自に変数を定義し、fecth でその値を取り出すことで、task 間で変数をやり取りできるようにしている。

set :var, val

fetch :var

Capistrano を Rake のように使う

以下の点に気をつければ Capistrano と Rake の違いをあまり気にせず使える。気をつけてほしいのは、Capistrano があれば Rake なんて要らないぜ！ということを言いたいわけではないということ。あくまで、この場合は Rake、この場合は Capistrano、と使い分けを考えなくても、この辺だけ意識すれば Capistrano だけでもある程度イケるよ、ということで書いている。

接続先サーバを記述しない

task :TASKNAME, :roles => :ROLE do
  ...
end

ではなく

task :TASKNAME do
  ...
end

で書いていく。

run メソッドを使わない

run メソッドはリモートのサーバにログインして実行するためのものなので、

task :TASKNAME do
  system()
end

あるいは

task :TASKNAME do
  Rubyコード
end

だけで書くようにすればリモートサーバへのログインなしに task を実行できる。

  1. というか Capistrano ではこの部分は実行サーバの定義に使われている。 ↩

  2. ドキュメントはそれほど多くない Capistrano だが、RDoc を読んでいくとどのオブジェクトにどのような役割が割り当てられているのかはだいたい分かるようになっている。 ↩

Opensource FastLadder 設置失敗

※ 連休終わりに書いてますが、ネタは休み初日の内容です。

連休の課題第一弾として選んだ FastLadder 設置、見事に玉砕しました。

環境、

  • OS は FreeBSD
  • Ruby は ports で入れた 1.8.6
  • ports の Rails に 2.0 は来てなかったので gem から最新の Rails をインストール

という状態で、ハマったのは FreeImage.

要求されているのが 3.10 で ports で入れてあるのが 3.9.3 だからか、どう頑張ってもちゃんと読み込んでくれない。最初インストールした場所が悪かったのかなと思ってあっちこっちに link 置いてみたけどダメで、なんじゃこれと思って ktrace したら最後の最後、libfreeimage.so.3 が自分自身を指す link になってて file open を諦めていたんだけど、これを直してもダメ。

引き続き ktrace して見てみると、libfreeimage.so.3 -> libfreeimage.a を open してるっぽいんだけど見事にスルーしている。0.0.1 のときは invalid file format ってメッセージが出ていたような気がするけど 0.0.2 にしたらそのメッセージは出なくなったので、もしかしたら気のせいかも。とにかく、libfreeimage を読んでくれない。Ruby の dlopen の問題なのかとかあれこれ思ったけどこの辺の事情にまったく疎いので深追いをやめる。

あと野良で FreeImage 3.10 を入れる手もあったんだけど、面倒くさくなってやめてしまった。これが読み込めないと crawler もまともに動かないし mongrel にアクセスしても 500 しか返ってこない。つまり、まったく使えていない。Linux, Windows, MacOSX ではそれぞれ動かしている人がいる気配なので次は Linux でやってみるか。

FreeBSD では情報が増えてきたらもう一回やってみようかな。どなたか FreeBSD で動いたって人いませんか？

なんか Diigo がさらに使いにくくなったような

最近調子悪いなーと思っていたら v2 beta になった。機能が増えたりしたんだろうけど、ぱっと見で気づいたのは

  • Social Annotation と名乗っているけど、これ前からだっけ？ なんかコンセプト変わった？
  • 水色が増えた
    • Google inspired か？
  • 以前ボタンを CSS でリンクっぽく見せてるのは Mac のブラウザでひどいことになってるよと書いていたのは直った
  • ブックマークした各記事の上にマウスカーソルがきたらアクションのメニューが表示されるという相変わらずワンクッション待たせる操作性1。ただ、メニューを表示するために小さい more ボタンを一生懸命クリックする必要はなくなった。
  • もともと低い一覧性がさらに低くなった
    • 上で言う各記事に対するアクションメニューは mouseover で on/off するだけで「表示する場所は最初から確保されている」。つまりメニュー出っぱなしの状態となんら変わらない。で、そのメニューの分と、どのサイトをブックマークしたかの情報の分のスペースが邪魔。あとページタイトルがでかすぎて場所を取っている。
  • 検索窓は右の方に行ってしまい、自分が普段使っているウィンドウサイズでは隠れてしまう。

なんだろうなぁ。この、印刷した時きれいに見えますよ的な余白の使い方をしてる感じ。

ということで例によって user css. 今回のポイントは

  • 随所で px 指定されている font-size を全部いじるのは面倒なので、とりあえず各ブックマークアイテムについて、タイトルを 100%、それ以外を 80% にする
  • 思い切って site filter（たぶん新機能）をカット
  • メニューボックスを一段下ではなくタグなどと同じ高さに。cache とか一部リンクが辿れないケースが出てくるがどうせ使わないので気にしない。これは思いとどまった。

こんな感じで。

@-moz-document domain("diigo.com") {
  #logo {
    z-index: 20 !important;
  }
  #siteNav {
    position:      relative !important;
    margin-bottom: -20px !important;
  }
  .easySearchBox {
    position:   absolute !important;
    top:        0        !important;
    right:      0        !important;
    float:      none     !important;
    z-index:    10       !important;
    background: none     !important;
  }
  #mainNavOuter {
    margin-right: auto !important;
  }

  #column {
    position:     relative !important;
    margin-left:  .25em    !important;
    margin-right: .25em    !important;
  }
  #box {
    width: auto !important;
  }
  h1 {
    clear:         both !important;
    text-align:    left !important;
    margin-top:    0    !important;
    margin-bottom: 0    !important;
    line-height:   1em  !important;
  }
  .bookmarkListHeader,
  .bookmarkListFooter {
    height: auto !important;
  }
  .bTabs {
    float:      none !important;
    margin-top: -2px !important;
    height:     24px;
  }
  .bTabs:after {
    white-space: pre;
    content:     "\A";
    visibility:  hidden;
  }
  .sorter, .filter, .pagination, .bFooterOptions {
    line-height: 1em !important;
  }
  .bFooterOptions {
    height: auto !important;
  }
  h3.title {
    font-size:    medium !important;
    width:        auto   !important;
    margin-right: auto   !important;
  }
  h4 {
    font-size: 80% !important;
  }
  h4.tags a {
    color: #5a9de1 !important;
  }
  h4.siteFilter {
    display: none !important;
  }

  #leftColumn {
    width:        auto !important;
    margin-right: 12em !important;
  }
  #rightColumn {
    width:    12em     !important;
    position: absolute !important;
    right:    0        !important;
    top:      0        !important;
  }
  #user_tags_list,
  #rel_tag_list {
    width: auto !important;
  }
  #user_tags_list,
  #friendList,
  #groupList {
    border:        solid 1px #999999 !important;
    margin-bottom: 1em !important;
  }
  div.DivInnerBox {
    height: 30em !important;
  }
  .sideBarBox {
    width: auto !important;
  }
  .sideBarBoxBorder {
    background: none  !important;
    padding:    .25em !important;
  }
  .sideBarBoxHeader {
    background: none !important;
  }
  .sideBarBoxContent {
    margin: 0 !important;
  }
  .sideBarBoxFooter {
    background: none !important;
  }
}

と思ったけど、

  • 各所の width の px 指定を排除
    • background の image も除去
  • rightColumn と leftColumn のバランスも em で指定。leftColumn の width を auto に
    • 先行する leftColumn の width が auto になった関係で float が効かなくなるので、 rightColumn を position: absolute によるレイアウトに変更
  • 余白の分減ってしまう情報量がもったいないので全体に margin, padding をきつめに
  • 検索窓も position: absolute にして z-index を上げることで、ウィンドウの幅を縮めてもナビ部分の高さが変わらず、かつ検索窓が隠れないように
  • 検索窓の z-index を上げたらロゴに掛かったのでロゴの z-index をより高く

という具合にさらに変更を加えてちょっと大掛かりになってしまった。

全体に、自分が普段使わないものは隠れてしまっても構わない方針で作っているので普段使いには若干注意が必要かと思いますが、どうぞご自由に。

ちなみにユーザースタイルシートの作成には

  • Firefox
  • Firebug
  • Stylish

を使っています。Firebug の Inspector で HTML 上の要素の特定を行い、その style を確認します。これを見ながら Stylish で書き換えを行っていきます。（Stylish は今回初めて使ったけどめっちゃ便利だわ。）

できあがったスタイルシートは常用ブラウザが Camino なので Stylish 上ではなく userContent.css にコピペして利用しています。

  1. こういうのは tiddlywiki とか、基本は読ませるけど編集もできますよ的なページなら有効な技だと思うけど、ブックマークはそういう使い方しないでしょ。 ↩

PATH_INFO と <base> と Web の「完全」保存

ここんところ地味に調べていた範囲で分かったところ。

  • 動的に出力しているページは PATH_INFO のパラメータを利用するしないに関わらず、PATH_INFO 付きのリクエストが可能
  • PATH_INFO 付きのリクエストの際、クライアントがページの PATH を誤認してしまい、相対パスで指定されている画像などが正しく取得できないばかりか、この場合はすべての画像などのリクエストがスクリプト本体に集中する1
  • つまり、画像をたくさん使っているページは、PATH_INFO 付きリクエストをしただけで軽く DoS

といった動作が起きる。つーことで、動的に生成しているページでは PATH_INFO を利用している利用していないに関わらず <base> を吐くようにした方がよい。2面倒くさいから同じ意味を持つ HTTP ヘッダか何かないのかと思ったけど、どうやらそういうものはないらしい。

問題は <base> ってどのクライアントに対しても安心して使えるものなの？ということなんだけど、i-mode, Vodafone, EZweb, L-mode の HTML および XHTML の仕様には base 要素はありました。EZweb の proxy サーバによる XHTML → HDML 変換でもこれは生きるようです。WILLCOM では Opera か NetFront が標準と考え（超乱暴）、どの環境でも使えると踏んでいいんじゃなかろか。

で、ふと思ったのは、<base> を HTML の中に書いちゃったら、ローカルに保存してもそれが有効じゃん？てこと。試しにやってみたらバッチリ <base> の指示通り、ページが公開されていた URL に対して画像をリクエストしてくれた。警告も何も出ない。3んー。これってどうなんだろう？ Thunderbird ではプライバシーやセキュリティの観点からリモートの画像をダウンロードしない設定が可能だけど、ブラウザの場合はどういう動作するのがいいのかね。

じゃあ「完全」保存の場合はどうなるの？と思ったら、これは以下のようになった。

ブラウザ<base>の処理
IE6SP2コメントアウト
Firefox 1.0.7コメントアウト
Opera 8.5削除

どのブラウザも、ローカルに保存したファイルだけで完結するように HTML を修正している。

ついでに、「完全」てどの程度完全なのよ？と思って CSS の @import を利用しているページを保存してみた。今度は

ブラウザ@import への追随
IE6SP2×
Firefox 1.0.7×
Opera 8.5○

こういう結果になった。Opera 優秀。と感じるが、Opera は注意が必要。保存したファイルは HTML も画像もすべて同じフォルダにどばっと保存される。うっかりデスクトップに保存した日にゃ大変な目に遭う。

  1. PATH_INFO が付いたまま画像などをリクエストするため。 ↩

  2. すべて絶対パスで指定しているか、PATH_INFO 付きのアクセスを禁止するとか rewrite するとかしてるのなら話は別だけど。 ↩

  3. とりあえず Firefox のデフォルトの設定ね。 ↩

クライアントとサーバで同じ言語を使えたら便利かもね

http://haxe.org/

6以降の Flash Player でも Apache module でも動く1 ECMAScript ベースの言語。悪い言い方をすると IDE がなくて（Eclipse plugin はある）デファクトに乗っかりまくりな Curl (日本法人) みたいなもんか？ ライセンスは各種オープンソース。コンパイラやライブラリなどの違いによって GPL や two-clause BSD, LGPL が選択されている。

http://www.mtasc.org/

ActionScript 2 コンパイラ。ActionScript 3 に対応するつもりはなく、上のプロジェクトに注力することになるらしい。

JavaScript でも Server-side JavaScript (Wikipedia) とか見るといろいろプロジェクトはあるみたいだけど、いちばん現実的なのは JScript.NET なのかな。

  1. standalone executable package も使えるように Introduction には書いてあるなぁ ↩

max-width 推進運動？

ソリッドとかリキッドとかメタルギアですかというネタはおいといて、ソリッドでもリキッドでもなく間をとって

IE 無視で max-width 指定するのがいちばんいいんじゃないの？

というのはたぶんみんなあえて無視してるんだろな。IE を考慮に入れなきゃプロのデザインとは言えないもんね。

私は6年くらい前からずっと max-width 大好きっこです。幅広げすぎると読みにくいじゃん。でもウィンドウを細くしても横スクロールしたくないじゃん。

ほんとはリキッドデザインて”ある意味”幻想だと思うんだけど、これも書き始めると長くなるので別な機会に。

Wiki だけで解決しようとしない方がいいと思う

sheepman さんが Ruby のドキュメントに関して Wiki そのものにある編集に対する心理的ハードルに注目している。これについては以前からいろんな人が

  • 編集したくなるメニューデザイン
  • 署名

などの角度から議論をしている。まだそうした先人の知見を自分の中で整理しきれているわけではないけど、それらとはまた異なるアプローチでハードルを低くできないだろうかと考えたりする。

Wiki を編集するまでに乗り越えるハードル

個人の Wiki でさえ編集することが躊躇されるんだから、Ruby の公式リファレンスマニュアル_の編集するまでに乗り越えるハードルはやっぱり高いんだろうか。どうやったら人が集まるだろう。

まず、Wiki なんだから編集すればいいというスタンスはなかなか分かってもらえないと思う。私のようにコミュニティの外様の場合はやはりかなり躊躇する。知らない人の Wiki に手を出せるのはせいぜい typo 修正止まりだと思う。1（逆引きRuby では正規表現マッチのところに手を出したけど。）

そういう意味でも先日書いていた編集権限と commit 権限を分離した Wiki があるといいなぁと思っている。小人も自由に書けるが、正式に承認されたバージョンに反映されるかどうかは committer の裁定に委ねてしまうことができる Wiki。つまり書き手の立場がいきなり core member と対等になってしまうのはビビるので、一段下にしてください、という寸法だ。もちろんこれは committer の負荷が上がるので運営側としては採用に躊躇する面があると思うけど、参加者を増やすという意味では悪くない案だと思う。

もう一つは、いろんな人が手を出してちまちま編集していることを分かりやすくて提示できたらよいと思う。例えば RuWiki のような保存の際にコメントを書ける Wiki であれば、ここに書くコメントで「編集行程の雰囲気」を伝えることができるのではないかと思う。もちろん本来はどのような修正が加わったのかが分かりやすく書かれていることが前提なんだけど、例えばここに「ぐはぁ、typo ハッケソorz」と書いてあったら、編集者のフランクな性格を表すことができると思う。2また先の編集と commit の区別があればこのコメントはもう少し書きやすいのではないだろうか。

可能なら、Wiki committer が ML でやりとりしている様子や、blog なんかも読めるといいのかなぁ。欲張り過ぎはよくないのでどういう風にサイト上に盛り込むかというのはとても難しい問題だけど。ちなみに pukiwiki.org ではこれが全部 Wiki 上で行われているので、参加の敷居は確かに低くなったが追っかけのコストがとても高いサイトになってしまっている。うまく間を取れればいいなと思う。

ただ、本家リファレンスマニュアルはどうしたって参加者は増えにくいと思う。よほど Ruby に自信がなきゃ書けませんよ、やっぱり。少なくとも私は書きたくありません。怖いです。

  1. 中に入ればいいじゃんという指摘は当然あると思うけど、自分が何らかのアクションを継続するためにこのスタンスが自分には合っているので、あまり深くコミュニティに commit したくないというのが正直な感想なのだ。たぶん張り切りすぎてすり切れてしまうだろうと容易に想像がついてしまうし。 ↩

  2. 現実にフランクかどうか、そもそも修正点が分からないからダメ、という指摘はとりあえずここでは置いておく。 ↩

Ruby のドキュメントとかサイトとかここ数日で動きがあったらしい

どーも話についていけないと思ったら羊堂本舗を Sage に突っ込んでなかったのが原因ぽい。そうかそういうことか。わはは。日本Rubyの会Wikiを Sage に突っ込んだらとても悲しいことになったけどしょうがないのだろうか。かずひこさんに Sage のスクリーンショット送り付けて悲しいですって言うべきか？（パッチよこせと言われそうだけど Hiki の HEAD 追っかけなんてやってないよ。）[追記]2月14日にとても悲しいことからとてもステキなことに変わりました。

Rubyホームページへのご意見募集

あげつらうだけなら楽だけど、具体的なアイディアじゃないと面白くないしね。考えてみよう。

  • ファイル名が日付なのはいかがなものかと思う

ちょっとギョッとしますね、これは。tDiary を使っている限りしょうがないのかもしれませんが、今なら lily + CVS でいくか、Rubyist Magazine のような方向で構築する方がいいのかなとも思います。もちろん編集などのメニューが見えるのは不格好なのでやめてほしいです。どっちを使うにしてももうちょっとツールの完成度があがってからになるかもしれませんし、コンテンツの移行を考えるとすぐにはどうにもならないと思いますが。

  • 本体だけでなくドキュメントにも snapshot とリリースがほしい

Ruby 界隈の人の力があればこれを自動化するのはまったく大変なことじゃないと思うのに、いつまでも正式に HTML ベースのドキュメントをリリースしないのはどうかと思います。正直言えば「1.8 がリリースされてからいったいどれだけ経ったと思ってんだ」という感想です。1.6 のドキュメントがダウンロードできて嬉しい人よりも 1.8 のドキュメントをダウンロードしたいと思う人の方が多いでしょう。

Wiki は確かに便利なのですが、自分の思ったようにちょこちょこ検索したいと思うと、サーバの負荷が気になります。ネットワークに繋がらないと使えないというのも不便です。

もう一つ、そのためにも RDTool の標準添付など Wiki 上のリファレンスを素早く HTML に起こすために必要な作業を進めるべきだと思います。

  • Wiki で提供されている部分で突然見た目が変わるのはやめてほしい

サイトとしての統一感がなくて見ていてとても戸惑います。Wiki をやめろとは言いませんが、統一感のなさは問題だと思います。

  • メニューを整理してほしい

ruby-lang.org にも日本Rubyの会Wiki にも言えるのですが、これらは Wiki ではあるけれども圧倒的に読者の方が多い Wiki であるということをもっと意識してほしいです。読者にとって不要なメニュー、読者がもっと素早くアクセスしたい検索などのメニューがすべて同一の重要度で並んでいるのは使い勝手が悪いです。

ruby-lang.org でサイト内検索がずいぶん下にあるのはなぜでしょうか？ これはもっと上にあるべきでは？

  • 人手がほしいなら分かりやすく募集すべき

ruby-list で人手不足について書かれてもサイトを見ているだけの人には分かりません。サイト上に書いてないということは募集する気は特にないと言っていることと同じだと思います。

さて、Hiki の方にコピペすっか。……一気に送ったけど嫌がらせだと思われただろうか？(^^;

Wiki について「あぁそうだね」とうなずく

結城さんの9日の日記経由して江藤さんやらyomoyomoさんやら。

私が Wiki のよさに気づいたのは一昨年の秋ですが、そのとき感じたのは「なんだこれは Web そのものじゃないか」ということでした。逆にこう感じることができなかった当時は何が便利なのか分からず、触ってはやめいじってはやめのくり返しでした。あの「掲示板のようなもの」って説明はよくないですな。先入観に引きずられます。

それはそうと江藤さん、近江町市場は休みの日やってないのでご注意あれ。

久しぶりに HotWired

HotWired の記事はどちらかというと煽動的であまり記事として重きを置く気にはならないのだが、テーマとしては興味深いというか、少なくとも他のメディアと横並びの内容にはなっていないのでその辺がなかなかよい。

子どもへの抗欝剤投与が増加——問われる安全性

この「増加」ってのは曲者だよな。調査対象が全然分からないんだから。 まーそれはともかく、内容的には少なくとも日本では穏やかな話じゃないだろう。個人的には薬の投与はせずに親へのカウンセリングと幼稚園なら幼稚園の環境改善が先だと思う。もちろん病気としての治療も選択肢としてはありだが、病気として認めてしまうのはあんまりいいことじゃないように思う。なぜなら病歴になってしまうから。何かあったときにまたその病気が顔を出す可能性が残る。

「苦手なものを克服した」ということであれば、病歴にはならない。気の持ちようの部分ももちろんあるが、基本的になんでもかんでも病気として片付けることには反対だ。もちろん病気として認定されたおかげでずっと本人も社会も対処が楽になる場合もあるが、それはもっと大人になってからの話だろう。乳幼児期の対処としては、避けられるなら避けるべきだと思う。

ADHDの子どもたちはコンピューターと仲良し

うーん、身につまされる思いがするのは考えすぎだろうか。自分も授業中に落ち着きがないとよく言われていた。さすがに高校以降はそんなことはなかったが、小中学校のときはどちらかというと真面目に授業を受けることができないタイプだった。

理由としては、今思えばだが、テンポが遅すぎて退屈だったということがあるように思う。授業と言うのは基本的には平均よりちょっと下くらいの子を対象に進行する。つまりデキる子はほとんど待ち時間になってしまう。自分がデキると言ってしまうのは傲慢だが、まぁ小中学校時代は事実だったので仕方あるまい。とにかく自分も授業は退屈だった。

そのとき、例えば追加の課題を授業中に出す先生も居た。パソコンを与えるというのもこれに似た部分があるように思う。恐らく他の子ではパソコンの操作そのものに時間が掛かり、逆に学習を阻害する面もあるはずだ。だが他の子よりテンポが早くて集中力が持続しない子にはタスクを増やしてやればちょうどよくなる。シンプルすぎる解だし、「パソコン」というものがどうしてもあやしさを醸し出してしまうのが難点だが、悪い方法ではない。選択肢の一つとして採用が進んでほしいと思う。

nice, renice

はっきり言ってこれらのコマンドは非常に分かりにくい。もうプロセスの優先度という言葉は頭をちらつかせないことにした。NICE値。これのみ。nice なプロセスとは周りにちゃんと遠慮できる、システム的には優先度の低いプロセスのことだ。

nice値を上げると、周りに迷惑を掛けなくなる。nice値を上げると、周りに迷惑を掛けなくなる。nice値を上げると、周りに迷惑を掛けなくなる。 以上。

うわあ

視点・論点にアグネス・チャンが出てる！ そういう時代なのか。。。

About

例によって個人のなんちゃらです