第 2 章: ドメインを理解する
“2. Understanding the Domain” from “Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#” 📚
This site is not a place to provide value to readers, but a one for personal thought experiment. Rindrics, the note owner, will share content such as: the things he is currently learning, memorandum, favorite things, the process and the results of his thoughts.
“2. Understanding the Domain” from “Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#” 📚
“1. Introducing Domain-Driven Design” from “Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#” 📚
関数プログラミング的考え方でドメイン駆動設計をやるとどうなるのか興味がある。
とある研究者の方から分析環境構築について相談を受けた。 アーキテクチャ設計 & データパイプライン構築を支援したのでメモしておく。
日本の資源評価が OSS をベースとして回っていることをふと思い出し、これは改めてすごいことだと思った。 ベースソフトウェアが OSS の形態をとっていることで日本の資源評価には大きな可能性が秘められている。 少なくとも、資源評価の関係者ではなくなった現在の私にも、貢献の導線がある程度開かれている。
「事実」と「意見」を区別せよ、とよく言われるように。
I cannot commit to a certain OSS repo because the dumb
-type terminal of my Emacs (GUI version) caused an error on githook script.
Keyball44 を入手して組み立ててあったのだが、QMK 用のキーマップ定義の書き方を覚えるのが億劫に思えてそのまま放置してしまっていた。
To learn about compilers hands-on, I built a Linux development environment with configuration management.
The first subject for my reverse modeling is Twitter.
In the last two months or so, I have developed a strong interest in domain-driven design (DDD).
Concurrent Go programming with goroutine, especially about:
コーディング時にブレース間で改行したときの挙動が気に入らなかったので改善した。
Processing も Emacs で書きたい!ということで久しぶりに processing-mode を触ってみたら、環境設定で何箇所かハマったのでメモしておく。
公式のガイドではさらっと説明されている kubeadm join
でつまづいたが、ネットワークの設定を見直すことで解決できた。
本を読むならば紙に限ると思っている。 しかし最近は、収納スペースを気にして、その本の購入自体をためらうケースが多くなってきた気がする。 これでは本末転倒なので、利用できる場合にはなるべく電子書籍を買うようになってきた(電子書籍に慣れることを狙う目的もある)。
ブログを始めるにあたり、とりあえず免責事項の記事を書いてみた。 Hugo を立ち上げると、何やらブログトップの “Latest Essays” に “免責事項” の文字が…(ついでに “About” も)。 これはかっこ悪い。ということで、 “Latest Essays” として表示される記事の Content Type を制限することにした。