Runner in the High

技術のことをかくこころみ

2019年の抱負、そして2018年を振り返る

今週のお題「2019年の抱負」

■ 2018年の出来事

 去年は各月の出来事を垂れ流して書いていたがめんどくさいのでやめた。今回は出来事を箇条書きスタイルで。

大学を卒業した

 大学を卒業した。ギリギリまで単位が足りているのかわからない状況で、教務課に問い合わせても「最終的な判断はご自分でしていただいて...」みたいな雑な回答しか得られず非常にフラストレーションが溜まった。

 こういう作業こそコンピューターで自動化して「あと〇〇の単位がいくつ足りません」みたいなのがリアルタイムで分かるようにすべきだろうが、と思った。とはいえ、練馬区の極小中堅大学にそんな文句を言っても仕方がない。もう卒業したしどうでもいいや、という感じではある。

 英文科的な所属であったのに、英語で本格的に教授とディスカッションしたのがこの大学4年生の頃だけだったのがなんとなく情けない。まあ、これも自分の大学選びが悪かったとしか言えない。

ひとり暮らしを始めた

 江東区に住み始めた。実家は世田谷区なので、なぜいまさら江東区なぞに...という感じではあるが、自分はミーハーなので清澄白河駅周辺に住みたいという欲求がとても強かった。

 また、実家は単なる集合住宅であり、成人4人が住むにはもはや狭すぎた。また、やはり人生経験としてひとり暮らしをしたいというのも個人的な願望としてはあったのだ。本当は高層階タワーマンションに住みたかったが、自分の収入と照らしあわせて最終的に見つけることのできた物件はあまり良いものではなかった(後述)

社会人になった

 Fringe81株式会社に入社した。 www.fringe81.com  10社くらいインターンに参加して、最終的に最高な会社だったなということでここに決めた。正直、なぜ自分がFringe81に決めたかという話は、軽く話してしまうともったいない気がしているので時間を取って書こうと思っている。が、あっという間に一年目が終わってしまいそうなので焦っている。

 入社してからは主にScala, Golang, Elmを書いている。もともとJavaScriptRubyばっかり使っていた身からすると、相当レベルの高い言語を書いているなという感じがする。決してプログラミング言語に優劣をつける気はないけれど、正直動的型付けよりも静的型付けの言語のほうが思想が深いと感じている。特にScalaなんか正にそうで、型システム自体がめちゃめちゃ深い。そして行き着く先はモナドだと思う。ここはまだまだ全然自分の中で咀嚼できていないことだらけなので、根気よくやっていきたい。

 Elmに関しては非常に自分の中で好き度が増している。とくにReactやVue界隈のどこまでいっても道具選びで消耗している感から解放されている感じがよい。Elmアーキテクチャというデ・ファクト・スタンダードが決まっているのもよい。社としてのプロダクトづくりの前提としてElmを選ぶという決定ができるというのはすごく喜ばしいことだと思うし、自分がElmを学ぶ必要に迫られるきっかけがあるというのはとてもありがたいと思っている。

海外出張に行った

 弊社がWebSummitへ参加するということで、人生で始めての海外出張へ行った。というかそもそも社会人が初めてなので、そりゃ初めてで当然という感じではある。 fringeneer.hatenablog.com  人生発ヨーロッパでもあったけど、現地のカンファレンスで話した言語は英語だったのでとくに問題はなかった。これまで英検準一級まで取った甲斐があったな、というくらいたくさん英語が話せたのでとても満足した。大学ではスペイン語を勉強していたものの、ポルトガル語は微妙に違うところがたくさんあり、そしてそもそも単位をほぼCで取得していたのでまったく役に立たなかった。単語は節々にそれっぽく分かるものがあった程度。

 帰りのトランジットで降りたパリが正直汚くて萎えた。リスボンは町並みやら気候やら、食事がとても自分にあっていた気がして、ちょっと暮らしてもいいかもなと思ったりした。

■ 学んだっぽいこと

2018年で学んだっぽいこと。こう書くといろいろある。

アプリケーション設計

 例えば大量のトラフィックを捌けるようなアプリケーションを設計する、という状況になるとして、アプリケーションの特性に応じてI/Oがボトルネックになるのか、CPUがボトルネックになるのかなどの勘所が学生の頃よりは持てているような気がする。弊社はGCPを使ってマイクロサービスっぽい構成でアプリケーション開発をしているが、Cloud Pub/SubやTaskQueueがどういった理由で必要になるのかというのは今思えば去年は全くもって想像できなかったんではないかと思う。

 また、適切なモジュールの責務分割と、それにまつわるユニットテストを書くことにすごく重要性を感じるようになった。これまでは、モジュール間の粗結合性をコードレベルでどう生み出せばいいのか、という知識が足りてなかったため、実質的にユニットテストをあまり意味のないものだと思っていた。だが、例えば「クリーン・アーキテクチャ」や「オブジェクト指向設計実践ガイド」などを読み込んでいくことで、複数モジュール間の依存関係をどのようにして粗結合な実装として表現すればいいのか、という概念的な知識がついてきた。特にこの2冊は「いかにして変化に強い設計にするか」という目的に向かってたくさんのヒントを提示してくれた。

 自分ひとりで作っているようなアプリケーションは結局作ったら作りっぱなし、という場合がほとんどであったけれども、業務でお金を生む機械として作るアプリケーションには、非常に多くの変更が加えられる。うれしいことに、ユーザーが比較的増えつつあるサービスを作っているだけあって、先輩たちから指導を受けながらアプリケーション設計を実践する機会がたくさんあったと言える。

新しい言語のパラダイム

 ScalaやElmは自分にとって本当にパラダイムシフトになった。

 自分が初めて使ったプログラミング言語はCだったが、そのときは「型付言語ってめんどくさいな」という気持ちが強かった。それもあってActiveBasicやらHSPに逃げたりしていたところもある。けれども、RubyJavaScriptを使ってある程度の規模のSPAやらサーバーサイド・アプリケーションを作ってきた過去を少しでももっていると、型があるということでどれだけの凡ミスやそれにまつわるランタイムエラーを防げるかがとてもよく分かった。

 が、逆に動的言語には動的言語なりのよさ(たとえばダック・タイピングとか)があり、自分の中でそういう考え方を失ってしまうのもそれはそれでもったいないと思うところがある。その点Golangはすごくちょうどよい。Interfaceでダックの実装をある程度約束できたり、動的/静的型付の良さをうまく折衷できている感がある。ポインタやリフレクションがでてくるとすぐランタイムエラーまみれのコードを書いてしまえるのが少し気になるが。

人間の死臭

 隣人が孤独死したので、その死臭を嗅いだ。なかなか人間の死臭を嗅ぐ機会もないだろうということで、これもある意味学びなんではないかと思う。

 死んでいるのがみつかったのも真夏の結構暑い時期で、どうやら1ヶ月程度は放置されていたらしい。古い物件だということもあり、隣の部屋にインターホンがなかったため面倒くさがって自分は入居の挨拶をしなかった。が、どうやら何らかの病気を患った人だったらしい。弊部屋の壁は本当にペラペラなので、隣の部屋からゴホゴホと咳をしている音が頻繁に聞こえてきた。さすがにちょっと心配になっていたが、今思えばもうちょっとお節介だったら助かっていたのかもしれないなと思うことはある。

金が金を生むということ

 株やクラウドレンディングに手をいくつか手を出した。

izumisy-tech.hatenablog.com

 現時点で、少額だが100万を超える金をクラウドバンクで運用している。見方によっては、どちらかといえば新興の金融商品であるクラウドレンディングだけれども、個人的にはわりとおもしろい資産運用だと思っている。毎月5000円程度の不労所得でポケットに入ってくるのも嬉しい。とりわけクラウドレンディングでお金を運用してみて良かったなと思うのは、よく言われる「金が金を生む」とはどういうことかが分かってきたところにある。

 ロバート・キヨサキの「貧乏父さん金持ち父さん」の最初の章に頻繁に出てくるフレーズとして「金持ちは負債ではなく資産を買う」というものがあるが、結局そのとおりなんだろうなと思っている。自分の収入の大半で資産を買い、残ったお金で慎ましく生活するというのが、4月から社会人になった自分の生活だった。ともすれば、ゲームやら服やらをたくさん買ったり、毎月旅行に行ったりしてお金をいくらでも散財できるが、そういうものにあまり興味が湧かないというのは、わりかし自分でも得な性格だなと思うところがある。せいぜい買ってもプロテインか本くらいなもので、それ以外は散歩でもしてれば大体満足する。

■ その他

基本情報技術者試験に合格した

f:id:IzumiSy:20190104202041p:plain

 自分は文系のバックグラウンドであるため、ある程度情報工学の素養をつけるために受けてみた。毎日チビチビ勉強をするのは、なんとも懐かしい気持ちになった。

そこそこQiitaの記事を書いた

 27記事書いていたらしい。 qiita.com  「今年は100記事書きたい」みたいなことを言っていた記憶があるものの、それには遠く及ばなかった。一部のエンジニア界隈ではQiitaはオワコン、みたいな風潮が散見されるが、いまだに日本語のプログラミングに関する情報についてはQiitaが量的には一番ではないかと思う。自分の場合には毎回英語を使って調べることが多いので、あまり検索結果上でQiitaに遭遇することはないが。

■ 2019年の抱負

目下次の2点かなという感じ

もっと徹底的に節約する

 まずひとり暮らしをして思ったのは、やはり「ひとり暮らしというのはコスパが悪い」ということ。

 どこで聞いたのかは忘れたが「都内のひとり暮らしは最高の贅沢である」という言葉はあながち間違いじゃないなと思わされた。今住んでいる物件の家賃は8万であるが、もはやこの8万を払っていることすらもったいない。ということで今年は早々に物件を引き払い、千葉にある母親の実家に居候をする形にしようと考えている。通勤時間が伸びたところで、その分自由になるお金が増えるのであれば大した話ではない。単純計算で毎月8万の家賃を12ヶ月支払っているということを計算すれば、毎年約100万円をドブに捨てているということが分かる。ケツを拭く紙にすらなっていない。これは確かに最高の贅沢だ。

本をもっと読む

 2019年にはビジネスモデルや不動産、税に関する知識をもっと深めたいと思っている。

 不動産投資関連の本を読んでいて思ったのは、不動産にまつわる節税スキームは日本の税制の歪みを利用しているものが多いということ。結局それらをうまく利用できるかできないかは、自分自身がどれだけ知識をもっているかにかかっている。不動産に限らず、社会人として生きていく上で比較的重要とされる世の中の仕組みは、そのほとんどが学校で学べるものではないし、知っているかどうかで大きく生き方に差がでるのではないかと思うことが多くなった。ビジネスモデルもまた、社会の仕組みの隙間の落穂を拾うような形で生まれているものがあったりと、相互関係にあると思っている。

Maybeに代えてカスタム型を使う

 ElmのMaybeはデータの有無を型で表現できるゆえ非常に便利なものであるが、文脈が失われるため無闇に使い過ぎるとワケがわからなくなる。ケースによっては、カスタム型を使うことによって型でデータの有無を Maybe に代えて表現するほうがよりメンテナブルにある可能性がある。

前提

 ユーザーログインの機能を持つTODOアプリを開発している。

 上記の仕様から、おそらくモデルに currentUser: User みたいなフィールドと TODO を表す todos: List Todo があるだろうと言うことは容易に想像できる。 だが、実際には「ログインしていない」と「ログインしている」のふたつのコンテキストを表現しなければいけないため、両方とも Maybe になる。ログインしていなければ両方共 Nothing になる。

type alias Model =
  {
    currentUser: Maybe User,
    todos: Maybe List Todo
  }

 正直ここの Maybe は苦しい。なぜならこの Maybe は文脈を持っていないからだ。

 例えば、ログインに失敗して Nothing なのか、純粋にまだ TODO を一個も持っていないから Nothing なのかは、ここでは分からない。 ユーザーがログインに失敗したから Nothing なのか、まだログインしていないから Nothing なのかも、判断が難しい。場当たり的な処置として Result 型を使う手もある。だが、結局文脈をもたない Maybe はコードを書く側が頑張ってその文脈をコード・リーディングしながら紐解いていくことになる。これはまず大変だし、バグを生む可能性がある。

 ではログインにまつわる文脈を持たせましょう、ということで LogInStatus 型のデータを与えると以下のようになる。

type alias Model =
  {
    currentUser: Maybe User,
    todos: Maybe List Todo,
    logInStatus: LogInStatus
  }

type LogInStatus
  = NotLoggedIn | LoggingIn | LogInSucceeded | LogInFailed

 これでモデルにログイン文脈のデータが与えられたが、それでもまだ苦しい。

 それぞれの Maybe の結果は LogInStatus と独立しているため、開発者のうちひとりが LogInSucceeded の状態であるにも関わらず currentUser を Nothing のままにしているなどのコードを書いてしまう可能性がある。ログインが成功しているのにユーザーがいない、というのはまず仕様としてもおかしい。

カスタム型で仕様を表現する

 Elmは型付言語なので、仕様を表現するような型制約を設けるのがよい

 たとえば、以下のようにデータが前提としてログインの状態に紐づくようにすることによって Maybe を使わずに currentUsertodos の存在有無を表現できる

type alias Model =
  {
    logInStatus: LogInStatus
  }

type alias UserData =
  {
    currentUser: User,
    todos: List Todo
  }

type LogInStatus
  = NotLoggedIn
    | LoggingIn
    | LogInSucceeded UserData
    | LogInFailed

 このコードであれば、まずログインが成功していない限りユーザーも、TODOも存在していないということが型レベルで表現されるため、もとのコードにあったような Maybe の結果とログイン状態が食い違ってしまうようなコードを書いてしまうのを防ぐことができる。

2018年で最も早くTypeScript+Reactのアプリを作る方法

結論から言うとこれです。

$ npx create-react-app myapp --typescript

create-react-app で --typescript オプションが公式にサポートされたということで、例えば以下の僕が昔 Qiita で書いた時に使った react-scripts-ts みたいなジェネレータ・スクリプトよりもこのオプションを使うほうがいいかと思います(絶対ダメ! というわけではないけど、公式のほうが安心感がある気がするので)

qiita.com

ちなみにこの --typescript オプション追加の PR は以下です

github.com

ちなみに、この PR で TypeScript のテンプレートが create-react-app の中にコミットされけど、これが react-scripts-ts のコピーなのかどうかは分からない。似てる気はするけど、コメントなどで言及もないしたぶん違うかな。

gpd-pocket-ubuntu-respinの更新を適用したらファンが止まらなくなった

本日久しぶりにGPD Pocketのコミュニティパッチを更新して適用したところ、まだ44℃だというのにCPUファンが思いっきり回転しはじめた

おそらくこれはファン周りのデーモンかなにかがうまく動いてないな...ということでおもむろにログを確認

 $ journalctl -u gpdfand.service 
-- Logs begin at 金 2018-08-24 17:54:08 JST, end at 金 2018-08-24 18:06:16 JST. --
 824 17:54:10 izumisy-gpd-pocket systemd[1]: Started GPD Fan Daemon.
 824 17:54:11 izumisy-gpd-pocket gpdfand[769]: Traceback (most recent call last):
 824 17:54:11 izumisy-gpd-pocket gpdfand[769]:   File "/usr/local/sbin/gpdfand", line 78, in <module>
 824 17:54:11 izumisy-gpd-pocket gpdfand[769]:     set_fans(1,0)
 824 17:54:11 izumisy-gpd-pocket gpdfand[769]:   File "/usr/local/sbin/gpdfand", line 46, in set_fans
 824 17:54:11 izumisy-gpd-pocket gpdfand[769]:     gpio.write(unicode(a))
 824 17:54:11 izumisy-gpd-pocket gpdfand[769]: IOError: [Errno 1] Operation not permitted
 824 17:54:11 izumisy-gpd-pocket systemd[1]: gpdfand.service: Main process exited, code=exited, status=1/FAILURE
 824 17:54:11 izumisy-gpd-pocket systemd[1]: gpdfand.service: Unit entered failed state.
 824 17:54:11 izumisy-gpd-pocket systemd[1]: gpdfand.service: Failed with result 'exit-code'.

変更を遡って見てみると、どうやら以下の変更でIOErrorが起きるようになったっぽい?

github.com

いったんコミットを 7813b8a まで戻して再び更新を適用

$ git checkout 7813b8a
$ ./update.sh

これでとりあえずはファンが静かになった

Golangではinterfaceはどのパッケージに属するのか

Golangを使い始めてinterfaceでDIPっぽいことをしようとするとたしかに湧きがちな疑問のひとつ。結論から言うと、interfaceはそれを使う側のパッケージに所属させるのがセオリーらしい。なるほど。

Go interfaces generally belong in the package that uses values of the interface type, not the package that implements those values.

CodeReviewComments · golang/go Wiki · GitHub

なぜか

せっかくなので理由を考えてみた。

以下はJSONXMLなど複数のフォーマットでログを出力できるロガー・アプリケーションのクラス関係図の例。 このアプリケーションの設計は、中核となるLoggerクラスと具体的なXMLJSONなどへのシリアライザ実装がそれぞれISerializerインターフェースという抽象に依存している典型的なDIP(依存性逆転)だ。LogParamsクラスは、ログとして出力するデータの内容を保持しているものとする。

f:id:IzumiSy:20180819114326p:plain

それぞれ、黒矢印は「利用」、白矢印は抽象に対する「実装」、点線の矢印は「依存」を表している。

まず、このアプリケーションにおいてserializerパッケージというのは「どのように出力するか?」のHowが所属するレイヤであり、一方でmainパッケージはアプリケーションのビジネスロジックとして「なにをするのか?」のWhatが所属するレイヤにあたる。

そう考えると、具体的な実装を持たないinterfaceであるISerializerが、「出力の方法」を責務として所属させるべきserializerパッケージにいるというのは違和感がある。なぜならinterfaceは単なる「使い方」を示すだけのものであって具体的な実装を持つものではないのに、Howが所属するパッケージにいるからだ。このような理由で、interfaceはそれを使う側に配置するのがよい、というプラクティスに合点がいく。

(ちなみにではあるが、そもそもこの関係図だとmainパッケージとserializerパッケージが双方向依存になっているため、Golangではコンパイルの時点でエラーになってしまう)

f:id:IzumiSy:20180819115021p:plain

ということでISerializermainパッケージに所属させる。

パッケージ内での依存関係はいくら循環していようと構わないので、これは問題なく動作する。また、ISerializerインターフェースが実装先のパッケージから切り離された。これで正しく「使う側」に所属させることができた。

DDD的な観点: 例えば今回のISerializerに当たる部分が、DDDでいうところのリポジトリであると考えてみる。そう考えると、リポジトリドメイン層のインターフェースに当たる部分なので、リポジトリの具体的な実装のパッケージにそれが所属するのは解せない、というのがしっくりくる。意図せずここで不思議なつながりが見えた気がする(?)