なっぱ箱

ゲームとか読書の感想とか時々技術系の話とか

初売りでMacBookProを買ったから最初にした設定をまとめておく

夫婦で初売りの時にMacBookProを購入しました。勢いって大事。

スペックは夫婦ともに同じく2018年モデル13インチTouchBar付きのメモリだけ16GBにアップ。 ただ自分だけUSキーボード。買ったからには慣れるしかない。

2人ともMacの所持がはじめてのWin使いなので、念のため最初に行った設定をちょっとまとめておく。 なにかおすすめのアプリとか設定等あったら教えてくれると嬉しい。

Google日本語入力

macOSの日本語入力を少し試してみたけどなんかしっくり来なかったのでGoogleさんを憑依させる。

https://www.google.co.jp/ime/

かな/英数切替キー設定

ものは試しということでUS配列にしたので左右のCommandキーにそれぞれ切替キーを設定。まずはKrabinerをインストール。

https://pqrs.org/osx/karabiner/

インストールしたらKarabinerを起動して「Complex Modifications」の左下にある「Add rule」を開く。

f:id:b7472:20190110222548p:plain

「コマンドキーを単体で押したときに、英数。かなキーを送信する」を「Enable」にする。 「For Japanese」のメニューが無いときは「Import more rules from the Internet」から追加すること。

f:id:b7472:20190110222932p:plain

Homebrew

Win使いがUsageを見たときにbrew install hogehogeしか書いてないと目からハイライトが消えるHomebrew。

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

トラックパッドの設定変更

「システム環境設定」→「トラックパッド」から「ポイントとクリック」の軌跡の速さを最速に。

f:id:b7472:20190110225445p:plain

バッテリーのパーセンテージ表示

アイコンだけじゃわからんのでパーセンテージも表示する。

f:id:b7472:20190110224915p:plain

日付の表示

日付はちょくちょく脳内メモリから消えるので表示するようにしておく。

「システム環境設定」→「日付と時刻」から「時計」の「日付の表示」をON。

f:id:b7472:20190110225133p:plain

コンピュータ名の設定

デフォルトの名前が適当なので変更。結果適当だけど。

「システム環境設定」→「共有」からコンピュータ名を変更。

f:id:b7472:20190110225853p:plain

Finderの設定

いくつか設定変更。

拡張子を表示

Finderを起動して「Finder」→「環境設定」→「詳細」から「すべてのファイル名拡張子を表示」をON。

f:id:b7472:20190110230405p:plain

各種情報を表示

Finderを起動して「表示」→「タブバー」「パスバー」「ステータスバー」を表示。

f:id:b7472:20190110230517p:plain

Docの設定

Docさんは自動的に非表示にしましょう。

「システム環境設定」→「Doc」から「Docを自動的に表示/非表示」をON。

f:id:b7472:20190110230809p:plain

ファイヤウォールをON

「システム環境設定」→「セキュリティとプライバシー」から「ファイヤウォール」をON。

セキュリティソフトは後で調べとく。

f:id:b7472:20190110231520p:plain

Night ShiftをON

目に優しく。

「システム環境設定」→「ディスプレイ」から「Night Shift」を「日の入りから日の出まで」で設定。 ※とりあえずお試し

f:id:b7472:20190110231852p:plain

その他アプリ

開発環境系は後回し。

じぶん Release Notes (ver 0.31.12)

なっぱ(ver 0.31.12)がリリースされました。更新内容は下記のとおりです。

技術関連

  • Vue + Firebaseで即席アプリを作成しました
    • クイズ大会用早押ボタンに使用
    • ユーザー登録、ボタン押下履歴管理、得点管理
  • AtCoderに入門しました
    • とりあえず過去問を少しづつ解いています
    • 回答言語はRust/Go
    • 実行環境はDockerで用意

github.com

着手済未完了

イベント

  • 前撮りを行いました
  • お互いの両親の顔合わせを行いました
  • 友人たちとクリスマス会を行いました
  • Perfumeのライブに参加してきました

買物

ゲーム

クリア

なお、次のタイトルはパーティーゲーム、またはその他用のため購入時点でクリアしたものとして扱います。

プレイ中

積み中

読書

読了

読書中

アウトプット

ふりかえり

Keep

  • 結婚式と新婚旅行以外の婚姻イベントはこれでおおむね終了することができた
  • 色々とイベントが立て込んでいたがクリスマス会幹事をこなすことができた
  • 業務以外で毎日なにかしら技術的に手を動かすことができた
  • 軽く触った程度だがFirebaseに入門をすることができた
    • 実際に作成したクイズ早押ボタンをクリスマス会に活用することができた
  • Fit Boxingで運動を日課にし始めることができた
  • 憧れの生ハム原木を購入することができた

Problem

  • 11月に引き続き教習所へあまり行けなかった
    • イベントが重なってしまい時間がなかった
  • ブログエントリをまったく書くことができなかった
  • やろうと思っていた技術的なTryに着手することができなかった
  • 生ハム原木が思ったより場所を取ってしまっている

Try

  • 技術系
  • 1月中旬から教習所が激混みするので、可能な限り勧めておく
  • Fit Boxingを継続する

2018年のふりかえりと2019年の目標

気がついたらあっという間に年末飛び越えて新年ですよ……早すぎ…意味分かんない……ブログ書こ…。

とりあえず分野別に2018年を振り返ってから簡単に2019年の目標をたててみる。

結婚

🎉🎉わたくしなっぱ、2018年9月16日に入籍いたしました🎉🎉

とにかく2018年で一番のメインイベントといえばこれ。 数年前の自分に「お前数年後結婚するよ」と言ってもきっと信用しなかっただろうなぁ。結婚はタイミングというのを身をもって体験した感じ。

すでに同棲していたのでとくに大きな変化があったわけではないんだけれども、長い人生の中ではかなりデカめのターニングポイントでした。(奥様は改姓したのでそのあたりの手続きとかもろもろご苦労様でした…)

式はまだ未定。ただ12月には前撮りをしたので、写真としてそれっぽい記録は残せたのかなと。 前撮りは自分たちでスタジオを借り、知り合いのカメラマンさんに撮影をお願いしたのでなかなか自由な感じて撮ることができました。このとき平日にもかかわらず手伝ってくれた友人夫婦にはもう感謝しかない。自分たちだけでは絶対キャパオーバーになっていたのは間違いない。

結婚指輪については自作できるお店で作成してみたので(ワックスで型だけ作って鋳造以降は職人さん)、このあたりは来年振り返って記事書いてみようと思う。ものづくりが好き、かつお金を抑えたい人にはオススメ。

なにはともあれこれで一人だけの人生ではなくなったので、これからはより(無理しない程度に面白おかしく)頑張っていこうと思います。

体調

2018年は今までになく体調がよろしくない年でした。

始まりは春くらいに腹部とか背中の違和感があったことからなんだけれども、そこからピロリ菌の除去、謎の背部痛からくる膵臓癌疑惑への恐怖、CTなどの各種検査、胃酸過多疑惑からのプロトンポンプ阻害薬の処方…。

結果から言うと症状は多少落ち着いた程度で完治はしていないんだけども、各種検査や健康診断を受けてもとくに引っかかることもなかったので、大病の心配はなさそうです。原因がわかっているわけではないのがもにょる所だけど。

医者に「内臓は大丈夫そうですね。というか癌にビビるくらいならダイエットしたほうがいいです(改変なし)」って言われたのでダイエット頑張ります。はい。

技術関連

GitHub Public Contributions

Powered by grass-graph

ぼちぼち、かなぁ?

ちょこちょこ学習用にコミットしてたのとPixelast、あとはNESエミュ関連ってところ。OSSへの貢献としてはBoostnoteにちょこっとしてPRを2つだけなので微妙。2017年はPR4つだったので半減。2019年は頑張りたい所存。

技術振り返り

大雑把に振り返るとこんな感じ。 手は出していてもアウトプットに乏しいのが残念。

  • 言語
    • Rust
      • 今までに手を出したことのないジャンルとしてNES HelloWolrdを作成できた
      • 自分の中で情報を追っかける言語という立ち位置に収まった
    • Go
      • 改めて再入門。せいぜいNESスプライト抽出機くらいしか作れていないけど
  • フレームワーク
    • React/ReactNative/expo
      • まだTutorial+α程度
    • Vue
      • 業務で小さいのを1つ作成。Vuex使用しない程度のもの
  • クラウドサービス
    • Firebase
      • 手を出すのがおそすぎた感はある
      • クリスマス会のクイズ大会用早押ボタン作成
    • Azure
      • 業務で一部分に使用している程度
    • AWS
  • その他
    • ちょこちょこAtCoderの過去問解いている。2019年はコンテストチャレンジしたい所
    • Kaggleでタイタニック問題試してみたけどそれっきり

ゲーム

2018年に購入したゲーム一覧。

こうしてみると結構買ってるなぁ…とくにSwitchのソフトを買いまくってる。インディーズゲーが安くて魅力的だから困る。

各ゲームについては別記事でまとめたい所。

読書

2018年に(漫画を抜かして)読んだ本一覧。

結果は4冊。だいぶ少ない。DDD本でだいぶ時間がかかった感ある。 2019年は技術本以外で軽めなやつをサクサク読んでいきたいと思う。

調理

2018年に取り扱ったちょっと珍しい、もしくははじめて扱う食材。

  • 生ハム原木
    • クリスマス会で提供。まさかの購入実績を解除。処理や管理を経験
  • ヒラメ
    • 都合3匹捌く。これですき引きと5枚おろしを経験
  • マグロの尾
    • これはステーキに。安くて美味しい
  • 本マグロ中骨
    • 晦日に購入。マグロマートで出てくるアレ
    • 調理も何もないけど一般家庭で買うことは稀だと思うので
  • 活アナゴ
    • 自力で開きに。かなり難しかったので要修行
  • オーロラサーモン
    • フィーレ(半身)で購入したブランド物のサーモン。うまいけど油がなかなかすごい

www.instagram.com

2018年総評

やりたいことやりきったかと言われれば微妙なんだけれども、結婚もしていろいろなイベントもこなしてかなり満足できる年だったかと思う。ブログを書く習慣もちょっとついてきたし。ただ技術的なアウトプットはまだ全然なので、そのあたりは来年改善してきたい。

とにかく体調不良によるモチベーション低下がかなりきつかったので、健康の大事さを改めて感じた…いやほんと。今まで長期で病気なり体調不良になったことがないのでちょっと甘く見ていた。30歳過ぎたあと体に突然ガタが来るってのは本当なんで、20代の皆様におかれましては健康を維持する努力を今からしておくことをオススメします。

まぁこれを言われて「よし頑張ろう!」ってなるような人はすでに健康に気を使っていると思うけど。

本当は観劇についてとか色々あるんだけど、長すぎちゃうのでまたの機会に。

2019年目標

2019年の目標としてはこんな感じ。

  • プライベート
    • 田舎へ移住して生活基盤を整える(リモート可能な職場へ転職)
    • 健康的なレベルまでダイエット
    • 新しい趣味を1つふやす
    • 英語のレベルをもう少し実用レベルに上げる
  • 技術
    • アップデートされていないコンテナ技術の知識を最勉強
    • MBP買う予定なので、せっかくだからiOSアプリ作成
      • なんだかんだ実機で稼働するものは作ったことない
    • 低レイヤの知識を得る
    • NESエミュとGBエミュ作る

大雑把だけど今思いついたのだとこんな所。

移住と転職はほぼ確でこれから動くのでバタバタしますが、友人の皆様に置かれましては2018年と変わらぬお引き立てのほど、よろしくお願い申し上げます。

なお、新年のFGOガチャは大勝利でしたことをここにご報告いたします。

f:id:b7472:20190101161608p:plainf:id:b7472:20190101161615p:plain

育てなきゃ・・・

じぶん Release Notes (ver 0.31.11)

なっぱ(ver 0.31.11)がリリースされました。更新内容は下記のとおりです。

技術関連

着手済未完了

イベント

買物

ゲーム

クリア

プレイ中

読書

読了

読書中

アウトプット

ふりかえり

Keep

  • 長々と読んでいたDDD本を読み終わらせることができた
  • RTAにチャレンジすることができた
  • ポケモンピカチュウ、undertale共に積むことなく全クリすることができた
    • 特にポケモンは図鑑を完成させることができた
    • 今回は楽になってるとはいえ、自力で図鑑完成は初の快挙🎉
  • ウォーキングだけでなくランニングをするようになった
  • 少しだが家事の改善を行った
    • 「人生が整う家事の習慣」を参考に

Problem

  • 教習所にあまり行けなかった
    • 教習所のシステムリニューアルがあったので仕方ないが・・・
  • 技術系のアウトプットが全然できていなかった
    • Pixelastの更新もできていない
  • もともと書こうと思っていたブログ記事が書けていない
    • LS Miniの導入について
    • crateの公開手順書
    • ロックマン11感想
  • NESエミュレータHelloWorldが全然速度出ていなかった

Try

  • 技術系
  • ゲームの感想を簡単にシェアできる方法、サービスを検討する
  • 教習は2段階後半まで進めたい
  • 来月も何作品かゲームが出るので積まないように気を付ける

ポケモンでRTAの一端に触れてみた

いつか自分もやってみたいなーと思っていたRTAに初チャレンジしたので感想をちょっと残しておく。

RTAとは

そもそもRTAって何?っていう人のために一応説明しておく。

RTA」は「Real Time Attack」の略で、ゲーム開始からクリアまでの実際の時間の短さ(ゲーム内時間じゃなくて実際の時計の時間)を競うゲームのプレイスタイルの事。 よくある「タイムアタック」はゲーム内の時間(マリカーとかの最速タイムとか)を競うものだけど、RTAは実際の時間で計測するのが大きな違い。

ほかには言わずと知れた「TAS」があって、こちらは「Tool-Assisted Speedrun」の略。エミュレータ等を使って人間には不可能な操作して最速を競うというプレイスタイル。 エミュレータのクイックセーブを使っていい結果だけを残したり、メモリの中の値をみてエンカウントの調整したりしながら最速のプレイ結果を作って、最終的に最速の動画を作り上げる感じ。

今回やってみたRTA

今回は懐かしき「ポケットモンスター ピカチュウ版」をチョイス。ノイズ交じりの「ピッカー!(鳴き声)」がすげー懐かしい。 なお、選んだ理由としては下記の通り。

  • プレイ時間が2-3時間程度
  • アクションゲームじゃないから練習しなくてもとりあえずできそう
  • ぐぐったらチャートがすぐ出てきた
    • チャートはゲームごとの手順書的なもの。先駆者の方々が残した「どういう手順でプレイすればいいのか」がまとめてある
  • 偶然3DSのVC版を持ってた(残ってたセーブデータ見てみたら最初の草むらで止まってた)

ちなみに今回使わせていただいたチャートがこちら

ポケモン ピカチュウ版チャート(並走用):青にいとのブロマガ - ブロマガ

一言でいうと「ニドキング無双」

  1. 開始してすぐにニドラン♂をゲット(トキワの森前)
  2. 序盤から中盤は「つのでつく」と「あばれる」で殲滅
  3. 中盤以降は豊富な技幅と必中化した「つのどりる」で殲滅
  4. 最終的にニドキング1体で殿堂入り

※初代(赤緑)と2代目(金銀)の「ヨクアタール」は技が必中になるのだ!!!一撃必殺技でも!!!ちゅよい!!!

同じピカチュウ版をニドキングで走ってる人の動画はこんな感じ。

www.nicovideo.jp

結果

クリアタイムは3時間17分でした。 普通は2時間30分は普通に切れるっぽいのでクッソ遅い。

テストプレイしてないのがもろに影響していて、ダンジョンの中身が頭に入ってなくて大苦戦。特にイワヤマトンネル(フラッシュ無しで進む)

ちなみに殿堂入りしたときのゲーム内時間はこんな感じ。

差が出てるのは鬼門であるカスミのスターミーに何回かやられて全滅してたから・・・バブルこうせんこっわ。

感想

なかなか普段やってるゲームとは違う感覚で遊べて新鮮だった。 しいていえばそれこそレースゲーのタイムアタックに似てるんだけど、レースゲーはスプリント、RTAはマラソンって感じ。 やってみるうえで独別な機材もいらないし、タイムアタック好きの人は一度試してみるといいと思う。完走したときの解放感はなかなか。

興味あるけど自分でやるのはちょっと・・・という人はRTA動画見てみるのをオススメ。 人間がやってるからミスがあったりするし、運要素でドラマがあったりするから見ていてドキドキハラハラできる。 TAS動画見て「すごいけど失敗しないの分かってるし物足りないなー」って感じる人には向いてると思う。

とりあえずすぐに別のソフトで走ってみる予定はないけど、またいずれ何かにチャレンジしてみようと思う。

読了: 人生が整う家事の習慣

本の概要

人生が整う 家事の習慣

人生が整う 家事の習慣

著者 本間朝子・藤原千秋・河野真希/監
ページ数 224ページ

内容

これまでの家事をリセット!家事の方法を見直して、効率のよい仕方、負担のない習慣をお教えします。

【本書の内容】
●一度やればずーっとラク!家事の棚卸し、家事の時間割
●人生が整う!掃除、洗濯、料理の新習慣
●できていない原因は家にあった...家事がしやすい家づくり

目次

  • 1章 家事を見える化する
  • 2章 家事を習慣化する
    • (掃除)
    • (片づけ)
    • (洗濯) 
    • (料理)
  • 3章 家事がしやすいおうちづくり

感想

Kindle Unlimited対象になってたのと自分の家事を見直すためにサクっと読んでみた。 内容としては基本「家事のコツ集」なんだけれども、方向性が「家事を習慣化させるためには」に絞ってある内容になっている。

  • 1章: 家事の全体を可視化し、全体のコントロールをできるようにする
  • 2章: いろいろな家事のコツを知る。各家事を効率化
  • 3章: 再度全体に立ち返って最適化

このような流れ。 2章で家事のコツをつまみ食いするだけでもいいし、1章から読んで家事を全体から最適化するのに使ってもいい。

イラストも多めで読みやすいし、ボリューム的にもライトなのでKindle Unlimitedユーザーで家事やる人はザっと目を通してみるといいと思う。

家事の習慣とは

タイトルにある通り家事を習慣化させるには、というのがこの本のメインテーマになるんだけども、 ここでいう「習慣」は定期的にやる、というより「日常生活の一部として意識しなくてもいいくらいになりましょうね」といった側面での意味合いが重要になる。

「週末には頑張ってまとめて家事するか・・・」のように気合を入れて頑張って家事をするんじゃなくて、 「朝起きる → 着替える → 歯を磨く → ついでに洗面所をかるく掃除 → 出かける」といった具合で日常の定例動作の一部にしてしまえ、というもの。

家事を習慣化させるためには

意識しなくていいくらいの習慣にするためには「家事をするための心理的/物理的ハードルを下げる」というのが必須になるんだけれども、そこを助けてくれるのが「家事のコツ」。 例えば紹介されてるコツの中に「汚れやすい場所に掃除用具を置く」というのがあるんだけれども、これは「すぐに手に取れるところにないと掃除しないから」というのが理由。

朝歯を磨いているときに、「あ、洗面台汚れてるな」と気付くひとは多いと思うけど、その場ですぐ掃除にとりかかれる人となると数は結構限られてくる。この場合実行に移せない心理的ハードルとしては「掃除用具を取りに行くのが面倒くさい」というのが大きなウェイトを占めてると思うので、最初からメラミンスポンジとかの掃除道具を洗面台のところに置いておく、というのが解決策。

この場合使い捨てできるものが向いていて、下手に普通のスポンジが置いてあるだけだと「使用後にきちんと水を絞る」「おいてある場所に水垢ができていないかチェック」などの余計な手間もかかってしまう。

  • 非習慣化家事
    1. 洗面所が汚れているのを発見
    2. 掃除道具を持って来なければならない
      • 持ってくるの面倒くさい。戻すことも考えると億劫
      • あきらめたら汚れが積み重なって掃除がさらに大変に
    3. なんとか持ってきて掃除
    4. 終わった後は掃除道具を綺麗にする
    5. さらに掃除道具をもとにもどす
  • 習慣化家事
    1. 洗面所が汚れているのを発見
    2. 目の前にあるメラミンスポンジを手に取る
    3. ササっと掃除
    4. 使ったものはゴミ箱にぽい

「こうするべき」という固定観念にとらわれない

これは「抜ける手は抜いて調理をラクにする」という項目の一文なんだけれども、これって家事全体でも同じことが言える事で、「トイレは毎日掃除しなきゃ耐えられない」なら別にいいんだけども「毎日トイレ掃除しなきゃいけないのつらい・・・でもそういうもんだし」っていうのはちょっと思考停止だよね、という。

不衛生にならないようにするのが目的なんだから、便器が汚れにくいようにグッズ使うなりして便器が汚れない状態が保てるなら毎日の掃除をやめてスパンを長くしてもいいわけだし、目的と状況に応じて工夫していくのが大事なのかなと。

ちなみにこれって一番闇が深いのが調理で、「料理は手間暇かかってなきゃいけない!」っていうのを調理する本人が固く信じ込んでいて疲弊していたりするのってよくあるし、家族とかからプレッシャー掛けられる場合が家事の中でもダントツだと思う。

ちょっと前にバズってた「彼女にはクックドゥ使ってほしくない」みたいなのとか。

この本をお勧めする人

すでに日常的に家事をしてる人が「もっと効率的に家事したいなー」とか「家事もっと楽にできないかなー」と思ったときに一度目を通すといいのかと。もしくはこれから家事を本格的にやり始める人決意ができた人が読んでも参考になると思う。

ただ、実用的な本であって自己啓発成分が薄いから「普段全然家事しない人」が読んでも「よし!習慣的に家事しよう!」みたいなことにはならなそう。 (こんな簡単なことでいいならやろうかな、という思考に至る可能性はあるけど)

読了: エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

DDDといえばこれ。読んでくじけちゃうやつ。 実際後半はくじけかけてた、というかきちんと理解できてないけどとりあえず読むだけ読んでみた感じ。

他にDDD関連本読んで基礎知識入れてからでないと前半で撃退されるのでは。

本当ならためになる部分とか自分の理解を書いたほうがいいんだろうけど、これはただの読了メモエントリなのでその辺は省略。IQ低めなざっくり感想と読書中のメモだけ張り付けておく。

目次

全4部の17章構成になっている

  • 第1部 ドメインモデルを機能させる
    • 第1章 知識をかみ砕く
    • 第2章 コミュニケーションと言語の使い方
    • 第3章 モデルと実装を結びつける
  • 第2部 モデル駆動設計の構成要素
    • 第4章 ドメインを隔離する
    • 第5章 ソフトウェアで表現されたモデル
    • 第6章 ドメインオブジェクトのライフサイクル
    • 第7章 言語を使用する:応用例
  • 第3部 より深い洞察へ向かうリファクタリング
  • 第4部 戦略的設計
    • 第14章 モデルの整合性を維持する
    • 第15章 蒸留
    • 第16章 大規模な構造
    • 第17章 戦略をまとめ上げる

まえがきでは2.3.4.9.14章は読むべきである。と案内している。 全部読もうとして挫折するくらいだったら、いったんおすすめされてる章だけ読むだけでもいいと思う。

ざっくり感想

  • 非常にためになる。ためになるがハイカロリー
    • DDDに関心があるならぜひ1度読んでおきたい
    • ただ内容がとても難しい・・・意識を強く持たないと読んでるけど頭に入ってこない状態になりがち
  • 読了後はできればだれかと議論したほうがいい
    • 内容が複雑、多岐にわたることもあって個々人によって解釈や理解度がバラけそう - 読み終わった人同士で本持ち寄って議論できたりするとグッと理解が深まりそう
      • 輪読会なら最大値の効果が得られそうだけど、いかんせん会の継続運営難易度が高い
      • 特定の章に絞るとかならあり?
  • DDD入門で読もうと思ってる人はやめておいたほうがいい
    • 先に数冊DDD関連本読んでから戦うことをお勧めする
  • ある程度読み進めた後に自分のコード振り返ってみたら割と効果が出てた気がする

以下読書中の簡単なメモ

第1章

  • ドメインモデリングはモデルを写実するのではなく映画製作のように現実の概念を表現している
    • 不要な部分は見せない
    • 現実をすべてその通りに再現するのではない
  • モデルの有用性

    • モデルと設計の確信が相互に形成しあう
    • モデルはチームメンバの全員が使用する共通の言語である(ユビキタス言語)
    • モデルは蒸留された知識である
  • 効果的なモデリングの実装

    1. モデルと実装を紐づける
    2. モデルに基づいて言語を洗練させる
    3. 知識豊富なモデルを開発する
    4. モデルを蒸留する
    5. ブレインストーミングと実験を行う

第2章 コミュニケーションと言語の使い方

  • ユビキタス言語
    • ドメインエキスパートとエンジニアによって作成されたモデル(共通言語)
    • 使いにくい、不適切なものがあるときは随時見直さなければならない
    • ユビキタス言語における変更はすなわちモデルに他する変更となる
    • 専門用語が交差するところで高められる
      • 専門的なビジネス用語 -> ドメインエキスパートの領域
      • システム的な専門用語やデザインパターン -> エンジニアの領域
      • 業務用語、構造の用語やパターン名 -> 両方の領域

第3章 モデルと実装を結びつける

モデルと機能の紐づけが複雑だと理解が難しく、設計が変更された時に紐づけを維持できなくなることがある

第Ⅱ部

第4章 ドメインを隔離する

  • レイヤ化アーキテクチャ

    • 原則は「下にある」レイヤにしか依存しないという事
  • ユーザーインターフェース層(もしくはプレゼンテーション層)

    • 人間や別システムのコマンドを解釈
  • アプリケーション層
    • ビジネスに意味があるか別システムのアプリケーション層と相互作用するもの
    • この層は薄く保つ。やるべき作業の調整のみ
  • ドメイン
    • ビジネスの状況の反映を行う
    • その後のデータの永続化(DBへ保存)などはインフラ層
  • インフラストラクチャ層
    • 技術的機能の提供
      • アプリケーション層のメッセージ送信、ドメインの永続化等

第5層 ソフトウェアで表現されたモデル

  • エンティティと値オブジェクトの違い

    • エンティティは同一性を追跡できるもの
  • 値オブジェクト

    • 通販における「住所」
      • 同居人などが複数人が同一住所で注文したとしても、それが「同じ住所」であるかは関係ない
      • つまり同一性を追跡する必要はなく、値オブジェクトとなる
  • エンティティ
    • 電力提供事業者における「住所」
      • 「住居」に対して電気料金が発生する。住居を表す「住所」は同じ住所であれば同一とみなさなければいけない
      • つまり同一性を追跡する必要があり、エンティティとなる

第6層 ドメインオブジェクトのライフサイクル

  • ドメインの集約
    • 例: 自動車
      • 自動車/タイヤ/位置/といったエンティティになる
      • この時自動車エンティティがルートになり、外部からはタイヤを直接参照できない
    • こうして集約することで管理しやすくする
  • ファクトリパターン
    • 本来ドメイン層の責務だが、複雑化したオブジェクトや集約の生成を管理
    • デザパタなどで紹介されている
    • 不変条件をすべて満たすもののみ作成する。満たせない場合は作成不可。例外発生など
    • またファクトリは具象クラスではなく、型に応じて抽象化する
    • コンストラクタではだめなのか?
      • 単純である、かつコンストラクタ内でべつのコンストラクタを呼び出さなければよい
      • 複雑であればファクトリに任せたほうがよい
  • リポジトリパターン

第7層 言語を使用する

  • 集約をどのように分けるか
    • 参照用途などを考慮して経路を考える
    • 貨物 → 荷役イベントの場合は貨物に集約してもよさそうだが、輸送機器側からも参照される
      • その場合は独立すべき
    • リポジトリはそれぞれ集約のルートに対して作成される
  • 腐敗防止層
    • 別のアプリケーションなどと連携するとき、相手側のモデルをそのまま受け入れない
    • こちら側のモデルに変換する「腐敗防止層」を作成して噛ませるのが良い
  • エンタープライズセグメント
    • 理解できていない。あとから解説があるか?

第Ⅲ部

第9章 暗黙的な概念を明示的にする

  • オブジェクトの制約はそれ単品でモデル化した方がいい場合もある
  • 検索などでドメインにあるルールをクエリに適応しないと行けない場合はどうするべきか
    • リポジトリに汎用的なクエリビルダを設置して使用するのが良い

第10章 しなやかな設計

  • 意図の明確なインターフェイス
    • カプセル化しても別の人間が使うときに中身を見なければ理解できないのはだめ
  • 副作用のない関数
    • 既存オブジェクトには影響を与えず、新規オブジェクトを生成など
  • 表明
    • 事前条件や不変条件などを明確にコード化。テスト書いたり
  • 概念の輪郭
    • 読み直し
  • 独立したクラス
    • 依存関係が多くなればなるほど設計を理解する処理の負荷は大きくなる。クラス内の依存関係を可能な限り取り除き、プリミティブを使用することで単独で理解できるクラスになる
    • ただなんでもかんでもプリミティブにすればいいものではない
  • 閉じた操作
    • 戻り値と引数の型が同じであればそれはそのインスタンス集合の中で閉じていると言える

第11章 アナリシスパターンを適用する

  • アナリシスパターンはビジネスモデリングにおける共通の構造、概念のグループ。ドメイン一つの場合もあればまたぐこともある
  • 同一性によって定義されるオブジェクト=エンティティ
    • 例: 同日同金額同口座への振込=区別する必要があるエンティティ
    • 例: その取引の金額オブジェクト=区別する必要はない。エンティティではない
  • アナリシスパターンちゃんと調べる

第12章 デザインパターンをモデルに関係づける

  • ストラテジーパターンとは
    • デザインパターンをモデルに適応する場合はレイヤーを一つ増やす
    • 適応するパターンの考え方がドメインの概念に合うかを確認すること

第13章 より深い洞察へ向かうリファクタリング

  • ドメインに馴染む
  • 常に違う見方をする
  • ドメインエキスパートとの対話を途切れさせない

第Ⅳ部

第14章 モデルの整合性を維持する

  • モデルには統一性が必要
    • ただし巨大なシステムにおいてドメインモデルを完全に統一するこのとは現実的ではないし、コストに見合わない
    • これを無理にやろうとすると次のようなリスクがある
      1. 一度に多くのレガシーシステムを置き換えてしまうかもしれない
      2. 調整にかかるオーバーヘッドが限界を超えてしまうかもしれない。巨大なプロジェクトは身動きが取れない
      3. 特殊な要件の場合は要求を満たさないモデルを使うことになるかもしれない
      4. 単一モデルでどうにかしようとすると複雑になり使いづらい
  • モデルが適応されるコンテキストを明示的に定義すること
  • 境界はチーム編成、アプリケーションの特殊な用途、コードベースやスキーマ定義などの視点から行うこと
  • 偽同族語
    • 同じ言葉でも若干意味が違う
  • 腐敗防止層
    • レガシーなシステムの遺産を使わざるを得ない時に汚染されないためのレイヤー
    • ファサード、アダプタ、変換サービスで構成
    • ファサードが外部を直接操作。アダプタがメインシステムとの橋渡し。変換サービスが必要に応じて形式を変換

第15章 蒸留

  • リファクタリングする時どうするか
  • 全部ダメだからどこからやってもいい、はトッププログラマだけの集団でないと難しい、困ったところから、だと対処療法でしかない
  • 困った時にコアに関連するものであれば頑張って対応する。余裕があるときはコアの適切な抽出、サブドメインからの不純物除去がよい

第16章 大規模な構造

メモ消えてた

第17章 戦略をまとめ上げる

戦略的意思決定を行うために大事なこと

  • 意思決定はチーム全体に伝えなければならない
  • 意思決定プロセスはフィードバックを吸収しなければならない
  • 計画は進化を許容しなければならない
  • アーキテクチャチームが最も優秀な人材をすべて吸い上げてはならない
  • 戦略的設計にはミニマリズムと謙虚さが必要である
  • オブジェクトはスペシャリストだが開発者はジェネラリストである