Mistel BAROCCO MD650Lを自宅用に導入した

以前にKinesis Freestyle2を導入して、分割キーボードいいなーとなっていたのだがやはり机のサイズに比べてかなり大きいことが問題で。

raydive.hatenablog.jp

本を広げたりすることを考えるとやっぱりサイズ的には小さい方がいいよなーと、Mistel BAROCCO MD600もチェックし社内で使ってる人に触らせてもらったりしたが、キーボードの高さが微妙。

パームレストつければいいのだけど、机のスペースを空けたいのでどうするかしばらく悩んでいたのだけど、ロープロファイルなスイッチを使ったMD650Lがいつの間にかAmazonに売ってるのを発見して思わず買ってしまった。

この文章もMD650Lで書いているのだけど、腕が机で支えられる上に肩をすぼめなくてすむのでとてもいい。姿勢が悪いところはあるので、なるべく背筋を伸ばしてやっているが若干肩の張りがましになったかなぁと思う。何よりスペースが空くので、本を広げたりしながらキーボードを打つことができるのはほんとありがたい。めっちゃいいです。

Domain modelling made functional Chapter3を読む

raydive.hatenablog.jp

続き。

Chapter 3 A Functional Architecture

この章からドメインをソフトウェアアーキテクチャに変換していくところに入る。その前にソフトウェアアーキテクチャ自身もドメインだよねと、用語を定義するためにC4モデルを導入する。C4モデルの自分の理解としてはこんな感じ。

本の例だと、境界付けられたコンテキストとして今着目しているOrder-Taking ContextをDeployableなContainerとして話を進めている。*1境界付けられたコンテキスト間のやり取りにDTOやキューを導入したり、またコンテキスト間の決め事に三パターンあげている。

  • Shared Kernel
  • Customer/Supplier (Downstream contextが基準作って、upstreamがそれに乗っ取る)
  • Conformist (Upstream contextが提供しているものに、downstreamが合わせる)

このコンテキスト間の決め事はエリック・エヴァンスのドメイン駆動設計にも書かれてるが、この本のまとめが端的なので読みやすいかもしれない。外部システムとのやりとりには腐敗防止層もでてくる。ここまではよくあるDDDだが、52ページの"Avoid Domain Events within a Bounded Context"でFunctionalなデザインについて述べられる。さらにはオニオンアーキテクチャまで発展するのだが、この辺り伝統的なレイヤー化アーキテクチャとの比較になっているので、Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)とか読んでると納得度は高そうに思える。

raydive.hatenablog.jp

次の章からF#を使ったFunctionalなアプローチが始まるようなので、楽しみにしておこう。

ひとまずこの辺まで。

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

*1:前の章でマイクロサービスはちょっと……みたいな論調だったけど、ちょっとそれっぽい気もする。もっと筆者が想定しているよりも粒度が細かいのだろうか?

Domain modelling made functional Chapter1, Chapter 2を読む

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# (English Edition)という本を読んでいる。自分で理解で端的に書くならば、ドメイン駆動設計をFunctional Programmingに落とし込んでいくためのどう考えるか・どうするか?を述べている本だと思う。今、社内で輪読会が行われていて、これがとても面白いのでちょっとばかり自分の理解のため、忘れたときのために書き残しておく。

全体的にどんな本かは、以下のQiitaに素晴らしいまとめがあるのでこちらを読めば良いと思う。自分も参照しています。

qiita.com

Chapter 1 Introduction Domain-Driven Design

第1章はDDDの大事な大前提をギュギュッとまとめつつ*1Event Stormingを用いてドメインイベントを洗い出し、ワークフローを浮かび上がらせていこうとしている。

面白いなと思ったのは、エリック・エヴァンスのドメイン駆動設計だとインタビューなどを通してエンティティや値オブジェクトにビジネスロジックを集めようとするが、ここではイベントとそのイベントによって生成されたコマンド、コマンドを入力としてワークフローが駆動され、またイベントが発生し次のコマンドに……という動的な流れそのものに着目しているところ。このあたり自分の納得度が高く、この考え方はいいなと思った。

Event Stormingによってイベントをさらに拡大させ、大きなドメインサブドメインへ分割する話や境界付けられたコンテキストの発見へと至るのは感動がある。ただどうやって境界付けられたコンテキストを見つけ出すかは、

This is an art, not science

となっていて、この部分機械的に解決はできないのね。難しい。

あと、ユビキタス言語を生きたドキュメントとしてちゃんと残しておくのはいいことだ、と書かれておりモデルと実装を一致させるDDDにおいても、生きたドキュメントは必要だろうと自分は考えていたので、ポイント高い。

Chapter 2 Understanding Domain

第2章からは、ドメインエキスパートへのインタビューでいろんな質問を通して、一つの境界付けられたコンテキストを深掘りしていく。最初に読んでて思ったのは、当たり前ではあるのだが、ドメイン駆動設計の大枠に則って話を具体的に進めているので、Functionalでなくとも参考になる部分が多いなということ。データベース、つまり技術的な詳細に引っ張られないようにする、技術的な言葉ではなく通じる言葉で質問するなど、オブジェクト指向でのDDDでも大事なことだ。

深掘りを経て、新しいユビキタス言語が追加されたり、Event Stormingでは見つからなかった新たな境界付けられたコンテキストを見つけたりした結果が、36ページのワークフローになる。この図を見たとき自分は集約がこれに置き換わったのかなと思ったが、実際にEvent Stormingではワークショップを通して集約などを見つける手法だと後から知ったので、自分の感想はいいところをついていたようだ。

というところでここまで。次はChapter3を読んでいきたい。

koboにもあるんだ……

*1:開発者の仕事とは何かやメンタルモデルの共有の大事さなど

業務システムデザイン勉強会に行ってきた #kyotoui

connpass.com

内容的に面白いものが多く、色々ためになった。ずいぶん前にUXの勉強会で社内システムはそれほどUX考えなくても……なんて話もあったが、いやいやそんなことはないと言える発表が多かったと思う。

どれも面白かったが、アクセシビリティ、エンジニアのための情報設計、視覚言語とUIは骨太の内容。エンジニアのための情報設計はDDDを想起したりしたけど、むしろワークフローやデータをどう取り扱うかの観点から似たような考え方になるのかもしれない。Mackerelを例にした「線」から始まる視覚言語については、実際に目にしているプロダクトであるので説得力のある内容だった。考え方として取り入れていきたいな。*1

メモ

みやすいデザインにするための基礎知識

@883_issan 10分

社内システムにおける「使いやすさ」の重要性

@furusin_oriver 10分

  • 使いやすいシステム?
    • 起動速い、レスポンスが良い、ぱっと見でわかるUI
    • 個人的に速さは正義だと思ってるので、正しい
  • やるたいこととシステムが一対一
    • いろんなコストがかかる
    • 連携できるようにしないと解決しない
  • 使いにくさ
    • 社員が働く時間はコストである
    • ここわかってない人多いよね、人が動くのはコストがかかる

アクセシビリティの改善について

ヌーラボ 中川さん 30分

エンジニアのための情報設計

@tan_go238 20分

  • データモデリング手法 RDRA
  • 業務システムのUIデザインの難しいところ
    • 取り扱うデータが多彩で大量、登場人物が多く複雑
    • UIデザインするのに情報設計がいる
  • ビジネスは定性的、ビジネスとデータの間にデザインがある
  • データからデザインを想定
    • なんか余計固定化されそうな気がする
    • ドメインモデルと捉えればそう間違いでもないか
  • DDDっぽい香りだけど、DB設計見るのはなんか固定化されそうに思える
  • UItとしての統一感あるのは正しい
  • 検索設計の仕方はその通り

視覚言語とUI

@takuwolog 15分

  • 視覚言語
    • UIなどを構成する最小単位の視覚的に意味を持ったスタイル
    • WebだとCSSでかけるので、そこに意味を込めていく 例:ある線 => form
  • 2pxの線はformにのみ使っている
  • 点線のform その場で編集できる
  • 他色々な視覚言語の組み合わせで、UIが形作られる
  • ふわっとしたドキュメントがあるらしい
    • ふわっとしてるのは、新しい視覚言語が追加されたりしてメンテが大変なのでかっちりとはしてないようだ
  • 面白い

*1:フロントエンドやってないけど……

2019年4月13日 京都市植物園の桜

3月の終わりぐらいから京都市植物園で桜の開花状況を写真に収めてきた。残念ながら、ちょうどいい感じに咲いていた先週は風邪で体調崩していたので、いかなかったのだが今日は天候に恵まれていて、なかなかいいのが撮れたと思う。

_DSC2058.jpg

いきなり植物園行くまでの鴨川のシダレザクラなのだが、やっぱり色合い的にはソメイヨシノよりこっちの方が好きだなぁと思いながら撮っていた。

_DSC2062.jpg

_DSC2064.jpg


植物園到着。

_DSC2096.jpg

先々週はまだ咲いてなかったけど、真っ赤な花が咲いていて良い。お目当の桜はというとこんな感じ。

_DSC2103.jpg

_DSC2106.jpg

_DSC2110.jpg

_DSC2122.jpg

やっぱり見頃は先週ぐらいだったかなと思いつつ、いくつかは満開、散り始めという感じだった。去年は全く写真にも収めてなかったので、まあ今年はこれでよしとしよう。他の写真はこちらからどうぞ。

4.13.2019 Kyoto botanical garden & Kamogawa

歯医者帰りの今日の空

_DSC2163.jpg

風邪もだいぶよくなったので、歯医者帰りに京都市植物園まで行ってきた。ほんとは先週ぐらいがちょうどよかったのだろうけど……まあ今日もそれなりに咲いている状態だったので、よかったと思う。

風邪治りかけ

raydive.hatenablog.jp

このあと若干寒気がするなぁと思いつつ、翌月曜になると高熱になって完全に風邪をひいていた。三日目にはなんとかリモートワークできるぐらいには回復したが、一週間は外に出る体力がなくて、久々にひどいのにかかったなぁと。日曜には投票所までいけるようになってたけど、いまだに咳が抜けないので地味にしんどい。のど飴も常時なめてるので、したが荒れているし早いとこ直したいなぁ。