あんパン

こしあん派

やっていく技術テーマを探す: masawadaの場合

はこべさんのエントリを読んで、自分も今後時間をかけてやっていく技術テーマを探そうと思い立った。まだ本職でWebエンジニアを始めてから2年弱くらいだけれど、自分なりの強みを出せる領域がないのではと危機感を覚え始めたところだった。

アウトラインははこべさんのエントリを参考にしつつ進めた。

ステップ1: 指標を考える

まずは、自分なりの指標を考えた。といっても、結局は元エントリとほぼ同様の指標になった。

  • 指標1: 周辺技術の興味度
  • 指標2: 短期的な役立ち度
  • 指標3: 長期的な役立ち度
  • 指標4: 世間への役立ち度
    • 元エントリでは「Web技術者人気」とあったけれど、世間への役立ち度に変えた
    • Web技術以外の領域でも学んでアウトプットできて世間様の役に立つこともあるだろう、という気持ちをこめている
  • 指標5: 先行者が少ない度
    • ブルーオーシャン度とほぼ同義。

最初はこの他に「手軽に始められる度」という指標も入れていたのだけれど、思いの外ノイジーだったのでやめた。上記の5指標と同様に手軽さの評点をつけると、合計点での順位付けであまり納得感のないリストができあがったため、今回は計算の対象から外して参考値として横に併記するにとどめた。ある程度の係数を設定して合計点への影響度を下げたらもう少しマシになるかもしれない。

ステップ2: 取り組めそうな技術テーマを羅列する

ここでは30項目ほど挙げた。じっくり考えると、いろいろと興味のある分野が広いのだなということに気づいた。意外といろいろと挙がったので、それぞれ横にジャンルを記入してみることにした。今回付けたジャンルは以下の5種類。

  • プログラミング言語
  • 技術・理論
  • 電子工作系
  • 理工系趣味
  • デザイン

技術・理論は結構大雑把な分類だけど、DBやネットワーク、OSの基礎知識だとか、アプリケーションの設計についてだとか、そういうやつにつけた。理工系趣味とはなにかというと、アマチュア無線とかそういうやつ。

ステップ3: 技術テーマにスコアをつける

特に意味はないが、それぞれの指標に5段階でスコアをつけた。結果をみたところ割と同率の値が出たので、やはりフィボナッチ数の方がグラデーションを付けやすかったかもしれない。またあとでフィボナッチ数バージョンも作ってみようと思う。

なお、レーダーチャートは作成しなかった。ある程度どういう点を重視しているのかの傾向は見やすいだろうけど、それがわかったところでどのようなアクションにつなげるか特に思いつかなかったため。もう一手間、重み付けなどの工夫を加えるならチャートを作って傾向を確認するのも良さそうと思った。

感想

実際に作ってみると、なるほどねという思いになる。当然最近の興味が強く反映されるのでほぼほぼ思い通りの結果になったけれど、意外と以前からやりたいと思っていたことの点数が低かったり、特にやりたいジャンルが技術・理論に大きく偏っていることも分かって良かった。これからこの結果を元にサクッとテーマを選んでいきたいと思う。

yarn-outdated-formatter@2.0.0をリリースしました

yarn outdated --jsonを整形するツールの新しいバージョンをリリースしました。

yarn@1.2.1からyarn outdated --jsonの出力形式が変わり、その対応を入れたバージョンです。(id:wadackelさんにPull Requestいただきました。ありがとうございます!) このリリースでyarn@1.2.0までのサポートを落としたので、メジャーバージョンを上げました。

github.com

yarn自体のバージョンを上げるタイミングを逃しがちで、すっかり変更を見逃していました。まるで現代の紺屋の白袴のよう。。

そして丁度会社的に期末期初でバタバタしており、GitHubの通知も見逃して対応が遅くなってしまいました。申し訳ないです。ぱすたくんからのPull Requestもマージしますと言っていてすっかり対応を忘れていた! ので、近日中にマージしてリリースしようと思います。

ところで、Contributionをいただいた時、どこにその旨を書いておくのが一般的なんでしょうか。CONTRIBUTIORS.mdとかAUTHORS.mdとかを作る感じ?またはCHANGELOG.mdあたりにあると良い? npm releaseしてから、そういえば何か書いたほうが良かったなと思い立ったのでした。追記したいので、こうした方が良いなどアドバイスあれば教えてほしいです。

spec/factories以下に正しいfactoryの定義が存在するのにFactory not registered

結論: springのせい、らしい

spec/spec_helper.rbで

Rspec.configure do |config|
  config.before(:all) do
    FactoryBot.reload
  end
...
end

したら直った。もっと良い直し方あるのかなこれ。

spring起因の問題にぶち当たること多くて、世の中のRails使っている人々はみんなこんな思いをして書いているのか気になる。

出典: ruby on rails - ArgumentError: Factory not registered - Stack Overflow

docker-compose run --rm app bundle exec rails cがうごかなかったやつ

これ。

masawada.hatenadiary.com

Dockerfileで

FROM ruby:2.4.2

...

ENV BUNDLE_PATH /bundle

としていたけど、ruby:2.4.2の方はこういう状態で、$BUNDLE_BINがあらぬ方向を向いている状態になってたっぽい？なぜかruby:2.4.1だとうまく行ってたんだけどナ。

正確には、bundler 1.15.4までは大丈夫で、1.16.0からは動かなくなっていた。まだdiff見ていないけどそのあたりでちゃんと各種PATHを見るようになったとか、そういう話かもしれない。

ということで、BUNDLE_PATHを設定するのをやめて、bundle用のvolumeを/usr/local/bundleにマウントするようにしたところ、正常に動かすことができた。