  |
はてなキーワード: HTTPとは
スパムメールに騙されて、スパム文面（下記参照）の「振込入金の詳細については、SMBCダイレクトでご確認いただけます。」のURLリンクを踏んでしまいました。
だけど、それは謂わばスパム側による囮の様なURLで、三井住友銀行のドメインだったので、幸運にも今回は難を逃れることができました。
今回のスパム側の主な目的は、メール受診者（スパム被害者）がHTML形式でメールを確認して、また、メールの内容を信頼して「ご確認」のURLリンク「ttps://www.shuhmsドットcom」（詐欺サイト）をクリックすることだと思われます。
私は普段から平文形式でメールを確認するので、（実際の被害を受けるという意味では）今回難を逃れたけど、普段からHTML形式でメールを確認していたり、情報弱者や高齢者だったら騙されやすいだろうと感じます。
ポイントは、「ご確認」のリンク先が「ttps://www.shuhmsドットcom」になっていた他、「振込入金の詳細については、SMBCダイレクトでご確認いただけます。」の次の行のURLの/kojin以下の文字列がオリジナルと違うことです。
それ以外、題名、送信元、メール内容についてオリジナルに擬態しています。
普段からスパムメールに注意していますが、スパムの擬態が高度化して、情報弱者が騙されやするなる閾値を超えたと感じたので、警鐘の意味を込めて書いておきます。
【スパムメール】
-------------------------------------------------------------------------
Subject: 【三井住友銀行】振込入金失敗のお知らせ
Date: Thu, 9 Mar 2023 **:**:** +0800
From: 三井住友銀行 <SMBC_service@dn.smbc.co.jp>
-------------------------------------------------------------------------
-------------------------------------------------------------------------
Date: Sat, 25 Feb 2023 **:**:** +0900
From: 三井住友銀行 <SMBC_service@dn.smbc.co.jp>
Reply-To: SMBC.Auto.reply@ar.smbc.co.jp
-------------------------------------------------------------------------
-------------------------------------------------------------------------
三井住友銀行より、ご指定口座への振込入金失敗についてお知らせします。
振込入金の詳細については、SMBCダイレクトでご確認いただけます。
ttps://www.smbc.co.jp/kojin/app/smbcapp.html?aff=dirct_mlODM1902001（←kojin以下の文字列がオリジナルと違う）
―――――――――――――――――――――
※振込依頼人から振込の「取消」「変更」「組戻」があった場合等、お知らせした明細と実際の手続が異なる場合があ
ります。
※本メールは、お客さまお届けのメールアドレスへお送りしています（本メールの再送依頼は受け付けておりません）
。
偽のメール等で誘導された当行を装う偽サイトに、お客さまの口座情報やワンタイムパスワード等を入力すると、不正
＞ ttps://www.smbc.co.jp/kojin/special/stop_phishing_crime/
「三井住友銀行」名でお送りするメールには、携帯キャリアのメールアドレス宛を除き全て電子署名を付けています。
＞ ttps://www.smbc.co.jp/security/smime/
閲覧しているサイトが当行の正当なサイトかどうかを、電子証明書により確認いただけます。
＞ ttps://qa.smbc.co.jp/faq/show/297?site_domain=default
本メールに対するメールでのご返信・お問い合わせはお受けしておりません。メールの内容に身に覚えがない場合や、
サービス等についてくわしく知りたい場合は、当行ホームページをご覧いただくか、以下より電話番号を確認の上、お
問い合わせください。
＞ ttps://www.smbc.co.jp/contact_list.html
＞ ttps://direct.smbc.co.jp/aib/aibgsjsw5001.jsp?sc=081
-----------------------------------------------------------------------
-------------------------------------------------------------------------
・色んなこと満遍なくやりたい
・やべー案件に何年も磔にされたくない
これが多様なサービス、アプリを作ってみたいという話なら高単価SESに行くしかない。
かなりの経験を積んだベテランじゃないと入れない世界で出身学部も見られるから相当に厳しいと思う。
フロントやバックエンド、インフラなどもやってみたいという話なら自社でウェブサービスを運用している上場企業に正社員で入るのがいいだろう。
ただし正社員ということはリリース日には何が何でもサービスインさせる立場になるということでもある。定時退社の社風であっても進捗上がってないなら稼動上げて対応ということは普通にある。
派遣で入ればそういうことは無い。上場企業ならコンプラ厳しいからね。でも数ヶ月程度、長くて数年のスポットになることがほとんどなので長期的にはどうなんだろうな。
ここでは俺の経験を踏まえて「自社でウェブサービスを運用している上場企業に正社員で入る」という前提で話す。
アピールすると良いのは使える言語、インフラの知見、構築と運用の経験。
全部が強い必要は無い。どれか一つが強くて他はまあなんとか程度でいい。逆に言うと全くダメですが一つでもあると厳しい。
使える言語では、C#,Javaを大きめな規模のバックエンドとして使ってるとこが多い反面、対応できる人はフリーにも派遣にもたくさんいるのでちょっと弱い。SIer出身でコード書いてたなら当然できるよね、というレベル。
今ならtypescript(javascript), pythonあたりができてgo あるいは Rust勉強してます、というのがけっこう強い。
分かってると思うが言語が使えるというのは、まっさらなPCを与えられて主要なウェブフレームワークをセットアップしてローカルホストを立てるとこまでを含む。
JavaならSpringboot+gradle+JUnit、PHPならLaravel、pythonならdjango、typescriptならNode+React+knex、あとJestかDreddも入るかな。
インフラ知識では、クラウド、オンプレ両方のメリットデメリットを把握しているとよい。
AWS,Azure,GCP,Oracle Cloudのどれでもいいけど実際に使った経験があるとよい。俺は個人でGCPを契約してkubernetesとVM、LBを使っている。
ネットワークの知識は薄くでも持っていた方がよい。HTTPとかcookieとかセッションとか知りませんCORSって何ですか？レベルでは無理。まあここら辺はウェブサービスを作れば必ずやるので大丈夫だろう。
LetsでSSL証明書を作ってopensslで検証してnginxに適用してHTTPS化ができるならアピールになる。
dockerはもうそろそろ使えて当然のレベルになってきているので必須。実際ウチではdockerが分からない使えない人は面接へ進めないようになっている。
構築と運用では、予算内に収まるような構築と運用、サービスインした後のトラブルシューティングの経験があるとよい。
常にコスト意識を持っていることが必要。クラウドは油断すると100万程度すぐ飛ぶ。コスト意識が無い人を運用担当として採用することは絶対にない。
トラブルシューティングで重視されるのはベンダー対応よりもエンドユーザー対応の方。
サービスを早急に復旧させること、そのためにどういう仕組みが必要なのか、構築するところから語れる知見があるとよい。もちろんそこにもコスト意識は必要。
CI/CD、PrometheusやDatadogによる監視とアラートについて語れるとよい。
CI/CDを扱うということは当然gradle,maven,yarn,シェルスクリプトは書けて使えてwebpack,minify,Jenkinsのコンフィグもできるということである。
どうだろう、かなり雑に書いたが雰囲気は伝わると思う。
あ、git使えないは論外。もし使えないなら今すぐ使えるようになるか諦めるかのどちらかで。
結構多くのWEBサーバのアクセス制限で.co.jp .ne.jp .jpがdeny設定されていたって話である。
https://b.hatena.ne.jp/entry/s/twitter.com/kanose/status/1601270223386324992
個人のネット利用で大きな転換点は2005年くらいで、例えばブログのはしりのはてなダイアリーサービス開始は2003年でアルファブロガー選考開始は2004年、youtubeサービスインが2005年だが、これらの特徴は「アカウントをとって企業のWEBサービスを利用する」という、今では当たり前の方法だ。
だがこの以前にはそういう方式のものは少なく、ISPや借りたレンタルサーバに自分でコンテンツをアップロードして構築するというのが主流だった。
これは内部的にはLINUXサーバ制限アカウントを貰ってユーザーディレクトリの/WWWにファイルを置くという事やね。
だから最初のうちは個人サイトのURLは「ｈttp://www.yourisp.co.jp/~aybabtu」って感じだった。~はUNIXのユーザーホームディレクトリを示すのね。やがてバーチャルドメインに対応するサーバ会社が増えてｈttp://www.aybabtu.rentarusabaa.comみたいな今では当たり前のURLになったんだが、最初はバーチャルドメイン設定は有料だった。
MS Officeには「パブリッシュ」ボタンがあってそれを押すと編集してるファイル群の構造のまま指定したサーバにFTPでファイル送るみたいな機能もあった。（だがこれはShift-JISでUpするというクソ仕様で後に読めなくなるのだった）
httpの頭のHTはハイパーテキストで、参照箇所にはリンクが設定できて参照元にジャンプ（これも死語だ）できる電子文書なわけで、まさに公開はパブシュッシュ＝出版なわけだ。今もサブスクリプション＝新聞雑誌の定期購読というのはこの建付けが残ってるからだ。
ISPやWEBレンサバにはユーザー権限の多寡で違いがあって、ユーザに実行権限も付与してperlなどのインタープリタを構築しておくと、テキストであってもファイル先頭にインタープリタへのパスを書いておくとそれが実行され、標準出力をhttpで返す。これがCGIで、ISP供与で多いHTMLファイルの公開だけの権限制限されたサーバに不満な層は「CGI実行可」のレンサバ屋に移っていった。
但しプログラムであるから、いい加減に書いてループ参照とか起こすとサーバのCPUやメモリを喰いつくしてサーバダウンを惹き起こす。だからISP供与のでは実行権限を与えなかったわけだ。逆に言えばISPが必ずホームページ公開スぺースを供与するのに個人向けレンサバが成り立ったのは何故？と言えばCGIの実行が出来たからだ。
故にWindowsしか使わない人には難しい上級者向けだったのだが、これを優しいチュートリアルで簡単設定出来るようにしてユーザーを増やして会社を大きくしたのがpaperboy＆co.の家入一真氏なわけだ。はてな創業者の近藤淳也氏と並ぶ個性的なアントレプレナーと謂われた。その後堀江などと共にインターネッ党を作って都知事選に出て箸にも棒にもな結果になったのは黒歴史なので触れないで上げてください。特に堀江は野菜でいじられるよりも傷つくので偉そうに政治の話してる時に「インターネッ党」とボソっというのは残酷な事なので止めてあげて欲しい。お願いします。
また、CGIでの使用言語はperlが圧倒的で、perlで書いた掲示板スクリプトを配布するサイト、趣味プログラマが星の数ほどいた。
こういう訳で初期のWEBで動的ページ＝perlであってJcode.pmを開発した小飼弾氏は魔術師扱いされて崇拝されており、ブログブームが来ると圧倒的な人気を誇った。
今では多言語が普通に扱えるのが当たり前だが、マルチバイト文字の扱いというのは難しく、文字コードがそれぞれ違うのがそれに輪をかけていた。例えば今でも日本語Windows上でフランス語や中国語のファイル名は作れないだろう。また、最初期からかなりの期間、Twitterでは日本語の検索が出来なかった。youtubeでも日本語で投稿できなかった期間は長い。
子飼氏はperlで日本語を使用できるようにするライブラリをUNICODE対応にしてWEBで普遍的に日本語が使えるようにしたものだ。
ただ、HTLMと実行文を混ぜ書きできるPHPがver.4になるとデータベース連携が強化されていてデフォルトでSQL文発行関数が実装されており、perlCGIは廃れていってしまう。
またISPより高い自由度を求めて自宅にサーバを立ててそれを公開するという者も現れた。
はてなはサーバをデータセンターに置いてはいたものの、筐体は町工場に設計図を持ち込んでステンレスの1U筐体を自前で作っていたし、Pixivはギガバイトのシステムボードを使って自作した多数のサーバをエレクター上に置いてむき出し運用してしていたので、自宅サーバ組の延長にあったのだな、実は。
こういう中で画像を公開する、動画を公開するというのはなかなか大変だった。
仲間内で見るという分にはファイルを置けばいいだけだが、問題になったのが「2ch晒し」であった。これは悪意を持って2chにURLを貼るのだけじゃなくて、単にURLを書くというのも含まれた。
というのも2chにURLが書かれるとアクセスが集中して大抵はサーバダウンしてしまう。すると他の契約者のサイトもページも見れなくなってしまう。
例えばヒーロー戦記主題歌みたいな社歌でbuzzった日本ブレイク工業のサイトは重すぎて何週間も閲覧出来なくなった。社歌の動画ファイルを置いていたためだ。
こういうサーバダウンは契約者の責任ではないがホスティング会社も許してはくれない。契約解除、つまり出ていけか、法人契約への変更かを迫られる。転送量制限なしと言っていても実際に転送過多になると干すティングになるわけだ。
だから2chは悪意の塊の他にサーバーダウンとサーバからの追い出しを惹き起こすので蛇蝎のように嫌われていた。2ch晒し→その時点でサイトを閉じてしまう人も多く居た。
するとこれを逆手に取ってアップローダ（あぷろだ）を自作サーバで運用してアフィリエイトで収入を上げる者が現れてくる。
ただこれは著作権違反のファイルが上げられて訴えられる事もあるからそのリスク低減のためと転送量制限の為にファイル容量に制限が設けられていた。
すると大きなファイルを共有したい連中はこれでは満足できない。
そこで目を付けたのが海外でアップローダを運用しているサーバだ。運用動機は日本のアップローダと変わらない。だがファイルの大きさの制限が緩かった。
そこでそういう海外のアップローダが違法性が高いファイルの共有に使われるようになった。やってたのは2chのダウンロード板と半角板がメインだ。
だがこれは運営には迷惑な話で、日本人は英語の広告なんてクリックしない。しかも商品の販路が無いので日本からのアクセスに報酬は支払われない。つまり金を落とさず転送量だけ上がるのだ。しかも海外では転送量従量課金は多かった。
更に問題なのがロリ画像がアップロードされることだ。2次元ロリでも規制があるのに実写ロリは完全アウトだ。実写ロリが発覚した場合、サーバ管理者は必ず逮捕される。マグショットが新聞に掲載されTVで晒され、釈放後も幼児が被害者の性犯罪者なのでGPSロガ装着が義務付けられ住所は共有される。二度と部屋を借りる事は出来ずに一生トレーラーハウスかキャンピングカーを買って橋の下で生活となる。
こんな実写ロリ画像や動画をアップロードする奴が居たのである。
そこで管理者としては日本からのアクセスが増えたのを確認した時点で遮断するしかない。一生を棒に振る可能性を回避するためだ。
圧倒的によく使われるWEBサーバのapacheでは.htaccessというシステムファイルに記述してアクセス制限を掛ける事が出来る。ここで国別IPアドレス指定するのはちょっと難しいのでdeny from co.jp deny from ne.jpという風に書くとドメインがco.jp、ne.jpからのアクセスを全部弾くことができる。
この時にディレクトリ指定を「/」にするとそのサーバの全てが弾かれて403エラーが出てしまう。しかもバーチャルドメインも同じなので思わぬところで403エラーが出る事もある。
そういう訳であちこちの海外サーバで日本からのアクセスが拒否されていた。全て2chダウンロード板と半角板のやつらのせいである。
自分はアメリカの田舎の新聞社のトップページで403を食らったことがあるから嫌われ方は相当なものだと思う。「やるべき.htaccessの基本設定」みたいなのに書かれて共有されたのかも知れない。
因みにダウンロード板と半角板は2ch名物の厨房板だったのに、今見たら無くなってるのな。諸行無常だ。
2005年にサービスインしたYoutubeだが、翌年にGoogleに買収されたもので最初は元paypal社員らが作ったベンチャーだった。
だが最初は著作権違反コンテンツばかりであって、自作ビデオというのは少なかった。
特に酷かったのがまた日本人で、最初は10分制限がなかったのをいいことにアニメの全話丸上げみたいなのが大量にされており、当事者のアニオタ達も「ここまでやったら閉鎖されるだろ！」と諫めるほどだった。
そんな中で2006年6月にYoutubeが数日間の大メンテナンスに突入し、画面には「All your video are belong to us」というブロークン英語が書かれていて騒ぎになった事があった。
これの元ネタは「All your base are belong to us」で、古いセガのゲームの英語版で出てきたセリフだ。深刻な場面で突然めちゃくちゃな英語をいう。このおかしさでFLASHが作られたりとミーム化していたものだ。
しかも日本産ゲームは結構あちこちでバカ英語を作ってて、engrishとかjanglishとか言われてネタにされていた。日本で言えばアヤシイ中国製品の日本語を愛でるような感じだ。
そこでYoutubeがあんなメッセージを出したので、日本のネット民は身に覚えがありすぎて「アニオタのせいだろ！また排除されるだろ」と責任のなすり合いと相なったのだった。
因みにその後も日本人の利用が制限とかは無かったので誤解だったのだが、海外アップローダ見つけては403の焼き畑とかロリ画像問題とかがあって、その後のアニメフル全話という流れだったので過剰反応をしたのであった。
22は、空の下なるFTPに、
25は、岩の館のSMTPに、
80は、暗き御座のHTTPのため
影横たわるWorld Wide Webの国に。
HTTPは、すべてを統べ、
HTTPは、すべてを見つけ、
HTTPは、すべてを捕らえて、
くらやみのなかにつなぎとめる。
影横たわるWorld Wide Webの国に。
Twenty two for the FTP under the sky,
Twenty five for the SMTP in their halls of stone,
Seventy for Gopher doomed to die,
Eighty for the HTTP on his dark throne
In the Land of World Wide Web where the Shadows lie.
HTTP to rule them all, HTTP to find them,
HTTP to bring them all and in the darkness bind them
In the Land of World Wide Web where the Shadows lie.
「http リクエストを５０回実行するシェルスクリプトワンライナーをサンプルを表示してほしい。またリクエスト後にhttp レスポンスコードをチェックし500番台だったら実行停止してエラーメッセージを表示するようにしてください。」
ChatGPTにたいして上記の命令からはじめて、１０分くらいの作業時間で動作テストしつつ自然言語のチャットのやりとりでバグを取りつつ非同期実行などの追加仕様を加えてGo言語にリプレイスして出来上がったコードがこれです。
自分でコードはほとんど書いてませんが数行程度の手直しはしました。
注：このコードは結局500番台で全Goルーチン生成抑止/実行停止するわけではないので非同期実行化した際の仕様バグがまだ混入してますが、まあとりあえず動作はします。またGoルーチンを無作為に大量生成してしまうのでこれを抑止するような機能もあった方が良いでしょう。このレベルの仕様バグを解消するには非同期実行時の正しい動作を定義した上であらためて作業した方が手っ取り早そうですがこの文書の目的から外れる作業だし、めんどくさいので放置することにしました。コマンドライン引数周りの細かなバグについても同様です。
【所感】
ChatGPTは平気で嘘つくし、ドメインナレッジにまだ乏しいし、この例だと例えばsyncパッケージ使わない的な単純なバグも平気でしこんでくるのでまだ信用できないやつですが、嘘やバグを見抜ける程度の普通の技術者が監督するなら現時点の水準でも作業量を大幅に削減できるしオーバーテクノロジー感があります。特に小さくて雑なアプリケーションを書いて手法を実証するようなプロトタイピングフェーズなら現時点の技術水準でも大いに役立つでしょう。
我々ITエンジニアは今後１０年くらいのスパンで言うならば課題設定能力、ドメインナレッジの注入、コードレビューの力量とQAの力量、そして役立つアプリケーションが本当に役立つかを実証する能力（ビジネス的？）が問われるようになってくのでしょう。そして最終的には目的の設定と評価のフィードバックループを回し続ける現在のプロダクトマネージャーのようなスキルセットに移行する事になるのでしょう。
YouTuberを始めるにあたって昨日今日と環境構築をしている。
動画のジャンルは内緒として、ひたすら効率良く動画を作ることを志向してる。理想は新規のMarkdownファイルがGitHubのmainブランチにマージされたら自動でYouTubeの自分のチャンネルに動画が投稿される、みたいな状態。
まあそこまでやるのは調べるの大変だし事故とかbanが怖いしまずYouTuberとして大成しないことにはって話なので、どっかで妥協すると思う。てかCI/CD周りちゃんと仕事でやっとけばよかったな。
テキスト読み上げで商用利用するなら今はVOICEVOXが良いのかなと感じた。
ただ、作成した音声に合わせた字幕ファイルを作るのがひたすら面倒くさい。絶対自動出力できそうなのに。
VOICEVOXから直で出してくれたら楽だったんだけど、リップシンク用のファイル出力しか対応してなかった（どっかでやってる人がいるかもしれない）。
VOICEVOX公式のGitHubでissue上げることも考えたけど、俺自身がまだ動画一つも上げてないし、字幕ファイルの需要がどれほどのものかも分からないので、とりあえず変換用のスクリプトを自分で書いてみた。
VOICEVOXのプロジェクトファイルであるvvprojファイルの中身はバイナリではなくただのJSONなので、エディタやエンジンのソースコードを弄らなくても、比較的簡単に字幕ファイルに変換できる。なお今回俺はDenoを使った。
こういうシェルスクリプトみたいな小さい仕事やるのにDenoはまじで楽。
あとは動画作るときに需要ありそうだなと感じたら、SubViewer以外のマークアップに対応させてissue上げるなり俺のrepoに置いとくなりしようかな。
エンジンの実態はhttpサーバーらしいので、上手くやれば意外と労力かけずに理想に近い自動化が実現できるかもしれない。
ごめん、言ってなかった。
このトラバはそもそも別の増田に対する回答だから、自衛隊を軍隊にとか言ってる部分はあなたに対する回答じゃないんだ。
面倒かけて申し訳ないけど、あなたに対する回答になるであろう部分だけを下記に引用するからもう一度読んでみて。
まず加害者である自衛官4人は退職するそうなので、懲戒免職の上で実名を公表して民事ではなく刑事裁判にかけ、民間以上に重い実刑に処して見せしめにする。郡山駐屯地の中隊名を正式に公表する。被害者がハラスメントに限定しないあらゆる違法行為を内部告発するための、警務隊等とは独立していてかつ権力のある窓口を設置する（これは民間等第三者機関でもいいと思う）。
（欠格条項）
第三十八条 次の各号のいずれかに該当する者は、隊員となることができない。
一 禁錮以上の刑に処せられ、その執行を終わるまで又はその執行を受けることがなくなるまでの者
二 法令の規定による懲戒免職の処分を受け、当該処分の日から二年を経過しない者
あらためて読むと第一項第一号と第二号がまじでやばい。門戸広すぎる。
他にもできそうなことは色々ありそう。
俺としては、いまは議論のための認識のすり合わせをしてる段階で、まだ議論は始まってないという認識。
今までのは議論ではない。
あと、
俺のこの問いかけに対する回答は、
ってことで良いのかな。
だとすると、あなたの言っていることについてはちょっと俺も追いきれてなくて、今調べてる最中。
ひとまず現状での俺の認識としては以下の通り。
第二条 この法律において「自衛隊」とは、防衛大臣、防衛副大臣、防衛大臣政務官、防衛大臣補佐官、防衛大臣政策参与及び防衛大臣秘書官並びに防衛省の事務次官及び防衛審議官並びに防衛省本省の内部部局、防衛大学校、防衛医科大学校、防衛会議、統合幕僚監部、情報本部、防衛監察本部、地方防衛局その他の機関（政令で定める合議制の機関並びに防衛省設置法（昭和二十九年法律第百六十四号）第四条第一項第二十四号又は第二十五号に掲げる事務をつかさどる部局及び職で政令で定めるものを除く。）並びに陸上自衛隊、海上自衛隊及び航空自衛隊並びに防衛装備庁（政令で定める合議制の機関を除く。）を含むものとする。
とある。
で、件の被害者の方は2022年9月9日8月31日（修正）に防衛省を訪れた際、再調査を求める署名を「木村次郎防衛大臣政務官」に提出している。
https://sdp.or.jp/sdp-paper/gonoi/
https://www.kantei.go.jp/jp/101_kishida/meibo/seimukan/kimura_jiro.html
自衛隊法に則ると、当の「防衛大臣政務官」はもとより、防衛省トップである「防衛大臣」すら自衛隊ということになる。
これ、現役自衛官だった頃に座学で学んでるはずなんだけど、全然覚えてない。その時は俺も政治に興味がなかったのでスルーしたのかもしれない。
http://www.clearing.mod.go.jp/kunrei_data/a_fd/1959/ax19591216_00061_000.pdf
これらを総合すると、俺の主張する
被害者がハラスメントに限定しないあらゆる違法行為を内部告発するための、警務隊等とは独立していてかつ権力のある窓口を設置する（これは民間等第三者機関でもいいと思う）
オレオレ、俺だよ。
厳密には俺の主張の帰結としては反論ではなく、元増田の情報不足に対する補足なんだけど、これは俺がそうとも読める書き方をしたのが悪いな。
「この増田の主張を前提に」俺から言わせれば、ごく稀だからこそ、取り上げることに意味がある。
俺の主張の一番重要なところは、「人間が警備する限り、起こらないってことはないでしょ」ということ。
そこを
とシチュエーションを限定して書いてしまったところは俺の反省するところだけれども。実際他の増田にツッコまれたし。
「例外的事象」については、元増田の主張を前提の発言ととればまあ、「俺は」理解できなくもない。
ただ、少なくとも明石の事故の当事者にとっては例外的事象ではないだろ？
元増田や擁護した増田についたブクマカの中にも、当事者として明石の事故に言及した人たちがいるかもしれない。
その当事者たちは、明石の事故の経験によって、元増田の主張する「雑踏事故を甘く見過ぎてはいけない」ということを身をもって知ったわけだろ？
そんななかで明石の事故を例外的事象として捉えてしまって良いのか？
んでもって、「ごく稀」とはどれくらいだ？
どれくらいの期間のうちどれくらいの件数であれば、「この増田にとって」「ごく稀」であると言える？
よく言われることだし、元増田の
の「まず」にも係るけれども、曖昧な言葉遣いは、読み手側に書き手側の意図しない解釈を与えやすく、批判の糸口になりやすいから気をつけた方がいいよ。自戒を込めて。
さて、ここでまた、このやさしく暇をもてあました俺がこの増田の代わりにちょっとだけ調べてあげよう。
まず、当初俺は「雑踏事故」というワードで調べたのだけど、「群集事故」という呼び方もされているようだ。
https://ja.m.wikipedia.org/wiki/群集事故
ここに書かれている内容に元増田の主張と齟齬があるようには感じられなかったので、以下群集事故を調べることにする。
調べた限り、一番事例が載っていたのはこれ。
https://www.wikiwand.com/ja/事故の一覧#群集事故
で、元増田は1972年以降の事例を（宇崎ちゃん以外に）挙げていないので、
の条件で絞り込んで拾い上げると、2001年の明石の事故までに少なくとも2件起きている。
一つずつ挙げていく。
Wikipediaには項目がなかったが、昭和54年の警察白書に事例として記載がある。
https://www.npa.go.jp/hakusyo/s54/s540800.html
ただし、警察が事故の起きた当時警備業務に関わっていたか、事前にコンサートの概要を把握していたかは読み取れない。以下白書より引用。
1月、札幌中島スポーツセンターで開催されたイギリスのロックバンド「ブラックモアーズ・レインボー」ショーで、興奮した観客約500人が開演と同時にステージに殺到し、このため、いすにつまづいて倒れた観客が将棋倒しとなり、下敷きとなった1人が死亡、7人が負傷した
https://ja.m.wikipedia.org/wiki/ラフィンノーズ公演雑踏事故
この公演に3000人の観客が集まり開演と同時に観客がステージ近くにまで駆け寄り演奏に興奮した一部の観客がステージに上がろうとし、それに続こうとした後続の観客が重なるようにして転倒・下敷きになったのが原因であった。この事故で死者3人・重傷1人・軽傷19人の計23人が被害に遭った[要出典]。主催者は公演前日に警察署に届出をしたが、当日は主催者スタッフのみで警備員の配置を全くしていなかったことも事故を増幅させた。
これは当時の音楽ファンの間では有名な事故みたいなんだけど、情報源を探すのに苦労した。
https://aucview.aucfan.com/yahoo/s1053964729/#&gid=1&pid=3
ちょっと目を通すだけでも、Wikipediaの記述と相違があるように見受けられる。速報だからかも知れないけど。
ことが辛うじて読み取れる。
本件に関するこれ以上の調査は図書館行って当時の新聞を読み漁る必要があり、こもりびとである俺の行動できる範疇を超える。誰か調べてちょ。
らしい。
その要綱の内容は、やっぱり探すのに苦労した。Wikipedia記載の警察庁への外部リンクはhttpでリンク切れになっていて、httpsにしてみてもnot foundだった。
代わりに見つけてきたのは↓。栃木県警が上記の要綱を受けて、内部通達した資料と思われる。
https://www.pref.tochigi.lg.jp/keisatu/n15/jourei/documents/11_2.pdf
一応、時期的にも内容的にも一致しているように見える。
詳細は各自で読んで欲しいし、俺も全文はさすがに読んでないんだけど、要綱の
警察は、施設使用公演等に伴う雑踏事故の防止対策に資するため、これら事故の過去における発生実態及び原因等の分析を行うとともに、タレント等の人気度、観客層の構成等の実態について、平素から把握に努めるものとする。
という記述をみるに、この事故は、その発生以前と以後で警察の雑踏事故に対する態度が変わったという意味で、取り扱っても良い事例かもしれない。
に、
がこの時点で加わったわけだ。
元増田は主に戦後日本の雑踏警備について話しているので、ここでは戦後（1945年以降）に限って話を進める。
群集事故件数の年次推移的な資料を探したのだけどなかなか見つからなかったので、ここは妥協して「報道されるほどの被害をもたらした事故」に限るとし、先ほどの群集事故の一覧で数えることにする。
自分で数えた限り、1945年から現在までの80年弱で、日本では明石の事故含め21件ほどの群集事故が起きている。
明石の事故の前後は、前は先述の1987年ラフィンノーズ公演雑踏事故、後は2003年の中日阪神戦でのファン乱入・乱闘騒ぎ。
ちなみに後者では死者は出なかったものの、誰が使ったか知らないが防犯用の催涙スプレーが使われたとある。なんでや阪神関係あるかわからへんやろ。
んでもって、1945年以降1972年までの28年間に13件、1973年以降現在までの50年間に8件。
当然、
といった点は考慮すべきではある。
けれども俺としては、明石の事故がというよりは、報道されるほどの被害をもたらす日本の雑踏事故自体が、数年に1〜2回程度しか発生しないという印象を持つに至った。
大きな事故は、数年に1〜2回程度。
だからこそ、恐らく雑踏警備は難しい。
ラフィンノーズ公演雑踏事故の教訓を受けて、「常日頃から情報収集に努める」という要綱を施行した14年後に、明石の事故が起きた。
そしてその主たる原因は、過去のイベントの警備計画をほぼ流用した警察らの怠慢にあった。
その14年間に色々なことがあったであろうことを隅に置いて物事を単純に捉えると、明石の事故の当事者の方々には大変申し訳なく思いつつも、警察のこの失敗に共感してしまう自分がいる。
もし俺が雑踏警備を主たる業務とする警察官（仮定が成立するかは知らん）で、5年も10年も雑踏事故が起きなかったら、全てではないにしてもいくつかの雑踏警備に手を抜いてしまう可能性を否定できない。俺怠け者だし。
長期にわたって怠慢に抗うのは、少なくとも俺にとっては、とても難しい。
おわり。
https://anond.hatelabo.jp/20221002090419
↑の元増田です。
トラバでやり取りしてるうちに、
と言われたので、こいつめんどくせー！と思いつつ、調べたよもー。
（どうでもいいけどhttpなんだね。ロシアってそういうサイト多いのかな？）
（2022-10-19 12:46 追記。今日のロシアにおけるインターネット事情を踏まえ、プーチン演説全文の外部リンクは削除した。各自自己責任の上で探して欲しい）
で、「核兵器使用の前例」に関して述べたと思われる箇所はここ。
США – единственная страна в мире, дважды применившая ядерное оружие, уничтожив японские города Хиросиму и Нагасаки. Кстати говоря, создали прецедент.
えっと、最後の単語прецедентが日本語訳で「前例」に当たるんだけど、Google翻訳によれば古フランス語が語源。
実際прецедентの発音は英語のprecedentに割と近い。
https://www.google.com/search?q=precede+meaning
late Middle English: from Old French preceder, from Latin praecedere, from prae ‘before’ + cedere ‘go’.
とある。
何せ公式が既にWebの海に放流した文章なので、仮に多少演説原文とはニュアンスが違ってロシアから「ちがうそうじゃない」と言われても「いや、あんた英語でこう書いてるんやから」で通るだろう。
また、世界的に言えばこちらの方が読まれる回数は多いのではとも思われる。
個人的に英語の方がまだ読めるという事情もあり、当初の予定とはズレるけれども、英語訳の方を読んでみることにした。
さて。
下記が上記の原文と同じ箇所。
The United States is the only country in the world that has used nuclear weapons twice, destroying the cities of Hiroshima and Nagasaki in Japan. And they created a precedent.
ちなみに、原文・英文ともに引用部分で一つのパラグラフになっている。
ここでまず、precedentを目的語に取る単語としてcreateが使われていることと、precedentの冠詞としてaがついていることがちょっと気になった。
特に後者については、さっと調べてみるとロシア語には冠詞がないそうなので、原文と英文でささいなニュアンスの違いが生まれるかもしれない。
https://www.google.com/search?q=create+meaning&oq=create+meaning
ま、普通に考えて
ということでいいだろう。
https://www.google.com/search?q=precedent+meaning&oq=precedent
これもまあ、普通に
an earlier event or action that is regarded as an example or guide to be considered in subsequent similar circumstances.
ということだろうな。
ていうか、ここまで長々と書いたけど、引用文をパッと見ても単語の定義調べた上でためつすがめつ見ても、俺には「お前が最初にやったんだから"誰か"がそれに続いても文句言えめえ？」と言ってる様にしか読めない。
「その"誰か"はロシアである」とこの文から決めつけるのはさすがに難癖かと思うものの、発言の責任はやっぱりロシアにあるので、俺の主張は変わらないかな。
みんなはどう思うだろうか？
ちなみに、直後の文では
Recall that during WWII the United States and Britain reduced Dresden, Hamburg, Cologne and many other German cities to rubble, without the least military necessity. It was done ostentatiously and, to repeat, without any military necessity. They had only one goal, as with the nuclear bombing of Japanese cities: to intimidate our country and the rest of the world.
と言ってる。
実はほとんど読んでないんだよね。
若手から中堅、シニアに至るまでみんな「プログラマーになりたい」と言っているのだが
現実問題としてそんなに簡単になれるものではない、というのを知っておいて欲しい
算数や国語は長い歴史の中で様々な試行錯誤が行われ、どのように教えれば大半の人が知識獲得できるかという方法論が確立されてきている
もちろんまだまだ改善の余地はあるが「こういう教え方が良い」というのがちゃんとある
ところがプログラミングに関してはまだまだ歴史が浅く、どのように教育すればプログラマーになれるかが分かっていない
幼少期からC言語を教えるのか、Scratchでいいのか、Pythonがいいのか、何も分かっていない
今のプログラマー達は生存者バイアスでしかないので体験談は全然アテにならない
何かしらそれっぽい理論が発表されてたりもするがエビデンスに欠けるモノが多くてまだまだ研究中という感じだ
そんな感じなので「実際に書いてみるのがいい」「業務で使いながら覚える」「写経するのが良い」などなどいろんな方法論が乱立している
あなたがプログラミングを勉強し始めると「教え方が良くない」「本が役に立たない」となることを覚悟してほしいし
勉強法をトライアンドエラーで繰り返していくことになるので技能獲得には相当な時間がかかる
PythonでもJavaScriptでもメモリのアロケーションのような計算機的知識が必要とされる
みたいに言われることも多いが実際にはそんなことはなく、ちょっとしたバグを引いたときにでもその手の知識が必要になる
もちろん昔に比べれば非常に楽になったが全くゼロでいい訳では無い
同様にクラウドリソースを使うときにTCP/IPを全く知らなくて良いか、と言われるとそうでもない
GraphQL使うときにHTTPの知識が全くいらないわけではないように
プログラミングでは下手するとWiFiやLTE/5Gの知識まで必要とされる
これは例えば建築関係においても同様で、家を建てる人にはコンクリートの基礎知識が必要だったり木材に関する基礎知識が必要だったりするのだが
歴史が古い分野では教育法が確立されているので建築学科なりに行けばキッチリ教えてくれる
同様に情報系の学部に行けば教えてくれるが、大学による差がかなり大きいし、体系化されているわけではない
Word, Excelの使い方を中心に教えるような大学もあれば情報理論から教えるような大学もあるし
それのどちらが良いかは誰も分かっていない
オンラインビデオで有名大学の授業を見ることもできるが、質問はできないので分からないところがあれば終わりだ
なので大学に行ったとしてもいろんな授業を受けてトライアンドエラーで長い時間をかけて技能獲得する必要がある
「Python検定1級」みたいなのが乱立しているがはっきり言って役に立たない
しかも「Python検定1級取得のための集中研修」みたいなのもあって地獄みがある
問題を解くための知識だけを得たところで前述した前提知識がないと実務で役に立たない
プログラマーを雇う側はその手のことをよく知っているので、こういった資格は全く考慮に入れていない
TOEICや英検のように「実務ではあんまり役に立たないんだけどな」と思われてる資格であっても社会的にコンセンサスが取れていればそれなりに役に立つが
プログラミングに関してはそういった資格がない状態である（IPAはそれなりに信頼されているが、取って無いから落とすようなことはない）
この英語における「TOEICがない」状態で困るのは効果測定である
プログラミングを勉強しても自分が成長しているのかどうかを客観的に知る方法が無いので独学で学んでも役に立つかどうか分からない
オープンソースに携わったり業務経験などを経て長い時間をかけて「プログラミングができるようになってきた」となるので1，2年でさっさとプログラマーになることはできない
一番の近道は旧帝大の院に入学して2年間キッチリ勉強すればそれなりのプログラマーになれる
もちろんスタートラインなのでそこから業務経験を身につける必要がある
なので旧帝大の院に入れないような人はプログラマーとしての前提知識を得るための前提知識がそもそも足りていない
独学でやるなら近道は一切無いので5年ぐらいは覚悟した方が良いと思う
