  |
はてなキーワード: スタックオーバーフローとは
で疑問なんだけど、これ、企業・団体や個人の人脈、固定ファンを持ってない人の記事ってどういう導線があるの？
ホームもトレンドも半分以上がオーガナイゼーション所属か見覚えあるアイコン。
企業系はもう身内でいいねだかLGTMだかを押し合って押し上げる印象しかないし。
有象無象の投稿者に一見さんが訪れるのはせいぜいアドカレ？年末だけか。
Qiitaって今、盛り上がってるのか…？
https://qiita.com/Qiita/items/75a34af032d898a86679
ひとつもストックされない記事がどれぐらい埋没してることやら。
覗いたついでに一個記事を上げてみたけど、初日の閲覧数100前半で止まった。
読み物でもなく需要・トレンドがあるわけでもない記事だけど100人ぐらいにしかクリックすらしてもらえないんだな。
数年前の3いいねぐらいの記事でも5～7000viewぐらいあってクローラーだとかの細かい積み重ねにしてもひどい頭打ちね。
今、ゼロからQiitaに投稿していこうってエンジニアは何をモチベに投稿し何かしらモチベになるものを受け取れているのか…？
まあ、Qiitaはもう昔から内輪で回す閉じたコンテンツだっていうバイアスをかけてるからそう見えている可能性が高い。
QiitaとかZenとか日本語版スタックオーバーフローとかteratailとか、ここらへんのコミュニティの環境を定期的に解説してくれる人いないかなぁ。空気感とかこんな出来事があってこんな風になったよとか。
下世話すぎるか。
おまんこって、人口の約50パーに「お」がつくって考えたら、すごいよね。それはさておき、スタックオーバーフローの説明は「いちまんこ」のコピペがすき。
いちまんこ
先日ふと、マンコの数が気になったので数えてみることにした。
http://hemon.net/fear/copy/%e3%81%84%e3%81%a1%e3%81%be%e3%82%93%e3%81%93.html
25年くらい前になるかな。パチンコ・パチスロを辞めてから20年以上立つので、ここに書くのは全部昔の話。今どうなってるかは殆ど知らない。
自分はいわゆる「学生プロ」というようなもので、大学院での研究をしながら月に10万くらいパチンコ・パチスロで稼いでいた。朝まで研究室にいて、モーニング打って寝て、なんて生活をしたりしてた。今ほどネットが発達してなかったので、情報源の大半はパチンコ雑誌、パチスロ雑誌だった。数多くあった雑誌の大半は「オカルト系」と呼ばれるもので、「大当たりを狙う撃ち方」というような科学的根拠のない記事が並んでいたが、その中でも「パチンコ必勝ガイド」と「パチンコ攻略マガジン」の2誌だけは、科学的根拠がしっかりした記事を中心としていて、毎号買っては丹念に読んでいた。
当時は「合法として運用されている違法？連チャン機」の全盛期だった。これは「保通協」という「パチンコ屋のホールで稼働していい機種かどうかを検査する機関」（後の仕事で、保通協はパチンコ以外にもいろんな業務をしてることを知るが、それはおいておく）で検査されるときは、申請通りのスペックで動作するが、実際のホールで稼働するとなぜか連チャンしてしまう機種のことだ。上述の2誌は、この「検査時はおとなしいが実稼働では連チャンしてしまう」仕組みについての調査を行い、雑誌に情報を掲載していた。
調査では実機を入手し...と思いきや、なぜか「ROMだけ先行入手できました」というケースも多く、パチンコ台メーカーによっては、ROMプログラム解析だけで「定番のスタックオーバーフローでの保留玉の抽選値書き換えパターンでした」というわかりやすいものもあったりした。メーカー毎に連チャンの仕掛けの癖があって、ROMプログラムだけで挙動がわかるようなメーカーもあれば、「実機を入手してICE使って解析してもその仕組がわからない」という技巧派メーカーもあったようだ。この記事の「春一番」を作ったのは、「西陣」という技巧派タイプのメーカーだった。ちなみに「実稼働で暴れる」という実態に業を煮やした当局は、当時一般的だったCPU「Z80」の使用を事実上禁止にし、そのためにICEも使えなくなったりしたようだが、それはこの記事よりも後の話。
さて、春一番の連チャンの仕組みが始めて雑誌に出たのは、恐らく「パチンコ必勝ガイド」の方だったと思う。その内容はこんな感じだった。それまでのホールでの実プレイでの検証から「連チャンは保留玉に限らず発生する」というものだった。そこから「大当たり後、一定の確率で連チャンモードに入り、連チャンモードであれば高い確率で当たりをひく」までは想定されていた。実機のプログラム検証の結果、この機種は0,1,2,3,0,1,2,3...とサイクリックに値を刻み続ける「連チャンカウンター」があり、大当たりの終了のタイミングでこのカウンターが、とある値（3だったかな）であれば、連チャンモードになり、保留玉〜20回転くらいで当たる、そうでなければ通常モードになる。
そして衝撃的だったのが、「この連チャンカウンターの値は狙える」というものだった。大当たりの終了タイミングは、アタッカー（デジパチで大当たりしたときだけ開くところ）の開閉の最終ラウンド（＝16ラウンド）の最後の玉（＝10個目）がセンサーに感知されたタイミング次第、となる。連チャンカウンターのサイクルが秒とか数秒であればまだしも、カウンター自体は比較的高速だったので、このタイミングを狙うのは現実的に不可能だ（そもそもタイミングを狙う指標もない）。
普通ならここで諦めるとこだろうが、雑誌の記事では現実的な攻略法が書いてあった。デジパチのアタッカーは10個目の玉を検知するとアタッカーが閉じて、次のラウンドに進むが（16ラウンド終了したら、大当たり終了）、タイムアウトまで10個入らない場合にもアタッカーが閉じる。このタイムアウトが正確（恐らく29.8秒、とかだったと思う）かつ連チャンカウンターと同期しているのを利用して、「ある条件に当てはまったら、以後のラウンドですべてタイムアウトを発生させると、連チャンモードが確定」ということが判明した。その「ある条件」は、大当たり画面のとある場面の切り替わりの瞬間が、大当たりBGMの四拍子のどのタイミング（拍子）か、というものだった。それも固定のタイミングではなく、大当たり前の４つの状態（とあるLED表示パターンで簡単にわかる）と大当たり後の４つの状態（これも同じLED）と16ラウンドの組み合わせで決まるため、単純には4x4x16=256通りの基準タイミングでの判定となる。
雑誌の記事を理解したとたんに「これは本当に使える攻略法だ！」と思い、春一番が設置してあるホールに出向いて試してみた。何回かやってみると、うまくいくケースもあるのだが、「タイミングは完璧なはずなのに、連チャンしない」というのもいくつかあった。「…これは雑誌の説明はあっているが、タイミングの表の数値が部分的に間違っている！」。翌号の記事で訂正記事が出るかな？と思ったものの特に何もコメントはなかったのだが、自分の推測は確信していたので、やれることは「自力で数値を修正する」だった。
そこからしばらく、「正しい数値はどれか」と「間違っているなら何が正しい数値か」の検証を進めていき、数値の修正が進むにつれて、連チャンを狙える率もちょっとずつ上がっていった。その作業のさなかに出た雑誌（最初の記事の翌々号）に「すいません！数値が間違ってました！」という訂正記事が載る。自分の検証と照らし合わせてみると、ほとんどが思ったような訂正になっていた。「こいつはそのまま使える！」。自分の数値は「実機で検証した推測値」だが、雑誌は「解析で計算した本当の値」なため、雑誌の数値の威力はやはり絶大で、条件さえよければ100%連チャンが狙えるレベルになった。
この「条件さえよければ」だが、実はこの攻略法が使えるには、いくつかの条件がある。まず絶対に欠かせない条件としては「大当たりのBGMがなってること」だ。BGMのタイミングで判定をする以上、これが鳴ってないと全く手が出ない。全く鳴らないホールはないのだが、音量の大小は様々だった。次は「ホールが騒がしすぎないこと」。BGMがはっきり聞これば聞こえるほど、成功率は上がる。逆に騒がしいホールでBGMが辛うじて聞こえるようなときは、わずかに聞こえるBGMからタイミングを検出する「人間相関検出器」状態になる。最後は「店員のチェックが甘いこと」。「ここから先、アタッカーに10個目の玉を入れずに29.8秒経過させる」というのは、やるのは簡単なのだが、実際にやると、「大当たりしているのに玉を打たない」という非常に不自然な状況になる。アタッカーにはほとんどの玉が入るようにできているので、普通に打つと10個の玉が入るのに10秒もかからない。そのため20秒以上は「玉を止める」ことが必要になる。やってることは合法なのだが、店には「特定の打ち方をしている客を追い出す権利」があるので、「何かやってる」と悟られた時点で終わりだ。そして店員に限らず、周囲の客に「何かやってる（から連チャンしている）」と悟られるのも同様にやばい。とにかく、条件にあてはまって「以後はタイムアウト発生させる」となったら、アタッカーが開いてもすぐには玉を打たずに、店員が通ったり、客がこっちを見てそうなタイミングだけ玉を打つ（そして9個で止める）、としていった。
こうして、その気になれば何十万、あるいは何百万も稼ぐことは可能な状態になったが、「バレたら終わり」なので、なるべく目立たないように勝ち続けた。「お兄ちゃん調子いいねー」「今日は調子いいっすねー（毎度調子いいだんけどな）」てな感じで、数ヶ月は稼ぎ続けたと思う。エンジニア、あるいはゲーマーにとっては理解しやすく、攻略もできる内容だったが、世間的には使っている人は全くいない感じだった。とはいえ、さすがに終わりはあって、いつも通っている店にも情報がやってきたのか、ある日「そういう撃ち方やめてもらえますか？」とやんわり言われ、「はい、わかりましたー」と快諾して、その店は終了となった。
「こうなったら市内中のパチンコ屋で最後のひと稼ぎするか」となったものの、この攻略の「もう１つの難点」をどうにかしたくなった。その難点は「最初の当たりは自力で当てないといけない」というものだ。普段なら「当たるまでじっくり待つか」でいいのだが、今回のように「残り時間が少ない」となると、そうも言っていられない。そこで誰かと一緒に行って、稼ぎを2倍3倍にすることを考えた。とにかくこっちには攻略法がある。負けるわけがない。なので「負けたら全額出す。勝ったら折半」という条件で友人を誘い出した。
実際に打ち始めると、その友人にあたりが来る。隣の台だが、画面を（さりげなく）ガン見してBGMも集中して聞く...「条件にハマった！ここからラウンド9個で止める！」と指示するものの、残念ながら普通の人は練習もなしにそういうプレイができたりはしないらしい。数回やってみて路線を変えることにした。当たったら打つのを交代する。どうせ勝ち分は折半するのだから、文句も全く言われない。これで2週間くらいにいろんな店をまわり、友人を誘ってやった会は負け知らず（一人で打っても、よほど運が悪くない限りは負けない）だった。
そんな「最後のひと稼ぎ」をしているある日のこと。比較的寂れた系のホールで打っていて、打っている客は島の中で自分と背中側の斜めに一人か二人、という状況だった。しばらく打っていると、その背中の人が大当たりをひいた。自分の台ではないのだが、自然と「1,2,3,4,1,2,3,4...」とBGMを追ってしまう。「あの台の状態は〇〇だったから、このラウンドでは2.5泊だったら当たりだな...おっ、条件にあてはまった。ここで止めれば」と思ってところに、打ち方をラウンドでの9個止めプレイに変わった（！）。
…今思えば、その人に声かけとけばよかったなー。
プログラミング独学の初心者はほぼ必ずどこかで詰まると思いますが、そういう時はYahoo! 知恵袋やTeratail、少し敷居は高いけれどスタックオーバーフロー日本版などを使ってみると良いと思います。（人力検索は死んだんだよね？）
質問サイトには、承認欲求に呑まれて出られなくなった教えたがりさんが大量にいるので、プログラミング初心者が何か質問をしたいな、と思った際はそういう場所でしてみるといいかと思います。
タイトル「(プログラミング言語)で(やりたいこと)が出来ません」
内容「(OS、WindowsとかMacとか)の(プログラミング言語かフレームワーク)で(やりたいこと)がしたいのですが、(動きません or エラーが出ます)。
(書いたコード、行ったこと)は(コードややったことを"出来る限りそのまま"書く)、エラーの内容は、(エラーの内容を"完全にそのまま"貼る、翻訳したり要約したりしない)です。解決方法をご教授ください。」
という感じでいいと思います。足りない情報があれば多分向こうから聞いてくるので。
同じようなエラーが起きている人がいないか質問サイトで検索するのも良いと思います。(質問する前にやっておくのはマナーでもある、ただ探して見つからないものは仕方ないので大人しく質問するべし)
GoogleStudyJamで機械学習をやりながら、俺は今雰囲気でBigQueryに触っていると呟いてから一ヶ月、やっとTシャツが届いた。
CodeJam以来だから十年近くあいての二枚目のグーグルシャツである。
胸にTensor Flowのロゴがちょんと載ってる。先日いただいたスタックオーバーフローのTシャツとどこか少し被ってる感じを受けたのは気のせいだ。
それはそうと材質はかなり良い。プリントTシャツとしては高級に近いものが送られてきた。なんたって縫製が丸胴である。縫い方が違う。側面に縫い目がないそれは表裏を大きく使えることから大胆なデザインをTシャツというまな板に広げることができるのだ。なのにロゴはつつましく左胸にあるだけ。シャツという名の自由を許されたキャンバスの大きな無駄遣いである。
今回はコードジャムなんかと違って参加条件はゆるゆるだ。機械学習のラーニングを4つ以上受けるだけ。参加したら確実に貰えるであろう。その参加者にこんなTシャツを送るとは。。
大量発注でも単価は500円は硬いはずである。割と大々的に発表してたし参加者は１万人以上は硬いだろう…グーグルの資金力を目の当たりにしてしまった。レッドハットのTシャツなんて一度も貰えたことないのに！（ほしい）
送り主は未だ六本木ヒルズタワー44階であった。そうか渋谷にお帰りになるのはまだ先か……森ビルに務める知人が40f以上に行くエレベーターの中でゴールドマン・サックスとグーグルの人と一緒になるの嫌だーっとぼやいていたがそれももうすぐである。
スタックオーバーフローのユーザー会に行ってきた。Tシャツ目当てで。
メタな話は、正直あの界隈の人たち好きじゃないので興味なかったのだけど、
同じように一般参加した人がstackoverflowに質問した内容やそれを自己解決した経緯を聞くのは楽しかった。
エンジニアだったら、なんかの問題に躓いて、死ぬほどリファレンス読み込んで解決できなくて
神にもすがる思いで誰か…同僚だったり、SOだったり、GitHubに頼った経験はあると思う。
同僚に事象を説明していたら、環境差分に気づいてスルスルっと解決しちゃった体験。
サンドバッグになってありがとうといつも優しい同僚に言っていたが、最近ラバーダッキングというちゃんとした名前があることを知った。
長ったらしいエラーログから特徴的な文言を抜き出して、ググった先がGithubのissueで。
英語で続くよくわからない会話についた絵文字のGJを頼りにフィックスして結局直ってねーじゃんと失望するような体験。
kubernetesを見るがいい。よくわからないbotが90日後にやってきて勝手にissueをcloseしていくぞ。
そんな中で、技術者として真だなと思うのが技術的に解決方法を自分で見つけた人。隣の人から聞いたのはそんな話だ。
macのドック(下にあるアプリケーションのローンチバー)から消したアプリアイコンが、電源入れるたびにゾンビのように復活するので調べたら
osのバージョンアップ用プロセスがdockの配置を定義している静的ファイルを操作して勝手に元に戻していたことがわかったらしい。
osのバージョンアップ用プロセスがリブートで必ず動くことへの対応は見つけられなかったけど、事象と対症療法は何とか見つかったよとのこと。
正直かっこええなと思う。
システムのアーキテクチャがわかってて深い理解があって初めて可能になるような。
こんな方法はベンダーのマニュアルにも、どの教本にも載ってはいない。しかし、可能ではある。システム全体に対する深い知識と理解と応用力があれば。
EGFﾏﾀﾞｰ?といつも呟いている自分は、EGコンバットでいつEMPバラージにあってもいいように備えている。
そんな中、CVE-2018-1002105 の issue を読んで kube-apiserver に詳しくなろう！
は今、「kubernetes the hard way on azure」をやってて最初のCIDRによるネットワークの分割は、lucidchartでお絵描きまでして頑張ったのに
kubeconfigファイルの作成あたりは無の境地になって、。。。はっと、なんか不安になってきた自分に強くささった。
「kube-apiserver がリバースプロキシとして動作する」こともあるというアーキテクチャの理解をベースに脆弱性情報がこうやって発展するのか...みたいな。
震えるほどかっこええなと思う。
知識の深堀のために、SOが発展していけたら。そんなことを思う。
