ペルシャ風ラム肉の煮込み
はじめに
GW、どこにも行けない代わりに、普段作らないような手間のかかる手の込んだ料理を作ろう。
そう思っていたところに思いつきました。「イラン料理だ！」
学生時代、第二外国語でペルシャ語をやっていたのと、その授業で連れて行ってもらったペルシャ料理屋。 その味をもう一度食べたい。
というわけで今回、ペルシャ風ラム肉の煮込みを失敗覚悟で作ってみたら、思いのほか美味しくできたので、記録としてレシピを残します。
作ったものは、以下の3つ。
- ラム肉の煮込み
- シーラージサラダ(Shirazi salad)
- イラン北部にあるシーラーズが由来になっているサラダ
- Jeweled rice(もどき)
- ハーブやレーズン、ナッツ、ザクロを混ぜてつくるライス。今回は、ザクロは利用せず。
準備〜片付けまで、大体1時間くらいでできました。
参考レシピ
日本語で書かれたレシピは、ほぼ見つからなかったので、以下の動画を参考にしました。 www.youtube.com
副菜として作ったシーラージサラダは、以下の動画を参考にしました。 www.youtube.com
材料
ラム肉の煮込み
| 材料 | 分量 |
|---|---|
| 玉ねぎ | 1玉 |
| ラム肉(肩) | 300g |
| シナモン | スプーン2杯 |
| ターメリック | スプーン2杯 |
| カルダモン | スプーン1杯 |
| ナツメグ | スプーン0.5杯 |
| サフラン | ひとつまみ |
| ライム | 1/2 |
| レモン | 1/2 (or 1/4 ) |
| タイム | 適量 |
シーラージサラダ
| 材料 | 分量 |
|---|---|
| きゅうり | 1本 |
| パプリカ(赤・黄) | 1/2 |
| レッドオニオン | 1玉 |
| トマト (今回は切らしていたので無し) | 1個 |
| レモン | 1/2 |
| オリーブオイル | 大さじ3 |
| ブラックペッパー | 適量 |
Jeweled rice(もどき)
| 材料 | 分量 |
|---|---|
| バスマティライス | 1合 |
| ルッコラ | 4~6本 |
| イタリアンパセリ | 4~6本 |
| レーズンミックス | 適量 |
| ピスタチオ | 適量 |
| レッドオニオン | 1/2 |
手順
1. バスマティライスを炊く。
使ったのは、こちら。
- メディア: 食品&飲料
炊飯器で、日本のお米と同じように炊きます。 日本の米の時と同じ量の水だと、やや硬めになるとパッケージに書いてありました。 今回は、水を1.1倍ほど入れたところ、もちもち感が出ました。
炊飯器のボタンを押したら、炊き上がるまでにメインを作っていきます。
2. ラム肉の煮込みを作る。
①. 玉ねぎを切る
②. 香り付け水を作る
熱湯 180mlに、サフランをひとつまみ入れる。
香りが立ってくる程度。
Do not Overuse.
レモンとライムの皮をすりおろしたものと、絞り汁を加える。
※参考にしている動画では、Rose Waterを入れてますが、用意できなかったので省略。
③. ラム肉をスパイスでコーティングしていく。
スパイスは、ターメリック(左上)、シナモン(右上)、カルダモン(左下)、ナツメグ(右下)
上記のスパイスに塩を少々加えて混ぜ、ラム肉に馴染ませていく。
少し余らせて、火を通した後再度使う。
④. ラム肉に火を通し、一旦取り出すし、スパイスを再度馴染ませていく。
⑤. 玉ねぎを、香り付け水・タイム・ベイリーフとともにを炒める。
⑥. 玉ねぎが飴色になる前に、ラム肉を入れる。
⑦. 熱湯400mlとコンソメの素を入れ、弱火で蓋をして煮込む(約10 ~ 15分)
3. シーラージサラダを作る。
ラム肉を煮込んでいる間に、サラダを作っていきます。
①. 材料を用意します。
本当はここに、トマトが入ります。
レッドオニオンは、ライスでの使うので少し多めに切る。
②. 材料を賽の目に切ります。
③. オリーブオイル・レモンの絞り汁・ブラックペッパーを加え、よく混ぜます。
サラダはこれで完成です。 そうしている間に、ライスが炊けている頃合いなので、続いてライスに手を加えていきます。
4. Jeweled riceを作る。
参考の動画ではザクロを入れたりして、Jeweled riceにしていますが、今回は色々簡略化します。
①. レッドオニオン・ルッコラ・イタリアンパセリを切る。
②. バターをフライパンで熱して、1で切った材料を炒める。
③. ライスを入れ、お好みでレーズン・ピスタチオ等を入れる。
これで調理は完了です。 最後に盛り付けていきます。
盛り付け / 終わりに
本場の味とまではいかずとも、スパイスの香りと、柑橘系の酸味・甘味がいい感じにミックスされて楽しめました。
在宅中心になって、自炊するようになりましたが、代わり映えのないレシピ。 今回、普段使ってこなかったスパイス・ハーブを使って調理したのは、新鮮でした。
ハーブ・スパイス、果物・ナッツを多く使うというイラン料理、 まだまだ色々ディグり甲斐がありそうです。
ちなみに学生時代に行ったイラン料理のレストランは、日暮里の「ザクロ」 でした。 COVID-19がもし落ち着いたら、また行きたいです。
さて、次は何を作りますかね。 以上
2020年出会えてよかったものたち
2020年に買ったり、食べたり聴いたりしたもので、特に出会えてよかったというものを振り返りました。
それぞれ、大体5つずつ挙げていきます。
ガジェットとか
ヘッドホン
AONIC50
2020年のベストバイ。有線の煩わしさからの解放、装着感の心地よさ、感動ものの艶・広がり・バランス。
良いお値段ですが、至高の一品です。
オーディオインターフェース
7年前に買った同じくNIのものが壊れたので、リモートワークだし買うか、ということで購入。 スピーカーに繋げたり、趣味で再開したギターのライン録りに利用。肝心のマイクはUSB接続のものを利用という。
NATIVE INSTRUMENTS ネイティブインストゥルメンツ/KOMPLETE AUDIO 6 MK2
- 発売日: 2019/06/12
- メディア: エレクトロニクス
シュレッダー
地味に役に立ったもの。 ECやネットスーパー利用が増えて、住所書いてある紙の処分に困っていたのをスッキリ解決。 セールで約3500円で購入。コスパの良い設備投資でした。
Mac Mini(2019)
M1が出る2ヶ月前に買ってしまったもの。 Bluetoothがちょくちょく切れる問題と、排熱が弱い以外は満足です。 ディスク1T、メモリ32G、CPUは3,2GHz 6コア i7
マウス
mx master 3 for mac
横スクロールホイールが結構便利。動画編集とかDAWでとっても役に立ってます。
最初は、でかい！と思ったけど、手に馴染んできて、とても使い心地がいいです。
以前より右腕が痛くなることがなくなったのも嬉しいポイント。
- 発売日: 2020/08/20
- メディア: Personal Computers
食材
鰹の藁焼き
楽天のセール時期に購入。
肉厚の鰹が最高。ご飯が止まらないですよ。
ハラミ 1kg
上に同じく楽天のセール時期に購入。
2500円でこんなにハラミを食べていいの！？となります。
塩胡椒で焼いて、白米に乗せる。シンプルだけど最強の焼肉丼が最高です。
豚の味噌煮
上に同じく楽天のセール時期に購入。
ジューシーで柔らかい、そして味噌の味がよく染み込んでいる一品。
これまたご飯が止まらないですよ。
ヨーグルト
普段食べているもの。はちみつと一緒に食べるととても美味しいです。
おかず畑 ひじきと豆のサラダ
ほぼ毎日1個は食べてる、というくらいお世話になったもの。
そのままでも良し。豆腐と一緒に食べたり、サニーレタスと食べたりしても良し。
アクセントにゆずポン酢を少量かけても良し。食事のおかずにも、小腹が減った時の間食にも。
とってもお世話になりました。
音楽
The Winking Owl
残念ながら、2020年7月にvo.の脱退により、無期限活動休止に。 もう少し早く見つけていたら、ライブにいきたかったです。
BAND-MAID
最高だっぽ!!! どうしてもっと早くから知っていなかったのか、アンテナの低さを後悔しました。 実は海外のReaction動画がかなり多く、評価が高いバンド。
楽曲もカッコよく、演者全員のレベルも高いだけでなく、 それぞれの個性が見事にアンサンブルされている感じがグッときます。
オンラインお給仕も参加できたし、来年はニューアルバム出るし、めちゃくちゃ楽しみなバンドです。
わーすた
アイドルには詳しくないけど、この曲聴いてかっこいいな、と思いました。 今後もフォローしていきたいグループ。 www.youtube.com
Johannes Bornlöf
スウェーデンのコンポーザー。 元々ピアノインストが好きなのですが、Johannesの独特の浮遊感がストライクでした。 集中したい時などにもよく聴いてました。
Spotify My Top Songs 2020
半分くらいはHR/HM、メタルコア辺りでした。 鬼滅は見れても読めてもないけど、LiSAの紅蓮花は最高です。 PassCodeも相変わらず最高です。
Youtube
ディスカバリーチャンネル
期間限定公開を謳いながら、ずっと公開し続けている懐が深いチャンネル 金採掘のドキュメンタリーや、サバイバル系などよく見ていました。 www.youtube.com
美人MCのアリーさんのチャンネルも、クスッと笑える動画が多く必見です。 www.youtube.com
THE FIRST TAKE
言わずもがな。 LiSAの紅蓮華、もうすぐ1億再生ですと。。。この企画を立てた人、すごいなと思いまし。 個人的には、小中の頃聴いていたようなYUIの出演は嬉しかったです。 www.youtube.com
Smosh
海外のコメディ集団のチャンネル。 英語の勉強にもなりますし、なによりコンテンツが面白すぎる。 毎回お腹抱えて笑ってます。 www.youtube.com
だいじろー
英語の発音を極めた方のチャンネル。インド人のモノマネがツボです。 イギリス英語の特徴解説など、真面目なコンテンツもあり勉強もなります。 www.youtube.com
MAHOME
デスボを極めた人のチャンネル。ホイッスルボイスで女王蜂の炎歌い上げる変態()
私はデスボを出せないですが、デスボ出したい人は必見です。
www.youtube.com
Podcast
寝る前や、朝早く起きた時など、この辺りをよく聴いてました。
その他
紅茶(ダージリン)
去年伊勢丹地下のNavarasaの紅茶を、売り場のお姉様()にお勧めされて、購入した50gで3,4000円する紅茶。 めちゃうまだったので、今年も欲しいと思ってた中のコロナで伊勢丹はしばらく閉鎖。
ネットを探すと、Navarasaは伊勢丹限定ブランドとして、Leafullが出しているものと判明。 Leafullのサイトから、去年も購入した、キャッスルトンのダージリンをオンラインで購入しました。 【19オータムナル】 キャッスルトン農園 Clonal Tippy DJ-508 | リーフルダージリンハウスオンライン
植物
殺風景な部屋に飾りをと思い、ポトスと購入。 想像の倍以上の、結構いいお値段しましたが、良い買い物でした。
apegoというサイトで購入しました。
www.apego.jp
FFVII REMAKE
ゲームはあまりしない方ですが、FF7Rは買いました。涙ちょちょぎれながらプレイしました。 続きが楽しみです。
- 発売日: 2020/04/10
- メディア: Video Game
以上
【読書メモ】Fundamentals of Software Architecture ~第三章 Modularity~
第三章は、Modularity(モジュラリティー)について。
MDN web docでModularityの定義をみると、以下のように説明されています。
システムのコンポーネントを分離して再結合できる程度を指しており、またソフトウェアパッケージを論理ユニットに分割することもあります。モジュラーシステムの利点は、部品を独立して考えることができることです。
この章では、モジュラリティーを理解するための三つの指標が提示されています。
cohesion(凝集度), coupling(結合度) それとconnascence(コナーセンス)です。
凝集度と結合度については、わかりやすい記事が既にあるので、ここでは飛ばします。
本記事では、残りのconnascenceについて詳しく触れていきます。
- connascenceとは
- Type of connascence
- 1. Connascence of Name (CoN)
- 2. Connascence of Type (CoT)
- 3. Connascence of Convention (CoC) / Connascence of Meaning (CoM)
- 4. Connascence of Algorithm (CoA)
- 5. Connascence of Position (CoP)
- 6. Connascence of Execution (CoE)
- 7. Connascence of Timing (CoT)
- 8. Connascence of Values (CoV)
- 9. Connascence of Identity (CoI)
- 3つの性質(Properties)
- 参考
- 英単語メモ
connascenceとは
凝集度と結合度は耳にすることも多いですが、connascenceは日本語だと情報がなかなか出てこないです。 connascenceは、Meilir Page-Jonesにより発明されたソフトウェア品質を測る指標だそうです。
coはtogather、
nascenceは'to be born' を意味するようです。
(ルネッサンス(Renaissance)は、re + nascence で復活の意味)
connascenceは複数のものが、同時に生まれるという意味になります。
では、ソフトウェア開発の文脈で、connascenceであるとはどういうことを指すのでしょうか。
connascenceの提唱者、Meilir Page-Jonesは、connascenceを以下のように定義しています。
two components are connascent if a change in one would require the other to be modified in order to maintain the overall correctness of the system.
二つのコンポーネントがconnascentである時、一方の変更が、システム全体の整合性を保つために、他方のコンポーネントの変更を要求する。
Type of connascence
次に、connascenceの種類について。全部で9種類存在するようです。
connascence.ioを元に、詳しく見ていきます。
1. Connascence of Name (CoN)
名前についての合意
function Aは、A()と呼び出す、という結合。
発見しやすく、リファクタもrenameで容易に可能。
2. Connascence of Type (CoT)
型についての合意 主に、静的型付け言語での話。例えば、以下のような例。
int age; age = 10.5 // TypeError
こちらも、静的型付け言語であれば発見しやすくリファクタも容易。
3. Connascence of Convention (CoC) / Connascence of Meaning (CoM)
意味についての合意
例えば、次のような関数はCoCによる結合を生み出す。
def get_user_role(username): user = database.get_user_object_for_username(username) if user.is_admin: return 2 elif user.is_manager: return 1 else: return 0
0, 1, 2のそれぞれの「意味」をget_user_roleを利用する側は知っている必要が出てしまう。 Enumとしてまとめることで、CoCの結合にすることができる。
4. Connascence of Algorithm (CoA)
アルゴリズムについての合意
複数のエンティティが同一のデータを扱う際にしばしば発生する。
例えば、次のようなコードは、エンコーディングがUTF-8である、という合意を元にしている。
def write_data_to_cache(data_string): with open('/path/to/cache', 'wb') as cache_file: cache_file.write(data_string.encode('utf8')) def read_data_from_cache(): with open('/path/to/cache', 'rb') as cache_file: return cache_file.read().decode('utf8')
また、サーバサイドとクライアントサイドの両方に実装される、 ハッシュアルゴリズムや、バリデーションロジックなどでも起きうる。
5. Connascence of Position (CoP)
位置についての合意
次のようなコードは、connascence of positionによって結合されている例だ。
def get_user_details(): # Returns a user's details as a list: # first_name, last_name, year_of_birth, is_admin return ["Thomas", "Richards", 1984, True] def launch_nukes(user): if user[3]: # actually launch the nukes else: raise PermissionDeniedError("User is not an administrator!") user = get_user_details() launch_nukes(user)
userというリストのうち、4つめの要素が権限を示すということを知らないといけない。 dictやエンティティにすることで、CoNの結合にすることができる。
6. Connascence of Execution (CoE)
実行順序への合意
例えば、リソースのロック/アンロックや、カプセル化されたステートマシンで起きうる。
以下のようなEmailSenderは、最後の2行が不正となる。
email = Email() email.setRecipient("foo@example.comp") email.setSender("me@mydomain.com") email.send() email.setSubject("Hello World")
このケースでは、実装箇所が近いため、発見は用意だが、 最後の2行が別スレッドで実行されるようなケース(high locality)では、発見が困難になる。
7. Connascence of Timing (CoT)
実行タイミングについての合意
例えば、複数スレッドで並行処理などで起きうる。
8. Connascence of Values (CoV)
値についての合意
例えば、以下のようなコードではArticleState.Draftが初期状態である、という合意が元にある。
class ArticleState(Enum): Draft = 1 Published = 2 class Article(object): def __init__(self, contents): self.contents = contents self.state = ArticleState.Draft def publish(self): # do whatever is required to publish the article. self.state = ArticleState.Published
テストコードでArticleの状態をチェックする際など、Articleクラスの初期状態を知っていなければいけなくなる。 しかし、そうなるとArticleクラスの初期状態がDraftではなくなった場合、テストケースは壊れることになる。
以下のように、初期状態を示す値を持つことで、その問題を回避できる。
class ArticleState(Enum): Draft = 1 Published = 2 InitialState = Draft class Article(object): def __init__(self, contents): self.contents = contents self.state = ArticleState.InitialState
例えば、初期状態がDraftから、Preproductionになった際は、以下のように変更すればよい。
class ArticleState(Enum): Preproduction = 1 Draft = 2 Published = 3 InitialState = Preproduction
9. Connascence of Identity (CoI)
同一エンティティについての合意
一般的な例としては、2つの別々のコンポーネントが、共通のデータ構造(例えば分散キュー)を共有・更新する時など。
3つの性質(Properties)
また、connascenceは3つの性質で見ることができるようです。
- degree：より強いconnascencesは、より発見しづらく、リファクタリングしづらい。
- locality：より多くのエンティティと、connascentであるエンティティは、問題の影響が大きくなる。
- strength：Connascentな要素は、コード上で近い位置に存在する方がよい
1. Strength
Connascenceには、強度が存在し、コードはConnascenceが弱くなる方にリファクタするべきとされている。
CoNは、renameによって変更可能であるため結合が弱く、CoCはコード全体から変更を洗い出すことがより難しいため、結合は強くなる。
また、Static connascenceに比べ、Dynamic connascenceは実行時の挙動について知る必要があり、より強いconnascenceである。
2. locality
コンポーネント同士の近さ、を示す軸。 より強いconnascencesは、同一モジュール内などの近い関係では許容しやすく、 離れたコンポーネント間では、より弱いconnascencesであるべきである。
3. degree
connascenceが関与する影響度を示す軸。 結合が2つのコンポーネントに影響するのは、200のコンポーネントに影響するのかを見る。
参考
日本語での情報が少なく、あまり認知されていない(?)概念のように思われる。 以下、参考にしたリソースのメモ。
英単語メモ
■untangle (verb)
def: to separate pieces of string, hair, wire, etc. that have become twisted or have knots in them
def: to make something that is complicated or confusing easier to deal with or understand
■incarnation (noun)
def: a period of life in a particular form
def: a person who represents a particular quality, for example, in human form
【読書メモ】Fundamentals of Software Architecture ~第二章 Architectural thinking~
雲を見る時、気象学者の視点と、芸術家の視点では見ているものが異なるはず。
本書では、アーキテクトの視点でアーキテクチャを見ることを、Architectural thinking(アーキテクチャ的思考)と呼んでいます。
重要なポイントは、Architectural thinkingは、単にアーキテクチャについて考えることではないということ。
アーキテクチャ的思考には以下の4つの側面があると述べられています。
- アーキテクチャと設計の違いを理解し、アーキテクチャを機能させるためにチームとどのように協力していく方法を知る事。
- 幅広い技術的知識を持ちながらも、一定レベルの技術的な深さを維持し、他の人には見えない解決策や可能性を見出す事。
- 様々なソリューションと技術の間のトレードオフを理解し、分析し、調整する事。
- ビジネスドライバーの重要性を理解し、それがどのようにアーキテクトの懸念事項に反映されるかを理解する事。
<目次>
- Architecture Versus Design
- Technical Breadth
- Analyzing Trade-Offs
- Understanding Business Drivers
- Balancing Architecture and Hands-On Coding
- 英単語メモ
Architecture Versus Design
アーキテクトと開発者の役割の違い<Traditionalな分け方>
▼アーキテクトの範囲
- ビジネス要件を分析してアーキテクチャの特性（「能力」）を抽出・定義する
- 問題領域に適合するアーキテクチャのパターンやスタイルを選択する
- コンポーネント（システムの構成要素）を作成したりするコンポーネント（システムの構成要素）を作成したりする
▼開発者の範囲
この関係性の問題点は、アーキテクト -> 開発者 という一方方向な関係になっていること。
どうあるべきか、というのは以下の図のように示されています。
アーキテクトと開発者の垣根がないこと、そして共にイテレーションを回していくことがプロジェクト成功には重要とのこと。 つまり、どこからがアーキテクチャでどこからが設計か、という分け方ではないのだ、ということでしょう。
Technical Breadth
ここでは、アーキテクトが身に着けるべき技術的知識について書かれています。
まず、開発者とアーキテクトでは、求められる知識にどんな差があるのか。 それは、幅と深さである、と述べられてます。
書籍中では、以下のような図で説明されています。
技術的な深さは、「Stuff you know」(知っていること)を掘り下げていくこと。
技術的知識の幅とは、「Stuff you know you don't know」(知らないと知っていること)を増やしていくこと。
アーキテクチャ的な最適解を見つけるアーキテクトにとっては、
この技術的知識の幅をいかに広げていくか、が重要ということみたいです。
とはいえ技術的な深みや専門領域がなくてよい、という訳ではないのだと、
この後のセクションで触れられています。
Analyzing Trade-Offs
Architecture is the stuff you can’t Google.
Richards, Mark,Ford, Neal. Fundamentals of Software Architecture (Kindle の位置No.571-572). O'Reilly Media. Kindle 版.
この言葉の通り、アーキテクトが考えることは、トレードオフであり、
技術・ビジネス・組織の中で発生する要求や制約の中で、何を選択して何を選択しないか。
選択することによるメリットデメリット、選択しないことにより起きる条件制約。
置かれている状況の中でトレードオフを分析し、選択していくことがアーキテクトの考えで重要である、と述べられていました。
Understanding Business Drivers
アーキテクトの選択・決定はビジネス的要求とマッチしていることが重要、という話。 具体的にどう言った特性があり、どう考えればいいのかは、4〜6章の中で触れられているようです。
Balancing Architecture and Hands-On Coding
アーキテクトとしていかに、技術的深さやコーディングスキルを磨いていくか、という話。
三つの方法が紹介されています。
1. クリティカルパスや難しい箇所以外の開発に入る
この方法のいい所は、３つ
(1)アーキテクチャがプロダクトコードを書く機会を得られる
(2)開発チームがより難しい部分にフォーカスできる
(3)開発チームが感じている、プロセスや開発環境面での苦痛に気付ける
2. PoCの開発を担う
アーキテクトがPoCで開発を担うことで、
ドキュメント・構成管理・アーキテクチャなど、後の開発チームのガイドになるような土台を作れることがメリットの一つ。
アーキテクトにとっては、高品質で構造化された開発の腕を落とすことを防げるメリットがあるとのこと。
3. 技術的負債やバグ解決に関わる
コーディングスキルも磨きながら、コードベースやアーキテクチャの問題に気づくことができたり、
自動化やプロセス改善のきっかけにもなる。
また、コードレビューをすることで間接的にコーディングに関わることができ、
メンタリングやコーチングの機会も作ることができる。
第二章はここまで。
次回から、第三章に入ります。
英単語メモ
■quiver (verb)
def: to shake slightly; to make a slight movement
SYNONYM: tremble
■atrophy (noun)
def: (medical) the condition of losing fat, muscle, strength, etc. in a part of the body because it does not have enough blood
【読書メモ】Fundamentals of Software Architecture ~第一章 Introduction~ (2)
『Fundamentals of Software Architecture: An Engineering Approach』(以下、FoSA)の読書メモ、今回は第一章 Introductionの2回目です。
前回の記事はこちら
Intersection of Architecture and...
このセクションでは、ソフトウェアアーキテクチャと以下の４つについて書かれています。
- Engineering Practices
- Operations/DevOps
- Process
- Data
上から順に、見ていきましょう。
Engineering Practices
まず前提として、プロセスとプラクティスという考え方があるそうです。
- プロセスとは、どうやって「人」を動かすか（会議やチームビルディングなど）
- プラクティスとは、継続的に恩恵を生み出す仕組み（CI/CDなど）
アーキテクチャとしては、プラクティスにフォーカスを当てる事が重要とのこと。
例えば、マイクロサービスで必要な、自動プロビジョニング・自動テスト/デプロイなどをどう実現するかを決めること。
なぜプロセスとプラクティスを分けて考えるのか。
- (1) プラクティスはプロセスに依存せずに構築できるため。
- (2) 人間は「分からないとわかっていないこと」に対する推定が苦手なため。
「分からないとわかっていないこと」というフレーズは、2002年にラムズフェルド元米国防長官という人の発言として有名なようです。
詳しくはwikiを参照ください。
ジョハリの窓理論に由来するそうな。
プロジェクトの始まりは、「知らないと知っていること」を明らかにしていくこと。 例えば、開発者が予習しておくべき要素やドメイン知識など。
問題は、「知らないと知らなかったこと」にぶつかった時。 これについて、事前に考慮したプロセスを組むことは不可能で、 イテレーションを回して解決する他ないようです。
長くなったのでサマリとしては、
この二つがアーキテクトには求められるようです。
Operations/DevOps
かつては、運用はコスト削減のためアウトソースの対象、という背景があり、
アーキテクトは、運用は外部委託すると言う制約に対して防御的になるしかなかった。
その結果として、SPACE-BASED-ARCHITECTUREというアーキテクチャが生まれたそうです。
柔軟なスケールを実現するためにESB-driven SOAなども考案されたが、複雑であり、運用を考慮していなかった。
運用の関心ごとは運用でハンドルすべき
マイクロサービススタイルを築き上げた人たちは、そのことに気づいたそうです。
アーキテクチャーと運用をうまく連携させることで、
シンプルなアーキテクチャと、適切な運用を実現した。
不適切な姿は無駄な複雑性を産んでしまう、と本書で述べられてます。
Process
ソフトウェア開発プロセスと、アーキテクチャが独立しているというのはナンセンスと言う話。
本書では、イテレーションを回しながら進めていくプロセスの重要性が語られています。
イテレーションのいいところは、再構築性が高い事。 そもそも、アーキテクチャ自体の変更はあり得る。 最初はモノリスで初めても、あとあとマイクロサービス にするなど。 逆にウォーターフォールでマイクロサービスは現実的ではないよね、という話も出ていました。
Data
外部データはアーキテクチャにとって無視できないよって話。 詳しくはChapter 3で。
ソフトウェアアーキテクチャの原理原則
▼ソフトウェアアーキテクチャの第一原理：
Everything in software architecture is a trade-off.
ソフトウェアアーキテクチャのすべては、トレードオフにある。
▼ソフトウェアアーキテクチャの第二原理：
Why is more important than how.
「なぜ」は「どうやって」よりも重要である。
本書では、トレードオフを踏まえた決定の背景にある「なぜ」
に注目していく、というところで第一章が締まります。
今回はここまで。
次回から、第二章に入ります。
英単語メモ
■agnostic (noun)
def: a person who believes that it is not possible to know whether God exists or not
XX-agnositc で「〜に依存しない」
■nemesis (noun)
def: the person or thing that causes somebody to lose their power, position, etc. and that cannot be avoided
■infuse A into B | infuse B with A (verb)
def: to make somebody/something have a particular quality
■nomenclature (noun)
def: a system of naming things, especially in a branch of science
■delve into (phrasal verb)
def: to try hard to find out more information about something
【読書メモ】Fundamentals of Software Architecture ~第一章 Introduction~ (1)
『Fundamentals of Software Architecture: An Engineering Approach』(以下、FoSA)の読書メモ、今回は第一章 Introductionです。
そもそもソフトウェアアーキテクトとは何なのか。
本章の始まりは、「ソフトウェアアーキテクトは人気職種の一つだが、それになるための明確な道筋がないのはなぜか？」という問いから始まります。
対比として、ナース・プラクティショナーやファイナンス・マネージャも人気の職だが、キャリアパスが明確にあると例示されています。アーキテクトは学位だったり資格を取ればまずはokという訳ではないと言うことが言いたいのだと思います。
さて問いに戻ると、4つの理由が本章では提示されています。
- ソフトウェアアーキテクチャについての明確な定義がない
- 担う責任範囲が広い
- ソフトウェア開発のエコシステムが急激に進化している
- 時代依存が強い
ひとまず、アーキテクトという職に正解はないという事なのだと雑に理解。 このセクションで印象的だった箇所を引用します。
“Hey, I have a great idea for a revolutionary style of architecture, where each service runs on its own isolated machinery, with its own dedicated database (describing what we now know as microservices). So, that means I’ll need 50 licenses for Windows, another 30 application server licenses, and at least 50 database server licenses.”
(Kindle の位置No.159-161). O'Reilly Media. Kindle 版.
これは、2002年にマイクロサービスを実現しようとしたら、どうなるかという例です。 アーキテクチャ的な"正しさ"は、時代や状況(文脈)に依存するとはどういう事か、 なるほどこれはイメージしやすいと思いました。
Because everything changes, including foundations upon which we make decisions, architects should reexamine some core axioms that informed earlier writing about software architecture. (Kindle の位置No.153-154). O'Reilly Media. Kindle 版.
"正しさ"すらも変化する中で、良い姿を検討・検証することがアーキテクトの責務だと一旦理解して読み進めていきます。
ソフトウェアアーキテクチャを定義づける
アーキテクト がアーキテクチャを分析するとき、”何”を分析しているのか？ 本セクションではこの問いを通じて、ソフトウェアアーキテクチャとは何か定義しています。
本書の定義によれば、ソフトウェアアーキテクチャは、
以下の3つを組み合わせた「システムの構造(Structure of the system)」
・アーキテクチャ特性(Architecture characteristics)
・アーキテクチャの決定(Architecture decisions)
・設計原則 (Design principles)
によって構成されるとされています。 以下、それぞれ詳細に触れていきます。
システムの構造
システムの構造は、アーキテクチャスタイルとも言われ、例えば microservices・layerd・microkernel といったもの。ただし、これだけではソフトウェアアーキテクチャ全体を言い表せないことに注意。 Architecture characteristics・Architecture decisions・Design principlesを理解して初めて、アーキテクチャを理解したと言える。
アーキテクチャ特性(Architecture characteristics)
一言で言うと、ソフトウェアを成功に導くための基準。 例えば、可用性・スケーラビリティ・信頼性など。
アーキテクチャの決定(Architecture decisions)
一言で言うと、システムがどう構築されるべきか定めるルール。 例えば、ビジネス層とサービス層のみがDBにアクセスできる、など。 アーキテクチャの決定は、システムに制約を設け、何が許容され許容されないかを開発者に指示するもの。
何らかの制約や条件によって、アーキテクチャの決定に則った実装ができないこともある。 そういった例外については、ARB(アーキテクチャ・レビュー・ボード)もしくはチーフアーキテクト により、 トレードオフの分析・検討を経て承認・却下されるべき。
※ARB: 組織横断的に構成される、アーキテクチャに関する意思決定機関。部門・企業を跨がり、経営層・パートナー企業・ステークホルダーから参加する。
設計原則 (Design principles)
一言で言うと、好ましい方法を示すためのガイドライン。 例えば、マイクロサービスのサービス間通信はパフォーマンスを高めるために非同期であること、という指針。 アーキテクチャの決定で、全ての条件・オプションをカバーするのは難しい。 代わりに、開発者が適切な選択をできるようにガイドラインを決めておくのが設計原則。
アーキテクトに求められる8つのこと
1. アーキテクチャの決定を作ること
アーキテクトとして、技術の選択ではなく、アーキテクチャの決定を作りチームを導くことが重要。 ただ、アーキテクチャ特性を維持するために、特定の技術を決定することもある。 アーキテクチャの決定については、19章で触れるよう。
2 継続的にアーキテクチャを分析すること
ビジネス・テクノロジーの変化に対して、過去に作られたアーキテクチャが現在もどれだけか、 構造に老朽化していないか分析すること。 また、テスト・リリースの環境についても考慮が必要。
3. 最新のトレンドから遅れをとらないこと
開発者が利用技術を追うことが必要なのに対し、アーキテクトは技術的・ビジネス的なトレンドを追うことが求められる。 アーキテクトの判断は、長期間影響し続け、一度決めたら容易に変更できないため、 間違った判断はよりクリティカルになる。
4. アーキテクチャの決定と設計原理が遵守されていることを確かめる
なんらかの理由によりアーキテクチャの決定に違反する実装が行われる可能性は0ではない。 例えば、パフォーマンスの問題から、プレゼンテーション層からDBアクセスしようとする開発者がいるかもしれない。 実装がアーキテクチャの決定に基づいているか確認することもアーキテクトの責務。
5. 多様なテクノロジー・フレームワーク・プラットフォーム・環境に触れること
深く知っているより、幅広く知識を持っていることが重要。 1のプロダクトのエキスパートであるよりも、10のプロダクトのpros/consを理解している方が アーキテクトにとって有益。
6. ビジネスドメインの知識を持つこと
アーキテクトがビジネスドメインについて理解していると、 ステークホルダーや経営陣とコミュニケーション取るのに有効に働く
7. 対人能力を持つこと
ジェラルド・ワインバーグが言う様に、"No Matter What They Tell You, It's a People Problem"、 つまり解決すべきは「人間が抱える問題」であり「技術的な問題解決」は手段にすぎない。 チームビルディング・ファシリテート力・リーダーシップなどのスキルを持つことはアーキテクトとして重要。
8. 企業の政治的風土を理解しナビゲートする
アーキテクトがどんなに素晴らしいアーキテクチャを設計しても、 それが現場で承認されなければ意味をなさない。 アーキテクトの決定は、コストや労力を伴う。 その時にプロジェクトマネージャ・ステークホルダー・開発者と交渉・説得することが求められる。 交渉力はアーキテクトに求められる能力の一つであり、23章で詳しく記されている。
今回はここまで。
英単語メモ
■elucidate (verb)
def: to make something clearer by explaining it more fully
synonym: explain
■hard-and-fast (adj)
def: definite and not to be changed, avoided, or ignored
■fool’s errand (noun)
def: a task that has no hope of being done successfully
■viable (adj)
def: that can be done; that will be successful
synonym: feasible
【読書メモ】Fundamentals of Software Architecture ~はじめに~
ソフトウェアアーキテクチャについて勉強してみたいと思い、『Fundamentals of Software Architecture: An Engineering Approach』(以下、FoSA)という本を買ってみました。
どうやら400ページくらいあるらしい。。。(しかも英語) このままだと、kindleアプリの中でデジタル文鎮になることでしょう。
と言う事で、少しづつまとめをアウトプットしながら読み進めようと決めました。 目次を見ると24章あるので、 各章につき1記事くらいのペースになる感じでしょうか。
初回の本記事では、FoSAを読み進める上での前提を確認していきます。
誰が書いたのか
FoSAの著者は、Mark RichardsとNeal Fordの2人です。 この二人が、どんなバックグラウンドを持ちFoSAを執筆したのか、 FoSA公式ページに掲載されているプロフィールを元に簡単にまとめます。
Mark Richards
マーク氏は、30年以上アーキテクトとして経験を積み、マイクロサービス・サービス指向アーキテクチャの構築・運用に20年以上携わる。 また、執筆・登壇・トレーナーとして活動し、developertoarchitect.comというウェブサイトの創設者でもある。 developertoarchitect.comでは、開発者からアーキテクトになるためのコンテンツが提供されている。
Neal Ford
ニール氏は、ThoughtWorks社でアーキテクト・ディレクター・ミームラングラー(ニール氏による造語)として勤務。 大規模エンタープライズアプリケーションの設計と構築に関してコンサルティングを行う。 アジャイル開発とアーキテクチャに関するエキスパートとして、国際的に知られている。
ThoughtWorks社といえば、Technology Radarを出している企業ですね。 和訳されているニール氏の著書として、『進化的アーキテクチャ』などがあります。
なぜ書いたのか
本の紹介文と序文を読むに、 この2点について問題意識があるようです。
1つ目については、第一章で詳しく取り上げられているので、次の記事で触れたいと思います。
2つ目について、序章に "Invalidating Axioms" という副題がついている点に注目しました。 まずは、Axiomの意味をOxford英英辞書で調べます。
a statement or proposition which is regarded as being established, accepted, or self-evidently true.
「自明で、確立された命題/定理」
Invalidating Axiomsは「確立していたものが、無効なものになっている」という意味になりそうです。
この序文の副題から、「かつて良いとされてきたアーキテクチャに対する認識を変えないといけない」という 著者らのメッセージがあると自分は理解しました。
また、タイトルの「Fundamentals」は、 土台とこれからのアーキテクトに向けたガイドを作る という著者らの目的意識が現れているのだと思います。
終わりに (この本を通じて、何が得られるのか)
公式ページによると、本書では以下の要素について記されているようです。
序文の中で、 This book won't make someone a software architecht overngint
と明言されていることから、入門書やHowTo本ではなさそうです。 ボリュームも内容もヘビーな感じがしますが、頑張って読んでいこうと思います。
