コーヒーから抹茶に乗り換えたら体調がすごく良い件
あけましておめでとうございます(?)
タイトルの通りです。毎日コーヒー飲むのをやめました。
これまで、仙台の某コーヒー豆屋さんから仕入れた美味しい豆をミルで挽いて毎朝淹れて飲んでいました（出社時は近所のコンビニやカフェでコーヒーを買って飲みながら仕事していました）。
去年の年の暮れ、キッチン周りの片付けをしていたら、コロナ禍が始まった直後に買ったと思われる、伊藤園の抹茶粉末（未開封・賞味期限切れ）が発掘されます。おそらく、抹茶系のお菓子を作るつもりで買ったんだと思いますが、あんまり覚えてないです。
未開封だし賞味期限切れてても飲めるだろうということで、飲みきるまでのつもりで毎朝飲んでいるコーヒーをやめて抹茶に切り替たのですが、それをきっかけに抹茶にハマってしまいました。賞味期限切れの抹茶を飲み干したので、今度は伊右衛門の抹茶を飲んでます。
緑茶の粉末と何が違うのかわからないんですが、ほのかに出汁っぽい風味とあの香りに非常に癒やされるというか…あと、コーヒーの甘い香りとも違って、ホッとするというか。それと、コーヒー飲んだ直後のシャッキリ感も穏やかというか、まぁそんな感じを気に入ってしまったんでしょうね。
まぁそんな感じでコーヒー派から抹茶派になったわけですが、副次的な効果として、体調の改善が見られました。私のようなお腹ヨワヨワマンならわかっていただけると思うのですが、コーヒーって飲んだあとだいたいお腹ぐるぐる来ますよね。あれが結構辛くて、1日1杯を上限に意識してました（コーヒー自体は大好きなので、可能であればいくらでも飲みたいのですが）。しかし、それがないので、いくらでも飲めてしまう。それでいてトイレの心配がなくなる（水分なので前は近くなりますが…）。
ということで、今後もしばらく仕事中は抹茶を飲んでいこうと思います。
ハマりすぎて、仙台の茶室を調べてしまってます。1回くらい、教養として、茶道やってみたいですね…
2021年買ってよかったもの3選
今週のお題「買ってよかった2021」
今年もこんな季節になりましたね。
カードの利用明細を見ながら、今年のベストバイを振り返ります。
スキー
スキーに行くときは大体実家経由で蔵王温泉スキー場に行っていたので、高校の部活（アルペンスキー部でした）用に仕入れた、10年以上前に買ったサロモンのGS用の板かクナイスルのSL用の板と、ロシニョールの競技用ブーツを使っていたのですが、せっかく宮城側にいるのだから、山形経由しなくても宮城側のゲレンデでも遊べるように、新調しました。
買った板は、Fischerのロッカー「PRO MT PULSE」の2018-2019年モデル。楽天で2万円でビンディングセットを購入してます。ちなみに、ブーツはハードオフでたまたま見かけたロシニョールのブーツです。これは5000円くらいだったかな。ガチで競技をやるわけではないので、中古で十分です。
www.instagram.com
これで宮城側のゲレンデにも行けるようになったのですが、雪質などの関係で、結局山形側に行くことが多いです。
キャンプ道具 + 新しいバイク
10年前にバイク乗り始めてからずーっとやってみたかったソロキャン。会社の人からソロ用テントをもらったこともあり、今年こそ始めようと一念発起し、登山用に持っていた道具以外の足りないものを買い足して、秋に秋田へソロキャンしてくることができました。今年は１回しかできなかったので、来年はもうちょっとソロキャンできるといいな。
道具とかバイクのことは、ここに買いたので、割愛します。
しかし、7月に修理に出したバイクが帰ってこないまま雪が降りシーズンオフになっちゃいました…まぁ、来年ですね。
ポストイット
最後に、仕事関係。
基本的に仕事のToDoは、瑣末なものであれば脳内キャッシュにスタックさせておき、プロジェクト関係のToDoはZenHubに、プロジェクトに関係しない会社関係のToDoはMacのリマインダーに記録していました。
となると問題になるのは一覧性。いろんなToDoが散り散りになってしまい、ぽろぽろ漏れるようになってきていました。また、ToDo管理で陥りがちな、ToDo化することで脳のメモリを解放した結果、やること自体を忘れてしまうということも起きてしまいました。
なので、原点回帰として、ポストイットに全てのToDoを書き出して、自宅の書斎のモニター裏の壁に貼って管理するようにしました（プロジェクト関係のToDoはZenHubにも書き出す必要があり、若干手間ではありますが、やること自体を忘れることがなくなり、めちゃめちゃいい感じです。
ToDo管理の原則は 「いつも目に留まるところにある」 ことだと再認識したのでした（ZenHubとかリマインダーは、自分から見に行かないと見れないので、あんまり良くない）。
まとめ
こんな感じです。今年もありがとうございました。来年もよろしくお願いします。来年の抱負は、建てないでおきます。
Atomic Design を実装におけるコンポーネント分類手法として利用するのは悪手なのでは説
前提条件として 、 Atomic Design はデザイナーであるブラッド・フロスト氏が考えた デザインシステム だ。
フロントエンド開発者は、Atomic Design の概念をソフトウェア開発に持ち込み、デザイナーとのユビキタス言語とすることで、アジャイル開発におけるデザイナーとの早期コラボレーションを 実現している 目指している。
一方で、Atomic Design の考え方は、開発者なら誰もが耳にしたことがある DDD (ドメイン駆動開発 ) や クリーンアーキテクチャを強く想起させる。
※上記ブログより引用
こちらのブログで紹介されている Onion Architecture がまさに、 Atomic Design の概念に親しい。
※ブラッド・フロスト氏の記事より引用
よって、以下のような記事は、非常に合理的な考え方に見える。
だがしかし、見逃しがちな Atomic Design と Onion Architecture の違いは、ブラッド・フロスト氏の別なブログで記載されている以下の一文に集約される。
Organisms are relatively complex UI components composed of groups of molecules and/or atoms and/or other organisms.
日本語訳すると 「Organismsは、Molecules・Atoms・他の Organismsから構成された、比較的複雑なUIコンポーネント」 だ 。つまり、 Organisms は Organisms に依存される可能性がある。これではクリーンアーキテクチャと言うことは難しい。これが、意外と知られておらず、実装者の理解によって、 Organisms が Organisms を依存している構造が許容されたりされなかったりする。
正直、この点はよく目にする「このコンポーネント、Molecules にすべきか Atoms にするか論」よりも、よっぽど問題だと思っている。
もちろん、このルールを拡張して、Organismsは他のOrganismsを利用しないようにするという規約で縛ることでクリーンアーキテクチャ然に使うことはできるかもしれないが、基礎的な設計では Atomic Design はクリーンアーキテクチャにはなりえないと言える。
にもかかわらず、バズワード的に Atomic Design という言葉が広まったことで、属人的な理解の側面が強いまま、コンポーネント分類手法として広く定着してしまった。
このことから、食べログの note で紹介されたような、独自のコンポーネント分割を行うアプローチの事例も散発的に目に留まることが増えてきた。
再掲になるが、上記記事でも言及されている通り、 Atomic Design はあくまで デザインシステム であり、ロジック実装に関する事柄には触れられていない。
この辺の、どう捉えるべきかに余地がある（抽象度の高い）概念は拡張性がある一方、誤解を生みやすく、開発を始める前や、新規メンバーが参画した際の適切なインストールを行う必要がある。また、カスタマイズする場合はなおさらインストールが大変になることに注意した方がよさそうだ。
（特に、使う言葉が同じなので、言葉の上では「理解したつもり／共有したつもり」という誤解が生まれやすいのでなおさら厄介なのです）
なので、ぼんやり思っているのが、 Atomic Design の概念を拡張する 場合でも、格コンポーネントの分類をする際に名称を変えた方がいいのではないかということだ。
例えば、Atomic Designが原子物理学の比喩表現なので、工学の比喩表現（特にクルマ）を使ってみると、こんな感じに言い換えることができる。
| 原子物理学 | 工学 | 備考 |
|---|---|---|
| Atoms | Parts | これ以上分解できない部品（例：ギア・ギアボックスケース・タイヤ・ホイール） |
| Molecules | Assemblies | 部品が組み合わさって構築されたそれ単体では機能が提供できない組み合わせ（＝ASSY）（例：トランスミッション・タイヤがホイールに取り付けられた状態） |
| Organisms | Mechanisms | 部品やASSYが組み合わされてできた、それら単体で動作する機構（例：エンジン） |
| （該当なし） | Units | 部品、ASSY、機構で構成された、もう少し大きい粒度（例：エンジン＋トランスミッション＋プロペラシャフト＋デフ＋ドライブシャフト＋タイヤ） |
| Templates | Templates | この辺は提供する媒体（Webなのか紙なのか、はたまたクルマなのか）に引っ張られる。フロントエンドなので、Templateのまま |
| Pages | Pages | 同上 |
とまぁこんな感じ。
結論は、ラベリングし直しただけなんだが、 Units 層を加えたことで、クリーンアーキテクチャとまでは言わないが、依存関係は一方通行にすることができるようになった。
個人的にこの比喩表現が気に入ったのは、アプリケーションもまた工業製品であり、工学との相性のほうがいいのではないか、というところ。
デザイナーと会話する際はAtomic Designに翻訳して会話し、エンジニア間はまた別な意味合いのレイヤリングで会話することになるので万事が解決するわけではないが、対応表まで用意してあげればある程度問題にはならないのではないかと思う。
他にも、天体物理学の比喩表現も考えたが、「Atoms（チリ）が集まって高密度になったところが恒星になる（核融合反応で炎上する）」というのがあまりソフトウェア工学との相性が良くないので考えるのをやめた。（燃えるという点が縁起が悪い。なにより、わかりづらく、燃えた後に冷えていくというのはソフトウェア工学的に悪手の考え方。。。まぁ、炎上プロジェクトを冷やしにかかる時は有効かもね。。。）
11/22 追記
BCD Design というコンポーネント分類手法があるらしい。
atoms (Base) と molecules (Common) という粒度だけを共通の基底コンポーネントとし、命名規則とユースケースでDomain 別のコンポーネントを作る概念。新たに携わるプロジェクトで試してみよう。
朝会のない人だけで朝会をやってみることにした
現職で、今までプロジェクト単位で朝会をしていたが、いろいろあって、朝会の時間がない人が出てきている。
自分もその中の一人なのだが、その人とたまたま雑談する機会があったので、その際に「もう俺らで朝会してみませんか？」と提案されたので、明日からやることにした。今回は、やってみますという宣言のみ。
どういう結果につながるかちょっと楽しみ。
余談
毎日インスタに撮った写真はアップできてるけど、毎日ブログ書くって結構しんどい。
できれば統一したいけど、やってる目的が微妙に違うから難しい。
