ハイライト 2023-03-03
Articles
- Author: Megan C.
- Full Title: Is Offset Pagination Dead? Why Cursor Pagination Is Taking Over
Offsetページネーションに一昔前までかなり慣れていたけど、これからは基本的にはCursorページネーションを意識しておいた方が良さそう。そしてOffsetページネーションってパフォーマンス悪いってことに気づいていないことに気づいた。Cursorページネーションするときには、Cursorを何にするか、という設計が大事。
- Author: Chelsea Troy
- Full Title: Stop Saying “Technical Debt”
「技術負債」と漠然と言うのではなく、もっと具体的なスコープに絞り込まないと誤解を生みやすいというような話。例えば保守作業と機能開発に割り振られている時間の比率などを計測すると良さそうだ、など。
Books
- Full Title: Introduction
Staff Engineerの3つの柱
- 俯瞰力（Big-picture thinking）
- プロジェクトへの実行力（Execution）
- 他のエンジニアの成長促進（Leveling up）
Tweets
Domain Modeling Made Functionalが従来のドメインモデリングの書籍と一線を画すのは、「ドメインエキスパートとよく対話してモデル作っていこうな！」で留まらずに、型の粒度の設計指針を明確に打ち出していることです。
— kawasima (@kawasima) 2023年2月25日
そしてその本質は8章のTotal Functionsにあります。
Domain Modeling Made Functionalはバイブルとなりつつある
ハイライト 2023-02-22
Articles
- 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%
- Author: Taro Blog - Software Engineer Career Growth
- Full Title: I Just Received a Performance Improvement Plan (PIP) -- What Should I Do?
Performance Improvement Plan というのを初めて聞いた。PIPといえば認可におけるPolicy Information Pointが思い浮かびます😅 パフォーマンスが出ていない人との関わり方は難しい問題ですね。
Tweets
One trick to speed up the launch time for your MVP is to ignore all the edge-cases. 💡
— Michael Lin (@_michaellin) 2023年2月20日
This means focusing on the “happy-path”, where you assume the user does everything right, and not guard against user errors (eg typos in an intake form). ⬇️
トレードオフですよね。このあたりをさくっと議論できる環境にいるとやりやすいイメージ。
ドラマを見ていると I'll get out of your hair. というセリフに遭遇するかと。直訳すると「(あなたの) 髪から出ていく」なのでややわかりづらいのですが、「もうこれ以上、邪魔しない」といった意味。大体は他人に仕事を中断させた後で「邪魔したね」といった感じで、立ち去り際に発されます。1/3
— Mystery Parrot (ミスパロ)🦜 (@ParrotMystery) 2023年2月18日
空気を感じたときには「I'll get out of your hair」使えるようになるぞ。
ハイライト2023-02-15
Articles
- Author: David Boyne
- Full Title: Implementing Architectural Patterns With Amazon EventBridge Pipes
EventBridge Pipesを使ったアーキテクチャのパターンをわかりやすく解説してくれている。
- Content filter pattern
- Message translator pattern
- Normalizer pattern
- Claim check pattern
Books
- 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.
- Author: Marc-Andre Giroux
- Full Title: Production Ready GraphQL
GraphQLのProduction Readyな設計のプラクティスがよくまとまっている本。
Tweets
button-down shirt は、襟の先にボタンがついたシャツ。ブルックス・ブラザーズ創立者がポロ選手の襟が競技中にはためくのを見かねて考案したと伝えられています。が、ビジネスカジュアル定番の装いであることから、今や buttoned-down という表現は、「まじめ」「保守的」「堅物」の代名詞に。1/4 pic.twitter.com/4B5fiE0Aux
— Mystery Parrot (ミスパロ)🦜 (@ParrotMystery) 2023年2月12日
They want buttoned-up types who can keep secrets.
秘密を漏らさない口の堅いタイプを欲している
buttoned-up/down な表現は初めて知った。
ハイライト 2023-02-08
Articles
- Author: Ajeet Raina
- Full Title: Can ChatGPT Debug and Fix All of Your Docker and Kubernetes Issues?
AIからは解をもらうというより、探すためのヒントをもらうっていうのはその通りだなと。なので結局ある程度のスキルは必要だとは思う。
- Author: Andy Jiang
- Full Title: Back to the SSR
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のころは本当にフロントエンドのことだけ考えたりしてましたから。
- Author: Julian Arz
- Full Title: Compile Once, Run Anywhere With WebAssembly and WASI
WASMでビジネスロジックをフロントエンドも含めてポータブルにするというのは次世代感がある。
- Author: goldbergyoni
- Full Title: Goldbergyoni / Javascript-Testing-Best-Practices Public
ベストプラクティスありすぎだけど、Arrange, Act & Assert (AAA) は布教したい派。
- Author: jasonformat.com
- Full Title: Islands Architecture
Islands Architectureは結局のところmicro-frontendsのことかと思ったんだけど、micro-frontendsはどうやらHTMLに限った話では無いらしい。
- Author: Qiita
- Full Title: React18でuseEffectが2回走っちゃう件
useEffectは2回走っちゃってもちゃんと動くコードを書きましょうねという話。
機能を軸にしてディレクトリ構造を考えるのは自分も好き。「機能の粒度をエンジニアだけで考えない」という観点はとても大事だと共感。
- Author: memo_md
- Full Title: 規模感の違う脱レガシーで必要なこと
一人で隣町まで行っただけなら帰り道も辿れそうだが、みんなで宇宙に行ったら簡単には地球には帰ってこれない。ちゃんと次の惑星に辿り着かないといけない。撤退という選択肢がどこかのタイミングで難しくなってくる。
表題と上の引用がグッとくる。バイブルにしたい内容。
- Author: Martin Fowler
- Full Title: Modularizing React Applications With Established UI Patterns
AuthorはMartin Fowlerになってるけど、実際はJuntao QIU氏が書いた記事。フロントエンドのアーキテクチャについて非常に勉強になる内容。気になるのは、今後はコンポーネントのそばにデータのfetchを入れていくアーキテクチャになっていきそうだということ（Next.jsで語られているcollocated data fetching）。この点とも合わせて今後注目したい。
Tweets
言葉や評価がやや過剰だと言いたいとき、英語ではよく That's an overstatement. と表現します。statement は主張、前に over (超える) がつくことで「それは (実際を) 上回る主張」→「言いすぎ」となるわけです。この表現には、割に感情を排除した淡々とした響きがあるので、職場などでも便利。1/3
— Mystery Parrot (ミスパロ)🦜 (@ParrotMystery) 2023年2月6日
overestimateも頭をよぎったりした。さらっとoverstatementだったりunderstatementを使えるようになりたい。
ハイライト 2023-02-01
Articles
- Author: Qiita
- Full Title: JavaScript / TypeScript の豆知識 10 選
実は、「
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
このあたりは無知。
- 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:
- Build your authorization logic as close to the data as possible, ideally within your GraphQL API.
- 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.
- 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における認可のアーキテクチャについてとてもよくまとまっている記事。
Storycapやreg-cliは初めて知りましたが、これを活用すると脱Chromaticできる？
アクセシビリティが高い＝テスタビリティも高い
- Author: EX-IT 効率化で独立を楽しく
- Full Title: Amazonが支払調書の古き慣習・誤解を打ち破った件
確定申告も近いし、支払調書について割とわかってなかった中出てきた記事。
- Author: geekly.co.jp
「正しそうなことを言うけどわかっていなそうな人」じゃなくて、「ちゃんとコードを書ける人」というところを頑張って維持したい。
DDDとCQRSの話も聞けて非常に面白い。子育てと自己研鑽の両立の難しさの話もとてつもなく共感。
Tweets
一時的なテスト環境とステートフルなサービスのプラクティス。確かにAWS上でやるなら毎回作ったり消したりは現実的じゃない印象。
I'm a big fan of using temporary environments when I'm building serverless architectures. As a practice, it combines well with the pay-per-use pricing model of serverless components.
— Yan Cui (@theburningmonk) 2023年1月31日
But what do you do when you have serverful resources like RDS?
🧵
英語のDo you know〜とDid you know〜の話。ミスパロさん最高です。
自分の知っている情報を相手も知っているか確かめたいとき、「～知ってる？」と尋ねたりしますね。なので、同じことを英語で表現する際、日本人は Do you know ~? といった文を作りがち。が、このように言った後で、自分の既知情報を共有すると、ネイティブは微妙に困惑してしまうのです。1/5
— Mystery Parrot (ミスパロ)🦜 (@ParrotMystery) 2023年1月29日
■
SwitchBotのスマートロックを、指紋認証つきのキーパッドと一緒に購入しました。
ちゃんと設置できるか不安はあったものの、特に迷うことなく取り付けることができました。ハブとAPI連携できるという情報も聞いていたので、ついでにハブの方も購入。
IFTTT連携も簡単にできそうだということで、設置後にさっそく検証してみました。IFTTTの「IF」にSwitchBotを選択すると、ロック関連の項目が2個見つかります。
英語、日本語という違いだけでおそらくどちらを選んでもOKです。デバイスに関しては自分のロックのデバイスを選択します（自分の場合「ロックFA」）。
どのようなときにトリガーするか、というところで「ロック状態」が選択できます。選択できる状態は以下4つ：
- 施錠済み
- 解錠済み
- ドアが開けられた
- ドアが閉められた
今回は解錠のときのAPI連携をしてみました。IFTTTの「THAT」の部分にはとりあえずSlackを設定してみます。
例えばMessageのところに埋め込むこのとできる情報は CreatedAt と Contentでした。 Content には何が入るのでしょうね？
SwitchBot のアプリの方を覗いてみると、履歴のところで以下のように「どの認証方法で解錠されたか」がわかるようになっています。
「これは期待できる！」と思ってさっそく検証してみたところ
残念ながら {{Content}} には何も値が入っておらず undefined でした。。。
下記ドキュメントを参照しても、そのような情報は現時点では渡って来ることは無さそうですね。
{ "eventType": "changeReport", "eventVersion": "1", "context": { "deviceType": "WoLock", "deviceMac": DEVICE_MAC_ADDR, "lockState": "LOCKED", "timeOfSample": 123456789 } }
「どの認証方法で解錠されたか」の情報があれば、例えば子どもたちに登録した指紋でフィルタリングしてSlackに通知するようにできそうですね。 例えば留守にしないといけない状況で子どもが先に家に帰ってきたときなど、通知が飛んできてくれたら少し安心できそうです。
今後に期待したいですね。
ということでスマートロックを購入したのでAPI連携の検証をしてみた話でした。
Stripe Checkoutを使ってみたのでTipsを残しておく
Stripeを仕事で使うことになり、いろいろと調べたことを忘れないうちにアウトプットしておこうと思います。尚、これは執筆時点の仕様に関するもので、今後変わる可能性は大いにあります。
2022/02/17更新
とてもありがたいことにStripeの中の人にアドバイスをいただくことができたので、ところどころ記載内容をアップデートしています。
ちょっと記事でanswerする時間が今日なさそうなので、ツイートでとりあえずインライン回答。https://t.co/SblZapax9C
— hide@Stripe Developer Advocate 🐈🐈🦓🥑 (@hide__dev) 2022年2月15日
- Stripe Checkoutはフロントエンドだけで使える？
- Stripe Checkoutのページにいい感じに消費税は表示できる？
- サブスクリプションな商品の場合、途中でプラン変更した場合などの支払いはどうなる？
- サブスクリプションの期間の調整はStripeの管理画面からできる？
- Stripe Checkoutで買った商品（サブスク）の支払い方法の変更はどうやってやる？
- Stripe Checkoutで申し込んだお客様に飛ぶメールの言語はどうなる？
- 決済が発生したときにお客様とStripe User双方にメールは飛ぶ？
- Stripeのメタデータに設定できる量に制限はある？
- priceIdはテスト環境から本番環境に引き継がれる？
Stripe Checkoutはフロントエンドだけで使える？
一応Stripe CheckoutにはClient-only integrationというものがあります。
ただし、Stripeからも非推奨と言われています。以下の制限が主な理由です。
- カード支払いのみがサポートされています。
- Coupons、Discounts、Promotion Codes、Tax Rates の各 API には対応していません。
- 既存の Customer オブジェクトを使用した 1 回限りの支払いの作成はサポートされていません。
- 請求前のカードの売上の保留はサポートされていません。
- 1 回限りの支払いと継続支払いを 1 回の取引で行うことはサポートされていません。
- Connect プラットフォームは、連結アカウントに代わってこの組み込みを使用することはできません。
- Stripe Tax はサポートされていません。
全部痛いのですが、特にクーポンが使えないことと、Tax ratesやStripe Taxが使えないのが致命的だったのでClient-only integrationは僕はあきらめました。
使い方については以下が参考になります。
Payment Linksについて
フロントエンドだけでどうにかできないかと思い、Payment Linksについても調べてみました。こちらはクーポンやStripe Taxも使えていい感じです。
ただし、Stripe Checkoutで扱える情報以外にも保存しておきたいものがあったため（お客様の会社名とか備考とか）、フロントエンドだけで使うのはどのみちあきらめました。
特に細かい要件が無ければPayment Linksでいろいろと足りそうです。
Stripe Checkout client-server integration
フロントエンドだけでは無理そうだとなったら、client-server integrationを使います。こちらはサーバーサイドでセッションを作って、もうちょっといろいろとごにょごにょできるようになります。
Stripe Checkoutのページにいい感じに消費税は表示できる？
作りたてのアカウントではいい感じには表示されません。商品に消費税を設定しましょう。手数料が許容できるのであればStripe Taxも検討した方が良いですし、推奨されています。
Dynamic Tax Ratesというものあるのですが、残念ながら日本はまだサポートされていません。
サブスクリプションな商品の場合、途中でプラン変更した場合などの支払いはどうなる？
スタンダードの1年プランみたいなものの2ヶ月目とかでプレミアムプランに切り替えたとき、お金の扱いがどうなるか。あるいはプレミアムからスタンダードに切り替えたときはどうなるのか。
このあたりは「比例配分」の話で、Stripeが「いい感じにやってくれる」仕組みがあります。
サブスクリプションの期間の調整はStripeの管理画面からできる？
サブスクリプションの周期を変えたくなるときが出てくるかもしれません。そんなときはTrial期間をうまく使うみたいです。
Stripe Checkoutで買った商品（サブスク）の支払い方法の変更はどうやってやる？
1度買ったら終わりな商品はあまり関係ないのですが、サブスクリプションだとカードの期限が切れたりします。その場合に支払い方法をどうやって変えれば良いのか。
そこで使うのがCustomer Portalです。
お客様用の専用ページを作って、そこでお客様に自分自身で変更してもらいます。
注意点として、Customer PortalはStripeのテスト環境だと、 管理画面からサクッと見ることができる のですが、これはあくまでプレビュー用＆テスト用のものです。
本番用のCustomer PortalのURLはAPIを使って発行する必要があります。セキュリティの観点から、URLの有効期限もシビアなので気をつけましょう。
新しいポータルセッションは 5 分後に期限切れとなります。顧客がその期限内にセッションを使用すると、そのセッションは最新のアクティビティの 1 時間後に期限切れとなります。各ポータルセッションは、最大 2 時間まで有効です。
Stripe Checkoutで申し込んだお客様に飛ぶメールの言語はどうなる？
Stripe Checkoutで商品を購入すると、例えば領収書がメールでお客様に送信されます。このメールの言語はどのように決まるのか。
まず、Checkoutのページには locale を設定することができます。ここで en とすれば英語のページなりますし、 ja にしたら日本語のページです。 auto にすると、ブラウザの言語で自動判定してくれます。
で、Checkoutのページの言語でメールも飛んでくれるかと思うかもしれませんが、そうはなりません。
何も考えずに実装すると、Stripeで設定している「顧客のメール」の「デフォルトの言語」で送信されます。
これをどうにかいい感じに切り替わるようにしたければ、Customerオブジェクトをあらかじめ作って、 preferred_locales を設定する必要があります。
ただし、Checkoutのページから顧客が「キャンセル」した場合にCustomerオブジェクトのゴミが作られちゃう問題などがあるため、よく考慮して実装する必要があります。
2022/02/17追記：
直接この問題とは関係が無いのですが、Customerオブジェクトのデータがたくさんできちゃう問題に対処するには、ゲスト顧客を検討するのが良さそうです。メールアドレス、電話番号、カード番号から、顧客をグルーピングしてくれるいい感じな機能です。
決済が発生したときにお客様とStripe User双方にメールは飛ぶ？
設定によって飛ばすことができます。注意点として、Stripe User側は、ユーザー毎に設定が必要です（全体設定ではない）
Stripe Userとしてのメール通知設定について
お客様に送るメールの設定
テスト環境では自動メールは飛ばない
注意点として、領収書などの自動メールはテスト環境では飛びません。領収書に関してはStripeのダッシュボードから送信できるので特に問題は無いのですが、Stripe Userにどういうメールが飛ぶのかというのが本番でしか確認できないのはちょっとつらいです（特に自分が誰かのためにシステムを作っている場合）。
この場合は本番でしか確認する方法がありません。領収書付きで確認したい場合、日本では最低価格50円のサブスクリプションを作って、実際に決済するしかありません（現時点では。サポートに確認済みです）。自分のクレジットカードを使うのに抵抗があるかもしれませんが、ひとまずあきらめましょう（実はいい方法があれば知りたいです）。
いろいろと事情があるようで、メールのサンプルについてもサポートから開示してもらえなかったので、決済してみてのお楽しみです。
Stripeのメタデータに設定できる量に制限はある？
- 50 keys（40 characters long）
- 500 characters long values
Stripeが標準で保存する情報の他に、プラスαで保存したくなる情報があります（会社名とか備考とか）。それにはStripeのメタデータが使えるのですが、これにも一応制限があるので注意が必要です。
priceIdはテスト環境から本番環境に引き継がれる？
Stripeはあらかじめテスト環境と本番環境を用意してくれていて、非常にテストがしやすいDevExになってます。ただ、ちょっとつらかったのが、テスト環境で使っていたものをそのままシームレスに本番環境で使えるわけではない点です。
テスト環境の商品を本番環境にコピーするのはとても簡単です。「本番環境へコピー」というボタンをポチッと押すだけで本番にコピーされます。ただし、このときに priceId などのIDの値は変わります。
ドキュメント に以下のような記載があったので、IDも引き継げるのかと期待したのですが、どうやらこれはPlanIdに特化したもので、基本的にはIDは変わるものとして設計する必要があります。
今は非推奨（？）なPlanに関しては、確かにIDを設定するAPIがあります。
~IDが引き継げるとめちゃくちゃDevExは向上しそうなのですが、このあたりはあきらめてツールを駆使してあまり意識しなくても良いようにしましょう。~
2022/02/17追記：
この問題は検索キーを使うことで解消できるようです。検索キーとpriceIdを関連付けて置くことで、フロント側が意識するキーをテスト環境も本番環境も同じものにしておくことができそうです。
