DroidKaigiのこと
俺の Advent Calendar 6日めの記事です。昨日は dageziさんの DevUI でした。って、Advent Calendarに登録するの忘れた。いかん。
気を取り直して、今日は DroidKaigi 2016 の話をしたいと思います。
まあ、自分は端っこに参加してるだけなのであまり深い事情をしりませんが、と言い訳をしつつ。
DroidKaigiとは
この DroidKaigi、RubyKaigiをご存じの方はわかるように Androidに関するエンジニアの知見を集めた Conferenceを作りたい、ということで集まったんだと思います。すでに Androidの Conferenceとしては Android Bazaar and Conference (略称ABC) が何回か行われてるわけですが、それとどう違うんでしょう、というのは実は ABCに参加したことがないのでわかりません。ここらへん、いままでコミュニティ活動をサボっていたつけがあります。ただ、イメージとしてはビジネス色がうすい、かつ世界を狙っているあたりが違うのかなあ、という感じです。
で、不肖ながら自分もそのボランティアの末席に加えてもらって、雑事を手伝うと言いつつ、いろんな会社におじゃまして綺麗だなあ、とか思ったりしてるわけです。
現在は、2016年2月の開催を目指して、CFPは終わって、一般参加の申し込み をやってるところです。めでたく早期割引は売り切れて、一般参加ももう少し、というのが現状のようですね。学生枠もちゃんと捌けて欲しいな。
DroidKaigiの運営
まだ 2回しか参加してませんが手作り感が高いっす。いろいろなことが手探りで決まってる感じが高く、ボランティアと言いつつ待っているだけではだめな雰囲気があります。とはいえ、自分もイベントとかを仕切るのは苦手なタイプなのであまり口出せずに歯がゆい感があります。
例としての CFP審査
その例として、本日行った CFP審査会議のことを書こうかと。まあ、こんな下っ端でも CFP審査に出ていいのかな、と思いつつも 90本あまりの CFP (公開されてます) を読み込んで会議に参加してみました。ちなみに CFP募集中も期間も「Kotlin熱いねえ」「Rxなかなか来ないねえ」「そもそも選べるほど来るんだろうか」と中の人としてちょこっと心配してましたが、結果、いろんなジャンルのものが海外からも集まったりしてすげーな、という感じです。自分は、2本しょぼいのを付け加えただけで尽力してないけど。
実際の審査は至極穏やかに行われました。個人的には「なんでこれをいれないんだ! そんなの落とせ!」とか激論が繰り広げられるのかとワクワクしてましたが、非常に民主的に投票で決まっていきました。ちとあっけないっす。個人的には聞きたかったな、というのが落ちたりして無念だったのですが、まあ、仕方ないっす。
それでもなかなか聴き応えのあるものが揃ったと思います。あとはうまく聴衆が重なる分野が同じ time slotにこないといいけど。時間割作成者の気苦労が忍ばれます。
CFP読んでみて
とりあえず今回、CFP読む側に回っての感想がありました。あくまでも個人の感想なので、これが審査する人全員に通用するかはわかりませんが。
前置きは少なめでいい: それなりに審査員は技術がわかった人が読むので背景は少なめでいいのでは。
どれだけディープかわかるといい: よく知られたネタでも、じつは深掘りすると面白かったりすることはよくあるので。バズワードを散りばめただけか、それともそこに意外な深い知見があるのかわかるといい。
対象聴衆がわかるといい: 簡単そうな内容でも、初心者用にあえて丁寧にやる、とかだと受ける気がする。
知見的なのは悩む: 一つの分野だけじゃなくて、複数にまたがった話とかだと悩む (Kotlin中心だけど + CI とか)。技術は独立しているわけじゃないんだから、そういう話が必要なのはよくわかる。でもシナジー効果的に話が面白くなったりするのか評価しにくい。どうしたもんでしょうね。
これからが本番だ
やっと CFPの一次審査が終わっただけで、これからいろいろあるようです。特に今回は有料になったので、お金のこととか面倒くさそう。 とはいえ、参加して祭りをつくり上げるのはなかなか緊張感があって面白い感じです。技術ネタ以外でも Android界隈を盛り上げて採用目的、もとい活気のある業界になるといいっすね。
DevUI
俺の Advent Calendar 5日めの記事です。
俺はメインは Androidのアプリの開発をやっています。そろそろ今やってるアプリの骨子の部分はできてきて、で、ちょっと嫌な部分になってきました。UIとかの調整です。
アプリエンジニアの中には、凝った UIを作るのがすきな人もいるのだと思います。でも、自分は苦手です。しかも、Quipper社は自分が人を集めたりしている成果、そういう Android Engineerが集まってきてしまっています。Networkの APIとか、Model Layerで整合性を取るとか、そういうのは得意なんだけど、UI調整というと逃げ腰になるという。まあ、その解消策の一つとして gradle-android-9patch-plugin を作ったりしたわけですが、これは問題の一部を解決しただけでまだまだ苦手感は有ります。
その一つというか大きな要因に、なんでそういう UIにすべきなのかよくわからない、というのがあります。
データベースとかだったら、なんでそういうスキーマにするのか、とかがわかります。今後度のデータが増えていって、どういう情報を見せたいかを考えると、このテーブルを作らなきゃいけないとか。それぞれの技術的選択にどういう得失があってどう決断するかわかります。過去のしがらみとかももちろんありますが、それも技術的負債として将来返済しようと前向きに考えられます。
でも、UIはよくわからんのです。
なんでここでこういう marginが必要なのか、ここの animationはどう動くべきなのか。まあ、画面の遷移ぐらいだと、こうしないと必要な画面にたどり着かないよね、とか判断できるけど、でもやはりわからない点も多い。
あと、やっているうちに考慮していない遷移 (エラーケースが多いけど、それ以外に正常系でも多い) が発生して、そこに対する対処が場当たりっぽいなあ、と感じたり。
で、そういうのはソースにも現れるわけです。最初は conventionつくって ちゃんと意味に則った dimensionとかを予め定義してそれから外れないようにしようと頑張ったりしたこともあったんですけど。 semanticにそういうのをまとめても結局例外とか現れたりして、最初に決めた semanticは何だったのか、ということになる。もう最近はそんなもの抽出するのを諦めて数値ベタ書きになってたりします。UIの refactoringとかできない。そもそも UIの factorってなんだそれ、俺の目には掛け合わされた合成数しか見えないぞ、って感じです。
まあ、ここまで愚痴を延々と書きましたが、そこらへんは Waterfallっぽい開発に毒された脳みそのせいもあるのだと思います。UIについてもコードと同じく継続的に評価と試行を回していくことによって factor outしていく必要があるのだろうなあ、と。
で、表題の DevUIということばにいたるわけです。 DevOpsのように、DevとUIが協調して Iterationを回すことによってお互いに納得しながらいいものを作っていけるのではないかと。
と、最後はちょっとエモくなってしまったので、もっと地に足をついたことを書いたほうがいいのでしょうが、そこまでまとまった tipsがあるわけではなし、ちょっと書けるネタは Sketch 3 Advent Calendar に書く予定なのですみません。まあ、この Advent Calendarやってるうちにも何かトライして面白い結果が出たら書いてみたいとは思います。
でも、考えてみると Webアプリの場合、そこらへんをやってるのがマークアップエンジニアって位置だったりするんでしょうか。どうなんでしょ。
時間切れ
俺の Advent Calendar の 4日の記事です。
と言いつつ、書くネタと時間がなくてこんな時刻になってしまいました。23:30です。 やはり午前中のテンションの高いうちに仕上げないとだめっすね。
きっとちと発想を変えればネタは出てくる気がするんですが、発想を変えるエネルギーがないというか。酒を飲んでしまって、家族もそばに居て、いろいろ無駄な思考を考える部分がない。
とりあえず、書き出してみたらなんとかなるかなあ、と思って書いてみたんですがこんなグダグダな感じです。
いまは、このぐらいでごまかして、ネタになるかもしれないことを今から遊びます。では。
ほかの Advent Calendarを眺めてみる
ほかの Advent Calendarを見てうらやましげだな、と思って始めた企画なんで、とりあえずほかのやつを見て小並感でも書いてみます。 あんまり網羅しておらず、行き当たりばったりです。
上から目線でどうでしょうか、とか書こうと思ったけど、上から目線で切る立場じゃないので、面白かったものを淡々と。
モバイル DevOps
モバイルDevOps - いいアプリを楽しく開発できる現場を作るために大切なこと - Qiita
Webと Mobileの違いが面白かった。というか、そこらへんに歯がゆさを感じてるモバイル開発者は多いんじゃないかな。Webの best practiceを適用できないという。 そのせいで、Mobileはまだ Water Fall風の流れがまだ残ってるんだよなあ。仕様書きっちり書こうとしたり。tryするだけでできないけど。中途半端だ。
Sketch3
github×Sketch 3 運用のススメ - meycoのUX&UIデザイン技術メモ
一応、自分も参加してる Sketch3 Advent Calendarの 1日目です。同僚でもある meyco氏です。
思ったより長い。というか、こんなこと考えてたんだなあ、とびっくり。あと、ちょっと突っ込みたいところもあるけど。
っていうか、Github運用の話はもっと先の日じゃんかったっけ。自分はそこに続くネタとして日にちを調整したのに。まあ、面倒くさいから日付は移動しないけど。
まあ、DevOps的な観点からここら辺の Designの雑事ってもっと減らせる気がするので、かかわっていきたいとこです。
Android
Choreographer 〜 AndroidでFPSを意識してみる話 〜 - Qiita 専門の Androidも。 @wasabeef_jpさん相変わらず頑張ってるな。
FPSというのは、普段意識してないけど，確かにかくかくするところはあるので意識すべきかな。それよりライブラリをすぐに切り出す態度が偉いな。でもメンテできてるのかな。いっぱい出して生き残ればいいのかな。
Scala
http://qiita.com/wasabeef_jp/items/a98571081f6c3224744a Scala が解決できる Android アプリ開発の問題領域について - 非同期処理編 - Qiita
すごい Scalaファンじゃないけど成り行きで読んでしまった。Androidネタに絡めてあります。
ここら辺、Promiseは monadだ、ってことに帰着するんでしょうか。ざっと読んだだけなんで咀嚼できてません。
個人的には Androidで Scalaはないなあ、と思うので Kotlinで同じことできないかなあ、とか夢想します。でも Closureの数が多くなりすぎて Androidでは破たんするのかなあ。Bytecodeレベルでの optimizer (facebookが作ってたよね) で解決したりするのかなあ。
オレの
本日 JavaScript ゲームライブラリ『phina.js』をリリースしました! | phiary
勝手に対抗意識を燃やしてた オレの Advent Calendar ですが、俺のみたいにネタじゃないみたいです。Phinaって jsライブラリをまじめに公開してます。結構準備してたみたいです。すみません、侮ってました。
終わり
現場からは以上です。
俺の Advent Calendarをやってみる
0655を見て、ああ、師走も始まってしまったんだなあ、と思いつつも 12月最初のあわただしい朝が始まってしまった。今日は嫁が用事で早く出るとかでいつもよりも忙しい朝だった。その代わり、子供とともに出かけてしまうといつもよりも静かな朝が来た。ということで、一人でいる朝にこんなものを書いている。
というより、思い付きで始めてしまった。俺のAdvent Calendar である。
まあ、twitterで 1日目書いたよ、ってのをいくつか見てちとうらやましくなったのが端緒である。blogとかいうものちっとも書いてなかったので書かなきゃ、というものもある。発表もいくつか応募したのでネタを書く練習をしなきゃ、というものある。まあ、いろいろある。
よくある 30days lifehackというやつと言えなくもない。まあ、正確には25日だけど。たぶん、同じことをしてる人もそこそこいるんだろう。ググってもないけど。「俺の」って命名も、某レストランチェーンに乗っかったようで凡庸なネーミングだ。あれってあとから変えられるのかな。
単に書き続けることが目的なので、何について書くかは決めません。時間がなくて単に一言の愚痴とかになることもありそう。避けたいけど。たぶん、仕事柄プログラミングネタが多くなるだろうけどそうじゃないものも書くのでは。よくわかりません。
いずれにせよ、最初は勢いで、最後は惰性で頑張りたいと思います。「勢い」と「惰性」、物理的には同じような意味なのにやる気のあふれ方の違いが面白いな。アリストテレス的とガリレイ的な世界観の違いかな。
あわてて思い出しながら描く
7月も終わりになってしまうというので、一応近況がてら書いてみます。忘備録というか、誰得なチラ裏になるけど。
Quipper社買収発表および引っ越し
一番でかいのはやはりこれでしょう。techcrunch ですっぱ抜かれて、というかリークしたように Quipper社は Recruit 社に買収されていたのでした。これで公に言えるようになってよかった。
それに伴って、渋谷区の端っこの笹塚から中央区は京橋にオフィスが引っ越しました。Rグループの一員という感じです。個人的には昼飯事情がよくなって大変うれしいです。旧オフィスは笹塚といっても駅徒歩15分の住宅街の中にあったので、あまり昼飯の選択肢がありませんでした。でも、京橋は歩いて5分以内に選択肢が山ほどあります。毎日違う店に行っても半年ぐらいは困らないでしょう。夜もいろいろありそうだし。めでたい。
ちなみにオフィスについても前回ほどではありませんがファンキーさを残しております。ごろ寝スペースはあるし、テーブルフットボールもバージョンアップされました。前回は、くつろぎすぎてまるで部室みたいだ、と言われたのですが、今回は社会人としてもっと清潔感を出すように心がけたいと思います。
お近くに来た時はぜひ遊びに来てください、といいたいところですが、今回大企業に買われたということで、いろいろ社内ルールを見直していて、簡単に執務スペースに入れなかったりするのかも知れません。カードキーとかもついたし。はっきりしたらまた更新するかもしれません。誰も見てないからしても意味ないか。
お仕事内容は、まだはっきりとは言えませんが、なんとなく決まってます。残念ながら自分は向こうのエンジニアとかとちゃんと絡めてません。隣なんだから行きたいんだけど、いきなり乗り込むほど度胸ないっす。まあ、当面は以前どおり海外むけの Quipperサービスをメインに粛々と続けていきます。
社内の雰囲気は変わるかについては、今のところそんな変わってません。11時過ぎに blog書いてるところで察してください。CEO経由で聞いたところによると、R社はそういう文化込みで Quipperを買ったので、それをわざわざ壊すようなことはしないはずだ、とのこと。それを信じて、当面は短パン Tシャツで出社してます。
残念なこととしては、そこそこやめた人がいたこと。これは単に R社に買われたからというわけではなく、皆それぞれ事情があって、それとタイミングを合わせて考えたら今やめるのがベストだということでそうなったようです。もちろん、イグジットしてしまってこれ以上いてもチャンスがないから、というも加味されたりしてるんでしょう。スタートアップとしては当然のことであります。
そのかわり資本力が増えたことにものを言わせた採用活動が実って、一緒に働いてくれるメンバーが数人内定しました。ちなみにフィリピンでも 2人 Android Engineerが増えました。そこについてはまた別で書こうかな、とか思います。
全体としてなかなか強力なメンバーがそろったようで、wktkです。チーム運営的な難しさは増えてくるんでしょうが、Q社としての文化を残したまま、うまくゴールを合わせて作り上げていきたいところです。
その他
なんか、買収まわりのことを書いていたら長くなってしまいました。ほかの activityについては githubでも参照してください。
あと、Windows10まだ入れられてません。うむむ。
WIndowsの入力回りがだいぶまともに
二週間ぐらい前に Vaio Pro買ったよ報告をしたが、やっとキーボード回りが快適な状態になって来て使えるようになってきた。のでみんなに公表。我ながら偏った設定だと思うが、Unix系から流れた人には参考になることを希望しつつ。
のどか
autohotkey や ymmyも試してみたが、のどかにした。
英語モードだと default2.nodokaをちゃんと読んでくれない (SJIS encodingになっていたらしい) とかではまったが、まともに使えるようになってきた。やはり emacs bindingから離れられない。
ということで、現状の設定ファイルをhttps://github.com/dagezi/nodokarc に置いといた。
Thumbsenseも当然ながら有効になっている。
やや困るのが、touch trackpad -> D-F -> untouch trackpad -> U-F のシーケンスで、最後に MouseUpではなく U-Fがそのままはかれてしまい、いろいろ整合性が取れなくなる。ここはちゃんと shift状態を保持してほしいが、設定ファイルでいじるところではない気がする。
やれやれ、subversionをinstallしないと。
Synaptics track pad
本当にこれはひどい。MacBookユーザが Windowsに移行して使いにくいという原因の 8割がたは、この tuneされていない trackpadに起因しているのではないかとさえ思う。コンピュータに意志を伝える第一段階、マウスカーソルの反応が遅いと、どれだけ普段の生活にストレスを与えるかの好例。しかも脳みそは、それを trackpadのせいだと認識できず、Windows全体に非難は分散する。Windowsかわいそうだ。
てっきり、そういう tuneされていないデバイスは台湾製の PCだけかと思ったら、元Sony製の Vaioですらその状態だったというのはがっかりである。
ということでこの tuneはむちゃくちゃ重要、かつ生産性に聞くと思う。まだ Windowsで何も生産してない俺がそういっても説得力ないが。
以下、defaultから変更した設定項目を書いてみる:
- Tapping: off。カーソルを移動しようとしてクリックになるかと思うと、怖くてカーソルも移動できない。
- SmartSense: とにかく off。default onなのが信じられない。これを切ったらむちゃくちゃ反応性がよくなって快適になった。
- Pointing-Sensitivity: これは一番 lightに。すぐに動け。
- Button-Right Button Zone: Thumbsenseがあるので 0
- Clicking-Two finger click action: Primary clickに。間違えて触ってしまって右ボタンメニューが出てびっくりするので。
でもまだ2本指スクロールがちょっと不満。MacBookほど反応性がよくないのは、deviceだけのせいではない気もする。
あと inactiveな window上での振る舞いが MacBookとちょっと違う。Macはカーソルがある部品がスクロールする。論理的整合性がないなあ、とか思ってたが結構便利だったことが、Windowsに移行してわかった。xmouseも試してみたが、active windowだけの問題ではなく、windowsの中の focused controlもあって、単にカーソルの下の controlが scrollするようにはならず、ちと不満。
