2014年2月8日土曜日

sbt 0.13.1でMaven Centralリポジトリに登録する方法

今日の第3回 Scala関西ビギナーズに間に合わせようと、先週から毎日少しずつコードを書き進めて、dmm4sというライブラリを作った。

SNAPSHOT版とはいえなんとか勉強会当日にリリースが間に合い、そこそこの笑いを取ることができた。

sbt はご存知の通り、ver間の互換性に難があり、sbt 0.13.1でのライブラリ開発はちょくちょく詰まりポイントがあった。Travis CI, Coverallsの利用など、多くはsbtのverによる依存関係の問題で、基本的には各pluginやライブラリの最新版を使うことで解決することができた。

Maven Centralリポジトリへの登録も、基本的にはsbtのドキュメントの通りで問題なかったのだが、ちょくちょく苦労したポイントがあったのでまとめておこうと思う。

環境は
sbt version: 0.13.1
scala version: 2.10.3
Mac OS X 10.9.1

1. Sonatype OSSRHでJIRA登録

まずはSonatype JIRAにユーザ登録し、ログイン。その後画面の左上あたりにある"create issue"をクリックし、必要事項を記入する。

Issue Type: "New Project"を選択
Summary: プロジェクトの概要
Group Id: build.sbtなどに設定している、organizationの値
Project Url: プロジェクトのサイトURL(githubのURLで良い)
SCM Url: githubのURL

ちなみにdmm4sのチケットはこちら

しばらく(1日くらい?)待っていると、中の人が設定終わったよ、という返信をくれる。
僕は深夜にJIRA登録したのだが、登録後10分くらいで返信が来てビビったw

2. PGPキーの作成

gpg --gen-key
コマンドでPGPキーを作る。gpgが入って無ければ、
brew install gpg
でインストールできる。

gpg --lisy-key
で作成されたキーを確認し、
gpg --keyserver http://pool.sks-keyservers.net --send-keys {キーID}
でkeyserverに公開鍵を登録する。

3. sbtのセッティングとpublish

http://www.scala-sbt.org/0.13.1/docs/Community/Using-Sonatype.html

上記のドキュメントに従い、sbtに各種設定を追記する。
基本的にはここに書かれているコードをコピペしつつ、sonatypeのパスワードとか、自分のプロジェクトのURLなどを書き換えればいいのだが、publish時にPGPキーの署名をする部分でうまくいかなかった。

sbt 0.13 でPGPキーの署名をしつつpublishするには、SBT PGP Pluginをインストールし、sbtで
publishSigned
のコマンドを実行する。

上記のsbtドキュメントにもSBT PGP Pluginへのリンクが貼ってあり、ここに"~/.sbt/plugins/gpg.sbt"ファイルを作成して、"addSbtPlugin("com.typesafe.sbt" % "sbt-pgp" % "0.8.1")”と書け、とある。

僕もそれに従ったのだが、sbtで"publishSigned"のコマンドを認識してくれない。

これは、ファイルの作成場所が間違っており、正しくは"~/.sbt/0.13/plugins/gpg.sbt"が正しい。

4.リリースの処理を実行

https://oss.sonatype.org/index.htmlにアクセスし、sonatype JIRAと同じアカウント、パスワードでログインする。

左側の一覧から"Staging Repositories"をクリックすると、一覧が表示され、自分のプロジェクト選択。"close"を実行する。ここで成功したら"release"を実行。

あとはJIRAに、リリースした旨をコメントすれば、中の人がCentralリポジトリに同期させてくれる。

とまぁ、こんな感じ。

2014年1月26日日曜日

命がけのリアル脱出ゲーム - トイレに閉じ込められたはなし -

■トイレのドアノブが壊れる

2014年1月25日 22時頃。友人たちと楽しんだベルギービールの余韻に浸りつつ、帰宅。
突然の雨に体を濡らし、熱いシャワーでも浴びたいところだったが、ビールの摂取に起因する尿意を解決するため、とりあえず部屋着に着替えてトイレに入る。

用を足し、水を流し、外に出ようとドアノブに手をかけて右に回すが、手応えがない。
訝しみつつそのままドアを開けようとするが、当然ドアノブに手応えがない以上、ノッチが引っかかったままで開くはずがない。

ん? 何かがおかしい……。

酔っていてドアの開け方を忘れたのかな? 右回しかと思ったけど左回しだったかもしれん。

もう一度、次はドアノブを左に回す。…が、手応えなし。

うっかり鍵をかけてしまったのかもと思い、鍵のつまみを回すも、やはり空回りするばかりで手応えがまるでない。なにをどうやってもドアのノッチが開いてくれない。

これは…まさか…閉じ込められたのか…。

長い闘いのはじまりである。

■自力脱出を試みる

我が家は妻と2人暮らしである。土曜日の夜、普通なら妻がいる。さして広い家でもなし、大声で彼女を呼べば通常ならかけつけてくれるはずである。

が…しかし…。

妻はIT業界の闇、デスマーチに巻き込まれ、休日出勤の只中にあった。22時にもなるというのに帰ってきていない。デスマ滅んでしまえ。ブラック企業ごと滅べ。この世から。跡形もなく。

雨に濡れて体も冷えている。いつ帰ってくるともしれないデスマーチ中のITエンジニアの帰宅など待っていられない。まずは自力脱出を試みる。

脱出の鍵はやはりドアノブである。ドアノブが故障しているのはもはや明白であるが、これをなんとかしないことにはドアは開けられない。現状確認だ。

どう回しても空回るこのドアノブは、調べてみると左にいっぱい回した状態から、右にいっぱい回した状態まで300度ほど回転する。1回転より若干少ない。
そして、ドアノブの中心に鍵をかけるためのつまみがついている。これも空回りするが左右に回転する。

これらの組み合わせで、なにか運良く一瞬でもノッチとドアノブが連動しないだろうかと試してみる。

左にいっぱい回した状態で、鍵のつまみを左右に動かす。次に右にいっぱい回した状態で、鍵のつまみを左右に。これをドアノブを少しずつ動かしながら根気よく組み合わせを試していく。直交表が手元にほしいところであるが贅沢はいえない。頭にExcel方眼紙を思い浮かべながら全てのパターンを網羅する。

…が…開かずっ…!?

空回りしているのだから当然か。ドアノブの組み合わせによる解放は早々と諦める。

次にガチャガチャと力任せにドアノブを乱暴に扱ってみるが、なにも起こらない。刑事ドラマで、密室殺人発生時に強引にドアをぶち破っているシーンを思い浮かべ、肩から力任せにドアに体当たりしてみるが、肩を痛めただけでドアはびくともしない。

…なんて堅牢なドアだ…。たかだか室内のトイレのドアをここまで頑丈にする必要がどこにあるんだ……。

少し心を落ち着けて、冷静に現状を確認して脱出の手立てを検討することにする。

■トイレの密室感は異常

脱出するために、自分になにができるのか。今ぼくの手元にはどのようなカードが配られているのか。それを確認する。

外部との通信手段さえあればどうとでもなるはずだが、大便のときならともかく小便をするだけのためにわざわざ個室にiPhoneを持って入らない。

外部との通信手段は皆無である。

次に室内を見回す。

まず、トイレ清掃用のブラシが便器の脇に設置されている。あとは予備のトイレットペーパー、そのトイレットペーパーを設置するために芯を貫く棒。トイレクリーナー的なもの。これだけ。

……そう…これだけ…。

トイレの室内に工具などあるはずもない。ドライバーの一本でもあればドアノブを外すこともできる。しかし、何もない。

一般家庭のトイレの個室の中には、何一つとして脱出に使える道具はないのである。

ここで、子どもの頃に読んだ冒険小説を思い出す。冒険小説の主人公は、一見するとなんの関係もない道具をうまく応用して使うことで、サバイバルを切り抜けていた。ぼくにもやれるはずだ。考えろ。極限まで思考を巡らせろ。

まず、何か硬いカードのようなものをドアの隙間に押し込んで、ノッチを外せないかと考えた。

トイレットペーパーの芯は結構硬い。これをある程度の強度を確保しつつ平らに加工し、使えないものだろうか。

結論からいうと、ダメ。外側からならともかく、内部側は、ドアがこれ以上内側にいかないように枠がはめられていて、それが邪魔をしており、ドアのサイド側の隙間になにかを差し込むことができないようになっている。

トイレットペーパーはどうやら脱出には使えそうにない。

次にトイレットペーパーを設置する棒をなにかに使えないかと考えた。

ドアを見ると、下部に手のひら程度なら通過できるくらいの大きな隙間が開いている。ここに棒を押しこみ、テコの原理でドアの一部でも破壊できないものか。

……えいや!!

勢いにまかせて棒に力を込めると、バキッ、という音とともに手応えが…!?

……棒が折れた。

もうだめだ…。密室すぎる…。残されたトイレクリーナーとトイレブラシをどう応用したらドアを破壊することができるというんだ……。こんなもの、トイレ掃除する以外の使い道なんて思いつかない…。

床にしゃがみ込み、絶望に打ちひしがれる。もう妻の帰りを待つしか無い。ドアの下部にあるこの隙間。ここからドライバーさえ渡してもらえたら、ドアノブを外すことができるし、脱出の手段は劇的に増えるだろう。iPhoneだって手に入る。

しかし、これがもし1人暮しだったらどうか。脱出の手段はゼロ。我が家にたずねてくる人など、Amazonからのお届け物を持ってくる配達員以外いない。しかも今はAmazonに注文しているものも無い。

…餓死するしか無いじゃないか!?

突然襲い来る死の恐怖。寒い。喉が渇いた。トイレの水って飲んでも平気なんだろうか。飲んでお腹を壊しても、トイレだしそこは大丈夫そうだな。

様々な思考が脳内を駆け巡り、トイレの床に体育座りでリアルに泣く、35歳の男の姿がここにあった……。

■妻の帰宅。ついに脱出にむけて光明がさす

永遠にも思える時を、トイレの個室の中で過ごす。時折隣の部屋の住人がトイレを利用するする音や、外の廊下を別の部屋の住人が歩く音などが聞こえ、その度にドアや壁を叩いて存在を主張してみるが、何の反応もない。

気が狂いそうだ。

どれくらい経っただろう。我が家の玄関が解錠される音が聞こえる。

!!!!?? 妻が帰ってきた!!!!

立ち上がり、ドアを力いっぱい叩く。「助けてくれ!!!! 閉じ込められた!!!!!」

事情を説明し、例のドアの下の隙間からiPhoneとドライバーを手に入れることに成功。

これで勝てる!!!!!

少し余裕が出てきたので、iPhoneを使ってTwitterにつぶやく。

瞬く間に大量のRT。
お前らRTしてる暇があったら助けろ! ksg!!

しかし、さっきまでのぼくとは違う。今は手元にドライバーがある。
慎重にネジを外し、ドアノブをドアから取り外す。これでなにか手がかりが得られるはずだ。


結果がこうである。
真ん中の四角い穴。これをどう回しても、ドアにはなんの反応もない。どうやら完全に壊れているようだ。
僕はドアノブを外して何がしたかったのだろう。完全に詰みだ。内側からできることはもう何もない。

なんなのだこれは。いくらなんでも密室すぎるだろう。もっと安全側に倒して設計しろよ。トイレのドアをここまで堅固にして、いったい誰が得をするのだ。もうだめだ。自力でできることなど何もない。ここはもう、業者を呼ぶしか無い。

業者に連絡する。深夜ということもあって、到着まで4, 50分かかるという。ここからさらに1時間弱待つのか…。

ここからの1時間は妻を待っているときの絶望感とは打って変わって心穏やかだった。脱出の糸口が見えていたし、TwitterでRTされまくって100近い励ましのリプライをもらっていた。もうぼくは1人ではない。あと50分。耐える! そして生還してみせる!!

■神の使い。業者がやってくる

玄関のチャイムが鳴る。深夜2時。閉じ込められて4時間近く経過していた。

やっと業者がやってきた。妻と金額の話をしている。

払う…!金ならいくらでも…!! ここから生きて出ることさえできたなら…!! 払う! 払わざるをえない…っ!

業者の話によると、ドアは完全に壊れており、ドリルを使って内部の金属を破壊するしかないという。なんだそれ。自力では無理ゲーすぎるじゃないか。1人暮らしだったらマジで詰んでるぞ……。

深夜のマンションに響き渡るドリルの音。ご近所の皆さんに申し訳ない。しかし仕方がないじゃないか。こっちは生き死にがかかっているんだから。

金具が完全に破壊され、ドアが開く。やっと外の世界に出られる。生還だ。まだもう少し、人生を生きることができる…。

見事な業者の仕事ぶり。プロの仕事である。神すぎる。

こうして、ぼくは脱出することができた。
最初の閉じ込めツイートのRTは300を越え、いつのまにかフォロワーが40人増えている。

…お前ら……。

最後に記念に作成した悪循環コラを掲載し、このエントリを終えようと思う。

応援してくれたみんな。本当にありがとう。


2013年12月31日火曜日

2013年を振り返る

今年も残すところあと僅かとなりました。毎年恒例の振り返りエントリです。

■プログラマ定年
今年の9月に35歳になりました。
以前勤めていたSIerでは、30歳を過ぎたあたりから少しずつ仕事でコードを書く機会が減ってきており、顧客調整とかスケジュール管理などの仕事が多くを占めるようになっていました。その後そういった状況が嫌で今の会社に転職し、幸いなことに35歳を数ヶ月過ぎた今でも毎日Scalaコードを書き続けています。

将来的にいつまでこの状態が続くかはわかりません。僕も今の会社で職位が上がり、開発リーダーなど任されるような日が来るかもしれませんし、そうなるとやはり自分が直接コードを書く機会は減るでしょう。ただ、そうなった後でも、今のマインドを捨てず、あくまでも「プログラマ」としてそういったリーダー業に従事できるようになりたいです。

"SE"とか"PL"とか"PM"とかではなく、限界ぎりぎりまで自分は"プログラマ"を名乗って仕事をしていきたい、ということを考える良いきっかけになりました。

■訃報
今年は身の回りに訃報が多い1年でした。
自分に大きな影響を与えた著名人だったり、同級生だったり、コミュニティの人だったり。まだ皆さんが亡くなられてから日も浅いですし、自分の中できちんと整理もできていないのでここでは多くを書きませんが、本当にいろいろな事を考えました。

■コミュニティ活動など
去年に比べると、勉強会などの参加数はかなり減ったと思います。
今までは手当たり次第にいろいろ顔を出していたのですが、勉強会でHP/MPを回復する、というような「勉強会お花畑」な状態では無くなったので、自分がどのようにコミュニティに対して貢献するか、どのように自分のキャリアを積むか、ということに少し悩んでいました。

自分がスタッフやスピーカーなど、「中の人」として関わった勉強会をまとめます。

1月

・ TDDBC 大阪 for C#(Visual Studioハッカソン事前勉強会)
現場でのペアプロについてお話させていただきました。風邪を引いて翌日のハッカソンを欠席するなど、少し迷惑をかけてしまった記憶があります。

2月

DevLOVE関西「勉強会勉強会」
勉強会について勉強する、というメタな勉強会です。
ビアバッシュでのQAコーナーのファシリテーターをしました。

3月

Scalaカンファレンス
今年の社外活動の中で最も印象に残っているカンファレンスです。
最初、公募セッションに応募したものの落選し、その後いろいろあって会社がスポンサーになってくれたので、スポンサー枠で発表させていただきました。
こちらのエントリにも書きましたが、ものすごい熱気で、この時代にあの場所にいれた事をとても幸福に思います。

ステーキ駆動勉強会(hoge駆動)
いつものhoge駆動でした。

4月

勉強会参加はなし。

5月

第4回 関西ソーシャルゲーム勉強会
会社で、ソーシャルゲーム関係者を招いての交流会をやったのがきっかけでスピーカーとして呼んでいただきました。これをきっかけにスタッフとして第5回のお手伝いをすることになります。

6月

お世話になった某社の編集者さんが留学されるということで、送別会に行ったりしました。あとはプログラマーズナイトでLTをやったり。

7月

IT英語勉強会 第1回
Scalaカンファレンスで英語のスライドを作ったことで少し自信がついて、参加してみました。生まれてはじめて、英語でLTをしました。ネイティブの人に、聴きやすい発音でしたよ、と言っていただけて嬉しかったです。また行きたい勉強会の1つなのですが、他の予定と被たりしてなかなか参加できずにいます。

・アジャイルラジオ 前編 後編
Webラジオに出演しました。めちゃくちゃ緊張して、何を喋ったのかあまり覚えていないです。だいたい雰囲気がわかったので、もう一回やりたいです。

日経コンピュータ 奇跡のJava
ある日仕事をしていたら、本社の広報から自分のデスクに電話がかかってきました。普段広報から内線が来ることなどないので、SNSでNGな話題でも書いてしまって怒られるのかと身構えていたら、この記事の取材申し込みについての連絡でした。Scalaカンファレンスでの登壇がきっかけだったようです。
雑誌の取材を受けるのは当然人生初体験だったので、いい経験をさせてもらいました。

夏のhoge駆動☆カレーの王子さまリターンズ
いつものhoge駆動でした。

8月

勉強会参加はなし。仕事がむちゃくちゃ忙しかった記憶があります。関西に遊びに来た@zer0_uさんとランチ食べたりしました。

9月

デブサミ関西
憧れのデブサミに登壇することができました。自分戦略セッションが公募制で、自薦も可、とあったのでダメ元で申し込んでみました。たぶんムリだろうと思っていたのですが、なんと人気投票1位ということでびっくりしました。

10月

高速ITコミュニティ秋祭り
初回から参加しており、今年で3回目の開催になります。
これまでは登壇者としての参加でしたが、今回はスタッフとしての参加です。といってもあまり大したお手伝いはできなかったのですが…。

こういう、「お酒と食事を楽しみながらのトークイベント」という形式は個人的に大好きで、関西でもこういう企画をやりたいなー、と常々思っています。来年あたり実現したいです。

怖くないScala勉強会
Twitterでの会話をきっかけに、日経コンピュータさんの奇跡のJavaの記事とも絡めて開催したイベントです。
Scala関連の勉強会の盛り上がり方は本当に驚くばかりです。こういうコミュニティの盛り上がりを絶やさず、現場の普及も着実に拡げていきたいものです。

個人的には、持ち時間に対して大幅に早く発表が終わってしまう、という大失態をやらかしてしまい、反省点の多い勉強会でした。

11月

第9回 RxTStudy
DVCSについて話してほしい、というご依頼をいただいたので、以前関Javaで話したgitの失敗事例の後日談をお話してきました。

開発現場に伝えたい10のこと
達人出版会さんから出版されている電子書籍です。DevLOVE関西にゆかりのメンバー10人で書きました。5月のGWに執筆し、11月に出版という長期プロジェクトでした。

第5回関西ソーシャルゲーム勉強会
主催という立場でやらせていただきました。会場提供やスピーカーへの呼びかけなどアマゾンデータサービスさんにものすごくお世話になりました。
こちらの勉強会も継続してお手伝いさせてもらおうと思っています。

12月

合同勉強会 in 大都会岡山 -2013 Winter-
毎年恒例の岡山での勉強会。LTでは途中でマシンがフリーズしてしまい、「自己紹介を2回やる」というネタにあふれたLTでした。

Far East Developer Review
DevLOVE Pubが冬コミで頒布する同人誌に寄稿させていただいてます。
これもずいぶん前に書いた文章なのですが、ようやく陽の目を見られました。

・忘年会駆動
いつものhoge駆動でした。

■まとめと来年の抱負

来年に向けて、デブサミの公募セッションに応募したのですが、落選しました。一度雅叙園で登壇してみたいので、機会があればまたチャレンジしたいです。

今年1年間、コミュニティ活動をしてきて、実に様々な人と関わりを持ちました。そのような中で、自分たちの開発が、決して他社に引けをとらない、という自信も持ちました。

僕が勤める会社は、まだまだネームバリューが高いとはいえません。全国的に名を売ろうと思えば、大ヒットのサービスをローンチするなど自分個人では難しい部分もあるでしょう。しかし、エンジニア界隈でバリューを上げる、ということなら、今までコミュニティに対してコミットメントしてきた自分もある程度貢献できるのではないかと思い始めました。

これまでは自分個人のバリューアップのみに焦点を絞っていろいろな活動をしてきましたが、2014年は自分と会社双方のバリューアップに貢献できるような動きをしていきたいなー、と思っています。

2013年12月18日水曜日

いろふさんとの思ひ出

いろふアドベントカレンダー 18日目です。昨日はみうみう「いろふさん絵描き歌」じゃないヤツ、歌ってみた #irof_history でした。

技術的なネタの構想もあったのですが、こちらは動画を撮ったりいろいろ仕込が必要で、今日は自分の番だということをすっかり忘れていてついさっきまで先斗町の鉄板焼き屋でぼっち日本酒を嗜んでおり、気づいたら準備する時間が無くなってしまいました。元々のネタはhoge駆動で発表しようと思います。

と、いうことでいろふさんとの思い出話でも。

いろふさんと初めて出会ったのは、2011年4月のScala本読書会でした。

こうして振り返ると今や同僚となった塾長がいたり、後にほげメン(hoge駆動メンバー)と呼ばれる人達のほとんどが集まっていたり、僕自身当時の会社を辞めてScalaで仕事してたり、今の僕のある意味で原点みたいなところだなぁ、と思います。

いろいろ思うところあって勉強会に行き始めたところでもあり、Scalaに興味を持ち始めた初期の頃でもあり、当時の同僚だったs_kozakeさん以外は全員初対面でした。
(この次に参加した勉強会がイケメンと初めてお会いしたTwitter4j読書会だったと思う)

そんな中にいろふさんもいました。

この時にいろふさんとの接点はほとんど無かったと思うのですが、この読書会のすぐ後に僕がこんなイベントを企画しました。

第1回 業務前モクモク会

同僚のs_kozakeさんと、会社の近くの喫茶店で始業前に勉強してから会社行こう、という会で、もともと2人でやればいいや、と思っていたのですが、他に来れる人がいたら皆で集まって各自で勉強しましょう、ということでATNDをたてました。

そこにいろふさんが来てくれました。いろふさん自身も当時思うところあって、いろいろな場に積極的に顔を出そうとされていたところだったようです。今の「いろふ複数インスタンス」の最初期だったのでしょう。

そういったところで、お互い「勉強会にとりあえず手当たり次第に顔を出す」みたいな最初の時期に接点があって、僕はなんとなくいろふさんを近い存在として感じていました。

で、なんやかんやあって今に至るわけです。

なんやかんやの部分はまた気が向いたらまたどこかで。

2013年12月8日日曜日

DevLOVE Advent Calendar 2013 【29日目】「現場における正しさとは」

DevLOVE Advent Calendar 2013 の29日目です。


去年のDevLOVEアドベントカレンダーでは「仕事とプライベートがウェットってブラックなの?」でその年のDevLOVEブログで最も読まれた記事、に選ばれましたので、今年も頑張って書こうと思います。

■きっかけはある人の質問

先日、第9回RxTStudyで、チームにおけるgitの失敗事例と、その改善までのお話をさせていただきました。(そのときのスライド)

僕たちのチームでは、結成当初からgitを使ってソースコードのバージョン管理を行っています。導入当初はメンバー全員がほぼgitを扱うのが初めて、という状態で、幾度と無くトラブルにも見舞われました。

運用を安定化させるために、チームではいろいろな試みがなされました。様々なGUIツールを試したり、ブランチ戦略を検討したり。

そのような中で、最も効果が高かったのは、『入門Git』などを読んで「正しい知識を身につける」ということでした。


僕はRxTStudyでの講演を、「ツールを使いこなすには、まずは正しい知識をきちんと学ぼう」という結論で締めくくりました。

講演後、ある方から質問をいただきました。

「正しい知識、というキーワードがお話の中で何度も出てきましたが、正しさの定義とはどのようにお考えですか?」

なるほど。これは辛辣な質問です。

僕は「正しさの定義」はそれぞれのチームや現場によって異なると考えています。この時にいただいた質問でも、そのような主旨の事を回答しましたが、それをもう少し具体的に書いてみよう、というのがこのエントリのテーマです。

■現場における正しさの定義は「チームメンバーが合意すること」

「gitの使い方」というような場合における「正しさ」の定義は簡単です。そのツールの仕様が、正しさの前提だからです。

では、チームでコードレビューなどをする場合における「正しさ」はどうでしょう。「正しいソースコード」などと言われても実に曖昧で、正解などないような気がします。

僕はこういう曖昧なものに正解を求める必要があった場合、「チームメンバー全員が合意する」という事を軸に考えます。

コードレビューにおける「正しさ」は、最終的にチームメンバー全員が「それで良い」と判断すれば、それが「正しいコードである」とみなします。

ペアプログラミングでのプログラマ同士の議論、あるいはチーム全体でのレビュー。こういった、度重なる議論を経て、僕たちが書いたソースコードは最終的にプロダクトとして世に放たれます。ならばチーム全員の合意を「正しさ」の定義に据えるのが、最もわかりやすい考え方ではないでしょうか。

■「チームメンバーの合意」が間違っていることもある・・・

しかしこの考え方には危うさがあります。

ここである架空の現場を想像してみましょう。

彼らは仕様書をExcelで書いており、それを以下のように管理していました。

・認証システム設計書_20131208.xls
・最新版_認証システム設計書.xls
・最新版_認証システム設計書_bkup.xls

チーム全員が合意の上で、彼らはこのような管理をしているわけですが、これは本当に「正しい」と言えるでしょうか?

現場における正しさの定義には、「チームメンバーの合意」に、もう一つ付け加える必要がありそうです。

■正しさとは、「チームメンバーが合意」しており「困っていないこと」

メンバーが合意した方法や考え方であっても、チームとしてその運用が困難であったり、なにか問題がある場合、それは正しいとは言えないでしょう。

さきほどの設計書の例で言えば、メンバーの合意があっても、結局本当の最新版はどれか、という問題が生じてしまうのであれば、それは正しいとはいえません。

チームにおける「正しさ」とは、チームメンバーが合意しており、その運用において解決すべき問題が無い状態が望ましいです。

こういう正しさの定義は、チームの成熟度によって当然変化します。

今まで問題とされていなかったような事柄が、チームの成長にしたがって問題として顕在化することもあります。その場合はチームが成長して「正しさの定義」に変化があったということですから、その問題と向き合って新しい「正しさ」を見つければよいだけのことです。

僕たちは個人ではなく、チームで仕事をしています。
で、あるならば、その中で生じるいろいろな事柄はチームとして定義されるべきです。

僕からは以上になります。

明日は@shinyorkeさんです。

2013年12月3日火曜日

いろふインスタンスの最大数を探る。

いろふアドベントカレンダー3日目です。

昨日は@kawakawa さんのirofさんとAR(拡張現実)で遊んでみよう♪ でした。

ちなみに去年はこんなの書いてました

さて。いろふさんと言えば、複数インスタンスですよね。昨日大阪の勉強会でご一緒したと思ったら、次の日は東京にいる、とかしょっちゅうで、いろふ複数インスタンス説が唱えられて久しいわけです。

と、いうことで、いろふインスタンスははたしていくつまで作ることができるのか、僕のMBP上のScalaのREPLで試してみましょう。ちなみにREPLはなんのチューニングもしていない、デフォルト状態です。

まずはいろふクラスを作りましょう。これが、すべてのインスタンスの元になります。

case class Irof(name:String, age:String, place: String)

型がすべてStringなのは、まぁ、ご愛嬌。

とりあえず、いくつかインスタンス作ってみましょう。

val irofs = List("osaka", "tokyo", "nagoya", "hokkaido").map(Irof("hirofumi nozaki", "unknown", _))

このくらいなら余裕です。
地名を指定するのも面倒なので、とりあえずこうして1000個くらい作ってみましょうか。

val irofs = (1 to 1000).map(p => Irof("hirofumi nozaki", "unknown", p.toString))

余裕です。

どうせなら、無限の世界に突入しちゃいましょう。いろふインスタンスに上限など設けてはいけません。
def xs(n: Int): Stream[Int] = n #:: xs(n + 1)
xs(1).map(p => Irof("hirofumi nozaki", "unknown", p.toString))
無限リストのmapですから、概念上、これでいろふインスタンスは無限に存在することになります。これでこそ僕らのいろふさんです。

2013年11月17日日曜日

ぼくも執筆に加わったDevLOVE本が出版されました

昨日、DevLOVE関西 -Decision- の開催に合わせて、「開発現場に伝えたい10のこと」という電子書籍が出版されました。

開発現場に伝えたい10のこと
DevLOVE関西
達人出版会
発行日: 2013-11-16
対応フォーマット: PDF, EPUB


ぼくも、「第二章 アジャイルな乙女ゲーム開発のおはなし」を執筆させていただきました。

今年のゴールデンウィークに数日かけて初稿を書いていましたから、ものすごい長期プロジェクトでした。

プロジェクト自体はBacklogで管理されていて、原稿はMardown形式で書き、gitで共有されていました。各担当者からのレビュー結果などがBacklogにチケット登録され、それを反映してgitにpushしてチケットをクローズする、というエンジニアにとって取っ付き易い形で作業を進められたので、楽しかったです。

前述のとおり、原稿を書いていたのは今年のゴールデンウィークの頃ですので、今とはチームの状況や仕事の進め方など変化している部分もありますが、チームのマインドはこれを書いていた頃と何も変わっていません。

皆さんの現場について考える小さなきっかけにでもなれば、嬉しいです。

このプロジェクトを立ちあげ、長期間牽引してくれた、@papandaさん、@yohhatuさん。達人出版会の高橋さん。執筆陣の皆さん。レビューに協力してくれた弊社技術ブログライターの皆さん。ステキな挿絵を提供してくれた@issps2009さん。本当にどうもありがとうございました。