けいまさんですけど

死ぬ気でやってりゃ、そりゃ死ぬわ

はじめに

YAPC::Asia Tokyo 2015に参加して、俺の夏は終わった

YAPC::Asia Tokyo 2015に参加した

ヤップシー エイジア トーキョーに初参加しました。
所属している会社がいろいろとしてくれたお陰で参加できることとなり、本当に感謝しかなかった。弊社に感謝の正拳突き1万回・・・!!!

実は昨年も行くチャンスはあったんだけど、さいたま新都心でやるデカいアニソンイベントに行きたかったので泣く泣く諦めた次第です。
今年は日程がかぶらなかったのと、キンスパ行ったのでアニサマ欲がそれほどでもなくなったので心置きなくYAPC充してきました。

大規模カンファレンス運営

僕は4月末にDroidKaigiのスタッフとして500人募集、381人参加のイベントを行いました(関連記事
そのときの後悔・・・というほどでもないけど、次やるときはなんとかしたいと思っていることとして、「行きたくても来られなかった人がたくさん居た」という事実があります。
しかし、手弁当で開催するにはDroidKaigiの会場規模が限界であることを痛感しており、次に開催するには、もっと大きな会場であることが求められます。
そういう意味でYAPC::Asia Tokyoの歩んできた道は、これから僕達が歩む道になるだろうと思っていたので、どうやればあんな大きなカンファレンスを運営できるんだろうかと気になっていました。

そういう観点からいろいろと思い出せる範囲でつらつらと書いていきたいと思います。
なおセッションについての感想はみんながハッシュタグ付きで書いてるからそれ読んで!!!!!

ノベルティ

スタッフ総動員で詰めていくようです。3時間位かかるっぽい、ヤバい。
中身はグッズ、冊子、クリアファイル、あめ、などなどバラエティに富んでおりました。

部屋

200人部屋が2つと、100人くらいの部屋が2つ。1000人はいる大ホールが1つ。
懇親会をやった部屋は別の場所に1つ、700人収容したらしい。
各部屋数人のスタッフが常駐しており、アナウンス・タイムキーパー、音響調整、ドアオープン・クローズ、空き席案内、列整理などなどを分担して担当していた気がします。

ロビー

割と重要。このへんで立ち話とかして親睦深められるからね!
流石はビッグサイトと言うべきか、広々としていた。
ただ前夜祭のときに騒ぎすぎた人たちがいて、ルーム内にも笑い声とかが入ってきてたのでドアクローズを徹底したほうが良かったのかも。
(このあたりは941さんが後のセッション等で反省していたので、まぁねw)
本番2日間では特に気にならなかったので快適でした。

別な場所に喫煙スペースもあった(俺はタバコ吸わないけど吸う人からすれば死活問題なんでな)。

エスカレーター

ボトルネックになってた気がする。とはいえ建物の構造上仕方ないところ。。。
それはそれとしてエスカレーター降りてすぐにゆっくり歩いたり立ち止まったりする人いるけど危ないので、流れるように脇によけるなりして欲しいな、と思うことはありました。
あそこに混雑時にスタッフを上り下り1名ずつ置いてアナウンスさせるか掲示するか、というあたりが考えられそう。。。

大ホール&通訳

完璧だった!ああいうのがやりたいんですよ僕は!!!!!
通訳さんも技術わかってる人だな!ってかんじでした。
割と同時通訳レシーバーの集計で大変そうな印象を受けた。どうも無くすと割とつらい額の弁済があるっぽくて。。。

僕はライブとか好きな人なので、せっかくなんでノベルティのサイリウムをつかった演出とか無理やりやってみたかったりしますね!
PPPH!あれ、なんのイベントだったっけ・・・w
(とはいえそういうのお気に召さない人もいるので、用法用量を守って。)

入場管理

Peatixをつかっていた。
PeatixのAndroidアプリはあんま評判良くないような話をYAPC関係ないところで聞いていたのだけど、まぁ入場管理としてちゃんと機能していたので良いのかな?と思いました。
このあたりは実際に入場管理していたスタッフさんから話を聞きたいところ(エラー率とか)。
ぶっちゃけ最も混雑した時間に自分は居なかったので、列の捌き方がスムーズだったかどうかは分からないです。

DroidKaigiでは最悪ケースも想定して考えて6レーン設置したのですが列形成することがなかった。過剰すぎたんですかねw

Makiさんに直接訊いたこと

懇親会の時に、弊社でボランティアスタッフに志願した人にお願いして、Makiさんと繋いでもらい、いくつか僕が悩んでいることの相談に乗ってもらいました。とても有意義だった。ありがとうMakiさん。
惜しむらくは、僕があんまスペック高い人間じゃないので、あんま踏み込んだ話ができなかったかも・・・というところ。精進します。

それはそれとして知りたい内容はだいたい以下のリンク先で読める内容と近いことだと思う。多くの人にはそれで充分だと思います。

まとめ

僕がやりたいイベントを最速で開催するには、YAPC::Asia Tokyoが敷いたレールに乗るのが早いと思っています。特に会場をどうするかは相当参考にしています。
けれど、Copy of YAPC::Asia Tokyoをやっても意味が無いとも思っていて、そこをどうするかというのがスタッフの個性だったり旗振り役の手腕が問われてくるのだと思いました。

僕達の夢の実現に向けて全力で頑張ろうと思えたYAPC::Asia Tokyo 2015でした。がんばろう

Which do you like?

はじめに

あなたがサイコーにクールなAndroidWear用WatchFaceを作ったとしても、
ロケール設定で表示内容が変化するFormatを使っている場合、思わぬ表示上の問題を生み出すこととなる。
そう、↑の画像のように。

romannurik/FORMWatchFace

Google I/Oのサイトのような、モーフィングする数字をもったWatchFaceのソースコードが公開されている。

スクリーンショットを一目見て最高だと思った(自分が視認性を重視する性格のため、もう少しスリープ時の色にメリハリをつけて欲しかったかもしれない)が、実際に使ってみると致命的にダサい点が見つかった。

それが、↑のスクショの左側で示した点。

曜日が日本語で表示されている。また、よく見ると右横の日付とフォントが違う。
これは意図してそうなっているのか、気付かずそうなっているのか判断がつかなかったが、
とはいえ僕はこれをクールだと思わなかったので、ソースを修正した。

今は自分でビルドしたWatchFaceをインストールして使っている。とても良い。オープンソースばんざい。

「SimpleDateFormatは使うべきではない」という共通認識

アプリの多言語対応などを考えると、SimpleDateFormatを使うよりもDateFormatのほうがずっと楽に開発できるはずだ。
(とはいえ最近はJoda-Timeを使うことが多いけれど)

実際に僕も普通のアプリ開発をするときはDateFormatを使うようにしている。

ただ、WatchFaceのような、「世界中の全員に同じ体験を与える」という意図がある場合は、DateFormatよりもSimpleDateFormatを使うほうがベターだと思う。
(そのあたりは、上記のやんざむさんの記事でも触れられています)

というわけで無事に修正することが出来た。スクショの右側が修正後。クール。

おそらく「予期せぬ表記」だったのではないか?

ところで、FORMWatchFaceで日本語が出るのは意図したものだったのだろうか?

例えば、見た目よりもわかりやすさを重視する場合、ここで日本の曜日名が出るのは正しいと思う。
(AndroidWearの標準WatchFaceにある「Digital」はそういう意図が感じられる)

けれどこのWatchFaceで採用されているフォントは英語と数字のみ提供されている。
結果としてモトヤマルベリが表示されているので、おそらくは意図していないものだったのではないか?と僕は思っている。

まとめ

この記事を書くにあたり自家製アップローダーに画像をぶん投げようとしたら、APIが消滅していて動かなくなっていたのを直したりした。。。

DroidKaigiが無事に閉幕しました。DroidKaigiに関わりましたすべての皆様に感謝申し上げます。
さて、ここではDroidKaigiを数字で振り返りたいと思います。

なお、ここで触れている数値はDroidKaigiでの実際の数値(または概算)を掲載しておりますが、
感想・考え・思いなどについては、この記事を書いている @pside の個人的なものとなりますことをご理解ください。

118

DroidKaigiの最初のミーティングは2014年の12月28日に行われました。
そこから2015年4月25日までの118日でDroidKaigiをつくっていきました。

23

DroidKaigi実行委員会は総勢23名のメンバーで構成されています(GitHubのDroidKaigiグループによる)。
それぞれが何らかの役割を担い、圧倒的な当事者意識のもと、イベントの成功のために奮闘しました。

63

総数63件の登壇応募(Call for papers)がありました。
これは当初の想定数を大きく上回っており、DroidKaigiの期待の大きさを物語っているのだと分かりました。

21

DroidKaigi実行委員会では、21件の登壇応募を採択しました。
差し引き42件の応募を落とした、というよりも、21件を選ぶために泣く泣く採択を諦めたという表現を個人的にはしておきたいところです。

400

会場となったサイバーエージェント セミナールームのキャパシティから、一般来場者の募集数を400人と設定しました。
これはサイバーエージェントの会場担当者との打ち合わせの結果、
当日来ない人もある程度いるだろうということを考慮したうえでの設定でした。

ちなみに、CAさんとの打ち合わせでは、出席率66%くらいではないか、という感じでした。

8

200人の先着枠が8分で受付終了となりました。
スタッフの誰もが想定していない事態であり大変驚愕しましたが、大きな期待の現れだということで、各位がより一層の奮闘を誓いました。

2.5

200人の抽選枠には、約500人の方がエントリーをされました。倍率およそ2.5倍。

結果として、ほぼ定員と同じ数の方がDroidKaigiに足を運べないという状態になりました。
このことはDroidKaigiを継続開催する上で第一に解決すべき問題だと個人的には思っております。
(が、そうなると手弁当ではいかなくなりそうだ、とも思います)

4

Twitterの日本のトレンドにおいて、約4時間に渡り「#DroidKaigi」が登場するという出来事がありました。
テック系カンファレンスとしては珍しい出来事ではないかと個人的に感じております。
また、幕張ではニコニコ超会議が行われ、さいたま新都心では坂本真綾さんのライブが行われていた状況で、
この結果はとても奮闘したものだと思われます。

また、ルーム単位でのハッシュタグ「#DroidKaigiA」「#DroidKaigiB」もしばしばトレンド入りしておりました。

6

この記事を書いている人は当日の朝6時に起きて名簿を出力しました。
なんで早起きしたかというと、「この時間までにキャンセルしなかった人は絶対に来るんだよね?????」というまぁそういう感じです。

489

当日は全員が来場すれば489名の方をお迎えすることになっておりました。
なお、前述のとおりですが、ここから当日来ない方がいることを前提で設定しております

なお、具体的には・・・

  • 400名がconnpassで登録された方
  • 71名がスタッフの関係者(会場提供のCAさんの招待枠も含まれます)
  • 18名が登壇者(4名はスタッフ兼登壇者のため、ここには含みません)

という内訳です。

381

実際にDroidKaigiの受付を通過された方は381名でした。

これについて強調すべきことは、「489 - 381 = 108 つまり108人がドタキャンをした」ということではありません!

受付は1名の漏れ無く処理することが求められますが、それはなかなか難しいものです。
また、後半は2部屋でのセッションを行っておりましたが、受付を設置していたのは1部屋のみでした。
午後から来られた人が受付のない部屋に直行したということも大いに考えられます。

しかし108人のうちいくらかの人は当選しているのに当日来なかったわけですから、
「あの日あの会場に行きたかったけど行けなかった400人の無念」を抱えながら、
今後同じようなことを繰り返さないようにいただくことを切に願いたいと思います。。。
(とはいえそれを見越して定員設定している主催側もいるので悩みどころではあります)

それはそれとして、この数値は今後の(特に東京での)カンファレンスを主催するうえでの重要な知見ではないかと思われます。
(そういう意味では、CAさんの会場担当の方は流石だったと言えます。)

79.50 と 69.00

connpassでは「先着枠」と「抽選枠」を設けました。

先着枠で参加の方で受付を通られた人の割合は79.50%でした。抽選枠で参加された方で受付を通られた人の割合は69.00%でした。

こちらを補足すると、先着枠の人は登録の早い順に並べた上位50人の通過率は約88%でしたが、最後50人については約63%となりました。
これは、最後50人は「直前に繰り上がった人」が多いため、キャンセル処理を忘れるなどがあり、通過率があまり高くないのだと思います。

まとめ

いかがでしたでしょうか?

なお、主にカンファレンス主催の人が気になるであろうお金の話は、僕がそのあたりを触ってないので意図的に外してあります。
誰かが語ってくれるかもしれないし、オフレコとして伝承されるのかもしれません。

はじめに

仕事で作っているアプリで非同期処理のコールバックが地獄めいてきて吐きそうになったので
そのあたりをバッチリ解決するためのアレコレを模索していた。

そんな折にKeithYokomaさんがQiitaに海外記事の翻訳を公開したのを読んで、一念発起したという具合です。

EventBusを使う方法も考えたのだけど、あれはLocalBroadcast使うまでもないときに発動させるのがいいんだろうな、という感想です。

そんなわけで、色々と見たこと・考えたことを備忘録としてまとめました。

参考にしたサイトたち

だいたいこれ読んどけばOKみたいなそんな感じです。

入門

応用例とか

お役立ち

ハマリポイントつぶし

その他

理解したことの整理

Reactive ExtensionsはPromiseパターンに似てる

もともとJavaScriptのPromiseパターンは理解していた(AngularJSでは頻出)ので、それと対比して関連付けて着目することが多かった。
Rx == Promise ではない気がする。じゃないとRxJSみたいなものがなんで存在しているのかわからないです。。

RxはPromise++でありcallback++である、と記されたサイトがあった。そういう感じだと思った。

JavaScriptでは(俺の観測範囲では)すべてが非同期で、UIスレッドがどうの〜ということがないし、
適切なコールバックを使うことがある種の慣習となっているので、Promiseの概念は取っ付き易いんだと思う。

一方でスマホアプリはUIスレッドで同期命令を実行すればその間の描画がフリーズする。
なのでそういう命令を使うならば別スレッドで処理を実行し、結果をUIスレッド側にコールバックする必要がある。
そのため、どのスレッドにいるのかを意識してコーディングしないといけないし、スレッドのきめ細やかな調整がとても大事なのだと思う。

RxAndroidはAsyncTaskLoaderを置き換えることができる

詳細はKeithYokomaさんが訳した記事を読んでいただくとして。とにかくAsyncTaskLoaderはつらい。
「開始」「終了」「リセット」くらいしかコールバックを得られないうえ、画面回転の対応も微妙。
柔軟に扱えるようにするにはかなりいろんなことをしないといけなくて、ないよりマシだけどつらい。

しかしRxAndroidなら、(ちゃんとObservableを定義すれば)レスポンス値を見てエラーにできるし、
飛んできたデータに対する加工も簡単。Observableの開始時や終了時に何か実行させたいとか、
いろんなところでコールバックを受けることができるので柔軟性が高い。

AppObservable.bindActivity/bindFragment はハマることがあるので気をつける

詳しくはsys1yagiさんの記事を。

すべてのAsyncTaskLoaderを追放できるか?

日和った答えとしては、まぁちょっとずつやっていくかー。という感想。
RxJavaおぢさんとしてすべての非同期タスクをRxで書いて問題あるのかないのか、まだ答えを出しかねている状態。
あとRxAndroidがまだまだ破壊的変更あったりするというのも気になる(がgradleでバージョン固定できるからそこはまぁ気合でなんとかなる)。

まとめ

という具合です。

はじめに

冷え込んだり少し暖かかったりする今日このごろですが、いかがお過ごしでしょうか。
さて、今回はAndroidデベロッパー向けのイベントのお知らせです。

DroidKaigi

"DroidKaigiは、エンジニアが主役のAndroidカンファレンスです。"ということで、4月25日(土)に渋谷・サイバーエージェントのセミナールームにてDroidKaigiというカンファレンスが開催されます。詳細は以下リンクを御覧ください。

僕はこのイベントのお手伝いをする予定です。

このイベントではCFPを募集し、採択されたら登壇することが出来るというスタイルを採用しておりますので、登壇されたい皆さんは公式サイト内「Call For Papers」の項をよく読まれた上で応募いただけると嬉しいです。

ABC(Android Bazaar and Conference)との関係

DroidKaigiの情報解禁後、ABCとの兼ね合いを気にされている方がいて、色々と拝見させていただきました。
各々がDroidKaigiというものを見て色々思うことがあるなら、それ自体でDroidKaigiをやる意義はあるなぁ〜と関係者の端くれとしては思う次第です。
また、関係者にも色々「思い」があるはずで、「Android技術情報の共有とコミュニケーションを目的」という点を除き、皆それぞれ違う考えでDroidKaigi成功にむけて取り組んでいる気がします。

率直に申せば、DroidKaigiの発端はABCとなんの関係もないところからスタートしています。「こういうのがあればいいのに」と考える人がたまたま複数おり、集結した結果のアウトプットがDroidKaigiです。

経緯は以下記事が詳しい。

「ABCでかつて行われたようなEffective Androidのセッションのように、ABCでやることは考えなかったのか」という疑問もあるかと思います。
これは、DroidKaigiに仮に「次」があると仮定して、全工程を自分たちでやることで経験値を得ないといけないので、ABCの1部屋ぶち抜きというスタイルでやるよりも「すべて」を自分たちでやることに意味がある、と僕は考えています。
(個人的にも、ひとつのイベントがどのようにして立ち上がっていくかを知りたかったので、この経験はとても貴重だと思っています。)

まとめ

DroidKaigiはAndroidデベロッパーに着目したカンファレンスです。
5月末にはGoogle I/Oも開催されるので、「とりあえず今Androidどうなってんの」を知るにはとても良い機会だと思います。ぜひご参加をご検討頂ければと思います。