本稿のセミナーイベント・勉強会
なお、後でYoutubeからアーカイブ視聴ができる（おそらく）ので、会場でなければできないのはハンズオンセミナーとブース展示訪問、そして崎陽軒シウマイ弁当。
以下はYoutubeチャンネル。
ぜひ会場の雰囲気を感じてみて欲しい。
Pythonパッケージ管理ツールの最新情報 (Version 2024.09)
遅刻してほとんど聞けなかった…
土日にアラート設定忘れるのホント気をつけよう
B. 関数型ドメインモデリングを非関数型のプログラミング言語でやってみた
１記事書けるぐらいに多いので開閉
後述するフレームワーク
https://zenn.dev/o/jtechjapan_pub
書籍：関数型ドメインモデリング
F#の本。DDDでソフトウェアの複雑さに立ち向かおう、という本らしい
2024年に日本語訳版が出版
ドメイン駆動設計と関数型プログラミングを組み合わせ、ソフトウェアの複雑性に対処する明確かつ簡単な設計を生み出せる
すごそう
そもそも。関数型ドメインモデリングを導入すると何が嬉しいのか？
- 手続き的・暗黙的→宣言的・明示的
- フレームワークの全否定か？
- データの状態（処理の結果）→データの遷移（処理の流れ）
イミュータブルなデータと関数を組み合わせた型でドメインの状態遷移を明示的に表現する（前書き）
とは、
- 型がドキュメントの代わりとなる
- 不正な状態は表現できず、コンパイルエラーになる
- データ構造からビジネスイベントやワークフローに焦点を当てる
のように変わっていく
が、現状はOOPばっかりだよね
C#と関数型パラダイム
- データをrecord型で定義し、イミュータブルにする
- データに振る舞いを持たせない
- データに状態を持たせない
- 関数を静的=staticに定義する
- メソッドチェーンでパイプライン処理を書く
- Unit型を定義し、voidの代わりにメソッドの戻り値として使う
- デリゲートを全てFunc型に統一できる
- Option型を定義し、Nullableに
鉄道思考プログラミング(ROP)
とは？
→エラーハンドリングの手法。プログラムの処理を鉄道のレールに見立てて、処理の流れを線路・エラーを分岐と捉える方法。
正常な処理は一本のレールを進む
分岐したら元のレールに戻さない
関数の戻り値にResult型を用いて表現
エラーはthrowではなくreturnとして扱う考え方
エラー自体をドメインエラーとして扱い、ドメイン駆動設計の他の部分と同じように注意を払う
聞いてもよくわからない。
Result型<値の方, Error>が返ってくるので、エラーハンドリングがしやすい
従来のtry-catchだとエラーになった場所を特定するのが大変なので、この問題点を消している。
GitHub ActionsのようなCIで考えると、前の段階で処理が実施されているよね、っていう確認してるので、この考え方に近いな
if-else書きまくるより、正常系とエラーケースの処理でまとめちゃえばよくない？という考え方によるか
→たとえばPythonでいうところの with open みたいなコードだった場合にエラーキャッチをどうやるんだ？というのが気になる
C#でやってみた
鉄道ほど大きなものではなく、ベルトコンベア型のライブラリを作成した話
この辺りの考え方はJavaなりPythonなりで実現できそう
Lambda使えば何でもできるな
コマンドで始まりイベントで終わるワークフローとCQRS・イベントソーシング
- 注文書を受け取った後にユーザーが注文情報を書き込む
- 確定した注文が別のイベントのトリガーとなって発火する
- 商品発送
- 請求
これを一つの関数にマッピングしてしまえばよくない？という考え方
- 入力はコマンドに関連するデータ
- 出力はワークフローが生成するイベント
コマンド ー ビジネスワークフロー ー イベント
外の機能とつなげれば良さそう
→CQRS（コマンドクエリ責務分離）をしよう！
クエリとコマンドはドメインモデリングの観点から見るとほとんどの場合違う
イベントソーシング
状態に変化があるたびにその変化を表すイベントが永続化される
CQRSを実現するフレームワーク「sekiban」
C#・F#用
コマンドの実行とイベントの生成を行い、これらを永続化（DB）する
自動テストやWebAPIエンドポイントの自動生成に対応する
コード解説を聞いてはいたけど、アーキテクチャ図と結びつかないので分かりにくい印象
いわゆるDOとは何が違うのだろうか？（データの状態を持たせない、という話もあったが、私が理解できてないだけの可能性も）
ドメインモデリング所感（講師）
ビジネスアプリケーション開発には有用だが、オブジェクト指向から関数型へのパラダイムシフトは必須
特にROPに対応するものは現状F#とsekibanぐらいだろうか。まず考え方自体が受け入れられるか
オブジェクト指向から関数型へのパラダイムシフトの中間点として取り入れてもらうポジションとしては良さそう
（言語不問として、関数型っぽく書くなど）
所感
タイトルに釣られて。何の話か全くわかっていない状態から参加。
今までOOPにべったりだし、新卒指導でもOOPばっかり教えている私自身のパラダイムシフトが必要だなー、という印象
海外の最新情報を取り入れて実践した日本語講義のありがたみを感じる
これ学習コスト高くないか？
鉄道思考プログラミング（ROP）という新しいパラダイムを理解する必要があるし、書き方も理解する必要がある
メソッドチェーンでエラーハンドリングできるのがいいよね！っていう部分しか私が理解できなかったので、もっと本質的な課題があるかもしれない。
ただし、ROP自体は面白い考え方というか、初学者にif-elseの分岐について説明しやすいので、今後ROPに繋げるためにもぜひ採用していきたい。
B. 【飲食OK】今さら聞けない人のためのDevOps超入門
１記事書けるぐらいに多いので開閉
かんたんDevOpsをやってます
- どんなツールを使うべきか
- 何を行うべきか
- 汎用的なDevOps環境と手順書を提供
- DevOpsに関する改善を行うためのサポート
フルマネージドでDevOpsチームに参画する「おまかせDevOps」もあるよ！
https://thinkit.co.jp/series/10843
開発・運用環境の課題
- 開発チームと運用チームは分離されている
- 開発は変化を求める、攻めの姿勢
- 運用は安定を求める、守りの姿勢
- 隣のチームの業務内容がわからない
- 良い方法が社内ノウハウとして蓄積できていない
利用者のニーズに応えられず改善・発展しないという問題があるため、変化のリスクを組織改革とツールで低減していく
これをDevOpsで解決していく
- 開発と運用の境目を曖昧にする（密に連携する）
- 新しい機能をリリースし、受け入れる体制を作ることで変化を受け入れる
- 導入時のオーバーヘッドをなくす
- 日次・週次定例以外のコミュニケーションの場が必要
- ユーザのニーズに迅速に応える
- 特にリリース期間は気にされがち
- システムの価値が高まりビジネスに繋がる
DevOpsのビジネス的なメリット
- 開発状況の可視化
- 進捗：チケット駆動
- 品質：テスト駆動
- 開発手法の標準化
- 自己流での開発からの脱却
- 生産性の向上
非技術的な観点からの納得感
モデル環境
- VSCode
- GitHubへPR・マージをトリガーにテスト
- GitOps
- JenkinsやCircleCIでビルド(CI/CD)
- GitHub Actionsも便利
- 凝ったことをやるならCircleCI
- IaCにもこだわりたい
- 本番環境に乗せたら（特にバージョンアップも含むと）遅くなったケース＝データ件数とかもあるし〜
- Slackに通知
- AWSにデプロイ
主に自動化（テスト・インフラ=IaCによる構築）が目的で、CI/CDによる効率化
開発管理ツールとしての運用を想定したい
自動化
- 手動では困難なテストを容易にする
- リソースの有効活用
- 夜間
- 人的
とはいえ、初期コストは高いし、テストコードも万能ではない
テスト手法もいろいろあり、
- 静的テスト（コード解析）
- 単体テスト・ユニットテスト
- 統合・結合テスト、E2E
テストの自動化（標準化）によるメリットとして、属人性やフットワークが軽くなる
DevSecOpsにも直結していく
SBOM
- ソフトウェア部品表
- システムを構成するソフトウェアの管理
- SPDXーISO/IEC 5962:2021
- 脆弱性情報と連携した管理ツールが必要
- SaaS(yamory)があるよ
DevOps実践のために
- 手段と目的を履き違えない
- DevOps導入により従来とは違う文化を取り入れるため、抵抗感も出てくる
- トップダウンでのスピード感のある対応が必要
所感
金曜日にリリースするな→バグったら土日がなくなる。つらいね
勉強会に参加しているような人が話す内容と、社内政治や経営がメインの層だと考え方（文化）が違うな、と感じる
人の問題と予算の問題が大きいか
C. [Learn Languages 2024] 関数型プログラミングのパラダイムはアプリケーション開発に必要なのか？
１記事書けるぐらいに多いので開閉
関数型プログラミングの設計テクニック
関数型ドメインモデリングの本の話
- ドメイン知識のメンタルモデルを共有
- ドメインモデルには特定技術を持ち込まない
- ドメインモデルとコードのモデルは一致させる
データはANDとかORで表現する
例：Contact型の構造を意味のある単位でまとめていく
-
不正な状態は表現できないようにする
- 正しい状態・不正な状態はビジネスルールで決定
- メールアドレスを入力するか、ID名を入力するか。それ以外は全部不正
-
メールアドレスの検証状態をステートマシンとして扱う
-
状態ごとに型を宣言
（早すぎてもうついていけない）
依存関係を後工程の関数で受け取れるように設計すると、依存関係にある関数に強い結合関係が生まれないか？
なんで関数に分けたんだっけ？が分かりにくい…
注釈
ROPを考えると、処理の分岐が発生するタイミング＝if文を書く場所でいったんreturnを返すような制御だろうか
関数型スタイルを取り入れたアプリケーション開発の例
自社SaaSを作った話。書籍通りにやってない←読んでないけど、前の講義で何となく疑問があったので違和感がない…
C#ではなく、TypeScriptでやった話
ドメインオブジェクトは型インターフェースで定義する
失敗の分岐はResultで表現する
オブジェクトの変更は「関数適用による状態遷移」として実装する
受け取ったデータ型に対してパラメータを追加して、元のデータ自体を返す
(Contents) => {Contents.result = true}
I/O→純粋関数(Modelを引数にとる)→I/Oという構成（オニオンアーキテクチャとも）
やりたいこと
- 型を有効に活用したい
- 静的検査に寄せたい
- ドメイン層において「不必要な状態存在」を減らすと堅牢になる
- エラーハンドリングを型で扱い制御できる
トークセッション
（話が早くて、分かっている人の会話のようでした）
まとめるのが難しいため、省略
TypeScriptだとResult型の制御が大変
所感
ストーリーが全くわからないので入ってこない
話も早いし、困った。ついさっきの講座でこの辺りの話を聞いていなければ本当に何もわからなかった
話を聞いていて気付いたが、全ての関数＝ビジネスロジックという考え方なので、前段の処理に依存していて問題はないのか
B. 技術書の書き方～キー音粛々、夜、原稿を書く～
１記事書けるぐらいに多いので開閉
SNSに流して！という要望があったので頑張ります
事前に資料の取り扱いやConfidential的な事を伝えてくれると安心感があって良い！
執筆とは？
クリエイティブではない一方で、クリエイティブな活動である
- 構成: Construct
- 本の構成を考える。目次とか。
- レベル感は人により。章（チャプター）立て、節（セクション）と項（小見出し）
- スタート（Docker何もわからん）とゴール（K8sもざっくり分かる）
- 書く
- ノートの使い方
- wordの使い方
- 校正: Proofreading
- 本を整える作業
各章から各節を考える
構造を考える
↑
- 樹形図
- なんちゃってタイムライン風
- カード
- メモを書いてマスキングテープや付箋にする
- 後で並び替えやすいように切った貼ったできるようにしている
- ノート
- word
↓
書く内容
のようにツールを使い分けている
- 構成を考える時間と執筆をする時間を分けるのがスピードアップのコツ
- （本の読者）ペルソナを作っておく。技術書は「知らない事を勉強する時のツール」として使用されるため
書く技術
- Wordならでは、文字の装飾をしよう
- markdownでも書けるけど、装飾は弱い
- 音声入力が一番早い。文字変換が要らない。フリック入力もだるい
- 長文で話すことと、句読点をつけさせることが重要
- 固有名詞はなかなか変換してくれないので、後から一括置換する
- 書きたいところから書く
- 第一章は一番最後に書く。網羅性が必要だから
- インストールが一番書きやすい、考察の余地がない
- モチベーションコントロール
- 端から作るとゴールが遠いのでしんどい
- マイルストーンを作って埋めるやり方もあり
校正
原稿にイラストをつける作業
商業誌だとDTPという専門の作業者もいるぐらい。
初校〜再校、色校まで
紙に印刷した後に校正記号を使い分ける。フリクションおすすめ（専用の消しゴム）もあるし、アイロンで消す方法も
（紙で見るとミスに気づきやすい）
ハンコを使う方法もある
スピードダウンの要因を取り除く
- 調査：例として「インターネット」
- JISやらISO, IPAが定義しているとはいえ、説明としては不十分
- 「A is B」のように説明できるか？
- イラストにするにしても、細かい調査が必要。公式ドキュメントは全部書いてあるか？というと「欲しい情報がない」ことも多い
- 先読み
- 自身の原稿が古臭いと不安＝本質を掴んでいない状態、になる
- 時代を読まなければ古い本になってしまう
が、ここまでやる必要があるかどうか、は人によるか
クリエイティブではない一方で、クリエイティブな活動である
所感
武器（なんだろう？）を振るとスライドが捲られるのおもしろい！
めっちゃ本書いてる人だった！それも気楽にやってるよ！と。
が、楽なだけではないという話があった。これが聞きたかった！
書く内容を決める。これが一番時間がかかりそうだ
→よく考えたら、私もこのメソッドを無意識で使っている（ような気がする）
勉強会などに参加したら即時に記事を上げる、という活動をしている
ハンズオン. 【要参加申込】VS Code Dev Containersで始めるリモート開発環境体験ハンズオン Vol.2
Dev Containers
VSCodeのリモート環境（ローカル）。Dockerコンテナ上で動作する
DevContainerを使うとローカルの実行環境もまとめていい感じに構築できる仕組みができる
これからの環境構築は、手塩にかけて育てた秘伝のタレ化した環境ではなく、インスタントな開発環境を作れた方が良いよね ← 確かに！
所感
まずはハンズオン部分は無事完了（これが思った以上に大変だったりする）
この環境をどうやって作るんだっけ？とかそういう話も聞きたかった！
後で会場アンケートに要望しておく事にする
A. OSSのノーコード・ローコード開発ツール「プリザンター」
私も勝手に協賛させていただいているぐらいに何となく知っているので、今更何を書こうかと。
会場での進行としては、まずプリザンター自体の概要の話があって、ユーザーの認知度とかシステム構成の話とか。特にAPIが充実してるのが嬉しい！
MySQLに対応するよ！という話があってデモへ。
デモ環境の中身をこれほど懇切丁寧に（社長自らツールのソースファイルを開けたりDB参照するの面白すぎる）説明しているのはなかなか見れない。
開発者がAPIだけでなく、サーバースクリプトを弄る事ができる（極端にいえばOSSかつオンプレでいじれるので、あってもおかしくない）ので、カスタマイズの範囲がかなり幅広い！
所感
裏でプリザンターをダウンロードしてガチャガチャやろうとしていたのだが、サクッと環境を作れなかったので、帰ってじっくりいじる事にする
Winに入れてIISで動かすよりWSLの方が早いよ！ということが分かったので、そちらの環境で検証予定
なお、Macでやる場合はDockerが必須っぽい
うまいこと使えばLMS的に進捗管理で使えそうなのがいい
LMSとTMSを連携してうまいこと使えないか、と悩んでいたのでぜひ提案してみることにしたい
A. PHP開発者と運用管理者に捧げる持続可能なプロダクト&サポートサービス
Zendと会社の関係性の話
多くの会社さんらしく運用保守など現場サポートが必要な場所に入っての契約がメイン
特にEnd of Life(EOL)への対応が重たいタスクに
PHPのバージョンの変遷
全員（世界単位）が最新版を使っているわけではないのと、古いバージョンが残ってしまっている事もあるらしい
同じく、PHPサーバーのOSのシェアもUbuntu（次点にDebian）がメイン。
Zend Serverから Zend PHP & Zend HQへ
元々Zendはオンプレを想定した環境だったが、クラウド化していくにあたって重すぎる
そのため、実行環境と運用管理をZendPHPとZendHQに分離して運用できるようにすることでOSに依存した環境からの脱却を図る
あくまでZend系の話なので、WordPressとは別の話。とはいえ、前段での話があったPHPのバージョンについてはZend系と同じ問題がある。
サポート終了(LTSを含む)と移行期間
PHPのバージョン（特に8系）のOS側の対応とフレームワーク側の対応の問題があり、事実上Ver7.4が安定版みたいになってるのかな
Ver8に移行できない原因がそれぞれのツールやフレームワークライブラリに依存する場合は、バージョンアップを妨げている要因を解消する方向に舵を切るべきだが、保証中なのでなかなか移行が進まないのかも
ZendHQの機能
- Z-ray
- ブラウザの開発者ツールのような便利機能が使える。ページごとの実行時間計測が主か
- モニタリング
- PHPの実行中に設定値を超えたイベントと状況を記録する。デフォルトで実行状態なのでエラーやエクセプションを監視している
所感
よく考えたら、PHPとフレームワークとしての機能には依存していたものの、その周辺ツールについては使った事がないかもしれない。
Zendと聞くとZend FrameWorkの印象が強いので、ZendServerはおろかZendPHPやZendHQは知らなかった。
私があまりPHP自体に詳しくないというか関心が薄いというか、あくまでアプリを作るためのツールだとしか認識していなかったので、PHPの監視についてはクラウド側に丸投げしていたがこういったものが用意されているのであればぜひ活用して行きたいし、していくべきだろう。
今回、特にサポート終了については思うところがあり、SAP S4HANAの時もだがサポートが切れそうにならないと移行もままならないケースが多そうだ。
移行時にも要件吸い出して移行計画を立てるので、サポート終了日ありきでやるべきではないはずなんだけどなぁ、と思わないでもない。
全体所感
実は来週はスタッフという形でこちらに参加するので、下見を兼ねて（ついで）参加したというのがある。
が、よく考えたら去年のサーバーレスデーのセミナーにも参加していた事を思い出したので知ってたというオチだった。
執筆時時点ではこれから懇親会！
懇親会以降、古き良き同人誌即売会のような空気感
規模が大きいのと繋がりが強いのとで、やや身内感が強めに出てしまっているのは仕方がないところはあるが、私個人としては昨今多く感じられる疎結合なコミュニティの雰囲気よりは、がっつりと入り込みやすい・入り込んでくる本コミュニティのような雰囲気だと昔を思い出せるので落ち着く（が、騒がしい）なぁ、というただの感想
ジャンケンスクワット（＝景品が欲しい人はジャンケンで決めてね）にも参加できたし、結果は残念だがただジャンケンしたかっただけなので、他の人の手に学ぶ機会が届いたということで喜ばしい。
次は10/26の展示ブースかな。オンライン参加も当然する