  |
はてなキーワード: デバッグとは
女性に対等なヒトとしての自由意志を認めないミソジニストがインセルじゃん。
インセルの思想は「男は当然女をあてがわれるべき」だ。女性の自由意志を想定してない。
そして男女平等を疑いなく受け入れてるなら、男女が同じ生き物だと分かってるから、男女分断の思想にも陥らない。
だから自由恋愛のデメリットに見えるそれらは、実は自由恋愛が徹底されてない為に起こると思う。
女性を人間扱いせずモノとして消費するのがメジャーな男社会こそが問題だ。
幼少の頃から男だけで固まって女性を排除して、無許可で性的消費するのが横行する文化。
疑問を持たずにそんな環境に慣れてしまえば、理性は育たず、まともな感覚は麻痺していく。
その結果、たとえば女性同士はメイクの技術を教えあって助け合うのに、男はスキンケアさえ怠って清潔感を蔑ろにしてるわけ。
相手を対等な人として扱わず、美人とか胸とか男社会で評価されるトロフィーとしての価値で挙動不審になる。
他人の心理的安全性をゴリゴリに削ってるのに、「避けられて悲しいよ」「辛いよ」「次行け次」。
個人的な考えだけど、少子化だけが社会的な解決が必要な問題だと思う。
ごく一部の成婚して子どもを育てられる、えらい奴らに必要なカネが行き届いてない。
分析のためには、ある程度デジタルに人々を社会的な歯車として見る必要がある。
『人材』みたいな言い方って好きじゃないけどね。でも人間同士が依存しあうのが社会。
幸福を生み出す社会的装置として、よく機能してる最小単位の家庭に資源を注ぐべきだと、私は思う。
家庭から第二子、第三子と、さらに子育てできる余裕を奪って、身勝手な人たちに回してる現状を見よ。
優先順位をつけなくっちゃならない。
横だが、そういうのって「はてな」の見出しを見てるだけで目に飛び込んで来ないか？ JavaScript関係だけでもこの20年間にどれだけ変化があったことか。他にもweb系で使われている言語の盛衰やフレームワークの入れ替わりとかだけでも凄いじゃん。今や Perl それ何？ 状態だろうし、GoにSwiftにRustにCotlinにScalaにWebAssemblyにと次から次へと新しいものが出て来てるしバージョンアップでの変化もあるし。C/C++だけでもちゃんとついて行くには勉強し続けないといけないし。開発手法もアジャイルだスクラムだなんだと喧しいし、デバッグの手法関連もそうだし。今やデバッグドリブンで自動化でとかが当たり前っぽいし。
増田は、chatGPTでプログラム書いたり、論文書いたりして、無茶苦茶能率上がった情報系の研究者です。
最近、新機能のcode interpreterなるものが出て、本日使ってみました。
これまでは、プログラムをchatGPTに作ってもらっても、信用性がイマイチで、結局自分がデバッグすることが多かったのですが。
今回は、あっさり正しいプログラムが出てきやすい、なぜなら、プログラムをchatGPTが実行して、その結果をchatGPTも知ることができるから、正しさがわかりやすい。
グラフとかも、いちいち自分で実行してたのが、chatGPT上でささっとグラフが書かれると、なるほどなあと速攻で納得できる。
いやあ、こりゃすごいわ。プログラミング能力に関して、今までデバッグで煩わしいから、chatGPTまだまだだなとか思ってたけど。こりゃすごい。
これ、自分が知らないだけで、もっとすごい使い方で便利になるんだろうね。
え〜っと、PDFも読めるらしいから、自分の論文の査読とかもやってもらえるのかね。
なんなら、chatGPTくんが、リライトとかしてくれるのかな。
今までは、chatGPTの字数制限とかあって、論文全体を提示できないから、部分ごとにchatGPTに投げて文章を校閲してもらってたけど、
PDFを渡して、chatGPTが全体を読んだ上で、部分部分の文章表現を訂正してくれるわけだから、全体に統一感とかまで出ちゃうのかな。
凄すぎやろ。。。
論文書くのがこんな楽しみになるとは思わなかった。
自動車メーカーのプロパーAが異動になり、今の現場を離れることになったという。
聞いた話では、今回10名が退場した件で、自動車メーカーと元請け間で話し合いが持たれ
「Aを現場から外さないならば、うちは全員撤退する」と元請けが啖呵を切ったらしい。
怠慢な元請けがここまで動くということは、自動車メーカーか下請けと訴訟沙汰になりかけていたのではないかと予想している、
部下が全滅した後に撤退命令を出し、指揮能力を誇っている間抜けにしか見えなかった。
今まで一緒に仕事を回してきた同僚も、睡眠障害で起きれなくなり退場。
Aから戦力外通告を受けていたメンバーも、ようやく次の職場が決まった。
残ったのは私一人と、Aが残した数百件の改善指摘だけだった。
Aが私に丸投げしていた、他部署からの問い合わせ対応も無くなった。
「そちらがリリースしたコードをいじってビルドしたら動かなくなったんだけど、デバッグしてくれない？」
「君らのリリースしたソフト、容量が大きすぎてローカルにダウンロードできないんだけどどうにかならないの？」
のような、これが世界規模の自動車メーカーの開発現場か？というレベルの質問に数時間付きっきりで対応する必要があったからだ。
いずれ元請けがねじ込んでくるであろう、補充要員の世話をまた0から始めるのもウンザリだった。
上司は難色を示していたが、ここ最近の残業の件で労基に相談に行くと言ったら
「数百件の改善指摘を全部片づけるなら」という条件でOKが出た。
退場したメンバーの残した指摘は、知識が浅い状態でレビューを受け、指摘の意味も分からぬまま記載されたものが多かった。
不快なことに、それらを解読できるのはAからの理不尽な指摘を長年さばいてきた自分だけだった。
その手の資料は、作業ミスの発生時に再発防止策として追加されたものであったし
教育環境のない職場なので、レビュー用資料を作ることで内容を学んでいく側面もあった。
プロセスの削減や自動化の結果、また「手順書通りにやっただけで中身は知りません」な人材が増えるのも容易に想像できた。
すべてが不毛で不快な職場だったが、後を濁さず退場できたことは、唯一達成感を感じることができた。
余談に続く
自分の手で操作している時間よりもコントローラーを放り出してカットシーンを眺めている時間のほうが長いクソゲー。それが『FF16』である。かの制作陣は、インタラクティブなゲームプレイを通じて「物語」を描くことを諦め、その全てをカットシーンにアウトソースしている。
近年のRPGは、オープンワールドで膨大なテキスト量を誇り、サブクエストでさえ短編小説のように濃厚で、かつプレイヤーが主体的にその物語を体験できるように作られていることが多い。しかし『FF16』は、そうしたコストをかけた物語体験を諦め、最低限の規模のものを無理せず上手く作ることを目指した。プレイアブルでないのだからデバッグも要らない。破綻が少ないという意味ではよく出来た作品ではある。だが全く新しいゲームを作ろうとし（て砕け散っ）た前作『FF15』のような志の高さはそこには無い。
FFに限らず、どうも最近のスクエニは「ストーリーはカットシーンでやればいい、RPGのゲーム性はアクションにこそ宿っている」と考えているように思える。しかし、『FF16』のアクションは、たとえばスクエニの近作『Forspoken』にも遥かに及ばない。縦横無尽にフィールドを駆け巡り、ド派手な魔法を組み合わせて敵を屠る『Forspoken』に対して、『FF16』のアクションというのは、一本道を進むあいだに次々にザコ敵がやってくるベルトスクロールアクション、ボス戦は迫力のある映像に合わせてボタンをポチポチと押すだけのQTEもどきだ。
ストーリーを放棄し、アクションも拙劣であるのなら、『FF16』に残ったゲーム性とは何なのか。何もない。虚無だ。つまり『FF16』はただの「ミニゲーム付き3DCGアニメ」にすぎないのだ。
もちろんそんなことはなく、他社の書いたソースコードを読み解く必要もあれば
エラーが出ればデバッグして発生箇所を特定くらいはできる必要があるのだが
「手順書通りにポチポチするだけ」みたいな売り文句で人を集めていたのではないかと疑っている。
サブリーダーはAの罵倒の洗礼を浴び、1か月もせずに適応障害で退場。
後任探しは諦めたようで現場はAから直接指示を受けて仕事をすることとなった。
なお、サブリーダーはしばらく後に幽霊社員※として復帰してきた。他に行ける現場がなかったのだろう。
（※元請け社内の雑用係。常にチャットツールはオフラインで、対外的には居ないことになっている）
なお、集めた内容は最後まで活用されることはなく、現場の手間が増えただけだった。
「いつかこれを使ってお客さんとスケジュール交渉できたらいいねぇ（笑）」と口では言っていたが
作業内容も理解していないのに、数字だけで顧客どう交渉する気なのかは謎である。
Bは「そういうのいいから！もうお客さんから受けちゃったから！こうして君と話してる時間が無駄！とっととやって！」と逆ギレしていた。
そのメンバはたいそうショックを受けたようで、翌月には職場を去った。
「文章が長すぎて読めない」「文字だとわからないから図で描いて」「来たばかりの新人が見ても分かるように書いて」のみ。
Aから「いつになったらまともにレビューできるようになるんですか！？」と詰められていたが、結構最後まで改善はなかった。
Bとの社内レビューで10時間近くかかった案件が、顧客担当とのレビューでは10分で終わったこともある。
他所の部署のリーダーに「増田の残業がヤバそうになったら彼に注意して」と残業管理を丸投げしていた。
もっともその頃にはCとの関係は相当険悪になっていたので、残業関係のメールやチャットは無視していた。
「我々はお客様にお金をいただいて勉強させてもらっているんだからそれくらい我慢すべき」といってAを擁護する始末。
続く
ちょっと前に
っていう増田で皆が盛り上がってたよね。
これなにもおかしくないでしょ？
「出産というリスキーな行為に対して正しくリスクを感じることが出来ない生物が滅びやすかった」
これってつまりは
「アクセルしかない車は滅んだ。ブレーキがないと運転手が死ぬから」
ってだけの話でしかないんだけど？
なんでこんなことを理解するのに「うーんうーん。難しいなあ」「皆さんどう思いますか」「やはり、バグだと思いますね」って議論してるん？
アホなん？
「もしもこの機能がなかったらどうなっていたかについて、ちゃんとシミュレートしてみる」だけでいいんだけど？
なんなん？
現実に存在しないものに対してのシミュレーターは最初の１動作までしか動かせないん？
つうか１動作分の処理でも「出産を軽んじたことで母体が死亡」は想定できない？
「痛みがなかったらもっとポンポン生むじゃん！はい勝ち！論破！俺が正しい！」になるのなんで？
let a={
//宣言をする為の処理
};
のようにスコープを分けられるから、デバッグの時とかに「変数を宣言する為に使った変数」とかが残り続けることがない。
PHPだと可読性の為に変数の処理を段階的に分けようとすると、それがメソッド内に残り続けてデバッグをしようとしたときに非常に読みづらいしバグの原因になる。
・スコープを限定することができなくてデバッグの時に訳が分からんくなる。
・メソッドを分けて切り分ければよいのか？でもこれをするとパフォーマンスが低下するしな。
・型の情報がほぼ無いから知識を引き出す為の取っ掛かりがつかめない。
・Github Copilotに頼り切りになってる。それが無かった時はフレームワークの機能を丸暗記してたのか？
・RustやTypeScriptではVSCode上に表示されるドキュメントの情報を読みながらコードを書いていたので、それができないのは本当につらい。
・nullがあるのが気持ちが悪い。Optionが無いとエラーハンドリングでバグりまくりそう。
