基礎教養というのは人生の打率を上げるためのものかも知らん
なまじあり物のライブラリやなんかを組み合わせてそれなりのソフトウェアが作れてしまうし、10年もやってりゃそれなりに哲学のあるコード（良いコードとは言ってない）が書けるようになったので、ともすれば自分をいっぱしのシニアエンジニアだと勘違いしてしまうときがある。
ただそういったものがないフィールドで戦う必要が出たとして、僕は急に戦うすべを持たなくなってしまう。
たとえば難関大学の数学や物理を出たソフトウェア技術者が周りにゴロゴロいるわけだけど、こと2010年代後半のAndroidアプリ開発（フレームワークより上のレイヤ）に限っていえば僕もそれなりに彼らと比肩できる自負があるが、彼らはこの世から急にAndroidが消えても次の何かにジャンプしてまた活躍する基礎がある。僕はそれが非常に恐怖だし羨ましい。
とかく自分は低レイヤに信仰にも似た崇拝感情をもっており、お釈迦様の手の上で楽しく踊っているとつい「この下はどうやって出来てるんだ」と不安を覚えてしまう。そして下に掘っていけば行くほどむき身の数学と対峙する必要がある。
ただこれは無意味な前提である。Androidは今日突然なくなりはしないし、低レイヤを突き詰めるとしてじゃあどこまでおりて行くんだ？半導体に電気ながしゃ気が済むんか？ということになるし、若干ノイローゼ気味なのかも知れない。
で、思うに、基礎教養っつーのは人生の打率を上げる以上の意味はないのかも知らんなぁというのが最近の気付きだ。
基礎教養はあるに超したことはない。そんなもんは僕だって分かりきっているが、さりとて高校のときにサボって10年寝かしちまったもんはもうしょうがないわけで、いまたまたま「上のレイヤ」でメシが食えてるんならそれでまあ良いじゃないと思うのが身の丈に合った幸せってもんなのかなぁと。
で、これも思うに、じゃあ基礎教養のないまま諦めるかっつーとこれはまあ僕の過去のエントリを見てもらうとお分かりのとおり僕は非常～～～に諦めの悪いおとこで、いまもチマチマやっとるわけである。ある日突然ハシゴが外されたときに僕も生き残る打率を上げたいんよ。
最後にツイートにも書いたけど僕はマジで普段エラそうに「技術者の待遇をあげよ！」とか喚いてるわりに高校数学もおぼつかない有様なんだけど、その僕が移動時間や夜眠れないときの睡眠薬に使ってる数学の参考サイトがこれである。
これは秘密にしておきたかったんですが、僕みたいに数学が本当に本当にできなくてプログラマになってから泣きながら復習してる人にこの「数学ハイパーテキスト」をおすすめします。僕はここよりわかりやすいサイトをみたことがない。こういうコンテンツに感謝の投げ銭したい。https://t.co/iJIQ5W45G6
— 父 (@fushiroyama) 2018年3月15日
「数学ハイパーテキスト」がいかに素晴らしいかはこのページを見ればわかる。https://t.co/5W7KBMkTdU
— 父 (@fushiroyama) 2018年3月15日
不登校等で数学を学べなかった人が「独習」できるように予備校講師の方が善意ではじめられたコンテンツなのだ。このページを読むだけでもう最高のコンテンツと確信できる。実際素晴らしいし。
これほど素晴らしいコンテンツが原初インターネットから存在しているのはこの世の救いである。なんとかして御本人にお礼を伝えたい。僕は数学が苦手だが数学が好きな生徒(34歳)です。ありがとう。
Macで貧弱なネットワーク回線を再現してスマホアプリをテストするTips
QAさんに口頭で伝えるのが大変そうだったのでブログエントリにする。
iPhone/AndroidアプリのQA時に貧弱なネットワーク回線を再現したいことがままある。そういうときは「Network Link Conditioner」と「インターネット共有」を使うと便利だよという話。
1. Network Link Conditioner
https://developer.apple.com/download/more/
から「Additional Tools for Xcode」をダウンロード。その時々で最新のものを選ぶと良さそう。今日時点でmacOS High Sierra (10.13.3) + Xcode 9.3用のAdditional Toolsで動作を確認。
古いNetwork Link ConditionerはHigh Sierraで正しく動かないので注意。
展開。Hardware > Network Link Conditioner.prefPane をダブルクリック。
こんな感じでSystem Preferencesに入る。
任意のProfileを選んでONにするだけ。Profilesは帯域やパケットロスも含めて細かくカスタマイズ可能。
2. インターネット共有
「共有する接続経路」に有線インターネットのデバイスを選択する。ここではUSBイーサネットアダプタを選択しているが環境によって読み替えて欲しい。
「相手のコンピュータでのポート」に「Wi-Fi」を選択して「インターネット共有」を有効にするとアクセスポイントができる。
右下の「Wi-Fiのオプション」からSSIDとかパスフレーズとかを設定できる。
3. つなぐ
AndroidでもiPhoneでもなんでもつないでください。低速回線が再現されます。
Androidも使える方法でもっと楽なのがあったら教えて。
DroidKaigi 2018で登壇してきたので振り返りとか補足とか
DroidKaigi 2018で登壇してきたよ！
Unit Test Hands On is underway! #DroidKaigi #DroidKaigi_room4 pic.twitter.com/jBfAxYQwyN
— DroidKaigi (@DroidKaigi) 2018年2月8日
資料はこれ。
ハンズオンのサンプルプロジェクトと課題はこれ。
良かった点
前日こんなツイートしてかつDroidKaigi公式アカウントがそれをRTしてくれたせいか、ハンズオンなのに立ち見／地べた座り参加者が出るほどの盛況だった。
アプリで登壇者に自分がおるのめっちゃ嬉しいな。DBもRESTもDomain層もPresenterも全部テスト書けるようになるぞ君たち。Presenterとか感動するよ。絶対おいでよ。 pic.twitter.com/nOiUSfrSM3
— 父 (@fushiroyama) 2018年2月7日
それから参加者の半分はUnit Testが初めてかそれに近い状況で、資料もハンズオン課題（の前半部分）もまさにそういった方に向けて一生懸命作ったのでそれに関しては満足している。
反省点
いっぱいある…
- Robolectricが初回実行時にダウンロードするライブラリの差分が会場ネットワークの詰まりで進まず、ハンズオンがストップした。これは運営さんやインフラを責めているのでまったくなく、そのような可能性に思い至らなかった自分が悔しい。
- GitHub APIが同一IPからの単位時間あたりの接続数上限に達してしまい会場でサンプルアプリが動かなくなった。これも事前の調査不足というか、実際にそういう目に遭ってみないと考えつきもしなかった。
- サンプルアプリをAndroid-CleanArchitecture風に設計し、その各レイヤごとにUnit Testを書けるようになるとめちゃくちゃ有意義なのでは？という想定のもとすべてを準備したが、会場の参加者がそれを求めていたように感じられなかった。完全に自分の独りよがりになった。
- ハンズオンとして参加者に書いてもらう部分の調整の甘さ。僕はUnit Testを書くことそのものは大好きだが、ハンズオンをそれほど主催したことがなく、課題として空欄にして埋めてもらう部分の難易度設定に難があったように思う。
- ハンズオン課題を英語対応しなかった。会場には日本語を解さない海外からの参加者の方もいて、その方には個別に対応したが、そもそもこれだけの規模のイベントでそういう参加者が当然に来てくださることをもっと真剣に考慮すべきだった。
とまあこれらはすべてもし次回があったときの糧としたい。まだ初日が終わったところで、2日目の早朝にぐずる赤ん坊を抱っこしながらこのエントリを書いているので、最終的なフィードバックの集計を待ちたいところだ。
サンプルアプリに関する補足
今回はスライドで座学をしたあと、前述のハンズオン課題をもくもく解いてもらった。
これはGitHubアカウントを入力したらその人のレポジトリ一覧を表示するという人類が一体どれだけ同じものを作ったのか想像もつかないほどありふれたアプリだが、設計には慎重な考慮を重ねてUnit Testもできるだけ「明日から仕事で使える感」を目指した。
個人的に課した縛りは次の2点。
理由は単純で、それぞれこのライブラリのことを説明するだけで50分のセッションができるほど習熟が大変だからだ。RxやDaggerが出てくることで今回の設計やUnit Testの本質がブレてしまうことを避けたかったのだ。
したがって非同期処理基盤には古き良きThreadPoolExecutorを用いDIはシンプルなコンストラクタインジェクションとFactoryパターンという古典に則った。
しかしながらシンプルで理解しやすさを求めて敢えてこれらの込み入ったライブラリを用いなかったことで却ってこれらのライブラリの恩恵でスマートに解決できている問題を自分で処理せねばならないという皮肉な結果となった。
誰にでも分かってもらいやすくするために特定のライブラリやパラダイム（例えばRx）に依存せずユースケースやレポジトリを書こうとすると、結局「特定のライブラリやパラダイムのお陰でキレイに解決できてた問題」が首をもたげてくるので、却って何がしたかったか分かりにくくなるな…（伝われ🙏）
— 父 (@fushiroyama) 2018年1月25日
このときには資料づくりは佳境でなかなか方向転換もままならなかった。参加者のみなさんの感想が楽しみでもあり怖くもあるが、なんとかこれらのライブラリを使わずありふれたJavaのコンポーネントだけで書いたことによる可読性の方がわずかでも勝っていると信じたい🙏
で、サンプルアプリで特に注目して欲しいのはやはり各レイヤのテストコードだ。
前述のレポジトリはハンズオン向けにcloneしたらデフォルトでtasksというブランチがチェックアウトされるようになっている。こちらはUnit Testが空欄になっている。これをmasterブランチに切り替えると僕が普段書いているようなUnit Testをひととおり書いてある。興味のあるひとは是非見てみて欲しい。
Repositoryより下のビジネスロジックの部分はみんなも関心が高いしテストコードも結構書いてると思うんだけど、ちょうど同期と非同期が混じり合うUseCaseの部分はどうやってテスト書いていいか苦慮すると思うし、Presenterなんかもテスト書きづらいんじゃないかな。Presenterはちゃんと書くとViewとのインタラクションを検証できるので是非プロジェクトをcloneしてみてフィードバックが欲しい。
DroidKaigiの感想
とにかく最高のひと言。
After Partyでスピーカーには風船を付けさせるアイディアは最高で、これのお陰もあって「白山さんですよね？」と数え切れないほどの人に話しかけてもらって本当に光栄だった。
スピーカー風船つけて飲んでるのでUnit Testの相談しにきてください #DroidKaigi pic.twitter.com/wsbwW1uPlm
— 父 (@fushiroyama) 2018年2月8日
それからAndroid 設計パターン入門という本の著者陣がほとんど居るという豪華な状況が嬉しくて子供のようにサインを求めて回った。
そういえば「Android 設計パターン入門」の著者陣がいらっしゃったのでサインを貰って回った。ここにあとSFの今井さんのサインが加わったら巨大な龍が現れてどんな願いも叶えてくれるはず https://t.co/CCON01SVN2 pic.twitter.com/P5hTqeaC5J
— 父 (@fushiroyama) 2018年2月8日
返す返す、これほど素晴らしいAndroid関連イベントは世界でも早々ないであろう。代表の日高さん、スタッフのみなさん、登壇者のみなさん、そして参加者のみなさん全員に深く感謝したい。
まだ2日目が控えているが、こういうのは早ければ早いほどその時の熱気が文章に乗ると思ったので赤ん坊に3回目の授乳をして抱っこしたまま早朝の暗い部屋の片隅でこれを書いている。
今日もまたみなさん楽しみましょう。じゃあの。
DroidKaigi2018「はじめてのUnit Test」の資料事前共有とフィードバックのお願い
2/8の DroidKaigi 2018 にて「はじめてのUnit Test」というハンズオンを担当します。
で、setohさんのこのツイートにシビレたので僕も資料を事前共有することにします。
DroidKaigi、順調に行けば週末に資料公開すると思います。見てもらえればある程度のレベル感と内容が伝わって、CfP読んだイメージと内容が違ったという事故は減るかと。逆に資料だけ見て満足する勢が来なくなるリスクはあるけど、それは僕以外の人にはプラスになるので全く問題ないです。
— setoh (@seto_hi) 2018年1月31日
資料はこちら。
念のため確認ですが、僕のセッションはあくまでハンズオンであって、
- 座学パートでこの資料をみながらUnit Testの書き方を解説する
- その後はチューターとしてサポートしながら各自ハンズオン形式でUnit Testを書いていく
ことを予定しています。ここで共有したのは前者の参考資料です。
本当はハンズオンのコードを共有したかったのですが、もうちょっと作り込みたいのでちょっと待って下さい。
一応、
- 初心者向け課題として、この資料にでてくるサンプルコード片のテストコードをひととおり用意しているので好きなように書いてもらいます。まったく初めての方はこれが達成できたら万々歳です。
- 中級者向け課題として、完全に動くシンプルなAndroidアプリを用意しており、これはいわゆるClean Architectureに範をとった構成になっています。これの各レイヤーのよくあるテストコードを書いてもらいます。かなり実践的な内容が詰まっていて、僕も共有するのが楽しみです。
という感じです。
で、これを見てくださったみなさんは資料でもうえに書いたハンズオン課題（構成案ですが）でもいいので、何でもコメントください。Twitterで @fushiroyama にリプライでもDMでもください。
とにかく参加者のみなさんに「有益だった！」と言ってもらえる時間にしたい。そのためには一時的に恥をかいてもなんら構わない。なんでもコメントください。それではよい週末を。
macOS High Sierraのzshでちょっとハマったのでメモ
2年経って会社の開発マシンがリプレースの時期になったので今日からMacBook Pro (15-inch, 2017) Touch Barモデルで開発している。 思ったほど困ってないがzshの設定で少しハマったのでメモ。
ログインシェルをzshにできない
% brew install zsh % chsh -s `which zsh`
としてもiTermを立ち上げ直すと $SHELL = /bin/bash に戻っている。
% sudo vim /etc/shells /usr/local/bin/zsh # 追記
これで使えるようになった。
aliasと同名の関数を定義できない
Sierra環境で使っていたzshrcをそのまま使おうとすると
% source ~/.zshrc /Users/shiroyama/.zshrc:188: defining function based on alias `ssh' /Users/shiroyama/.zshrc:188: parse error near `()'
というようなパースエラーが出るようになった。たしかに alias ssh と ssh() {} が存在する。
zshのことは全く詳しくないのでエラーでググったらどうやら関数に明示的に function ssh() {} のように function とつけてやれば良いようだ。
全部そのようにしたら晴れてエラーが解消した。
ちなみにHigh Sierraだからじゃなくて普通に考えてzshのバージョンだと思う。
% zsh --version zsh 5.4.2 (x86_64-apple-darwin17.3.0)
Touch Barモデル雑感
よくESCがないとツライと聞くが、僕はESCはC-jに割り当てているのでvimを使う上では何ひとつ困らない。
ただファンクションキーがないのは明確につらくて、カナ変換とかで思わず手がF7を探しちゃうし明るさも音量も調整にまごつく。
デスクに座ってる限りは外付けキーボードとトラックパッドを使っているので違いは感じないが携帯したときにストレスを感じるかもしれない。
あと、ポートがUSB-C * 4だけというのが一番気が狂いそうになる。電源もイーサネットアダプタ1もディスプレイケーブルもスマホも何もかも全部ぜーんぶUSB-Cである。 何年後かにこの世にほとんどUSB-Cだけが生き残っていたらもう少し生きやすいのかもしれないが、その前にAppleさんはiPhoneをUSB-Cにしなかったのはなんでなんですかね… そんくらいかな！
なお古いMacBookを返却する際にベタベタに貼りまくったステッカーを全部はがし終わるのに60分要した。 もう二度とこんなアホなマネはせえへんぞとステッカーをはがすたびに思うがどうしても再びやってしまうのは自分でも理解できない。
口が悪いエンジニア論争
通勤の暇にかこつけて今話題の「口は悪いが凄腕の技術者を雇うべきか」論争に対する自分の考えを残しておく。
まず大前提として「技術力も人間力もある」のがベストというのは揺るぎのないものであり、僕もここを目指したいと常々考えている。
その上でだけど、僕は「そうすることが必要な場面では口の悪さに目を瞑って技術力を取る」選択もありだと考える。
みんなこれには一家言あるようだけど、結局のところ全員前提としている状況が違うので意見が異なるのは当然のことだ。ただ僕が言いたいのは「ある種の問題はそれを解決することがそもそもできない絶対的な壁がある」ということだ。
本件に関して様々なツイートを拝見したが「そもそも技術力は育てられるが人間性は中々変えられない」という意見には、後半こそ賛同するものの前半には両手をあげて賛同できない。ある種の課題、プログラマのコンテキストで言えばいわゆるNP困難な問題は中庸なプログラマを100人並べても対処できない。ゼロだ。
なんでもいいんだけど例えば事業の課題としてGoogle Mapを超える最強の地図アプリを作ろうとするじゃない。そしたら最短経路とか求めないといけないけど、これそういう教育を受けてない人には無理じゃないですか。
ダイクストラ法ぐらいならググれば出てくるけどダイクストラ法はコストが負のノードがひとつでもあったら成り立たない。じゃあそれの改良版のコレコレを使いましょうとかね。
こういうのって数ヶ月から数年の教育と訓練と実務で身につける類のもので、人間性の優れた素人プログラマを10人集めても倒せない。こういうとき、酒癖も女癖も最悪だけど一騎当千の呂布みたいな武将に力を借りざるを得ないのは仕方ないと思う。
なのでまとめとしては最初に書いたとおり、場合によっては口の悪さぐらいでは引き換えにならないぐらい技術力には壁があるんじゃないかしらということだ。それからこれが1番言いたいことなんだけど、みんな人間性の優れた呂布になろうな。僕も頑張る。
近況と2018年の抱負
ご挨拶
新年明けましておめでとうございます。
このブログは普段のAndroid開発の気付きとかを他ならぬ未来の自分（最近つとに忘れっぽい）のために書き残していたのであるが、人生について書いたエントリが随分バズってしまったのでやっていきブログと思われているかもしれない。なのでこの辺で意図的に本来予定していたゆるさに戻していく。
元同僚の定期的なブログ更新の良さについて - 滞舎路日記というエントリに賛同する部分が多かったので僕もとりあえずネタがなくても何か書いていこうと思う。
渡米準備
ビザの書類には数え切れないほど用意するものがあってもちろん会社や代行業者がサポートしてくれるんだけどそれでもめっちゃ大変（語彙の喪失）
あとは引っ越しの準備とか手放すものの整理とか郵便の転送とかそれから仕事の引き継ぎとか英会話とか娘の保育園の手続きとかDroidKaigiのスライドとか毎日目も回らんばかりだ。
子育て
僕はフルタイムお父さんであってパートタイムプログラマである。とにかく子供たちと毎日精いっぱい生きている。やはりプログラマの端くれなので新しいことに挑戦する時間が取れなくなると切なさを感じないではないが、これまでは夜9時に寝て朝4時に起きるなどして何とかしてきた。ところが次女が昨夏生まれて以来ふたたび夜泣き対応を経験しており「あ〜、あったな〜こんな時代」としみじみしている。まあそんでも子供がお父ちゃ〜んと背中にまとわりついてくれるのなぞせいぜい満4-5歳ぐらいと考えたら最後の一滴まで味わいつくしたい。
ベンチャーキャピタルさんと新規事業
2018年は米国のラボで新規事業やらなんやらをやる。弊社がLP出資しているVCがあってその縁で彼らがこちらの新規事業のアドバイスを定期的にしてくれているようだ。で、こないだ初めてこのVCとこちらのMTGに参加させてもらったんだけどこれは詳しくは書けないけどまあひどい内容で、思わず間に入って最初から最後までずっと通訳*1と狂言回しをするハメになった。この先のことを考えると暗澹たる気分になったが、その後VCのメンバーとの会食で「君は一番印象に残ったよ。これからもよろしく頼む」と褒めてもらってそれは自信になった。これは正直僕が頑張らないとどうにもならんという感想だし、まあ結局のところだからこそ僕が送り込まれるのだと腹をくくった。とにかく結果を出したい。
ともかく楽しくなりそうではある。2018年もよろしくお願いいたします。
