最近の自分が興味あることとかそのへんの話
2018年6月現在、僕は株式会社エウレカで働いています。 最近自分がやってることや興味があることを書き出してみたいと思います。
UI/UXおよびデザイン
自分はAndroid開発が得意です。 一時期サーバーサイド開発をやったりもしましたが、あくまで当時のドメイン知識の範囲であれば新規開発や保守運用もできたなーと感じています。
WantedlyやLinkedinなどでサーバーサイドのお声がけをいただくこともあるのですが、期待されているアウトプットは現時点では出せないと感じています。 とはいえ状況によってはそんなこと言ってないで必要なことはなんでもやるぜ！というスタンスですが。
そんな自分が最近思っているのはAndroidエンジニアとしてクライアントサイドをやっている以上、UIをメインの戦場として戦っていきたいということです。 大規模開発での設計の重要性を認識した上で、自分としてはよりUI実装を得意とした方向に進みたいなーと感じています。 その上でアルゴリズムなどを必要があれば学ぶというスタンスです。
そういえば、もうすぐマテリアルデザインアワードのノミネートが締め切られますね。Pairsでノミネートしたいと思っています。
Does your product push the boundaries of #MaterialDesign?
— Material Design (@materialdesign) 2018年8月2日
🏆 Expression
🏆 Experience
🏆 Adaptation
🏆 Innovation
Nominations for the 2018 Material Design Awards are now open: https://t.co/j8EgvEzCpD pic.twitter.com/WQY4f6s6hm
まとめると、UX向上においてユーザーのUX向上をUIを通じて改善することにより価値をおいている状況です。
チーム開発
今年はRSGT2018にも参加しました。 2018.scrumgatheringtokyo.org
エウレカでは全社的なスクラム開発を経て、事業部全体のカンバン運用に入っています。
自分としてはその中でカイゼン委員会に入っていますが、そこの経験からチーム開発やプロセス改善に興味をもっています。
チーム開発って奥が深いです。 暴論ですが、タスクを1人1つこなしている状況はチーム開発とはいい難いと感じています。 このあたりの考えについては別の機会でアウトプットしてみたいと思います。
DApps
ブロックチェーン技術は注目しています。 既存の中央集権的なサービスを置き換えるまでに行く状況というのはまだ先の話かなーと思いつつも、未来はわからないのであっという間に変化の波が来るかもしれません。 この辺の動きは注視しつつ自分の行動はすばやくしていきたいと思っています。
この記事はめっちゃ良かったです。 記載されている本は買って読んだし、Blogは購読するようにしました。 blockchain.gunosy.io
コミュニティとしてはこの辺はwatchしています。 blockchain-tokyo.connpass.com
まとめ
情報は発信すると集まるの法則を信じています。
自分が興味あることをこのように書いてみることで、同じように興味ある方からの反応をいただけると最高だと思います。
そして反応してくれた方との議論や対話を通じて自分をアップデートしていきたいなーと思っています。
個人開発のアプリをなんとかリリースまで持っていけた理由
はじめに
今年の個人目標として技術書以外の本を40冊読む！というのを立てたことをきっかけに本を読むようになってきたのですが、 本を読み続けるモチベーションとして、何か記録をつけるサービスを使って行きたいなーと思っていた時にいくつか選択肢がありました。
その中でも僕が選んだのが今回非公式クライアントAndroidアプリを作った読書メーターです。 良かったのは本ごとに一緒にメモが残せる点と、グラフや数字でどれぐらい読んでるのか見ることができる点です。 bookmeter.com
でも残念なことに既存のAndroidアプリは非公式で、更新も滞っていました。 そこで、無いなら自分で作ってしまおう！と思って開発をはじめました。 実際に開発しているのがこちらです。 play.google.com
リリースまで開発を続けられた理由
①自分が使いたいこと
一番はこれです。個人開発は納期も無いし必要に迫られることが無いと感じていましたが、自分で使いたいから早くほしくて手が動くという感じでした。 リリースしたこれからは自分以外のユーザさんも出てくると思うので、そのあたりも今後はモチベーションになっていきそうです。
②競合がいること
最初に上げた既に存在していた非公式Androidアプリがなかなか良いダウンロード数で1万〜5万という表示がされていました。 更新が滞っていたので自分が新しいモダンなものを作ることができれば、同様のダウンロード数ぐらいまでは行けるのではと考えていました。 勝手に競合だと思って、勝ちたい！と思って開発が進んだと思います。
③MVPを意識すること
MVPとはMinimum Viable Productの略で最小の労力で最大の効果を得られる機能に集中して開発していくって感じの理解です。 開発をしているとあれもこれもやりたくなってきて、いつの間にか何作ってるのかわからなくなって来るパターンもあると思います。 そんな時はこの機能は絶対ないとだめ、これはあったら嬉しいけどなくても困らないなど自分の中で作るものと作らないものを分けて開発を進めました。
おわりに
いったん自分が欲しい機能は作れたのでこれで読書も捗りそうです。 読書メーターにはSNS的要素もあったりするので、よければ一緒に読書していきましょー！ futabooo - 読書メーター
Scrum Masters Night! に参加してきた
最近スクラムマスターとしてお仕事するようになったので、色々吸収したいと思って第16回 Scrum Masters Night!に参加してきました。 smn.connpass.com
Scrum Masters Night!とは
Scrum Masters Night!はオープンスペーステクノロジーで運営されており、参加者同士のディスカッションを通じて、スクラムを実践する上でぶつかった課題や疑問に対して解決のヒントを得ることを目的としているイベントです。 参加者の中からファシリテーターを募集するので、スクラムマスターにとって重要となる「ファシリテーション力」を鍛える事が可能です。 僕は初参加でびびってたので、ファシリは遠慮しておきました。
オープンスペーステクノロジー
スクラムアライアンスが主催する「Global Scrum Gathering」でも活用されている、会議運営の手法です。 会議の参加者が、解決したい問題・議論したい課題を持ち寄って小グループでディスカッションを行います。ファシリテーター役の参加者が、ディスカッションを促進します。 また、会議の参加者は、 The Law of Two feet（2本足の掟） に従って行動します。
The Law of Two feet（2本足の掟）
会議に出席すると決めた場合、参加者はそこで、「学習する」か「貢献する」か、どちらかをしなくてはいけません（これを徹底するには、かなりの努力が必要です）。 もし、議論の場にいても学ぶものがなく、貢献もできていないと感じたなら、参加者は席を立って、2本の足でその場を離れ、2つの行為のどちらかができそうな別の場所を探す責任があります。 同じ会場の中の、別の課題を話し合っているグループに移っても良いし、休憩所に行っても良いのです。
参加した議題
スクラム開発における品質管理に参加しました。
学習or貢献できないと思うタイミングが無かったのでそのテーブルから動かなかったので、１個しか話してません。でも濃かった。
ファシリテーター役の方が最近個人的に聞いていたポッドキャストのオーガナイザーの方だったのでテンション上がりました。 初対面だけど適度にパーソナルな突っ込んだ話とかもして場をつくるのうまかったなーという印象。
議論中はこんな感じでテーブルにシートがはられててファシリ役の人がメモっていっていた。
書き出すのは問題対私達にできるのですごくよいなっておもった。ファシリテーション・グラフィックとかで調べると出て来る。
缶ビールとかが写ってますが、飲食に関しては、BYOB（Bring Your Own Beverage/Beer/Booze）形式で自分でのみものとつまみをもってくるっていうかたちでした。
品質管理は組織構造でうまくいったよー的お話聞けたのですごくよかった。 ここでも思ったのは戦術は戦略が間違ってたらダメだからもっと戦略から考えられるようにならないとなってこと。
来年もGoogle I/Oに参加したいと思ったGoogle I/O 2017だった
Google I/O 2017に参加してきました！ 最高でした。 来年も参加したい。 行ったらなんとかなったのですが、行くまでは準備に不安だったし、1回行ったらもっと改善できそうな事があったので残しておきます。
セッションについては色々な企業のブログで触れられていたり、youtubeには既に動画が上がってるので書きませんｗ
宿
Booking.comで宿を取りました。 チケットが当選する前から会場の近くのホテルを抑えていました。 Booking.comで予約できるやどは前日までキャンセル料がかからないものがあったので、チケットが当たらなければキャンセルすれば問題ありません。 チケットが当選してから宿を取ると中々見つからないという話をよく聞くのでこの方法は来年もやろうと思います。
ただ相場がわかって無くて比較的高額な宿に泊まってしまったので、そこは来年に活かそうと思います。
またホテルの場所ですが、会場までのシャトルバスが出るホテルが公開されているのでそこに泊まると楽かもしれません。 毎年同じなのかどうかまでは分からないのでなんとも言えませんが。
今年僕が止まったホテルはシャトルバスが泊まるホテルまで徒歩5分程だったので会場へは行きも帰りもシャトルバスを使うことができました。
ごはん
I/O開催期間中は朝ごはん・昼ごはん・夜ご飯が会場で提供されています。
当たりハズレもありますが、概ねおいしかったので開催期間前後でフリーな日があればその時のご飯だけ確保すれば大丈夫です。
ご飯を確保する必要がある場合はYelpを使えば大丈夫です。 僕はカンファレンス最終日はホテルに泊まって次の日の朝の便で帰国予定だったので、 3日目の夜ご飯（I/O最終日は4時で終わり夜ご飯無）をYelpを使ってホテル近くのお店を見つけて買いに行きました。
このボリュームで$9でしたｗ
ネット環境
今回はサンフランシスコ国際空港にあったプリペイドSIMを売ってるところで現地プリペイドSIMを購入しました。 8日間の間1GBまでは高速回線、それを超えても低速で使い続けることができるものを購入しました。（100/kbpsぐらいだったと思います） それでだいたい$60ぐらいです。
ホテルやI/O会場ではwifiが提供されているので僕の滞在した5日間でも低速回線になることはありませんでした。
市内まででてAT&TやT-mobileのお店までネットなしでも行くことができれば、もう少し安いプリペイドSIMも手に入れられそうでしたが、 ネットが無い、英語も満足にできない状態で空港の外へ出るのが怖くてできませんでした＼(^o^)／
日本国内に居てもAmazonなどで現地プリペイドSIMを事前に購入しておいて現地でアクティベイトすることが可能なものもあります。
気をつけたいのは端末が使える対応周波数です。 AT＆TやT-mobileのようなキャリアによって対応周波数が違います。 端末が対応している周波数で提供しているキャリアのSIMを使うようにしましょう。
泊まったホテル近くにあっためちゃくそでかいスーパーで売っていたSIMです、種類多すぎますねw
アメリカもMVNOが豊富なようでした。
移動手段
ホテルから会場まではシャトルバスが使えるのであればシャトルバスを使いました。 そうじゃなくてもUberかLyftを使えば問題なくホテルから会場まで行くことができます。
マウンテンビューからサンフランシスコ市内やサンノゼ市内まではUberやLyftを使わない場合はCaltrainを使って移動します。
Caltrainはチケットを乗るたびに買ってもいいですし、Clipperと言われる日本のSuicaみたいなカードを買ってチャージしてもいいと思います。 僕はClipperを使ってみたかったので$3のデポジットを払ってカードをもらい、$20チャージして使っていました。
いまいちよくわからなかったのが、Caltrainの駅で乗る時にカードをタッチすると最大料金がまず引かれて、降りる時にサイドタッチすると実際にかかる費用が引かれるという仕組みです。 乗る時にチャージ料金が足りなくてビープ音となんかの注意文言が表示されたのですが早すぎて読むことができずに何が起きたのかわかりませんでした。 結局その時は現金で別途チケットを買って乗りました。あれはなんだったのか。。。
来年もまた行けますように！
hugoを触ってみる
静的サイトジェネレーターであるhugoを試してみました。
hugoのinstall
brewも用意されているのでそっちでやるのもいいと思います。むしろ公式サイトにはbrew経由でのinstall方法がかかれていました。
僕はgithubのreadmeに書かれていたgo getする方法でinstallしました。
$ go get -v github.com/spf13/hugo
新規サイトを作る
hugoには新規サイトの雛形を作るコマンドがあるので実行します。
$ hugo new site futabooo.com
上記を実行すると下記の感じでフォルダやファイルが作られます。
futabooo.com/ ├── archetypes ├── config.toml ├── content ├── data ├── layouts ├── public ├── static └── themes
hugoのサイトにはいくつか公開されているthemeがあるので、それを自分のサイトに反映させます。 今回はこれにしますHugo Theme: Tranquilpeak
$ cd themes $ git clone https://github.com/kakawait/hugo-tranquilpeak-theme.git
ローカル環境で動かすためのコマンドもhugoには用意されています。
$ hugo server --theme=hugo-tranquilpeak-theme
これでlocalhost:1313にアクセスするとサンプルの状態のサイトが表示されます。
ここからはconfig.tomlを自分好みにカスタムしていくことで、自分のサイトにしていくことができます。
今後
現状GCPで公開するところまでできてるのですが、werckerからのdeployに対応させて、記事を書いてgithubにコミットしたらauto deployされる！みたいにしたいと思っています。
DroidKaigi2017にスタッフ＆スピーカーとして参加してきた
はじめてのカンファレンススタッフ
僕がDroidKaigi2017のスタッフと参加することになったきっかけは、代表のmhidakaさんと僕が勤めている会社の人事の人のつながりから当日スタッフとして人員増員というかたちでした。 スタッフはみんなメインのお仕事が別であるとか学生の方も一部いるようで、基本的にDroidKaigiの運営は空いた時間にやっていくという方々ばかりでした。
タスク管理すごい
DroidKaigiの運営にあたって、タスクはGitHubのIssueで管理されていました。
IssueにはかならずDoneの定義と締切日がGitHubのマイルストーンを使って設定されていました。
そのうえマイルストーンが設定されていないIssueがあると、Botがマイルストーンを設定してね！とIssueにコメントをしてくれます。
またマイルストーンで設定されている締切日を過ぎたIssueにBot経由でコメントをさせるショートカット的なものがあり、そいつを使うと締切日を過ぎてるIssueにBotがコメントをしてくれます。
その他にもIssueへのコメントが流れる専用のSlackチャンネルが存在しており、タスクに関連する話についてはIssue上でやっておけば誰でも状況をつかむことができる状態にされていました。 本業ではタスク管理にJIRAを使っていますが、ここまで管理を徹底できていないのでこのノウハウは社内に還元したい！と思っています。
ミーティングはリモートとリアルの両方ある
リモートとリアルのミーティングが週に1回づつありました。
基本リモートが週1回と、月一回のリアルミーテイングがありました。開催直前はリアルミーテイングも週1で行っていました。
リモートの方は都合が合わずに参加することができなかったのですが、リアルの方では現在の状況で共有したいことと相談したいことという2点についてそれぞれがアジェンダに記入しておき、順番に話をして物事を前に進めていく感じでした。
この時にリアルで足を運ぶのが難しい人もハングアウトでミーティングに参加することができるスタイルでした。
リモート勤務がある企業の方もいたのかどうかを把握できていませんが、プロジェクト運営はリモートが前提となっているやり方のように感じました。 世の中のリモート勤務導入を検討している企業さんには大変参考になるのではないかと思います。
基本スタンスは楽しむこと
DroidKaigi2017ではおよそ800名の来場者があったようですが、言ってしまえば全員他の会社でお仕事がある人達で800人規模のイベント運営をなぜやれたのでしょうか。 個人的に感じていたのは、みんな好きで運営をやってるし来場者に最高の体験をしてもらいたいと思っていたからだと思っています。 好きこそ物の上手なれということわざがありますが、まさにそれを感じました。
例えばタスクが締め切りまでに終わらなかったとしても「なんで終わってないの？」みたいなことは把握してる限りではありませんでした。
締め切りまでに終わらないことがないようにメンバーがヘルプをしてくれるし、Issueには助けてLabelをつけることができてヤバそうなら事前に助けを求めることもできます。
よく仕事でもマインドが大事だと言われることが多いと思います。僕自身は仕事としてやるべきことをやっていれば問題ないという考え方の人間でしたが、マインドとか考え方がそもそもに無いと結局何かが足りないアウトプットになってしまうのかなーという気づきを得ることができました。
スタッフをやってよかった
運営スタッフをやって本当に良かったと思っています。 様々な気付きや学びを得ることができましたし、なによりDroidKaigi2017が最高に楽しいイベントとなって思い出に残すことができました。 もちろん、参加者の方からのフィードバックもたくさんいただいているので来年も参加することだできたらそのあたりを改善したより良いDroidKaigiを提供する側にいたいと思っています。
スピーカーとしても初参加
スピーカーとしても初参加でした。 僕が勤める会社からは3人のスピーカーが登壇していたので、発表当日までに3人で進捗どうですか？と確認をしあって進めていました。これをやっていたおかげで前日にあわあわするということもなく、スムーズに発表の時を迎えられたと思っています。
自分の当たり前は誰かにとっての知見
Welcomeトークでスピーカー代表のlvla0805さんも話していましたが、僕の発表テーマもこんなん話して需要あるのか？と思っていました。 しかし実際には採択され、発表することができ、アフターパティーでは「発表良かったです！私が聞いた中では一番でした！」と言ってくれる方も居ました。褒められて死ぬかと思いました。 来年もとりあえずなんかしらのCFPを出そうと思います。
DroidKaigi2017総評
控えめに言って最高でした！ 運営、スピーカー、スポンサー、来場者などなど全ての関わった人で作られた最高の会でした！
Freelineとはなにものか
これはAndroidその２ Advent Calendar 2016の23日目の記事です。
はじめに
昨今Androidのbuildまわりの話は結構盛り上がっているなーと感じます。 Androidのbuildをしてるとマシンリソースをもっていかれて他の作業に支障がでたりすので、自分のマシン以外に誰も使ってないマシンをbuildサーバ的に使ったり、GCPなどのクラウドリソースを使ったりすることで解消する方法が様々出てきています。 それ自体は最高だな！自分も職場では使っていくぞ！という気持ちで実際空いてるiMacを使ってbuildしたりしています。
一方でbuild自体が高速で終わればbuild中に何分間も他のことができない！みたいな状況はないのではないかとも思います。 また個人開発として考えた時に、札束で叩く選択肢はなかなか取りづらいよなーと思ったりもします。 そこでひとつの解決策として良さそうなのが今回紹介するalibaba/freelineです。
Freelineとは
概要
githubのREADEMEの導入部分を引用すると下記のように紹介されています。
Freeline is a fast build and deployment tool for Android. Caching reusable class files and resource indices, it enables incrementally building Android apps, and optionally deploying the update to your device with hot swap.
Developed and used by Ant Fortune (about us) Android Team, Freeline has been significantly saving time in daily work. Inspiring by Buck and Instant Run but faster than ever, Freeline can finish an incremental build in just a few seconds. No more recompile and reinstall again and again before seeing your modifications, Freeline brings life-changing development experience for Android.
要点だけまとめるとこんな感じです。
- ホットスワップを可能にするぜ！
- BuckとInstant Runにインスパイアされているが、それらよりもより早く動作するぜ！
- FreeLineはAndroid開発生活に変革をもたらすぜ！
完全に意訳ですが、ノリとしてはこれぐらいハッピーな感じで書かれてるんじゃないかと勝手に理解しました。
詳細
特徴
また下記の項目の変更に対応しているようです。
| Java | drawable, layout, etc. | res/values | native so | |
|---|---|---|---|---|
| add | √ | √ | √ | √ |
| change | √ | √ | √ | √ |
| remove | √ | √ | x | - |
他にもたくさんあるようですが、RADEMEに記載されているので興味がある方はご覧ください。
まだまだな点
- 初回だけちょっと遅い
res/valuesの削除には対応できていない- 抽象クラスのインクリメンタルビルドはできない
- Kotlinはサポートしていない
最近の国内でのKotlin熱を考えるとサポートしてないのはちょっとつらいかもしれないですね。
Freelineの使い方
githubにsampleプロジェクトがあるので、それを使ってみます。 手順はこれだけ。
git clone git@github.com:alibaba/freeline.git cd freeline/sample ./gradlew initFreeline python freeline.py
実際にコマンドの実行をしているところを動画に収めたのでご覧ください。 （本当はttyrecとttygifを使ってgif化したかったのですが、謎のエラーでttyrecが使えず今回の記事では諦めましたorz）
— futabooo (@futabooo) 2016年12月23日
なんかtaskが並行実行されてる雰囲気がわかっていただければ幸いです。 既存の自分のプロジェクトに導入する場合はbuild.gradleへの記述などありますが、READEMEに書いてあるので簡単に導入可能です。
おわりに
手元にある大きめのプロジェクトはkotlinが入っていたりしてうまく動かなかったので、Freelineでどれだけ早くなるのか比較を書くことができずに終わってしまいました。 この記事をみてFreelineを試した方にぜひ比較結果をコメントもらえたらなーと思っています。
またほとんどFreelineのREADMEを紹介するだけになってしまいましたが、今回本当に紹介したかったのは下記の記事です。 中国語で書かれており、内容の把握に骨が折れますがFreelineがどのように実装されているのか詳細な紹介がされています。 Androidのフレームワークの知識が必要なため僕自身グーグル先生とともに解読中です。
