´Д｀)< 泣いた — Takoyaki _umaaaaaa (@TakoyakiU) October 13, 2017

最近だいぶ親戚の赤ちゃんに懐かれる！ 多分、家族と親戚内でもセックスしたことないのが 俺と赤ちゃんだけだからかな！波長が合うってヤツ？？ははーん？ — 大童貞男(おおさわらさだお) (@oosawarasadao) October 13, 2017

´Д｀)< ワイのパンツに印刷しておきたいくらいの美しさ — Takoyaki _umaaaaaa (@TakoyakiU) October 13, 2017

ＣＵＲＥＷＨＩＴＥ！！ http://pic.twitter.com/uzYJxTTmq9 — JJ(獅子つつし) (@jj_art_works) October 10, 2017

´Д｀)< 辛いンゴねぇ・・・ — Takoyaki _umaaaaaa (@TakoyakiU) October 13, 2017

´Д｀)< なった。 — Takoyaki _umaaaaaa (@TakoyakiU) October 13, 2017

´Д｀)・・・ — Takoyaki _umaaaaaa (@TakoyakiU) October 13, 2017

´Д｀)< 問題箇所・原因が特定できるログというのは本当に重要になる。 実装しているときは適当に対応しがちだけど、あとで大変なことになる。 — Takoyaki _umaaaaaa (@TakoyakiU) October 13, 2017

´Д｀)< 「あたりまえでしょ」とか「普通」とか思うけど、これができていないことが非常に多い。非常に多い。 project が佳境に入ってくると、不具合修正に求められるスピードは本当にシビアにものになってくる。悠長に再現確認なんてしている時間はない。 — …

´Д｀)< そのほかはエラー箇所の log 出力。面倒だろうけど、チマチマと入れて行った方がいい。 重要なのは ・どの部分で発生したか特定できる ・エラーとなった値を出力する こと。 — Takoyaki _umaaaaaa (@TakoyakiU) October 13, 2017

´Д｀)< あくまで自分の process 内で出すようにする。 マジでめんどくさいことになるからね。しかもこれが問題になるのは project 終盤だから、余計に問題が大きくなる。 別チームのリソースを奪うようなことはご法度。覚えておこう。 — Takoyaki _umaaaaaa …

´Д｀)< 問題切り分け用 log でもう１点注意が必要な箇所がある。 それは「別 task で出力しないこと」。 callback 関数とか、API 提供した関数の中とか。 そこで出したい気持ちもわかるんだけど、相手の task が重くなって問題になることが多々ある。 — Tako…

；´Д｀)< だいぶ痛い目を見たからな・・・ この辺りは何度でもしつこく言いたいところ・・・ — Takoyaki _umaaaaaa (@TakoyakiU) October 13, 2017

´Д｀)< つまりそれなりの log を出そうとすると、そのモジュールの作りもそれなりに考えている必要がある。 log はただ入れればいいというものではない。最後には頼ることになるんだから、しっかり考えて入れておく必要がある。 — Takoyaki _umaaaaaa (@Tako…

´Д｀)< そうでないと log から「相手からのデータが来ていないのが問題だ！」と判断しても、実は log に出ていないだけでデータを受け取っている可能性があるなんてことになれば、その log 自体に価値がなくなるからね。 — Takoyaki _umaaaaaa (@TakoyakiU) …

´Д｀)< 重要なのは ・外部とやりとりしている全データを出力すること ・データの送信直前，受信直後に出力すること これらが作りとして保証されている必要がある。 つまり外部とのやりとりを行う箇所は極力１箇所に絞り、その場所に log を仕込む必要がある…

´Д｀)< log 出力 code で気をつけることを少し書いてみる。 まず最初に必要なのが、不具合発生したときにその不具合が自チームのものなのか、他チームのものなのかを切り分けるための log 。 例えば別モジュールと通信している部分や API 呼び出ししている部…

´Д｀)< あとは他チームが出力している情報と被らないこと。機密情報は出力しないこと。個人を特定できるような情報とかね。 — Takoyaki _umaaaaaa (@TakoyakiU) October 13, 2017

´Д｀)< 再現性の低い不具合で、肝心な部分の log が出せていませんでした、なんて大変なことになってしまう。 どういう場所に入れるのが効果的か、どういう目的で入れるか。それをはっきりさせて入れていく必要がある。 — Takoyaki _umaaaaaa (@TakoyakiU) O…

´Д｀)< code への log 入れは技術だよ。マジで。 log は入れすぎてはいけない。組み込み機器の log 保存領域は狭いから、出し過ぎると欲しい部分が消えてしまう。 しかし少なすぎてもいけない。欲しい情報が無いと、問題が発生したときに解析ができなくなる…

Log に出力される AT コマンドを読んだりしていた。 ある程度分かりやすい出力をしてくれるのは助かったな。 — Takoyaki _umaaaaaa (@TakoyakiU) October 13, 2017

´Д｀)< チップの動作制御は別チームの担当だったんだけどね。 そのチームが提供する I/F を使って bluetooth 経由で Android アプリと通信したりしていたから。 不具合が発生したときに、 BT チームの問題なのか自チームの問題なのかを切り分けるために — Ta…

´Д｀)< AT コマンドは直接扱ったことはないけど、 Bluetooth 通信用のチップが制御のために AT コマンドを採用しているものがあって、どの動作確認のために見る必要があった。 — Takoyaki _umaaaaaa (@TakoyakiU) October 13, 2017

去年ATコマンドを実装したときのメモを発掘したので、ウルトラどうでもいいATコマンドのひみつを大解説するぞ！ (1) 「AT」はコマンドキーワード。ATでもatでも通じるが、大文字小文字混合のaTやAtは通じない。 — ウチューじん・ささき (@uchujin17) October…