(広義の)サイバー犯罪に巻き込まれたときどのレベルまで同情の余地があるのか
kb10uy(@kb10uy@mstdn.maud.io)の投稿 美少女のもみあげと裾についておはなしします
🔞性欲駆動開発アカウントにつき覚悟してください
Avatar icon: [𝕏] nunyu31
Header: [𝕏] hataraku125
弐寺: 1751-5340
夏稀bot もよろしくね: @mecha_natsuki
容量を信用してはいけないもの、メールの添付ファイル容量の他にブラウザのCookieなどがあります
このアカウントは、notestockで公開設定になっていません。
教材とかの目的で狙ってでもやらなきゃあんなガバガバなWebアプリケーション作れないでしょ最近のフレームワークは
ローカルファイルを操作したという点よりかはそれが送信されるリクエストに影響してしまうという方が問題っぽそう
この記事における「脆弱性による損失を通報者に被せようとする組織」の存在の可能性が脆弱性報告に対する心理的安全性を大きく下げてそう
脆弱性関連情報の届出関連 FAQ：IPA 独立行政法人 情報処理推進機構
https://www.ipa.go.jp/security/vuln/faq.html#Q1-8
> 脆弱性関連情報の届出について定めたガイドラインにて、発見者は「氏名、連絡先等」を明らかにすることが求められています。
> →ガイドライン IV. 2. 5) , V. 2. 4)
> IPAでは、発見者の情報を個人情報の取扱い方針に従い、適切に管理しています。発見者が希望しない場合は、発見者に関する情報が製品開発者やウェブサイト運営者に伝えられることはありませんので、安心して届出をしてください。
調べたけどAimeの譲渡は御法度(当たり前)だけどオンゲキのカードは特に禁止する文章が見付からなかった
@kozue 印刷と合わせて200円ぐらいですね
ところでR(さっきの)でよければもうちょっとで枠なしにできますがどうしますか？
むしろ歴史的な話を聞くものとして聞きたさがなくもない (そうでもないかも)
JOINとかしまくると結果が十数カラムの闇のクエリが発行されることがあり、正直ローカルに型生やせてもちょっとつらい
そもそも Rust では匿名の型を生やすというのがあまりアレなので…… (一応 existential types とか structural record の提案はある)
RFC: Structural Records by Centril · Pull Request #2584 · rust-lang/rfcs · GitHub
https://github.com/rust-lang/rfcs/pull/2584
というのも、こういうことをしようとすると連番用シンボル列の生成と、連番用シンボルと固定文字列の結合による新シンボル作成が必要になると思うんですが、後者に必要な `stringify!` マクロが微妙なので。
たとえば stringify!(foo_, bar) を $sym:ident として受け取りたくても、実際やろうとすると $sym には `stringify` だけ読まれてパース失敗するとかそんな感じのことが起きたはず
let foo: { id: u32, text: String } = { ... }; みたいなことができればいいんだけどねえ
https://mstdn.maud.io/@kb10uy/101928007913375694
もしこれっぽいことをやるなら生成される使い捨てのstructをどうやって生やせばいいのか、みたいな文脈
Rustのマクロに造詣の深い各位に聞きたいことがあるんですが、Rustのマクロで「fn内で連番になるような識別子」って生成可能なんですか?
後藤 英一-コンピュータ博物館 http://museum.ipsj.or.jp/pioneer/gotou.html
「外国人研究者：「俺は後藤という日本人を3人知っている．パラメトロンの後藤，ゴトー・ペアの後藤，磁気単極子の後藤．お前はそのどれかか」後藤英一：「俺はそのすべてだ」の後藤英一は1931年1月26日東京渋谷に生まれた」
一々 struct を明示的に生やすのがアホらしいというだけで型安全性を投げ捨てたいわけではないし、このマクロぐらいならけっこう実現性ありそう
query!(query_object, {
id: u64,
count: i32,
created_at: Timestamp,
})?;
ぐらいで書けるならわりと良さそう
でも実際生成されるクエリから結果のカラム名は決定できるはずなので、一律にStringにマップするならわりとできそうな気がしてくるな
アプリケーション側で DBのスキーマを全く知らないという前提を持ってくると急激に困難にならないかこれ
どうやって変換するかよりどうやって効率良く様々なクエリに対して安全な型を生やすかみたいな話に帰着しそうな感じがしてきた
よく考えたらあれは何もJSONやらTOMLやらのフォーマットとのser/deのためだけにあるものではなかった
そもそも Rust で型安全に {de,}serialize するときのデファクトスタンダードは serde だし、こいつは実質 any みたいな型とちゃんとした型との間を安全に変換する機能があるのでそんなに悩むことはない
C# (.NET) には dynamic があるし PHP には stdClass があるし(ぼくは assoc のが好きだが)
まあ Rust であの手のクエリビルダを手書きでやるのは多分死ぬのでうまいこと変数にマッピングさせてやる必要があるんだろうねえ
Laravelのクエリビルダのようにメソッドで分かれていたりするなら型定義で適切な匿名型を生成しろという意見もありそうだけど、それをやると今度は生SQLが書けなくなる可能性が発生する
ちゃんとDBのスキーマに対応するようなクエリだけが発行される場合は DB と対応する型を生やす意味はある
Laravel のクエリビルダや knex.js 、Dapper は任意のクエリに対してその通りの結果を返すのでアプリケーション側に型を生やすという行為が愚の骨頂になるんだった
少なくともJSはORMをやるとPOJSO性が失なわれて逆に不便ということが起こりうるので [x: string]: self | number | string ぐらいにしかマッピングしなくて良い気がするけど(個人の感想です)
なので、 DB で型付きであるというのは何の慰めにもならない……
というより、ビジネスロジックと DB 側での型の相違をちゃんと検出できるかというのがクエリビルダや ORM の型安全性の本質ではという感じがする
knex.js は Dateは忘れたけど JSON/JSONBカラムは本当にJSオブジェクトになる
クエリビルダとはいえそれに投げさせるとDBの型に合わせて数値・文字列・日付ぐらいはアプリケーション側の型に合わせてくれるしねえ
あとは DB によって既に型が保証されているのでアプリケーション側での型安全性をそこまで気にするほどでもないという意見もある
参考までにLaravelのマイグレーションはこんなかんじですが
https://github.com/kb10uy/shortstoryserver2/blob/master/database/migrations/2019_04_14_095850_create_posts.php
diesel も本質は type-safe なクエリビルダで ORM はオマケだよということになっているみたいなので、 Rust で DDL を操作できる別ライブラリが必要とされている気がする
Eloquentの本質、クエリビルダであってActiveRecordの部分ではないと思っており
diesel-rs はマイグレーションそのものの SQL は生で書くことになってますね、そのマイグレーションを適用した DB にアクセスして Rust のコードを吐くところはサポートされてるんだけど
Eloquent、knex.jsなどの形で移植されてるぐらいにはORMとして優秀だと思うんですがどうでしょうかね
入れ替えよりも「マイグレーションとかバックエンド毎に書きつつ一貫性を保ってビジネスロジック側では単一のコードで扱いたい」みたいな気持ちがある
残念ながらテスト環境だけ SQLite にしたいみたいな需要を常に抱えて生きているので、いつも不満
iPad(第3世代)をそろそろ引退させてあげたいが僕は使ってないし金がないというので何も買えないんだなあ
> この配色が「ミカンの実と葉の色にちなむ」というのは後付けの説明であるが[1][15]、
> この他にも「神奈川県西部や静岡県地方特産のミカンとお茶にちなんだもの」といった沿線の風物に発祥しているとする説明が広くなされており、
> JRが発行するガイドなどでも「みかんやお茶など、沿線の特産品を表現した塗装」というように解説されている場合がある。
https://ja.wikipedia.org/wiki/%E6%B9%98%E5%8D%97%E9%9B%BB%E8%BB%8A#%E6%B9%98%E5%8D%97%E8%89%B2
サマータイムと呼ぶと真夏しかやっていないかのような誤解を受けるので日常会話でもDaylight Saving Time (DST) と呼んでいる
Berry Go (Aire Remix) - Freezer feat.妃苺 #NowPlaying
まだ全然サマーじゃねえぞとか思って調べたら3〜10月とか書いてあって :sokka: になった
夏稀の彼氏 さんのチェックイン (4月15日 08:23) - Tissue https://shikorism.net/checkin/2021
人事の問題、本当は第三者機関用意するべきなんだろうけど大学でそんな第三者なんて集められないよなあ
