mmyoji’s blog

web 開発以外の日常に関するブログ

Twitter

最近自分のメインの Twitter アカウントと少し距離を取ってしまっていてどうしたものかなと考えている。

基本的には web dev 関係のことを呟くようにしたいなと思ってはいるものの、大体が文句だったり記事のリンクを貼るくらいしかなくて、それなら別にやらなくていいかとなってしまっている。 文句なんて言い出したらキリがないし、別に書いても仕方ない(ポジティブな効果があるなら別だが)。 リンクを貼る行為も別に自分が tweet する必要性を感じないし、自分のためなら Pocket で十分なので、せいぜい個人用 esa に軽くまとめる程度で自己完結している。 Twitter で何か言及すると変なのに絡まれるリスクもあってそんなところで消耗したくないというのも多分にある。

reader 目線でも最近は特にキツイなーと感じるようになった。コロナネタはどうでもいいが、自分含め TL の老化が進んでしょうもないネタやダジャレに疲れたり、「それわざわざインターネットで言う必要ある?」みたいなのが見ててつらくなってきた。昔の Twitter の使い方に対して抵抗を感じているんだと思う。 また政治的な発言や主張は全然していいし、自分と異なるスタンスの人の意見などは見るべきだとは思うが、自分はそれを Twitter に求めてないように感じる。

Twitter 上でしかつながってない人もいるので辞めるのはそれはそれで面倒くさいのでとりあえず放置しているが、フォロワー整理くらいはした方がいいかもしれない。 以上感想文でした。

去年の振り返り

2019年はほぼフリーの傭兵業をした。 前半は真面目に Rails 開発の手伝いをして、そのあとは前回の記事に書いたように TypeScript, GraphQL, React, k8s な環境で少し働いた。

1~6月

mmyoji.hatenablog.jp

上記記事にも書いているので若干被る点があるかもしれない。

2019年前半の Rails 開発では、主にリファクタリングやパフォーマンスチューニング、依存している古いソフトウェアからの脱却などを行った。 負債がたまっている割に社内に Rails をわかっている開発者がいない現場だったので自分がやっている対応がどの程度理解されているか怪しかったし、 今後も維持されるかは正直自信がないがそれなりに改善できた気はする。 コミットメッセージに色々書いてきたので後からまともな人が何かの手違いで入ったら察してもらえると信じている。

個人的に経験できたよかったことは、 MySQL で数億単位のレコードが格納されたテーブルを触ったことはなかったので それくらいのサイズになるとどういう点に気を付けないといけないか(そもそもそんなになる前に対応しろよという話はあるが)を 考えることができたこと。

逆に言うとそれ以外は時間の許す限り Rails-way に乗せることをひたすらやっていた気がするが、メンバーがあのままだとまたすぐダメになるだろうなという気もしてる。 Rails を採用するのはいいが、その場合は組織内でちゃんと FW や OOP の勉強をちゃんとやるなりアドバイザーを雇うなりして、持続可能な開発を続けられる体制を作ってほしいと思う。 個人的にはさすがにもう組織で Rails を使うのはいいやという気持ちになってしまったので、今後はそれ以外の道を模索したいと思う。

7~8月

2ヶ月間だけだったが、前職(厳密に言うと前々職)の元同僚から「正社員として入ってほしい」というオファーをもらって、 「様子見したいので最初は業務委託で」と言って手伝った会社。

開発メンバー自体はめちゃくちゃ優秀でよかったんだが、結局その人たちも経営陣と対立(ここら辺はあまり詳しくは聞いてない)してて辞めるという話になってたり、 自分もその経営陣とはやっていけそうもなかったのですぐに辞めた。

がっつり TypeScript を触る時間が作れたのが良かったし、 k8s にも触れることができたので学ぶことが多い環境だったのがよかった。 こっからはしばらく ts ばかり触ってて、個人でも大体 ts で開発することが多くなった。

9~11月

この期間は仕事する気力もなかったのでひたすらゲームしてた気がする。 知り合いの会社を遊び半分で手伝ってて、そこのホームページのような web app をよくわからないサービスに HTTP でホスティング(しかも PHP)されているのを、 Firebase + TypeScript + Nuxt.js に置き換えることを少しだけやってたくらい? 脆弱性ありまくりの酷いサイトだったので、世の中こんなものを作る人でもお金もらえるんだなーと逆に感心した。

いい加減引っ越しをしたいのと東京から脱出したかったので10月半ばくらいからフルリモートができる仕事を探し出した。 引っ越しの契約のことを考慮して基本正社員で探したが、意外と日本には完全フルリモートができる会社は少なかった。 GitHub などにそういう職をまとめている人もいるが、フルリモートの定義が各社異なっており、「一切出社しなくていい」という条件の会社は本当に少なかった。

その中で給与はガッツリ下がってしまったがよさそうな会社が見つかって無事採用面接をパスできたのが11月半ばくらいのこと。

12月~

1月半ばで1ヶ月半ほど経つが未だに出社はしてない(最寄り駅は知っているがオフィスがどこにあるかはちゃんと把握してない)し、今のところ出社する必要も なさそうなので引っ越しによさそうな時期(5~6月頃?)になったら東京を出てどこか適当なところに住もうと思う。

ただ結構主要そうなメンバーの退職が重なっており若干先行きが不安な気もしているのでそれまでに状況が変わる可能性は全然ある。

web app 開発がメインだしそういうポジションで入って、 app 周りの機能開発やら修正やらもやっているが、「興味があれば SRE 的な立ち回りをしてほしい」と言われて 興味がないわけでもなかったのでそういうタスクもちょいちょいやっている。 ガッツリインフラに時間を割くことは今までそんなにやってなかったが今のところ結構楽しんでやっていけてる。 ビジネスドメインの知識がそこまで要求されないし、他社に行っても使えることを勉強しながら仕事ができるというのはとてもやりがいがあるし、 やったことを個人 esa にまとめるのも楽しくて業務時間外でも色々と勉強したいことが増えて充実している。

問題なくなって地方に移住した場合、それが人質になって退職しづらい、みたいな状況にならないかが少し懸念点ではある。 今後フルリモートOKな会社が増えてくれることを期待するしかない。 もしくは何かしら他に収入を得る方法がないか日々考えている。

今年もよろしくお願いします。

最近は TypeScript とか k8s とか

やっているという話。

以前同じ職場だった人からの依頼で手伝ってるスタートアップが全部 JS (TypeScript) という今までそこまでやってなかった技術スタックでなかなか楽しい。

フロントが React+TypeScript というのは最近は割と多いと思うが、 Native app に RN, backend も Node.js (TypeScript) で front <-> backend の通信は GraphQL, インフラは k8s を使っててそこらへんも少し触らせてもらったりして色々と勉強になった。

TypeScript は前から少し触っていたがやはり VSCode のサポートが至れり尽くせりといった感じでとても楽ができていい。

k8s で一通り遊んだ感想としてはもうすべてこれになってくれという気持ちしかない。個人的には Heroku, Cloud Run あたりで十分になる世界の方が嬉しいが

GraphQL server 兼 ORM に Prisma を使ってて色々と便利だが、 Prisma2 がもうすぐ出る(ガッツリ変わる)とか吐かれている SQL の生クエリが見えないとか「正気か?」と思うことがいくつかあって個人的には使いたくはないかなと思えたのは良かった(?)

開発メンバーは自分より優秀な人しかいなくてとても良いが、経営陣その他が結構残念なので2ヶ月で契約終了する予定ではあるが久しぶりに刺激がもらえて楽しかった。

お仕事の依頼等が来たら話を聞いたりはしているが、とりあえず今年はもう十分働いたと思うのでダラダラと半ニート 1 生活をおくろうと思う。

半と書いたのは突発的に仕事が出るケースがあるからだが理想的には全ニート希望

全然関係ないけど今の仕事終わったら Windows Preview 版にして WSL2 有効化して色々遊びたい


  1. 厳密に言うと NEET ではないがここでは無職という意味で

開発者の淘汰について

(タイトルがあまりよくない)

日々チーム内でコードを書いてて、プログラマという職業内でここまで個人差が出るものかと悲しくなることが多い。 思うにこの業界は仕事をする上で特に資格も必要なければ、時間がかかろうがクソコードだろうが何かしらのアウトプットを出したり、 それが上司にバレなければ、正しく評価されることは(少なくとも日本では)稀で、生き延びられる。

最初から資格が必要で、それを取得するのに一定のコストがかかるなら自分は開発者になれていなかった可能性はあるのでそこを狭めることは避けたいが、 ある程度キャリアを積んだあと(例えば2年その職種に居続けた場合など)は何かしらの試験を課して、それをパスしなければ別の職種に移らないといけない、 というような仕組みがあればいいんじゃないかとふと思った。(特に深くは考えてないので悪しからず) 別の職種に移るのが嫌なら再度試験を受けてパスするまでがんばるか、コードを書く仕事は週に数時間までしかやってはいけないなど成約を設ける。 ただ「正しく評価する」試験を作るのが相当大変な気もするので、そこのコストと世の中のコードがキレイになり得られるメリットのどちらが大きいか という点が問題になってくると思う。

個人的な経験で言うと、本当にどうしようもない開発者というのは各職場に1~3人くらいはいて、その人達の尻拭いをすることは多々あり、 最初からその人達がコードを書かずに自分が担当していたらもっと開発が早く進んでいたし、今メンテナンスしやすいコードを保てていただろうな と感じることは多かった。『人月の神話』を令和になった今でさえ読んでない、理解していない経営者や採用担当は多くて、とりあえず人数いれば開発が 進むと思っている連中は多い。そのせいで不利益を受けてきた・受けている開発者は少なくないように思う。

微妙な開発者A, B, Cをそれぞれ500万で雇うのと、優秀な開発者Dを1,200万で雇うなら後者の方がいいというのは開発者ならわかると思うが、 採用段階で本当に優秀かどうかは判定が難しい(採用コストをそれなりにかけられるなら話は別)し、その人が辞めるリスクというものも当然存在する。 リスクヘッジという意味では300万余計に払うのは安いのかもしれないが、比較的不利益を被ってきた側としては無能な開発者がチームにいる状況は避けたい。 無能な、と書きはしたが教育枠として経験が浅いメンバーがいるのはいいと思う。ある程度キャリアを積んでるはずなのに初心者かな?と感じるレベルの人間が 一定数(それも少なくない数)いるという現状を批判しているだけである。

Twitter でつぶやいたところ、以下のような意見も頂いたが、評価者がアレなせいで開発チーム全員が辞めてほしいと思っているフリーランスが 居続けている現場というものを知っている分、評価者側の教育もないと思うようには進まないと思う。

特にまとまりもないが、ふと思ったので書いてみた。

2019年前半やったこと

2018年末に社員から業務委託に契約を切り替えた仕事が6月末でようやく契約終了となるので、やったことを振り返っておく。

正直何も大したことはしてないので焦るために書く。

これを書いている時点ではまだ終わってないが、基本もう終わったようなものなので?過去形で書いている。

働き方

業務委託で週4稼働、フルリモートで週1の PM/PO的なポジションの人との MTG があり、進捗及び次にやることの確認を行った。

大体朝の9:00~10:00頃から作業を開始して、約8時間稼働することが多い。

(法律的にはグレーだと思うが)毎日日報をつけることを強制されていたため、やったことなどを書いた。

一日大体1~3本くらいの pull-request を出して、他の人のコードレビューなどもした。

Slack や GitHub を眺めてて実装に困ってそうな人がいたら変わりにコードを書いたりもした。

Rails アプリケーションがメインなのでひたすら Rails / Ruby を書いた。

やったこと

サービスが5~6年ほど続いており、その間に開発者も何度も入れ替わっており、溜まりに溜まった負債を返済することが自分の主なミッションだった。

簡単に箇条書きで挙げていき、コメントすることがあれば後に書く。

  • 規約から外れたファイル・クラス名の修正
  • カスタム Rubocop gem のリファクタ、公開準備
  • Rubocop の TODO 対応
  • Rails-way に沿ったアプリケーションアーキテクチャにする
    • app/ 以下の独自レイヤーを消す
  • Rails の機能をちゃんと使う
    • ActiveRecord の validation, relation の活用
    • strong parameter を使う
    • JSON の組み立てに ActiveModelSerializer を使う
    • etc.
  • Resque -> Sidekiq 移行
  • Rails の upgrade: v5.0 -> v5.1 -> v5.2
  • 開発環境用に Rails を docker 化
  • 不要なコードの削除: okuribito_rails, debride などを利用
  • switch_point を正しく使う
  • composite_primary_keys の廃止
  • 論理削除 -> 物理削除移行
  • N+1 の解消
  • メモリ使用量改善
  • seed データの整備
  • テストの整備、リファクタ
  • etc.

規約から外れたファイル・クラス名

12~今年の3月頃まで少しずつ進めてきた大きなものとしては、 Rails の規約に従ってないファイル・クラスを rail に乗せることだった。 該当クラスを一つ一つ autoload に渡して読み込むためのファイルが存在し、それを廃止した。

具体的に言うと app/models/foo/bar.rb というファイル名なら Foo::Bar というモジュール名になるべきだが、なぜか Models::Foo::Bar みたいな謎の名称になっているファイルが山のようにあった。

一気に全部置換してしまうと他の feature branch で conflict 解消するのが大変だし、コードレビューも大変だったのでスキを見て少しずつやった。これは単に grep して地道に置換していくことが大半だったので根性で対応した。

Rubocop 周りの整備

社内でカスタマイズされた rubocop の設定が onkcop 的な感じで gem として存在していたが、 rubocop の version が古かったり上書きしているルールの根拠がよくわからないものが多かったので、最初はその gem の repository に pull-request を投げまくった。

自分でカスタマイズする場合は上書きしたルールだけ列挙すればいいと思うのだが、なぜか rubocop がデフォルトで設定しているルールまで設定ファイルに書かれており、まずはそれを整理するところから始めた。

また後からその gem を社外に公開できるようにしてほしいと頼まれたので、その整備もした(なぜかまだ公開されていない)

その後は長年放置されていた .rubocop_todo.yml に挙がっている TODO を解消するという仕事をした。

正直途方もない量があり、 auto correct で対応できないものがかなり多かったのでこれも diff が大きくなりすぎないように少しずつ進めた。

例えば Metrics/ClassLength などが 600 行以上に設定されていたりと非現実的なルールになって rubocop として意味をなしていないルールが大量にあったが、それをもう少しまともな値に戻すところまでは完了した。

残りはそこそこのリファクタリングを伴うものが多いので、地道にリファクタリングを進めている。

Rails-way に沿ったアプリケーションアーキテクチャにする

app/ 以下に app/repositoriesapp/entities など「DDD ちょっとかじりましたw」みたいな頭の悪いレイヤーがいくつもあり、今いる開発者から苦情が出ていたのでそういうのを廃止していく作業などもした。

Rails らしいコードに直す

長年 GitHub Issues に上がったままだが特に対応されてないものを見ていくと、 Rails で用意されている機能などを使わず自前で書いたせいで引き起こしている bug が無数にあり、 Rails っぽい書き方をしてあげることでそういった bug を潰したり、コードのクオリティ(この言い方が適切かは不明)をあげたりした。

ActiveRecord の validation, relation あたりがまったくといっていいほど使われてない、と言えばどれだけヤバイかは伝わると思う。

API サーバーとしての機能も持っているが、 JSON レスポンスを組み立てる際に controller で Hash をこねくり回すのが基本となってしまっており、それを ActiveModelSerializer を使うようにしたりとかもやった。ただ、同じリソースでも index と show でレスポンスがまったく統一されておらず、下手に共通化すると分岐が多すぎて逆に汚くなる、というケースがあったため、あえてクラスを別にして整理したりした。ここらへんは仕様の変更等、関係者が増えるので後々色んな方にがんばってほしい。 Hash をこねくり回すよりはマシ、という判断で serializer 化を進めた。JSON を組み立てるための gem は jbuilder をはじめ、いろいろあり個人的には何を使ってもいいと思っているが、既に一部で使われていたので serializer を使った。

Resque -> Sidekiq 移行

もともと非同期処理に Resque を使っていたが、 Sidekiq に移行したいと言われたので、移行を行った。そもそも非同期でやる必要があるのか?的な処理も結構な数あり、そういったものは同期処理に直したりした。

switch_point を正しく使う

DB の書き込みは master, 読み取りは read replica へと切り替えるための gem を使っていた。

書き込み直後のレコードを読みに行って replication 遅延でレコードが無い、みたいなエラーが頻発しており、見つける度に直したが、これも relation をちゃんと使っておけばわざわざ取得し直さなくても、メモリ上にあるオブジェクトをそのまま使える、などといった低レベルなものが多かった。

例えば以下のような感じ

# in a controller

# User に紐づく Post を作成 (master への書き込み)
# ご丁寧に?クラスメソッドでわざわざ定義されている
Post.create_my_post(current_user, xxx)
# ここで read replica へ読みに行って、まだ replication されてなくて違う post が返る
current_user.posts.last


# 単にこれでいい
post = current_user.posts.create!(xxx)

実際は無駄にもっと複雑で一目でわかりづらいものもあったが、大体このレベルだった。

使っている gem のドキュメントや実装をまともに読まずに使わないということをキャリアの初めの頃は何度かしてしまったが、そういうことが普通に起きている現場だった。

Rails の upgrade

Rails の version を 5.0 -> 5.1 -> 5.2 に上げ、まったく更新されていなかった各種 gem を更新したり、使われなくなった gem などを消したりもした。

これはもう色んなところでやってある程度知見が溜まっているので、 Rails upgrade 業的なのをスポットでやりたい。

その他

体感でソースコードの6~7割がクラスメソッドとして定義されており、そういった処理も Rails らしいコードに書き直して潰していっている。クラスメソッドとして定義されてしまっているせいでとにかく引数のバケツリレーが酷く、 OOP を何も理解してない人がコードを書くと百害あって一利なしだなと思った。大体 scope 的なものや、 relation を使う形に直せばそもそも無くていいようなメソッドなども大量にあった。

以上のように、最初から普通に RailsRuby, OOP をちゃんと勉強して書いていれば発生しない業務が大半なので、初期のメンバー選定は技術選定以上に重要だと改めて思った。

次以降の仕事はもう少し価値のあることがしたい。

WSL 環境の見直し

最近は基本的に WSL 環境で仕事をしていて、つい先日 WLinux -> Pengwin に変わったことで色々と対応が必要になったのでそれについて。

docker を middleware のみの使用にしたことは こっち で書いた通り。

仕事で使っている Ruby の version が 2.4 系なのが功を奏した?のか、 WLinux + linuxbrew 環境でも rbenv 経由で ruby を install できていたが、プライベートプロジェクトで 2.6 系を使用していてそれでハマった。

結果として linuxbrew を捨てることで(おそらく厳密に言えば linuxbrew 経由で install された readline or openssl のせい) 2.6 系も install できた。

ruby-build のログを見てもあまりわからなかったので確証は持ててないのでアレだが、結局 apt と linuxbrew の二重管理状態になってしまっていたので捨てて良かったと思う。ログでは libssl1.0.0 がどーのこーのと言ってた。

自分が依存している package が基本的に apt で入るものが多く、そこまで使用頻度は多くないが apt だと入らず installation に少し手間がかかるものに関しては一緒に捨てた。

また WSL に限らず neovim の plugin 管理に dein を使っていたが、 plugin を update する毎に configuration がうまく読み込まれず( cache のせい?)何度も nvim を再起動する必要があるのが地味にめんどくさかったので vim-plug 管理に戻した。 .vimrc ( init.vim ) ファイル1個で管理したかったというのもあるので個人的にはこっちで必要十分だと思ってる。

docker が中途半端にしか使えないのが地味に不便なので今の仕事が終わればまた Linux (Ubuntu) 環境に戻るかもなーという気もしている。

仕事の話

無事?6月末で契約を終了することができそうなので今年も夏休みを取ってダラダラしようと思う。普通に仕事を取ってしまうと 900 万を超えて税金が増えてしまうのでそれを調整するためにも少し時間を置いてから仕事を再開したいなと思っている。日数少なめで仕事を取れればそっちがマシ。

最近また Ruby が好きになってきているので Ruby の仕事を取りたいなーと思うが Vue.js でフロント書いたり Go で API サーバー書くのも良さそう。

リモートの仕事を見つけられるといいけど。

Linkedin をやめた

タイトル通りだが今朝アカウントを消した。

基本的にエージェントからしか連絡は来ないし、「こういうメッセージ以外は対応しませんよ」とプロフィールに書いていてもそれを読まずに送ってくる連中が少なくは無くてそれにうんざりしたのでカッとなって消した。

海外からのオファーが無くは無かったが当然魅力的なものは少なく、

  • CS の学位すら持ってない
  • 有名な OSS プロジェクトを持ってない

ような開発者はさすがに相手にしてくれないんだろうなぁと思った。

逆に CS の学位を持っていればもう少しまともなメッセージが来たのかどうかはわからない。 あくまで知り合いに聞いた話だと別に...という感じなので遅かれ早かれやめてたと思う。


全然関係無いがこないだ parcel-bundler の website を日本語に翻訳する issue が荒れてて話題になった。

英語との言語距離(日本語が正しいかわからない, Linguistic Distance)が日本語ほど離れてないであろう人間が「英語を勉強して英語が読めるようになればいいだろ」なんて言うのはあまりにも酷いなと思った。

普段の開発でも極力英語のドキュメントを読むように心がけているが、度々「自分がネイティブだったら今頃もっとイケてる開発者になってるだろうな」と感じる程度にはヘイトは溜まっている。

自分は外国語学習が楽しいと感じる方なのでまだマシだが、そこに楽しみを見出だせない開発者は本当に気の毒に思う。

ほとんど試したことがないのでほぼ妄想だが、現状だと読む際には Google 翻訳を使って、書く時には「機械翻訳がキレイに動くための日本語」を意識して書くのが一番効率がいいのかもしれない。話す・聞く部分に関しても Google Home がリアルタイム翻訳をサポート的な話が最近あったと思うのでそういうのを極力利用するのが良さそうに思える。

もちろん「機械翻訳がキレイに動」いているのを誰が確認するか問題は生じるが。