Tech 系の手書きコミックで著名な Julia Evans さんの作品です。
定期的に見直すべき内容だと思うので記事化しておきます。
出展は こちらのtweetです。
本ブログの記事作成時の方針
About
- 当ブログ内で記事を書く際の方針やスタイルをメモする場所です
- 文章を書く際のコード規約に近い何か
Rules
1. コンテンツ
記事を書く際は、読者を想定し、以下が伝わることを目的に書く。
- どんな問題を解決するために、何について話をしようとしているのか？
- 解決策の概要
- それがあると何が嬉しいのか？
- 抽象度の高い概念については、具体例も示す
特定のプロダクトについて説明をする際は、以下について説明することを心がける。
- いつ誰が開発したのか。元になっている要素技術、論文 (歴史)
- どのような問題を／どうやって解決しようとしているのか？それがあると何が嬉しい？
想定されるユーザーとユースケース
- できれば、単に特定のユースケースを語るのではなく、「どういう開発(運用)体制/分業体制下でどのような業務の全体図があって、その中で誰が使うといいのか？どのような効果が期待できるのか」まで踏み込めるといい。ユースケース図を書きながらアクターを整理するイメージに似ている.
機能について説明する際は、「直接的に何をしているのか？(石を積む)」だけでなく「それにより上位のどのようなことが実現されるのか？(城を作る)」についても説明する
- 設計思想/トレードオフ構造についてどのような意思を表明しているのか？
- 参考文献の一覧
- より詳細な情報を知りたい時の道標を提供する
2. 全体の構造
- 以下で言われているような構造を目指す
2.5 荒く文章をプロトタイプする時の方法論
- 以下の順番で書き進める。
- まず書きたいことを殴り書きする
- 次に上記に従い、付属する部品を補完しつつ再構成する
- 時間がない時は、一旦箇条書きスタイルでもokだが、後で「文」に置き換えることを心がける
3. スタイル
- 課題と解決策がペア/ワンセットになるような説明を心がける
- 段落の中には、同じような話題を扱った文が凝集している状態を目指す。仲間はずれの文を見つけたら、他の段落への引っ越しを検討する
4. 記法
- 「である」調ではなく、「ですます」調で書く
- 読者に適切に説明するために記事を書く、という意識づけのため
- 用語については、できるだけ和名と英名を併記する
- 例: × 冪等性、○ 冪等性(idempotency)
- 丸括弧を使うときは、丸括弧の前後に半角スペースを入れる
- 例: × データ(Data)の活用、○ データ (Data) の活用
- ひらがなにした方が読みやすい単語についてはひらがなで記載する
- 例: × 全て、更に ○ すべて、さらに
- 引用文献を記載する時は、はてなの脚注記法を使う
- (())
- 長めの文章を書く際は、H要素にナンバリングをして、contentで目次を自動出力させる ※ サンプルとなる過去記事
お手本とする記法
特定の概念をコンパクトに説明する記事としては、以下記事の書き方がきれい。参考にする。 www.codereading.com
英文のパラグラフライティングを意識した文章としては、以下の記事の文章が優れている。 https://www.joyent.com/node-js/production/design/errors
Blogをメンテナンスしました
- テーマを変更しました
- サイドバーの順序を見直しました
- カテゴリに階層構造を導入しました
メンタルモデルとは何か
読者にとってわかりやすい資料を作りたいけど、わかりやすさってなんだろう？と悩んだ経験はないでしょうか？ そのような悩みを持つ人にとって有益なメンタルモデルという概念があります。メンタルモデルとは、人間がインプットされた情報を理解するために頭の中に作る「理解のモデル」です。以下にメンタルモデルについての備忘メモを記載します。
メンタルモデルとは何か
- メンタルモデルとは、人がインプットされた情報を処理するために頭の中に作る「理解のモデル」
- 「わかりやすい説明」とは「理解のモデルの構築コストが低い説明」と考えることができる
- また、順番やグルーピングが適切だと、効果的にチャンクが形成されワーキングメモリへの負荷が少ない？
- 上記のような考え方は、文章を書く際にとても有益
引用
この情報処理をスムーズに進めるために、人は頭の中にメンタルモデルを作ります。 メンタルモデルを作って、関係情報を活性化し、高速に情報を処理しようといます。 (略) 読み手に明確なメンタルモデルを作らせるためには、概略から述べることです。 (略) たとえば、「本モジュールは、A、B、Cの3つのサブモジュールで構成されている」と書き始められていれば、 読み手はメンタルモデルを作って先を理解しやくなります。 読み手はこの文を読んで、「この後は、A、B、C3つのサブモジュールをこの順に説明するな。まずはAサブモジュールだ」 と思うはずです。
文章を読むとき、読者はそこに書かれている言葉をもとにして、 心の中に概念を組み立てます。つまり、読者は言葉を通じて概念を構築するのです。 (略) 文章を読むことは、文章の流れを追うとも表現できます。 「文章の流れを追う」というのは、道を歩くことに似ています。 著者が書いた文章が道であり、文章の流れを追うのは道をたどって歩くことに相当します。
ブール値(Boolean)の元になっているのはこれ？
ビジネス本を読んでいたら、ブール値の起源らしき情報について書かれているくだりを見つけました。ので備忘的に引用しておこうと思います。
ブールは真実の発言を「1」とし、虚偽の発言を「0」として、論理の問題が数学のように解けることを示した。それがすぐに現実的に重要な意味を持つことはなかったが、ブールの死から7年後、シャノンがAT&Tのベル研究所で夏のインターンシップをしていた時、シャノンは電話のルーティングの技術とブールの理論を組み合わせて、どんな種類の情報も符号化して、電子的に送信できることに気づいた。この洞察がコンピューターの根幹となっている。
出展: 『RANGE 知識の「幅」が最強の武器になる』日経BP, 2020
識別子 (identifier) とは何か
wikipedia の定義から言葉の意味を考える
https://en.wikipedia.org/wiki/Identifier
An identifier is a name that identifies (that is, labels the identity of) either a unique object or a unique class of objects, where the "object" or class may be an idea, physical countable object (or class thereof), or physical noncountable substance (or class thereof).
identifierとはオブジェクトを一意に識別するための名前である。
An identifier may be a word, number, letter, symbol, or any combination of those.
identifier は単語(word)、数字、文字(letter)、シンボルの単独あるいは複数の組み合わせで構成される。
The abbreviation ID often refers to identity, identification (the process of identifying), or an identifier (that is, an instance of identification).
identification はthe process of identifyingを意味する。つまり、identifying する/一意の何かを特定する、プロセスのことをidentification と呼ぶ。
identifierの定義はthat is, an instance of identificationとなっている。
instanceの意味は以下の通り。
a particular situation, event, or fact, especially an example of something that happens generally: https://www.google.co.jp/amp/s/dictionary.cambridge.org/ja/amp/english/instance
識別子の具体例
- URL -> 任意のWEBページを一意に識別 (identify)する
- マイナンバーカード
設計思想 == トレードオフに対する価値観の表明
ITシステムの設計をする際に、そのシステムを取り巻く制約条件・トレードオフ構造を把握することはとても重要です。そのような事柄について何をどのように考えるべきか、備忘メモを残しておこうと思います。
設計時に考えるべき事
1. 何と何がトレードオフとなるのか
設計をする際には、「〇〇を取ると△△を捨てることになる。逆に、△△を手に入れたい場合〇〇はあきらめざるを得ない」という、二者択一的な要素が存在します。まずは、このようなトレードオフ構造を可視化しましょう。
2. どちらを優先しどちらを捨てるのか
可視化されたトレードオフ構造については「何を重要視し、何を諦めるのか？」明確な方針を持つこと重要です。このようなトレードオフ構造に対する方針のことを 設計思想 と呼びます。設計に際しては明確な設計思想を持ち、設計ドキュメント内で明示的に説明しましょう。
引用文献
こうした、多数の自由度を持つ設計において、その方向付けをするガイドラインとなる方針、あるいは コンフリクトが発生したときに、優先順位を強く明確に決めたポリシー が、設計思想です。
いいかえるなら、設計思想とは価値観の表明に他なりません。とくに、トレードオフが生じる前に、「何を捨てるか」を決める ものなのです。
(略)
何年か前にKさんにお会いしたとき、わたしがまだHP-200LXという旧型のPDAを使い続けていることを覚えておられるでしょうか？ あの製品は、明確な設計思想で作られた代表的製品だったと思います。携帯可能で、キーボードをそなえ、市販の単三乾電池で1ヶ月動く。そのかわり液晶はモノクロでバックライト無し、無線通信機能も無し。GUIも無し。それでも、わたしはあれを2台購入し、両方が壊れるまで10年以上も使い続けました。ですが、GUIをのせた後継機種は買いませんでした。設計思想に不透明さを感じたからです。
_
コンセプトについて語るときに、常に著者が思い出す例は、1970年代後期に、時の米海軍作戦部長 ズーモルト(Elmo Zumwalt, Jr)大将が指揮して計51隻建造した、船団護衛及び低脅威海域哨戒を主任務とするローコンセプトのFFG-7級ミサイルフリゲート艦の下記を主要とする設計コンセプトである。
. (略)
本艦の設計コンセプトは、以下のとおりである。すなわち、対艦ミサイル装備のソ連攻撃型原潜脅威を曳航式パッシブソナーで 遠距離探知し、ヘリコプターで位置局限・攻撃することを重視する。
. (略)
しかしながら基本的にローコンセプト艦であることから、 最大戦力/航続距離、推進軸数等についてはトレードオフアイテムとする。 要するに、所要の任務に対応して、 必要な要件には重点投資するが、低減可能な項目については思い切って削減する という考え方である。
.
『軍事システムエンジニアリング』かや書房, 2006, P24-25
アトミック性(Atomicity)とは何か
可視性/観測性に着目さた定義の仕方が秀逸と感じたので、メモとして残しておきます。
アトミック性という考え方に実務のなかで触れる場面は色々あります。たとえば、トランザクション処理を考える際のACID特性のA。 また、ある処理を並行で実行しても問題ないか？という文脈でも類似のことを検討することが多いです。Linuxのコマンドでも処理がアトミックなものとそうでないものが混在しており、スクリプトを設計する際に考慮が必要なケースがあります。
アトミック性（原子性，不可分性）とは，その 操作の途中状態が外部（例えば，他のスレッド）から観測できない ことです。 ここでいう「観測できない（見えない）」は，ハードウェア的にどう頑張っても観測できないように作られている仕組みを使うのはもちろん，ロックなどの同期機構を用いて「見ないようにする」ことでも達成できます。
変数へ値が完全に書かれたか，あるいはまったく書かれていないかのどちらかの状態しか観測できないとき，その変数への書き込みはアトミックです。 逆に，アトミック性が無い場合は外部から途中状態が観測できてしまいます。
Ubuntuで夜間モード( Night Light feature )を有効化する
概要
- 目に優しい開発環境構築のため、普段Windows機利用時は f.lux を愛用している
- Ubuntuでもf.luxの導入が可能かどうか調べた所、 UbuntuのNight Lifght機能を使うことが推奨されていた ので試してみる
環境
$ cat /etc/os-release | head -2 NAME="Ubuntu" VERSION="20.04.3 LTS (Focal Fossa)"
有効化の方法
設定 -> ディスプレイから以下の画面にて有効化が可能- 自分の場合、日中も有効化したいのでカスタム時刻をそのように調整した
TECHONOLOGY RADAR Vol25
年に2回Thoughtworks社が発表の TECHONOLOFY RADAR の最新号が2021年10月に発表された。その内容についてのメモ。
Techniques
Four key metrics
Four key metrics はソフトウェアのデリバリープロセスのパフォーマンスを測定するためのメトリクス (KPI)のセットで、DevOps Research and Assessment(DORA) により発案されました。以下の4つのメトリクスを計測することで組織が持つソフトウェアのデリバリー能力を定点観測することができます。
- change lead time
- deployment frequency
- mean time to restore (MTTR)
- change fail percentage
上記の4メトリクスのうち、信頼性を評価するための2種、MTTR と change fail time については、CD Tool から取得できる値のみを使って測定しても、有用性の低い結果となることが警告されています。局所的な信頼性とエンドツーエンドの信頼性は異なるファクターだからです。そのためエンドツーエンドでの値の取得が推奨されています。
Four key metrics の詳細は LeanとDevOpsの科学 / 原題 Acclerate 第2章 2.2 にて解説されています。
platform-engineering-product-teams
- APR 2021に続き、2回目のAdopt
- 既存のIntrnal Teamの名前だけを「Platform Team」にすることはアンチパターンであること、また Team TopologiesのConceptの有用性が強調されていた
Living documentation in legacy systems
- behavior-driven development (BDD)のコミュニティにて誕生のLiving Documentationという手法をレガシーシステムの刷新につかうことが極めて有用という話
- ↑のLiving Documentationのリンクから辿れる、Specification by example chapter3のLiving Documentationの説明が面白かった。Test as Executable Specs的な話
Platforms
Pulumi
Pulumi はプログラミング言語で IaC が行えるツールです。TypeScript/JavaScript、Python、Go言語 が利用可能です。同じカテゴリの製品としては、 AWS Cloud Development Kit (AWS CDK)が存在します。
Terraform利用時の の Pain である不十分な抽象化機能、テスタビリティを解決する点が評価されていました。
中の人がAWS Lambdaの開発の歴史を語る動画を見た
AWS Lambdaの開発をリードしているMark Brookerが、Lambdaの内部的なアーキテクチャや開発の歴史を語る動画を見たが、Firecrackerベースのアーキテクチャを構想した時期の回想、Rust採用の理由と経緯などが語られていてよかった。re:Invent 2020の発表 は未視聴なのでこちらも合わせてみてみたい。 youtu.be
関連：
Wardley Maps
re:Invent 2020で技術革新の影響を可視化するための手法として Wardley Maps という手法がAdrin Cockroftによって紹介された。[1] ( AWS re:Invent 2020: Adrian Cockcroft’s architecture trends and topics for 2021 ) 本記事ではその概要を解説する。
サマリ
- Wardley MapsはSimon Wardleyが提唱した戦略可視化ツールである
- Wardley Mapsを使うことで、技術革新・新しいテクノロジーの登場が自社システムを構成するバリューチェーンに与える影響を可視化することができる
Wardley Mapsとは何か
Wardley MapsはSimon Wardleyが提唱した戦略可視化ツールであり、2016年に概要を紹介するスライドが氏によって公開されている。( An introduction to Wardley Maps ) 以下のWardley Mapsの例を示す。図の見方だが、縦軸はバリューチェーンを、横軸は、コンポーネントが技術発展ライフサイクル上のどこに位置するのかを表す。
図の出展 : https://www.slideshare.net/swardley/why-the-fuss-about-serverless-88107645 P110
縦軸の詳細だが、図の例では、オンラインの写真保存サービスを提供している会社が顧客に価値を提供するためのバリューチェーンにおいて、利用されている技術スタックの連鎖が示されている。DCで動作するサーバーによりWebサービスがホスティングされており、顧客はそれにアクセスすることで写真を保存できる、というのが概略となる。
図の出展 : Doctrine or Dogma?. Challenge Your Wardley Mapping… | by Erik Schön | The Startup | Medium
横軸の詳細だが、以下に記載の4フェーズの状態遷移モデルのようなイメージの分類学となっている。キャズムとかガートナーのハイプ・サイクルを念頭に置くと理解しやすいかもしれない。
- genesisなコンポーネントは、発見されたばかりで生まれたてほやほやの新たな概念である。我々はこのアイデアについてまだあまり知見を持っておらず、他の探求はこれから始まる
- custom builtなコンポーネントは、世の中ではまだまだ珍しい状態であり、知見が一定たまりつつらあるものの未だ「実験中」のフェーズである。特定の会社で特定の用途のために、フルスクラッチの製品が動作しているケースが多く、世に普及するためにはフェースが次の段階へ進む必要がある。ソフトウェアの仕様も未だ不安定であり、バージョンアップ等で大きく変わる可能性がある
- productに達したコンポーネントは、製品コンセプトや利用方法が世の中にある程度認識された状態になっており、ソフトウェアの仕様も成熟展安定度が上がり変化の速度もだいぶゆっくりになっている
- commodityに達したコンポーネントは、標準化が完了しており、世の中で特定の目的のために広く使われる状態になっている
※ 前述の Doctrine or Dogma?. Challenge Your Wardley Mapping… | by Erik Schön | The Startup | Medium をベースに和文を作成＋一部追記
これを使うと何が幸せなのか？
Wardley Mapsを使うことで、技術革新・新しいテクノロジーの登場が自社システムを構成するバリューチェーンに与える影響を可視化することができる。例えば、以下の図ではServerless(JEFF)が登場することによりWebApplicationを構成するバリューチェーンを構成する各コンポーネントがどのように置き換わるのか？が赤線で図示されている。これにより、特定の新技術の登場(点)が全体としてのバリューチェーン/技術スタック(線)にどのような影響を与えるのか？が可視化される。
また、自社の技術戦略/ロードマップを検討したり、要素技術の置き換えを時系列を伴うDirecotional Movemenetとして記録する際にもWardley Mapsを活用することができる。
図の出展 : https://www.slideshare.net/swardley/why-the-fuss-about-serverless-88107645 P248
Footnote
[1] 本記事の公開後に職場の同僚に教えてもらったのですが、DDD Europe 2020にて同様にWardley Mapsに言及した発表があったそうです
Slide
Rule of 3 , by Adrian Cockroft : ミッションクリティカルな処理は3重に冗長化しよう
設計をするときは要件、課題、解決策の順番で考える
『建築の設計力』 という本の内容を元に考えた、設計をするときの思考プロセスについてのメモです。
設計をするときは要件、課題、解決策の順番で考える
設計をする時は、要件をもとにまず課題を設定し、それから解決策を考える 進め方が望ましいです。
要件が与えられると、すぐに解決策の検討を始めたくなります。そこでぐっとこらえて、課題の整理にまず着手することが大事です。ここで整理される課題のことを「設計観点」と呼びます。
「課題」と「解決策」の関係を事後的にチェックできるよう、設計時の検討事項をドキュメント化しましょう。1つの設計ドキュメント内で「課題」と「解決策」が併記されている状態が望ましいです。
※「解決策」の実装に集中していると、意識が次第に「課題」から離れていき最終的に何を実現したかったのか？が曖昧になっていきがちです。それを防ぐために課題を明文化しましょう。「解決策が課題の要請を満たしているのか？」という観点で試験を実施する際も、課題が明文化されていると試験観点の抽出がスムーズです。
実際は課題をサブ課題に分割することが多い
fig.2 では「課題設定」の箇所を簡略化して書きましたが、実際には複数の課題を親子関係に分割/グルーピングして検討することが多いです。(fig. 3) [1] 多くの場合こうやって課題をグルーピングしていくと、ある一定のスコープを持つ設計領域が浮かび上がってきます。 e.g. Fault-tolerant設計, 収容＆スケーラビリティ設計 etc..
解決策を実装後は必ずテストする
解決策を実装後は、机上ではなく実際の振る舞い(システムの実動作)で、解決策が課題を満たすことをチェックしましょう。手間はかかりますが、机上検討時には予想もしていなかった有益な知見が得られます。
脚注
[1] 設計観点表などでは、これをスプレッドシートに落とし込み管理をする。課題管理表等で扱う場合も「カテゴリ」等の仕組みでグルーピングをすることが望ましい。似ている複数の似ている課題を、同時並行的に検討することが可能になるため。
