はてなキーワード: エラーとは
近頃、ChatGPTを規制するだのしないだの、AIイラストの著作権がどうだの、ド底辺の俺でも生成AIについて耳にする機会が増えた。
生成AIの性能はおそらく世の中のパンピーが想像している倍以上は高いと思う。
描いた絵を見た人に「この人骨折してるの?」だの「中学生でもマシな絵描くわwww」だの言われる程度の画力を持つ俺は「AIを使えば好みの絵量産し放題じゃね?」なんて浅はかな考えを抱くようになった。
まずは環境導入からハードルがたけえ。先人のブログ記事のコードを写経しながら、よくわかんねえコマンドラインを弄っても見たこともないエラーが出て土日を丸二日無駄にしたわ。
ローカル環境でやらなくてもNovelAI使えばいいじゃん、って意見もあるかもしれないが、いくらAIが高性能つっても、その性能を発揮するには適切な命令を「英語で」書かなきゃならない。
「マチカネタ〇ホイザがラバーのピチピチボディースーツを着てエロ蹲踞のポーズをしている」なんて正確に英語で表現できるか?俺には無理だね。努力を放棄して結果だけを求める浅はかな人間の俺に、そんな教養なんかあるわけがない。だからポイントなんてあっという間に使い切ってしまうね。
いざ環境導入に成功して、AIイラストを生成できるようになったとしよう。だとしても「ちやほやされよう」なんて無理だ。AIイラストのクオリティなんて似たり寄ったりだし差別化できねえ。クオリティだってどうやって上げるんだ?ぶっちゃけ神Seed引けるのを祈ることぐらいしかやることないわ。モチベが上がる気がしない。
何よりAIイラスト自体も肩身が狭いんだよ。権利関係が曖昧で、クリエイターからも蛇蝎のごとく嫌われている今、そもそもAIイラストで「ちやほや」されること自体が無理筋だ。
色々縁が合って学部名に情報が入る大学3―4年生の面倒を見てるんだけど,驚くほど英語が出来ない
一応授業である程度習ったらしいけどコーディング能力は低い.具体的にはFizzBuzz問題解けないくらい
しかしそれ以上に問題があるのは英語と基本的な知識で,例えば次の2つのエラー文がどちらからも何が問題なのかわからない
NameError: name 'Fizz' is not defined
IndentationError: unexpected indent
defineもIndentも単語として知らない以前に,変数と文字列リテラルやインデントを理解できてないからエラーコードでググっても解決できないんだよね
同じ理由でDeepL等で訳しても無理.ただ,ChatGPTとかに説明してもらうとわかるらしい
5人中2人がこのレベルなんだけど,本人の希望通りの業界に就職したら0から叩きこまれるんだろうなって思って子牛を見ている気分になったよ
これは本当。
Ka-52が狙っているのはとんでもなく遠いので見えない。
ただ弾を装填するのが手作業。
露ヘリコプター「Ka-52」は西側の兵器より効果的=独メディア
ロシアの偵察攻撃ヘリコプター「Ka-52」は、ウクライナ軍にとって大きな脅威となっている。ドイツ誌シュピーゲルの記者は、「アリゲーター」という愛称を持つ「Ka-52」について、西側の兵器では対処できないとの見方を示している。
シュピーゲルの記者は、「Ka-52」はウクライナの攻撃を撃退する上で非常に効果を発揮していると指摘した。
またシュピーゲルは、「Ka-52」に搭載されている6つの対戦車ミサイルシステム「ヴィーフリ」の重要性についても報じている。「ヴィーフリ」は誘導ミサイル「9K121」を備えており、最大で10キロ離れた標的を攻撃することができる。
また、西側から供与された「ゲパルト」を含むウクライナの防空システムの射程はわずか5キロしかないため、ロシアのヘリコプターは安全な距離から攻撃することが可能。「スティンガー」や「イグラ」といった携帯式防空ミサイルシステムの射程も足りない。さらに、ウクライナの航空機はロシアの戦闘機に対して脆弱であるため、Ka-52に対抗することができない。
ーーー
これより先、軍事、防衛ニュースの19FortyFiveも「Ka-52」を評価した。19FortyFiveは「ロシアのパイロットは相手を捕獲する技の策定しており、アリゲーターは今でも戦場で恐れられる 『本物の捕食者 』」と評し、特にKa-52が地形を利用して、極めて低い位置から目標に忍び寄り、敵の防空網から見えないようにする能力に注目した。
「ビデオ画像処理システム"オホートニク"は、物体の探知・認識距離の1.2~1.5倍の増加、テレビチャンネルの夜間の活動時間の増加を提供します。
自動追尾機能の存在は、観測画像の部位のビデオ視認範囲の結合の安定化を、テレビ方位測定システムは関連する照準ラインの目標の誤差へデジタルコードのエラーを出す事を可能にします」
ナセンコフは話した。
『無線電子技術コンツェルン』は、Ka-52Kの為の一連のシステム全体を製造する。
それは具体的に、高性能の機上防御複合体「ヴィテブスク」、回転安定光学電子ステーションGOES-451、電波位置特定複合体「アルバリェート」、兵器制御レーザービーム誘導システム、自動制御システムSAU-800の設置である。
「SAU-800は、手動、自動、自動制御モードでのヘリコプターの操縦を提供します。
SAU-800は、大気データ処理・記録複合体SIVPV-52と統合されており、パイロットは兵器の使用に集中することが出来ます」
ナセンコフは話した。
ICOCA周りのWeb系にしても他のいろんなところでITシステムがひどい
会計とか資産管理のITシステムがDBを直接編集するようなUIになってた
資産登録しようとしたらカラムを全部手打ちで埋めないとダメ、みたいな感じ
おまけにDBの制約条件をチェックしてくれない上にバッチ処理なので
実際に投入してみて次の日に「エラーで登録できませんでした」って返ってくるとか
ユーザーに提供してるようなシステムでも使いにくいの多いよね スシローとかまさにそれ
たまに良く出来てる奴があるんだけど大体が東日本、というか東京側の会社のプロダクト
西日本側の開発でもコンサルが入ってるものはそれなりにちゃんとしてるんだけど
自社開発とか子会社開発のプロダクトは、「学生の卒業研究か?」っていうぐらいヒドイ
スマホのアプリで出来が悪いアプリあったら会社調べて見ると大体が西日本だよ(というか大阪近辺)
JRとかNTTとかITシステムに苦手な会社の西日本側の支社になると輪をかけて酷くなる
もともとモバイルSUICAのアプリもヒドイ出来だったよね(最近はそうでもないが)
このページの上にあるテキストボックスだけどさ、何を入力しても以下のエラーが返ってくるんだけど、検索機能ってまともに動作してるの?
504 ERROR
The request could not be satisfied.
CloudFront attempted to establish a connection with the origin, but either the attempt failed or the origin closed the connection. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
Optionとかの影響で例外を投げないことに拘る人がたまによくいるけど、どうせ最上位で捕まえるんだから詳細な情報を詰めた上で例外はむしろ投げろし。— neuecc (@neuecc) June 27, 2023
これなーアジャイルとか大好きWeb系から流れてきたなんちゃってUnity開発者(個人の感想です)ほど例外になるんだけどどうにかしろって騒ぐ
いや例外出るよってxmldocでも書いてるじゃん、みたいな
この手のやつほどチームリーダーとかやりたがるから仕方なく自分の実装レイヤーでエラーコードに変換してやるってことがしばしば
C++でかつコンソールゲーム系の人は例外😬みたいな感じになるけど例外復帰でループから抜けたりするみたいな使い方でなければまあわかってくれる
ごめんね。内部ストレージもいっぱいですってエラーがでるのでなんとかしてほしいといわれて、ストレージにある動画とか画像とか逃がしてるうちに
強制プリインストールされているキャリアアプリ系の謎のエラーメッセージに気づく。これはアレをすれば解決するか(・・?そうおもった。削除したいアプリ一覧とかいうのを 参考にして、ドコモ電話帳
DOCOMO Initialization
docomo Application Manager
dアカウント設定
dメニュー
my daiz
などを削除したら、泣かれた。電話もできなくなったっていわれた。ごめんなさい。なぜだろう(・・?けっこう騒がれてつらみしかない。今朝はあそこに立寄ってから出社したいから、お小言にずっと耐え忍ぶのか?
もちろんそんなことはなく、他社の書いたソースコードを読み解く必要もあれば
エラーが出ればデバッグして発生箇所を特定くらいはできる必要があるのだが
「手順書通りにポチポチするだけ」みたいな売り文句で人を集めていたのではないかと疑っている。
サブリーダーはAの罵倒の洗礼を浴び、1か月もせずに適応障害で退場。
後任探しは諦めたようで現場はAから直接指示を受けて仕事をすることとなった。
なお、サブリーダーはしばらく後に幽霊社員※として復帰してきた。他に行ける現場がなかったのだろう。
(※元請け社内の雑用係。常にチャットツールはオフラインで、対外的には居ないことになっている)
なお、集めた内容は最後まで活用されることはなく、現場の手間が増えただけだった。
「いつかこれを使ってお客さんとスケジュール交渉できたらいいねぇ(笑)」と口では言っていたが
作業内容も理解していないのに、数字だけで顧客どう交渉する気なのかは謎である。
Bは「そういうのいいから!もうお客さんから受けちゃったから!こうして君と話してる時間が無駄!とっととやって!」と逆ギレしていた。
そのメンバはたいそうショックを受けたようで、翌月には職場を去った。
「文章が長すぎて読めない」「文字だとわからないから図で描いて」「来たばかりの新人が見ても分かるように書いて」のみ。
Aから「いつになったらまともにレビューできるようになるんですか!?」と詰められていたが、結構最後まで改善はなかった。
Bとの社内レビューで10時間近くかかった案件が、顧客担当とのレビューでは10分で終わったこともある。
他所の部署のリーダーに「増田の残業がヤバそうになったら彼に注意して」と残業管理を丸投げしていた。
もっともその頃にはCとの関係は相当険悪になっていたので、残業関係のメールやチャットは無視していた。
「我々はお客様にお金をいただいて勉強させてもらっているんだからそれくらい我慢すべき」といってAを擁護する始末。
続く
だめじゃあ。
今またブルスク。KERNEL DATA INPAGE ERROR だけど、結局のところSSDがビジーで応答を無くしたために
ページファイルが読めなくて・・というわけなんだろうなこれ。
しかしSSDがビジーになる原因が特定できない。ここ最近、ずっとタスクマネージャーを画面の片隅に置いてにらめっこしているが
フリーズの間際に最後にチラ見できた限りでは System が少しディスクを使っていたが、これが重大な負荷をかけているとは思えない。
もう分からない。。。
そういえば、だいたいブルスクが出る時間と Bing Wallpaper が壁紙を交換する時間が一致してる気がする。
以前は夕方に壁紙が交換されてた気がするが、最近は確かにこのあたりの時間だ。
ずっと前から Bing Wallpaper が壁紙を交換するタイミングで、マウスが少しカクついてたりするのは気になってた。
壁紙の交換は、弱った SSD に対しては負荷の高い作業なんだろうか?
熱のせいで不正終了を繰り返した結果、ファイルシステムが傷んじゃって、壁紙交換程度でも無用な負荷がかかっちゃうのか。
どんなアプリでも、このよわよわ SSD をがっつり使おうとすると妙な負荷がかかる可能性はあるんだろうかね。
Dell Data Vault も、まあユーザーの利益の見えづらいよく分からんアプリとは言え、ブルスク犯として糾弾するのはちょっと安直だったかな。
もうちょっとだけ知見を貯めた後で SSD を換装するんじゃ。
追記:やっぱり、ちょっとPCを放置してると Antimalware Service Executable がSSDをまさぐるんだけど
少しの間、マウスが応答しなかった。SSD が通常の負荷に対して弱くなってるんだろうなあ。
転んでもタダでは起きたくないというか、SSDを交換する前に、何かこう完璧で究極の知見を得てから
「よし、次のSSDで運用する時にはこれに気を付ければいいな!」みたいな何かが欲しいんだが。
難しい。
そんな絶賛ハードウェアトラブル中にもかかわらず、メモリを16G追加しちゃったwアホかーw
追記3:
ちなみに Bing Wallpaper は完全にシロ。壁紙を更新する時間はログイン直後だが、BSoD になるのはその1時間以上後。
さてさて、ここ連日 UNEXPECTED STORE EXCEPTION か CRITICAL PROCESS DIED の BSoD が「毎日・朝に・1回だけ」発生。
今朝はようやく、SSDに大きな負荷がかかった直後、まだタスクマネージャーが応答する状態で、諸々と観察する事ができた。
しかしタスクマネージャーを確認した限りでは、何らかのプロセスがSSDに負荷をかけているようには見えなかった。
タスクスケジューラーのログをとってみたところ、BSoDの直前に動いていたタスクは Windows Error Rporting/QueueReporting とのこと。
タスク名からして、エラー情報をキューイングしてるのかな。まさかこの後、実際に送信する時にSSDに負荷がかかってる?
とはいえもちろん、普通のSSDであれば難なくこなす作業であり、弱っている(と思われる)特別な状態にあるSSDにだけ荷が重いんだろう。
たとえ何が起きているのかを正確に突き止めたとしても、価値ある情報にはならない気がしてきた。
追記4:
やっぱり、Windows Error Reporting Service を止めたら、ここ最近毎日朝に発生していた BSoD が今日は発生しなかった。
通常の状態であれば、Windows Error Reporting なんて大した負荷じゃない。
でもその作業中に、弱ったSSDのどこかのツボを突いちゃってるんだろうかな。これ以上の深入りは不要だろうか。
しかしそういえばちょっと昔、おそらく Windows Error Reporting が 30G 以上のファイルを送信したらしく
それまでは長期出張のためにポケットWi-Fiをレンタルしており、容量は実用上は十分だったが
それでも万一を考え「従量制課金接続」の設定をオンにし、通信容量を節約していた。
そのおかげかは分からないが、Windows Error Reporting も情報を送信していなかったらしい。
そして家に帰り有線接続となった途端、Windows Error Reporting が大量の情報を送信したらしい。
溜まりに溜まったエラー情報は、やっぱり何かしらの負荷になるはずだ。
Windows の品質向上に協力するのは別にやぶさかではないんだが、どんだけのエラー情報が溜まっているのか
それをコントロールする事は出来るんだろうか?
「ディスクのクリーンアップ」で出来るらしい。といっても3Mしか溜まっておらず、クリーンアップは短時間で終了。
追記5:
Windows Error Reporting Service は動かしていないが、それでも今日もSSDに妙な負荷がかかったようで1分ほどフリーズ。BSoD には至らなかった。
タスクスケジューラーのログも有効にしてあるが、少なくともその5分前までに走ったタスクは無い。
結局「SSDが弱っているから、何が起きても不思議じゃない」という幕引きになるのか?
追記6:
随分前にDiagnostic Policy Serviceのファイル操作で異様に長い時間がかかる事を突き止めていた。もちろん、根本原因はこの傷んだSSDのせい。
なので、このサービスもずっと停めてある。
おそらくこのおかげで、30秒くらいフリーズの後にBSoDが出る事は無くなった。
しかし今日(7/10)もやはり UNEXPECTED STORE STATE の BSoD が発生。今は(午前中である事は変わりないが)ほぼ予兆無く突然発生する印象だ。