自分が思うRubyの「動的さ」が世間とずれているっぽいので書きとめておくメモ

何かに強く反論したいとかじゃなくて、自分で引用しやすいようにpermalinkを作っておく、くらいの意味。

Rubyは動的型であるという言い方

動的型というのは実行時にならないと型が決まらないという意味なので、それはそう。例えば Ruby には

int a;

のようなコードは存在しないので、

a = 1
a = '1'

も正しく動く。この時 a の型は実行時にしか決まらず、動的である。間違いない。

※ 1 や '1' は実行前に決まっているけど、こっちの話題は今回は取り上げない。

動的型言語に動的型変換の機能があるけど、Rubyは意外と厳格

1 + "2"を計算する

awk

$ awk 'BEGIN { print 1 + "2" }'
# -> 3

3 が返ってくる。これは数値の 1 に対して文字列の 2 が数値の 2 に動的に変換されて計算された結果である。

PHP では

$ php -B 'print 1 + "2";'
# -> 3

結果は同じ数値としての 3 になる。

JavaScript は

$ node -p '1 + "2"'
// -> 12

これは文字列として連結して 12 になっている。

Ruby

$ ruby -e 'p 1 + "2"'
Traceback (most recent call last):
        1: from -e:1:in `<main>'
-e:1:in `+': String can't be coerced into Integer (TypeError)

で実行できない。

これは Integer である 1 の + というメソッド（演算子のように見えるけど）が String である "2" を強制的に Integer にすることができず、Type が合わないという例外で死んでしまっている。

"1" + 2を計算する

awk では

$ awk 'BEGIN { print "1" + 2 }'
# -> 3

先ほどと同じ 3 になる。awk では + に文字列の連結としての機能は存在せず、常に数値で解釈される。

PHP では

$ php -B 'print "1" + 2;'
# -> 3

先ほどと同じ 3 になる。PHP も + は必ず数値の演算として解釈される。文字列の連結には . という専用の演算子がある。

JavaScript では

$ node -p '"1" + 2'
// -> 12

JavaScript では + は数値の演算にも文字列の演算にも利用できるが、混ざると文字列としての演算が優先される設計になっている。

Ruby では

$ ruby -e 'p "1" + 2'
Traceback (most recent call last):
        1: from -e:1:in `<main>'
-e:1:in `+': no implicit conversion of Integer into String (TypeError)

先ほどと同じように思いっきり TypeError となる。若干エラーメッセージは異なるが、String である "1" の + メソッドが 2 という Integer を強制的に String にできず Type が合わないという例外で死ぬ。

もちろん揃っていれば普通に動く。

$ ruby -e 'p "1" + "2"'
# -> "12"

実はRubyは型について厳しいのだが、静的に強制できないことが問題視されるようになった

Rubyの挙動を整理し直すと、

  • Ruby は文字列の連結も数値の加算も + を利用する
  • ただし + は演算子ではなくメソッドであり、メソッドは左辺に当たる値の class に定義されている
  • String#+ は Integer を受け取っても文字列の連結を行うことはできず、Integer#+ は String を受け取っても数値として加算することはできない

オブジェクト、メソッド、class で考えると至極自然な動作をしている。

このように Ruby は型については実は意外と厳しい。よく分からない挙動で悩まされることは少ない。少なくとも動的変換で変な踏み抜き方はしないので、そういう意味では「型に関する挙動ではだいぶ安全」である。もちろん明示的に変換を指示する際にヘマをすることはできる。そこはプログラマの自由だ。

ただし、標準の機能では変数への代入、関数の引数への割り当て、戻り値について型を強制することができないという問題はある。（動的に死ぬようなコードを作ることはできる。）

逆に、PHP や JavaScript はエラーが起きずに意図しない動作をすることが問題となり、開発規模の拡大とともに型を指定したいという要求が高まり、TypeScript や PHP 7 以降の型の扱いに結実した。結果、Ruby より静的に解釈しやすくなり「より安全に『開発できる』」と言われるようになった。

「動作としての安全性よりも人間の頑張りに期待する安全性の方がよりよいものとして評価されている」ような状況なので個人的にはあまり納得はいっていないのだけど、周辺のツールを含めて「結果としてどうなのか」だけに注目すると「実際に動作させる前に検知できる」のはバグの発見の早期化という意味でよいことだと思う。

これについての Ruby の 2020 年時点での回答は Ruby 3 なので、Ruby 3.0.0 Released など、関連情報を漁ってもらうとよいと思う。少なくとも TypeScript 的なアプローチで静的に問題を検知することはできるようになっている。

エコシステムとしては TypeScript ほどの充実はまだ実現できていないけれど、システム自体は Ruby 2.6 以降でも利用できるので、今すぐ実践投入することもできる。

Rubyの本当の動的さはそっちじゃない

上の例に挙げた String や Integer では不可能だが、PHP や JavaScript のようなふわふわした挙動の演算子のようなものを持った値も以下のように作ることができる。

class AmbigiousValue
  def initialize(val)
    ..
  end

  def +(other)
    ..
  end
end

さらに、上のように普通に class で定義したものについてはインスタンスの状態でメソッドを上書きできるので、あるオブジェクトだけ + の意味が違う、みたいなこともできる。

※ 残念ながら（？） Integer ( Numeric ) や String は継承ツリーに Class を持っておらず、Module に定義されている動的なメソッド定義を実現するメソッド群を持っていないので、Ruby の構文解析を維持したままいきなり 'a' + 1 が 'a1' になるようなコードを作ることはたぶんできない。

もちろんオブジェクト単位で挙動が異なるようなことは「できる」というだけで推奨してる人はたぶんいないけど、この点については自分は以下のようなことだと理解している。

午前4時。あと数時間でユーザが出勤してくる。それまでにシステムをまがりなりにも 動く状態にしておかねば… どうもサードパーティ製のあるライブラリ(ソース無し)の 挙動が怪しいのが問題の原因のようだが、APIにどういうパラメータを与えた時に バグが再現できるか絞りこめていない。もちろんサポートが開くのは明朝、それでは 間に合わないッ。だがッ！ ライブラリの内部のみで使われる ある関数に、まれに異常な引数が渡っていることが分かったッ！ この内部関数の呼び出しをフックして引数を修正すればとりあえず動かせるッ！—とか、

そういう状況において、「どんなに汚くても、打てる手段がある」というのは 何物にも替え難い救いなのです。というより、そういう予想外の事態に対して エスケープポッドが備えられていない処理系を使うなんて恐くて出来ません。 Lisperは臆病なんです。

Lisp:よくある正解

Ruby が安全なだけの言語でないのは間違いないと思う。

2018年ふりかえり

時間配分

ここで書く最も大事なことは今年は日記書いただと思う。

去年までも増やそう増やそうと思って頑張っていたんだけど、明らかに増えたぞーと言える。

過去5年分を比較するとこんな感じになる。

年投稿数グラフ
20149*
20158*
201620****
201719***
201863************

明確。これでも6日に1回ペース。まだ増やせそうではある。

理由はいくつかあるが、

  1. 使える時間が増えた
  2. まとめる役回りが増えた
  3. 調べる役回りが増えた
  4. まとめやすいことをやっている

ということで、まぁ喜んでいいんじゃなかろうか。

4 についてはあんまりここで満足しすぎてはいけないかもしれないが。

技術的に

今年は日記的には概ね

  • モダンフロントエンドの JavaScript
  • FaaS の JavaScript
  • Infra as Code
  • セキュリティ、特にパスワードおよび鍵管理
  • BigQuery 向けの何か
  • 静的サイト（ジェネレータ以外も）

をやっていた。

あと書いていないのは業務系の SaaS API やそれを扱う何かとの戦い1みたいな感じ。

扱うものが単に多岐に渡っているだけでなく、フロントエンドをモダン化するとアーキテクチャ全体もちゃんとモダン化して責務を分離しないとダメっすね、みたいなことを思ったりしながら、仕様化テストからアンチレガシーも同時にやっちゃうぜ、みたいなところがやっぱ得意領域っぽいです。はい。

もともとバックエンドからインフラは見る人がいないので PaaS 丸投げにしてどんどん負荷を下げつつ、テストの自動化で変更をガードしつつ、できることを増やす作戦だったんだけど、近年こっち方面はちょっと移譲できそうな感じになってきているのと、現在の環境的には重点的に扱えた方がよい2ということで徐々にフロントエンドにステ振りを変えつつある。（気づかれてないかもしれないけど）

その他お仕事的には

最近は

  • それコストに合わないっす
  • それ「引き出せ」てないっす

みたいなツッコミ役と壁打ちの壁役みたいなのが多い。これ、割と汎用的な役割なので、なんかそこら中に首つっこめた方がいんじゃね？ みたいな気がしてきている。

イカ的には

今年はヒーローモード、ナワバリ、オクト、ガチマッチと順番に丁寧にやってきましたが、ガチマ始まったらストレスが爆上がりなので、目標切ってどこかでバッサリいかないとまずいかもという気がしている。あ、スプラトゥーン2っていうゲームの話なんですけどね。

Ingressの時も思ったけど、ゲームね、やっぱ向いてないっすね。ストレスになる(笑)

  1. だいたいアーキテクチャ含む設計と現実のデータや振る舞いとの戦いに主にレビュー方面から ↩

  2. UI的な意味と分析的な意味の両方 ↩

2015年のお仕事ふりかえり

久しぶりに年末にふりかえりのエントリが書けるかな。頑張ってみよう。

クラウドとよくできた通知システムとしてのチャットを取り入れた

昨年度から production 環境のクラウド化、リポジトリを社外ホスティングに移行、チャットシステムを入れ始めた。具体的には AWS S3, GitHub, Bitbucket, Slack, Sqale, EngineYard, Heroku, Papertrail, SendGrid, Redis Cloud, NewRelic, CircleCI, Codeship, DNSMadeEasy 辺り。S3 だけは以前から使ってたかな。今年はいろいろ噛み合って動き始めた感じ。

いちばんの動機は自分の仕事の中での「サーバ管理系の雑務」の割合を減らすことと外注と組めるようにすること。1

もう一つの欲としては「この地域でもこういう面白い道具使って仕事してるとこあるんだぜ」というアピールなんだけど、これはまだうまくいってないので、それ以外の成果を書こうと思う。

いちばんうまくいってるのはゼロから自分の手で立ち上げた Rails プロジェクトで、これについては先日の CircleCI のエントリもそうだけど、GitHub, CircleCI, Heroku, Slack, NewRelic がバッチリ連携できてて非常に快適。気に入ってるのは以下の設定。

連携用途
GitHub -> Slackプロジェクト用のchannelで通知なし
GitHub -> CircleCI -> Herokuproduction, staging へ自動deploy
CircleCI -> Slacktestの成否とdeployスクリプトからのPOSTを通知用のchannelに
NewRelic -> Slackerror通知用のchannelに

メール通知を完全にゼロにはできていないけど、日常的に「自分以外の人の動き」「アプリの負荷が上がった」「アプリのエラーが増えた」などが比較的小さな負荷で見えるようになった。

以前のサーバでは log からお手製の swatch みたいなやつを仕込んだりしてたけど、メールより断然スマホアプリと連携できて通知の on/off を細かく制御できる Slack が楽。できることが増えたので管理系の雑務自体が減ったかどうかで言うと実は微妙だけど、以前より全体の状況はつかみやすくなっていて、この部分が2015年最もライフチェンジングだったように思う。

この辺りは Kanazawa.rb の meetup では話題に出してはいるんだけど、日常的にこういうの使ってる会社はこの辺じゃあまりないので、工夫を共有するみたいなところまでは行ってないのが残念。ぶっちゃけると言語の話よりこういう話の方が好物ではあるので、みんながガンガン使えるようにおれが事例を作ってやるぜ。

そういや JAWS x Hokuriku.NET x Kanazawa.rb 合同勉強会でこの辺りの発表した資料上げてないけど、どういう理由で上げてないんだっけ。あぁ、たぶん単純にものすごく大変な時期だったんだろう…。

Kanazawa.rb x Hokuriku.NET x JAWS-UG北陸 : ATND

クラウドを前提にしたWebアプリの楽さと難しさ

とにかく環境の構築、スタートが楽、だけど作法は守ろう

というわけで、世界あるいはトーキョー的には今さらな感はあるけど、自分の中ではクラウド化というのが2015年のいちばんホットな話題。

実際には PaaS でやりますという決定だけして自分でやってないやつ、途中まで自分でやったやつ、立ち上げは自分でやって、移行を他の人にお願いしたあとにチューニングがまた自分の手元に戻ってきたやつなど、いくつかある。

いちばんライトなやつはポチってアプリ作ってポチってリポジトリ作って、bundle install と push しておしまい、みたいなやつで、これは本当に楽になったなーと感じた。サーバに何が入ってて、とか何も気にしなくていい。.ruby-version と Gemfile.lock で決まる。Capistrano の設定も要らない。さすがにカップラーメン作るよりは時間掛かるけど、こんなんでいいんすか、という楽さ。

もちろん、そんな楽なものばかりではなくて、どれも一長一短というかうまくいっているところとそうでないところがあるんだけど、Heroku + Rails で動いているものが今のところいちばん「環境」としては楽。

とにかく環境が portable なのがとてもよい。development と production では middleware は割と違うんだけど、ちゃんと抽象化されているので production でしか動きませんということがほぼない。（なくもない）

12factor 的には当たり前の話なんだけど、これが実は当たり前じゃあないんだ。

というのも、いわゆる「本番での動作しか想定していない」という作り方をしてしまう人はやっぱりいる。結局その辺は PaaS か否かは関係ない。具体的には

  • 秘密情報がハードコーディングされてる
  • 画像アップロード周りで S3 の URL をそのまま DB に書いちゃう
  • Nginx の設定に依存したコード書いちゃう
  • reverse proxy の動作に依存したコード書いちゃう
  • メール周りが SendGrid にベッタリ依存してて development や test で困る

それでいて

  • ストレージが揮発することを忘れたコードを書いちゃう

2015 年だよー。Rails 登場から10年だよー。こんなことやったらテストの自動化も deploy の自動化も難しくなるじゃん、と自分は思うんだけど、そもそもそんな考えがないんだ。社会は厳しい。

こうなっちゃうと何が起きるかというと、単に PaaS はいろいろバラついてて制限が強くて面倒な環境だってことになっちゃうんだね。違うよ、そこは世界の優秀な人が書いたフレームワークがお守りをする部分で、自分で工夫して書いちゃダメなんだよ。自分で工夫して書いた部分がボトルネックになるのであって PaaS が悪いんじゃないよ。

確かにね、「ある程度から先の領域」に入ったら自分で工夫しなきゃいけないところは出てくる。でもほとんどのコードは過去の自分のやり方ではなく、世界の先達の作法に従った方がマシなんだ。だからちゃんと世界を知りなさいという話に尽きる。自分の過去、自分が今思いついたこと、隣の同僚、そういうレベルだけで仕事していいのはごく一部の人なんですよ。

話がそれた。要はちゃんと楽するための作法を知れということです。

楽するための作法を守っていないとどんどん開発速度は落ちていく

のだから。

例えば本番でしか動かないコードをコミットしたら「ローカルではちょっと書き換えて動かす」みたいなアホな手間が生まれる。一度入れたらその後ずっと開発コストは上がった状態になるし、まずミスる。「S3 が動いていれば ok」というコードにすると開発用の S3 が欲しくなる。逆に面倒になって画像が絡む部分はローカルではテストしなくなる。

開発コストを上げて品質を下げている原因は環境じゃない、開発者の姿勢とスキル。

これも2015年によく感じたことの一つだった。

まぁ、開発者のやる気を削いでしまう環境はあるかもしれない。残念ながら。でもそれを言い訳にして改善をしないのなら、そこを辞めた方が結果的にプロダクトを受け取るユーザーはハッピーになるんじゃない？ 君のコードは何のためにあるんだ。アホな組織のためにあるのか？

また説教くさくなった。いかんいかん。

構築は楽だけど IO のコストが見えるようになる

いろいろ楽になったけれど、PaaS は基本的に何もかもバラついているというのは事実で、環境の構築と再現は楽だけど、アプリは常に IO との戦いというのが見えるようにもなってくる。

Heroku + Rails のアプリの中の一つは徐々に

  • ストレージを S3 に追い出す
  • 開発環境を Vagrant Box に
  • Ruby, Rails のバージョンアップと Heroku 移行
    • 開発環境を生 OS に（必要に応じて Foreman / Dotenv）

と変化させていった。いびつになってしまっている部分もあるけど、Rails と便利 gem のおかげで特に環境の切り替えがとても有効に使えていて、移行も比較的スムーズに行えたと思う。実際にはこのリポジトリを GitHub に置いて Heroku 化するダンドリだけ自分でやって移行作業は別な人にお願いしたんだけど。（並行して自分は何やってたかというと、全然違うプロジェクトが動き始めてそっちの設計と打ち合わせに掛かりっきりになっていた。）

今年の日記がぽっかり空いてるのはその時期で、これが実際に動き始めたら AWS の us-east と ap-northeast って遠い2なーというのが最初の課題。それまでもなんとなく S3 使い始めてから遅いなーと思ってたけど、サーバが海外に行っちゃってから遅さがいろいろなところで爆発＆管理系の要件が妙に重くなってきて、正直 Heroku めっちゃ遅いのでは？と思ったけど、単に実装がまずいだけだったという結論が出るまで、あれこれ試行錯誤が続いた。

最終的には

  • S3 への無駄な通信が生まれないように手直し
  • 妙に asset（特に画像）が多く、しかも cache の効かない書き方だったのは CDN に丸投げ
    • 今はどんどん画像をなくすようにしている
  • えいやで全部書き換えてた DB のレコードを必要なものだけに絞る
  • クリティカルなものからバックグラウンド処理に移行（Sidekiq の dashboard かっこいい）

みたいなことをやってた。あとは jpmobile をちょっと独特な使い方してて、それが Ruby と Rails のバージョンアップ時に悪さして、GC 止めたり元に戻したりと、

とにかく NewRelic をよく見ていた時期だった。

サーバ管理をしなくて済むように PaaS にしたらアプリもインフラも見るようになってた。一周回って元に戻る。

とは言え、「探る方法がポチだけで用意できて、しかも分かりやすい」「解決策がある」というのがいちばんの救い。その分、仕組みを考えるに当たって以前より広い視野を求められるようになった。そこはよい機会と捉えている。

次点

  • PHP で packagist を使ってライブラリ公開
  • Google Apps Script を使って管理画面をゼロから作らない

これも以前より方法の幅が広がった話。詳細は割愛。

その他

  • PowerAssert を production で(?)使い始めた
  • Mixpanel を一部で入れたり Google Analytics の staging 環境を用意したり、この辺はまたの機会に。
  • Browserify と Mithril の実験。これを Rails 以外にも展開できると面白そう。
  • 本を読む時間が全然なかった。WebAPI, Mithril とあとは縦書きの本を少々。

でも実は技術じゃない課題がどんどん膨らんでいく…。考えられる人が足りない。（足りないのは己の能力か）

今後の課題

今後はとにかく布教活動かなぁ。今のやり方はハマればすごくいいと思うんだけど、知らない人と組むことはできない。とにかく手が足りないので外部と組む必要があるけど、求めているのは「ちょっと Linux サーバ立てられます」みたいな人じゃない。ところが PaaS の経験のある人が地方にはとても少ない。pull-req を merge しただけで deploy できる環境があるって実感できてる人が少ない。ついでに言うと REST とか resource とかトランスパイラとか React系のフロントエンドの動きとか、ね。

まぁ東京のまねごとをしてるので東京に頼めばいいんじゃないの？という話になるかもしれないけど、予算がね…。ううう…。

布教の話はあんまり言うと全部自分が教える系になりかねないので、それは避けないといけない。じゃあどうやって盛り上げていくのかを考える必要はありそう。

あとはハードウェアまで含めた新しいことをやっていきたいなーなんてことを思いながら最近になってようやく RasPi とか Arduino とか調べてた。たぶん自分がやりたいことにいちばん近いのは Intel Edison Kit for Arduino なんだけど、もうちょっと手軽なものからちょこちょこと遊んでアイディアを膨らませていきたい。

  1. もう一つはちゃんとサービスごとに経費が分かるようにすること。 ↩

  2. すでに S3 が ap-northeast で稼動してた ↩

2013年ふりかえり

なかなかギョーム以外でPCを触り続ける時間が確保できない状態が続いているので、こういうの書く時間も必然的になくなっちゃって久しいんだけど、たまたま大晦日で早く酔っぱらって早く目が覚めたので、書き留めておこう。

※ いきなり脱線だけど、スマホで書くとか個人的には苦行以外のなにものでもないなーと思ってる。メモは書けるけど文章は書けないよー。メモは書けるのでスライドの下書きは書けちゃうんだけど、やっぱ文章は書きながら編集できないとつらいっす。

新しくできたこと・試してみたこと

Vagrant + Chef

正直言うともう忘れ始めているけど、これは2013年でいちばん大きな収穫だった。以前は Mac を使っている自分だけ Rails の環境を不自由なく使えるとか、Linux と Mac で環境を合わせるのが面倒とか、独自に作った VM の Linux が微妙に設定足りなくてたまたまエラーの起きない環境で作業してる人がいたりとか、お仕事的には困った感じになっていたんだけど、今は Vagrant

  • Chef Solo を使った VM を配布して Win/Mac 問わず Linux 上で作業するようにしている。

実際にはこれだけでは済んでなくて、Samba 越しにコード書けるようにしとけばみんな幸せかなと思ったら Windows + Samba のクセ1にちょっとハマったり、みんな同じ環境を使えるようにするために hostonly ( private ) な network にしたのでスマホの実機確認しにくくなって proxy を足すとか、使う道具が増えて面倒になった部分もあるけど、それでもよかったなと思う。

今は vagrant up するタイミングで repos の最新版と比較して警告を出すようにしてるので、プロダクトのコードだけでなく環境も更新しやすくなってきている。こういう細かいノウハウ、もっと表に出していきたい。自分のために。

Padrino

The Elegant Ruby Web Framework - Padrino Ruby Web Framework

ごく簡単なものを実際に作って動かしてみた。どこにもそのメモをアウトプットできないまま時間が過ぎてしまったんだけど、個人的な感想としてはすでに Rails 使ってる人は Rails でいいし、初学者も Rails の方がいいんじゃないかなぁという気がした。ただし、

  1. 要件があまり変化しない（基本的な API 中心とか？）
  2. Rails のように情報が大量に手に入る必要がない
  3. Rails のように便利 gem のカタマリになりすぎると gem のお守りの比率が増えてよくないと判断できる

場合にはいいのかなぁという、消極的な採用理由は残りました。

まずそもそも Rails と併用すると似てるけど微妙に違うコマンド、タスク、作法に戸惑うので割とイライラする。裏を返すとRails の経験があるとだいたい勘が働いて、落ち着いて考えるとだいたい「あーそうだよね」という動きをするということでもある。

ただ実際に利用した 0.11.x で iOS のやや古い Safari で redirect が正しく動かないとか、Rails では経験したことのない「うーん？」という動きをしたり、どーにも Controller の DSL が気持ちよくないなぁという感想が残って、結論としては上のような感じで自分がメインで使うのは Rails かなぁという感じ。

Controller の DSL は Sinatra 由来なんすかね。Sinatra は発想はいいなと思ってるし、Kanazawa.rb の企画に取り入れたりはしてたけど、実はまともに使ったことがなくて、今回初めて書いたけど、あんまり気持ちよくないなーというのが正直な感想だった。すごく初歩的なことなんだけど、ApplicationController を継承しないので、じゃあ全部の Controller で共通する処理はどこに書けばいいの？とか、 module を使えばいいかなと思っても block は module でも class でもないからどうすんだべ、とか調べないと分からないところなんかが個人的な引っかかりポイントでした。2

つまんないこと言ってすいません。

でもなんか「フツーこうすればこうなる」って容易に想像がつく、少なくとも ApplicationController 方式はフツーの OO を知っていれば想像がつくのはよいことなんだなぁと再認識することができたのはよかった。この経験があって、改めて Rails を触ってみたときに、うまいこと Ruby そのものをパワーアップさせてる感じが本当にうまいなぁと小並感を抱いたもんです。callback とか module の使い方が Ruby そのものの理解に繋がっていく感じがすげー3。

だいぶ脱線したけど、Sinatra だけでゴリゴリ書けるものをもう少しうまく扱うのにはよいのかなと思いました。まる。

PhantomJS

タイトルが意味分かんなくなっちゃってるけど、この中に Jasmine と組み合わせる話を軽くまとめた。結論から言うと PhantomJS 1.8 以降はすごく便利だし、使うべし。

ただし、本物のブラウザなのでそれなりにメモリを食うので CI サーバが貧弱だとまずい。

Cucumber

Cucumber - Making BDD fun

やっとまともに回せた気がする。きっかけは Turnip の登場で、Turnip が流行り始めたからこそ逆に Cucumber かなという気がしてきているところ。

ポイントは

  • end-to-end のテストは必ずしも受け入れテストではない
  • Turnip は The RSpec Book はじめ、近年あちこちで言われている二重構造の BDD に逆行しているような気がする

あるいはごく単純な話にすると、開発者は

rake spec

を叩いた時に常に受け入れテストが走ってほしいかということ。で、自分は違うなぁと思った。

自分がなかなか Cucumber を使わなかった理由は単に面倒くさいに尽きる4んだけど、実際に feature を書いたり Turnip に関する記事を読んでるうちに以下のようなことを思い始めてきた。

  • 開発者視点だと Gherkin を使って書くシナリオは必須ではないし、逆にユーザーストーリーとしては記述されない部分の中にも end-to-end でテストしたいものはある
  • だから end-to-end テストすなわち Gherkin というのは変だし、シナリオベースのテストは開発者の安心にとって必要十分じゃないのではないか

で、

受け入れテストは開発者が日常的に動かすテストと別な場所に置いてあって別なツールで動かした方が扱いやすいのではないか

というのが今のところの結論。だから受け入れテストは Cucumber にしようとしてる。実際には自分のお仕事的には受け入れテストが揃っていることは要件ではないので姿勢の問題でしかないんだけど。

Limonade-php ( 未投入 )

Limonade - PHP micro-framework

Sinatra の DSL が気持ちよくないと言っておきながら PHP の Sinatra-inspired なフレームワークを試してた。

小さいビジネスにはこういうので十分かなと思った。ほどよく枯れていて、かつ止まっていない。View がちょっとだけ制限された生 PHP になるのがモダンな感じ。基本は OO ではないので $this-> がコード中に出てこないのがまた気持ちよい。書こうと思えば Class-based な Controller も書ける。

mod_rewrite 頼みなのはそれはそれでハマりポイントがあってイヤだし、Model はスルーだけど、今のお仕事であれば Model は昔自作したやつがあるので、まぁそんなもんかなという感じ。ブツが育ちそうなのが分かってれば Rails にする。

ほか

  • Terminus ( 未投入 )
    • 試した限りではちょっと古い iOS 端末やシミュレータではテストが完走しなかったのもあってまだ実戦投入はしてない。すごくよいとは思っている。
  • Jekyll plugin ( Github Pages でトラブって頓挫中 )
  • AWS S3
  • Fabrication ( 以前から使ってたけど、拙作 easy fabricator と同居させた )
  • Veewee
    • 当初思っていたよりずっと簡単だし、適当に拾ってきた Vagrant Box 使わなくてよいのでオススメ
  • Zapier
    • 無料で使うにはいろいろ制限があるけど、任意の URI に post できるのは助かる。IFTTT ではできないことができるのでよい。

継続できたこと

  • Jenkins
    • Capistranoと組み合わせたり
    • visualize plugin 増やしてやる気維持
  • Capistrano
    • deploy時に必要な権限を制限して実行できるユーザーを増やしたり

Kanazawa.rb

Meetup - Kanazawarb

  • 大物ゲストを招いての開催の成功とその反動の沈み込みを一応抜けた
  • 2013年現在、wtnabe がいなくても meetup の開催は継続できる状態になった
  • 2013年にコミュニティスピーカーデビューを Kanazawa.rb で果たした人が 7人

これは自慢していいと思う。ちなみに 2012年にスピーカーデビューした人が6人で、これを越えたのも自慢。

ただ本当はやっぱり Kanazawa.rb という名前で何かプロダクトやみんなが参照してくれるような資料的なコンテンツが生まれるといいな、その結果みんなにもっと Kanazawa.rb が知れ渡って、憧れの地というか「あの Kanazawa.rb に参加するんです、ドキドキ」みたいなことになれたらいいなという思いはあるけど、なんかどうもこのコミュニティはあんまりそっちを志向していないような気がするなという感想を最近は持ってて、次の目標をどこに置いたらいいのかなぁという迷いはある。

2012年は人材流出コミュニティというのが自虐的な内輪のブランディングではあったけど、マジな話、Kanazawa.rb から次々と有望な人が抜けていく状態だったことはやっぱダメージはあって、少なくとも技術的にリードできてノウハウやスキルのシェアに積極的な人は不足している。やっぱり Asakusa にはなれないよねーという当たり前のことを再確認しつつ、じゃあどうするかはまだ見えていない。

ほんとはこんなこと心配しないでおれはおれのコードを書いてブログを書くだけにした方が自分のためにはなるんじゃないのと思ったりもする。一方で「それじゃあ2000年代と何も変わらないじゃないの、東京以外にはおまえらはいないのですか」ともう一人のおれが問い詰めてくるわけだ。ぶっちゃけつらい(笑)

読んだ本とか

なぜかアサマシが貼れないのでとりあえずそのまま。

  • The RSpec Book
  • アプレンティスシップ・パターン
  • アジャイルレトロスペクティブズ
  • 入門Chef Solo
  • Railsデプロイ
  • コーディングを支える技術
  • SQLアンチパターン
  • TeamGeek
  • これだけ！KPT
  • Twelve-Factor App
  • パターン・ランゲージ
  • 明日の広告
  • Running Lean
  • BMGワークブック
  • ランチェスターNo.1理論
  • 採用基準

ここ数年は帰省のタイミングでまとめて乱暴に読む + 日常的にちょこちょこ、のリズムができてきて、いっときよりは読めるようになってきたけど、まだまだ勉強不足だなと痛感することしきり。

ただまぁスマホしか持てずに本も読めない、何か書いたり作ったりできないという時間が増えているので、これ以上インプットを増やすのはなかなか難しいなぁとは思っていて、歯痒い。

作ったもの

小物ばかりだけど、一応成果は出せていてそこそこ満足。

まとめ

ブログ力の衰えは著しいけど、こうして見るとまだ停滞はしてないのかなという気もするので、そう考えるとそこそこよい年だったのかも。個人的な印象では悩んでばかりであまりいい年だった気がしないんだけど、いい年だったっぽい外面を作るのも大事かなという気もするので、よい年でしたと言っておきましょう。

よい年でした！

  1. ちゃんと設定しないと実行ビットが勝手に立ってアレな感じになる。Samba もだいぶ忘れちゃった。 ↩

  2. RSpec はその辺うまいこと処理しててすごいなと思う。なんとなく module を include しても普通に動く。目的が決まっていて DSL でできることが上手に制限されているからなんだろう。実装の参考になるかどうかはともかく、設計としては RSpec はすごく参考になる。 ↩

  3. この感想が Kanazawa.rb meetup #15 の発表に https://speakerdeck.com/wtnabe/learning-rubys-dynamism-with-rails 繋がる ↩

  4. でも end-to-end のテスト自体はやってる ↩

2009年最後の買い物は Pocket Wifi

iPod touch を買って以来、

Twitter / wtnabe: Mobile Safariのある今、ガラパゴスケータ …

2009.09.19

19:53:27 >wtnabe< Mobile Safariのある今、ガラパゴスケータイWebの貧相さ
加減が本当に残念。あとWebに繋ぐと電池なくなり過ぎ。アプリでのキャッシュ
の活用ができないケータイはもっとメールを活用すべきだなと思った。

ケータイの Web が本当に不便だなと思っていた。

  • 以前に比べれば速いとは言え、やはり性能が足りない
  • ケータイ向け HTML の表現力不足
  • ケータイ向け HTML が PC 向けと分離しているため、ケータイでは逆立ちしても取得できない情報も多い
    • ケータイ向けのページがあっても PC に比べて情報量が少ないため、例えばせっかく目的のお店の近くに来ていても分からないとか、携帯できる便利さをちゃんと享受できていない
  • キャッシュの容量も小さいのでやたらと通信が発生して電池がすぐ切れてしまう

touch は普段それほど Web 閲覧には使っていなかったが、フリックにも慣れ、文字入力でもケータイの方が使いにくいなと感じるようになったので、ネット端末としてはケータイよりも iPod の方を中心に使った方がよいのではないかと感じるようになってきた。

そこで、以前から持っていた emobile の端末を PocketWifi に変更し、PC を持っていなくても iPod touch をインターネットに接続できるようにすることにした。

2009.12.31

19:31:23 >wtnabe< Pocket WiFi 契約してきた。違約金と端末代でそれなりの
出費だけどきっと満足するはず。ケータイの定額サービスを変更した。

これは、1月からケータイ代の端末代キャッシュバックキャンペーンの効果が終わり、端末代が上がるので通信料の方を見直す必要があったためでもある。au のパケット定額でいちばん安いものに変更した。

Pocket Wifi の設定については

2010.01.01

12:10:14 <wtnabe> Pocket WiFi の設定って WiFi で繋いで設定できるのか。
えー。ということは WiFi を他人に解放しちゃうのはオススメしない機械なの
か、これ。
12:33:41 >wtnabe< Pocket WiFi の IP アドレスフィルタリングっていうのは
種別「拒否」で方向「OUT」に固定されてるんだけど、これは外からの攻撃へ
の対応は考えてないのか。まぁモデムだと思えばそらそうなんだけど。
12:51:32 >wtnabe< とりあえず Pocket WiFi の設定完了。設定画面のパスワー
ド変更と WiFi の自動接続オフ、3G 接続をマニュアルに。こんなもんか。
12:57:42 >wtnabe< なんかでもこれ、プライバシーセパレータあるから出先で
3G 回線を共有するにはいいけど、家用の回線にするには fw 周りがちょっと
なぁ。電気屋ではそういう売り方（まとめちゃえば安いよ的な）してたけど、
まずいんじゃね。
  • 10分でWifiが切れる設定を無制限に
  • 自動で3G回線に接続する設定をマニュアルに
  • Wifiには無認証で接続できるように

設定を変更した。繋ぎっぱなしにするわけではないので、自動接続を切ってしまった方がよいかなという判断。これまでも emobile はそれほどヘビーに使っていなかったので、あんまり贅沢に回線を開くとランニングコストが急上昇してしまう危険性がある。

それにしても Pocket Wifi は本体の設定を Wifi 経由でできるのはちょっとあぶないかなーという気がした。まぁすぐリセットできるからブルートフォースで破られてもいいっちゃいいんだろうけど。設定する機会なんて多くないし、USB 経由でしか設定できなくてもよかったんじゃないか。でもそうすると touch からは設定できないからダメなのか？

あと 3G 回線の接続をマニュアルにしたので [ CONNECT ] ボタンを使うんだけど、これの使い勝手が微妙。というのも長押しして接続するんだけど、長く押しすぎると接続モードが切り替わってしまうのである。これ、分かりにくい。

しかしなんだ。

最近でこそガジェット系やケータイ Web にはあまり興味がないが、もともとは cdmaOne の速度と WAP という世界標準を求めて当時のセルラーに乗り換えたくらい Web を持ち歩くことに強い関心を持っていた10年前の自分を思い返すと、この選択は至極当然の判断のような気がしている。

2008年振り返り

を、小正月に書くライフハック。

2008年の頭はその前の年からの PHP 4 -> 5, PostgreSQL 7 -> 8 の移行、サーバリプレイス作業に掛かりっきりでそれ以外よく分からなくなってた。

その成果がこの辺り。

ロクな監視ができていなかった古いシステムをどうにか移行させるためにあれこれ工夫してた時期。今も本当の意味で現代的な管理はできていないんだろうけど、以前よりはだいぶマシなのも間違いない。今後は最近ハマってる Rake ( Capistrano ) でより確実な作業に昇華できるようにしていく予定。

次、監視繋がりというかもっと feed を便利に、ということで Yapra を使い始めた。勢い余って Yahoo! Pipes も始めてみた。また Yapra 繋がりで、長いつきあいの Ruby をようやく Web 方面に活用し始めた。

feed を利用するだけでなく、リソースから API を用意したり feed を吐いたりもしてた。要は今になって HTTP Header を勉強し直したということですな。

また rest-client や Yapra の影響もあって git と github を始めた。

でも正直、git のメモが多いのは git がよく分からない証拠。実際、git を始める前から Mercurial を使っているが、Mercurial のメモは実は一切ない。これは少なくとも Subversion からの移行については、あくまで個人的な感想だけど圧倒的に Mercurial の方が楽だから。

他、

辺りが細かく熱かったところ。また Rack や Routing、jQuery なども含めて

2008年は全体的に Web と Ruby で充実してた年だった（なのに Rails はノータッチ）

と言っていいんじゃないかと思う。あとまぁ Mac も OSX 10.5 に移行して、以前よりいろんなことが快適になったかな。

2009年も基本的にはこの路線で頑張る感じで考えている。とりあえずは Rake と監視能力の強化かな。これまではあまりネットウォッチャーのスキルに興味なかったんだけど、そっち方面を強くしていきたいかなと思っている。

あとは紙を含めて雑多な情報の扱いをもう少しうまく回していきたい。あんまり有名すぎて言うのもはばかられるけど GTD とかライフハックとかももう少し意識した方がいいのかも。

身体も労りつつ鍛えなおさにゃいかんかなーなんてことも気になっている。もういいおっさんだしな。最初から無理の利く身体ではないが、無理せず、いい落としどころを見つける目も養っていかなきゃな。ガムシャラなだけではもうダメなんだ。そこはもう諦めついたよ、さすがに。

2006年の振り返り

作業環境

  • 公私ともに Subversion + Trac に移行

サーバ管理

  • 結局 WSS 2003 にしたが、やはりかなり苦戦
  • WSH + JScript を結構やった

ecmascript

今年は ecmascript の年と言ってもいいくらいにやった。

  • WSH + JScript を結構やった
  • Web もフツーに
  • greasemonkey とか bookmarklet とかにハマった

Y! Widgets は散々調べたけど動くコードはほとんど書いてないな。やっぱ画像で UI を作るってのが面倒。とりあえず基本の UI は px 単位で CSS で作っていった方がいいか？ で、サーバサイドに処理を投げる部分をローカルのコマンドに投げる部分とスイッチできるようにするっつーのはどうだろう。Y! Widget を素早く作れるようになりたいな。

PHP, Wiki

  • pukiwiki のパーサをとりあえずそのまま抜き出した

クライアント管理

  • sysprepとか

こっそりオレフレームワーク

地味ーに。ファイルアクセスと logger くらいですけど。テーブル構造を割と自由に使えるようにできる感触はあるんだけど、sort とか検索のツメがまだ。

そんな感じかなぁ。

来年の目標

まずサーバの仮想化とかその辺からかな。

About

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