@risa それ Scheme の構文だと思ってたんですが CL でも使えるんですか
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)님의 게시물 @risa それ Scheme の構文だと思ってたんですが CL でも使えるんですか
Run a Replicated Stateful Application | Kubernetes
https://kubernetes.io/docs/tasks/run-application/run-replicated-stateful-application/
なるほどなぁ、小さいプレーンテキストであれば config map と init containers でやれるのか
This account is not set to public on notestock.
『NieR:Automata』のUIデザイン | NieR:Automata 開発ブログ
https://www.platinumgames.co.jp/dev-nier-automata/article/183
これを思い出した
操作可能な選択肢が多いとじっくり考える系のゲームになりそう。将棋とかはまさにそれだけど。
マノヴィッチが「ニューメディアの言語」で現実を排除したヴァーチャルな画面について強調してしまっているけど、ゲームについてはそういう(現実と無関係な意味での)仮想的な空間という言いかたはあっている。
けど、エンゲルバートの構想にとって重要だったのは潜水艦のレーダーとかで、これは外界と認知主体を繋ぐためのインターフェースだったわけで、業務アプリやらなにやらのほとんどは、現実を知覚するためのさまざまなビューを必要としている。
UIデザインの諸問題、けっきょく情報の開示と操作の提示の組み合わせに尽きるという気がする。操作によって可視的な情報に変化がおき、情報をもとに操作を決定する。
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.
「操作可能な選択肢が多い」に対しての解決のひとつがコンテキストメニュー (俗に言う「右クリックメニュー」) で、名前の通り操作の文脈によって有効なアイテムのみを列挙できる機能なんだけど、これもまあまあ濫用されてしまっている気がする
コンテキストというよりは、メソッド呼出のレシーバ (self とか this) に対しての操作が全部列挙されてしまっているような。
まあユーザからしてみるとそっちの方が使いやすいのかもわからん
This account is not set to public on notestock.
*nix のシェルというのはそもそも「操作を知っていれば O(1) で入力できるし、操作や操作対象を知らなければ列挙で補完される」なので、 UX そのものとしてはかなり古い
This account is not set to public on notestock.
結局 GUI に固執しすぎただけなんじゃない？ という素朴な感想はあるが。コマンドラインアレルギーというか。
GUI は主に WYSIWYG とポインティングデバイスが強いのであって、それ以外の要素でこれといって CLI を取り止めるべき理由を持っているわけではないので……
メニューの選択をポインティングデバイスでやる必要はない。選択できれば何でも良いのだから。
AquaSKK プロジェクト::新機能の紹介
https://aquaskk.osdn.jp/imk_topic.html
操作が多様だから言葉を利用していく(コマンドを利用する)のってUI上の良い解決ではないので、そもそもの操作可能な選択肢を減らしていく必要がやっぱりある。
あと選択肢の多さとは直接関係ないけど、一昔前のブラウザでマウスジェスチャが流行っていた時期があって、あれは「選択肢に tier を付ける」という感じよね。 CPU の L1 キャッシュと L2 キャッシュ、メモリ、HDD、みたいな。
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.
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.
This account is not set to public on notestock.
日本語 IME を使っておきながら「vi にはモードがあるから使いづらい」みたいなこと言ってる光景はちょっと笑ってしまう (関係ない話)
モードってそもそも隠れた内部状態があって、その内部状態によっておなじ操作UIで操作の意味が違うってやつだから、だいたい誤操作のもと
This account is not set to public on notestock.
自分はモードがだいたいよくないと思っているのに vim 好きなのなんでだろうとおもってたけど、「情報を読みとる」ことと「操作する」ことをいつもフェーズ分けてるからだな。vimperator が現役だったときGスプレッドシートにモードをわざわざ導入したおぼえがあるけど、これも情報の読み取りと操作を分けたかったからだ。
This account is not set to public on notestock.
~~モードフル/レス~~ ステートフル/レス というのが割と雑で、隠れ状態というのがユーザに起因している場合と UI モデルに起因している場合がある？
あるいは「ユーザの状態変化をアプリに適用するとき、操作が羃等でさえあれば連打で済む」みたいな話
全角/半角によるトグルは「全角を入力したい」に対応する操作が羃等でないことが多いから使いづらい、とか。
私の場合 Windows では「変換」で平仮名モード、「無変換」で無変換半角英数モードになるようにしてあるので、今の状態とかは全然気にしていない
https://mastodon.cardina1.red/@lo48576/110951561253209227
モードじゃねえや、ステートフル/ステートレス
モードもステートの一種だからこの文脈では大差ないか
何が言いたいかというと、「今の状態がわかるようにする」という方向性だと画面がごちゃごちゃするわけで、「意図した状態に簡単に行ける」の方向を目指すのも解決としてはアリだろということ
……しかしその結果が MS Office のリボン UI だと思うと、やっぱりうまいやりかたではないのかも
理屈のうえではまあまあよくできてるんだよな、何が駄目なんだろ
リボンの中のボタン群とかの配置かね。目標操作からすぐに場所を割り出せないので、「眺めて位置を探す」操作が必要になる
その点では旧来のメニューも同じなのだが。
リボン系の UI はアイコンがデカくてテキストが下なので上下左右両方に空間をとるうえ、それがさらに並んでいるので情報の流れが複雑。2+1次元になっている。
対照的に旧来のメニューはアイコンは文字と同程度のサイズで、アイテムは一貫して横向きに記述されて縦向きに列挙されているので1+1次元で済んでいる
画面というものに問題がある
自動車とかは、情報を表示する盤面と操作インターフェースが完全に分離されている
This account is not set to public on notestock.
飛行機の操作体系は画面に押しこむことができるが、それをやるとかなり多くの問題を発生させることになる。操作機器類は露出させておくほうが絶対にいい。
しかしあれは習熟訓練が前提であるということが許容されているからああなっているわけで、ある意味ユーザを選んでいる
単一画面(情報の表示と操作UIの同居)こそがモードの発生源になっていて、画面こそがソフトウェアデザインの躓きの石になっている
そもそも特定機械専用の物理的な操作機器はそれ自体が単一のモードしか持てない、という方が表現として正確そう
複数のアプリケーションを扱えるという意味でモードが複数持てるのは、汎用コンピュータの本質的な強みな気がする
単一なモードしかもたないようにデザインしろってたぶんノーマンが言ってた(飛行機の操作を画面におしこむ話もたしかノーマンが書いてたはず)
アプリが単一のモードであってもユーザがそれを切り替えれば全体としては複数のモードを持つわけで、それが許されるなら「単一のアプリが表面上は複数のアプリであるかのように振る舞う」という体裁のもとで複数のモードを持つことも許されてしまうのではないか？
結局のところ「ユーザで主導でモードの切り替えが発生するか」というあたりが使い勝手において重要な要素なのか
まさにそうで、「内部状態を抱えた機械」というものの登場はそう古いことではないが、過剰に内部状態を抱えている機械こそが汎用コンピュータ
情報がモード間で共有されるかどうか、というのも重要な気がしてきた
各モードの状態というのはユーザの脳にキャッシュされているが、あるモードにおける操作が別のモードにおける状態を (隠れているか否かに関係なく) 変更してしまうと、そのキャッシュを invalidate して再構築するぶんのオーバーヘッドが発生してしまう。これは体感的な使い辛さに直結する
vi がモードをもっているの云々というのもあるけど、そもそも vi の前にあったラインエディタとかテキストの全体がわからないままテキスト編集していたわけで、vi はまさにテキストの状態を可視化するツールとして現れたはずだとおもう
vi は操作こそモードがあるが、状態のストアはほぼ単一で、バッファ内のテキストとコマンドとして入力中の数文字くらいしかない。だから複数のモードがあっても困らない
ラインエディタは確かに現代で人間に使わせようとは思えないな……
ed は廃れたのに parted や gpg は現役 (?)
This account is not set to public on notestock.
対称性という点では、電車のワンハンドルマスコンとかも結構危険だと思う
> 東急8000系を開発する際に、ワンハンドルマスコンの操作法について、“押して制動・引いて力行”と、馬を御するやり方に基づいたそれと逆とする案の両方が出され、最終的には前者に決まった[14]。前者については、人間の体が慣性に逆らわずに運動する、また、万一失神時には前に倒れ込むであろう、といった点が“人間工学に基づいたシステム”としての観点から言われている。導入に際しては当時の運輸省から「どちらでも良いが、どちらかに決めたらその方式は以後変えてはならない」という指導があり[14]、
でしょうね……
すずしい (エアコン設定29℃、デスク周辺気温31.8℃)
飛行機の操作を画面におしこむ話、『人を賢くする道具』の第6章「分散された認知」に書いてあった。飛行機の操縦席になんでデカい操作機器が必要なのかというと、複数人で操縦していて、自分の操作を他人に見せる必要があるからという話。操作は内部的にはすでに電子的な操作であって昔みたいに物理的なものではないから、操作機器は小型化できるけど(それこそゲームコントローラーみたいなものが作られたらしい)、小型の操作機器を導入したらパイロット同士が互いに状態がわからなくなってしまった、という話だった。画面の話ではなかった。
This account is not set to public on notestock.
今回みたいに、タイムラインに適当な議論をなげる人がいて野火みたいに議題がわーって広がるの好きなんだけど、協働的に思考するみたいなスタイルで、「飛行機の操作機器がデカいのは大事」みたいな話とつながっているなとおもった
こういうのでちゃんと関連の投稿を RT してもらえるとフォロー外で広がっているところまで捉えられるのでめちゃくちゃ助かっている
雑談とかはどうしても文脈 RT が少なくなりがちなところがあって、そうなるとフォロー外の観測範囲が狭くなり、結果としてリコメンドや FTL 等によるディスカバリーに頼らざるを得ず、分散が滞る……
This account is not set to public on notestock.
#AC6 気になってるんだけど、 PS5 でやるか PC (RTX 3090) でやるか悩んでいる
DualSense の各種機能 (ハプティックフィードバックとかアダプティブトリガー) が Steam で使えるかどうかなのよな
【アーマードコア6雑談】デュアルセンスからエッジに乗り換えるか悩むな。
https://gamemos.net/2023/08/26/post-64693/
> ちょっと触ってあこれオフにしてたアダプティブトリガーつけると面白いやつだと思ってたら対応してなくてダメだった
Steam 版だと非対応っぽい？
This account is not set to public on notestock.
a = a_q × n + a_r (ただし 0 ≦ a_r ＜ n)
b = b_q × n + b_r (ただし 0 ≦ b_r ＜ n)
() として商と剰余に分解して考えれば、
a mod n = a_r
b mod n = b_r
なので、
(a mod n) × (b mod n) mod n = a_r × b_r mod n
で、
a × b mod n
= (a_q × n + a_r) × (b_q × n + b_r)
= (a_q × b_q × n) × n + ((a_q × b_r) + (a_r × b_q)) × n + a_r × b_r mod n
= a_r × b_r mod n
となり等しいことがわかる
単純な領域なら
a = a_q × n + a_r (ただし 0 ≦ a_r ＜ n)
b = b_q × n + b_r (ただし 0 ≦ b_r ＜ n)
これでだいたい (最後の mod n を剥がせないものの) いけるところまでいけることが多い
This account is not set to public on notestock.
累乗については、 t≧2 (b ∈ ℕ) の場合を考えれば、これも分配法則で
a^t mod n
= (a_q × n + a_r)^t mod n
= (a_q × n + a_r) × (a_q × n + a_r)^(t-1)
= (a_q × n) × (a_q × n + a_r)^(t-1)
+ a_r × (a_q × n + a_r)^(t-1)
mod n
= a_r × (a_q × n + a_r)^(t-1) mod n
も言えて、あとは t=1 のとき
a^t mod n
= a mod n
= (a_q × n + a_r) mod n
= a_r
なので、数学的帰納法でキマりですね
一番外側の mod n を剥がさない限りにおいては、基本的に n の倍数として括り出せた項が全部あっさり消えていくので、割と素朴ではあるし納得もしやすい部類
This account is not set to public on notestock.
This account is not set to public on notestock.
あー、これそのまま展開すると
a_r × (a_r × (a_r × … mod n) mod n) mod n
みたいになるから、ちゃんと数学的帰納法するならもう一手間必要だわ。まあぼんやりと直観的には言えそうだよねということで ()
s × (t mod n) mod n = s × t mod n
みたいなのを示して (これは簡単) うだうだやればできそう？
最初に二項定理で
a^t = a_r^n + n × (Σhoge)
の形に展開してやれば一発っぽかった、ﾊｲ……
こういうときにめちゃくちゃ衰えを感じる。もう何をやっても駄目だ……
님의 게시물
prime@mstdn.poyo.me
This account is not set to public on notestock.
整数論は難しいと界隈の人が言ってた (界隈外からすると五億歩十億歩なんだけど)
DH 鍵交換、絵の具と色とかで喩えたことはある
なんかおすすめに出てきたけど、この「訂正版作成予定」って絶対に変なオタクにマサカリ投げられまくったパターンやろ
これね、観てないけどリコメンドに出てきてウケてた
まあ変なオタクが変だからといって鉞投げられた方が間違ってないとは限らないし、そこはね……
「PSYCHO-PASS」など主題歌担当のEGOISTが活動終了「ギルティクラウン」発のユニット - コミックナタリー
https://amp.natalie.mu/comic/news/538415
This account is not set to public on notestock.
This account is not set to public on notestock.
Standord Univ. 学長の前にも、Stanford の Prof. やりつつ MIPS を教育・研究からスピンアウトして事業家・創業したり全般的にこの分野の研究者や技術者があんまり得意そうでない biz ネタもきっちりずっこなしてきてる人という雑感
This account is not set to public on notestock.
まず「文字」って何ですか？ コードポイントじゃないとして、コードユニット？それとも grapheme cluster？
go の rune は結局のところ code point だけど、それって rust の char と等価だし、 str::chars() はそもそも配列化なんて無駄なことしない (Rust やるような人たちは無駄なアロケーションを嫌うので)
str - Rust
https://doc.rust-lang.org/stable/std/primitive.str.html#method.char_indices
for (i, c) in your_str.char_indices() {
// こういうことでしょ
}
go で code point という既存概念に対して rune とかいう独自の名前を与えたことで、go があたかも「文字」なる概念をうまく扱えていると勘違いされるなら、それは誰にとっても不幸なことだよ
だからといって char という名前が良いというわけではないが。
grapheme cluster 単位の分割を標準ライブラリの範疇でできる言語自分は PHP ぐらいしか知らないけど Ruby とかもできそうな気がする
そもそも Ruby は Unicode 以外の文字集合も扱えるとかで、よく抽象化できたものだなぁと (実は逆に大して抽象化していないゆえにインターフェースを提供できている説も考えられる) (しらんが)
言うて下手に「文字」を定義しようとせず「特定の文字符号による文字列」それぞれに型を割り当てていけば、割とどうとでもなるというのはある (たとえば Rust でも UTF-8 とは限らない OS ネイティブな文字列型 OsStr などがあり)
その辺りは本来はサードパーティの文字コード型ライブラリとか特定文字符号用ライブラリとかが管轄すべきことだとは思う
Rust の str / String も、言ってみれば UTF-8 文字列ライブラリ (のコア機能のみ) なわけで。
ランタイムで Unicode 関係の諸々のテーブルを持つの、オーバーヘッドは如何程なんだろうという素朴な気持ちがある (その程度のオーバーヘッドなんか屁でもないような環境なら持っといてもいいだろうけど)
$ ruby -e 'p "👨👩👧👦".grapheme_clusters'
["👨👩👧👦"]
$ ruby -e 'p "👨👩👧👦".chars'
["👨", "", "👩", "", "👧", "", "👦"]
This account is not set to public on notestock.
UTF-32 の話してます？ まあ結局32でも足りなかったんだけど
RFC 8369: Internationalizing IPv6 Using 128-Bit Unicode
https://www.rfc-editor.org/rfc/rfc8369
やはり UTF-128！ UTF-128 は全てを解決する！！
UTF-8「どうせ大半は ASCII なんだから都度バイト足していけば短くなるでしょ」
→可変長に
UTF-16「どうせ前半しか使わないし2バイトにしとけばええやろ、足りなかったら2つ繋げるってことで！」 (Java, 従来の Windows)
→サロゲートペアで苦しむことに。しかも結局可変長
UTF-32「コードポイントそのまま持てばええやん」
→コードポイントは21ビット範囲しかないのに32ビットで表現するのでだいぶ無駄。しかも結局 grapheme cluster は可変長
UTF-24: ？？？
UTF-128: ？？？？？？？？？
UTF-24 はみんな一度は想像するのに存在しないし、 UTF-9 は I-D で破棄されたのに UTF-128 は Informational で出てるし、 UTF ファミリーは総じて馬鹿 (?)
いわゆる map が Hash と呼ばれていて実装がハッシュ関数によるものではない処理系はさすがに存在しないか
出力が1ビットのハッシュ関数 (暗号学的とは言ってない)
カステラなんだけど冬の金玉みたいだなと思った。冬の金玉たべます
This account is not set to public on notestock.
ansible のタスク書くのミスって SSH で締め出し食らったが、 Proxmox VE 上の LXC コンテナだったので noVNC 経由でどうにかして一命をとりとめた
Unixのフィルタプログラムのような用途では標準入出力を流れるバイト列のエンコーディングを気にしなくても良い場合も多いと思うけど、Rustで文字列処理をしようとするとUTF-8としてのバリデーションが必要になりがちでアレみたいなところはありそう。`bstr`クレートみたいなものもあるけど、例えば`core::fmt`周りのコンパイラマジックをの恩恵を受けるにはやはり`str`が必要だし
では標準の文字列型を`BStr`相当のものにしておけば良かったのかというと、それはそれで例えばJSONの書き出しのような本当にUTF-8が必要な処理で文字列リテラルを書き込むだけでバリデーションが発生するなどのつらみがありそうなので、はい。何なら必要なバリデーションを忘れるコードが氾濫するまでありそうだし
OS との界面まわりでもうひとつ面倒な話というと、 config file 系のもの (たとえば toml) とかを普通は str や String へ読んでから解釈すると思うんだけど、そうなると non-UTF-8 なパスを設定項目として記述できないなどがある (独自でエスケープ記法を用意する手もなくはないが……)
Proxmox VE のバージョンを取得するのに pveversion コマンドを叩くの嫌なので (なんか遅いし) /etc にそれっぽいのないかなぁと探しているが、微妙
実態が perl スクリプトだった、重いのはそれか
git.proxmox.com Git - pve-manager.git/blob - PVE/pvecfg.pm.in
https://git.proxmox.com/?p=pve-manager.git;a=blob;f=PVE/pvecfg.pm.in;h=6307ed9b0a48d32e2118f5803438da1e235a3a10;hb=HEAD
/usr/share/perl5/PVE/pvecfg.pm に直書きしてあった……マジかよ……
님의 게시물
Mzrapid@mstdn.poyo.me
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.
今月に入ってからレジストラのGANDIから .af ドメインが不安定だから安心のためによそへ移管してほしいってメール来てたし雲行きが怪しい
あれまぁ。しかし ccTLD だからそういうこともあるよね……
CVE-2020-19909 is everything that is wrong with CVEs | daniel.haxx.se
https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-everything-that-is-wrong-with-cves/
うわぁ……そんなことあるんだ
