まあ言うて日本も狂牛病がどうとかで似たようなことをやっているというのはある
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)の投稿
まあ言うて日本も狂牛病がどうとかで似たようなことをやっているというのはある
『宇宙軍士官学校』の存在を唐突に思い出し、全巻買って読みたくなってきた
/dev/neru
#今すぐ寝ることで救える命があります
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
data を潰して content と entries が乱立する回 (?)
datas は使わんけど hogeinfos は使いがち(Vec<HogeInfo> みたいな文脈で)
Info って型名で使うことあまりないな。オブジェクト自体が大抵は情報なので (稀に情報でなくハンドルなこともあるけど、その場合そっちに -Handle と命名する)
このアカウントは、notestockで公開設定になっていません。
あーでも node handle に Node と命名してコンテントとメタデータに NodeData と命名したりしてたわ、 Info と似たようなものか
メタデータの塊に Info とか Metadata というサフィックスを付けたくなるよねという話やね
メタデータに -Meta したくなるのはちょっとわかる
でもどちらかというと私は meta な方がプレーンな名前で、コンテントに -Content と付ける癖があるな
というより、メタデータとコンテントを合わせてひとつの型にすることが多くて、コンテントが専用の型であることって意外と少ない。コンテントはそこそこ汎用的な型で通せることが案外あるので
べつに古来から「さぎょいぷ」みたいな概念はあったし、プライベートと仕事のコミュニケーションは全然違うだろという話でしかない気がするが。
プライベートのそこそこ親しくて無礼講気味な流儀を仕事に持ち込まれたら、そりゃ嫌に決まってるだろ
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
の投稿
herschel@raptol.net
このアカウントは、notestockで公開設定になっていません。
CPU or M/B のせいで USB デバイスが brick したり M/B 上のチップの対応が悪いせいで無線がランダムに利用不可になったりしているマンとしてもな……
OS 以上のソフトウェアの不具合はだいたい雑にパッチ書いて誤魔化せるのでどうにかなっているけど、ハードウェアで踏み抜くやつはだいたいどうしようもないので険しい
Infoとかそれはメタ情報(？)であるって単語等を型名につけない文化圏、例えばオーディオプレイヤーアプリ作る時に、曲名とかの情報をどういう構成でどういう風に扱ってどう命名するのか謎＞＜
オレンジは曲クラスが曲名等情報クラスを持ってるみたいな構成にして、曲名等情報クラスの名前はInfoかなにか忘れたけどなんかそういう「これはメタ情報である」的な命名してたような記憶ある＞＜
そもそもアプリケーションくらいの高いレイヤーでの設計だと、型ってもんが本質的にメタな部分あると思っている
このアカウントは、notestockで公開設定になっていません。
アプリケーションのレイヤーで「音楽そのもの」なんてものはないし、たとえばハンドルであるにせよ ID であるにせよ曲名とアーティストであるにせよパスであるにせよ、「概念を表現するメタ情報をオブジェクトとして持っている」という形になるわけで
たとえば音楽の波形データであればそれは音楽そのものではなく「音楽の波形」として扱うことになるだろうなと。
その波形を音楽 (を表現するオブジェクト) から弄れるようインターフェースを作ることはあるだろうけど。
で、インターフェースというのは間接的であるものだから、「音楽」を表現するオブジェクトが内部的に何を持っていようがどうでもいい。「音楽そのもの」であるか「音楽を指す何か」であるかの区別なんてものは必要ない
そのうえで「ストレージ内で音楽を表現するバイト列やオブジェクト」を指すものを作りたいのであれば -Handle という形で「(音楽自体というよりは) ストレージ内のリソースを指している」ということを明示する意図があるので私は -Handle を多用する (そして -Info は普通のことなので省く)、という感じ
このアカウントは、notestockで公開設定になっていません。
の投稿
herschel@raptol.netこのアカウントは、notestockで公開設定になっていません。
XPS 15 9570 あたりは鼻毛カメラだったんだけど、どうも最近の XPS は違うのかもしれない……
DELL XPS 15 （9570）レビュー！CoffeeLakeモデル。パソ兄さん
https://www.pasonisan.com/dell/xps15/9570-corei7-8750h.html
↑画面下部
Is the new Dell XPS 15 webcam below the display? | Windows Central
https://www.windowscentral.com/new-dell-xps-15-7590-webcam-below-display
> Fortunately, designs have matured, and the latest version of the XPS 15 doesn't have that problem. Its webcam is exactly where you would expect to find it — right above the display
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
の投稿
herschel@raptol.netこのアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
オレンジの事例の音楽そのものって、再生可能なオーディオデータのクラスで、生のデータ(を持つバイト列やストリームのクラス)や長さの情報やチャンネル数等は持ってるかも＞＜
でも、メタデータはメタデータであるので別って発想でそのクラスにベタに曲名プロパティとかアーティストプロパティみたいなのとかキーバリューなメタデータリスト等を直接置いたらごちゃっとしそうだから、ベタに置くのは避けたかも＞＜
その場合、たとえば全部メモリに乗せるなら
struct Sound {
channels: u8,
len: Duration,
repeat: bool,
waveform: Vec<u8>,
}
みたいになると思うし、最終的に生データは Vec<u8> とかそういう感じになるから命名する必要がない。
で、外側の「メタデータ含む」型自体が Sound になる
ここで SoundInfo と SoundData に分けたうえで Sound を作るようなことは私はあまりしないですね……
まあコンパイル時間の最適化みたいな理由があるとまた話は変わってくるけど
「イカゲーム」を北朝鮮に密輸入した男性、銃殺刑に処される - ライブドアニュース
https://news.livedoor.com/article/detail/21248643/
> 同サイトによると、男性はドラマのデータが保存されたUSBメモリーを中国から北朝鮮に密輸し、現地の学生へ譲渡。データを手にした学生は、同級生6名と一緒にドラマを視聴したという。密輸人からUSBを受け取った学生は終身刑、ドラマを視聴した同級生は5年間の重労働が言い渡され、彼らを指導する教師と学校長は解雇された後、鉱山や遠方に追放される。
「鉱山や遠方に追放」、およそ令和に聞けるワードではない
それってつまり単一の型で表す(.net frameworkではそうなってる事が多い気がする)か、またはハンドルはハンドルでメタデータはメタデータで完全にバラバラの型を作りハンドルとメタデータの関係性の表現には型システムを使用しないって発想じゃん？＞＜
「複雑化を防ぐためにひとつの型が持つプロパティ等の数が極端に増えすぎないようにしたい」＆「ハンドルとメタデータの関係も型で表現したい」ってなるとオレンジ方式になる気がするというかそういう考え/場面でそうしてる＞＜
「全部メモリに乗せるなら」の話であって、全部メモリに乗せないのであれば話は変わってくる
その場合ハンドルを持ったうえでメタデータのみクエリする場合もあるだろうし、それともメタデータ型を作らず個々のフィールドの getter をハンドルに用意する方が適切かもしれないし、要件次第。
結局具体的な要件のない話をしても †デザパタ論議† みたいになるので不毛っちゃ不毛
私はデザパタとかいう概念が嫌いなので。あれは言語設計の敗北。
プレーヤーを作るなら ID3 タグみたいな情報は波形データとは別でほしくなることが多いだろうから別の構造体を切るかなあ
再生していない曲のデータ、表示用のものだけ持っておくのか、プレイリスト内のファイルの全メタデータを事前に持っておくのか等でいろいろ変わってきそう
つまりらりおさんの例示で言うと
struct Sound {
channels: u8,
len: Duration,
repeat: bool,
waveform: Vec<u8>,
metadata: Audiometadata, // ←こんな感じの構造にする場面の時にDataとかInfoみたいな単語がつく命名が出てくるかも＞＜
}
channels とか len とか repeat がメタデータだと思ってたけど、曲のメタデータの話か
だったら
struct Sound {
channels: u8,
len: Duration,
repeat: bool,
waveform: Vec<u8>,
}
struct Music {
title: Option<String>,
artist: Vec<String>,
// ...
}
という感じかなぁ (Sound あるいはそのハンドルが Music に含まれるかは要件次第)
たぶんここで MusicMeta や MusicInfo という名前にはしない
内部的にファイルハンドルとかファイルパスのみを持つようなやつを MusicHandle とか MusicFile と命名しといて、
MusicFile::meta(&mut self) -> Music
MusicFile::sound(&mut self) -> Sound
みたいな感じの API にするかなぁ。
&mut なのは std::fs::File は読み込みでも変更されるから
や、音楽プレイヤーの文脈で言うならさらに Sound は再生しながらストリーミング読み込みという感じになりそうなので、波形データの部分的読み出しやデコードを担当する SoundStream みたいな型を用意することになるだろうけど。
ネットワーク経由のデータとかを扱いたい可能性を考えると -File よりは -Handle か -Uri かな
Score と PlayableItem に分けるなどの雑ｿﾘｭｯｼｮﾝがある (適当)
デザパタ自体は既に定まってしまった残念な言語仕様に対する workaround 的な面があるので仕方ないっちゃ仕方ないんだけど、「デザパタがあって素晴らしい！ デザパタを使いましょう！」みたいにさもデザパタが正の存在であるかのように喧伝する連中が鬱陶しすぎる (暴言)
オメーがやっとるのは道路の真ん中に開いた落とし穴を都度埋める作業であるということを失念しとらんか？ という。落とし穴のない道だってあるんやで。
「よっしゃ俺はスコップ持ってるから穴の開いたこの道を堂々と進んでやるぜ！」みたいなのはスコップに躍らされていると言うんじゃ
このアカウントは、notestockで公開設定になっていません。
ハンマーしか持っていなければすべてが釘のように見える | ニュース・コラム | バーンワークス株式会社
https://burnworks.com/news/article/159/
Quote #324 "True. When Your Hammer Is C++, Everything Begins To Look Like A Thumb.
http://www.anvari.org/fortune/Quotations_-_Random/3041_quote-324-true-when-your-hammer-is-c-everything-begins-to-look-like-a-thumb.html
「ハンマーがC++だったら、すべてが親指のように見える」
ただしワンタイムパスワードの共有手段と保管のコストは別で確保する必要があるとする (ﾊｲ)
真面目な話をすると、ワンタイムパスワードはワンタイムなので過去や未来のパスワードから推測できないし、解読を試みようにも「あらゆる鍵を試す」ことで「あらゆる結果が得られる」ので、そこも最強ポイント
Smalltalk - Wikipedia
https://ja.wikipedia.org/w/index.php?title=Smalltalk&oldid=86096955#%E3%83%A1%E3%83%83%E3%82%BB%E3%83%BC%E3%82%B8%E5%BC%8F
カスケード式を見て RDF (というか Turtle) みたいだなと思った
オレンジ方式は、『音楽』が『音声データ』と『曲名等のメタデータ』を持つ(『...』がそれぞれ型)だけど、
らりおさん方式だと、『メタデータも持つ音楽』が『音声データ』を持ってるみたいな構造になってるの興味深いかも＞＜
オレンジの発想だとメタデータこそフォーマットが安定しない(ある形式ではジャンル名があったり、音圧の情報が追加されてたり)って発想があるので、上位にある『音楽』型が将来仕様変更が少なくなるように、メタデータは別の型へのハンドルにするって発想かも＞＜
たぶんその辺りはアプリケーションかライブラリかで相当変わる
あと、そもそも音楽プレイヤーの文脈であれば「エントリとして選択できるものはだいたい決まっている」か「任意の key-value pairs を扱える」のどちらかの仕様であると思われるので、形式やファイルごとのメタデータの構造差はアプリケーション側のスキーマ設計で完全に吸収される
アプリを作るときどこからライブラリにするかは場合によるのでなんとも言えないけど、基本的に音楽プレイヤーは “汎用的でない” ものなので、汎用的でないアプリケーションのために過度に「早すぎる抽象化」を施した実装をしたくないという気持ちがある
というか私がライブラリ作るときはアプリケーションの性質を想定せず「ライブラリ自体がどうあるべきか」を考えて作るので、その場合はプレイヤーはライブラリが単独で使い物になるレベルに到達するまでは手をつけない
新規感染者はオフセットの乗っていない量なので「今日は昨日の-30倍暑い」とか言えなくてつまらん (?)
結構汎用的だと思うけど＞＜
一回ライブラリ作っておいて互換性も保ち続ければ次にオーディオ再生したい時にそのライブラリにファイル投げてPlayってするだけで音ならせるし、曲名とかも取得できる＞＜
たとえば非同期まわりをどうするかとか、 queue に積んであるデータについて許容できるメモリ利用とファイルシステムアクセスパターンの要件とか、外部データ (たとえば映像) との同期とか、実際使うとなるといろいろ考慮すべき点があるはずなんだけど。
どうせその辺り柔軟にやろうとすると gstreamer とかになるわけだし
あるいはメタデータだけ取得できれば十分かもしれないし、その場合 container が読めれば十分で内側の codec のライブラリへの依存があるのは嫌なので結局プレイヤーのライブラリ使わないことになりそうだし
そりゃ「既存のライブラリを前提にして、その機能や挙動を引き継ぐ前提で物を作る」という話なら CLI や GUI の代わりに API 経由で操作できてもいいよねとは思うけど。それは結局アプリケーションが API を露出しているという話であって、単独でライブラリとして望ましい形になっているかとは別の話
使う使わないというか依存関係の話で、そもそも別パッケージにして使えるというレベルの疎結合なのであればパッケージを分割して作るので
や、まあこんなんコードなしに話してもしょうがないしコードがあってもケースバイケースでしかない
オレンジとしては、公開するライブラリ作るみたいな意味でそうしてるんじゃなく、基本的に一人で作ってるから、次に同じような事をする時に楽したかったり、GUIだけ違うものをあとで作ったり出来るようにそういう風に作るので、構造が「他の人にとって使いやすいか？」じゃなくて「何年後のオレンジがこれを再利用できるか？＞＜；」みたいな事しか考えて無いかも＞＜
で、実際に10年以上前のコードから引っ張って来て使うとか普通にしてる＞＜
アプリケーションをライブラリ的に使えるようにするのと、ライブラリをライブラリとして作るのと、だいぶ考え方を変えるのでたぶんそれ
スターリンの恋心についてのｴﾖｹﾞｿﾝｸﾞを聞いている (適当)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
大学に通学するときは目黒駅の下り階段で Portal の『4000 Degrees Kelvin』を BGM として流していた
Portal walkthrough - Escape (Part 1) - YouTube
https://youtube.com/watch?v=Vby-QK4Jip0
実際の利用シーン
ポルノサイトで数学の講義動画を公開している台湾人講師にインタビュー
https://www.vice.com/ja/article/dyp8wa/math-tutor-video-lessons-pornhub-changhsu
タグスパムかぁ
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ていうか、バイパス化がそもそも遺族を中心にうったえられ続けて長年実現しなかったのがやっと的なあれかも＞＜
生年月日をパスワードにするよう指定 子育て支援サイトが話題 パスに認証以外の役割があった - ITmedia NEWS
https://www.itmedia.co.jp/news/articles/2111/25/news174.html
落ち着いて冷静に考えてほしいんだけど、あの神奈川県警を擁する神奈川県の公式サービスですよ？
品質なんて容易に想像つきますよ (?)
Tor サーバというのは要するに「出口サーバ」なんだけど、 Tor を違法用途に使いたい連中のトラフィックを自分のサーバから吐き出すってことやで。
少なくとも日本の法が適用される状態で鯖立てるのは絶対やめとけ
そりゃもちろん理想的には無数の人がこういうサーバを立ててランダムにトラフィックを交換しあえればそれが良いのだが、国家には勝てへんで
あとは P2P 使ってただけでプロバイダから脅迫じみた警告文が届いたなんて話もあったりするわけで、 Tor の出口を立てるというのはそういう無知や悪意と戦い続けるということやで。しかも自分でなく他人のために。
このアカウントは、notestockで公開設定になっていません。
プライバシーは人権です。接続元を匿名化するブラウザ｢Tor｣がサーバー不足でピンチに | ギズモード・ジャパン
https://www.gizmodo.jp/2021/11/tor-lacking-server.html
でも結局 bridge ってどこかの共有されたデータベースからランダムに抽出されるっぽい雰囲気がある
Tor の入口ノード (?) に警察の手が及ぶことはあるんじゃろか
理屈のうえでは暗号化されて中身を知ることができないトラフィックを中継しているだけなので違法性はなさそうだけど、そういう理屈は法治国家の警察に通用するものではないと愛知県や神奈川県が教えてくれたからな
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Minecraft 1.18 は 2021-12-01 リリース予定らしいけど、鯖立てるときは PaperMC を使うことになるので2週間くらいは待つことになるだろうなぁ
このアカウントは、notestockで公開設定になっていません。
パスワードが生年月日なのに CSRF 対策してるの面白すぎる、今期イチの爆笑コンテンツだ
それは今時全部手書きでもしなけりゃタダで対応できるやつだし
このアカウントは、notestockで公開設定になっていません。
CSRF 対策を CSRF と言うのやめろ、 Sans serif を Serif と言うようなもんやぞ
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
