プログラマーズナイトでLTとDJをしてきました。

4/29の鹿駆動勉強会への参戦を表明して、「そろそろ宿とか予約とるか」と思っていた頃にプログラマーズナイトの告知を@daiksyさんのtwitterで見かけました。
プログラマーズナイト : ATND

開催は鹿駆動の前日。しかも徹夜になる。ということで「きついかなぁ」と思っていたのですが、参加してしまいました。

参加の理由

実はDJをしてみたかったのです。そのうち@ITのコラムで書こうと思ってるネタにDJとプログラマの話があります。そのネタ自体は結構長い時間温めてて、そろそろ出そうかと思っているところでした。そんななか、プログラマーズナイトの告知に「LT,DJやりたい人募集」と書いてありました。「ここでDJやれば、自分の実体験を足してコラムが書ける。説得力も増すだろうな」ということで、DJをするために参戦したわけです。

LTしてみました。

ここでやったネタは、アジャイルサムライ横浜道場でもやった日露戦争インセプションデッキでした。で、やってみたのですが「なんかうまくウケない」という感触でした。
その後の場の雰囲気を感じてわかったのがコンテキストの違いでした。関東と関西という地域、人の問題。場のテーマの問題がありました。
どうも関東と関西ではウケるポイントが違うようで。関東でウケたネタを関西に持ち込んでもそう簡単にはウケないようです。（だから吉本の芸人さんはすごいよなと思うわけです。関東でも関西でもウケがとれるので）
また、アジャイルサムライ横浜道場では当然アジャイラーな人が集まっているのでネタも通じます。プログラマーズナイトはやっぱりプログラマで、相当レベルの高い人達ばかり。他のLTもそんな感じだったので「コンテキスト間違ったか・・・」とあとで後悔しました。
その後、鹿駆動勉強会の懇親会で@daiksyさんの会社の後輩であり、プログラマーズナイトにも参加されてた@kuchitamaさんと話す機会がありました。そこで良かったですよ（か悪くなかったですよか。ポジティブな感じではありました）という意見をいただけてちょっと救われました。

DJ初体験

京都に来る深夜バスのなかで選曲をしていました。が、会場のDJの流れを感じて「これは違う」と思い慌てて選曲をしなおしてました。@tanigonさんの計らいもあってか、ちょうど選曲が終わった頃に出番の声をかけてもらえました。
かけた曲は大体このあたり。

FreeTEMPO BEST ALBUM “TENSE”(初回限定盤)

Super Departure

New Sessions!

FACE TO FACE

やり始めた当初は曲をつなぐ・次のタイミングを図るので手一杯でした。ですがやれば慣れてくるもので。終わりの方では場の状況を見れるくらいの余裕は生まれました。
MiMさんの曲はノッてくれてる人もいて良かったですね。ダンスミュージックで歌モノっていうのがいいのかも。
終わったあと@tanigonさんと選曲について話していて、他にも使える曲があったなぁと気づきました。次の機会があれば、もうちょっと練習して挑みたいですね。

とはいえぼっち

やっぱりアウェイでしたね。知ってる人は@daiksyさんくらいなものだったので。知ってる人が皆無といえば、以前Titanium Mobile 2.0 ローンチイベントの飲み会に参加した際はきちんとお話したことがある人が皆無でした。ですが、アプリを作っていたこともあって「それ知ってる！」になったのでぼっちにはならずにすみました。
やっぱり知ってもらえているってことは重要ですね。また機会あれば関西で何かしたいです。
ご挨拶させていただいた皆様、ありがとうございます。Twitterでもフォローをさせていただきました。これからよろしくお願いします。

おみやげも頂きました。

スポンサーのフリュー株式会社さんからは「なめこ」のぬいぐるみを、TENGAさんからはTENGAを頂きました。ありがとうございました。

アジャイルサムライ横浜道場でLTをしてました。

タイトルの通りなのですが、4/26に行われた「アジャイルサムライ読書会 横浜道場 特別編」でLTをしてきました。
そこでやったスライドはこちら。

もしも日露戦争のときに満州軍総参謀長児玉源太郎閣下がインセプションデッキを作っていたら

View more presentations from Daiki Tanoguchi

4/12のアジャイルサムライ読書会 横浜道場「みんなをバスに乗せる」の回の懇親会で「航海もプロジェクトだよね」という言葉を聞きました。そこから「航海→海→海軍→戦争=プロジェクト→日露戦争！」と連想しました。それで作ったのがこちらのLTでした。
当初は「高橋是清が外債募集の際に」ということで作っていたのですが、「やっぱり児玉源太郎閣下のほうが話しの流れ的に合うな」ということで方針変更しました。

はじめてのインセプションデッキ

を今回作りました。アジャイルサムライは出た当初に購入していたのですが、インセプションデッキを書く機会はありませんでした。そんな状況ではあったのですが、「GitHubにテンプレがあるよ」と@enumさんに教えていただいたので、そちらのテンプレを使って作りました。
support/blank-inception-deck at master · agile-samurai-ja/support · GitHub

テンプレがあるって、やっぱり便利ですね。初めて書く場合でも、テンプレに従ってやれば相応のものが作れるので。あと、過去の歴史を元にして書いてみたことで、既に状況やコンテキストを理解している状態で書けたのであまり苦労はしなかったです。時代考証の苦労などはちょっとありますが。
歴史や物語をベースにインセプションデッキを書くのも、練習になっていいかもと思いました。こう書けばいいのかなと思いながらできるので。その後の懇親会で「歴史ものでインセプションデッキ書くのはいいよね」と言ってもらえましたし。

はじめてのネタLT

でもありました。普段は真面目なことしか出来ない自分ですが、このLTを思いついた時「これはとことんネタでいこう。笑いを取りに行こう」と決意してました。
実際の発表では、冒頭のあたりで声のトーンを落として話しました。これは「坂の上の雲」のナレーションを意識してやってました。自分の言葉の部分は自分のトーンで。この落差でウケがとれてました。
失敗だったのは、周りの笑いにつられて発表者である自分も笑ってしまったところ。このあたりはもっと「演じる」ということが出来ないとダメなのかもしれないです。（お笑い芸人さんたちってすごいですよね）

まとめ

ということで、歴史ものインセプションデッキいいですよ♪みんなもやってみるといいよ♪

参考資料

@nifty：デイリーポータルZ：ペリーがパワポで提案書を持ってきたら
開国について一言言っておこうか
この二つが元ネタです。

ATND出欠確認アプリ「ATNDチェックイン」がこくちーずに対応しました。

先週火曜日にアップデートをした「ATNDチェックイン」Ver1.1でこくちーずの出欠確認を出来るようにしました。
出席確認画面の「イベント選択」からこくちーずを選択し、イベントID(http://kokucheese.com/event/index/{ここの数字})を入力するとこくちーずの申込者リストを取得出来ます。
申込者リストを公開していない場合、リストの取得は出来ません。（こくちーずの仕様のため）

今後の計画

UIの改善と他のイベント告知サービスへの対応を考えています。
とりあえずはZusaarに対応させたいな。

横浜へなちょこiOS勉強会で発表してました。

3/24の横浜へなちょこiOS勉強会で発表してました。
随分と時間が空いてしまいましたが、スライドと発表者ノートを載せておきます。

悔しさと憧れとあきらめなさと

View more presentations from Daiki Tanoguchi

スライド作りの話

今回はマインドマップを使わずに付箋でストーリーを考えていきました。

この写真は構成をまとめた後ですが、マインドマップ的ですね。
付箋でストーリーをまとめて気づいたのはあとから構成変えたりするのが容易なこと。マインドマップは全体構想がある程度固まってるときには有効だけど、決まりきってない場合は付箋のほうがいいですね。

そこから絵コンテ→スライドと落としていきました。

今回のスライドでは@take3000さんの達人ライトニングトーカーへの道（2）：初心者のためのLT作成講座――5分で収まるスライドを作る3つのTips (1/2) - ＠ITを一部参考にしています。
状態変化する図を文字のみ適用&小規模に使ってみた感じですね。（特にスライド32枚目〜37枚目）

今回初めてこういう変化をつけてみました。同じ写真を背景に文字を追加するだけでも自分の気持ちの流れを表現することができたりして有効だなぁと主ました。

デモの話

今回はiOSアプリの開発話ということでシミュレータを使っての説明も行なってみました。
ここでもいくつか反省点がありました。
僕はプレゼンを行う場合、ディスプレイとプロジェクタの表示を別にしています。そこでシミュレータを起動したりする場合、プロジェクタ側に表示しなければ状態が分からないのに気づいておらずディスプレイ側に表示していました。
IDEなどはプロジェクタ側に表示するようにしましょう。

シミュレータ起動まではいま何をしているのかを話すようにしていました。このテクニックは

エバンジェリスト養成講座 究極のプレゼンハック100

から頂いています。

あとで参加者からフィードバックをもらって「いいね！」と言われたものがありました。
デモを行なっているなかで工夫したところの説明をしました。その際に根拠として

iPhoneアプリ設計の極意 ―思わずタップしたくなるアプリのデザイン

の該当箇所を読み上げたのですがここに高評価を得ました。
実際に本を持ってきたこともあって、発表後本を見てもらったりもしました。

発表後のフォロー

も結構やりました。何人かの方と合計2時間くらい話しました。
興味持ってるけどやったことない。そんな場合に講師の方から直接話しを聞ける時間はやはり貴重なんだなと思いました。
また、横浜へなちょこiOS勉強会自体がもくもく中心の会。話を聞く時間が十分にあったことも影響したのでしょうね。
発表して終わりではなく、その後のフォローの時間をしっかり持つべきだと感じました。

Exception in event callbackでハマる。

ATNDチェックインのアップデート用コードを書いていてハマったのでメモ。

TitaniumのSDKは1.8.2 XCodeは4.2 iOSのバージョンは5.0です。

こくちーず対応のコードを書いていました。イベントのテーブルと参加者のテーブルを分けています。
こくちーずの申込者リストRSSをパースしてデータを登録するところでタイトルの通りException in event callbackが発生しました。

このときイベントテーブルへのデータ追加と参加者テーブルへのデータ追加の際のDB接続が別になっていました。
一度closeしてもう一度openする感じです。
その際にException in event callbackが発生しました。

もしやと思って両方のデータ追加メソッドを呼び出す前後でopen, closeするようにしたら解決しました。
そもそもこういうコードがよろしくない。Transactionの中に含めるべきなんでしょうけどやってない。
そんな適当コードだから起きたんだよな。。。と。

これから設計を学ぶ君に贈る一冊 #君に贈る102冊目の名著

こちらの翔泳社さんの本

100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊

を読んでて、自分もちょっと書評を書きたいなぁと思ったので書いてみます。

今回の書評はこちら。

ユースケース入門―ユーザマニュアルからプログラムを作る (Object Technology Series)

いまの時代、設計を学ぼうと思った場合にまず手をつけるのがUMLではないかと思う。僕も前の会社で設計を考えなければならなくなったとき、最初に読んだのがUMLの入門書だった。UML入門とか、そういったやつだ。
しかし、そういったUMLの入門書を何冊か読み、実際にモデルを書いてみても全然理解できなかった。思えば、そもそもオブジェクト指向とは何ぞやということすら理解できていなかったのかもしれない。
Javaや.netの入門書でもクラスとかの話は書いてあるが、動物クラスがあって、犬とか猫とか。そういった説明を読んでもピンとこなかったのは僕に限らず多くの人が体験したことだろうと思う。
そんな僕が「オブジェクト指向とはどういうものか」「どうやってシステムを設計するか」のきっかけを得たのがこの「ユースケース入門」だった。
この本は著者が考案したICONIXと呼ばれる方法論を用いた設計手法が説明されている。この方法論は要件定義のレベルから実装までの設計をUMLの表現を用いて行うものだ。そのやり方は簡潔であり、要件からクラス図までシステマティックに落とし込んでいける。
僕はこの本を読み、実際にユースケースシナリオやロバストネス図・シーケンス図・クラス図を書いていくなかで、いつしか頭の中でシステム像というべきものを描くことができるようになっていた。

ソフトウェアの設計を行うには設計の方法論を知らなければできないと僕は思う。UMLは所詮モデルの表記方法でしかなく、設計方法とは切り離されている。そしてその方法論は細かい差異はあるものの、基本的な原理は昔から変わっていないのであろう。
2010年の9月、平鍋さんがUStreamで「ソフトウェア工学の名著探訪」という企画でいくつかの本を紹介されていた。その中でオブジェクト指向方法論OMTを紹介されていた回がある。Ustream.tv: ユーザー hiranabe: オブジェクト指向方法論OMT（ランボー）, James Rumbaugh の『オブジェクト指向方法論OMT』('91)を紹介。羽生田さん監修で日本に1992年に紹介されました。オブジェクトモデル（オブジェクトモデル図）、動的モデル（状態遷移図）、機能モデル...
それを見た時、「これってユースケース入門と一緒だ！」と驚嘆したことを今でも覚えている。

では実際に今業務でロバストネス図やシーケンス図を書いているかというと書いていない。ドキュメントを求められていないのと早く動くものを作ることを優先しているからがその理由だ。しかしこの本に書かれていたやり方はいまでも設計や実装を考える際のベースになっている。
プログラムが書けるようになった。でも全体像をうまく考えられない。そんな人にこそ、この本を読んで欲しい。そしてシステム像を考える面白みを感じて欲しいと思う。

「ATNDチェックイン」開発裏話

さて、今朝Appleの審査が通って公開された拙作「ATNDチェックイン」。こちらの開発裏話などを書いておきたいと思います。

作ろうと思ったとき

昨年のXP祭り2011が終わって、Lingrでふりかえりをやっていた際に@kawagutiさんが「来年は技術の進歩で、iPadで効率的に受付できるシステムが作られるはずです。(DevLOVEの人が作る)」と書き込んでいたのを見て「俺が作ろう！」とずっと心に秘めていました。
その後、昨年10月ごろからiPhoneアプリ開発をObjective-Cで行っていました。参考書も2冊ほど購入し写経をして「そろそろ書けるかな？」と思って、自分でコードを書き始めたのですが、DBへデータを流すところでどう書けばいいのかわからなくなり挫折。たった数時間でorzとなりました。

それからTItanium Mobileの勉強に手をつけはじめました。昨年12月下旬。「DevLOVE Pub ライトニングトーカーの告白」脱稿後のことであります。

アプリを作り始める

開発に着手したのは今年の1月に入ってからでした。その段階で既にいくつかのアプリの構想がありました。そのなかで今回の「ATNDチェックイン」を開発の対象に選んだ理由は「一番簡単に作れるだろうから」「その後の構想を実現するための練習として」というものです。
今回はGitHubにてソースを公開しています。 dproject21/ATNDCheckin · GitHub
こちらのソースを見ていただくと分かるのですが大したことは全然していません。Gihyo.jpでTitanium Mobileの記事が掲載されていますが( Titanium Mobileで作る！ iPhone／Androidアプリ：連載｜gihyo.jp … 技術評論社 )、こちらの第1回〜第9回のコードの大半をATND API用に置き換えたようなものです。機能の実装は2日程度で終わってしまいました。

アプリを手直ししていく

ちょうど機能の実装を終えたあたりから本業が忙しくなり、開発に取れる時間がなかなか取れずにいました。手直しを始めたのは2月に入ってから。

iPhoneアプリ設計の極意 ―思わずタップしたくなるアプリのデザイン

こちらの本を読みながら、UIを整えていきました。（といってもフォントや行の幅くらいしか直していませんが。）
最後の仕上げは横浜へなちょこiOS勉強会さんのもくもく会時間を使って行いました。ここでスプラッシュまでが完成。家に帰ってからアイコンを作り完成となりました。出来上がったのは2/18。着手から一ヶ月ちょっと、所用時間20時間程度でした。
その翌日Appleに申請を行い、本日審査通過。公開となりました。

作ってみてわかったこと

「Titanium楽すぎる！」の一言につきます。Objective-Cの難解さに比べると圧倒的に楽です。ちょっとしたツールならば1日あれば作れてしまいます。
また、一つアプリを作ったことで派生アイデアがいくつか浮かんできました。初めてLTを経験したときと一緒で、体験すると敷居が下がるんだなぁと感じました。

今後の野望

いくつかアイデアのストックがあるので、それらを形にしていきたいなと思います。願わくばそれなりの収益も得たいなぁと。「ATNDチェックイン」に関しては他のイベント開催支援サービス（こくちーず、Zussarなど）にも対応させていきたいなぁ。
Titanium関係の勉強会にも足を運んでみたいと思っています。いろいろ楽しみは広がっていきますね♪

Rubyもまた勉強してみたいと思っています。iPhoneアプリと連動する形でFacebookアプリを作りたいという野望がふつふつとわき上がっております。Ruby界隈の皆さんにはまたお世話になるとおもいます。どうぞよろしくお願い致します。