セクショニングを h[1-6] タグを使わず本文と同じテキストスタイルで行う勢、険しい
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)님의 게시물 セクショニングを h[1-6] タグを使わず本文と同じテキストスタイルで行う勢、険しい
ブログのタグシステムを再構築しているのだが、「つらぽよ」を英訳する必要性に迫られた
ていうか、ソフトウェアのローリングリリース自体が開発者というか長年続いてるIT界隈の「セキュリティホールはあってもいい」という甘えだと思う＞＜
一億歩譲ってセキュリティアップデートの為に限ってローリングリリースなり自動アップデートさせるのは仕方ないとしても、仕様の変更まで含めてしまうのは完全に開発者の甘えだし結果的にセキュリティ上マイナスだし、その仕組みでアップデートさせる必要があるセキュリティ問題をひとつ作ってしまった毎に、土下座して謝罪すべきかも＞＜
自動車のリコール制度とか見倣うべき＞＜
IT界隈以外では、致命的な欠陥は「なおすもの」かも＞＜
致命的な欠陥があっても改修も回収返金もせずに、「後継の製品ならば」なんて言って済ませるのIT界隈くらいかも＞＜
1990年代頭まで辺りなら、特にPCも発展途上でしかたないとか言えてたけど、それからさらに何十年たって誰でも使う物になってもそのままって甘えでしかない＞＜
不具合の改修と機能の追加の完全な分離も出来ないような、きれいに分割されていない酷い設計が受け入れられたままなのも問題の根っこのひとつかも＞＜
オレンジが最近何回か話題にした、将来の互換性を考えれみたいな話も、
https://mstdn.nere9.help/users/orange_in_space/statuses/101228330322959442
欠陥を改修しても仕様変更せずに済む正しい設計をって話につながるかも＞＜（部品に欠陥があっても、最新の改修済みの部品に完全な互換性があるなら、その部品だけ変えれば済む＞＜）
ていうか「部品」とは、ある仕様（結果的な契約とも言えるかも＞＜）に基づく振る舞いを行う事が出来るひとかたまりとも言えるかも＞＜
それが破られる＝仕様、振る舞いが違うものは別物だし、その仕様（契約とか規約とも言えるかも＞＜）がころころ変わる境界は、部品としての分割面では無いとも言えるし、分割（モジュール化）されていないとも言えるし、機能毎に適切に分割されていないような設計はゴミかも＞＜
今のローリングリリースで最新版以外はまともに使えない状況ってつまり、まともにモジュール化されてないゴミみたいな設計のソフトウェアが世の中に大量にあふれたままとも言えるかも＞＜
https://mstdn.nere9.help/@orange_in_space/101263232768409527
理想的にはこれはそれなりの正しさがあるんだけど、実際どうなのかというと、たとえば web でなく Project Xanadu を待つ人がどれだけいたか、 Linux でなく GNU Hurd を待つ人がどれだけいたか、それが答え
正しい在り方のものを待つには人間の寿命は短すぎる
人間は食えるならウンコだって食う種族なのである
今のGoogleには、すでに総合的な技術力は無い...かもしれない。：村上福之の「ネットとケータイと俺様」：オルタナティブ・ブログ
http://blogs.itmedia.co.jp/fukuyuki/2012/03/google.html
> しかし、あれだけウンコOSでもWindowsは世界標準になった。いま、Androidは17年前のWindows95だ。ウンコでも我々はAndroidを知らないといけない。エンジニアはウンコを食べないといけない。
「エンジニアはウンコを食べないといけない。」、何度読んでも感銘を受けるし、名言として語り継いでいきたい日本語
ｲﾝﾄﾞｯｽﾞ、なんでも GUI でやるのが無理すぎて無理 (カーネルのことは知らん)
PowerShell のことは知らない (ｲﾝﾄﾞｯｽﾞメインで使うことがないので)
む、どうも orange 氏の投稿の取得に漏れがあるっぽい……嫌な予感が
しかし今日は遅刻するとヤバい授業があるので処置は午後
This account is not set to public on notestock.
This account is not set to public on notestock.
サーバー設備の増強とログイン状態の解除について : DLsiteインフォメーションブログ
http://home-info.dlsite.com/archives/9239261.html
This account is not set to public on notestock.
https://mstdn.maud.io/@kb10uy/101265156321592714
Inno 以外を使う奴いんの？ #文脈を大事にしたジョーク
This account is not set to public on notestock.
いわゆる社会的弱者としてのレッテルを貼られがちな “新人女性社員” が過労自殺して今どうなっているかということを考えれば、オッサンが自殺したところで無駄死になんだよなぁ
言ってみれば自殺による社会への請求もコンテンツのひとつなわけで、ｲﾝﾀｰﾈｯﾂが人々におおよそ行き渡った現在では他にもいくらでもコンテンツがあるわけよな
コンテンツとしての社会への請求を発信するなら、もっと持続的かつ中毒性のある方法で人々の生活を侵食する必要がある
님의 게시물
Tailchaser@mstdn.beer
This account is not set to public on notestock.
This account is not set to public on notestock.
おっぱい関数ジェネレーターを作ってみた【初リリース】 - Qiita
https://qiita.com/guru_taka/items/73ce07637a47183527e6
これ 3D モデルとかのプロシージャルおっぱい生成に使えるんじゃねえの
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.
@i_sparkling Mastodonは2017年春にはすでにPaperclip gem経由でS3を使うようにできてた気がします。Paperclipが対応してない形式に対応するように改造するのはたいへんそうだけど、ローカルなファイルシステムには保存できる感じなのでホスト側でfuseを挟んだりするのはそんなに難しくないのかもですねー
ConoHa のオブジェクトストレージを使っているので Openstack Swift を FUSE 経由でマウントしたいんだけど、なんかいいのが見付からなかったような記憶がある
@mohemohe 他に特にリモートストレージ持ってないので rclone 使ったことありませんでした。調べてみます
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.
void と void* は、「虚無」と「虚無が描いてある紙」くらいの差があるよ
これは差があるという話であって void * が虚無の描いてある紙に喩えられるということではないぞ
Java はメロンじゃねえし javascript もメロンパンじゃねえ
@tacumi 実際のところ、 void の void が虚無なのに void * の void が虚無ではなく「型指定がない」程度の意味しかないのが混乱の原因なので、ウーン説明が面倒だぞという感じですね
C言語での"return"は他動詞ではなく自動詞 - 何とは言わない天然水飲みたさ
https://blog.cardina1.red/2016/07/08/return-statement-of-c/
昔書いたやつ
@tacumi 「○○へのポインタである」という一貫性のある構文を捨てるか、「○○」の部分の正確性を捨てるか……いい感じの言葉が思い浮かびませんよね
void の void は虚無なんだけど、 void * の void は虚無ではなく「型がない」という意味 (一貫性のNASA)
This account is not set to public on notestock.
通常の型のポインタは暗黙にサイズ情報を含んでいるので、本当はアドレスというよりアドレス範囲を表現していると捉えるのが自然なんだけど、 void * は本当にサイズ情報を持っていないのでアドレスそのものを表現している
This account is not set to public on notestock.
This account is not set to public on notestock.
https://mastodon.cardina1.red/@lo48576/101265914227281503
これなのよな、初学者に calling convention の存在を把握しろというのもまあ無理な話で
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.
あと C の void の一貫性の NASA といえば、 void が unit 相当なのか bottom 相当なのかも微妙な感じよな (個人的には unit であろうという印象を持っている)
その解釈に従うならば、「void 型を返す関数」が実際に返しているのは「ただ一つの (実質何の意味もない) 値」であって、これがバイナリレベルではナンセンスなので省略される、みたいな理解をするのが (直観的には) 自然かもしれない
(void)unused_arg;
とか、何やってんだお前という感じはある
三項演算子に void の式を突っ込めるのとか、なかなか愉快な仕様になっている (お前それ絶対 unit じゃなくて bottom のつもりで型付け規則用意したやろみたいな感じ)
n1570 の §6.5.15/3 あたりを見るといいです
This account is not set to public on notestock.
というのも、たとえば
foo.set_bar(bar()).set_baz(baz());
みたいな式を書いたとき、 bar() と baz() の評価順序って定められてない気がするんですが、どうでしたっけ
評価順序が定められていないと何がマズいかというと、例外が発生するタイミング云々とか副作用云々とかその辺りです
@prime Rust に傾倒してから C++ 追い掛けてないので…… (調べてみます)
This account is not set to public on notestock.
あと意味的な面では、戻り値は何らかの(通常不可知な)値を知るために使われてほしさがあるので、常に *this が返されるなら最初から呼び出し側が知っている参照を使えよみたいな気持ちになります
(Foo * が返されると、 *this 以外が返ってくる可能性を想定してしまう)
c++ - Weird evaluation order in chained functions - Stack Overflow
https://stackoverflow.com/questions/48476469/weird-evaluation-order-in-chained-functions
ふーむ？
Order of evaluation - cppreference.com
https://en.cppreference.com/w/cpp/language/eval_order
님의 게시물
prime@mstdn.poyo.me
This account is not set to public on notestock.
function と proceduce を使い分けるとき、 function が副作用を含まないという意味なのか何らかの値を返却するという意味なのかは人によって異なる
hoge.fuga();
hoge.piyo();
で、fuga();が本来void fuga();でPascalでprocedureとするものであるのであれば、それはhogeに「何らかの操作をする」であって、hogeを加工した複製（例えば集合であるhogeの部分集合を返す）みたいな意味は持たないよね？＞＜
そういう意味を持つのであればそれはprocedureになるはずは無く必ずfunctionになるんだから＞＜
返す値が暗黙に複製であるとするのは仮定が強すぎません？ (よくわかってない顔)
いや私も副作用を起こすことを主目的にしている関数の戻り値としてレシーバそのものを返そうとは思いませんが、それはさておいて。
jQuery のメソッドチェーンが便利だというのは、まあわかるので (あれややこしいんだけど)
あーでも Builder から &mut Self を返すことはあるな。あれも一応気持ちとしては値の複製を返したいけど再利用性が云々とかコピーコストがみたいな妥協の結果ではあるんだろうけど
This account is not set to public on notestock.
Scheme とかも unspecified value を返すし
Pascal一族も別にfunctionで副作用を起こさないなんて意味は持ってないかも＞＜ そうじゃなく、procedureって必ず・・・副作用？＞＜； なんていうの？＞＜；参照透過性の崩壊？＞＜；
なんかそんな感じの関数型の言語が避けまくるような物を踏んづけてる場所だよって言う意味を結果的に持ってない？＞＜；（そうじゃない場所では踏んで無いということではなく＞＜；）
それは実用上そうなるというだけであって、言ってみれば慣用的にそうなるけど副作用が保証されているというわけではないのではという気持ち
This account is not set to public on notestock.
その何らかの慣習を強制したいのであれば、それは規約 (“デザパタ” とか) によってではなく型システムや静的検査によって強制されるべき
This account is not set to public on notestock.
少なくともC# で、何らかの関数を実行した結果は、何らかの新たな物（結果なりリソースなり）か何らかの部分集合等であって、その名前の手続きを実行して変化した（＝非破壊では無いという意味では破壊された）結果と解釈する事って少なくともオレンジは無いかも＞＜；
関数型とかあんまり好きじゃないけど、「破壊されたその物が返ってくる」ってその逆方向に突っ走りまくりな発想では？＞＜；
変更された結果返ってくる値が元の値のその後であるのか複製であるのか、これは単に (GC 付きの言語であれば) 元の値の参照が生存しているか否かの違い、所有権のその後の話であって、本質的に異なるものだと言えるのだろうか？
少なくとも私の知る限りで、 GC 付き言語が関数のシグネチャで表明する情報に、所有権の行方は含まれていない気がするけど……
例えばfugaってprocedureとint piyo(int x);ってfunctionを持つhogeがあったとする＞＜
int a=hoge.piyo(x);
hoge.fuga();
int b=hoge.piyo(x);
ってした時に、よりaとbという結果が異なる可能性が高くなるよね？＞＜；
より参照透過性（？）が危険にさらされる（？）場面である可能性が高くなると看做せる（？）というか・・・＞＜（状態を持つのであれば保障は出来ないのは当然として＞＜）
それは慣習に過ぎないのではという感想です (もっと言えば、状態を持つ/持たないは自明ではない (特にキャッシュとかがあると))
なんでそうなるかと言うと、（計算機の）状態が「必ず変化しない」procedureなんて、中の処理が実際には空っぽとかじゃなければありえないだろうし＞＜
これにはまあ同意するけど、「計算機の状態の全てが、あるオブジェクトから観測可能なわけではない」という観点もあり、つまりたとえばデバッグプリントは確かに副作用を発生させるけど、これが本当にコード上で何らかの観測可能な影響を及ぼすのか
本来「副作用」という巨視的すぎる視点ではなく、コードの有無が開発者の意図した結果 (特に値) を変更するか、というもっと制限された視野で考えるべき事柄のような気はする
典型的には C++ における const 性なんかはそういう「オブジェクトについて、観測可能な変更が行われるか」みたいな制限された視野を提供している
This account is not set to public on notestock.
戻り値のある function が参照透過性を破壊しないというお約束は、あまり当然ではない気がする
典型的には C++ の std::vector::pop_back() が pop された値を返してほしいという声は無限に聞きますよね (例外安全性か何かの理由でそうなっていないけど)
「参照透過性を破壊するコードを、そうでないコードと分離しろ」という意見ならまあわかるんですが、それはそれを表明できない言語のデザインが弱いのではという感じです
あいまいな表現になるけど＞＜；
オレンジ的には、その関数が示しているものをなるべく返して欲しいみたいな感覚があるかも＞＜
例えば変な例示かもしれないけどTryIncrement()って関数があってboolが返ってくるのであれば、（不可能な場合がある状態で）インクリメントしてみて出来たかどうかを返すのかも？＞＜（論理の正負はわからん）って解釈するかも＞＜
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.
で、intにint int.TryIncrement()みたいなのがあったらとんでもなく混乱するかも＞＜
int x=3;
int y=x.TryIncrement();
ってしたあとにxはどうなってるのかわけわからんってなるかも＞＜（xが文字通りインクリメントされて破壊されて4になった？＞＜ それともyに4が入るだけでxは3？＞＜ ていうかそもそもTryIncrement()が返すのは結果なのか、それとも何らかの勝手な定義による成否の表現？＞＜（例えば0なら成功とか））
https://mstdn.nere9.help/@orange_in_space/101266292721323876
これは型で表明されれば何の混乱も起きない話で、たとえば
fn TryIncrement(&mut self) -> Result<&mut Self, IncrementError>
なのか
fn TryIncrement(&self) -> Result<Self, IncrementError>
なのか、型を見れば mutability なんて自明なので
This account is not set to public on notestock.
「成功したか失敗したか」は bool ではなく「成功したか失敗したか」型で返ってほしい
try の結果を表明するなら Result 型を使えばいいので特に設計のうえで悩む点はないですね
enum 、もっと言えば代数的データ型はもっと積極的に使われてほしいんですよね
C++ でも Java でも碌に使えないので学校でちゃんと習わないんですけど
Scheme とかの Lisp 系であればそれっぽいことはやるか
クソ設計を前提として別の部分のまともさを評価しようとするのはナンセンスでは……
This account is not set to public on notestock.
enum 、整数にしたければ From / Into で型変換を明示的にかけるのが正しいのでは
メンバ関数の返り値を暗黙でthis参照とするの、「すべての返り値は使われるべきである」というような手続き型言語もあるのでなんともなあ
This account is not set to public on notestock.
そうですね、例えば強制的に全メソッドがnodiscardで
discard returnsSometing()
returnsNothing()
みたいになるのがNim
hoge(target, x, y) とも target.hoge(x, y) とも書けるみたいな(C#の拡張メソッドと言われればそうだが)
意地悪な例示でTryってくっつけたけど、Tryってつけてなかったらどうなる？＞＜ってなるかも＞＜
手続きのような言葉で関数のように何かが返ってくる時にその何かは推測が難しいかも＞＜
何が返ってくるかをその関数が表していなければ、何が返ってくるのかわからないって当たり前（自己言及的で循環する）な問題があるかも＞＜
hoge.fuga()のfugaと言う4文字ににhogeそのものが返ってくるって情報はどこにあるんだろう？＞＜
fugaというものが返ってくるのでは？って考えるかも＞＜
それこそ型を見ればいいじゃん (型を見てわからない言語使いたくない) という感想しかないですね……
や、人間にとって親切になるように設計しましょうというお気持ちは理解できるんですが、結局人間は信用できないので、強制されていないことは信じられないし、表明は強制されてほしい
その文脈上で、hoge.fuga()でfugaがhogeの型と同一の型で何かを返すのであれば、それはhogeは破壊されていないとオレンジは考えるかも＞＜ hogeにfugaと言う状態の変化を与えた物ではなくfugaと言う式を通した結果かもって＞＜
逆にfugaがprocedureであれば、hogeをfugaと言う手続きで何らかの変化をさせる以外の推定のしようが無いかも＞＜
hoge が破壊されるかは、レシーバが self なのか &self なのか &mut self なのかで判断されるべきで、戻り値型で判断されるべきではない
戻り値は本来レシーバについて何も述べていないはずだし、そこに暗黙のルールを持ち込もうとするのは、言語設計の弱さを規約で補おうとしているだけ
https://mstdn.nere9.help/@orange_in_space/101266366644177728
これ、
impl Hoge {
fn hoge1(self) -> Self;
fn hoge2(&self) -> &Self;
fn hoge3(&mut self) -> &mut Self;
fn hoge4(&mut self) -> Self;
// などなど
}
のどれのつもりで言ってるのかわからないんですが (これらが区別できない言語はまず弱い)
C++ で言うなら、
struct Hoge {
const Hoge &hoge1() const;
Hoge &hoge2() const;
Hoge hoge3() const;
const Hoge &hoge4();
Hoge &hoge5();
Hoge hoge6();
};
くらいの使い分けはできるわけで、たとえば hoge4,5,6 が自身を変更するであろうというのは明らかだし、 hoge1,2 が自身か自身の所有するオブジェクトの参照を返すだろうというのも明らかですよね、そして hoge3 は自身のコピーか別オブジェクトを返す (いずれにせよ所有権は別になりそう) というのもわかる
よーするにちゃんと型で mutability とかが書けてほしいというだけなんですが
https://mstdn.nere9.help/@orange_in_space/101266406119623083
だから、 hoge.fuga().piyo(); を実現するための手法は本来いくつもあるし、参照透過性を破壊するもしないも型で(それなりに)表明できるので、言うほどヤバい落とし穴はこういった言語上でそもそも自然には書けないのではということです
これら複数の選択肢の区別がつくなら、値を返すのと参照透過性を破壊するのは別々に表明(かつ制限)される事柄なので、自身を返す返さないの別は、暗黙に(意図せず)参照透過性が破壊されるリスクを含まない、という話です
This account is not set to public on notestock.
コピペの繰り返されるコード、なんか汎用の圧縮 (gzip とか？) をかけて圧縮率を見ると同じソース内での類似コード片の多さが見積もれそう (適当)
This account is not set to public on notestock.
@nao 画像アップロード時の画質の項目、「鯖側でいい感じに抑制してくれるので」は https://github.com/tootsuite/mastodon/issues/7218 でブラウザ側リサイズされるようになったのと同時期になくなりました。今はクライアント側でリサイズしないとリサイズされません。
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.
「ニンジャスレイヤー」世界観で繰り広げられる全方位STG『AREA 4643』、忍殺語が理解されずSteam審査ストップか
https://automaton-media.com/articles/newsjp/20181219-81896/
＞もちろん心当たりはある。とどのつまり、これは『ニンジャスレイヤー』の「おかしな翻訳みたいな文体」が、そのまま「おかしな翻訳」だと判断されてしまった故の悲劇だと思われる。
＞そういった「忍殺語」が、Steam側に「フルサポートされていない日本語」だと捉えられてしまったのだろう。
流石 #ニンジャスレイヤー ですね。
＞最悪の場合は日本語が対応インターフェース言語の欄から消えるかもしれないが、日本語で遊ぶことはできると述べられている。
いっそそうなった方が面白いかも？
#Steam 
