clean architecture 達人に学ぶソフトウェアの構造と設計 を読んだ

- 思想の話
  - xx型プログラムとかは制限を設けているだけ
  - してもいいではなく、してはいけない
- OOPの利点(というより特徴)はポリモーフィズム
  - classA -> classBの関係
  - classBを変更したいだけなのにclassAを意識せざるを得ない
  - oopはinterfaceが使える!
  - classA -> interface <- classB
  - 依存関係を制御できる
- オープン・クローズド
  - 修正に対して閉じていて、追加に対して開いている
- コードの共通化の話
  - 異なるユースケースで同じ処理がある
  - コードを共通化しておくと、Bのユースケースで変更があるとAのユースケースで困ることがある
  - コードが同じように見えるだけで、本当に同じかどうかはわからない
- 不安定なモジュール(class)に対する依存をやめる
  - インターフェイスを作ってそれに依存する
    - classA -> classB(不安定)
    - classA -> interface(安定) <- classB(不安定)
- 循環依存しない
  - classA -> classB -> classC -> classA とか
- 不要なものには依存しない
  - 例 classA -> classB.methodA, classB.methodB
  - もしclassAはclassB.methodBを必要としていないならおかしい
  - これもinterfaceで解決
  - classA -> interface.methodAのみとか
- 修正したいものがまとまっていると良い
- classを変更するときに理由はひとつ
  - コンポーネントを変更する理由もひとつ
  - 単一責任
- 選択肢を残す、決定を遅らせる
  - 方針(ビジネスルール)を決める
  - 詳細(DI何使う? DB何使う?)は決めない
  - 決定を遅らせられれば色々試せるし情報も得られる
- レイヤー
  - 水平レイヤー
    - システム的な部分
    - DB, UI, ビジネスコード, ....
  - 垂直レイヤー
    - ユースケース
    - 注文追加, 注文削除, 編集, ....
- 水平レイヤーでも分割するが、垂直レイヤーでも分割
  - 注文追加のときに削除のコードに影響を与えない
- ユースケース
  - アクターで考える
- ユースケースで分割すると重複コード
  - 今「偶然」同じなだけ
  - まとめる必要は無い
- 重要なものとそれ以外で境界線を引く
  - ビジネスルールが最重要
  - DB, GUIはムシムシで構築できると「決定」を遅らせられる
- マイクロサービスだとかはアーキテクチャにおいて重要ではない
  - サービスとサービスの間に境界線があるわけではない
  - ビジネスルールは横断的
- テストがプロダクションコードを硬直化させてはならない
  - 1個の修正が1000個のテストを壊したら?
  - 誰も修正したがらない
- ハードウェアはすぐに時代遅れになる
  - ソフトウェアは長寿命
  - ハードウェアに依存する(ファームウェアを書いてしまう)とソフトウェアの寿命も決まる

例えばRailsで、Androidアプリで、ってのを実際的には難しいのではと思いながら読んでいた。
`rails new` して、MVCで書いていて、フレームワークに依存してないはずだから
hanamiにすぐに変えられるか、というとうーんとなる気がする。
Androidアプリのコードを書いてて、ハードウェアに依存しないように書いて、
じゃあこれをiOSアプリで書いてと言われたら、うーんとなる気がする。

今までの経験的に、そもそも詳細(ハードウェア、フレームワーク)は真っ先に決まってしまって、
その上で動くコードを書いていたからか感覚と違っている、ように感じる。
例えばrailsであれば、先に素のrubyで、まぁARくらいは使って書いて、
何のフレームワーク使おうか、railsでhanamiで、っていう気持ちに出来れば良いねという感じかな。
なのでビジネスルールのみをコードに落とし込む訓練をしておくと良いのだろうとは思った。

詳細が決定されるのが早い理由は、実際に動いているところを見せる必要があるからかなと。
プロダクトの初期段階だと、そもそも上位の方針が決まっていないので、
プロトタイプを出しまくって方針を固めるってのがアジャイルだとよくあるケースだと思う。
なのでリプレース期とかにはいい気はする。
別にビジネスルールだけコード化して、詳細は後回しすべきとは言っていないので、
普通に開発してく中にも適用することは可能だと思う。

とか書いてたら

- フレームワークと結婚するな

って言葉があった。

テンカツ！セカンドシーズン 2話

前回に引き続いて今回も、forkwellでも一応転職希望で設定しておくと結構来る。
こっちは12件くらい来てるけど、まぁ職歴とかもちゃんと書いてあるわけではないので、 実際に会わないと本当にマッチしているかは分からない。
大抵は興味ない業種なのでお断りしているので残念ではある。

今回は転職ドラフトに登録して、結構指名が来たので楽しい。
あと1日あるけど、滑り込みセーフをかます会社はまぁ無いでしょう。
全部で7件で、基本的にAndroidアプリエンジニアで募集かかってるのが多いかなという印象。

一応、現職でこの数字を見せつつ確認してみるけど、 期待できない感じなら転職かなぁというお気持ち。

正直ここに来て転職どうしようかなという気持ちになっていて、 今回リプレースしてる案件が、時間がなくてFIXMEが多いので それを直したい気持ちが多分にあったり、 多分年俸はかなり上げてくれるはずだけど、 具体的な数字を出してくれていないし、 そこから毎年どれだけ上がるかも不安な状態で ただ転職活動めんどくさいしなぁというのもあって悩ましい。

一応

転職意欲

是が非でも転職する

で登録してしまっていて、それで指名が来ているので 気になるところに話聞きにいくくらいはしていい気がするなぁという感じです。

おひっこし

引っ越しました。

19m^2 から 36m^2 です。

引っ越しが決まったのが11月末くらいで、そこからだらだらと動いてたが、 正直引っ越し完了するまでストレスが半端なかった。年末年始挟んでいるのが悪い。 決めてもう2,3週間くらいで終わらせるのが良いんだろうな。

いくらか物は捨てたがそれでも結構荷物があったので、 またここから捨てたり買い直したりをする必要がある。 というかケトルとか加湿器とか、大した金額じゃないし買い直したほうが良かっただろうな。

沖縄居た時はそこそこ広い部屋で、デッドスペースが気になって 狭い部屋で良いんじゃね?!って思って、安くて狭い部屋に行ったが、 狭いと模様替えとかもしづらくて、物をどかす、というのがしづらいというのは教訓だな。 今回引っ越すときも物を詰めたダンボールが邪魔で掃除が出来ないという状態になっていたし。

ダンボールに物を詰める時、何を入れたか書いてたけど、 優先順位のための番号もつけておいて、 0,1,2,3はすぐ開ける, それより大きいのは後で良い、 みたいな感じでやってたが、結構微妙だった。 多分詰めた順番とか、日付くらいが良いんじゃなかろうか。 ゲーム/CDとか、数あると意外に重いから小さめのダンボールに入れるべきだなって後で気付いた。

テレビを実家に投げたので、また新しく買い直したいがまぁ後で考えよう。 それとは別でディスプレイは欲しいので24~27インチくらいのゲーム用で欲しい。

荷物になるので捨てて来たが、普段MIYOSHIの無添加泡のボディソープ・ハンドソープを使っていて、 これは変な匂いが無く、肌が荒れる事ないし、泡切れも良いので最強なんだが 置いている店が少なくて、目の前にドラッグストアがあるけど、 そこにも無かったので仕方なくアマゾンで買いなおした。

旧居は両隣があって、若干音に気を使っていたが 今回は階に2部屋しか無いのでその辺り心配しなくて良いのが良い。

交通費が、ちゃんと支給されるが、会社の引っ越しも重なっているので、めちゃくちゃ面倒くさい。 一応会社から1ヶ月定期分が毎月出されているんだが、定期が若干ズレていて、1/9までだったので、

1. 1/10~1/15までは手出しで毎回往復400いくらかを出して、
2. 1/17_{2/18までは1ヶ月定期で買って、(会社としては1/17}1/31までの実費の交通費を支給)
3. 2/18~2/22の往路分までまた手出しで出して、(これをどうするのか謎)
4. 2/23からまた定期を買う? (多分会社としては2/22の帰り分から2/28までの実費の交通費を支給, その場合通常の1ヶ月定期分が同計算されるのか謎だが)
5. 3月から1ヶ月分定期分を支給

定期の払い戻しをググったけど、https://ssl.tokyometro.jp/support/faq_answer?lang=ja&faqno=OpenFAQ-000449 この書き方だと0ヶ月数日は1ヶ月への繰り上げなんじゃねーかなと。 それに手数料とかアホくさいなと思って手出しだったが、どうするのが最適解なのか全く分からん。 多分区間変更とかもあるんだろうけどなぁ。

今回の引っ越しの反省から得た教訓は

• 年末年始とか挟まない時期にしろ
• 内見のときにカーテンのためのサイズ図っとけ
• magicplan使って帰って配置考えろ
• 物はガンガン捨てろ
• 引っ越しは2回(2日)くらいに分けてやれ
• 引越し先決めたら出来る限り早く引っ越せ
• 前日にガス止めろ、1日風呂入らなくても平気
• 契約書は事前に送ってもらえ (面倒くさい客扱い・契約書書き直させられるかは謎)
• ネット回線がどうなってるか確認しろ
• ダンボールに入れた順番と日付つけろ

年末なので

今年どんだけ働いたか調べたかった。

✗ git log --numstat --pretty="%H" --author='iaia' --since=2018-01-01 --until=2018-12-31 --no-merges | awk 'NF==3 {plus+=$1; minus+=$2} END {printf("%d (+%d, -%d)\n", plus+minus, plus, minus)}'

コマンドの意味はわかってない。

• Railsプロジェクト1
  • 41730 (+29195, -12535)
• Railsプロジェクト2
  • 3660 (+2699, -961)
• Androidプロジェクト1
  • 479 (+473, -6)
• Androidプロジェクト2
  • 51385 (+35883, -15502)
• staticなプロジェクト
  • 84957 (+30280, -54677)

主な仕事はRailsプロジェクト1とAndroidプロジェクト2なので、約10万行か。
staticの方はなんでこんなにあるのかよくわからん。

テンカツは転職ドラフトでresume通ったので、1月入札が楽しみやな。
それを持ってとりあえず現職で給与交渉してみて、そんなもんかってなったら転職する方針で。

それと、今年はrubyとvimのイベントに参加したので、OSSに貢献したい感がある。
一応2個プルリク送ってマージされているけど、もっと頑張るか。
qiitaにも記事を書いた。https://qiita.com/iaia/items/a3348b466de1fc9e5ba6

今年は70kg切るようにするという目標があったわけですが、まぁちょっと無理かな。
これはまぁそろそろ頑張らないとという思い。

引っ越しは今年やるとか言ってたが、一応来月引っ越しなので許容範囲内。
転職するつもりなのでちょっとあれだけど。

テンカツ！セカンドシーズン 1話

辞める意思は伝えたので。 今の仕事が3月には終わっているはずなので、3月末で辞めるかなくらいの考え。

元々今の会社に来たのは

• ToCの自社サービスをやっている
• Railsを触れる
• 希望すればAndroidも触れる
• 普通の一般的な開発スタイルができる

あたりが理由だった気がする。

で、なぜ辞めるか。

• そもそももっと前に辞めるつもりだった
  • 入ってみたら意外と経営がヤバイ状態だったので沈む前にやめよう
  • 少なくとも1年の経験を得てからにしよう
  • Androidアプリの開発手伝って！ -> (ユーザ操作があるアプリを作ってなかったので)ぜひともやりたい
  • アプリリリースまで続けよう
• それなりに実績・経験は積めた
  • まだだけどアプリリリースとか
  • もうどこの会社行ってもそれなりに働けるんじゃね？くらいの自信を持てたという意味
  • この会社でやれることは一通り出来たという認識
• 仕事は増えてくが給料は据え置き
  • Railsエンジニアでやってた時はそれなりに仕事やってた時は普通に満足だった
  • Androidもやり始めの時は問題なかったが...
  • 「最近Rails側のリソース足りないので手伝ってくれない?」のパターンが増えてきた
  • 都合よく使われている感が否めない
• ディレクター陣との考え方の違い
  • あの仕事を早めにやらないと残りの仕事が出来ない -> issue作れてません -> ディレ陣で確認作業が... -> エンジニアの仕事ありませんのパターン
  • 単純にディレ陣人数少ない割に仕事が集中しすぎていて忙しい
  • とりあえず文句は言うだけ言うが管轄外のディレ陣の話でそれなりに思惑はあるし一理あるし...
  • でもそれ1日で終わる仕事じゃない? というのにも安全策を巡らせて1ヶ月は掛けてる仕事もあるので、改善すべきだなと思う
• 子会社化
  • 親会社の要求でシステムにアホな設計を入れないで欲しいとはお願いしていた
  • 例えば「ウチが使うときには、XXXの機能は表示させるな(or ウチだけに表示しろ)」「UX悪くてもXXXを必ず表示させて訴訟リスクを減らす」とか
  • 赤字なんだし、仕事やるからと上で言ったみたいなことをやらされる
  • これ、文字化するのが難しいがどうしても自分にはやりたくない仕事
  • これが多分言いたいことを書いてくれてると思う
• この会社はどこを目指してるのか?
  • これが割と重要な気がしている
  • 子会社化して創業者がやめて...
  • 会社としての理念が消えてしまった
  • 新規事業立ち上げの話もあったが、辞める気だし特に案を出す理由ないし...
• 給料上げる上げない問題
  • 創業者やめた時点で、新しい目標・理念、新しい評価基準の2点の話が持ち上がった
    • 独自に目標・理念を持って、ただの下請け企業にならないようにする
    • 評価基準を設けて達成度合いで給料を上げられるというモチベーションを生み出す
  • この話が出る前ではそろそろ辞めようと思っていたが、この話が出て居続けても良いなと思えた
  • 実際100万単位で給料上がりそうだった
  • そういう期待を持たせられた状態で、突然のキャンセル
  • 親会社と色々あったらしいが、私には「お前ら赤字だろなのに何言ってんの」というのが印象に残る
• 1on1の結果
  • 給料上げる上げない問題があったあとに色々1on1が組まれた
  • 確かに仕事の割に給料低いよねという相互認識
  • でも親会社が給料にはうるさいので...という弱い立場
  • 4月になったら上げられると言われても...
  • 黒字に出来たら立場も変わってくる -> 従業員が弱い立場で我慢し続ける理由とは
• もう辞めるからはいはい言っておくか状態になっている
  • これは自分と会社どちらにも良くない

次の会社は自分たちで儲かっている企業が良いですね。 転職ドラフトで引っかかるのを待ちたいが、何せレジュメがrejectされるので辛い...。 こういう自分の評価って難しい。

vimconf 2018

vimconf 2018 聞きに行きました。

- いつもどおりの遅刻する感じ
- 外人と一緒に迷子
- wifi のパスワードどこにあるんやってキョロキョロ
- 英語の発表、通訳無しでそのまま聞けるようになれると良いですねと思いました
- vimがweb severになるとか、高速化したかったら高性能PC買えよとか、面白い話多かった
- 結構コアな部分の話も多かったので、いくつかキーワードを頭とブラウザに保存して、家に帰ってから調べたりする感じで
- あとpluginが100個以上とか多かったな
- 次のバージョンで入れたい機能とか、ワクワクする感じで良かった
- 個人的にOniとvim.wasmは聞いておきたかったので良かった
- 聞いてるとplugin作ろうという気分になれる
- 昼飯(今半のすきやき弁当)美味い
- After Party行けば良かったと思いつつも、なかなかああいう場だとぼっち感を演出してしまうので早々に退出

vim関連に貢献したいとは思ってて、よく使ってる vimagit にPR送ったりもしたけど、
今後も何がしかできるといいですね。

ビューワー

本棚のウェブアプリが欲しくて、まぁこんなのを作ってある。

作品のviewer部分は操作しないと分かりづらいのでスクショは撮らない。よく考えたら18禁なだったのでモザイク。
dmmは同人を電子で買うと、サークルによってはjpg, pdfでもダウンロードできるようになっている。上の画像はそれ。

要件的には

- 本一覧の表示
- 本をお気に入りできる
- 履歴を表示
- 著者、サークル、タグが設定できる
- 本情報を編集できる
- 本のページを見開きで表示
  - モバイルでも操作可

とかとか。そもそもこれを最初に作ったのは4年くらい前か。
sinatraで第一弾を作って満足してたんだが、段々ファイルが増えてきてもうsinatraの領分では無いのでは?
という気がして、railsの勉強がてら作りなおそうというのが第二弾。
その後、色々勘所が分かってきて、勉強の試行錯誤の後とかかなりゴミが溜まっていて、
今の知識ならもっとキレイに作れる！という気持ちで作ったのが第三弾。
その後転職して、railsを業務で使えて、テストもかけるようになったし、
第三弾までは見た目が非常に悪かったのを今ならキレイに書ける！という気持ちで作り直したのが第四弾(現行)。
実際、第四弾は1週間くらいでテスト含めて実用できるレベルまで作れた。
その後もチョコチョコ修正を加えてより便利になっている。

でまぁ最近、komifloというのが出てきて、俺が作ってるやつやんけと思い使ってた。
どうにもビューワーがゴミで、俺の作ってるやつで不満点を解消させてやろうという決意をした。何が駄目かと言うと、

- 作品ごとに読み込み
  - シコってる時に「THE END」と出てくる謎仕様
- 複数作品を一気に読めない
  - シリーズものはとか、間に余計なものは要らない
- 先頭のページに戻るのがだるい
- 作者の作品一覧からだと並び替えが出来ない
  - シリーズ物が3->2->1という順番でしか連続で表示できない
- 星マーク(お気に入り)とハートマーク(Like)の違いが意味不明

で、自分のviewerで改善策を実装してみた。

スクショ...は分かり辛いのでやめた

OnTheGoとかネタみたいなModelを作ったが、プレイリストを作って作品を全部連結させてるだけ。
実際全部の表示には時間かかるが、その日その日のオカズはたかだか10作品程度しかないはず(1作品20ページとして200枚の画像、1ページ2MBと考えても大したことない量)で、lazyloadしているから特に待ち時間は発生しないし、重くても一度読み込んでしまえばどうでも良い問題。
シリーズ物は間に「THE END」みたいなエロゲの中出し外出し選択肢みたいな余計なものは無く、スムーズにシコれる。
更に、ループ機能をつけているので、4作品目の最後のページが右にあって1作品目の最初のページが左にある状態が作れるので便利。作品ごとの並び替えは当然できる。
一つ問題があって、プレイリストを表示後に、別タブで別作品をプレイリストに追加したり、プレイリストの並び順を変えると、
プレイリストを表示しているタブで再読込みする必要があり、大量の画像をまた読み込むハメになって辛かったので、
imgタグを全部最新のものとreplaceする機能もつけた。画像は既にブラウザが持ってるので差分だけ引っ張ってくれる。次の日にシコるときにはプレイリストを削除する運用。

komifloのビューワも良いところはあって、

- 見た目が素敵
- その作品の一覧がサムネで見れて移動できる
- その雑誌の作品一覧が一覧で表示できて移動できる

この辺は真似したくて、いい加減ピュアなjs,css(sass)の小手先だけだと辛いので、
せっかくなのでviewerを独立させてAngularDartで作りたい。