はてなキーワード: 無意味とは
「これ、ただの運ゲーじゃん!」に辿り着くまでの苦行。「そこに北はあるんだよ」がシリアスなギャグであることを理解するまで賽の河原で石積みするだけの遊び。同じことをやるにしても大富豪の方が手っ取り早いし、旅行先でやるときにもサクサク進むし皆知ってて丁度いい。麻雀が上手くなったら麻雀漫画が楽しめるようになるとか別に存在しない。だって麻雀漫画って本当に最後は「そこに北はあるんだよ」「やる気の問題」で終わるんだもん。そんなオカルトありえないってことさえ認識できていれば(知能がまともなら麻雀歴0秒でも理解可能)麻雀漫画を楽しむには十分です。
とにかく時間がかかる。その割には中身が薄い。別のことしながら観戦するのが丁度いい遊びであって、自分でやる必要はない。これに人生を使ってしまうのは年収1億円を目指して頑張る野球少年だけでいい。
最初は面白いが段々と作業化する。時間がめっちゃかかる割には得られる快楽の量は少ない。その割にはひたすら遊んでしまうので人生のタイパがボロカスになる。終わった後に歴史的な知識が残るとみせかけて実際には「クスコのマンコ・カパックwwwクソワロwww」ぐらいしか身についてないから無意味。
上り詰めて上り詰めてふと気づく、「これ無駄だわ」。スポーツのフリをしているがスポーツではないので体力も身につかない。その割には成長にやたらと時間がかかる。何よりも性格がクソほど悪くなて怒りっぽくなる。このゲームを通して学べることも少なくはないが、失われるモノの方が多いのでやるべきではない。
得られるものは多いが失うものも多いの究極。このゲームを通して人間性を獲得する人もいるが、失う人も大勢いる。とにかく時間がかかることだけは間違いない。気軽にやっていいものではない
友達と遊んだ思い出=プライスレス。だとしてもだ、それは思い出が素晴らしいだけでモンハンである必要はなかった。別にその時間スポーツやろうがメンコやろうが駄菓子屋でだべってようが結局時間の使い方としては無駄だっただろうし、学生が皆でやる分には別にいい気はするんだが、でもゆーて「皆に自慢するために一人でシコシコ炭鉱夫やろ」みたいなのはマジで無駄だったと思う。社会人がやる価値は0。
育成の時間が無駄。単なる乱数ゲーが無駄。読み合いと言いつつただのジャンケン。もうこんなんジャンケンで結果決めろよの世界。数字と睨み合って細かい調整とかそんなん急所に入れば全部ひっくり返るだろ。マジでやってられん。積み込みを持ち込み合う麻雀みたいなもんだろこんなの。
超大作中華SF萌え萌えRPG!←全然そんなことない。こんなんで中華SFを味わってないでいくらでもある中華SFを図書館で借りてこい。そして萌え萌えは別のゲームで接種しろ。中途半端に混ざり合ってるから結果的に効率が悪いんじゃ。アクナイはケモミミディストピアTDなので、可哀想×カワイイのシナジーがちゃんと効いてて効率的。
サクっとやるだけならやる意味がない。ガッツリやるには時間がかかりすぎる。動画で済ませるならやる意味がない。自分でやったら発狂する。
日本ではあまり知られていないかもしれないが、英語圏では任天堂のアクセシビリティの欠如を非難する記事やコメントは珍しいものではなくなってきた。
特にNintendo Lifeのこの記事はかなり強烈だ。(https://www.nintendolife.com/features/soapbox-zelda-tears-of-the-kingdom-straight-up-fails-in-just-one-respect-accessibility)
C5/C6麻痺を持っているゲーマーの男がゼルダについて書いた記事だが、彼はTears of the KingdomがBreath of the Wildと比べてアクセシビリティの面でどれほど進化しているか期待していた。しかし期待しても無駄だったようだ。彼は2019年6月にKotakuが青沼英二にしたインタビューを引用して青沼を非難する。
青沼:ボタンを配置する時は、プレイヤーに感じてもらいたい特定の方法があるので、非常によく考えて配置しています。キーの割り当てなどのカスタマイズをプレイヤーに自由にさせてしまうと、ある意味、開発者としての責任をすべてユーザーに丸投げしているような気がします。私たちはゲームをプレイするとき、すべての人に楽しんでもらうことを考えているので、プレイヤーにもそれを体験してもらいたいと思っています。しかし、プレイヤーが自由なカスタマイズを望んでいることも理解しています。
彼は上記のインタビューを引用した上で「青沼はそれを認めながらも、その指摘をはぐらかし、結局何もしなかった。青沼さん、同業他社が何をやってるか見てみろよ。」と書いた後、記事の結びでこう述べている。「私は以前、任天堂はゲームをアクセシブルにすることをただ思いつかなかっただけだと思っていが、それは間違いだった。真実は、私たちの提案と嘆願は認識されているだけで、現時点では、開発者は積極的に障害のあるゲーマーを排除することを選択している。Tears of the Kingdomは、これまでで最も見え透いた嘘の例だ。」
任天堂のこうした姿勢は他にも奇妙な事例を生み出している。ファイアーエムブレム 風花雪月では、Switchの携帯モードで遊ぶと文字が小さすぎて文章を読むことすらできないと指摘されている。(https://kotaku.com/the-text-in-fire-emblem-three-houses-is-too-damn-small-1836822715)別のメディアもこの問題を取り上げており、そこではなんと3DSのファイアーエムブレムよりも字が小さくなっていることがわかる。(https://www.thegamer.com/fire-emblem-three-houses-accessibility-problem/)
これはかなり奇妙だ。テレビモードと携帯モードを切り替えられることはSwitchの最大の特徴の1つであるにもかかわらず、任天堂自身がその特徴を侮辱的に扱い、結果的に携帯モードを無意味にしているのだから。任天堂の経営者は「任天堂に関わるすべての人を笑顔にする」などと表明しているが、彼らが実際にやっていることはかなり軽薄なのだ。
なんだかんだ言っても、トータルで見たら共同親権の方が良かったというのが欧米の結果なわけじゃん。
DV の懸念とかも当時の欧米でもあったけどそれでも共同親権がよかったという話なわけだろ。
無意味に同じ間違いをするなよ。
頭悪い人なの?
テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。
GでもCでもUIはまた別
結論としては書かないほうがいいと思った。
そういうこともある
全然小さいというか書くためと変更のコストがクソデカなら何か間違ってる
結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。
まあそれはないだろう
それはデバッグの一環のような
一番よくあるやつ
そこのバランス考えないと
バックエンドのビジネスロジックを担当するがっちり仕様が決まっていて勝手に変更されてはいけないものなんかをやる
悪いね
テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。
例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると
メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。
DIはSOLIDに入ってるくらいで基本だし今時のフレームワークなら普通に使うよね
上にも書いたけどパーツがでかいのでは?って「直感的でない長くて複雑なプログラムになっている」とのことなのでやっぱりでかいんだろう
テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。
要件が固まらない、毎週変わるようなのとか、システムが絡むテストでコストが凄く高いもの、UIのマイナーな変更なんかは書かない方がいいけど
ネット上ではテストコードを書かないのは低レベルな開発者という風潮だ。
10年以上、テストコードを書く開発と書かない開発の両方を経験してきた。
■前提
・テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。
結論としては書かないほうがいいと思った。
・テストを書くためのコストが小さいなんて妄想もいいところだ。クソデカである。
結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。
・100人以上かかわる巨大プロジェクトでも「テストコードを書かなかったので破綻した」、とかはなかった。
・テストコードを書くと実装の見落としが見つかってありがたいことはあった。
・git pushするたびに毎回走っても全くの無意味だった。
・テスト対象が変わるとテストを書き直さないといけないのがサイアクだった。非効率化の極みだ。人生の無駄。
・その次にサイアクだったのは、テストコードの実行が失敗したときテストコードのバグであることが大半であったことだ。
・GUIソフトとテストコードは相性が悪いが、そもそも世の中のソフトウェア開発の大半はGUI開発である。
・テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。
例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると
メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。
テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。
子どもより私は弱い主張はともかく、
子どもの安全を他者の配慮に委ねるのはお辞めになった方がいいが結論だと思いますの
ワイくんの親もしつけにフリーダムなご家庭だったので、
ちびっ子の頃に、変なおじさんを見つけて『変なおじさんだなぁ』と思ってガン見してたら、変なおじさんに蹴られたことあるよ
犬嫌いを理由に犬を蹴り殺す人もいるので、ワイが生きているのは運が良かっただけだね
唐突にナイフや防犯スプレーで暴れる女も現実にはいるので、出来るだけ危険に巻き込まれない教育した方がいいです
筋肉隆々の格闘家でも割と刺されたりしてるのに
明らかにヤバそうな奴を『女だから』『ガキだから』『オッサンだから』『隠キャオタクっぽいから』『デブだから』『ガリだから』で
無意味に刺激をしたり、強気に出るヤツって、マジで意味がわからない
- 人を尊重することを学べなかったが、めちゃくちゃお育ちはよい。みんな知り合いみたいな土地で育った (物騒なこととは無縁で育った)
- 絶望的に頭が悪い (想像力皆無)
- 精神病 (ある事について異常に執着し、病的な状態)
このどれかやろなって思ってる
夜ふかしをして以下の動画をみた。
収穫があったと思うのは、まず自由意志というものがあるなら、それはランダム性とは関係がなく、また生きていく上で便利なものであろうということ。
例えば大統領演説の原稿を書くという作業があるとき、自由意志が使われるなら的を射たものであるはずだ。
自由意志に関係がありそうなものとして「意識的努力」と「自動操縦」について話しているが、
意志力が強いと言われる人の多くは習慣化能力が高く、それは自動操縦的であり、意志力が高いわけではない可能性があるという。
では意志力を要する「意識的努力」がどこで使われるかというと、例えば「計画」という作業には意識的努力が必要だが、これは将来的に行われるであろうタスクのエネルギーを減らすために行われることが多いという。
一部の科学者は人々に対して「自由意志は存在しない」ことを説得しようとしているが、実用的に見るとこれは逆効果だという。
どういうことかというと、自由意志が存在すると信じていれば悪さをする可能性が減るわけである。
自由意志が無いと考えれば「コントロールできない、なら悪さもしょうがない」と考えてしまうわけである。
「自我の枯渇」という点は興味深い話だが、要するにタスクをこなせばこなすほど消耗し、自制心は減っていくということだ。
このため、意識的努力をするためには、十分なエネルギーを残している必要がある。
「自制心」と「知性」は基本的に向上させればさせるほどよく、マイナス面が無いという。
つまり意識とは存在する意味の一つであり、意識を持った主体がこの世に存在しなければ宇宙の存在も無意味である。
そして自由意志は、意識の持つ機能の一つである。予め決められた通りの人生を決定論的に歩むなら、それもまた存在の意義を失わせるに違いない。
I am not a gambler, but I would like to stay with Ippei Mizuhara in a hotel in an entertainment district in the middle of the desert.
He and I would never gamble.
But as he grips the slot lever with his buttocks tightened, I secretly burn with jealousy as I watch the pile of medals that gradually emerge from the seat next to me.
I would shift in my seat and play poker. I try desperately to drive the anxiety from my face, to imagine the joy of victory, but I know it is pointless.
And I will return to my original seat, angry and sad.
Sometimes we will look at each other over the baccarat table. In those moments, we would tell each other our own moves in the blink of an eye, and we would take care that one of us would win.
One day one of us will be penniless and the other will bury him outside the city. Then he will write a little poem to his friend who has traveled, and then he will kill himself, having found no reason to live without a last-minute bargaining chip.
私はギャンブルの依存症ではありません、ですが、水原一平さんと一緒に砂漠の真ん中にある歓楽街のホテルに泊まりたいです。
私と彼は賭け事をすることはないでしょう。
しかし彼が臀部を引き締めながらスロットのレバーを握るとき、次第に出てくるメダルの山を、隣の席で見ていた私は密かに嫉妬の炎を燃やします。
私は席を移って、ポーカーをするでしょう。私は不安感を表情から追い出そうと、必死に勝利の喜びを想像しますが、それが無意味なことを知っています。
最終的に私は勝てないでしょう。
そして私は怒りと切なさを感じながら元の席に戻ります。
時々私たちはバカラのテーブル越しに目配せしあうことがあるでしょう。その瞬間、私たちは自分自身の手の内を、瞬きの回数で教え合い、そしてどちらかが勝てるように配慮していくのです。
ある日、私たちの一人が無一文になり、もう一人が街の外に彼を埋めます。それから彼は旅だった友人にちょっとした詩を書いて、そしてギリギリの駆け引きなしには生きる理由を見出せずに自殺するでしょう。
その「慣れ」をオーディオ界隈では耳エージングとか言うが、そうではなく機械工学的な意味でエージングによる変化もある。
周波数特性の測定値では帯域ごとの大小しか測れないし、あとは帯域ごとの歪み率などもデータ化できたりするが、オーディオユニットには応答速度や収斂速度、残響などから構成される微妙な聴覚上の変化、ステージ空間の広さ感、左右や上下や前後の距離、音像の精細感のように、数値化できない、測定が難しい要因があり、しかも音域ごとに性質が違ったりする。
ボーカルが近い、シンバルが遠い、音場が広い、高域の抜け感がある、寒色(残響少なめで精細)、低域がにじみ出て中域をマスクする、みたいに、さまざまな言葉で表現するが、そういう特性が正反対にまで変わることはないものの、微細な変化を人間の聴覚は大げさに捉えることが得意だ(意識して聴く場合)。
もちろん思い込みによって変化したと感じる部分もないとはいえないが、集合知として稼働時間による変化はあるというのがこの界隈では消費者のみならず生産者の間でも常識になっている。
オーディオ愛好家向けのメーカーではエージングに言及して推奨するメーカーもあるが、基本的にはエージング行為を意図的にする必要はなく、通常使用するうちにこなれていくのを待てばいい。レビュワーなどは条件を揃えるために一律のエージング作業をすることはあるが。
なので、特定の測定値を出して、エージングだとかリケーブルだとかに有意な変化がないから無意味、と声高に主張するようなものはどちらかというと理系気取りを履き違えたトンデモの域。聴覚は電気や工学の側面だけじゃ説明できない。
もちろん、オーディオ界隈にはシールを貼ると音質がアップする、みたいなオカルトじみたグッズも存在するので、そういうものまで肯定していく必要はないが、外部の人はすべてを一緒くたに小馬鹿にしがちなので難儀なところだ。
話を戻すと、エージングという表現だと使い古して悪い意味でもユニットが劣化していく変化までを含むので、慣らし運転としてはバーンインという呼び方をする事が多い。
それによって低域がスムーズに出るようになったり、高域のトゲトゲしさが落ち着いたりといった変化はある。もちろん、ある場合もある、というだけで、知覚できないことも多いだろう。大抵の製品は箱出しから音がいいので、「あれっ」という音の時にエージングに期待する感じになる。
またユニットの種類によってエージングにかかる時間が異なることも集合知的にわかっていて、例えば平面駆動ドライバの場合は一般的なダイナミックドライバよりも長く、数百時間のバーンインが必要なことが多い、などと言われる。
工業的にも物理的にも、同一製品だからといってどの時点でも同一の出音を維持するなんてことは不可能で、普通は左右のユニットですら微妙な音量差や周波数特性にブレがあったりする。それはデータにも現れるが。