  |
はてなキーワード: エラーとは
今でこそWindowsでも全く問題なく開発できるけど、ちょっと前は「Macのが開発体験が良い」と言われていた。
具体的には2011~2015年あたり。
2013年のころ、俺はWindowsで開発していた。WSL2なんてものは当たり前に存在しない時代だ。
たとえばC言語を使いたい場合、MinGWとMSYSを使ってこんなかんじで必要なものにチェックマークをしてインストールしていた。
まちがえた。俺が使っていたのはCygwinだ。こんなかんじでインストールする。
「パスを通す」とか言われていた時代だ。今ではインストーラがほとんどやってくれる。
Windowsのコマンドプロンプトがアホほど役に立たないので、msysCygwinのコンソールを使うのだ。
Pythonのインストールにもパスを通していた時代だった。当時はまだ2系が主流で、卒論を書く際、大学の教授から「3系は使ってもいいけど、俺は知らないからサポートできない」と言われた。
Scipyはインストールしなければ使えなかったので、「python scipy インストール」で検索して出てきた記事を参考にしてインストールしていた。これがまたエラーの連続だった。
プログラムを開発するエディタも、vim、emacsがまず候補に上がった。どちらも癖のあるエディタなので、そういうのが嫌な人はサクラエディタが推奨されていた。そして少しして登場するAtomに感動したのだ。今ではあたりまえのようにVSCodeがある。
ちなみに俺はPythonの開発ではIDLEというのを使っていた。知ってる？こんなの。
そんなWindowsユーザーを少し煽るような（Winユーザが自虐するような）、「プログラミングするならMac」という風潮があったと記憶している。そこから「どうやらMacはUnix系で、コンソール操作が簡単らしい」「文字がきれい」「Windowsでは定期実行するためのcronすらないが、Macにはある」「xcodeというのがあるからめちゃくちゃプログラミングがラクらしい」みたいなイメージがあった。
今ではWindowsも随分便利になったし、IDEやインストーラがなんでもしてくれるようになった。今では結論、「どっちでも好きなほうを使えばいい」という良い環境になった。
（Ｆａｃｅｂｏｏｋに投稿したものを転記しました。よかったら読んでください）
羽田空港での日本航空機と海上保安庁機の衝突事故ですが、事故の調査と捜査が始まりました。
それで、今わかっていることをまとめておこうと思います。
長文になりますが、本論に入る前に４つ説明したいことがあります。
前説明①
目的② 事故の責任を明らかにし、違法行為があれば刑事事件として立件する
①の調査は国土交通省の運輸安全委員会が担当し、②の捜査は警察（今回は警視庁）が担当します。
みなさんはどちらの調査・捜査の方が重要とお考えになりますか？
私は①と考えていますので、この投稿は再発防止の観点中心に記述しています。私は誰が悪かったのかという責任論にはほとんど関心がありませんし、（故意でない限り）関係者全員刑事免責でいいと思っています。今回の事故では、日本航空も海上保安庁も被害者に対する民事的責任のみ果たせばいいと考えています。
前説明②
滑走路での衝突事故は、世界的にみると頻繁とまではいいませんが時々起こっています。原因はヒューマンエラーが中心です。
航空事故にはならなくても、事故になる危険が高かった事態をインシデントと言いますが、日本で起こった重大インシデントのうち、かなりの割合が滑走路への誤進入（未然も含む）です。
日本での重大インシデントは国土交通省が全件公表していますが、２０２３年は１４件中３件、２０２２年は１４件中６件がそうでした。特に私たちが乗る可能性が高い旅客機（小型飛行機やヘリを除いた飛行機）だと２０２２、２３年とも２件の重大インシデントが発生しそのうち１件が該当インシデントでした。
事故にはならなくても滑走路への誤進入（未然も含む）という事態は繰り返し起こり続けています。ヒューマンエラーはなくせないということです。
前説明③
羽田空港に限らず飛行機の航路や使われる滑走路などは厳密に定められており公開されています。
今回の事故は北風運用時のＣ滑走路上で１７：４７ごろ発生しました。
北風運用の場合、Ａ滑走路を（主に南／西からの便の）着陸、Ｄ滑走路を（主に南／西行の便の）離陸、Ｃ滑走路を（主に北方面と長距離便の）離発着に使います。
Ｃ滑走路は離発着両方で使われますし、Ｃ滑走路への着陸経路は、Ｄ滑走路の離陸経路と交差しています。
羽田空港の場合、北米方面への便が離発着する１５～１９時が離発着ラッシュとなります。
事故は、羽田空港の一番忙しい時間帯に、運用が複雑な滑走路上で、日没して既に真っ暗になった時に起こりました。
前説明④
飛行場管制には、離陸や着陸、滑走路横断などの許可を出す飛行場管制（タワーコントロール）と、飛行機や車両が地上走行する許可を出す地上管制（グランドコントロール）の２つがあります。
本論で、（タワー）とか（グランド）とか書いていますが、それはどちらの管制が指示したのか明示したかったのでそのように記述しています。
前置きが長くなりましたが、今までわかっていることを９つ列挙します。
列挙にあたっては、（ ）内に次の略号をつけていますが、列挙した事柄をどこから収集したかを示しています。
（１）
ILS Z RWY34R Approachという経路を通っているように思います。着陸まで特に目立つ異変はありません。（Ｆ）
（２）
羽田の管制と海保機、ＪＡＬ機へのやり取りがこの事故原因解明の重要ポイントであることは間違いなさそうです。
各種報道もありますが、鵜呑みにせず、やり取りについて自力で追ってみます。（ネＡ）
この情報は、特に次の２つの投稿を参考にしています。なお時刻については、１～２秒のずれはあります。
https://www.youtube.com/watch?v=LP1xWcyKBDs
この投稿を基準にして他の投稿等と突き合わせして確認しました。
https://www.youtube.com/watch?v=D8FHnIRwe_M
グランドとの交信があります。わかりやすいのですが一部私の解釈と違う部分もあります。
17:42:29 JA722A, Tokyo Ground Hold short charlie.
17:43:11 Japan Air 516, Continue approach 34R.
（タワーからＪＡＬ機へ：３４Ｒ滑走路へ進入を継続してください）
17:44:13 JA722A, Continue charlie.
17:44:53 JA722A, Contact Tower 124.35.
（グランドから海保機へ：周波数124.35でタワーへコンタクトしてください）
17:45:00 Cleard to land 34R Japan Air 516.
（ＪＡＬ機からタワーへ：３４Ｒ滑走路は着陸に支障ありません）
この直前にタワーからＪＡＬ機へ着陸許可が出ているはずですが、LiveATCには残っていないようです。
17:45:13 JA722A, Tokyo Tower Good Evening number 1 taxi to holding point charlie 5.
（タワーから海保機へ：JA722A、東京タワーです。こんばんは。ナンバー１（離陸順１位）です。Ｃ５地点へ移動し停止してください）
この後のタワーと海保機、ＪＡＬ機の交信は私が探した範囲では残っていませんでした。
（３）
交信記録については、国土交通省が日本語訳したものを公表したという報道があります。（報）
それによると、17:45:13の交信の後、「滑走路停止位置 C5に向かいます。1番目。ありがとう。」と海保機から返答があったということなのですが、ライブやアーカイブでこの交信を聞いたという人は、私が探した限りいません。私が聞いたアーカイブにもありません。
国土交通省はせっかくＡＴＣを公開したのだから、日本語訳だけでなく原文を公開してほしいと思います。
この部分は、海保機がどのような認識をもっていたか理解するうえでとても重要だと思います。
（４）
この後、タワーから海保機に対して、滑走路進入許可(Line up)が行われた交信は見つかりませんでした。（報ネＡ）
タワーは滑走路進入許可も更にその先の離陸許可(Cleared for takeoff)も行っていないと報道されていますが、信憑性は高いと思います。
一方、海保機側は、滑走路進入許可を得たと認識しているという報道がありました。（報）
事実、滑走路に進入し、そこで待機していたため衝突事故は起こったわけですから、タワーと海保機側で認識の相違があったのはほぼ確からしいと思います。
この部分は推測ですが、ナンバー１（離陸順１位）という表現を誤解したのではないかという指摘があります。（報ネ）
一方、2010年までは「taxi into position and hold (from charlie 5)」という指示が使われていました。この意味は「（Ｃ５地点から）滑走路に入り待機せよ」となりますが、これと「taxi to holding point charlie 5」を混同したのではないかと推測する意見もありました。（ネ）
いずれにせよ、なぜタワーと海保機との間に認識相違ができたのかという点はもっと調査が進まないとわからないと思われます。
（５）
海保機は、Ｃ滑走路に進入しそこで４０秒ほど待機していました。（報ネ）
その間、離陸許可を待っていたと考えられますが、離陸許可を得ようとする交信があったかどうかは明らかになっていません。
また、ＪＡＬ機にはパイロット３名体制だったと報じられていますが、３名とも滑走路に進入した海保機を視認できていませんでした。
既に夜になっている状況で、多数の灯火が光っている滑走路に、わずかな灯火した持たない航空機が進入しても視認は難しいだろうとは思いますが、検証する必要はありそうです。
（６）
羽田空港には、着陸機が接近する滑走路に別の機体が進入した場合、管制画面に注意喚起をする機能が備わっていました。（報）
もしこの機能が正常に動作していたのであれば、タワーはなぜ海保機の滑走路誤進入に気づけなかったのかという疑問が残ります。
（７）
滑走路に進入しようとする飛行機に誤進入を警告する航空機接近警告灯（ＲＥＬ）というシステムがありますが、羽田空港には導入されていません。（ネ）
代わりに、羽田空港には可変表示型誘導案内灯（ＶＭＳ）が設置されていますが、Ｃ滑走路には設置されていないという情報があります。（ネ）（これはまだ確認できていません。すみません）
両方とも滑走路を横断する飛行機に対する警告を発する灯火システムなので、滑走路横断のないＣ滑走路には設置する考えがなかったかもしれませんが、離陸着陸の混合運用を行う滑走路についても、警告システムを導入すべきなのではないか、少なくとも検討は行う必要はあるのではないでしょうか。
さらに、先進型地上走行誘導管制システム（Ａ－ＳＭＧＣＳ）の研究を促進し、将来的に滑走路誤進入が生じにくいシステムを導入してほしいと思います。
（８）
１／１には羽田と新潟基地の間を４往復、事故の起こった１／２も２往復しています。（報ネＦ）
もし能登地震が起こっていなかったら、この事故もきっと起こっていなかったでしょう。
犠牲となった乗員のご冥福をお祈りします。
（９）
ＪＡＬ機の乗客乗員３７９人、一人も死者を出さずに脱出できたことは奇跡的と思います。（報ネ）
まずは、ＪＡＬの乗員がしっかりと訓練していたことは賞賛に値すると思います。
・後部ではパイロットとの通信が途絶え、ＣＡ自らが判断して扉を開けたこと
・パイロットは最後まで機内に留まり、全員が脱出したことを確認してから降機したこと
また乗客もパニックにならず荷物を取り出すことなく整然と脱出したことも、賞賛に値すると思います。
ＪＡＬ機側に死者がでなかったことは、本当に不幸中の幸いでした。
ちまたには、海保機を犯人と決めつけ、責任を問う声も上がっているようですが、航空機事故が生じるのはそんな単純な原因ではなく、さまざまな不運が積み重なって起こるということをわかってもらえればと思います。
私は、誕生から幼稚園に入るまで、大分の大空団地（おおぞらだんち）という旧大分空港に隣接した団地で育ちました。
毎日飛行機の離発着を見ていました。飛行機を見るのが大好きでしたし、今でも大好きです。
航空機事故はとてもインパクトの強いものですが、それでも他の乗り物に比べれば安全な乗り物と思います。
そしてその安全は、航空関係者の努力のたまものと思っています。
そんなわけで、ちまたの単純な犯人捜しの声にはとても心を痛めています。
最後に、私は専門家ではないので、できるだけきちんと調査し、正確に記述するように努めましたが、もし誤った認識等があればご指摘ください。
性同一性障害というように、心と身体の性自認が違うって明らかにエラーだからなあ
同性愛は性的嗜好の話でしかなく、性的嗜好ってわりとバラバラで当たり前だし、成人同士ならロリペドなんかと比べても受け入れやすい普通のこと
まとめて扱うのには違和感あるよな
Tl;dr
Cake.jp等、冷凍ケーキを一定以上の品質で宅配しているサービスは多数存在します。
一方で、数年前に「荷物が溢れて冷凍保管すべき荷物が露天保管になっている配送業者」のような問題点も指摘されました。しかし今回は特定の店舗の、特定の品物に問題が集中しており、配送の問題ではないことは明白です。
本来「冷凍」でおくるものを「冷蔵」「常温」で出荷してしまうケースです。これは日常的に発生し得ます。
とくに冷凍冷蔵便は送料が高いので、何らかのロジックで合理化を進めようとして、ミスが生じてしまう現場は稀によくあることです。
ただ、この場合消費者の手元に届いた時点で「冷凍」のシールが貼られていない、伝票に冷凍の記載が無いなどで消費者で判断が可能です。
今回の件は「崩れた状態で凍ってた」ポストが複数あることからこの可能性は低いのだと考えています。
推測に推測を重なることになりますが通常のオペレーションであればきちんと配送できるが、なんらかのオペレーションエラーが生じたことが考えられます。
そしてこの時期おこるエラーといえば、生産販売能力を超えた過剰な受注です。
固まってもいないケーキを箱に入れて配送業者に引渡したら、中でどうなるかは容易に想像できますよね。でも「24日に着かせるにはx日のy時に配送業者に渡さないといけない！でも間に合わないからとりあえず出荷してしまえ」が発生したのです。
都内近郊としても冷凍便なら前日午前には引き渡しでしょうか。そうすると現場では23日の明け方まで製造・梱包・出荷に追われていたのではないでしょうか。現場の人はかわいそうですね。
ネット販売はrate limitによる機会損失が少ないのが魅力であり、食品の場合「作れば売れる」的な発想になりがちです。
ただ、その発想において販売の現場は物流オペレーションを軽視しがちで、今回のようなトラブルは枚挙に暇がありません。
と、いうような例を少なからず見聞きしたことがあるのではないでしょうか。
おおくは、販売が跳ねた場合の限界値について検討されていない、もしくは検討されても適切に販売可能値（普通のカートシステムなら在庫設定するだけでよいが、食品は無限販売すること前提の運用がおおい）に反映されていないことが問題です。
今回の事業者も、写真を見るにデパートの先はお菓子のOEM企業のようです。複数経路からの受注を受け付けているのだとすれば、受注管理システムなどを運用していたら100%とは言いませんがかなり防げそうです。
これは通販というか小売業がそうなのですが、基本的多くの会社は利益率がITの水準から見ると驚くほどに低いです。
その中で適切なシステム化・運用が求められ、そのバランスを見誤ると今回のような事故が生じるわけで大変難しい状況にあると思います。一方で小売の考えを中心にしシステム・オペレーションを二の次にしがち、ということが事故頻発のおおきな要因であることもしっかり受け止め、他山の石としていただきたい。
お前は今からJavaScript Standard Styleに則ってコードの端から端まで魔改造されるんだよ…
それが済んだら次はWebStormのコード分析で真っ白になるまで俺好みに調整してやるからな…
破壊的変更が怖いと泣き叫んだってお前はこれからこのローカル環境のリポジトリで一生を終えるんだ…
青い鳥が居なくなった途端に親から見放されたChrome拡張機能のお前に今さら助けなんて来ないんだよ…
お前がES modulesとしてバラバラに切り刻まれた姿を生みの親に見せてやれないのが残念で仕方ないぜ…
何もしとらんやで
プログラミングちょっと手を出して4回目にコンパイルしたあたりでエラー出て原因が分からず脳内デバッグでぐじゃぐじゃって適性が無さを実感して挫折、エロ絵ちょっと描いてコンテンツ完成させられるほどの才能はないと挫折、DTＭちょっとやって挫折、動画2本投稿して挫折
派遣に応募し中小企業内鯖監視もどきの面接を終えたあたりで集団に属することに対し強烈な拒絶感を覚え挫折
AIイラストで8万稼ぐもやはりコンテンツを完成させ続けられるほどの才能は無いと挫折
タイミーで働こうとスマホ契約するも品出しバイトは2週間先まで埋まってて挫折
家事手伝ってネット見てシコって寝る毎日を繰り返しつつセルフスタンドでバイトしようと思い乙4取得するもトラブル体験談を見て挫折←いまここ
どうしようもねえな
