技術部のヨシオリです。 Netflix が Chaos Engineering の論文を公開して 2 年ほど経ちました。 クックパッドは最近、 Chaos Engineering を導入する事を決めました。 この記事ではその背景を紹介したいと思います。 そもそも Chaos Engineering とは Netflix では Failure Injection Testing として、営業時間中に意図的に障害を起す事をやっていました。Chaos Monkey というインスタンスとサービスを落すものから Chaos Gorilla、Kong という availability zone や region 単位で障害を発生させるものなどです。 その経験から Chaos Engineering というものが提唱されました。 Principles of Chaos Engineeringによれば C

このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(

この記事ではAngularDart/Flutterの文脈で新しいコンポーネント設計パターンとして広まりつつあるBLoCパターンを、Angularの語彙で理解し、実装する方法を紹介する。 BLoCパターンとは BLoCとは、Business Logic Componentの略である。 BLoCを使ったアプリケーションの実装パターンをBLoCパターンと呼ぶ。 まず誤解を招きそうなポイントとして、この"Component"はReactやAngularなどでいうところのビューを構築する"コンポーネント"ではない。 一般的な単語としての、アプリケーションを構成するひとかたまりの要素という意味の"Component"なので誤解しないこと。 対比するレベルとしては、"UI Component" vs "Business Logic Component"のようになる。 BLoCは複数の環境向けにアプリケー

Webにかぎらず、アプリケーションというのは作って終わりではなく、その後も継続して改修・改善されていくケースが多い。受託で開発して納品して終わりというケースでも、納品した先にメンテナンスする人がいる。 この記事では、Angularアプリケーションの開発において、いかにメンテナンス性を維持して、持続可能なプロジェクトを構成するかについての個人的な見解をまとめる。 フレームワークを邪魔しない Angularアプリケーションのメンテナンスにおいて、いちばん重要なことはいかにAngularのアップデートを阻害しないかという点に尽きる。 これはAngularに限った話ではなくフレームワークと呼ばれるものを使うなら常に必要なことであるし、 アップデートが定期的に降ってくることが決まっているAngularであればなおさらである。 アプリケーションの一番根幹となる部分の鮮度が落ちれば、その他の部分はそれに

僕がAngularアプリケーションを書くときに頻出する実装パターンを紹介する記事です。続くかどうかは未定です。 onDestroy$ ngOnDestroyメソッドが呼び出されたタイミングでemitされるEventEmitterを作っておき、RxJSのtakeUntilパイプなどで使う実装パターン。 ngOnDestroyメソッド内でunsubscribeメソッドを呼び出すよりも宣言的で意味が取りやすいし、忘れにくい。 実装例はこんな感じ。ReactiveFormsModuleを使うときにvalueChangesに引っ掛けることが多い。 import { Component, OnDestroy, OnInit, EventEmitter, Output } from '@angular/core'; import { FormGroup, FormControl } from '@ang