職業訓練
https://qiita.com/kaizen_nagoya/items/95368b63fa21d64271ec
Programmer, Day 8
https://qiita.com/kaizen_nagoya/items/2198971704fec661aec8
C言語(C++)が必要な人と必要ない人
https://qiita.com/kaizen_nagoya/items/2afe9e846b55b24cb6f1
C言語を習得する３つの方法
https://qiita.com/kaizen_nagoya/items/84cab0888c193bba429b
Programmer, Day 10
https://qiita.com/kaizen_nagoya/items/fe0ebd146c5b6f0fcd1f
MCP入門 〜面倒なことはAIエージェントにやらせよう〜 を聞きながら
https://qiita.com/kaizen_nagoya/items/54b648c838fae8d57e38
<この項は書きかけです。順次追記します。>
This article is not completed. I will add some words and/or centences in order.
Este artículo no está completo. Agregaré algunas palabras en orden.
misra
Misra Example Suite at docker コンパイル完了までの道のり。docker(154) error(56)
https://qiita.com/kaizen_nagoya/items/71f04a0204d5a1114577
C Puzzle book
C Puzzle Bookの有り難み5つ、C言語規格及びCコンパイラの特性を認識, error(21), coding(28)
https://qiita.com/kaizen_nagoya/items/d89a48c1536a02ecdec9
The C Puzzle Book
https://efrei.poupa.net/Programmation%20en%20C/Cours/The_C_Puzzle_Book.pdf
defs.h "The C Puzzle Book"
https://qiita.com/kaizen_nagoya/items/6d284651ac1244963bd9
Structures 1: Simple Structure, Nested Structure, The C Puzzle book, p.63
https://qiita.com/kaizen_nagoya/items/f32769f4e76f5cc05776
cf1.c, The C Puzzle Book
https://qiita.com/kaizen_nagoya/items/6b6c4b055b279502b13e
cf2.c THe C Puzzle book
https://qiita.com/kaizen_nagoya/items/0b05578f5d110487a1d3
cf3.c The C Puzzle Book
https://qiita.com/kaizen_nagoya/items/61c4c9c7382d5425d5f6
cf4.c The C Puzzle Book
https://qiita.com/kaizen_nagoya/items/2900320cb219aaa07211
program style 1, The C Puzzle book
https://qiita.com/kaizen_nagoya/items/9870d16747a82df61c58
The C Puzzle Book: Operators 1: Basic Arthmetic Operations
https://qiita.com/kaizen_nagoya/items/2a0d8277d72bfc579df6
c puzzle book op6.c
https://qiita.com/kaizen_nagoya/items/cd7a04de6b846becb2a4
c puzzle book op6.c install error
https://qiita.com/kaizen_nagoya/items/4542e50784561d5d3d3e
c puzzle book basic type 1
https://qiita.com/kaizen_nagoya/items/fdf42293421b7705c14f
c puzzle book basic type 2.c
https://qiita.com/kaizen_nagoya/items/81fb10b331cc7be90654
c puzzle book basic type 3
https://qiita.com/kaizen_nagoya/items/9c01c980c15951c6a3ef
Ｃ Ｐｕｚｚｌｅ Ｂｏｏｋをやる動機
https://qiita.com/kaizen_nagoya/items/962034c4e3812aeadee5
Ｃ＋＋版 Ｃ ＰｕｚｚｌｅＢｏｏｋ
https://qiita.com/kaizen_nagoya/items/5dd0fe4700b39c2ccea3
構造化
P118
分析と解析の共通点と違い。
分野によっては同じ意味で使うことがある。
解析は、ばらす方が中心。抽象化はあまりしない。
分析モデルには完璧・正解がない
ー＞ システムには、完璧・正解がない。
不完全性定理。
正しい＝
価値があるとは限らない。無意味なものは、正しい可能性がある。
正しいかどうかは、外挿的にしか決められない。
３分の１以下の力以上を投入しちゃだめ。
十分に良いレベル
システムの設計当初：３０点でいい。
分析時間を決めて、３人以上で分析する。
人命に関係しないシステムであれば、１時間から１日でいいかも。
人命に県警するシステムでは、１時間から１日をメンバを入れ替えて３回繰り返す。
大事なのは、参加する人の能力の分散が大きい。人が集まる意味がない。
安全関連系の人の能力の指針は。URLを追記予定。
顧客への最初の出荷（アルファリリース）：試験がまだできておらず、試験をしてもらうための出荷。
ベータリリース：顧客に十分制を確認してもらうための出荷。
正規出荷。
測定（能動測定）することは、対象を変える場合がある。量子力学に限らず。
受動測定では、だれも何もしないと、何も測定できない。
すべてを知るということが不可能
復習問５ 分析モデリングをした方がよい場合と、しないほうが良い場合をあげて、それぞれについてその理由を考えてみてください。
異常状態、エラーについては、分析モデリングをした方がいい。
１時間以内にソフトが欲しいと言われたら、分析モデリングはしない。（する時間はない。）
設計モデルは、そこからソースコード自動生成できるなら作ってもいい。
設計モデルから分析モデルの自動生成と、分析モデルから設計モデルの自動生成は１０倍以上むつかしいかも。
復習問６ エラー処理が実装の半分以上を占めている場合でも、基本機能から本質を分析することは必要だと思いますか。
必要。
エラー処理の優先順位を決めて、基本機能の邪魔をしないようにするために、分析するとよい。
Cの精神から自明。
復習問題７
目的の再確認をする。
本質を見極める。
収束させる。
複数の分析モデルのままでもいい。
顧客が１つがいいといえば一つにする。
顧客が３つでもいいといえば３つの分析を一緒にする。
設計モデルも、一つにする必要がない場合がある。
燃費重視のモデル、安全重視のモデルと、高速走行快適性モデルなどの複数のモデルを維持して、
共通の部品、共通の枠組みが作れるかどうかを検討してもいい。
復習問８ 分析する際に注意すべきことを５つあげてください。
P122
あまりにもほかの利用者のことを考えて作成するとかえって水らくなるのではないのか？
設計者の視点でまず書く。
利用者の視点、顧客（利用せず、お金を払う担当）の視点、社会の視点、ソースコードの視点
をそれぞれ自動生成するようにすれば、自分は常に自分の視点の図：ソースコードを保守すればいい。
設計レビューの視点
ソースコードよりも図の方が問題が明確になることがある。
保守の視点
自分で保守するなら、自分が直しやすいようでいい。DevOps＝DevelopmentとOperationが同じシステム（クラウドを含む）でやれば、設計者が保守する現在の流行りに沿っている。
再利用。
自動生成するのなら、再利用が前提。
自動生成アルゴリズムを葉推すか、図を直すかは選択。自分で両方やれば一貫性が保てる。
時系列図から、UseCae図を自動生成すれば、システムを利用しない顧客にも伝わる可能性が増える。
刻時図から、UseCae図、状態遷移図からUseCase図を自動生成するのもありかも。
局所化
うまくいけば、部品として便利。
うまくいかないと、人の足を引っ張る。ー＞ 他のモジュールの処理の邪魔をする。
邪魔＝ 空間的な邪魔（人が使う領域に値を書き込む）、時間的な邪魔（処理が遅くて間に合わなくなる）
例：Segment Falt
機能分割
局所化と一緒でうまくやらないと意味がない。
モジュール
モジュール構造 目的によりけり。こうすればいいという銀の弾丸はない。ー＞ 人月の神話
p.126
設計モデル：How 処理の定義。
What:構造の定義もすることがある。
設計モデルを一番先に書く場合。
機能分割：すでに利用可能な成熟したライブラリがある場合には、ライブラリのどの関数を使うかを選ぶ。
トップダウンだけでなく、ボトムアップで成功する場合がある。
ある構造に着目した、よい 言語、ＯＳ、通信規約（ｎｅｔｗｏｒｋプロトコル）、データ構造（ＤＢを含む）がある場合には、選択だけでシステムが構築できることがある。
インタフェース定義と機能定義
インタフェースだけにこだわる人たちがいると、機能の議論もしないと駄目。
機能を突き進めて、インタフェースの共通化ができないと、再利用性が落ちる。
プレーンモジュール
ライブラリ：汎用性が高く、事前に提供されているソフトウェア部品。
WEBでは、新たな仮想通貨が出てくれば、ライブラリの作り直しの可能性はある。
新たなサービスを、既存のサービスの組み合わせで実現できれば９９％はライブラリで実現できる。
AUTOSARで、５割から９割がライブラリだけでできるかも。
p.130
同期・非同期
処理と通信で違う意味。
業界で違う意味がある。
自動車業界では、
同期処理
すぐに実行するのではなく、周期時間が来てからやる。
非同期処理
すぐに実行して、周期を待たない。
「起動トリガをかけたあと、処理の起動や完了を待つことなく次の処理を行う」
呼んだ方と、呼ばれた方の優先度・優先順位の設定によりけり。
オンシート、オフシートは、構造図に限らず、状態遷移、時系列でもわかりにくくなれば取る手法。
トランザクション分析
処理の分析
処理の複雑さを回避する。
データ構造によって、処理を速くすることができるか。
変換分析
データの分析
最大抽象点（入力・出力）
STS
Source, Transform, sink
input process output
BOSS（親玉）をどうするかの例がない。
新たに作成する例が欲しい。
構造図
時間が速くなる。
空間が小さくできる。
保守が楽になる。
構造図を書き続けている人は、図をみればどうすればいいかがわかる人がいるかもしれない。
ソースから構造図を書いてもいい。
ソースを書くときに、すでにいい構造が頭の中にある人。
事例を問い合わせる。田中伸明さんに聞くかも。