誕生日だ

このエントリは、誕生日 Advent Calendar 2014 の 12 月 18 日分です。

誕生日

そういえば、@onk さんと同じ誕生日なんですよね。前々から bio に書いてあるのを見て「あっ同じだー」とは思ってました。

一緒に祝っておきます。はっぴばーすでー!わし&おなかさん!

カーチャン

誕生日について考えるにあたっては、やはりカーチャンへの圧倒的感謝を忘れるわけにはいきません。

わしが産まれる前、わしがこの世に発生したときに「覚悟を決めて産む」「キャンセル」というダイアログが出たと聞きます。結局、カーチャンは1人で産んで、色々あったけど1人で育てました。ロックだ。

今、わしは3人の子供を育成していますが、かみさんと協力してギリギリの状態で、やっと回っています。毎日の大変さが増せば増すほど、あの日「キャンセル」を押さないでくれたカーチャンへの感謝も比例して増していくようです。

33.0 歳ともなれば、仮に 99 歳まで生きるにしたって今まで生きてきた 3 倍の時間でしかないし、誤差っぽいです。それが 0.0 歳だとどうでしょう、何歳まで生きるかに関わらず Infinity 倍ですからね。救急戦隊ゴーゴーファイブの主題歌の中に「ひとつの命を救うのは 無限の未来を救うこと」という歌詞があるんですが、うおー。

この先生きのこることができるか

「生存戦略」みたいなものについて、わしは「この世に産まれてしまいさえすれば、あとはゴールまで生きるだけ」という人生観なので、いまいちピンときません。日本に生まれたのなら、どうあれ生存できちゃうと思います。なお、サバンナでは同じ事は言えません。

「いかに他人を出し抜いて、自分と家族だけは良い思いをするかという戦略」なら、なるほどって思います。ただ、まぁ、あまり他人をシバき過ぎると、殺されるかもしれなくなるので、程々にしないとダメだよなって思ってます。余力はシェアして、治安を高めよう。

「好きなことで生きていく」という事が「生存」であり、「望まぬ事を強いられて生きていく」という事を「死」と同等に捉える前提での「生存戦略」なのであれば、うおー、贅沢な悩みだなと思いますが、豊かであるということは素晴らしいですね。

Advent Calendar

一昨年くらいから Advent Calendar をボチボチ書き始めて、読むのも書くのも楽しいので毎年やることにしました。せっかく 12 月に誕生日があるので、空きがあれば誕生日の枠を確保してます。今年の投稿は下記の通りです。

誕生日ですが「ウィッシュリストに入れてるからには読めよ」などと言いながら難しい本を送りつけるなどの行為は何卒

カテゴリー: 未分類 | コメントする

RubyKaigi & RubyHiroba 2014 に、めっちゃ参加した

四日間フル参加、広場では生活発表と LT やった。
とりあえず、今日はもう寝ないと死ぬ

後で追記する

— 追記( 2014/11/28 )
このあと2ヶ月くらい、燃え尽き症候群めいていた

カテゴリー: 未分類 | コメントする

rubyhiroba で、すとうさんから学んだ事(後編)

はじめに

早いもので、rubyhiroba で、すとうさんから学んだ事(前編)というエントリを書いてから1年以上が経ったようです。そろそろ記憶も薄れてきたし、明日から RubyKaigi 2014 だし、続きを書いて〆ておこうかと思います。
ここからは、わしのノートにメモしてあった内容を曖昧な記憶で補完しながら書いていきます。

※ 注意
※ このエントリはほぼ実話ですが、細部については記憶の欠落や脚色があります。
※ 予めご了承の程、よろしくお願い致します。

あらすじ

ひょんな事から Rabbit のソースコードリーディングをする事になったわし達は…

ソースコードリーディングの様子

Rabbit は、言わずと知れた Ruby 製プレゼンテーションツールで、すとうさんが強力にメンテされている偉大なソフトウェアです。この時のソースコードリーディングで対象としたのは Rabbit::Canvas というクラスのソースコードでした。

require は、いつすべき?

参加者1「Ruby って、各ファイルで require するけど、それって DRY 的にどうなんスか?自分は PHPer なんスけど、PHP には __autoload() とか spl_autoload_register() ってのがあってオートロード出来るのに、なんで Ruby には無いのかなって思うんスよね」
わし(うおー。そこからかー)
参加者2「まぁ、Rails では const_missing をオーバーライドして、しかるべきファイルをオートロードする仕組みがあったりするよ」
参加者1「へー。なんで Ruby 本体に無いんスかねー。なんでスかねー」
すとうさん「あ、ちょうどなかださんがいるので聞いてみましょう。なかださーん」
わし(なかださん、なんで床に座ってパッチ書いてるの…)
なかださん「Rails でやってることなんだから、Gem にしちゃえば使えるじゃん。本体に入れる意味あんの?」
みんな「あざーす」

def_delegate 多すぎ

参加者1「なんか、よく分からないんスけど、def_delegate してる行が多すぎません?」
すとうさん「なぜ、多いと悪いと思いますか?」
参加者1「いや、なんとなくなんスけど、クラスの切り方がうまくいってないときにそうなりがちな気がするのでー」
みんな「ふーむ」

class comment について

参加者1「クラスの冒頭に、そのクラスを説明するコメントを入れたりしないんスか?」
すとうさん「特に必要無ければ入れませんね」
参加者2「ボクは入れる派ですねー。1クラスのソースが1画面に収まるくらいだったら書かないですけど」
わし(あ、これリーダブルコードで見たやつだ)
みんな「ふーむ」

Utils

参加者1「あっ!utils.rb なんてのがあるぞ!」
参加者2「utils っ! utils っ!」
すとうさん「見てしまいましたね」
参加者1「Rabbit::Utils 以外の module も書いてあるぞ」
参加者2「1 file 1 module じゃないんですかー。かー」
わし(怖ー!怖ー!コードリーディング怖ー!)

感想

こういった流れの中でも、すとうさんは楽しそうに場を進めていっていたように記憶しています。慣れているからなのか、人柄なのか、凄いなと思います。
とは言え、このソースコードリーディングは、恐らく場の趣旨とは違ったものになってしまったんじゃないかなと思っています。見ている分には勉強になりましたが、若干、心に闇が生まれました。
今後、これと全く同じ場はもう無いと思いますが、似たような場面に立ち会った際に、少しでも会話の場をハッピーな方向に変えられるような発言が出来るよう心がけながら、明日からの RubyKaigi 2014, RubyHiroba 2014 に臨んでいきたいと思います。

カテゴリー: 未分類 | コメントする

1年前に転職しました

退職しましたというエントリを書いてから、早くも1年が経過しました。せっかくなのでゆるーく1年を振り返ってみたいと思います。

いままであらすじ

1年前、ごく小規模の WEB 受託開発会社から、中規模の広告代理店へ転職しました。

転職先では、エンジニアの社員はわしだけです。

転職して変わったこと

複数のプロジェクトを掛け持ちしなくて済むようになったので、比較的、目の前の仕事に集中しやすくなりました。

電話を取らなくて良くなったので、比較的、目の前の仕事に集中しやすくなりました。

職場が広くて清潔になりました。しかも6月に新築ビルに引っ越してさらに快適になったので、比較的、目の前の仕事に集中しやすくなりました。

システム開発に関するしがらみが0なので、唯一のエンジニアであるわしの裁量で大体のことは決められます。比較的、目の前の仕事に集中しやすくなりました。

何か新しい機能を作るときに、(打算的な)見積もりを作って価格交渉したりする必要がないので、比較的、目の前の仕事に集中しやすくなりました。

目の前の仕事に集中しやすくなったので、比較的、目の前の仕事に集中しやすくなりました。

集中力に乏しいので、本当に助かります。

試してうまくいった事

入社して一番最初に目に付いたのは根性駆動の Excel 業務でした。毎月の定型作業を数日がかりで仕上げているのを見て、これはイカンと思い、VBA は未経験でしたが、少し勉強してマクロを書きまくりました。よくある「2日かかる作業を5分にするような改善」というやつです。同じような箇所は今でもまだまだありますので、今後もゴリゴリ倒していきたいと思います。「人間がコンピューターの仕事を奪うな」がスローガンです。

6年くらい前に Java で構築された WEB アプリが、テストも無くてメンテ可能限界を超えそうになっていたので、Rails で書き直してみました。テストもないし、新機能の需要もありましたので、移植ではなく、要件定義からやりなおしました。1回リスケジュールが入りましたが、先日なんとかリリース出来ました。

部署内の情報共有に HipChat と GitHub Organization を導入しました。それまではメールと口頭のみのコミュニケーションでしたが、今ではメールは社外とのやり取りにしか使っていません。「何か話すべき事があったら、井戸端会議をやる前に issue を立てて下さい」という事を口を酸っぱくして言い続けたところ、今ではすっかり徹底されています。ポケット1つの原則に従うと、本当に捗ります。

うまくいかなかった事

前職では毎日コーヒーメーカーで美味しいコーヒーを入れて楽しんでいましたが、現職では不許可となりました。仕方なくウォーターサーバーのお湯とティーバッグで紅茶を飲んでいます。

前職より年収を倍にしようと思って交渉しましたが、世の中そこまで甘くはなかったです。

Rails アプリの書き直しの仕事をやるとき「この日までには終わりそうかな」と言われて、うっかり「いくらなんでも終わるでしょう」と言ってしまい、割り込みの仕事などをホイホイ受けているうちに「あっ」ってなってしまったのは痛恨事でした。状況の変化を共有していくことの大事さよ。

今後やりたいこと

弊社では ISMS を導入しているので、社内で異質な開発環境についてあれはダメこれはダメと言われない為に、誰もやりたがらない ISMS 事務局のメンバーを買って出て ISMS 活動をしています。色んな会社で聞くような糞セキュリティにならないよう、今後も目を光らせていきたいです。

社内のエンジニアが開発を進めていく事の速さ、安さ、美味さを分かってもらえてきた頃だと思いますので、ここらでもう一人くらい増やせるように色々立ち回っていきたいなと思っています。

言いたいこと

1年前「エンジニアの居ない場所に行ってポストを作れさえすれば、割と無双できます」と書きましたが、1年経った今、やはり正しかったと思っています。エンジニア本人のためにもなるし、情報処理未開の地に住む人達にとっても福音となるのがいいですね。

世のチョットデキル系エンジニア達と比べたら到底パっとしない、わしのようなエンジニアでも、素人の中に居ればスーパーハッカーなのです。パソコンの大先生なのです。わしの場合、運も味方してポストが作れましたが、他にも潜在的な需要が沢山あるはずだと思っています。エンジニアを求めてるのはモヒカンの巣みたいな会社だけじゃないし、転職先を求めてるのはモヒカンばかりではない。そういう需要を掘り起こして、パッとしない系エンジニアとマッチングするようなサービスがあったら良いんじゃないかなと思います。

カテゴリー: 未分類 | 8件のコメント

うちの読み聞かせ

このエントリは子育て 読み聞かせ Advent Calendar 2013の7日目です。

4歳男児と2歳女児を育成中の我が家の読み聞かせについて書こうと思います。

絵本ってホイホイ買ってるとすぐに沢山貯まっちゃって、判も大きいから本棚に入らなくて、積み重なって大変なことになりますよね。いまは段ボールに入れて管理してますけど、あふれてきてどうしようってなってます。みなさんはどのように管理されてるんですかね。こう大量に絵本があると、中から特定の絵本をオススメするために選別するのも大変なので、昨晩、子供らからリクエストされた本を紹介したいと思います。

最初はプリキュアの絵本2冊
『はじめての プリキュアえほん1 わすれもの (はじめてのプリキュアえほん 1) 』と
『はじめての プリキュアえほん2 あぶないよ (はじめてのプリキュアえほん 2) 』です。

この絵本は娘の誕生日会で、わしの友達(おっさん)がプレゼントとして買ってきてくれたものです。開封してすぐに友達(おっさん)が「読ませてくれ!」って言ってきたので、ギフトを口実にプリキュアの絵本を買いたかっただけかもしれません。内容は「あいさつをしよう」とか「道路に飛び出さないように」とか、割と説教じみた話となっております。作画は結構良いです。大きいお友達にもオススメですね。

次はまさかの実用書
『果物の基本』という本です。

この本は20種類くらいの果物について、旬や食べ頃のサイン、栄養成分や保存方法や切り方、かんたんでおいしいレシピなどが詳しく書かれている大変便利な本です。
たまに子供らを本屋に連れて行って「なんでも好きな本を買ってよいぞよ」と言ってるんですが、娘が1歳のあるとき選んだのがこの本でした。本当にこんなの読むんかいなと思って買った本ですが、通算リクエスト数はかなり上位に入ります。この本を読むときは最初のページから順番に開いて、テキストを全部音読します。絵本より文字数が多いので結構大変です。
子供らが一番好きなのは一番最後のページにある「旬のフルーツカレンダー」です。縦軸が果物の種類、横軸が1〜12月の各月となっている表なのですが、旬に対応するマスに太陽のマークが書いてあり、一目で旬の果物が分かります。このページを開く度、4歳児が「いま何月?」と聞いてくるので「いまは12月だよ」などと教えてやると、12月の列を調べて「みかんが旬だね!食べよう!」などと食通ぶっております。
読み聞かせといえば絵本と思うかもしれませんが、絵とか写真がついてる本なら、だいたいなんでも読み聞かせが成立する気がします。本屋に行って児童書以外のものを選ばせてみるというのも一興ではないでしょうか。

最後はアンパンマン
鉄板中の鉄板といっても過言ではないアンパンマン、その関連書籍『アンパンマン大図鑑―公式キャラクターブック』です。

この本の帯に “テレビアニメ「それいけ!アンパンマン」に登場する2200以上のキャラクターが大集合!” って書いてあります。先日多くの人に惜しまれつつ亡くなられた、やなせ先生の仕事ぶりが良く分かる本ですね。見どころはバイキンマンと彼が今まで作ってきたロボについて書かれた部分で、38ページくらい書かれていて熱いです。
ご多分に漏れず、うちの子供らもアンパンマンの信者であり、TV放送の録画や YouTube にある関連動画を貪るように視聴しております。そんな中、この本の良いところはどこかというと、わしがキャラクターの名前と説明を読み上げたところで子供らから補足説明が入る所です。「だいこんやくしゃだよ」と読んでやると「この間、ポッポちゃんとお芝居をやってたんだよ!」などと、視聴済みエピソードの内容を教えてくれます。そういう調子なので、この本に関しては読み聞かせというよりも「わしが子供らにアンパンマンについて教えを請う会」のようになっているのが実情です。ただ、こんな事を続けていたら、多くの子供がアンパンマンを卒業していく中、うちの子供らだけアンパンマンオタクとして青年になってしまうのではないだろうかと心配したりしなかったり。

以上が昨日読み聞かせた本でした。
たまたま昨日リクエストされたのが上記のものだっただけで、うちにはもっと意識の高い絵本とかもあったりするんですよ?

カテゴリー: Blog, 育児 | コメントする

サンライズ出雲で行く RubyWorld Conference 2013

カテゴリー: 未分類 | コメントする

退職しました

私事ですが、7月末日をもって退職いたしましたので、ここにご報告いたします。
先ほど送別会から帰宅いたしました。

あんた誰?

「株式会社○○を退職しました」という記事を見る度に思うこと
しがない WEB†DB エンジニアです。
(技評さんとは何の関係もありませんし、記事を書いたこともありません。毎号読んではいます)

やめた会社

Web システム開発受託やホスティングをやっている従業員数3〜5人くらいの小さい会社です。
私が大学4年の3月に就活を始めて、なんとか内定をもらった2つの会社のうちの1つでした。

学んだこと

Perl とか Java を使って WEB システムを作るにあたっての一通りの事は学べたと思います。(まだまだ至らぬ所が多いですが)
中でも SQL の扱いなどは割と慣れたもんで、生でゴリゴリ書いたり、ORM に書かせたり(書いてもらうのではなく)はつつがなく出来る感じになりました。
技術的な事の他にも、提案から保守まで一貫して引き受けるスタイルの仕事でしたので、お客さんとの折衝も含めて幅広く学べたと思います。

困っていたこと

他の従業員が出社したりしなかったり、暗くなってから出社してくるのがキツかったです。
「プログラマは時間に縛られない(キリッ」と言われても、お客さんとのやり取りも我々の仕事なのですよ?
結局、お客さんの稼働時間帯との兼ね合いで、問い合わせ対応や各種事務などの作業は私1人に集中しがちになっていました。
また、横の繋がりが希薄になり、各プロジェクトの属人化が進んでいました。これは問い合わせ対応時に相当な負担となっていました。

零細における受託開発の限界

今のままのビジネスモデルで会社や社員が富やパワーを蓄えることが出来るのか、疑問に思っていました。
受託開発で利益を増やしたかったら、大雑把に言って人月単価を上げるか稼働率を上げるかしかないと思います。単価を上げると言っても、人月単価の相場(60万〜120万/人/月くらいですかね)ってのがあるみたいで、それを逸脱すると結構強く突っ込まれたりしますので、額面を上げていくのは難しいと思います。
では稼働率はどうかというと、すべての従業員が毎月1人月ずつ消化する状態は保てていましたので、稼働率をこれ以上に上げるということは、稼働率を120%、150%、200%としていく事に他なりません。ところが、小さい会社ですので、”本当の”受注情報をみんなが知っています。例えば「納期」「受注額」「人月数」などです。それらを知っていると、仕事のクオリティが、そこに合っていきます。もっと短期間で出来るはずの事が「本当の納期」に引きずられて「見積もり通りの人月」に収まったり、酷いときには納期に遅れたりします。「この仕事、とっくに終わってるけど、提出期限までまだまだ期間があるから出さんとこ」みたいな事も横行します。
早くできるものを早くやる事による圧縮は相対的に単価を上げることになるんですが、エンジニアに見返りが無ければ全体に還元されないようです。「レバレッジを効かせてみんなで豊かになろう」ってコンセプトを経営層も含めて共有できない限り、人月が見えちゃってるエンジニアの生産性は上がりにくいのかなと思います。(単にうちの意識が低いだけだったのかもしれませんが)

なぜやめたのか

受託開発には、お客さんの求めるサービスを見出し、それを形にしたモノがお客さんの求めるモノであったときに感じられる喜びがあります。ただ、やはりどこか他人事な感じが常につきまとい「契約内容さえ満たせてればおっけーだし」と思ってしまう癖がついていました。そういう自分を客観的に見て、このままでは誰も幸せにならないという想いを抱いていました。それが今回の辞職の原動力となっています。

どこかで「自社サービスのエンジニアは24時間365日、自社サービスについて考えている」というようなことを聞きました。これを聞いてからずっと頭の中でリフレインしており、意識していました。そして、もし転職するなら自社サービスをやっている会社のエンジニアになろうと決意していました。

あと、仕事で思う存分 Ruby を使いたかったんですが、既存の案件を急に Ruby にするわけにもいかず、悶々としていました。

次の職場

とある広告代理店に就職しました。
この会社はB2Bの自社サービスを運営しており、今までは開発運用は外注していました。
そこへ内製への舵取りをしたらどうかと提案したところ実現し、そこに生まれたポストに私が収まった形です。
今までにエンジニアを雇ったことが全く無い会社だったので、エンジニアのポストを作るところから交渉して内定をもらいました。

これからの仕事

当面はサービス周りの色々な事象を見える化したり、自動化したりする作業が続くと思います。
Ruby を使う事ができる場面がかなり増えそうなので、非常に楽しみです。
24時間365日、このサービスの事を考え、手を動かし、価値を創造していきます。

まとめ

エンジニアの居ない場所に行ってポストを作れさえすれば、割と無双できます。
そこで、井の中の蛙になって腐らない限り、みんな幸せになれそうです。
今『Team Geek』を読んでいますが、この状況に役立つ事が色々書いてあるげです。さらに熟読しようと思います。

カテゴリー: 未分類 | 6件のコメント

rubyhiroba で、すとうさんから学んだ事(前編)

※ 注意
※ このエントリはほぼ実話ですが、細部については記憶の欠落や脚色があります。
※ 予めご了承の程、よろしくお願い致します。

ruby hiroba に参加してきたので、レポートを一人称の小説風に書いてみます。

わしは druby hiroba が終わった後、景色のいいテーブル席でもくもくと復習していた。そこに、Ruby コミッタのすとうさんが、意識の高そうな rubyist を3名ほど引き連れてやってきた。

すとうさんは空席を指差して「ここいいですか?」
わし「はい、もちろんどうぞ」

そうして着席した彼らの話を聞いていると、なにやら、これからリーダブルなコードを崇めるサバトを開くとのこと。なにそれ怖いと思いながら、もくもくに戻ろうとするわしに…

すとうさん「当然、あなたも参加されますよね?」
わし「え!?あ、はい。よろしくお願いします」

ですよね。そこにいるんだから参加ですよね。

すとうさん「以前『リーダブルコード』が出版されたときにワークショップをやったんです」
わし(DevLOVE 2012 の『リーダブルコードを読んだ後』のことかな。わしも参加してたわ)
すとうさん「そこでは講師の立場だったのですが、むしろ自分で参加したいと思って、この場を設けました」
すとうさん「まず、なんでもいいので、既存のソースコードを読んでいきましょう」
すとうさん「そこで、リーダブルな所、アンリーダブルな所を見つけたら、その理由を挙げていきましょう」

なるほど、RubyKaigi での発表の実践というわけですね。コードのリーダブルな良い所が見つけられれば、それを真似できるので、自分のコードに生かせますね。

すとうさん「では、みなさんの中で、この場の題材にするコードをお持ちの方は?」
みんな「あー。仕事で書いてるコードは公開できないし、あんましないですねー」
すとうさん「そうですか。みなさんは普段『公開できないコード』をお書きになってるんですねぇ(震え声)」

そう言えば、すとうさんは、ぐんま Ruby 会議での招待講演の際にも「私はフリーソフトウェアプログラマー」と、熱く語っていた。プロプライエタリなソフトウェアについては色々と思うところがあるのかもしれない。

すとうさん「では、何かライブラリのソースでも読みますか。最近使ったライブラリ、何かありますか?」
わし「Rabbit ですね」

後に、この発言をする前にセーブしておかなかった事を後悔するとは、わしには知るよしもなかった…
(つづく)

カテゴリー: イベント | 1件のコメント

ぐんまRuby会議へ行ってきました

ぐんまRuby会議01へ行ってきました。

出発

午前中は家の用事などがあり、時間の余裕が無かったので、新幹線で行きました。
人生初の2階建て新幹線『E4系 Maxたにがわ』に乗りました。2階の窓から外を眺めていると、すれ違う『こまち』や『はやぶさ』のパンタグラフが丸見えで面白かったです。「パンタ丸見えアングル」です。

E4系Maxたにがわ

旅路

高崎駅から会場までは2kmくらいあったのですが、せっかく初めて降り立つ地なので歩いて向かいました。
途中、踏切があったのでカメラを構えていたら、湘南色の上越線が来たので撮影しました。帰宅後に息子に見せたら好評でした。

湘南色の高崎線

基調講演

最初は『初めてのRuby』の著者 yugui さんの基調講演でした。
家に IA-64, MIPS, RISC, Power その他多数のアーキテクチャのマシンを揃えて、それぞれのマシンで Ruby をビルドしているそうです。
「Ruby は今は WEB を主戦場にしているが、今後、様々な分野で活躍すると思われる。その時に備えて、いろいろな環境で動かせるように確認しておく必要があるのだ」とおっしゃっていましたが、正直それは建前で、変態なだけなんじゃないかなと思いました。でも、最後まで話を聞いてみると、決して変態だけではないという事が分かりました。本気で理想の世界を目指して取り組んでいらっしゃるようでした。(参考:ぐんまRuby会議01で発表した

様々なアーキテクチャでRubyをビルドするというyuguiさん

招待講演1 「プログラマー」 須藤功平さん

「プログラミングでつまづく人を少なくしたい。ではそのためにはどうすべきか」
「問題を”回避”しないこと。バッドノウハウをドキュメントに書いて回避するなどしていると、やはりつまづく人は絶えない」
「根本的な原因を直す事が大事」
「そのためにはソースコードがなければならない」
「そこでフリーソフトウェアですよ」
あえて OSS と言わずにフリーソフトウェアとおっしゃっていたのは、自由ソフトウェアの哲学からなのでしょうか。
質疑応答での咳さんとの絡みが面白かったです。Ruby コードの感想戦 【第 2 回】 WikiRの続きを読んでいるかのようで、須藤さんと咳さんの仲の良さが伝わってきました。

招待講演2 「サラリーマン」 大場光一郎さん

ロールプレイングゲームの内容を軸に、サラリーマンプログラマーとしてどのように生きてきたかというお話でした。
「就職先はコードが書ければどこでも….良くない!」

群馬の中心で愛を叫んだけもの

群馬でフリーランスエンジニアをやっている方2人のお話。
発注元の割合が「地元2:東京8」くらいで、リアルで東京に行かなければならないときに大変とのことでした。

LT

「アーティスト」関 将俊さん

「一度それを見ちゃったら、その後はそれを使うしか考えられないような、かつ、普通は思いつかないようなモンがカッコイイ。そういうのを作って見せびらかすためのものが、オレにとってのオープンソースだZE」って感じでカッコ良かったです。

「自由ソフトウェア GnuPG と Gnuk Token」g新部 裕さん

「お前ら、オープンソースって言うな!自由ソフトウェアだ!覚えとけ!」って感じで怖かったけど、カッコ良かったです。

「みんなで使おう!愉快に書けるWebアプリケーションフレームワーク Padrino」こしば としあき(@bash0C7)さん

Padrino Blog Tutorialを見れば簡単に使い始められるので、みんな使いましょう!ついでに、開発にも参加しちゃいましょう!」というアピールでした。

「群馬vs東京」五十嵐邦明(@igaiga555)さん

「群馬と東京は人口が17倍も違う。勉強会をやろうにも、東京で50人集まるようなものでも、群馬だと3人だったりするのがキツい。東京はイベントが成立するための閾値が低い。そういう東京に、経験値稼ぎのためにやってきた」確かに、よほどニッチなテーマでも、数名は集まりそうですね。東京。密度は世界トップレベルでしょうし、ヘタしたら世界で一番、勉強会を開きやすい都市なのかもしれません。

「Ruby本から読み解くRuby考古学」斎藤ただしさん

オブジェクト指向スクリプト言語 Ruby (ASCII SOFTWARE SCIENCE Language)』が出版されるまでのいきさつなどを語って下さいました。「俺たちは Matz の夢の中で生きてるんだ!」熱かったです。

「Rubyが私にくれたもの」寺嶋章子(@shokolateday)さん

「プログラムは思うように動かない、書いたように動く。という論理的な考え方は子育てにも生かされている。現在、Rails で保育園SNSを作ってます」保育園SNS、期待しています。休憩時間に2人のお子さんが乱入して来ましたが、大変可愛かったです。

ゆRuby Beyond

guRuby の方々は普段『初めてのRuby』を写経されているそうです。
このセッションでは著者の yugui さんを交えて、会場全員で写経を行いました。
対象は「9.6 Rubyの黒魔術」です。
当日、質疑応答で yugui さんのコメントが色々あったので、拾えた範囲でソースのコメントに書きました。

9.6.1 eval 族

# -*- coding: utf-8 -*-
# 文字列評価
b = binding
# 読者に binding とは何か?と思わせるために、b=binding を入れた
while code = gets
  p eval(code, b)
end
# -*- coding: utf-8 -*-
# コンテキストのすり替え
class CybernetedAndroid
  def initialize(name) @name = name end
end

proc = Proc.new {
  p self
  p @name
}

proc.call

dicey = CybernetedAndroid.new("dicey1")
dicey.instance_eval(&proc)

dicey = CybernetedAndroid.new("dicey2")
CybernetedAndroid.class_eval do
  def save; puts "saved" end
end
# do .. end と { } について
# 返値を代入したい時には { } にしている 
dicey.save

なんか「手元に tk が入ってないー!」とかって声があちこちから聞こえたんですが、みなさん Ruby1.8 を使ってるんですかね?

# -*- coding: utf-8 -*-
# 言語内 DSL
require 'tk'
TkLabel.new {
  text "Hello, World"
  bg "red"
  pack
}
TkButton.new {
  text "Close"
  command {exit}
  pack
}
Tk.mainloop

9.6.2 method missing

# -*- coding: utf-8 -*-
class Reporter
  def method_missing(method_name, *arguments)
    puts "メソッド #{method_name} が次の引数で呼ばれました"
    arguments.each{|arg| puts arg}
  end
end
reporter = Reporter.new
reporter.report
reporter.emargency 1,2

9.6.3 set_trace_func

これ、pry で実行したら大変な事になりましたw

# -*- coding: utf-8 -*-
# 最後に頼りになるのは debugger
set_trace_func proc {|event, file, line, id, binding, classname|
  printf "%8s %s:%-2d %10s %8s\n", event, file, line, id, classname
}
1 + 1

9.6.4 継続

# -*- coding: utf-8 -*-
require 'continuation' if RUBY_VERSION >= '1.9'
1.upto(10) do |i|
  if i == 3
    $cont = callcc{|continuation|
      continuation
    }
  end
  print i, ' '
end
$cont.call(nil) if $cont
# call の引数に nil を入れるのはなぜ?
# callcc の返値になるので、無限ループしなくなるという仕組み
# callcc の cc とは current continuation の事
# 『プログラミング言語 SCHEME』を参照

質疑応答

Q: 他の黒魔術は?
A:この章には書いてないけど、ruby の黒魔術について語るなら、send メソッドの存在を忘れてはならぬぞよ

Q:『初めての Ruby』の次に取り組むべき本は
A: リファレンスマニュアルでも読んだらいいんじゃないですかね。もしくは幸福の王子本
※幸福の王子本というのはdRubyによる分散・Webプログラミングの事ですかね

カテゴリー: イベント | コメントする

26個目のアンチパターンについて『SQL アンチパターン』

SQLアンチパターンを発売日に買って、それなりに熱心に読みました。
これはどえらい本が出てきたなってことで、理解を深めるため、関連する3つのイベントに片っ端から参加しました。

一つ目は DevSumi のセッション
SQL アンチパターン – 開発者を待ち受ける25の落とし穴( 2/15 )

二つ目はジュンク堂のトークセッション
データベースを巡る世代間闘争( 2/21 )

三つ目は DevLove #110
SQL アンチパターン・レトロスペクティブ -データベース危篤患者の救出-( 2/26 )

三つめのイベントで「みなさんも26個目のアンチパターンを考えてみて下さいね」という趣向があったので、わしも一つ提案してみようと思います。

26個目のアンチパターン

名前

オーバードライ(やりすぎDRY)

目的

重複する定義の排除

アンチパターン

<例1>
「amount が色んなテーブルに定義してあるのは冗長なので、amounts テーブルを作って、各テーブルには外部キーとして amount_id を持たせましょう。amount 属性の値を入れたい時は、まず select id from amounts して、見つかったらその id を外部キーにします。見つからなかったら insert します。その後、改めて select すれば、id が得られるはずなので、それを外部キーにします」
というような事をしてしまうと、
「こっちのクラスで想定している amount は 1000 未満に制限したいんですが!」
「でも、こっちのクラスの amount は 1000 の倍数じゃないとダメです!」
「矛盾してる\(^o^)/ 」
という事態になりかねません。

<例2>
「住所と名の付く属性は addresses テーブルへまとめて、必要なテーブルから参照しましょう。addresses テーブルの属性は、住所を必要とするテーブルのニーズを全部カバーしましょう」
というような事をしていると、
「こっちのクラスの住所には郵便番号が必須ですよ」
「でも、こっちのクラスからは郵便番号が入力出来る保証が無いので NOT NULL 付けるのはやめてください」
「矛盾してる\(^o^)/ 」
という事もしばしば。

アンチパターンの見つけ方

「とにかく、同じ名前の属性が無いかどうか、徹底的にチェックしよう」
という号令で、機械的にまとめていると、事故が起こりやすい気がします。

アンチパターンを用いても良い場合

当該属性が、ドメイン的に同一の概念である事が考慮されている場合には、何とか使えなくも無い気がします。ただ、数量のようなものまで共通化してしまうと、check 制約などを付けたいときなどに困るでしょうし、何より、使いにくいです。

解決策

共通のテーブルを定義するにあたって、文脈によって必須であったりそうでなかったりする属性については、用途に応じて特化したサブテーブルを作る事によって対応するといいでしょう。例えば、郵便番号が必須なクラスが必要としていた「住所」というのは、実は「配送先」であったというような事です。サブクラスとして「配送先」を作れば、矛盾を避けることが出来ます。
『「分ける」ことは「わかる」こと』と言われることがあります。ドメインの分析をきちんと行って、同じものは同じに、違うものは別に、という分別をする必要があるという事でしょう。

感想

私のいたグループで、この話をしていたところ、和田省二先生がいらっしゃり、「住所テーブルの話ですか?本来、住所ってのは、緯度経度ですよ!」という話をされはじめて、どひゃあ!ってなりました。その後、「サブテーブルを作って余計な属性を追い出す」という本件の解決策について、教えて頂きました。ありがとうございました。

27個目のアンチパターン

名前

シックスセンス(第6正規形)

アンチパターン

こちらは名前のみの出オチで、アンチパターンと言うと語弊がありますが、付録 A.3.7 に「Bugs テーブルが完全に第6正規形をサポートするには、ほぼ全ての列に個別の履歴テーブルが必要になり、テーブル数が過剰に増えてしまいます。第6正規形は、ほとんどのアプリケーションにとって過剰な正規形です。ただし、データウェアハウスの一部では、第6正規形が使用されています」と書いてありましたね。
HBase なんかでも素でカラム毎の履歴保存をやってくれたりするみたいなので、本当に履歴にこだわるならそういうモノを使う事も検討に値するでしょう。

カテゴリー: イベント | コメントする