coming soon
もみあげの長い美少女の話ばかりしています
Avatar icon: [𝕏] CamemBellcheese
Header: [𝕏] generalcanon
各種フレコ:
beatmaniaIIDX(九段): 1751-5340
オンゲキ(15.8): 3067667719792
Arcaea(◆9): 433827474
!!!カオスタイム!!! 、文字列としてめっちゃ擦ってるけど実際太鼓でやったことは一回もないのそのうちバチあたりそう 太鼓だけに
This account is not set to public on notestock.
This account is not set to public on notestock.
.NET の Process 作るときにコマンドライン引数が単一文字列なの意味わからんと思ってたがあれは Windows の仕様を正確に反映したものだったのか クソやん
This account is not set to public on notestock.
これかな
NovaWave 3Way | 株式会社CIO(シーアイオー)公式HP 充電器・モバイルバッテリーメーカー
https://connectinternationalone.co.jp/cioproduct/wirelesscharger/novawave/cio-3way-mgaprg/
2-in-1 MagSafe + Watch travel charger | Zens
https://zens.tech/shop/2-in-1-magsafe-watch-travel-charger/
This account is not set to public on notestock.
まあ正直追加の Qi ポートはなくてもいいので持ち運びやすい iPhone+Watch 充電ソリューションのおすすめがあれば知りたいです
MagGo Wireless Charging Station (Foldable 3-in-1) とかどうなんだろう(たけえなあ)
https://www.ankerjapan.com/products/b2557?variant=43752864907425
毎回家出るときにこれ↓からケーブルひっぺがして持ってってる
https://www.ankerjapan.com/products/a2579
OSCtouch、コントロール単位だと note でメッセージが分かれちゃって微妙な感じだからやっぱ自作するしかない可能性があるな
「ねえ ユニクロのトイレの壁に サイズの細長いシール貼っていく奴 お前マジでなんなんだ お前マジでなんなんだ」、歌詞として好きすぎる
This account is not set to public on notestock.
うまくいってればさっきの一回でこういう状態になってるはずなので、しましまだけのテクスチャを入れれば全部しましまに見えると思う
それはそうと罪過の聖堂、灰はギリギリギアチェンなし(MAXBPM 合わせ)で行けそうだけど穴は全く歯が立たん
KDDI小山ネットワークセンター 構内一般開放のお知らせ
https://news.kddi.com/kddi/corporate/topic/2023/04/11/6665.html
ちなみに YubiKey は YubiKey OTP という独立した OTP システムを実装してるけどあんまり使える場面を知らない
あと、Standard-Aが必要な理由がなければType-Cの方が耐久性がいくらかマシな上にセキュリティーキーの例のStandard-A的なコネクタ(なんか通称があるけど忘れた)は真のStandard-Aと違って金属カバーがないので市販のカバーが使えないという問題もあり、コネクタが壊れたときのフォールバックとしてのNFCも考慮してType-C + NFC対応モデルにするとよいという有力説がある
「ラジコンパークGoka」オープン | 五霞町公式ホームページ https://www.town.goka.lg.jp/page/page005009.html
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
結線だけのやつはキーボード側で判定して USB デバイスとして振る舞うか PS/2 デバイスとして振る舞うか決定してるとかなんとか
スイッチングハブなどと同じように USB ハブ自体も 1 台としてカウントされるから意味のあるデバイス 127 台繋げられるようにするのはかなり厳しそう
This account is not set to public on notestock.
交渉しだいでなんとかなると言われてるけど BigQuery で適当にクエリ流したら膨大なテーブル参照が発生して数百万円の請求になるやつとかもあるね
だいたい Booth で売ってるようなアバターの髪の毛は 1.0 にしておくことで髪の重力をかけつつペタってならないようにできるのか
ところでこっちの open-beta がリリースされると今度は ik-beta がネットワーク非互換になりそうなんだけどもしかして内部ではもうマージ済みだったりするのかな
This account is not set to public on notestock.
This account is not set to public on notestock.
PC だと生産に入るまでが時間かかって生産から出荷までは割とすぐっぽいんだけどモニタだとどうなんだろう、生産自体に時間かかるのかな
This account is not set to public on notestock.
VRCLens 側の設定と VRChat 側の設定を合わせないといけないのもその辺のシェーダーコード内での分岐に必要だったからと記憶している
VRCLens 便利に使ってるけどあれフレームバッファ(Unity 的には RenderTexture か)の乗っ取り方法がカメラ情報とか解像度に依存してるはずなので、そこの情報が取れなくなったら終わってしまう
実用面では WQHD 解像度ぐらいにはしたいと思いつつも、写ってるテクスチャの解像度が良くて 2048 とかなのでSSAA ぐらいにしかならないんだよな
自撮り心がけているとはいえやっぱり比率としては少なくなりがちで、ツイに上げるときは他人の写真を引用することがあるので撮った人を明示するようにしている
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
この記事における「脆弱性による損失を通報者に被せようとする組織」の存在の可能性が脆弱性報告に対する心理的安全性を大きく下げてそう
脆弱性関連情報の届出関連 FAQ:IPA 独立行政法人 情報処理推進機構
https://www.ipa.go.jp/security/vuln/faq.html#Q1-8
> 脆弱性関連情報の届出について定めたガイドラインにて、発見者は「氏名、連絡先等」を明らかにすることが求められています。
> →ガイドライン IV. 2. 5) , V. 2. 4)
> IPAでは、発見者の情報を個人情報の取扱い方針に従い、適切に管理しています。発見者が希望しない場合は、発見者に関する情報が製品開発者やウェブサイト運営者に伝えられることはありませんので、安心して届出をしてください。
@kozue 印刷と合わせて200円ぐらいですね
ところでR(さっきの)でよければもうちょっとで枠なしにできますがどうしますか?
むしろ歴史的な話を聞くものとして聞きたさがなくもない (そうでもないかも)
そもそも 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にマップするならわりとできそうな気がしてくるな
そもそも Rust で型安全に {de,}serialize するときのデファクトスタンダードは serde だし、こいつは実質 any みたいな型とちゃんとした型との間を安全に変換する機能があるのでそんなに悩むことはない
C# (.NET) には dynamic があるし PHP には stdClass があるし(ぼくは assoc のが好きだが)
まあ Rust であの手のクエリビルダを手書きでやるのは多分死ぬのでうまいこと変数にマッピングさせてやる必要があるんだろうねえ
Laravelのクエリビルダのようにメソッドで分かれていたりするなら型定義で適切な匿名型を生成しろという意見もありそうだけど、それをやると今度は生SQLが書けなくなる可能性が発生する
Laravel のクエリビルダや knex.js 、Dapper は任意のクエリに対してその通りの結果を返すのでアプリケーション側に型を生やすという行為が愚の骨頂になるんだった
少なくともJSはORMをやるとPOJSO性が失なわれて逆に不便ということが起こりうるので [x: string]: self | number | string ぐらいにしかマッピングしなくて良い気がするけど(個人の感想です)
なので、 DB で型付きであるというのは何の慰めにもならない……
というより、ビジネスロジックと DB 側での型の相違をちゃんと検出できるかというのがクエリビルダや ORM の型安全性の本質ではという感じがする
クエリビルダとはいえそれに投げさせると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 を操作できる別ライブラリが必要とされている気がする
diesel-rs はマイグレーションそのものの SQL は生で書くことになってますね、そのマイグレーションを適用した DB にアクセスして Rust のコードを吐くところはサポートされてるんだけど
入れ替えよりも「マイグレーションとかバックエンド毎に書きつつ一貫性を保ってビジネスロジック側では単一のコードで扱いたい」みたいな気持ちがある
残念ながらテスト環境だけ SQLite にしたいみたいな需要を常に抱えて生きているので、いつも不満
> この配色が「ミカンの実と葉の色にちなむ」というのは後付けの説明であるが[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) と呼んでいる
夏稀の彼氏 さんのチェックイン (4月15日 08:23) - Tissue https://shikorism.net/checkin/2021