AWSで実践するカオスエンジニアリング 〜ZOZOMOでの取り組み〜 - ZOZO TECH BLOG
はじめに こんにちは、ZOZOMO部OMOバックエンドブロックの長野です。普段はZOZOMOのサービスであるブランド実店舗の在庫確認・在庫取り置き（以下、店舗在庫連携）の開発・保守を担当しています。 店舗在庫連携はAWS上にシステムを構築しており、システムにはAWSの各サービスを利用しています。AWS上で構築するシステムは、マルチAZなどの冗長構成をとることで可用性を高めることができます。しかし、実際に障害が起こった際に、意図していなかった箇所でシステムが停止してしまう可能性は否定しきれません。 OMOバックエンドブロックでは、このような未知の障害を防ぐためのアプローチとしてカオスエンジニアリングを実施しました。本記事ではカオスエンジニアリングの説明とチームで行った結果を紹介します。 目次 はじめに 目次 カオスエンジニアリングとは 1. 定常状態を定義する 2. 仮説を立てる 3. 実験
GitHub Copilot Enterprise のススメ
GitHub が GitHub Copilot Enterprise というサービスをはじめました。かなり革命的なのですが、とにかく高い。利用するには一人 60 ドル/月 (GitHub Enterprise Cloud 21 ドル/月 + GitHub Copilot Enterprise 39 ドル/月)かかります。なので、気になってる人向けに実際に使ってみて何が嬉しいのかを雑に書いてみます。 Pull-Request サマリーの自動生成GitHub の Pull-Request を出すとき、レビューして貰うためにこの Pull-Request の変更点を整理して書くと思うのですが、これを自動生成してくれます。 https://github.com/sile/pixcil/pull/2これは弊社の社員が個人のリポジトリで GitHub Copilot Enterprise の機能を利用
E2EテストでNextAuth認証(OAuthなど)を突破する方法
NextAuth (Auth.js) で認証させているWebアプリをPlaywrightなどでE2Eテストする際に、認証をどうやってさせるか、あるいは回避するかが悩ましい部分です。 もし採用している認証方式が、単純なID/パスワード認証であればテストユーザを作成し、Playwrightにパスワードを入力させれば認証できるので問題はありません。 しかし、Google認証などの外部のプロバイダを経由するような場合は、E2Eテストをすることが難しくなります。そこでこの記事では、NextAuthの認証済み状態をPlaywrightで再現させる方法を紹介します。 やり方は大きく2つ NextAuthの設定に依存してやり方は大きく2つあります。 セッションデータを database で管理している場合 セッションデータを jwt で管理している場合 データベースの場合 セッションデータをデータベースに
【翻訳】テスト駆動開発の定義 - t-wadaのブログ
このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正
「UIの色を変えただけで大量のクレームを頂戴してしまった話」の何が問題か？｜moutend
結論話題の記事「UIの色を変えただけで大量のクレームを頂戴してしまった話」を読みました。ユーザーを軽視した内容に驚愕したのですが、それよりも記事が批判されている原因を理解できていない様子の方が存在することに衝撃を受けました。 現職のデザイナーあるいはデザイナーを目指している方々にお伝えしたいことは以下の3点です。 具体的な不都合を訴える問い合わせは無益なクレームではなく有益なフィードバックです。プロダクトの価値向上につながる貴重な意見ですから無視するべきではありません。 時間の経過でユーザーがUIに慣れることはありません。問い合わせをしても無駄だと学習して離脱したパターンを疑いましょう。受け入れられる場合も含めて画面の変更はユーザーに負担を強いているのだと自覚してください。 色覚特性や色とコントラストについて学びましょう。色だけで情報を伝えるデザインはアンチパターンですから避けてください。
フロントエンドパフォーマンスの変遷とNext.jsに見る次の時代
こちらのイベントのLT登壇資料です。 https://ochacafe.connpass.com/event/308830/ 登壇後、資料内の論理展開を登壇者の判断で改善しております。以下は登壇時からの主な修正点です。 ・レガシーMPAについて、FCPのみに着目して初回表示が遅いとしていた記述を削除 ・レガシーMPA + Ajaxについて、初回表示に関する言及を削除。SPAで行われる初回表示に関する変化の説明と重複するため ・SPAの初回表示について、FCPが速くなったとポジティブな書き方を、逆にLCPが遅くなったとのネガティブな記述に修正 ・SPA+SSRのページを削除。サーバーサイドフェッチを伴うSSRについてはNext.js側のページで解説 ・サーバーサイドフェッチを伴うSSRについてのネガティブな記述を削除し、SPA的なクライアントサイドフェッチのアーキテクチャとフラットに取り扱う
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
履歴データテーブルとの向き合い方_PHPerKaigi2024
