Infinito Nirone 7

白羽の矢を刺すスタイル

子の権現に登ってきた

本当は子の権現に行くつもりはなく、国道299号を秩父まで行って、そこから奥武蔵グリーンラインを走ってみようかなと思っていたのですが、途中で財布を忘れたことに気が付き、じゃあ子の権現に行ってそのまま帰ろうということで子の権現に行くことになったのでした。

ちなみに、ゴールデンウィークの国道299号は秩父へ向かう行楽客のマイカーが入間まで続くほどの渋滞っぷりで、あのまま秩父に行っていたら返ってくる頃には日が暮れている気もしました。そして、最初に目にした子の権現こちらの看板通りに行ったら、いきなり斜度18%の鬼のような坂を登った挙句登山道に行き当たって先にいけなくなるというボケもかましてしまいました。近所のおばあちゃん、親切に道を教えてくださって本当にありがとうございました。

さて世間で有名なあの激坂とは逆側から登るということで、くだりを気をつければ大丈夫なんじゃないかな?と気軽に構えていました。実際、残り5km地点から3km地点まではほぼ平坦な道でスイスイ進んでいけたので、これはこのままシュッと登って激坂を眺めながら帰れるな?と思っていました。

ところがどっこい、参道残り3km地点からは常時斜度10%以上の坂が続きます。途中ベンチのあるところで休んでいたおばあさんに「気をつけてね」と声をかけていただきましたが、息が上がりまくって出がらしのような声で「ありがとう…ございます…」と返事をしました。行けども行けども延々キツイ坂が続き、あまりにしんどくて残り1kmをきってしばらくしたところでギブアップしてしまいました。結局600mほど自転車を押して登りましたが、ゴールまで斜度が緩むことはなく、裏の道でも十分にキツイということがわかりました。

途中足はつけてしまったものの無事子ノ権現に登りきるも、財布がないのでなにもできず、かの激坂も自転車をおしながら慎重に降りることに。激坂区間の下でクリートカバーを外していると、これからあの激坂を攻めようとする人たちがちらほらと登ってきました。自分も子ノ権現は初めてでしたが、その方たちも初めてだったようで、軽く挨拶をし、あと300mの看板からがキツイですよ!とお伝えしたところ、壁のような坂を前に「なんじゃこれは!」と叫んでいました。

そりゃあ、こんな坂じゃあね…

f:id:KeithYokoma:20170503123128j:plain

上から見たらただの崖だし、下から見たらただの壁です。本当にありがとうございました。

間違えた道の18%の坂を下るときもそうでしたが、普通に降りようとすると後輪が浮いたら死んでしまう!というのと、ブレーキを書け続けられる自信が全くなかったので、自転車を降りて恐る恐る歩きました。 総行程100kmといつもよりは若干短いサイクリングでしたが、無事に帰ってこれてよかったです。

potatotips #39 に行ってきた

技術書典2 では TechBooster から Colorful Android のコンテンツの一つとして DroidKaigi で発表した WindowManager の内容 + Android O の話を書き書きしましたが、その Android O の部分の抜粋 LT をしてきました。

speakerdeck.com

Android O Preview 触った人手をあげてー!」ってやってたくさん手があがるのを見て「おー!」っていう雑なことをしようとしたら一人しか手があがらなくて「おっおっ」てなったのはここだけの話です。

内容は以前ブログAndroid O で WindowManager の振る舞いが変わる - Celeste Engineerに書いたことの通りで、整理されたけどシステムの介入があるから気をつけようね!という感じです。

shibuya.apk #13 行ってきた

shibuya.apk #13 で"Automation with Wercker and Container Builder"というタイトルで発表をしてきました。

speakerdeck.com

Wercker をつかった Android アプリの CI は以前から取り組んでいたものですが、実運用をしている上で困ったところを Google Container Builder でいい感じに解決し、アプリだけでなくビルド環境も CI/CD できるようにしたよ!というお話しです。

Wercker は主要な Docker イメージのレジストリをサポートしていて、ほぼ選択に困ることはないのではと思っていますが、Dockerfile で Docker イメージをビルドすることには使えません。あくまで、イメージを pull してコンテナを立て、その中でアプリを動かしテストする用途のサービスになります。

Docker イメージをビルドしてくれるサービスは Google Container Builder 以外に Dockerhub もあります。ただし設定の柔軟性は圧倒的に Container Builder のほうが高く、なにかと Dockerhub のビルドサービスには足りたいものがあったので、今回は Container Builder を使用しました。

環境そのもののリビジョン管理がこれでかなり楽になったのは超うれしいです。

Android O で WindowManager の振る舞いが変わる

先日の DroidKaigi 2017 で発表した「Building my own debugging tool on overlay」のなかで、WindowManager で取り扱うレイヤについて触れた部分がありますが、Android の次バージョンである O から使用できなくなるレイヤ、代替レイヤについてのアップデートがありますので、こちらにも書き残しておこうと思います。

developer.android.com

developer.android.com

使用できなくなるレイヤ

以下のレイヤは使用できなくなります。

  • TYPE_PHONE
  • TYPE_PRIORITY_PHONE
  • TYPE_SYSTEM_ALERT
  • TYPE_SYSTEM_OVERLAY
  • TYPE_SYSTEM_ERROR

このうち DroidKaigi の発表で取り扱った部分は TYPE_SYSTEM_OVERLAY と TYPE_SYSTEM_ALERT です。ドキュメントを読む限り、引き続き TYPE_SYSTEM_DIALOG は使用できるようです。

代替レイヤ

これらの使用できなくなるレイヤに View を描画しているアプリは、代わりに O から導入される TYPE_APPLICATION_OVERLAY を使わなければなりません。ドキュメント上でも must use とあり、エミュレータで動作を確認したところ、使えなくなったレイヤに描画はできてもタッチイベントは取れなくなっているようです(すべての使えなくなったレイヤで同じかは未検証)。

TYPE_APPLICATION_OVERLAY をつかっているプロセスは優先度が上がるようです。おそらく Service で WindowManager に View を描いている時、startForeground() しなくても visible process として扱ってくれるものと思います。

この TYPE_APPLICATION_OVERLAY については、ステータスバー等のシステムが受け持っている UI の下に位置するようです。システムは TYPE_APPLICATION_OVERLAY にある View を適宜動かしたりリサイズしたりできるようです。また、通知シェード(ドロワーのこと?)から直接 TYPE_APPLICATION_OVERLAY に View を書いているアプリをブロックすることができるとも記載されています。

まとめ

DroidKaigi のセッションでは、Keyguard の上のレイヤに View を置くときはタッチイベント等の入力を受け付けてはいけない話にも触れましたが、この変更では実質 Keyguard 上に View を置くことができなくなるように見えます(TYPE_PRIORITY_PHONE, TYPE_SYSTEM_OVERLAY, TYPE_SYSTEM_ERROR がダメになるので)。オーバーレイ表示そのものがかなり気を遣って実装する必要のあることを考えると、今回のレイヤの整理と挙動の変更はなるほどという感じですが、システムの介入が増える分考慮すべき部分も増えているはずです。

DroidKaigi 2017 に登壇、運営、参加してきた

運営についてのブログ記事はDroidKaigi 運営における Twitter 運用のあれこれ - Celeste Engineerにまとめましたので、この記事では主に登壇者としての立場の話をしようと思います。

登壇

30分枠にして内容てんこ盛りのゼロから始める黒魔術の入門から実運用までという話です。お陰さまで黒魔術師横幕こと黒幕という栄えある称号をいただきました😁。

speakerdeck.com

開始5分前くらいはシーンとしていて、写真を撮ったり撮られたりしていました。

運営スタッフとしては初回から関わっていますが、登壇者としては今回が初でした。はー完全に作りすぎました。途中、記述の間違いから話す内容が混乱してしまいました😞。

少しトークの内容に触れておくと、

このようにやろうと思えば数行のコードで邪悪なアプリが作れてしまうAPIです。用法用量を守って楽しくお使い下さい。

もう少しユースケースについて言及したほうが良かったかもしれませんが、アプリ内で起きている様々な目に見えない事象(モデルの状態変化、アナリティクスイベントの発火など)を Logcat に出していると、リリースビルドでログが見えなくなったときの動作確認が困難になってしまうため、リリースビルドの設定画面でスイッチ一発でそういう目に見えない情報をみえるようにしたい、という動機でこのオーバーレイの機能を作りました。DroidKaigi アプリでは使っていませんが、DeployGate と組み合わせると、Google Play で配信しているアプリでは見えない、DeployGate で配信しているアプリでのみ使える特殊機能というのが実現できるので、これと組み合わせて社内用リリースビルドで使える機能を作れます。これと合わせて使うとかなり効力がでてきます。

非公開 API を使って遊ぶと言う内容の話をこれまでにしてきた自分にとっては、公開 API だけを使って遊ぶと言う内容の話は自分としても珍しかったのですが、うまく伝えられていたようでうれしいです。

オフィスアワー

オフィスアワーやるよって言って実際質問が来るのかどうかドキドキしていましたが、質問に来てくれた人がいて嬉しかったです。

このほか「Android Auto エキスパートに話があるってよ」ということで、Android Auto について教えて欲しい!という話を、Android Auto とは何なのかと言うところからアツく語らせていただきました。Android Auto エキスパートというのは完全に自称ですが、Android Auto がどのような技術で成り立っているかなどソースコードレベルで熟読しました。実を言うと今回の DroidKaigi 2017 でもプロポーザル自体は出していたのですが、採択されずじまいでした。次こそは、もっと Android Auto のことを知られるべき!!という熱量でもってトークをしたいと思います。

さいごに

運営スタッフとの二足のわらじは聞いていたとおり大変で、同時並行に別のことを進める必要があるので、それなりに体力や根性みたいなものも必要です。一方で、お金を払ってきてくれた人たちがいる、ということに変に気負いすぎるのもよくないので、自分の知っているイカした技術を紹介するぜ!というスタンスでいると、程よい緊張状態で前に立てるのではと思いました。もちろん、有料イベントであることを忘れていいということではないのですが。 運営スタッフとしては Twitter を眺めるお仕事をしていましたが、会期中も会期後も興奮冷めやらぬツイートがたくさんあって、また今回は山口県や北海道など遠方からの参加者も多数いて、何かしら持って帰ってもらえたものがあったようで本当に嬉しい限りです。なかには、DroidKaigi 2017 に ポッサロから参加した 感想文 - Google スライドのような参加者自身の知見も出てきたりしていて、カンファレンス自体の圧倒的成長を感じました。

みなさま、お疲れ様でした。また次回お会いしましょう。

DroidKaigi 運営における Twitter 運用のあれこれ

3/9と3/10の2日間にわたって DroidKaigi 2017 が開催されました。おこしいただいた皆様、ありがとうございました。

自分はカメラを構えて写真を撮ったり、Twitter でお知らせを流したりしていました。当日は #DroidKaigi が非常に盛り上がっていて、数分でTLがどんどん流れていく状況でした。 @ken5scal さんの助力もあって、カンファレンス中の様子を Tiwtter を通して伝えられたと思います。

さて当日 Twitter 担当の @ken5scal さんと私がなにをしていたかというと、写真を取ってつぶやく以外にも以下の様なことをしていました。

スパム対応

同じハッシュタグのついたつぶやきが増えてくると、そのハッシュタグがトレンドとして扱われます。いわゆるトレンド入りというやつです。そうすると、トレンド入りしたハッシュタグをつぶやきに含めて人目を引き始める謎の bot が、1時間に1回のペースで #DroidKaigi を含めた無関係のツイートを流し始めます。日にもよりますが、DroidKaigi の場合は毎時0分ごろにそのようなつぶやきが増える傾向にありました。

無関係のつぶやきにトレンドのハッシュタグをいれられてしまうと、後々検索をするうえで邪魔になってしまいます。そこで、そういったつぶやきは都度見つけ次第、一つ一つ心を込めてスパム報告します。報告の数が上がるほど効力を発揮するため、当日は他のメンバーにも報告を手伝っていただきました。

しかしこれ、対応する数が多くなるにつれ、また時間が進むに連れてだんだんと心が失われていきます。初日には謎の「#全自動おぎゃり機」というハッシュタグもトレンド入りをしており、数多くの bot が「#全自動おぎゃり機」と「#DroidKaigi」を並べてつぶやいており、気分的には完全に「駆逐してやる…」という感じでした。おかげさまで二日目にはスパムツイートがほぼ皆無だったので、初日にがっつり対応した成果が出たようです。

おそらく他のイベントでも同じような対応をしていることと思いますが、スパム対応は規模の大きなイベントの運営ではほぼ必須の工数だと思います。

お問い合わせ対応

当日は Tweetdeck などのツールで「DroidKaigi」のエゴサ結果を常にみていたので、メンションのあるないに関わらず、スタッフに伝達して対応できそうなものを順次連絡していました。特に部屋の空調やマイクの調子などはその場でなんとかできそうな内容だったので、各部屋のスタッフに逐一伝えて対応をしてもらっていました。

もうちょっとしっかりできるとよかったなと思う点は、スタッフへの伝達後に、お問い合わせ(やそれに近い内容のつぶやき)にもメンションをとばすことがあまりできなかったことです。初日の夕方頃に振り返って気付き、少しずつですが対応をしてみたところ、ポジティブなリプライをいただくこともあったので、このあたりは折を見て積極的にやっていけるとよいなということがわかりました。Twitter を通したコミュニケーションではありますが、最終的には人が運用しているので、心地よくコミュニケーションが取れると、運営で疲れていても「がんばるぞ😊」という気持ちになって次につなげていくことができます。

自分はあまりできていなかったところですが、会場から沸き起こる参加者のツイートに「わかる」等の引用リツイートをしたり、ゆるふわなかんじで「フ〜」とツイートしたりして、楽しげな感じを出すのも大いに重要だということがわかりました。このあたりは @ken5scal さんに助けられました。

今後

DroidKaigi 2017 自体は終了しましたが、実は Twitter 担当のお仕事は会期後にもあります。発表者資料のリンクがまとまったら告知したり、セッションの動画を告知したりといったお仕事があります。動画は前回同様 YouTube にアップロードする予定ですが、YouTube 上で、動画のアップロードの完了と Twitter での告知を自動で連携することができます。この連携、今現在はどうかわかりませんが、前回の場合はつぶやきに URL が含まれないケースが数件ありました。これは人力で対応するしかない(たいてい短縮 URL を入れる余地は残っている)部分です。

さいごに

アフターパーティーで初めて知ったのですが、地方の、それもかなり遠いところから新幹線で参加している高校生の方がいらっしゃったことにはとても驚きました。個人的には学生枠というと、大学生がくるものと思っていたので、もっと若い層の人たちが、お金と時間をつぎ込んででも参加したいと思っていただけるイベントになったんだなと思いました。

DroidKaigi 2017 で "Building my own debugging tool on overlay" と題して登壇します

タイトルの通り、3月9日〜3月10日にかけて開催される DroidKaigi の2日目、Room 2 で 11:50 から “Building my own debugging tool on overlay” という題目で登壇します。 Android で開発者向けに提供されているオプションのなかでもオーバレイで各種情報を表示している部分を、自分たちのアプリにも組み込んでみようというテーマです。

当日はスタッフとして写真をパシャパシャ撮ったり告知を流したりもします。内容的に時間内で質疑応答ができるかどうかという感じですが、セッション後にかぎらず気軽に話しかけてもらえればと思います。