職業訓練
https://qiita.com/kaizen_nagoya/items/95368b63fa21d64271ec
Programmer, Day 13
https://qiita.com/kaizen_nagoya/items/799b5198c2ede17f7d20
C言語(C++)が必要な人と必要ない人
https://qiita.com/kaizen_nagoya/items/2afe9e846b55b24cb6f1
C言語を習得する３つの方法
https://qiita.com/kaizen_nagoya/items/84cab0888c193bba429b
Programmer, Day 15
https://qiita.com/kaizen_nagoya/items/b1b1fc9a3eb0ff474c86
MCP入門 〜面倒なことはAIエージェントにやらせよう〜 を聞きながら
https://qiita.com/kaizen_nagoya/items/54b648c838fae8d57e38
職業訓練（IT) オープンソースとユーザビリティ教育。構造化とUMLを使って。
https://qiita.com/kaizen_nagoya/items/c41988c2f8ce1b61a08a
名古屋Reject会議 ふたたび
https://qiita.com/kaizen_nagoya/items/d35d2de4a35abb797126
Qiita Tech Festa 2025 自己記事一覧
https://qiita.com/kaizen_nagoya/items/83f7b7d9609d6789dc3a
gcc(gnu), clang(llvm)コンパイルエラー・警告比較(1) D_04_03.c, docker(155) error(51)
https://qiita.com/kaizen_nagoya/items/780be9109348340e20e0
講義・演習体系 第二段階 参照一覧
https://qiita.com/kaizen_nagoya/items/a55a74f8efb9ac58cb18
<この項は書きかけです。順次追記します。>
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 C
MISRA C まとめ #include
https://qiita.com/kaizen_nagoya/items/f1a79a7cbd281607c7c9
Misra Example Suite at docker コンパイル完了までの道のり。docker(154) error(56)
https://qiita.com/kaizen_nagoya/items/71f04a0204d5a1114577
一つづつMISRAが作成した直したソースは別に解説します。
docker(201) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(1) D_04_03.c
https://qiita.com/kaizen_nagoya/items/780be9109348340e20e0
docker(202) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(2) R_02_02.c
https://qiita.com/kaizen_nagoya/items/496869b87dd3d29cea8b
docker(203) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(3) R_05_03.c
https://qiita.com/kaizen_nagoya/items/cb0d1da183f4f1e9e59d
docker(204) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(4) R_07_04.c
https://qiita.com/kaizen_nagoya/items/73b9f16638273a74d807
docker(205) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(5) R_08_04.c
https://qiita.com/kaizen_nagoya/items/c753db14cc95a9303fa5
docker(206) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(6) R_09_0x.c
https://qiita.com/kaizen_nagoya/items/8ad38c8728440688255c
docker(207) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(7) R_10_0x.c
https://qiita.com/kaizen_nagoya/items/05dd6f6c14aeafbe3e71
docker(208) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(8) R_11_0x.c
https://qiita.com/kaizen_nagoya/items/9962647a1b510825fa6e
docker(209) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(9) R_13_0x.c
https://qiita.com/kaizen_nagoya/items/dcd2de1267e3c3449536
docker(210) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(10) R_14_0x.c
https://qiita.com/kaizen_nagoya/items/772f49486e7cca1dbeb9
gcc(gnu), clang(llvm)コンパイルエラー・警告比較(12) R_17_03.c, docker(165) error(50) https://qiita.com/kaizen_nagoya/items/f85e29050b99ea1c2538
Day 14
構造化
program はじめてのC/C++ 構造化プログラミング
https://qiita.com/kaizen_nagoya/items/918148868c2afc1810d4
p.170
期待通り：妥当性確認（validation)済み
Q ５W1Hでレビューをしようとすると上限を設けないと無限に出てきてしまうため、どのくらいを目途に出したほうがいいのか
A システムの安全(safety), 安心(security)の必要性に応じ、Reviewerの能力を特定することが大事。
ある能力以上の人が確保できたら、安全、安心の度合いに応じて、１時間、１日、１週間などの時間で設定する。場合によっては、指摘項目は１０個以上、１００個以上、１０００個以上などの目標を設定することがある。
レビューに時間をかけすぎるより、開発の初期段階、設計変更または仕様変更があった段階、納期前の３回以上レビューをするとよい。
１週間でシステムを収める場合は、初日、３日目、５日目に１時間づつやる感じ。
ちょけねこ たんじょうびのおくりもの 安全(96) 図(34)
https://qiita.com/kaizen_nagoya/items/fc9675686c229f7a155e
P.190
レビュー
国際規格になっているレビュー方法
FTA
FMEA
HAZOP
P.194- 197
道具が大事
改善提案には仕様する道具(tool)の種類と、使い方（自動化）を含むとよい。
github, gitlab, bitbucketは必須かも。
成果物であるソースコードと、測定、課題などがすべて同じシステムで管理する。
設計と保守を同じシステムで行えば、DevOps(development, operation)として管理できる。
bitbucket/git(16)hub/gitlab連携環境構築 悪戦苦闘
https://qiita.com/kaizen_nagoya/items/87352fe88ceed2c1732d
アジャイルサムライ & 公開算譜は機敏だ(An Open Source Project is Agile)Git(12)Hub with Docker。仮説(51), Youtube(2)
https://qiita.com/kaizen_nagoya/items/5dd49a046b5991af3a5e
卒業論文、修士論文、博士論文はgit(17)hub/gitlab/bitbacketのprivate利用をお勧め LaTeX(10)
https://qiita.com/kaizen_nagoya/items/eb9945a2649f6f3eabd0
タイミング：Daily buildの場合は毎日。
毎日ビルド、毎日レビューまたはインスペクション（ツールを含む）
github linux
https://github.com/torvalds/linux
祝VZエディタソースコード公開
https://qiita.com/kaizen_nagoya/items/baad23cf4a041ce845a9
検証(verification)
検査(inspection)
https://www.oxfordlearnersdictionaries.com/definition/english/inspection?q=inspection
an official visit to a school, factory, etc. in order to check that rules are being obeyed and that standards are acceptable
表8.1 良い設計の特性
| 設計ガイドライン | |
|---|---|
| 1 | 適切なサイズのモジュールであること |
| 2 | 同じ機能が複数点在していないこと |
| 3 | モジュール内部に詳細が隠蔽されていること |
| 4 | 高いコヒージョンであること |
| 5 | 弱いカップリングであること |
| 6 | ファンアウト数が７以下であること |
| 7 | バランスのとれたシステム形状であること |
改訂版 良い設計の特性
| 設計ガイドライン | |
|---|---|
| 1 | 均衡のとれた系(system)形状である |
| 2 | 適切な大きさの要素(module)である |
| 3 | 同じ機能が複数点在していない |
| 4 | 高い凝集度(cohedion)である |
| 5 | 弱い結合度(coupling)である |
| 6 | 内部に詳細を隠蔽している |
| 7 | 扇出力(fun out)数が１桁である |
上が優先順位が高い。