ダチョウ倶楽部か…

電着付けたまま寝るのはまれによくある

今日もやっちまったぜ

仕事だ
休日出勤（在宅）

会社がトリプルモニターでリモート繋げるのはいいがこっちは2枚しかないから画面足りねえ…
やっぱタブレットを予備ディスプレイにするか

ビューカードの更新が来たが
大阪住みにはSuica残高の移し換えができない

SQLのアクセス回数が多いのなんだかなあ…

グループ内の機械リストとるのにSQL1回
機械1つにつきSQL1回

さすがにこれはないなあ…

せめてfetchせずに途中式のまま処理続けて欲しい…

人によってORMの記述が微妙に違うのバグ対応かなり辛いぞこれ

お昼やぞ！

はい。

最新値の取得方法でこんな効率の悪い取り方があったのかと他人のコードを見てびっくりしてる

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にかけてるんだよ！
ってところが非常に悪い

inner join 芸人

拙者inner joinのon句をWHERE句の代わりに使う侍でござる

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();

ってソースコードマジでやめてくれーーーーー

そのnewはなんなの！！！！！！？？？？？？？

なんで単体試験バグ対応でソースレビューしてんだよ…

んだよこのソース😡😡😡😡😡😡💢💢💢💢💢💢💢💢

コーダーによってバグの傾向はあるな
まあ基本的に動作確認なしで単体に回ってくることもあるし（ぬるぽ
だからといって
テスト駆動開発も悪くないんだがテストデータ作成が大変なことになるからなあ…

今回のプロジェクトでDBのデータ構造に対して割とみんな理解ができてるなあと思うのはDBのサンプルデータが結構しっかり作れたところだろうか…

SUGOI Excel

ノルマのバグ対終わったけどこれ午前中に終われたな…っていうか休み明けで十分だと思う
休出する意味ねえ

やはり分離キーボードの間にマウスは置くよな

うちのは静音赤軸なので静音改造が要らないな…

MD770はRGBの方がいいな
マクロ登録時に登録済みキーが光ってくれる

キーボードのベースプレートに鉄板は欲しいと思う
打感的にも安定性的にも

ジョンソンヴィルうまい

AIって言う名前のただの条件判断式

この動画を見た人はこちらも見ています

おーい磯野
九州で凧揚げしようぜーーー

セブンのベイクドチーズケーキ
やっぱ冷凍した方がうまいな