ハイライト 2023-03-15

OKR GraphQL Pagination SoftwareDesign

Articles

Measure What Matters Summary

fourminutebooks.com

youexec.com

改めてMeasure What Mattersを読むにあたって要約記事を見てみた。

Additionally, team members should create half of their own OKRs to promote engagement. Tracking progress is also important, and feedback and recognition are needed to help everyone reach their goals

自分ごとにどうするかという点と、どのようなインパクトが組織にあるのかがうまい具合に噛み合わさると良いんだろうけど、それがふわっとしたまま進むと悶々とした存在になってしまう傾向がある気がする。

How to Implement Cursor Pagination Like a Pro

medium.com

In conclusion, please, please for the love of God, do not concatenate your cursors, especially if you are dealing with large sets of data.

複雑なフィルタリングとソートが必要なエンドポイントの場合どうするんだ？って思ったけど、そもそもカーソルページネーションをやめるという選択肢もあるんだということは納得できた。カーソルで行きたいがためにconcatしちゃうのは、やっちゃいそうな予感。。。

Tweets

A Philosophy of Software Designまだちゃんと読めてないので読みたい。

"Use the Stereotypical Levels of Design"

responsibility-first なアプローチ。すべては：

  • a role
  • with responsibilities
  • that collaborate

Applications are just neighborhoods of abstractions playing roles, filling in responsibilities and collaborating with each other

ハイライト 2023-03-08

React Testing CSS Authorization Engineering

Articles

Title: Testing-Library でユーザの気持ちになって書くフロントエンドのテスト

zenn.dev

data-testid で一昔前までフロントエンド側はテストやりまくっていたので、accessibilityも考えて、あるべき姿にDOMを構成していくことが大事だと改めて認識。 Semanticがキーですね。

Ditching useState and useReducer: Why useImmer is the better option

dev.to

useImmer を使って useState と useReducer から開放されてみようっていう話。使ってみたいけど、依存を増やすこととのトレードオフですね。

Product Pulse #4: New directory and authorizer, evaluator, and more!

www.aserto.com

AsertoのTopazによるOPA+Zanzibarな権限ソリューションは気になっているのですよね。

www.topaz.sh

Engineering growth: framework overview

oreil.ly

Mediumが提唱しているエンジニアのキャリアパス。役職はなんだかんだで意味がある、ということ。

CSS Style Queries

ishadeed.com

Container size queriesはパラダイムシフトだなぁ。Media Queryよりだいぶいい感じに使えるような気がする。

Books

The Staff Engineer's Path - 2. Three Maps

learning.oreilly.com

組織内で何が重要なのかを理解することの重要性について、3つのMapを描くと良さそう。

  • A Locator Map: You are Here
    • 自分の位置づけを把握する
  • A Topographical Map: Learning the Terrain
    • 組織内の地形を把握する（政治的な部分やトラブルが多そうな箇所など）
  • A Treasure Map: X Marks the Spot
    • 宝地図のXにめがけて近づいているのかどうかを把握

Videos

Team Topologies, Cognitive Load & Complex Systems | Matthew Skelton In The Engineering Room Ep. 12

www.youtube.com

全部をコントロール下に置くことを目指すのではなく、コアな部分で意思決定をすることにフォーカスすべきと。また、意思決定するにあたっての指針を提示しておくと良さそう。ある程度の制約も設けることで、より意思決定はしやすくなる可能性もある。

Tweets

素晴らしいイベントでした。そして以下の内容も要ブックマーク。

scrapbox.io

unsatisfied は抽象的な概念にも使える。 dissatisfied を同じように使うと不自然になる。

ハイライト 2023-03-03

Management TechnicalDebt GraphQL

Articles

uxdesign.cc

  • Author: Megan C.
  • Full Title: Is Offset Pagination Dead? Why Cursor Pagination Is Taking Over

Offsetページネーションに一昔前までかなり慣れていたけど、これからは基本的にはCursorページネーションを意識しておいた方が良さそう。そしてOffsetページネーションってパフォーマンス悪いってことに気づいていないことに気づいた。Cursorページネーションするときには、Cursorを何にするか、という設計が大事。

stackoverflow.blog

  • Author: Chelsea Troy
  • Full Title: Stop Saying “Technical Debt”

「技術負債」と漠然と言うのではなく、もっと具体的なスコープに絞り込まないと誤解を生みやすいというような話。例えば保守作業と機能開発に割り振られている時間の比率などを計測すると良さそうだ、など。

Books

learning.oreilly.com

  • Full Title: Introduction

Staff Engineerの3つの柱

  1. 俯瞰力（Big-picture thinking）
  2. プロジェクトへの実行力（Execution）
  3. 他のエンジニアの成長促進（Leveling up）

Tweets

Domain Modeling Made Functionalはバイブルとなりつつある

ハイライト 2023-02-22

Management TechnicalDebt

Articles

shopify.engineering

  • Author: John DeWyze
  • Full Title: The 25 Percent Rule for Tackling Technical Debt

技術負債を以下の4つのカテゴリに分ける。業務の25%は技術負債にあてられるようにして、それぞれ以下の比率でハンドリングすると良さそうだとのこと。

  • Yearly Debt -> 5%
  • Monthly Debt -> 5%
  • Weekly Debt -> 10%
  • Daily Debt -> 10%

www.jointaro.com

Performance Improvement Plan というのを初めて聞いた。PIPといえば認可におけるPolicy Information Pointが思い浮かびます😅 パフォーマンスが出ていない人との関わり方は難しい問題ですね。

Tweets

トレードオフですよね。このあたりをさくっと議論できる環境にいるとやりやすいイメージ。

空気を感じたときには「I'll get out of your hair」使えるようになるぞ。

ハイライト2023-02-15

AWS EventBridge DDD GraphQL

Articles

aws.amazon.com

EventBridge Pipesを使ったアーキテクチャのパターンをわかりやすく解説してくれている。

  • Content filter pattern
  • Message translator pattern
  • Normalizer pattern
  • Claim check pattern

Books

learning.oreilly.com

  • Author: Scott Wlaschin

  • Full Title: Domain Modeling Made Functional

  • Long Running Workflows

    • Sagaパターンの解説
  • Functions, Functions, Everywhere
    • 関数型の思考について

For example, say that we have a large program that is assembled from smaller pieces.

• In an object-oriented approach, these pieces would be classes and objects.

• In a functional approach, these pieces would be functions.

Or say that we need to parameterize some aspect of the program, or we want to reduce coupling between components.

• In an object-oriented approach, we would use interfaces and dependency injection.

• In a functional approach, we would parameterize with functions.

Or let’s say that we want to follow the “don’t repeat yourself” principle and reuse code between many components.

• In an object-oriented approach, we might use inheritance or a technique like the Decorator pattern.

• In a functional approach, we put all the reusable code into functions and glue them together using composition.

GraphQLのProduction Readyな設計のプラクティスがよくまとまっている本。

Tweets

They want buttoned-up types who can keep secrets.

秘密を漏らさない口の堅いタイプを欲している

buttoned-up/down な表現は初めて知った。

ハイライト 2023-02-08

ai ChatGPT SSR Next.js WASM Testing Architecture React

Articles

collabnix.com

AIからは解をもらうというより、探すためのヒントをもらうっていうのはその通りだなと。なので結局ある程度のスキルは必要だとは思う。

deno.com

There are many benefits to moving the work a browser does to render a website to the server:

• Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded.

• Compatibility is higher with server-side rendering because, again, the HTML is generated on the server, so it is not dependent on the end browser.

• Complexity is lower because the server does most of the work of generating the HTML so can often be implemented with a simpler and smaller codebase.

フロントエンドエンジニアとしてカバーすべき範囲は広くなってきた感じはする。Backbone.jsだったりAngular.jsのころは本当にフロントエンドのことだけ考えたりしてましたから。

blog.codecentric.de

  • Author: Julian Arz
  • Full Title: Compile Once, Run Anywhere With WebAssembly and WASI

WASMでビジネスロジックをフロントエンドも含めてポータブルにするというのは次世代感がある。

github.com

ベストプラクティスありすぎだけど、Arrange, Act & Assert (AAA) は布教したい派。

jasonformat.com

Islands Architectureは結局のところmicro-frontendsのことかと思ったんだけど、micro-frontendsはどうやらHTMLに限った話では無いらしい。

qiita.com

  • Author: Qiita
  • Full Title: React18でuseEffectが2回走っちゃう件

useEffectは2回走っちゃってもちゃんと動くコードを書きましょうねという話。

zenn.dev

  • Author: Zenn
  • Full Title: 私の推しフロントエンドディレクトリ構成と気をつけたいポイント

機能を軸にしてディレクトリ構造を考えるのは自分も好き。「機能の粒度をエンジニアだけで考えない」という観点はとても大事だと共感。

mugi1.hateblo.jp

  • Author: memo_md
  • Full Title: 規模感の違う脱レガシーで必要なこと

一人で隣町まで行っただけなら帰り道も辿れそうだが、みんなで宇宙に行ったら簡単には地球には帰ってこれない。ちゃんと次の惑星に辿り着かないといけない。撤退という選択肢がどこかのタイミングで難しくなってくる。

表題と上の引用がグッとくる。バイブルにしたい内容。

martinfowler.com

  • Author: Martin Fowler
  • Full Title: Modularizing React Applications With Established UI Patterns

AuthorはMartin Fowlerになってるけど、実際はJuntao QIU氏が書いた記事。フロントエンドのアーキテクチャについて非常に勉強になる内容。気になるのは、今後はコンポーネントのそばにデータのfetchを入れていくアーキテクチャになっていきそうだということ（Next.jsで語られているcollocated data fetching）。この点とも合わせて今後注目したい。

beta.nextjs.org

Tweets

overestimateも頭をよぎったりした。さらっとoverstatementだったりunderstatementを使えるようになりたい。

ハイライト 2023-02-01

JavaScript AWS Authorization oso GraphQL DDD CQRS

Articles

qiita.com

実は、「 innerHTML を用いて挿入された script elements は、挿入時にはその内容が実行されない 」ということ自体は 正解 です。 これは W3C にもきちんと記されていることです。

Note: script elements inserted using innerHTML do not execute when they are inserted. (出典: W3C. "2. The Document Object Model". W3C. 2008 年 10 月 6 日. https://www.w3.org/TR/2008/WD-html5-20080610/dom.html#innerhtml0

このあたりは無知。

www.osohq.com

  • Author: osohq.com
  • Full Title: Authorization Patterns in GraphQL

My advice on building authorization in GraphQL applications usually boils down to these rules of thumb:

  1. Build your authorization logic as close to the data as possible, ideally within your GraphQL API.
  2. Custom Directives and Middleware are both neat ways to do this while keeping your authorization logic decoupled from your schema – but only if you only have a single GraphQL API.
  3. API Gateways can work if you need a single solution for multiple GraphQL APIs at once, but they can limit the types of rules you will be able to write.

GraphQLにおける認可のアーキテクチャについてとてもよくまとまっている記事。

logmi.jp

  • Author: ログミーTech
  • Full Title: 「フロントエンドのテストは“不安定さ・壊れやすさ”との戦い」　和田卓人×倉見洋輔×古川陽介が語る、アクセシビリティの重要性

Storycapやreg-cliは初めて知りましたが、これを活用すると脱Chromaticできる？

github.com

アクセシビリティが高い＝テスタビリティも高い

www.ex-it-blog.com

確定申告も近いし、支払調書について割とわかってなかった中出てきた記事。

www.geekly.co.jp

「正しそうなことを言うけどわかっていなそうな人」じゃなくて、「ちゃんとコードを書ける人」というところを頑張って維持したい。

DDDとCQRSの話も聞けて非常に面白い。子育てと自己研鑽の両立の難しさの話もとてつもなく共感。

Tweets

一時的なテスト環境とステートフルなサービスのプラクティス。確かにAWS上でやるなら毎回作ったり消したりは現実的じゃない印象。

英語のDo you know〜とDid you know〜の話。ミスパロさん最高です。