DroidKaigi 2016がいよいよ来週開催されます。 ふとした思いつきでDroidKaigiのカンファレンスアプリを作ったところ公式アプリとしてリリースさせていただくことになり、今現在完全オープンソースで色んな人がコミットしてくれています。スピード感あってなかなか面白いので、忘れないうちに経緯をまとめておこうと思います。 github.com アプリは現在こんな感じです。デモとしてアラビア語表示にも対応しています。 1/11（月） DroidKaigiの発表準備しないとまずいと焦り始めました。 最近は発表の内容に合わせてサンプルアプリを作って公開するようにしているんですが、ただのサンプルコードだと飽きちゃうので何を作ろうかなぁと考え始めました。 そこで思いついたのが、DroidKaigiのカンファレンスアプリでした。みんなが使えるアプリなら懇親会の時の話のネタにもなるし、ぼっちにもな

今日、初Androidライブラリを作って公開してみました。 github.com Google I/O 2015で追加された、Floating Action Buttonの動きを簡単に実装できるUIアニメーションライブラリです。MaterialDesign関連かつ、みんな大好きFloating Action Button系だったということもあって、それなりに反応があってよかったです。 今回のライブラリ公開もそうなんですが、最近 アウトプットを出したい時には完璧を目指しすぎない方がいいんじゃないかなぁと感じているのでちょっと考えをまとめておこうと思います。 「アウトプットの内容によるよね」という意見はその通りで、会社の大事なプレゼンとかそういうのは完璧を目指すべきだと思います。今回は、ブログ書いたりとかOSS活動したりとか、個人の活動にフォーカスして考えます。 荒削りで公開したライブラリ 今

「ここ、こんな感じにできませんかね？」と言われたエンジニアが、「うーん、それはちょっと厳しいですね。できないです」と返すみたいなやりとりは結構見かけます。 この「できますか？」⇒「できない」というやりとりなんですが、「できない」という言葉にはいくつか裏が考えられます。言葉足らずだっただけでちょっとした調整をすればできるよね、というケースもあるので、「できない」という言葉の裏側をまとめておこうと思います。 先に補足しておくと、「エンジニアの人の言葉が足りなすぎるでしょ」という意見ももちろんあると思います。こういうコミュニケーションは、お互いの信頼度によっても変わってくるので難しいところです。お互いが相手に伝わるように意識すべきだと思うんですが、 エンジニアから「できない」と言われた時にどういう意味で言ってるのか想像しやすくなればいいなという思いで書いておきます。 ちなみに、「（できるけどやり

開発で使うライブラリってどう選定してますか？ たぶん選定基準は様々ですよね。社内で基準が明文化されてるところもあるかもしれません。 選定の際には、GitHubスターの数やドキュメントの充実度、最終更新日といった客観的な指標はもちろん、キャッチアップコストやサービスの規模といった開発上の様々なトレードオフを考慮する必要があります。自分は漠然と「ライブラリはあんまり大きくない方がいいなぁ」と考えていたんですが、ちゃんと思考整理できていなかったので、ざっとまとめておこうと思います。 Android開発が多いので、Androidのライブラリを例に話します。あくまで現在の自分の考えのまとめなので、それ違うんじゃない？と思われるところもあるかもしれませんが、その辺は優しくツッコミいただけると嬉しいです。 ライブラリはみんなの課題を解決する そもそもなぜライブラリを使うかというと、その方が楽だからですね

最近若いヨルダン人エンジニアが入社してきまして、新卒の頃の自分を見ているようですごく懐かしい気持ちになります。 当然わからないことも多いので色々質問してくれるんですが、 質問の仕方をもう少し工夫した方がお互いに効率いいんじゃないかなぁと感じて注意することがあります。すごく素直な子なので、注意するたびに「はいッ！すみませんッ！」と流暢な日本語で答えてくれるんですが、逆に何度もそんなやり取りさせて申し訳ないなぁと思ってしまいます。 で、注意しつつも「自分自身こういうところに気をつけて質問してるよ」というのをちゃんと整理できてないなぁと思ったので、今後のためにもざっとまとめておこうと思います。 自分は小さい会社でエンジニアとしてしか働いたことがないので、他の会社では当てはまらないかもしれないです。あくまで 自分が仕事で質問する時に意識していることとしてまとめます。 タイミングを見計らう 大体みん

非エンジニアのメンバーと話していると、 なんだかもどかしい気持ちになることがあります。 なんか話が噛み合わないというか、すごく他責な言い方をすると 「もっと開発のこと理解してほしいなぁ」と感じてしまう時があるんですよね。例えば、難易度の高い修正をさらっとできそうな感じで話されたりとか、逆に超簡単なのに難しいと思って遠慮されてたとか。そういう認識の違いから来るもどかしさです。 最近、このもどかしさを解消するには エンジニアから非エンジニアに歩み寄る方がいいなぁと思い始めたので、考えをまとめてみます。 相手の立場に立って考え直す このもどかしさ何とかならないかなぁと考えていた時に、 SHIROBAKO 17話『私どこにいるんでしょうか…』を見ました。 anicobin.ldblog.jp この回では、新人制作の佐藤さんがアニメーターの遠藤さんにちょっとキツいスケジュールの仕事をお願いし行くシー

個人のアプリ開発は楽しいです。けど時々寂しいです。 例えば深夜にアイコン作ってる時とか。 「いつもはデザイナーさんに助けられてるけど自分でやらないとなぁ…」とか考えて、無性に寂しくなったりします。ちょっと前からこの寂しさを何とかしたいなぁと思っていました。 で、今は Slackにhubotを住ませて1人じゃない感を演出することである程度解決しているので、どんな雰囲気で開発しているかまとめておこうと思います。 先に言っておくと、あくまで自分はこうやってるよという話なので 趣味がかなり入っています。以後その点だけ注意をお願いします。 統一された世界観を作る プロジェクトごとにSlackのチャネルを作ってそこに全て集約しています。GitHubのアクティビティ通知、CI結果通知、メール問い合わせ通知などですね。 ここで自分が大事にしてるのは、 統一された世界観を作るというところです。 例えば この

最近Twitter眺めたりブログ読んだりしていると、 「伝えたいことがある時は汚い言葉は使わない方がいいんじゃないかなぁ」と感じることが多いです。 自分もブログを書くようになったので、自戒を込めて考えをまとめておこうと思います。 汚い言葉のエネルギーすごい 汚い言葉や過激な言葉の与える印象ってすごく強いです。 政治の話題だと特にありがちなんですが、例えば「老害は引退しろ」とか「馬鹿な政治家に任せてられない」とかよく目にするんですけど、すごく目立ちますよね。主張や印象がどうかは置いといて、とりあえず目立つ。 そう考えると、汚い言葉のエネルギーはやはりすごいなぁと思うわけです。 汚い言葉を使うと伝えたいことがブレる エネルギーはすごいんですけど、どうも主張が伝わってこないなぁと感じてしまうことが多いです。主張したいことに意識を向けてみるとそんなに悪いことは言っていないのに、言葉の汚さの方に気が

自社サービス運用している会社では、KPIを設定して数字を追っているところが多いと思います。 どんなKPIをどう計測するかはサービスによりけりなのですが、弊社では重要なKPIを毎日チャットに流すようにしていて、これが結構良い効果をもたらしているので、どんな雰囲気になるのか簡単にまとめておこうと思います。 朝9時に毎日Slackに流れる DAU、 新規ユーザー数、 翌日継続率をSlackに流すようにしてます。『KPI』というチャネルを作っていて、毎日9時に マスコットキャラのTabbyが教えてくれます。可愛いです。 Slackはメンバー全員が必ず見ます。メールは見ないこともありますが、Slackは確実にチェックします。 この 毎日皆が見るというのは、実はかなり重要なことです。 異変にすぐに気づく 分析サービスやSpreadSheetを見に行かなくても毎日流れてくるので 異変にいち早く気づくこと

1ヶ月くらい前、 「バグをドラゴンと呼んだらどうなるか」というTweetを見ました。 確かに、バグをドラゴンと読んだ場合「Sクラスのドラゴンが出ました！」「Aクラスのドラゴンを相手にしてる最中だってのに！」って会話になるし、ドラゴンは結局人の手で生み出されたものってところが中二ファンタジーっぽくて良い— 尾野（しっぽ） (@tail_y) March 18, 2015 これは天才的発想だなと思って職場で雑談で話してみたところ、 同僚のスペイン人エンジニアにバカウケしまして、 それからちょいちょいバグのことをドラゴンと呼ぶようになりました。 せっかくなので、どんな雰囲気になるのかまとめてみようと思います。 先に言っておくと、自分ともう1人スペイン人エンジニアが時々チャット上で使っているだけで、 正直そんなに流行ってないです。 なんかテンションが上がる バグ修正ってマイナスをゼロにするだけで何

最近、本業のTaptripで新機能の開発やコードレビューの数が多くなってきた中、 やはりエンジニアに必要なのは説明能力だなぁと感じることが多々あります。 これは受託の場合は全然違うよと言われるかもしれないし、裁量のある環境だけの話なのかもしれないですが、あくまで自分の感じたこととして考えをまとめておこうと思います。 エンジニアは説明することが多い 開発職じゃないとピンと来ないかもしれないですが、何かを説明することって意外と多いです。 例えばバグ修正をする時に、一番理想的な修正をするとテストも含め2日かかるけど、暫定修正なら半日で終わるみたいな場合。 「ユーザーへの影響が大きいので暫定修正で直して、次のリリースで回収できるように調整します」みたいな説明をしたりします。 もっとコードレベルの話で言うと、例えばこんなやりとりをしたりします。 ほとんど伏せているのでわかりにくいかもしれませんが、

嫁は専業主婦なんですが、エンジニアがどういうことをやっているのかをある程度理解してくれていて色々と捗ります。ただ嫁に限らずエンジニアじゃない人にエンジニアのことを理解してもらうのは結構難しくて、どう実現していったかを簡単に残しておこうと思います。 問題意識 仕事柄、突発的に問題が起こって帰りが遅くなることはざらにあります。特にリリース前は忙しくて帰りが遅くなることも多く、帰るたびに説明責任を果たす必要がありました。 また仕事以外でも勉強のために家で開発をしたりブログを書いたりすることも多く、ジトっとした目で不満を訴えかけられていました。 これは毎回同じような対応をするよりも、根本的に教育した方がいいかなぁと考えていました。問題の本質は 何をやってるか想像もつかないことにあると思ったからです。 クイズを出す こんな会話をしてました。 俺「（画面を見せながら）このボタン何%くらいの人が押すと思

Android開発していると、なんかMVCうまくいかないなぁとモヤモヤしてきました。そろそろ他のアーキテクチャを模索してみた方がいいんじゃないかと思い始めまして、ある程度考えがまとまったので自分なりの指針を残しておこうと思います。 そもそもアーキテクチャ必要なのか 世の中には色々なアーキテクチャが存在するんですが、なんか概念を読んでもスッと理解できることが少ないんですよね。これはなぜかと言うと アーキテクチャが解決しようとしている問題を理解できないからです。 極端に言うと、HelloWorldを表示するアプリにMVCを導入する必要があるの？って言うと答えはNoですよね。じゃあ猫の名前をリストで表示するアプリだったらどうかと言われると、これもまだ必要ないかもしれません。 つまり、アーキテクチャを適用しなくても問題がないほど小さなアプリにおいては、ただ冗長になるだけなので別にいらないわけです。