HHKB Pro2 Type-S を買った
Happy Hacking Keyboard Professional 2 Type-S です。HHKBの最上位機種です。猫に小判的な感じはするけど買っちゃった。このエントリはそんな買いたての Pro2 Type-S の練習がてらに書いています。
なんでそんな高いモノをいまさら…
10年以上 HHKB の Lite2 の英語配列版を愛用してきたけど、遂に打鍵音でうちの息子殿(新生児)が起きてしまうという問題が発生。そんな「ッターン*1！！」って感じのタイピングでは無いと自分では思ってるんだけど、Lite2 はガチャガチャと結構うるさいんですよ。
寝た子が起きるとまぁ大変なので、なんとかしようってんで、 Type-S はもともと静かな静電容量無接点方式の Pro2 ベースだし、さらに静音性高めてるそうだし良いなって言うので買ってみた。前から気にはなってたけど、値段が高すぎて買う気が起こってなかったが、ボーナスも出たことだしとエイッってな感じ。いい口実が見つかったってヤツです。
違い
こんな感じ。上が Type-S で、下が Lite2。
まぁ静電容量無接点方式が素敵とか言うのはみなさんご存じと思う。 静電容量無接点方式で有名な Real Force もかつて使っていたのでその辺はよく知ってたし問題は無かった。
タイピングの心地とか以外で、自分の中で Lite2 との大きな違いが下記2点。レイアウト面が中心。
- Fn キーが左下に無い
- Fn キーを押さないで使える矢印キーが無い
1 は不便なので、左下の Cmd キー(◇のキー)を Fn キーに HHKB のディップスイッチで割り当て直した。
2 は結構きついかも。いつも vim 使ってるわけじゃ無いので慣れるまで時間がかかりそう。存在しない矢印キーをウッカリ押下しちゃうのはなかなか直らない。矢印キーの位置をせめてhjklにしてくれれば助かったんだがなぁ。しかも ATOK のオリジナルキーバインドだと矢印キー多用するのでどうしたもんかと考え中。慣れるか。慣れますかね。
追記：結局Cmdキーはもどして KeyRemap4MacBook 使って Cmd(L) + hjkl を矢印に割り当ててしまった…。ますます可換性の無い体になる。
購入のワナ
あと、Type-S だけ PFU 直販(Amazon のマーケットプレイスとかも含むけど)じゃないと買えないのでめんどくさい。ってか安売りを狙うのが難しい。
箱がまたくせ者で、届けられたときに「あ！ Type-S じゃない！」と思う罠がある。一応 Type-S であることを示すシールが右上に小さく貼ってある。最上位機種なんだから自慢げに Type-S のパッケージにしてるのかと思い込んでた。
で結果どうなのよ
タイピングは気持ちいいし、凄い静かになって妻も子供もご機嫌です！！背は伸びてません。
RubyKaigi 2013 で動作報告があったので Arduino で mruby を動かしてみた
RubyKaigi 2013 の感想を書こうかと思ったけど、開催日あたりから私事で忙しく心が落ち着いてないので、ざざっと書けるこの内容から。
Ruby界隈で組み込み関連の発表をガチ内容でやってしまうことでおなじみの [twitter:@bovensiepen] さんが、 どうやら mruby を Arduino 上で動かしたという発表をRubyKaigi 2013 でやってくれたよう。
以前、同じようなことをしようとして結局 Arduino DUE のメモリ不足だかで挫折した経験がある。たまたま裏セッションにいたので聞けず、「あう〜」と呟きをしてたりしたら、ご本人から発表のURLを教えて貰った。感謝ですわ。詳しくはそちらを見てみて下さい。
とりあえず発表資料とデモ動画を斜め読み(視聴)してみたのは良いのだけど、その内容をイマイチそのまま受け取れないというか、もう少し聞かないと分かんないなぁという感じ。
聞けずに悔やんでたんだけど、RubyKaigi の次の日の RubyHiroba でだらだらしてたら、これまた STM32F4 上の mruby によるLチカ発表でおなじみの [twitter:@yuri_at_earth] さんが手招きしている。 @bovensiepen さんがデモしてくれるとかで、わざわざ紹介して下さった。ありがたや〜。RubyKaigi と RubyHiroba のおかげで、直接聞けて凄い面白かったし興奮した。確実に自分のお給金に直結しない技術話ほど楽しいモノは無いので、RubyKaigi から RubyHiroba の流れは素晴らしい。
@bovensiepen さんによる Arduino DUE 上で mruby を動かすデモの内容
デモの内容ですが、Arudino 上に mruby のコンパイラとランタイムを乗っけて、1行ごとに逐次コンパイルして実行する。スライドだかデモ動画通りの内容でした。見た目の地味さと比べて割と凄くて興奮する。
ソースコードをシリアル経由で書き込むと、Arduino 上に展開された mruby コンパイラがソースコードをコンパイルして mrubyVM 上で実行し、出力結果をシリアル通信で PC へ返送する。PC からみるとただの irb のようなモノに見えるんだけど、実際は Arduino 上でコンパイルされて実行されているわけで、夢一杯なわけです。
教えて貰ったデモの動画でもスライドにもそういうことは書いてあるんだけど、なんかイマイチ自分の解釈が間違ってるのかなぁと思ってただけに、本人に動かしてもらった後にソースコード見せて貰ってやっと「おおマジかこれは」と感動した次第です。(コードはそのあとで彼の github 探してみたらあった。コレだと思う。)
Arduino を少し知ってる人へのご注意
普及している Arduino は大体16bit なので 32bit 前提の mruby が動きませんのでご注意。 32bit 版の Arduino DUE をご氏名買いしてください。で、さらに注意なのが 32bit 版は出たばっかりで、 shield とかさっぱりだしウッカリすると電源飛ばすのでご注意下さい。
動かすに当たって聞いてみた点
自分で悩んだ点を細かくご本人に聞いた限りだと、下記のような感じだった。メモリ不足はどう解消したんだと聞いたんだけど、本体には手を加えなくても動いたよとさらりと言われた。うーむいつの間に。
- GC.disable
- mrbconf.h で MRB_HEAP_PAGE_SIZE を小さくしたり MRB_WORD_BOXING を有効化したり
- 本体には手を加えていない
- 動いた mruby は五月下旬のもの
最近 GC.disable はネタ化されているが、そういうのはまぁつまんないしそういうつもりじゃなくて、これしないと本当に実行が止まる。自分が試したときはこれに発想が至らなかったんだけど、その時も同じだったかは分からない。試したときから今までの半年の間でメモリ使用量の削減の努力があったのかもしれない。コミット見てると後者の気はするけど。いずれにせよ Arduino で動かすには大事な要素だった。
実行が止まるのは、メモリ不足のせいかポインタがずれたりしてるのかは追っかけてないので不明。GCが無いとVM上で動くオブジェクト指向言語の大きな魅力の一つが失われてしまうのでこれは残念。
Lチカを試す
家に帰って、言われたとおり試してみたら結構あっさり動いて拍子抜け。いやしかしこれで元々楽しい Arduino が益々楽しくなりますよ。
以下試したコード。
Rubyのコード。
GC.disable loop do Arduino.led_on(13) Arduino.delay(300) Arduino.led_off(13) Arduino.delay(300) end
これを mrbc でコンパイル。-BオプションでC形式でコンパイル結果を出力してくれる。
$ mrbc -Bblink blink.rb $ cat blink.c #include <stdint.h> const uint8_t blink[] = { 0x52,0x49,0x54,0x45,0x30,0x30,0x30,0x31,0xa5,0x74,0x00,0x00,0x00,0xdd,0x4d,0x41, 0x54,0x5a,0x30,0x30,0x30,0x30,0x49,0x52,0x45,0x50,0x00,0x00,0x00,0xbf,0x30,0x30, 0x30,0x30,0x00,0x02,0x00,0x00,0x00,0x00,0x00,0x42,0x00,0x01,0x00,0x03,0x00,0x00, 0x00,0x06,0x00,0x80,0x00,0x11,0x00,0x80,0x40,0x20,0x00,0x80,0x00,0x06,0x01,0x00, 0x03,0x40,0x00,0x80,0x80,0x21,0x00,0x00,0x00,0x4a,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x03,0x00,0x02,0x47,0x43,0x00,0x00,0x07,0x64,0x69,0x73,0x61,0x62,0x6c,0x65, 0x00,0x00,0x04,0x6c,0x6f,0x6f,0x70,0x00,0x00,0x00,0x00,0x6d,0x00,0x01,0x00,0x03, 0x00,0x00,0x00,0x0d,0x00,0x80,0x00,0x11,0x01,0x40,0x06,0x03,0x00,0x80,0x40,0xa0, 0x00,0x80,0x00,0x11,0x01,0x40,0x95,0x83,0x00,0x80,0x80,0xa0,0x00,0x80,0x00,0x11, 0x01,0x40,0x06,0x03,0x00,0x80,0xc0,0xa0,0x00,0x80,0x00,0x11,0x01,0x40,0x95,0x83, 0x00,0x80,0x80,0xa0,0x00,0x80,0x00,0x29,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x04, 0x00,0x07,0x41,0x72,0x64,0x75,0x69,0x6e,0x6f,0x00,0x00,0x06,0x6c,0x65,0x64,0x5f, 0x6f,0x6e,0x00,0x00,0x05,0x64,0x65,0x6c,0x61,0x79,0x00,0x00,0x07,0x6c,0x65,0x64, 0x5f,0x6f,0x66,0x66,0x00,0x45,0x4e,0x44,0x00,0x00,0x00,0x00,0x08, };
こっから先は割と力業で、Arduino のディレクトリに mruby のコードをごっそり置いて、Arduino IDE でコンパイル。こんな感じ。
$ pwd ~/Documents/Arduino/libraries/Arduinomruby $ ls -R mrbconf.h mruby/ mruby.h utility/ ./mruby: array.h data.h hash.h numeric.h string.h class.h dump.h* irep.h proc.h value.h compile.h gc.h khash.h range.h variable.h ./utility: array.c error.h mrblib.c proc.c backtrace.c etc.c mruby_core.rake range.c class.c gc.c node.h re.h codegen.c hash.c numeric.c state.c compar.c init.c object.c string.c crc.c kernel.c opcode.h symbol.c dump.c keywords parse.y value_array.h enum.c lex.def pool.c variable.c error.c load.c print.c vm.c
Arduino のコードは下記の通り。
#include <mrbconf.h> #include <mruby.h> #include <mruby/irep.h> #include <mruby/string.h> #include <mruby/proc.h> mrb_value mrb_arduino_led_on(mrb_state *mrb, mrb_value self/*, mrb_int pin*/) { mrb_int pin; mrb_get_args(mrb, "i", &pin); digitalWrite((int)pin, HIGH); return mrb_nil_value(); } mrb_value mrb_arduino_led_off(mrb_state *mrb, mrb_value self/*, mrb_int pin*/) { mrb_int pin; mrb_get_args(mrb, "i", &pin); digitalWrite((int)pin, LOW); return mrb_nil_value(); } mrb_value mrb_arduino_delay(mrb_state *mrb, mrb_value self/*, mrb_int msec*/) { mrb_int msec; mrb_get_args(mrb, "i", &msec); delay((int)msec); return mrb_nil_value(); } const uint8_t blink_b[] = { 0x52,0x49,0x54,0x45,0x30,0x30,0x30,0x31,0xa5,0x74,0x00,0x00,0x00,0xdd,0x4d,0x41, 0x54,0x5a,0x30,0x30,0x30,0x30,0x49,0x52,0x45,0x50,0x00,0x00,0x00,0xbf,0x30,0x30, 0x30,0x30,0x00,0x02,0x00,0x00,0x00,0x00,0x00,0x42,0x00,0x01,0x00,0x03,0x00,0x00, 0x00,0x06,0x00,0x80,0x00,0x11,0x00,0x80,0x40,0x20,0x00,0x80,0x00,0x06,0x01,0x00, 0x03,0x40,0x00,0x80,0x80,0x21,0x00,0x00,0x00,0x4a,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x03,0x00,0x02,0x47,0x43,0x00,0x00,0x07,0x64,0x69,0x73,0x61,0x62,0x6c,0x65, 0x00,0x00,0x04,0x6c,0x6f,0x6f,0x70,0x00,0x00,0x00,0x00,0x6d,0x00,0x01,0x00,0x03, 0x00,0x00,0x00,0x0d,0x00,0x80,0x00,0x11,0x01,0x40,0x06,0x03,0x00,0x80,0x40,0xa0, 0x00,0x80,0x00,0x11,0x01,0x40,0x95,0x83,0x00,0x80,0x80,0xa0,0x00,0x80,0x00,0x11, 0x01,0x40,0x06,0x03,0x00,0x80,0xc0,0xa0,0x00,0x80,0x00,0x11,0x01,0x40,0x95,0x83, 0x00,0x80,0x80,0xa0,0x00,0x80,0x00,0x29,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x04, 0x00,0x07,0x41,0x72,0x64,0x75,0x69,0x6e,0x6f,0x00,0x00,0x06,0x6c,0x65,0x64,0x5f, 0x6f,0x6e,0x00,0x00,0x05,0x64,0x65,0x6c,0x61,0x79,0x00,0x00,0x07,0x6c,0x65,0x64, 0x5f,0x6f,0x66,0x66,0x00,0x45,0x4e,0x44,0x00,0x00,0x00,0x00,0x08, }; void setup() { mrb_state *mrb; pinMode(13, OUTPUT); mrb = mrb_open(); struct RClass *module = mrb_define_module(mrb, "Arduino"); mrb_define_class_method(mrb, module, "led_on", mrb_arduino_led_on, ARGS_REQ(1)); mrb_define_class_method(mrb, module, "led_off", mrb_arduino_led_off, ARGS_REQ(1)); mrb_define_class_method(mrb, module, "delay", mrb_arduino_delay, ARGS_REQ(1)); mrb_load_irep(mrb, blink_b); } void loop() { delay(1000); }
"LEGOを使ったスクラム研修" というのを受けてみた
だいたい半日でスクラムのエッセンスを体験できるという研修でした。レゴを使ったスクラムシミュレーションというのがあるらしく、それをより理解しやすいようにカスタマイズしたというものらしい。顧客役が欲しい街をユーザーストーリーとして挙げて、それをスクラムチーム役が作るというもの。
端的な感想としては、理解の浸透が進んでとても良かったです。もっと早く受けたかった。あ、あと楽しかったです。
その他、受講していいことや体験できることはリンク先の"参加者の声"を参考にして頂ければいいと思います。だいたい私もそこに書いてあるような感想を持ちました。
以下、思ったことをだらだらと。
座学ぶぶん
座学が最初の一時間強。スクラムの入門本に書いてあるようなことだけじゃなくて、スクラムの歴史やら原則やら根底にある基盤みたいなのを、色々な知見や考え方を交えてざっと紹介してくれた。多くの人はスクラムだとかアジャイルだとかは単純にプロセスとして捉えて入門して、勉強するウチに色々な考え方とリンクさせながら時間をかけて理解を深めていくんだろうけど、プロセスも大事だけど大きな枠組みとして捉えましょうというのが最初から教えて貰えるのでその後のスクラムシミュレーションも有意義になった。(なんかこうかくと「もっと奥が深いんだ」みたいな感じになるな…。奥が深いけどそういう謎めいたあれじゃないです。)
ただまぁ予習大事なのは当たり前だけど、入門本でプロセスくらいは理解しておいてから受けた方が良いんだろうなとは感じた。
複雑性には二つの特徴があるという話が導入で聞けたのは良かった。ソフトウェアを作ることを長年続けていると、分析と解決を繰り返すというのが体に染みこむんだけど、複雑さの特徴についてはあまり考えないので、まずはそこから理解し直そうかという構成はいいと思う。小さな規律ある繰り返しの中で生まれる小さな変化を利用して複雑さを解決する的な考え方は、話だけじゃなくて体験込みじゃないと理解しにくい。
ちなみに。詳しいことは受講して頂くとして、二つとは「Complicated(入り組んだ)」と「Complex(複雑な)」です。
体験ぶぶん
とてもためになりました。
本でアジャイルだとかスクラムだとか学んだだけだと、本当に心配になるんですよ。模造紙やら付箋紙貼って…え？こんな感じかな？とかいっておそるおそるやるんですよ。写真でよく見るけどホントにこんな感じ？みたいに、しまいには変な汗が出てくる。
それを先生立ち会いの下みんなでやって、ベロシティがでてきて、おおホントに予測できるわ〜、本に書いてある通りだわ〜みたいな体験が出来る。
アジャイルの説明に「作ってるうちにより価値を高めるアイディアが出る」的な話はよくあると思いますが、そういうのがシミュレートできていました。「駅前にオブジェが欲しい」というのが街を作っていく中で、顧客役から出てきたのですが、「オブジェが欲しいってのはハナからでてくるような要望じゃ無い。街を見て感じるウチにでてくるような要望だ」と、時間を割いてこのシミュレートで得られた体験について講師補佐の角谷さんが説明してくれました。言われるウチに「お、お〜。コレを大切にしているのか」と改めて思い直す次第。
大江戸Ruby会議03に登壇しました
2013年3月17日、Asakusa.rb 200回記念の大江戸Ruby会議03に登壇しました。RubyWorld Conference 2012 の講演を見た [twitter:@kakutani] さんよりお声がけいただいたのが経緯。
最近、心と時間の余裕が無くてAsakusa.rbへ行けてなかったのだけど、1ヶ月ほど前に「なんだか行けそうだし大江戸の講演も近いし、最近はどんな感じかな」と、1年弱ぶりくらいにふらりと立ち寄ってみた。まぁいつも通りギークだかハッカーらがコードをテーマにしてるのかしていないのか雑談やら相談やらの雰囲気で大変心地よかったです。そういう場所だから200回も続いてるし、大江戸Ruby会議のクオリティなんだと思う。
大江戸Ruby会議からちょっとだけ日も空いたことだし、 togatter を眺めながら各講演について短い感想を。あ、各講演者のスライドは公式サイトのスケジュールにリンクされてるのでご興味があれば是非見てみて下さい。
一番下に自分の講演について書いてます。
オープニング
AM10:00開始はRubyistには早かった。200人で埋まるはずの座席は1/4程しか埋まっておらず10分ほど開始延長。角谷さんの開会のご挨拶と共にコンセプト「生活発表会」の説明。
招待講演『A Rubyist life in London』
[twitter:@makoto_inoue] さんのロンドンで9年エンジニアをしてきたお話。ロンドンでの働き方のお話。興味深かったのは、雇われエンジニアだと年収600万円ほどだけど、フリーだと1000万円ほどになるというお話。もちろんフリーでもレベルの高い人の話らしいけど、意外と日本と大差ないのではないかと。受託開発もそれなりにあるみたいだし。
ただ形態の外観は日本と似てるけど、中は違うんだろうなぁ。話を聴いてる間は懇親会でその辺詳しく聞こうと思ってたのに、すっかり忘れてたよ…orz。"日本だと受託開発が〜ノマドが〜"とか、乱暴な意見が相変わらず跋扈してるけど足下の問題を細かく見た方が良いよねって改めて思った。
あと、英語が苦手ならシンプルな日本語でジョーク控えめにすると意思疎通を文字上ででもできるからお勧めとか、そのテクニックが熱かった。
Ninja Talks 1『気づいたらここに立っていた(仮)』
[twitter:@takkanm] さんのお話。ご自身のコード遍歴とその途上で使ったライブラリのコードが流れ続ける感じ。ああ人に歴史ありって感じだなぁと。[twitter:@takkanm] さんとは割と長い知り合いだと思うけど、そういうのよく知らなかったので個人的に興味深かった。what_methodsというgemは結構仰天した。豪華な型システム無しにあんなのできんのって思って、コード読んだらずっこけた。
Ninja Talks 1『asakusa.rbに一年間通ったらこうなった』
[twitter:@katsyoshi] さんの何とも言えない世界の紹介。Asakusa.rbに毎週来るけど、あまりしゃべらないので謎だったから登壇して貰ったとか角谷さんの紹介。
面白い人だなというのは外から感じられる人で、Twitterで爆速でふぁぼつけてきたりするし、この前のAsakusa.rb新年会で少し話しただけだけど妙な雰囲気で呑んでくるので自分も興味あった。mikutterをどう動かすかを延々と話してる印象が残ってて、懇親会の帰りがたまたま同じ方向だったので、面白かったこともありずっとmikutterのコードの話を聴かせて貰ってた。講演によると特定のTweetを機械学習で選別して機械的にふぁぼしつづけてるらしく、公演中もふぁぼが飛んできて最早謎。この講演が良いのは、[twitter:@katsyoshi] さんが舞台に上がって講演して降りるというだけで、[twitter:@katsyoshi]さんの日常が続いてる感が出てるところだった。ご本人は大変だったとblogで書いてましたが。
Ninja Talks 1 『某レシピ共有サイトの Ruby 1.9 対応で大変苦労しました』
[twitter:@mrkn] さんのタイトル通りの苦労話。結構いろんな人のブログにもあったけど、超人オリンピックみたいな会社でもああいうコードがあるのねというのが正直な感想で、安心しました(?)。
これからプロダクトでこのメソッド使うなよみたいなのを、「コーディング規約」とか「コードレビュ」じゃなくて、warningとして出力させてアプリケーションエンジニアに伝えるというテクニックは、Rubyならではだし、出力を整形すれば機械的なチェックも出来そうだしで、とても良いテクニックだと感心した。
あ、ご本人のblogには、講演で言わかった大事な前提が書いてあって、ああそうだよねぇ、大事な事忘れてましたという次第。
基調講演1『Ruby の GC の問題点と 改善手法についての一考察』
[twitter:@koichisasada] さんのワンダと巨像がいかに面白いかRubyのGCの問題点と現在の実装とこれからについての講演。さすが大学で先生してただけあって重厚な講義風。
Mark & Sweep をひとまとめに実施するとGC中に止まるので、Sweep作業を細切れにしたのが1.9で、Markの場所をfork時の共有メモリを汚さない為にメモリの特定領域に移したのがBitmap markingでこれが2.0。一つのマシンの並列性が上がった現代には嬉しいですよと。あとは、再帰的にマークしていたのをスタック構造に移したのが2.0とか。
よく分からないけど、かつてのJavaの世代別GCだと若いオブジェクトを細切れにNew世代領域内でも行ったり来たりさせて効率化させてるけど、forkで使われる事が多いとこのテクニックもあまり使いにくいとか共有しているメモリへの書き込みが増えそう。
笹田さんはずっとGCRubyの処理系の事を考えて生活してるそうで、電車通勤でも飽きないのでGCRuby処理系お勧めとおっしゃっておりました。(3/22 訂正)
あ、そうそう。Bitmap markingがまんま画像フォーマットのbitmapに移せるのでそれを動画にしましたとかのデモが個人的に超楽しかった。いやああいうのってもうアートかSFじゃないですか。あの動画を出すツールを実行中横に出しておいて、「ああこのメモリの使い方はRSpecですねぇ。もうちょっとローカル変数を使うようにコード書いた方がいいですよ。」とか煙を燻らせながら言ってみたい(タバコ吸えないけど)。
Ninja Talks 2『RubyConfのNinjaの話の続きのおはなし』
[twitter:@yuri_at_earth] さんのmrubyをSTM32F4-Discoveryで動かしましたという話。組み込みでもRuby動いたら超楽しそうじゃないっすかという前振り。そう思います。LEDちかちかさせたい。で、個人的に前のめりになってしまったのが、STM32F4-Discoveryでmruby動かしましたというくだりで、私、実は同じ事試してたのですが、MacでSTM32F4の開発そのものが結構面倒の塊で、数日やってくじけてしまったのです。その資料是非ネットにアップして下さいって懇親会でお願いしてみた。
Ninja Talks 2『Travis-ciでのemberjsのi18n』
関西弁を操るシアトル出身の [twitter:@morgan_randy] さんのお話。爆笑しすぎて何を話してたのか忘れそうになった。emberjs を使った静的なサイトでもi18nできるよというテクニックのお話。懇親会で詳しくお話を聞いたら、翻訳ファイルは全てクライアントに持って行く仕組みらしくて、「転送量大丈夫？」と聞いたら、assetsの圧縮は大したモンらしくてそうたいしたことは無かったとのこと。
Ninja Talks 2『ぼくのかんがえたさいきょうのお問い合わせ管理システム』
[twitter:@hsbt] さんの会社の日常業務をさいきょうにしたお話。ありますよね？カラム毎の入力欄と 'name LIKE %?%' で全検索とかやっちゃうギョームシステム。少し違う検索をしたいだけなのにエライ時間かかったりテクニックが必要だったり。そういうのをえいっと横断的に探索して全文検索エンジンで均しちゃうお話。
このお話が良いのはスパナ持った隠れた伝説のおっちゃんが会社を歩き回って問題を解決するような雰囲気が出てるところ。おっちゃんは楽しいのでちょっと違う技術で直してしまうけど、問題はきっちり直ってる。そういうのをやらせてくれる会社も懐大きい。
あと、Rubyコミッタになった(おめでとうございます！)から、Rubyコミッタが忙しくて手出しできてない周辺環境をぐいぐい整備していきたいとかもうやってるよとか頼もしい事もおっしゃってた。流石や・・・。
基調講演2『Asakusa.rb vs. the World』
我らが [twitter:@a_matsuda] さんのお話。Asakusa.rbに集うハッカーは凄すぎて地の利を生かす手は無いとか。コードで世界を相手にするには、この陣容は素晴らしすぎるだろうという感じ。いや、あそこで会話聞いてるだけで面白いもんなぁ。
私的には [twitter:@a_matsuda] というハッカーの磁力がかなり強くてその相乗効果でさらに磁力がエライ事になってるとは思います。RubyのコミッタもRailsのコミッタもスゴイですよ。
Ninja Talks 3『Diversity is Good. RailsGirls Tokyoの取り組みと、そしてあなたがいつか得られるもの』
この辺から舞台袖で緊張しながら聴いていたので、あまり分からない…。
[twitter:@yotii23] さんのお話。RailsGirlsTokyoのオーガナイザー。多様性は善だけど、相変わらず男性に偏ってるけど、RailsGirlsTokyoやってみると女性も結構興味持ったし、きっかけさえ作れば偏りなんて関係無いし良いこと起こるんじゃないかなとかそういう感じだったと思う。
Ninja Talks 3『From 0 to 1: How to Get Involved in "Open Source"
よし、つぎは俺だと思ってたらいつの間にか順序が変更になってて、緊張のやり場に困ってしまいますますよく聴いていない。ふぇぇ。
[twitter:@yuki24] さんの、オープンソースコミュニティに打って出るハウツーやらを丁寧に説明してたと思う。スライド見たいけどまだ上がっておらず残念。
招待講演2『桐島、Rubyやめるってよ』
[twitter:@nari3] さんのコードを書く意味についてのお話。最早数日で伝説のトークと化してしまい、いまさらなんか書くことも無いけど、良かった。忘れてましたよ、楽しいから書くだけでもいいじゃん。そういう感じなのにスゴイ仕事を残してしまう人の例としてmameさんとかyharaさんとか挙がってて、自分もそう思って密かに憧れてましたよ。ほんと。nari3さんのGCもそうなんじゃないかなぁ？
自分の講演について
RubyWorld Conference 2012の再演でした。角谷さんに撮って頂いた写真がかっこよすぎたので何故か置いておきますwwww。他の人も格好いい(こちら)。
同じ話をこんな大舞台でしていいのかしらんという悩みはあったけれども、やってみて良かったです。角谷さんに再演をしかも大江戸でと依頼されたのは密かに嬉しかったのです。頑張ってみました。
案外、RWCの動画は上がってるけど見てなかったとか、直に見れてよかったとか大勢の方に言っていただけました。ブログ上で恐縮ですがホントにありがとうございます。
広義のシステムを使う人からコンピュータまで一貫して繋げられる技術とそのやり方がおぼろげながらも見えてきた時代だと思います。その見え方を見るための入門にはRubyはとてもいいんじゃないかと。
あ、この講演について、[twitter:@arton] さんがスゴイ感想記事を残して頂いていて恐縮です。両側の壁というのは端的で分かりやすいと思いました。
Developers Summit 2013 で少しだけお話しました
デブサミ 2013 で少し話しました。
【14-E-7】[TED] Technology Enterprise Development
http://event.shoeisha.jp/detail/1/session/34
話の枠組みとしてはRubyWorld Conferenceの時とほぼ同じにしましたが、聴衆がRubyistとは限らないのでその辺少し変えました。もっとRubyRubyさせたかったですが、私のプレゼン力ではごり押し感を出さないようにするのは無理でした＞＜。
このネタでお話するのは大江戸Ruby会議03でおしまいにしたいと思います。デブサミ含めてお話しして下さいと言われるのは自分にしては奇跡的な事で、自分史上バブルだなと思ってます。ホントにありがとうございます。
目の前の問題をうまく受け流すというか適宜対応できるように日々を少しずつ変えてれば、時代の流れで面白いことが起こるし、そこでズバンと行けるようにしようと言いたかったつもりです(勝手に面白いことが起こるわけでは無いけれども、準備してる人の近くには来やすいというか行きやすいというか)。あ、今年のデブサミのテーマはAction!ですよ。デブサミ代表の岩切さんに「デブサミ行っても"ええ話聞いたわー"といって終わる人が多くて歯がゆい」と、その趣旨を説明されて、「それは大賛成だ。いいテーマだなぁ。」ということで、こういうシナリオでお話したってのもあります。
個人的にはSIer disとかのアジテーションはどうかと思ってる*1し、まぁそういうアジに乗っかっても明日が変わるわけでも無いしつまんないかなと。
旧来のやり方が嫌なら、そういうのやってない会社に行くとか選択肢はたくさんあると思いますが、いずれにせよ技術に裏打ちされた文化や行動規範を持ってないとただ意識高い人になるだけですし、制約の中でもできることをコツコツする日々を送って、チャンスが来たときにパンチを繰り出す力が要ると思いますが、そういう人が増えることが変化を促すことに繋がるかなと思ってます。
そういえば角谷さんに概要を話したら「若者に任せればええんや(任せられるようになる？)って話ですね」ってまとめられて、流石うまいな…と思いました。そういう事なんですよね。
同じセッションでお話しした方々
梅原さんのお話は、話の内容により具体性があってとてもいいと思った。のこりの4つも知りたい。
石沢さんやあまのりょーさんは、肩の力が抜けた感じできちんと毎日を捉えてる感が出ていて流石というか、ああかなわないなという。ああいう風にありたいかもなぁ。
志茂さんの自動化の話は、いちばん手近に出来るActionでした。
川添さんの司会でうまく締まっていいセッションになりました。
ThinReports で生成されたパスワード付き PDF を Adobe Reader で印刷するとエラーダイアログが出る問題とその対応
タイトル長っ。
ThinReports 0.7.6 以前で成されたパスワード付き PDF を Windows 環境の Adobe Reader で印刷すると次のような文言のエラーダイアログが出ます。
「このページにはエラーがあります。Acrobatはページを正しく表示できない場合があります。PDF文章の作成者に連絡して、問題を解決してください。」
エラーダイアログは出るんですが、実際は正常に印刷も表示もなされ、何か問題があるようには見えないという現象です。実用上はあまり問題は無い感じですが、気持ち悪い問題です。
で、色々調べた結果です。
なお、確認している再現環境は下記の通り。
- ThinRepors 0.7.6, 0.7.5
- Prawn 0.12.0 (PDF 生成ライブラリ。 ThinReports が依存している)
- Windows 版 Adobe Reader 9 or 10
対応方法
ThinRepors が依存している Prawn という PDF ライブラリのバグらしく、次のようなモンキーパッチで直ります。
class Prawn::Core::Reference def <<(data) (@stream ||= "") << data @data[:Length] = @stream.length @stream end def compress_stream @stream = Zlib::Deflate.deflate(@stream) @data[:Filter] = :FlateDecode @data[:Length] = @stream.length @compressed = true end end
Rails から使っている場合は、config/initializer/prawn_patch.rb などに保存しておけば良いでしょう。
ライブラリの状況
ThinReports 0.7.6 が依存している Prawn のバージョンは 0.12.0 です。それ以前のバージョンには潜在的にこの不具合をもっていると思われます。
このモンキーパッチは Prawn の master ブランチのあるコミット( https://github.com/prawnpdf/prawn/commit/34039d13b7886692debca11e85b9a572a20d57ee )から持ってきたものです。次のリリースが 1.0.0 かは分かりませんが、Prawn は 1.0.0 のリリースに向けて目下開発中(リリース時期不明)です。このコミットが含まれた Prawn 1.0.0 と、 1.0.0 に対応した ThinReports がリリースされることで恐らく完治しますが、 ThinReports 0.7.6 以前で Prawn 0.12.0 を使っている場合はまずはこのモンキーパッチでしのげます。
このモンキーパッチは次のバージョンである ThinRepors 0.8 には内包してリリースされるそうですので、ThinReports 0.8 への差し替えタイミングで消せば良いでしょう。
Jim Coplien のスクラムマスター研修を受けた
2013/01/22、23 日本橋の野村コンファレンスプラザにて。
動機
現在、サービスビジネスと称して自社プロダクトをいわゆるクラウド上で展開するようなアプリケーションを開発している。大人数による受託開発がメインのビジネスの会社でやっているので廃藩置県時のサムライの商売みたいなところがある。とはいえ、ビジネスモデルが違えばプロセスは変わるはずだし、ウォーターフォール的な開発手法は不向きな領域なのは分かっていたので、非ウォーターフォールなプロセスで開発している。いわゆるアジャイルなと呼ばれる手法を書籍やセミナなどを通じて学んで実践している。コンサルタントだとか経験者を最初に入れた方がいいと色んな所で聞くのだが、そんなお金もないような感じなので一生懸命自分なりの解釈やコミュニティで聞くことを参考に自分のやり方に不安を覚えながら日々を暮らしている。
体系的に学んでみたい、研修のように網羅的に学んで、自分のこれまでの勉強や実践についての勘違い・知識・考えの穴埋めと修正をしたいとずっと考えてた。ただ高額な研修でもあるし(おまけに会社のビジネスモデルにはそぐわない手法)、滅多に開催されないのでなかなかその機会が無かったのだが、たまたまググってみたら「あらま。コプリエンさんが教えてくれる回が。なんと。募集中。」と気づいて、上司に無理言って参加させて貰った訳です。理解ある上司で良かった(10ヶ月ぶり2回目)。
とはいえ、講義を受ける前までは、(ソフトウェア開発の)スクラムの本を読んでみても、確かに良い事書いてるけど、認定とか専門用語やらにあてられて(?)、その良いことの起こる過程や態度についてあまり理解できなかった。これは私の理解力とか感受性が乏しいことが原因。自分でもどうかと思う。で、そんな感じなのに「なんで研修受けたんだ」ってツッコミ入りそうだけど、本当は自分の理解がショボイだけでそうじゃないんじゃないかという期待があったというのは本当です。
全体的な感想
スクラムという名前を伊達に冠しているわけじゃ無いんだなというのが最終的な感想。ああ、だからスクラムっていう名前なのかと。野中先生参加のカンファレンス直後だからか引用も多かった。
「認定」については多分賛否あるような感じだろうし、普及期の一つのやり方だったと分かるけど、あの研修自体はとても意味があると思う。
チームが自律的に動く、自己組織化されるのが大事というのがまずは自分の頭で理解できた気がする。でもね、「自己組織化が大事」って字で読んだり単語で聞いても「ああそうだね」という感じの感想になるんだよな。数年間自分なりにつたないながらもチームで開発をしたり、みんなでその底力を上げてみるという活動をしてきた経験も効いてるとは思う。そうじゃなきゃ…経験と理解を繋げられたと思いたい…。はてさて。
コプリエンさんは兎に角、本質を理解せよといった感じでギラギラ目を光らせて説明してくる。用意されたプロセスとツールじゃ無くコミュニケーションであって、チームの力を引き出せ。という感じ。バグがあったらバグを埋め込むプロセスを直せ。プロセスを改善し続ける。プロジェクトを管理するのではなく、価値を生み出すチームを。コプリエンさんは「皆さんは赤いピルを飲みたいんでしょう？青いピルのスクラムをやるんですか。」と、しきりにけしかけてた。
スクラムの良い本推薦してと言われて大野耐一の「トヨタ生産方式
https://sites.google.com/a/scrumplop.org/published-patterns/home と Organizational Patterns of Agile Software Development
最後はコミュニティがあなたを支援するって言ってくれた。元気を出して近くのコミュニティに参加してみようかな。とりあえず今日の研修をもって新しい出発点とすることとした。
