考えていた言葉や、どこかで見つけて気になった言葉を書き溜めたメモがたまってきたので書き出して消化する。
-
A test is not a unit test if...
- it talks to the database
- it communicates across the network
- it touches the filesystem
- it can't run at the same time as any of your other unit tests
- you have to do special thing to your environment to run it
-
speed and determinism
-
a proper unit test is a fantasitc tool for obtaining super precise feedback
-
database
- 遅い
- セットアップが不完全な環境では動かない
- 本番環境がLinuxだけど、開発マシンがWindows
- OS, ファイルシステムに依存
- External Datastore, Inmemory datastore, mock ...
- dao vs repository ?
- anemic domain design: these are same
- data mapper
- unit of work
-
network
- OSに依存
- networkが確立されないと動かない
-
filesystem
- 永続化 - 副作用が起る
- 一種のDBみたいなもの
- FSのないシステムがある。ある前提なのはダメ
-
I/O
- Consoleのないシステムがある
-
リファクタリングやってる
- モジュールに着目し、各関数の目的をメモする。役割が異なる処理を切り出し、別のモジュールへ移植。そのあと、ユニットテストを書く。
-
cmake便利
-
git bisect初めて知った
-
masukomi.org unittest presentation
-
状態とロジックの分離?
- 状態(データ)とロジックの統合はObject指向の目的→Class構文
- C言語ではclassがないのでモジュール単位で状態が一つしか持てないため、テストがしにくい。コンテキスト+ロジックの構造は別に状態と炉一句を分離していない
- レガシーコード改善ガイド14章 ライブラリ依存性 シングルトンなライブラリはテストできない。優れた設計のために導入される手段がテスト容易であるとは限らない。
-
get_base_addr(void)
- readした値を基にwriteするな
- wrapperとして用意するのはありだが、まずはunitとして提供すること
-
一つのスコープに複数の機能を設けない
-
sourcemaking.com リファクタリング
-
再利用性
- 再利用するなら大切
- 再利用しないならいる
- 再利用している
-
割り込みの関数がいろいろなところに定義されている。
- クソコード
- どうしてこうなった(何の原理に基づいていればよかったのか?)
-
board_init(void)
- 引数が最小限しかない
- ボード単位の初期化は間違い。アプリ単位でなければならない。
-
強み?
- 何かうまく回っていないときに原因を考察して対応策を検討する程度の能力
- 説得力がない
-
Software Development Career Path
-
デール・カーネギー 人を動かす
-
ys_ohta ブログ
-
c#のasync/awaitがJavascriptのようにはいかない
- マルチスレッドだから
- await + wait = Deadlock
- await Task.Delay(1000) => まってくれない
-
リリースタイミングとシステムテストするバージョン
-
時系列データ
- 収集しない あとでコピペ分析
- 配列に格納 最新N個 解析はエッジで
- 外部のデータベース 消えない。そして消しにくい。Retension policy, delete where
-
吉宗
- 享保の改革
- 天下はあずかりもの 人々が安らかに過ごしているか昼も夜も気になって片ときたりとも心がやすまることがない
-
海兵隊の居場所の話
-
webアプリ
- セッションはContextをContextとして扱うことで独立性を高めている。型安全ではない。
- typescriptは
[any]
を持つ - golangではどうする?
-
Router, Controller, Middleware, Helper
- MiddlewareとController区別しにk
-
endian苦手。modbus嫌い。
-
変わり続けるものを文書で追跡するのは難しい
-
命名則
- Verify: executeなので成功/失敗
- CheckVerifCode: booleanなので真/偽
- 動詞 失敗しない動詞 そんなものはない
- Object.Run()
- EEPROM_Read()
- start()
- end()
- get()
- set()
- update()
- do()
- check()
- send()
- init()
- create()
- wait()
- load()
- 問う
- IsOpen()
- HasContext()
- 失敗する可能性があるならintなければvoid
- CheckValidID()
- Checkに失敗したのかValidだったのかわからない
- 少なくとも真偽を返すのはよくない気がする
-
FAILEDマクロ
if (FAILED(hr = gotoOffice())) { switch(hr) { case xxx: //... } }
-
人は将来への投資を正確に評価することができない
-
利益供与/ソースコード
-
共通化 影響範囲2倍辛いぽよ
- 共通化していれば1か所の修正で2か所直す必要はなかった
- でも共通化できなかったかもしれない。
-
2017-12-13
- 計算機 = 主記憶、制御装置ControlStructure、演算装置(Register + ALU)+入出力装置
- 命令語
- 操作部(オペレーション)+ アドレス部(=演算数, オペランド)
- opcode + 第1アドレス + ... 第4アドレス
- opcode + 数字 即値命令
- 加算 被加数と加数の2つのオペランド、それに結果を記憶する3つのアドレスが必要
- 次に命令を実行するアドレスはオペランドにしないで命令の番地を+1することで命令を順に実行する:プログラムカウンタ
- 0アドレス方式
- 1アドレス方式
- 2アドレス方式
- OP1 <- (OP1, OP2)
- 2アドレス方式が主流らしい(92年の本)
- 3アドレス方式
- OP3 <- (OP1, OP2)
- 演算対象は常にスタックの先頭
- オペランドのアドレスの意味
- 主記憶にあるアドレス
- 外部記憶装置にあるアドレス
- 汎用レジスタに入っているアドレス
- オペランドそのものの値(即値)
- 次に実行する命令のアドレス
- 操作部の補助
- 命令の種類
- 転送
- 演算
- 飛び越し/分岐
- 入出力
- 特殊命令(制御)
- 計算機の論理的構成をアーキテクチャという
- 命令セットアーキテクチャ
- マイクロアーキテクチャ
- システムアーキテクチャ
- 同一系列の、上位互換性のある計算機群をfamily machineと呼んだりする
- 主要な回路
- MM MainMemory
- MCTL MemoryController
- PC ProgramCounter
- MAR MemoryAddressRegister - points address in RAM
- LAD LocationAdder - adder circuit of address
- LR LocationRegister -
- IR InstructionRegister -
- DEC Decoder - decodes command
- CTL Controller - runs operation, emit control signal for interrupts
- MDR MemoryDataRegister
- BR BufferRegister
- REG GeneralRegister
- ALU ArithmeticLogicUnit
- LAR LatchRegister - temporarily holds calculation result
- DET Detector - detects overflow, div0, pos/neg lar/sml
- FR FlagRegister - holds output of DET
- CH Channel - controls data transfer between IO and RAM
- IOC IOController
- IO IOUnit
-
動と静、都会と都
-
予定通りでがっかり
-
平均寿命とは
- 0歳のときの余命?期待値?0歳の死亡率と90歳の死亡率は異なる。
-
Mutexはなぜ機能するのか
- どのような実装をしているのか、どのような命令なのか
-
仕様変更について(2019秋)
- 顧客は水と仕様追加はタダだと思っている
- https://takam0.hatenablog.com/entry/2016/06/10/エンジニアはどうしてそんなに「それは仕様変更
- 嫌な理由
- 変更があったときの影響が分からない
- AをBにしてほしい。Aを前提条件としている別のモジュールが壊れる
- システムの目的、気を付けるポイントが分からないから変更後に正しく動く保証がない。影響の調査がいる。
- じゃあ実際どのくらい簡単なんだろう
- 変更があったときの影響が分からない
-
locklessinc
-
初心者は悩んだって成功しない vs 何も考えずにやる
-
no static, inject it.
- 面倒じゃない
- factory pattern
-
ARR01-C
-
Project-Iの立ち位置
-
問題の構造化
-
科学的方法 Scientific Method
-
正確に実装しきる難しさ
- 見ず知らずのシステムに手を加える
- 近くのコードをコピーして動きをまねる
-
Smile&Tears 名言多いね
- 立派でもお金持ちにならなくていいから元気に育ってほしい
-
DE-9IM
-
わくわく、冒険、寓話、新しきを知る
-
エラーモデル
- 無言の部下 void
- 言葉足らずな部下 bool
- 面倒な部下 int
- 無口な部下 fn(*out)
- 判断できる部下 throw
-
失敗の検知とログ出力ならerrorで十分
- 復旧しようとすると大変。
-
善意の誤読
-
悪意の誤読
-
uint 計算途中のオーバーフロー
-
動的なサイズのパケット解析
-
テストコードを描いたら本当に解決するのか
- 仕様変更に耐えられていないのではないか
-
自分が想定している構造ではなく、実装者が想定したよくわからない構造を読み取る
-
意図の分からない関数は上位に行けば分かる
-
バリデーション
- 考慮すべきことを考慮していない
- 謎のadjust
- なんでadjustしてるの
-
SingleColumnTable
- It is fine to have a table with only one column. Unary Relation in Relational Algebra - "This this exists"... In most cases it benefits by adding additional column.
-
ログイン機構のデザインパターンを書き出したけど大した実績にならなかったな。無駄だ。
- データベースについて考えるきっかけになった?
-
リファクタリングしたくなる病
- だってどこに追加仕様を描けばいいのか分からないんだもん。
- 一度始めると終わらないよね
--
よくわからないやつ
二つのグラフの並べ方
*****----- 50/100 (ratio)
*****----- 20/40
*****----- 50/100 (absolute)
**-- 20/40
言葉
-
まあちょっと様子見です(笑 ← hidoi nihongo
-
~しないといけないこと
- 気にすべきこと
-
解答してください
- 意見をお寄せください
-
まだ未完成
- 未完成
-
discipline
-
方法は問わない
- 方法を知っている者のみわかる
-
メモリを保存する