職業訓練
https://qiita.com/kaizen_nagoya/items/95368b63fa21d64271ec
Programmer, Day 12
https://qiita.com/kaizen_nagoya/items/84a9932f84b7f1382391
C言語(C++)が必要な人と必要ない人
https://qiita.com/kaizen_nagoya/items/2afe9e846b55b24cb6f1
C言語を習得する３つの方法
https://qiita.com/kaizen_nagoya/items/84cab0888c193bba429b
Programmer, Day 14
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
<この項は書きかけです。順次追記します。>
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 13
構造化
program はじめてのC/C++ 構造化プログラミング
https://qiita.com/kaizen_nagoya/items/918148868c2afc1810d4
p166
p165から
設計の品質
モジュール分割
重複の最小化 ー＞ 直交 ー＞ 他のものに影響を与えない。
力学で、直交する力は、他の軸の力に影響を与えない。
影響を与えないのが直交。
クローニング
完備 ー＞ すべてを網羅しているか。 ＝＞空間だけでなく、時間も。直交も考慮している。
情報隠蔽
抽象データ型で、非公開のデータがあり、公開の関数だけで処理できる。
public 宣言すれば情報隠蔽しないことになる。
データ構造とアルゴリズムを分離する。
データは、関数からしか処理しない。
データ構造を変えても、関数が同じようにうごくようにすればいい。
凝集度
構成要素が同じでも、構造によって大きくなったり、小さくなったりする。
機能的 ー＞ 一つの機能
複数の機能があると組み合わせ、順番がいろいろ考えられ、高速化、省容量設計がむつかしい。
ー＞ Unix, linux, macOSのコマンド(winodwsも同様）
Ｃ言語もコヒージョンが高い、機能的な関数をねらっていた。Unix, Linux(posix)で使う関数は、機能を細分化している。
ー＞ Ｃの精神の、プログラマがやろうとしていることを妨げてはいけないという考え方にもとづいて、似た機能の関数も入っている。→ getc 関係で具体例を書く。
getc, getchar, fgetc, fgets.
文字、文字列、ファイルからの文字、ファイルからの文字列など類似の関数群がある。
凝集度よりもCの精神を尊重。
ソースコードが肥大化してもコンパイル時にリンクしなければ、ソフトウェアの凝集度は確保できる。
Cの精神の「一つの操作を実行する方法は１つだけにしてください。」で、コンパイルするときは、一つだけ選ぶ。
肥大化しない。
逐次的 ー＞ 順序が決まっているものを一つにする。
通信的 ー＞ 順番が決まってない処理のライブラリ。
関数呼び出し＝通信と同じ。
IPC, RPC
お薦めじゃないもの。
手順的 ー＞ データ構造の定義が再液化できておらず、手順を決めちゃう。ー＞フォローチャートを書く。
一時的 ー＞ 直近で解決したことを、なにはともあれ解決しました。
論理的 ー＞ 外部の要請で一つにまとめた。 ー＞ 外部的
文章を書き直します。宿題。
偶発的 ー＞ ちょっと一緒においといた。
書いた人の意図がない。駄目だめ
具体例は、来年までの宿題。
Ｐ１７８ 肥大化。コヒージョンが低い
ライブラリが肥大化しても、使う関数をCの精神の「一つの操作を実行する方法は１つだけにしてください。」にもとづけばOK。
ｐ１７９ なんでも屋。コヒージョンが高い
なんでも屋であっても、機能が単純な一つだけでなんでもできるのなら、それはそれでいいこと。
コヒージョンの単位は、方向性がいっぱいあり、決められないかも。
p.170
結合 分子の構造単位と同じように、一律の単位がないかも。
p172 C言語などの高級言語であればコンパイラが許してくれない。 ー＞ 「C言語以外の」に変更するとわかりやすい。
C言語で内容結合を記述してみる。
共有結合： 排ガス規制データなどのように、特定の目的のため設計によってはGlobal dataにすることが必要な場合があるかもしれません。安全(safety), 安心(security)の視点での設計方針が大事です。
扇入 ファンイン、 扇出 ファンアウト
が多かった場合は、
データの量と、処理時間に応じて、２段階、３段階にする方法がある。
ファンインで、同時入力があった場合の、論理回路で不定になることを避けるか、優先順位を決めているかが大字。
目的ー＞ 時間で速い必要があるか、ゆっくりでもいいかで、モジュールを２段階、３段階に分けて、バッファ・キャッシュの処理速度を選ぶ。
ファンアウトもバッファ、キャッシュの速度に応じて分類するとよい。その先の通信路の容量、速度に応じて分ける。
左右
入出力と論理構造（アルゴリズム）
データ構造とアルゴリズムをバランスよく考えるとよい。
本人が意識しなくても、書いたソースコードを読めば、バランスが取れているものがある。
P177は違和感がない。
Q 一方的にデータを送るが相手の処理を考えて作成された場合と、互いにデータを送りあうが何も考えず作成された場合、どちらが結合度が高くなるのか？
A
何も考えずに作っても、ちいさくて速いソフトが書けるのが天才。いろいろな測定方法を考えてよりよくしてくのが秀才かも。
天才が書けば、どちらでも結合度は低くなるかもしれない。直観的に安全(safety), 安心(security), 妥当性確認(validation)に対する配慮があるかも。
凡人が書く場合は、安全(safety), 安心(security), 妥当性確認(validation)について、それぞれ考慮するとよい。妥当性確認(validation)は、一度自分のためのprogramを書いてみるとよい。
p178
肥大化
ソースコードで肥大化 Cの精神の２つ。
なんでも屋
抽象度が高いなんでも屋は、超便利。
スパゲッティ
goto 文で、ソースコードの元へ戻るgoto 文は駄目。
--> code complete.
いつ終わるか、確かめるのが非常に困難になる。
計算機が止まるかどうかがわからなくなる。
図８．１０ 一方へしか進んでない。問題ない。
図８．１１ 戻るのがダメ
無秩序な構造
goto 文で、ソースコードの元へ戻るgoto 文は駄目。
物理駆動
goto 文で、ソースコードの元へ戻るgoto 文は駄目。
本来の機能分析をしているのではなく、ハードウェアのイベントが機能を支配してしまっている。
ー＞本来ハードウェアは機能分析をして設計しているので、ハードウェアのイベントが機能を支配した方が速く処理できるはず。
老舗温泉旅館
左から右へいったり、右から左へ行くのが療法あると無限ループになるかも。
分割するかどうか。
制御、通信では、時間がまにあうかどうかが大事。
関数をわけると、スタックの積み下ろしで時間がかかる。
Inline 関数をあちこちで使うと空間を余分にとるかもしれない。利用可能なメモリの大きさが決まっている場合は、メモリに入るようにする。
ゲーム、音楽も時間が大事。
Excel, powerpint, browserでは
メモリを使いすぎると遅くなる。
メモリを使いすぎない構造、アルゴリズムにするのが大事。
分割することにより、無駄な空間をとったり、空間の取得開放に時間がかかるのが駄目。