エアコンの洗浄がしたいなあ…
社員証首からぶら下げてるのぶらぶらしてたり
机と腹で挟んでケース破損しそうで邪魔なんだよ
ガジェットオタクに風俗はありません
ガジェットそのものが嬢です
ガジェットには見境なく突撃します
人柱もﾊﾞｯﾁｺｲ
今日はそれだけを覚えて帰っていってください
そういえば遠方の業務面接でなぜかラズパイトークで盛り上がってしまって採用されてしまったことあったなあ
まあ辞めたけど
kyashの金の流れがいまいち信用できないのでおとなしくブラックカード使っときます
でもまあブランド偽装はアリかなあとは思いはするが
しかしなあSIMカードが壊れる事なんてあるのか
シェアしてるデータSIMあるから050番号と通信はできるが電話が死んでるしなあ
安SIMだと多分SIMカードの保証は無いだろうから有償交換かな
キャリアだと即交換してくれそうだが。
テプラで宛先シール印刷するようになって
宛先を書くという心理負担が無くなったのが地味にデカい
4K 43インチで
左下だけでフルHD実質21.5インチと同じ領域で作業する
動画映画見るときは離れて全画面
会社がトリプルモニターでリモート繋げるのはいいがこっちは2枚しかないから画面足りねえ…
やっぱタブレットを予備ディスプレイにするか
グループ内の機械リストとるのにSQL1回
機械1つにつきSQL1回
さすがにこれはないなあ…
最新値の取得方法でこんな効率の悪い取り方があったのかと他人のコードを見てびっくりしてる
https://www.risewill.co.jp/blog/archives/3483
どれが一番効率いいんだろうなあ…
あとwhere句に絡めずinner join句も絡めたいとすると
とかもあるし
長めのSQLの結構の数をjoinするとなるとEXISTSはあまりいただけるものでもないよなあ…
https://qiita.com/tatsuo-iriyama/items/83b12d066453f8478fd7
実行計画調査してもいいがめんどいというか
そもそも論としてソースに書かれているSQLの効率が非常に悪いから調査するまでもないしスルーしようと思ってる
だからなんで「一覧」を一回SQLから戻ってきてListに持たせてListをforしてまた要素をSQLにかけてるんだよ！
ってところが非常に悪い
from
aTable
inner join bTable
on aTable.id = bTable.id
and bTable.type_id=4
and aTable.tel_type=2
;
みたいなことを平気でやる
innerjoinのon句をWhere句代わり使うのは
joinするテーブル数が増えたときとかレコード数が多くなると影響がデカい
全部joinしてからWHEREするか、
条件に合ったレコードをjoin時に切り落とすか。
今回のプロジェクトで我の書いたSQL≒JOOQコードはWHERE句が極端に少ない
AClass hoge = new AClass()
hoge = fugafuga.method();
ってソースコードマジでやめてくれーーーーー
コーダーによってバグの傾向はあるな
まあ基本的に動作確認なしで単体に回ってくることもあるし（ぬるぽ
だからといって
テスト駆動開発も悪くないんだがテストデータ作成が大変なことになるからなあ…
今回のプロジェクトでDBのデータ構造に対して割とみんな理解ができてるなあと思うのはDBのサンプルデータが結構しっかり作れたところだろうか…
ノルマのバグ対終わったけどこれ午前中に終われたな…っていうか休み明けで十分だと思う
休出する意味ねえ
