35歳
ついに35歳になってしまいました。
35歳というともう少しちゃんとした大人を想像していたけど、結局のところ人間というのは突如成熟したりなどせず、過去の自分の積み重ねの写像でしかないのであります。
この2年ぐらいは自分の貯め込んだ知識をすべて会社のプロダクトと若手の成長のために注ぎ込んで参りました。ただもうちょっと僕自身も成長できるのではないかと考え、色々画策した結果幸運にも恵まれ、今こうしてアメリカ合衆国の大地を踏みしめております。
率直に言って老いは悲しいです。僕自身は正直500歳ぐらいまで生きたいです。たかだか80年というのは、僕がやりたいことを全て叶えるにはあまりにも短い。自分の人生が巡回セールスマン問題というのは中々皮肉なものです。しかしまあ、時というのは誰にも平等でありますから、定められた枠の間でベストを尽くすしかありません。
そういった中で、子供の存在というのはやはりかけがえのないものだなぁと感じます。僕が35になるのは悲しいですが、子供がその分ちゃんと5歳になるのだからまあ良かろうと思えるのであります。
子供とつなぐその手のひらが、小川をとびこえるその足が、パパにしがみつくその腕が毎日少しずつ少しずつ大きくなるたび、君の存在はこの世界の中にたしかに広がってゆき、僕はその分少しずつ小さくなりながらやがて大地に還って、そのまま風となって流れてゆくのだろう。千の風n…おっとJASRACがくる。
子供たちに会えてよかった。そして妻に会えてよかった。少し前は高校生ぐらいに戻って勉強をやり直したいと思っていたけど、妻と会ってやがて子供たちと出会うという、この書き換え不可能なコミットを見てしまった以上、そこに至らない歴史になんの興味もない。
35歳というかこれから2年ぐらいの抱負はやはり米国に来なければなし得なかった達成を遂げることです。この国と向き合い、この国の人々と向き合い、この国の問題に向き合って情報科学の力でこの世を少しでも良くしたい。我々プログラマはその力を持ってこの世に降り立った。幸運なことです。頑張ろう。
最後に、誕生日プレゼントはカリフォルニア州の免許が欲しいです…
というのは冗談で、本を書きます。Androidのテストの本です。とても良い本になる確信があるので是非買って下さい!ほいじゃあの!
言葉が持つ呪いにとらわれず生きたい
言葉は呪いを持つ。
趙の武霊王は紀元前310年、野台に立ち中山と斉を「望んだ」とある。
望むとは呪いを込めて見るということだそうだ(宮城谷昌光『楽毅』より)
すなわち攻め取るということだ。
時に僕は自分の望んだ自分になろうとする余り自分自身の言葉にがんじがらめになって動けなくなることがある。たとえば「アメリカでプログラマとして職を得るにはコンピュータサイエンスのマスターの学位が必要だ」といった思い込みだ。これは僕自身に対する呪いとなっている。
これは実際に自分がかつてビザの問題で就職に頓挫しその時色々調べた結果、これが最も確度の高い方法らしいと学んだ結果なのであるが、現役高校生ではあるまいし、冷静に考えると僕がこの方法に執着するのはまったく馬鹿馬鹿しいのである。
見渡すと、学位などなくても右腕一本でこちらの会社に乗り込んで行って職を得ている人などゴマンといる。僕もそうすれば良いのだ。
ここまでは僕の話で、ここからは僕自身が放った言葉の呪いが思いがけず他人を縛るかも知れないということ。特に若い人がたまたまアメリカでプログラマとしてやっていきたいという夢を持っていて、たまたま僕のエントリを読んで「あゝ自分は文学部卒だから所詮叶わぬ夢…」などと思わせてしまったら遣る瀬ない。そんなことを思う必要はない。学位を持たぬおじさんの学歴コンプ爆発と鼻で笑って自分の夢を追いかけて欲しい。その呪いを断ち切るためにこのエントリを書いた。エーンガチョ!これで君も僕も自由である。
ところで冒頭の武霊王は胡服騎射と言って、かつての中国における貴族的な戦車による戦いから、戦士が直接騎馬に乗って戦場を蹂躙するという"野蛮な北方民族"の戦術を採り入れて趙を一大大国に押し上げた。
僕も学位はなくとも10年の実務経験があるのだ。胡服騎射して攻め入るのみ!
本当はビザ面接、ソーシャルセキュリティーナンバーの取得から免許の取得までをエントリにまとめようと思ったのにカリフォルニア州の運転免許試験に落ちたので訳の分からんエントリになってしまった…じゃあの。
基礎教養というのは人生の打率を上げるためのものかも知らん
なまじあり物のライブラリやなんかを組み合わせてそれなりのソフトウェアが作れてしまうし、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分要した。 もう二度とこんなアホなマネはせえへんぞとステッカーをはがすたびに思うがどうしても再びやってしまうのは自分でも理解できない。