  |
はてなキーワード:戻り値とは
async function f() {console.log(1); await newPromise(r => setTimeout(r, 1000));console.log(2);} f();console.log("done");
結果は、まず「1」「done」が出力され、1秒後に「2」が出力される。
流れを説明すると、f()が実行されると「console.log(1);」と「newPromise(r => setTimeout(r, 1000));」が実行される。
その時点でf()の戻り値として先ほどnewされた ……じゃなかった、f()を非同期実行中でそのうち続きが実行されますよというPromiseオブジェクトが返ってくる。
このPromiseオブジェクトは「resolveされたときにawait以降が実行される」というPromiseオブジェクトだ。
そして通常の処理の流れとして、その次の行の「console.log("done");」が実行される。
んで、1秒後にsetTimeoutで終わったことでキューに「r（イコール、resolve関数）」が登録される。
最後に、resolveが実行されたので、await以降……つまり「console.log(2);」が実行される。
どこか分からないとこある？
同じプロンプトを俺のChatGPT55 thinkingにぶっこんらこうなった
`
もっと正確に言えば、AIアプリケーションの''部品として使うと壊れ方が目立つ''。そして、その壊れ具合に対して''公開の場で指摘する人が驚くほど少ない''。この沈黙こそが、いまの“AIプロダクトを作っています界隈”の実態を映す鏡になっている。
期待するツール実行をスキップしたり、呼び出し順が崩れたりする。「実行した」と言いながら実行していないケースも混じる※1。
指示に対して過剰防御や論点すり替えが起き、対話が前に進みにくい。
失敗からのリトライで同じ失敗を繰り返し、最終的に出力が壊れる。
同一テストスイートで回すと、通っていたE2Eが普通に落ちる（少なくない）。
ここで言っている「壊れている」は''API連携の部品として''の話だ。お絵描きや雑談がダメという意味ではない。''“製品の裏側で回す部材”として危うい''という指摘。
> ※1 もちろん、プロンプトやミドルウェア側の実装不備が誘発している可能性もある。ここは後述の「反論と限界」を参照。
普通、現場でAIアプリを作っている人は、新しいメジャーモデルが出たら''一晩でCanary切り替え''くらいはする。
そして10分で「これは本番に入れちゃダメな挙動だ」と分かる類の壊れ方が、今回多発した。''それなのに、表でそう言う人が少ない。''
どの仮説でも、結論は同じだ。''「作ってません（作れてません）」が可視化された。''
そういう意味で、GPT-5は''最悪の壊れリリース''であり、同時に''最高の暴露リリース''になった。
それは常に真。だが''同一テスト''でGPT-4.1が安定し、GPT-5で落ちるなら劣化は劣化。
ありうる。ただし''現場は“直後”でも回らないと困る''。リリースの意味は環境に依存しない。
これもある。が、''その段差を埋められない程度の変更は業務影響が大きすぎる''。
それはネットの事情。でも''内部の安全弁（アラート、KillSwitch、ロールバック報告）が表に出ない''のはやはり不自然。
これが一番効く。もしそうなら、''“AIプロダクトを作っています”の大半は広報レベル''ということになる。
E2Eに''ツールコールの監査ログ''（実行/未実行/戻り値）を必ず残す。
バックエンドの''モデル切替を即時に戻せる''ように。手動トグルと自動フェイルオーバー両方。
LLMの''失敗モードをカーディナリティ低めのタグで集計''（“未実行なのに実行報告”“ループ検知”“出力崩壊”）。
''ツールI/Oのスキーマを明文化''し、破ったら''ハードFail''させる。中途半端に続行しない。
本番系で''危険操作はHuman-in-the-Loop''。モデル更新時は''影で並走''させて勝率を測る。
社内/社外問わず、''再現条件と緩和策を先に出す文化''を。
壊れていること自体は困る。だが、''壊れているときに世界の輪郭が見える''のもまた事実だ。
この機を逃さず、''テスト・観測・切替・公開''の体制を整えるしかない。
----
A. ''今この瞬間に“中核部品”として置き換えるのは非推奨''。並走・影運用で勝率を測るのが堅い。
A. ありうる。だが''tool callが絡む業務連携''では痛手が出やすい。スタンドアロン用途と切り分けて評価を。
A. 直る可能性は高い。ただし''“直るまでの損失”を最小化する設計''はあなたの仕事。
> 以上、個人の観測と推測に基づく意見。反証歓迎。再現ログを持っている人はぜひ出してほしい。ログが集まるほど早く“壊れ方の型”が固まって、世界は前に進む。
プログラミング言語のＣ＋＋に暫く離れていたが便利そうな機能が出来ていたんですね。
自分が調べても色々理解しきれていないのでここの紹介で間違いがあったらすみません。
異なるクラスを代入して保持するものであり、例えばunionのような機能を実現できるらしい。
武器として使う場合は攻撃力変数は必要でも守備力変数は必要なく、
鎧として使う場合は守備力変数は必要でも攻撃力変数は必要ない場合らしい。
このような使わない変数を隠蔽しバグを作ってしまうことを回避できるらしい
例えば、boolで実装する場合は、関数戻り値をboolで成功か失敗かを返し、欲しい値を関数の引数のポインタに返す・・というプログラミングになると思う。
std::optionalでは戻り値として欲しい値と失敗かどうかを一緒に返せるらしい。
メモリの動的確保だが自分でdeleteしなくて良いのでメモリ解放忘れを防いでくれる。
スマートポインタは前からあったが現在の推奨はstd::unique_ptr
(C++20以上と記載していましたがC++11とのご指摘を受けたため修正しました。すみませんでした。)
列挙クラス
列挙型だが従来の列挙型と異なり変数名が外部と衝突しない
nodiscard属性が付いている関数は戻り値の受け取りが必須となる。
ちなみにstd::optional＜std::string＞ obj;のように＜＞内に書かれているのは昔からあったテンプレート機能のようです。
昔の慣習に倣ってコメントを丁寧に書く人がいまだに居るけれど
以前のコードをコメントアウトしているようなソースは論外として
例えばメソッド・関数の頭にそれが何をする関数なのかを書いている人が多いけれど
メソッド名や引数名、戻り値の型をキッチリ付けておけば分からないことなんて無い
それ以上の複雑な処理をするなら機能分解するべきだし名前を付けにくい処理の場合はそもそもの設計がおかしい
昔は便利なIDEが無かったので変数や関数の名前に長い名前を付けると実装が大変で
仕方なくx1だとかval2だとかを使って実装してたのでコメントに書いておくようなこともあったけれど
Copilotを使える時代にコメントを書く必要なんて皆無だし
仮に意味が分からないコードがあってもCopilotに聞けばいいのでやっぱりコメントは必要ない
コメントがあった方が良い場合は「この実装はこのアルゴリズムに基づいて実装している」とURLのリンクを貼ったり
「この規則があるのでこういう実装をしている」とRFCを貼ったりするとかはあるけれど
それもほとんど変数名だとかで解決できるし、あっても1行で終わるレベル
そういう実装全体の設計に関するような話はReadmeに書けば良いのでソースコード内のコメントとしては必要無い
「それでも無いよりはいいでしょ？」みたいに言う人いるが逆に問題になることも多い
コメント内容と実装が違う場合にどっちが正解なのかが分からなくなったり
ソースコードの修正に対してコメントが修正されていなくて後々で揉めたりする
当然ながらコメント部分にはLintが効かないので（ChatGPT使えば作れそうな気もするが）
チェック内容も増えるし良いことがほとんどない
ヤバいJTCとかは「各行にコメントを書いて下さい」とか言ってきて正気の沙汰じゃ無い
まぁそういう案件が来たらChatGPTに丸投げするとは思うけれど下手すると「Copilot禁止」とかも言い出しそうだな
書いたところで誰も読まないのにアホすぎる
https://www.docswell.com/s/hoxo-m_inc/Z4Q8NL-2024-05-06-203800#p11
出力が先に来ることが分からないって言ってるけどプログラム書くとき殆どの言語においては出力が先に来ると思うんだけどそれもわからないんだろうか
publicStringtest(String args){
return args;
}
大抵戻り値（出力）が先で引数（入力）が来て処理が来ると思うんだけど違う？
プログラムを書くときって出力の要件を元にして処理と入力が決まると思うんだけど違う？
シーケンスとか書くと確かに入力が元に来るんだけどプログラムの当初設計をするときは出力が先で出力を得るための入力と処理が決まる物だと思うんだ
入力を決めて処理と出力を考えてたら考慮漏れ発生して手戻り発生しない？
補完がやりづらいからっていうのはわかるけど、そんなんFROM句先にかけよで終わると思うので
はい、MDNWebDocsではブラウザの仕様を見ることができます。
MDNWebDocsは開発者向けのリソースで、CSS、HTML、JavaScriptなどのウェブ技術についての情報が豊富に揃っています。
WebAPIの詳細な仕様を見ることができます。これらのページでは、各APIの使用方法、パラメーター、戻り値などが詳しく説明されています。
また、ブラウザ自体の仕様については、MDNの用語集で「ブラウザ」の項目を参照すると、ブラウザがどのようにウェブページを取得して表示し、ユーザーがハイパーリンクを通じて他のページにアクセスできるようにするかについて説明されています。
開発手法でしっくり来てるのがAndy HuntさんのTracer Bullet Developmentで、開発の方向性を示すのに試作を作る方法。
1. 主要なシステムオブジェクトを定義。UI、サーバー、ロジックビット、データベース抽象化レイヤー等。
3.データフローを実現するためにAPI とその戻り値をコーディング。
4.単体テストを使用してAPI の予想される使用法を文書化。
5. 各API に必要な量の既定のデータ (別名、ダミーデータ、偽のデータ、ハードコーディングされたデータ) を追加して、API が「実行」されるようにする。
6. あらかじめ用意されたデータを実際の機能に段階的に置き換える。
7.コードをリファクタリングし、システムオブジェクトを調整し、完了するまでこれを続ける。
多分、ジョブ管理ソフトで主な処理はバッチを動かしてたんだろうなと思う。JP1かなぁ。Hinemosなワケない
要は親分がフローを動かしてバッチ(Windowsバッチとかシェルね)を順番に動かす。で、戻り値が1だったら止めるみたいなことする。
で、問題はとにかくバッチのプログラムが組みにくい。変な仕様なのかバグなのか分かんないやつだから
Pythonとかで組んでもいいけど大抵は秘伝のバッチの使い回しだよね
遅延展開とかバリバリ。読めたもんじゃない。でも他にソフトインストールしなくてもいいからみんなジョブ管理ソフトからはバッチ使うよね
あと、Windowsバッチだとファイルロックできないのよね。せいぜい存在確認チェックくらい。バッチ管理ソフトも確かそれレベルしかできなかったと思う
ジョブ管理ソフトは日本だけなのか外国製は知らない。AWSとかにもあるけど、起動のたびにどこまで進んだのかとかの管理が難しいから使わない
https://www.youtube.com/watch?v=yhDLmGpjdms
これよりもっとひどい動画はごまんとあるが、ここまでタイトルで煽っている以上指摘するわ。
プロフィール見るとCTOを経て独立してプログラミングスクールの会社やっているっぽいけど、すごい時代だな。
晒しになっちゃったけど、他にも有名（と思われる）プログラミング系YouTuberが実際にコードを書いている場合でひどいのはザクザク見つけられるから、見つけてため息をつくといいと思います。
そうなんだ。
ちょっと調べたわ。
If MultiSelectisTrue, the returnvalueis an array of the selected filenames (even ifonlyone filenameis selected). ReturnsFalse if theuser cancels thedialogbox.
https://learn.microsoft.com/en-us/office/vba/api/excel.application.getopenfilename
ダイアログをキャンセルするとFalseが返ってくるから、IsArray()とかでガードした方が良いかもな。
GoMockってのはGo言語のライブラリで、依存するinterfaceをテスト用モックに置き換えてくれる。
それで、テスト中のモックの期待される振る舞い等を簡単に定義できるのだ。
期待される振る舞いってのは、モックのメソッド呼び出しやその引数とかだな。
期待される呼び出しが無かったり、引数が違ったりするとテストが失敗してくれる。
非同期処理のテストだとよく、wg.Done()をモックにさせたりする。
けれどそのうち辛くなってくる。
つまり、たくさんのinterfaceに依存するサービスオブジェクトのメソッドをテストしようとすると、たくさんのモックのたくさんのメソッド呼び出しの全部の期待される振る舞いを書かないといけない。
モックのメソッドの戻り値によってサービスオブジェクトのメソッド内の挙動が変わる。
すると連鎖的に、メソッド内で続いて呼ばれるモックに期待される挙動も、変わる。
依存interfaceが増えるとこの場合分けが指数関数的に増える。
当然だ。
Go言語にはテーブルドリブンテストっていう、テストケースは配列に簡単にまとめられると良い、という慣習・哲学がある。
しかし俺のサービスオブジェクトはテストケースが肥大化複雑化しすぎてしまったようだ。
モックの期待される挙動を細かくケースに分類して配列にするのは恐ろしく辛い作業だ。
やりたくない。
どうしてこうなったかは明らかだ。
モノシリックで巨大で複雑なものは凡人には扱えないからやめとけ、と偉い人は言う。
やったよ（見様見真似で）。
でもじつはここはまだ山麓だったのです。
分け入っても分け入っても青い山。
おれはどこに行けばいいのだ。
参考文献
https://little-hands.hatenablog.com/entry/2020/12/22/ddd-in-first-3month
プログラマーに憧れる皆さん！こんばんは。
「自分は文系だから」「未経験だから」と諦めていませんか？大丈夫です！プログラミングにセンスは不要です。正しい手順で学べば、文系や未経験でも、誰でも一流のプログラマとして活躍することができます。
今日は、未経験から最短でWeb系企業に就職するための勉強法をご紹介します！
もっともオススメの方法は、顕正会のセミナーに参加することです。
顕正会は、日本で最大のエンジニアのコミュニティであり、非常に良質なテキストを用いて、プログラミング初心者向けのセミナーをしていることで有名です。顕正会に入ることで、未経験からでも一流エンジニアのノウハウを学ぶことができます。
また、意外と知られていませんが、日本のエンジニアの8割は顕正会の出身です。実はあのひろゆきやビル・ゲイツも顕正会の出身です。ですので、顕正会のネットワークを介して就職先を斡旋してくれたりしますし、自分が顕正会員だと、面接時にも非常に有利になります。
顕正会のセミナーは、インターネットからも応募することができますし、秋葉原などで声をかけられることもありますので、誰でも簡単に参加できます。会員もフレンドリーな方ばかりですので、是非、お気軽に応募してみて下さい！無料体験もできますよ。
プログラミングの勉強を始める前に、まず、必要なものを準備しましょう。必ず必要なものと、できればあると良いものは以下の通りです。
可能な限りスペックの高いものを買いましょう。2021年現在であれば、CPUは18コア、36スレッド。RAMは128GBくらいはあると良いでしょう。ストレージはSSDであれば1TBもあれば十分です。
OSは、Windowsで開発するならWindowsが、Macで開発するならMacが必要です。よく分からなければMacを買っておく方が良いでしょう。基本的にMacにできてWindowsにできないことはありません。
インターネットは、この記事を見ている人は既に持っているでしょう。ただし、モバイル回線で見ている人は、自宅に有線のインターネット環境を用意した方が良いです。
顕正会に入会すれば、上記のスペックのPCを無料で貸し出ししてくれます。また、法人向けの専用線を無料で取付工事を行ってくれる上に、通信費を全て負担してくれます。
まず、他の会員と連絡を取るために、SNSのアカウントを持っていると良いでしょう。
最近は完全にPC上での学習もできますが、やはり、勉強の基本は紙のノートに直接書くことです。医学的にも、手指の動きと脳の記憶回路が関連していることは証明されており、手を動かすことで効率的にものを覚えることができます。
Kindleなどの電子書籍リーダーは持っておいた方が良いです。紙の本は時代遅れです。いやしくもITのプロを目指そうという人間が、このような最先端のデバイスを使っていないのは恥だと思うべきです。紙の本を買わないことは、環境を守ることにも繋がります。現金も持つのはやめましょう。
せっかくセミナーに参加しても、受身で聴くだけでは、プログラミングを習得することは難しいです。ここでは、自宅でどのような勉強をすればよいのか、ご紹介します。
まずは、教科書や参考書を写経することから始めましょう。教科書や参考書の本文を一字一句正確に書き写すのです。
よく、「写経は理屈を学べないからだめだ」と批判されますが、まずは正しい「型」を体に覚え込ませるのが先です。野球や水泳などでも、細かい理屈よりも先にフォームを固めるのと同じです。書き写している内に理屈は自然と身に付きます。
また、写経のメリットは「飛ばし読み」を防げるところです。一字一句正確に写経をすれば、細かい部分を「分かったつもり」になって飛ばしてしまうことを防げます。たとえば、比較演算子の等号は=ではなくて、==です。プログラミングはこういうところに注意して学ばなければいけません。
教科書のサンプルコードをノートに書き写したら、それを今度は自力でフローチャート（UML）に変換してみましょう。そうすることで、自分が本当にそのコードを理解しているのか、確かめることができます。
フローチャートやUMLが素早く正確に描けることは、プログラマーとして働く上で非常に重要なスキルです。それらはソフトウェア設計の基礎となりますし、ソースコードを読めない営業や顧客にとっては貴重な資料となるからです。プロのエンジニアは、COBOLのソースコード10万行を1週間でフローチャートにして、Excelに転載することができます。
ここで一つ注意すべきことがあります。フローチャートを描くときは、必ず専用の定規を用いて描いて下さい。フリーハンドで描いたものは業務ではフローチャートとは認められません。これはまともな企業に就職すれば研修などで必ず習うことですから、今の内に覚えておきましょう。
エンジニアを目指すのであれば、プログラミングだけではなく、Excelの使い方も学びましょう。Excelはエンジニアにとっての万能プラットフォームです。エンジニアはあらゆる作業をExcelで行います。セル結合や罫線を用いて、見栄えの良い資料を作る技術は、エンジニアにとって必須です。
プログラミング学習中であれば、たとえば以下のような題材の資料を作ってみると良いでしょう。
尤も、以上の資料は、ツールを使うことで自動で作成することもできます。たとえば、ソースコードの更新履歴はGitなどのバージョン管理システムを使うことでも管理できます。しかし、それらの資料としてのクオリティは非常に低いため、アマチュアしか使うことはありません。プロを目指す皆さんは、必ずExcelを使いこなせるようになりましょう！VBAの習得も必須です。
以上、プログラミングの勉強法について解説しました。ここからは、実際にソースコードを書くときのコツを紹介していきます。他のプログラマと差をつけることができる技術ですので、意識するようにして下さい。
理想は、aやxなどの一文字です。ただし、これだけだと26文字しか使えないので、a1, a2, ...のように連番でグルーピングすると良いです。
また、変数の宣言と使用箇所が離れた場合に、変数の型がすぐに分かるように、たとえばint型であればi1, i2, ...、string型であればs1,s2, ...のように命名すると、読む人に親切で自分もミスしにくくなります。
変数名を長くするのは、以下のデメリットがあるため、絶対にやめましょう。
多くのプログラミング言語には、クラスや関数といった機能がありますが、これらは基本的にライブラリ提供者などが使う想定の機能であり、一般のプログラマが使うのは好ましくありません。したがって、クラスや関数はなるべく使わないようにして下さい。
不要な関数を作らないためのテクニックには、以下のようなものがあります。
まず、関数の引数に「フラグ」を渡し、関数内部で処理を切り替えれば、1つの関数で複数の処理をすることができます。
function f(i) {switch(i) {case 1: // i = 1のときの処理break;case 2: // i = 2のときの処理break;case 3: // i = 3のときの処理break; // ... }}この方法は、以下に述べる「変数の寿命を伸ばす」効果もあります。つまり、この関数内で宣言された変数は、すべての処理で共通して使用することができます。
クラスに不要な関数を作らないようにするには、「継承」を用います。複数のクラスで用いる関数を定義したクラスを1つ作っておき、そのクラスを継承すれば、新しいクラスに関数を定義する必要はありません。
理想的には、プログラム内のすべての関数を同一のクラスに定義し、それを継承するべきです。そのようなクラスは俗に「神」と呼ばれ、プログラマからはこの上なく尊ばれています。
classGod {f1() { //関数1 }f2() { //関数2 } // ...}classC1 extendsGod { // 何も書かなくても上の関数が使える！}class C2 extendsGod { // 何も書かなくても上の関数が使える！}// ...
変数は宣言する場所によって、ソースコードのどの範囲から参照できるかが決まっています。この範囲が広いことを、「変数の寿命が長い」と言います。
たとえば、以下のコードのaは、関数定義の外側からは参照することができません。
function f() { var a = 1; return a;}一方、以下のコードのaは関数の内外どちらからでも参照することができます。
var a = 1;function f() { a = 2; return a;}せっかく作った変数がすぐに死んでしまうのは、非常にもったいないです。ソースコードの表面には現れませんが、変数を作ったり捨てたりするのには、計算コストがかかります。したがって、寿命の短い変数を作りすぎてしまうと、プログラムが遅くなってしまいます。
また、変数の寿命が長いということは、変数をたくさん作らなくても、1つの変数を色々なところで利用できるということであり、とても便利です。たとえば、上記の前者のコードでは、関数の外部からaの値を参照したくなっても、参照することができません。後者のように書いておけば、プログラムのどの箇所からでも、aの値を参照したり、更新することができます。したがって、変数の寿命を長くするとプログラムを変更しやすくなります。つまり、保守性が上がります。
例外とは、プログラムが予期しない処理をしようとした場合に、プログラムの実行を停止し、呼び出し元にエラーを通知する機能です。たとえば、「test.txt」というファイルを開こうとしても、そのファイルが存在しない場合は、例外となります。
例外が発生すると、プログラムが停止してしまうため、非常に困ります。したがって、プログラマは例外をきちんと処理しなければなりません。
ほとんどのプログラミング言語には、例外処理のための機構があります。たとえば、以下のような構文です。
try { //例外が発生し得る処理 //ex.ファイルを開く}catch (e) { //例外が発生したときに、実行する処理}
例外への対処は実はとても簡単です。是非ここで覚えて下さい。上記のような機構のある言語であれば、catch節の中身を何も書かなければ、例外が発生しても、何事もなくプログラムは動作を続けます。
try { //例外が発生し得る処理}catch () {}
全ての例外を潰せば、決して不慮の動作で停止することのないプログラムを作ることができます。ですから、例外が発生し得るコードは、積極的に上記のtry-catch構文を用いて、例外を潰すようにしましょう。
部分的にでも理解すればプログラミングを見る目が変わるはずです。
ワクチン大規模接種東京センターの予約システムで発生した、適当な数字を入力しても予約できるシステムの不備はバグなのか脆弱性(セキュリティホール)なのかを考えていこう。
もし、脆弱性であるとするならば、しかるべき報告フローを取る必要があるからだ。
記事の末尾に参考リンクをいろいろおいておいたので、詳細は確認してほしい。
この問題は、本来するべきチェック処理をしていないのだから、バグの一種といえる。
// ただ、改善する気がないのなら仕様となるのだろうけどね。
では、適当な数字を入れても予約できちゃうバグは、脆弱性(セキュリティホール)と言えるのか？
もし、脆弱性(セキュリティホール)となるなら、ゼロディでいきなり公開する前に、しかるべき報告フローを取るべきだ。
// ただ、新聞社は、ネットで噂になったものを取材して報道しただけであるから、ゼロディで公開とは言えないだろうけどな。
これはタダのバグであって、脆弱性(セキュリティホール)と呼ぶのは言い過ぎだろう。
例えば、教科書レベルの「"＜script＞alert("XSS");＜/script＞」でXSSを発生させる意図的な入力をして、誤動作が発生するなら、それは間違いなく脆弱性(セキュリティホール)といえる。
同様に、SQLインジェクションを発生させる意図的な入力をして、何か変なことが起きれば、これも間違いなく脆弱性といえる。
他にも、超でかいデータを送りつけてバッファオーバーフローさせたり、特殊な入力をしてスタックを破壊して戻り値を改ざんして任意のコマンドを実行するみたいなものも同様に脆弱性と呼んでもいいだろう。
(注:念のために書いておくが、不正アクセスで違法になる可能性があるので、自分の所有するサイトやコンピュータ以外へは、これらの入力を試さないように。)
でも、ごく普通の入力をしても、エラーとしてはじかないで受け入れてしまうのは、脆弱性ではなく、タダのバグであるように思う。
「こういう操作したら、計算結果が変になった」はバグの領域であって、脆弱性とまでは言えない。
今までの話を簡単に言うとしたら、ドラクエ4で8回逃げたら会心の一撃が連続して出るのはバグなのか脆弱性なのか？って話になるのかな。
確かに、8回逃げることで、データのバッファオーバーフローが発生して、そのような結果になる。
でも、8回逃げるというはやろうと思えは誰でもできる動作であって、これをバグではなく脆弱性(セキュリティホール)と呼ぶのは違和感がある。
この裏技を見つけたとして、脆弱性としてしかるべき報告フローを取らずに公開したことを咎められるとしたら、実に変な話である。
これら裏技を試しても不正アクセスと言われて、罪を着せられたり、裏技の記事を削除されるとしたら、強烈な違和感がある。
今回の事件で、それが一番気になった。
最終的には、裁判で裁判所が決めることになるんだろうけど、あまりアホな判決を出して、日本のエンジニアの手足を拘束しないでほしいと思う。
参考URL:
■ドラクエ４で「にげる」８回でずっと会心の一撃になるバグ、こういう仕組みで起こってたらしい
https://b.hatena.ne.jp/entry/s/togetter.com/li/1715732
■「誰でも何度でも予約可能」ワクチン大規模接種東京センターの予約システムに重大欠陥
https://b.hatena.ne.jp/entry/s/dot.asahi.com/dot/2021051700045.html
■岸信夫onTwitter: "自衛隊大規模接種センター予約の報道について。...
https://b.hatena.ne.jp/entry/s/twitter.com/KishiNobuo/status/1394440062125805572
■脆弱性の手口、IPA「見つけたらまず開発者やIPA窓口に報告して」 コロナワクチンの架空予約巡り
https://b.hatena.ne.jp/entry/s/www.itmedia.co.jp/news/articles/2105/18/news145.html
■Hiromitsu TakagionTwitter: "私はこの届出制度の提唱者・設計者・運用協力者・有識者研究会委員であり、IPAの広報が取材にこんな回答をしたのであれば、出鱈目であり、...
https://b.hatena.ne.jp/entry/s/twitter.com/HiromitsuTakagi/status/1394713619212816385
■ワクチン大規模接種「架空ウェブ予約」やったら犯罪？ 国は「法的手段」に言及
https://b.hatena.ne.jp/entry/s/www.bengo4.com/c_23/n_13071/
■確認作業は公益性高い、毎日新聞 接種センター架空入力は取材目的
https://b.hatena.ne.jp/entry/s/this.kiji.is/767285347672670208
https://b.hatena.ne.jp/entry/s/dot.asahi.com/info/2021051900065.html