🏷️

Twitter技術記事ブクマの棚卸しログ

2022/12/24に公開約3,200字

年中こういうことはやってるものの毎回途中で挫折する & 途中途中にあるめっちゃ面白い記事などを読んだ後にすべてを忘れてTwitterに戻りTLパトロールしてしまうので、実はちゃんと棚卸しできた試しがない……ので、さすがにやっとくかと思い立ちました。
クリスマスにやることではないんだよなぁ


API 設計: gRPC、OpenAPI、REST の概要と、それらを使用するタイミングを理解する

https://cloud.google.com/blog/ja/products/api-management/understanding-grpc-openapi-and-rest-and-when-to-use-them

GoogleのAPI設計に関する記事。REST APIだと思っていたものはOpenAPIの仕様だったのか、、
ちゃんと読まないとわからんので個別で勉強します

フロントエンドエンジニアのステップアップのための集合知

https://hackmd.io/1hwucZmcTAG5k4G9o5Szeg

初歩的なセキュリティバグを生まない

これちゃんと出来ますか?って言われると結構自信ない
逆にミドルで「できてほしい」に位置づけられている要件は意外とここ2年でマシになった感がある 『成長』ってやつかネェ……(鼻こすり)

いまの会社がジュニアメンバーにも意思決定をかなり委ねている(し、それに足る業務ドメイン理解とコミュニケーションを職務として要求している)ので、モノによってはシニアの要件も一部カスってる感がある
それでいうとフロントエンドエンジニアというより事業会社におけるエンジニアの、って感じがするな

『マッド・ハイジ』

https://twitter.com/Munenori20/status/1605513409516015621?s=20&t=gKsvPCx_ad8VfZ22NSdB6w

チーズ系ファシストに支配されたスイスが舞台。闇チーズ製造罪で恋人のペーターを処刑され、おんじも家ごと爆破、さらに収容所で出会ったクララまでヤク(チーズ)漬けにされたハイジの復讐劇が始まる…!

意味がわからん でも観たい

クックパッドマートの失敗したデータ設計 Before / After 大放出

https://speakerdeck.com/mokuzon/after-da-fang-chu

物理在庫ロジシステムをつくることの大変さを弊社システムで痛感している身としては、2億回くらい首を縦に振りながら読まざるを得ない内容
配送待ちの格納判定、倉庫の作業者さんが置いてそれを記録するのではなく、システム側ですべて振り分けまでやってるんだ〜〜すげ〜〜! オペレーションミスなった場合地獄そうだなあ どうやってるんだろ

つらくなったらすぐ作り直しを検討していくことで、新規事業にとって重要な初速と長期運用に必要な品質のバランスを取っている

これ実現するために設計当初どういう業務ドメインの集約つくったよ、こういうの意識するといいよ、みたいな知見はかなり貴重そう サクラダファミリア化を見据えた拡張性高いドメインモデリング、知りたい

複雑なコマンドパイプラインを簡単に組み立てる方法

https://gihyo.jp/admin/serial/01/ubuntu-recipe/0723

外部サービスから取得した結果に基づいてユーザー抽出したり、そこからSQL書いたり〜みたいなのを自動で出力するためのスクリプトが作りやすいのだろうなと解釈 だいぶ良さそうだが経験浅ゆえにユースケースがピンとこない、、

状態、結合、複雑性、コード量の順に最適化する

https://ohbarye.hatenablog.jp/entry/2022/01/31/state-coupling-complexity-code

CAの新卒研修資料に『良いコードとはなにか』みたいなのがあり、その記事を新卒(去年)めちゃ読んで意識してたけど、ことしはこれを意識した。

初心者のプログラマがコード量を削減するのは、4つの基準の中で最も見つけやすいから

去年の自分はコード量削減のために過度な共通化してしまいハタから見ると何のために使われるコードなのかわからなくなったりしていた記憶。怪文書みたいなPR出しちゃって突っ込まれて枕を濡らす夜もありました(ありません)

  • 業務ロジックとか関係なく、こういう入力に対してこんな出力をお約束します!みたいな状態になるまでできる限り分解しとくこと
  • どれだけ関数名や分岐が長くなろうと、そうしないことでわかりづらくなる場合は許容する

みたいな、当然だけど大事なことを意識すると、変かも……と思ったときに価値判断しやすくて良い
SOLID原則やDRYに書くみたいな話ではある あやふやだけど合ってそうな感覚に名前を付ける & そうでない部分を可視化するためにも、改めてそういう基本的な原則には目を通したいところ

なぜ我々はユニットテストが書けないのか?

https://note.com/shift_tech/n/ne17f3fab6a05

TDDに限らないですが、始めるコツは完ぺきにこだわらないことです。メソッドの規模や重要度は気にせず、まずは分っている要件をちょろっと書き出して、それをNGからOKに変えるところから始めることです。

なんちゃってTDDみたいなことやり始めてから本当にバグへの不安減ったし開発に迷いもなくなってても早く動くようになった。あれは良いぞ

カバレッジの話なにもしらない(原則100%テスト通ってないと世に出せない世界でいきているので、カバレッジが低いことを許容されること、その指標が示すところがぴんとこない)なあ

腹筋

https://twitter.com/momo_diet_159/status/1547548865150205957?s=20&t=gKsvPCx_ad8VfZ22NSdB6w

マジできついし効く ただし腰にもくる

Value Objectパターンの話

https://bufferings.hatenablog.com/entry/2022/05/17/010943

value object、validかつ不変であることを保証する系のやつかと解釈していたので不変の話が二の次っぽいの意外だった
value Objectにまつわる知識はもっと仕入れたい 解釈がゆるい

その他

まだ読めてない、、、けどかなり有用そうなので共有がてら。

Discussion

ログインするとコメントできます