加齢してカレーを食べた人「か、辛え〜」
ボンクラプログラマー
頭とお腹が弱い。
最近は個人鯖の @shibafu528 がメインです。
⚠️ CW設定のない下品な発言が非常に多いです。これは仕様ですのでご了承下さい。
ℹ️ spam対策でフォロー承認制にしています。上の一文が構わないという方ならお気軽にどうぞ。
FINAL FANTASY XIV 関連の著作物は
(C) SQUARE ENIX CO., LTD. All Rights Reserved.
今日のshibafu528
「これキーの型的に必要なデータ取れなくない?」 「PHPならできてた!!(池沼)」
キャストする必要があるところで忘れてたならまだありがちだけど、キャストせんでいいのにキャスト書いてて指摘された瞬間吹き出しそうになったんだよな
kb10...9...8...7..6..5..432..1..111111100000000uy
いやマジで都民になったせいでこれに参加なの最悪なんだよな、東京都最大のディスアド
y4aには「改行多すぎるやつは画面が埋まってしんどい(から、極端に多いのは隠せるようにしよう)」「同じ文字列の行を反復してるのはウザいし大抵内容が無いから始末しよう」の思想があります
極端に多い、と曖昧なことしか言ってないのはポイントで、なぜならユーザーが1行単位でそのリミットを指定することはできないからです…(適当に作った)
家に帰ったらつついさんからの荷物が野ざらしにされ、おかんからの荷物が再配達になっていた
なんか2人くらい住民と初エンカウントして、声出なかったので不審者として認識されたかもしれん
芝生にお誕生日に情報のプレゼントをするとラズピッピのRAMが8GBになった
おおー、composerのメジャーバージョンアップが近い将来にあるんやな
Composer 2: What's new and changed • PHP.Watch
https://php.watch/articles/composer-2
2020年になっても複数リポジトリをソースとしたパッケージインストールを丁寧に強化しているの好感が持てる。
並列ダウンロードがとうとう標準サポートになるのが一番ユーザーインパクトが大きそう。
混沌としたPHPのライブラリインストールを統一するためには必要だったと思うが、もう不要になるんだなあ……
ついにPHP 8.0からはjson extが常時有効! もうjson extが無いと泣くことはないぞ!
https://wiki.php.net/rfc/always_enable_json
https://github.com/php/php-src/pull/5495
1_ちゅっちゅっちゅ……30分500万の女ですわ!.wav という東北イタコexVOICEがあってな
今日の #進捗
https://github.com/lo48576/thinking_faces/blob/master/png/256/syncing_face.png
:syncing_face: を作成・追加しました。
同期しているときにお使いください (???)
: drinking_face: です #進捗
https://github.com/lo48576/thinking_faces/blob/master/png/256/drinking_face.png
ちょっとTissueのDB持ってきてインデックス張るテストしたいなと思ったが、家の中に置いてあるPostgresが9.5やった…
Tissueのポスグレはいつバージョン上げようかねえ 言語環境ほど切迫しないしミスった時のインパクトでかいからつい放置してしまう
Please shutdown that postmaster and try again.
Failure, exiting
あ、はい…
postgresql96-setupがpg_hba.confを爆破しやがったので、泣きそうになりながら local all all trust した
Tissueのdocker-compose.ymlではpg10になっているけど、あれ実は本番と合ってないから注意が必要
ActiveRecordパターンなORMが横たわってる環境でガチのRDBMS依存クエリバリバリに書くやつおらんやろの構え
Tissue開発初期に初手生クエリでWindow関数使いだしたshibafu528のことは知らん
開発用だからまあいいけど、本番のアップデートやるときはダンプだけじゃなくて真面目にdata/をバックアップしてからじゃねえと危ないな
TwitterFactoryは実装上、常に新しいインスタンスを返すよな。んで、キャッシュでたまに取り違えがあるんだよな。ということは……キャッシュ用のコレクションに複数スレッドで書き込んで内部がぶっこわれたか?
毎回Twitter4Jのインスタンスを作るのと、synchronizedブロックでキャッシュ問い合わせするの、どっちがコスト安いかって話くらいだな。
twitter4j.TwitterFactoryは、new twitter4j.Twitter()ではなくリフレクションによるnewInstance()をしているのだけがコスト的に気がかりといえば気がかりか。
y4aの問題の処理はKotlinで書かれているけど、実際には2016年に書いたJavaコードのベタ移植だから……その時からずっとこのバグを抱えていたんじゃないかな?
そして、それより前ではアプリケーショングローバルで1つだけtwitter4j.Twitterのインスタンスを持ち回って、API呼出前にAccessTokenを都度書き換えていたから……
ハァーーーー、ファーストリリースから今まで7年くらい、ただの一度も安全ではなかったってことだけが分かりますね