 
|
はてなキーワード: エラーメッセージとは
はてな匿名ダイアリーを見て思った、最速でプログラミング言語を覚える為の10か条。
最初に覚える言語は、目的が明確でない場合はJavaかPythonを推奨する。言語仕様が簡潔で、資料が豊富で、応用範囲が比較的広い。
ペロペロ
1. htmlのはき出しがあるやつは?>を書いたほうがいいよ。それ以外は最近はかないのがはやりだねさらに昔はevalとかで書いてた
2. configこれはwwwやpublic_html以下にしかconfigを配置できないクソサーバーがあるので、phpにしておいたほうが安全。なぜなら丸見えにしてあれこれパスをさらけ出すバカがいるかもしれないからだ。オープンソースなら特に。
3. コメントは挨拶だ。必要以上に挨拶を繰り返す必要もないし、それ以上でも以下でもない。
4. eclipseのせいと、phpとかが出始めたころのコーディング規約がスペースにするように求めた。{を改行してから書くか、続けて書くかのこれは宗教戦争だ。だが正直スペースは気に食わない。LLのくせに何バイトつかってるのだとおもう。あとスペース２文字インデントのやつは旅立て！
5. phpの0と""の違いは緩すぎる。そういう意味でナンバーの取り扱いにだけは気を配るべきだ。あとはtmpでもbufでもretでもなんでもいい。
6. nullはつっこむな、nullで初期化はすんな。初期化されてないからnullなんだ。issetは有効につかえ。とくに$_系の変数
7. 本当はerrorprocをかけといいたいがLLにそこまで望んでもしゃーない。エラーを投げると鯖ログにまで場合によっては落ちたりしてやっかいだからfalseを返せばいいというものでもないが、trueで初期化するやつは滅びていいと思う。あとarrayを返すようなfunctionの場合、phpのなんだっけisarray?だっけ？がクソすぎて萎える
8. つかダブルクオートのなかに$を書くコードは滅びていい。コンストはすべて大文字でという昔ながらのルールだけ守ってくれればいい
9. 出力系のラップ関数ぐらいつくっておこうぜ。あと、var_dumpとかのほうが見やすい。あと、get_defined_varsとかをラップしておくと便利
10. 三項演算子はつかうな。ifの{}を略すな。可読性がおちるのとしんたっくすで原因の特定がめんどくさい。
12. ++iなんていうコードを書くな。あと、roopの条件文で計算すんな
13. むしろこういうのは文字列の連結以外で使うようなスチュエーションをつくっちゃだめ
14. あら上で言っちゃったよ。ここまでやるんだったらlogファイルに吐き出すところまで拡張しとけば?
15. んー。エラーメッセージを定数化するときは外国版をつくるあてまである時だけだな
16. これも上でいってしまったな。あとリロードされてもいいように初期化でクリアしておくといいぞ。
17. ああそうだな、関数が１スクロールに収まらないときは大抵正規化に失敗してる。つくりをみなおせ
18. えー、こんな風に書くのはどうかしている。public二つチェインで呼び出すぐらいなら、内部でprivateを呼び出すか、継承させてparentにしておくべきか、それともシステムとして共通のstaticで呼び出せるかにしてくほうがいいのでは？$this->setThis()でいいじゃないか。なぜpublic functionをそういくつも定義する必要がある？ 外部からの入り口出口は絞れ
19. グローバルなラッピング関数は最低限にとどめるべきで他は機能ごとにクラスつくってメソッド化しとけ。p(var)じゃねぇよDEBUG::p(var)とかにしとけってことだ
20. 眠くなったからねる。つまりはそんなもんだってことだ。気に病むな。満足してもらえるもんをしっかりつくればいいだけだ
カードの期限が切れるほど入荷に長い時間かけたのはamazonだが
まあここまではいいさ。
素直に更新した新しいカードの情報を登録しようとしたら、アカウントサービスが言うことを効かない。
システムのメッセージで何故か「カードの情報がおかしい」と言われる。
で、
「こんな出てるけど何。新しいカードは絶対生きてるしミスタイプもしてないよ（要約）」とサポートにメールを送ったら
「カードの情報がおかしいからキャンセルしてもう一回注文してくれ（要約）」と返答が来た。
お前それ、エラーメッセージそのまま読んでるだけじゃねえかと。
「それのどこがサポートだボケ！真面目にやれ！（要約）」と送ったら、今度は
「住所情報が正しくないからカードも無効になってる、手続きして直してくだちい（要約）」とかわけのわからないこと言う。
俺は間違った住所なんかamazonアカウントに入れてないし、長年同じ住所に送ってもらってる。
もう意味がさっぱりわからんけど、すでに入ってるのと同じ自宅の住所を入れなおした。
そしたらカードの情報も登録できたので、意味がさっぱりわからんけどまあ解決らしい。
「キャンセルするならここから手続きしてくれ」なんつーメールがきやがった！
じゃあお前、面倒なメール往復して支払い情報登録したのはなんだったんだよ！
だいたい「商品が入荷して発送準備段階に入った」って言ってたよな！？
その商品どこやったんだよ！この数日の間にキープしないで売っちゃったのか！
それとも元から入荷って言うのが嘘だったのか！
前にもおんなじことがあって、
その時はコンビニ支払いを指定してたので
なんなんだこれ？
アマゾンて販売部門は優秀だろうしとっても便利だけど
サポート部門は小学校低学年と文通してるみたいな気分にさせてくれる。
１回だけならたまたまだと思ったが、１回じゃない。
Messenger - 「この kids passport アカウントでは windows messenger はご利用なれません」
なんだこれは！俺をガキ扱いする気か！
http://help.jp.msn.com/announce.aspx#20090907_Mess
平素より、Windows Live サービスをご利用いただき、誠にありがとうございます。
現在、下記のエラーメッセージが表示されてWindows Messenger (*1) に
サインインできない現象が発生しており、ご不便をおかけしております。
(*1 Live Messenger と互換性はございますが別のプログラムとなります。)
＜ エラーメッセージ ＞
この kids passport アカウントでは windows messenger はご利用なれません。
kids passport の詳細および両親の同意の必要については
複数のお客様より、別の Windows Live ID アカウントでは
Windows Messenger にサインインができる報告をいただいておりますため、
Windows Live ID アカウント登録情報に起因した問題であるか
当 Windows Live サービス担当部署にて総力をあげ、調査を行っております。
お客様には、しばらくの間ご迷惑をおかけいたしますが、
調査が完了するまで、お待ちくださいますようお願い申し上げます。
一時的な回避策とはなりますが、改善まで別 Windows Live IDアカウントの
ご併用を検討いただけますと幸いでございます。
＜Windows Live IDアカウント新規登録方法＞
1. http://hotmail.com/ にアクセスします。
2. [新規登録] をクリックします。
3. 必要な項目をご入力ください。
お客様にはご不便おかけし、申し訳ございませんが、
ご理解いただきますよう何卒お願い申し上げます。
[2009.09.07 掲載]
もう1ヶ月半経ってるぞ－。
いや、実際にはもっとあるんだろうけど。 つっこみよろしく。
(1)(2) →アドレス帳に登録して相手の名前が表示されているため、メールアドレスの間違いに気がつかない。
(3) →送信者にエラーコードは帰ってきているが、送信エラー表示に気がついていない。
(6) →いずれも相手先メールサーバでエラーメッセージを返信しない設定になっている場合気がつきにくい。
(10） →自動送信ツールなんかで、あて先を全部BCCに突っ込んで一括送信する場合意外な盲点かも。部門で利用しているようなメールアドレスのときに要注意。
(11) →ホップ数設定が低いサーバが経路上にあると破棄されてしまう。
標準は26くらいで、引っかかることは少ないようだが、昔は10とか6とかあったらしい、
(12) →引越し通知に返信したのが引越し当日でメールサーバの電源きれてますとかな～
(13) →CC同報で送っていても、自分には届いてないと主張されると相当厄介。
自社内であればメールサーバログなどで受信状況確認したりできるけど他社の場合はなかなか証明しづらい。
というか、しらばっくれられて確かに届いていたことを証明しろとかいわれてしまうと正直どうしようもないんだが、、
WinXP機に、ruby on rails インストール中（gem使用中）に下記のエラーが発生した。
ERROR: http://gems.rubyonrails.org/ does not appear to be a repository
一時間ほど格闘した結果、プロキシの設定をしてないだけだった。環境変数HTTP_PROXYを作り、URLを設定する必要があるらしい。
Goto the cmd line
set HTTP_PROXY=http://mycache:8080
http://wiki.openqa.org/display/WTR/FAQ#FAQ-HowdoIgeminstallWatirbehindaproxyserver%3F
なんかスゲー話題になってるみたいなので、一応サポートで飯を食ってる人間として（上の例で言えば、オペレーターが相談してる上司か社員にあたる立場になる）一枚噛んでみる。
未熟なサポートと困ったユーザーはどうしたって無くならない訳で。サポート屋としては、実は元記事のような客はそんなに困らない。
対応の巧拙はあっても結局は同じ結果になったはずだし、後日素直にリセット処理にも応じてる。「気が動転してました」と自分の非についてもある程度反省しているようだし。（ただ、散々ごねた上に「法務を出せ」とまで言い、ブログでdisった挙句に勘違いでした…･･･って逆に訴えられても仕方ないレベルじゃないか？）
一番厄介なのが、ブコメに見られる中途半端に知識をかじったワナビーども。
コイツラは何かと言うとゴチャゴチャ話をややこしくする。初期化すれば済むだけの話を「そもそもIMAPとは（キリッ）」なんて言い出すから始末に終えない。いいから初期化しろよ！そうすりゃ直るんだから！
さて、まずは元記事の症状からざっくりと問題を判別してみよう。
8/31 22:00過ぎから、i.softbank.jpへの接続ができなくなりました。エラーメッセージは「ユーザ名またはパスワードが正しくありません」なのですが、IMAPアクセスしているiPhone側もPC側もユーザ名もパスワードも変更していないので、急にこの挙動になってしまったのが理解できませんでした。
アカウント情報を削除して登録しなおしてみたり、MySoftbankでメールアドレスやパスワードを変更してみても症状は全く変わりませんでした。その後、自分のi.softbank.jpにメールを送ってみると、
550 Invalid recipient:
でメールが戻ってきていることが判明しました。受取先が無効ですエラーってことは、アドレスが存在していない扱いになってしまっています。しかし、MySoftbankにはログインできていることから、
iPhoneの端末側の問題ではなく、IMAPサーバ側の問題である
という見解に至りました。
じぶんの経験で言えば、ユーザー側でここまで切り分けてくれた時点で御の字であるｗ有償サポートでも、いや、だからこそか、ここまでやってくれる人はいない。
"MySoftbank"のアカウントとメールのアカウントが同一であるかは分からないが、IMAPサーバ「側」の問題（iPhone本体ではない、という意味）であることは確かだ。
ところで、"550 Invalid recipient:"のエラーはIMAPではなくSMTPのエラーである。
これが、例えばSMTPは問題ない、つまり「送信できるけど受信できない」状態であればIMAPサーバーが悪いと言える。
しかし「送信できない」となると、IMAPは全く関係がない。
理由については「IMAP」でぐぐると最初のページに出てくる記事だがこのページ辺りを参考にして欲しい。
あと、設定方法をぐぐってみると、
IMAPサーバーとSMTPサーバーは別になってるようなので、「IMAPサーバー」の問題ではないことも容易に分かる。
つまりどういうことかというと、メールアカウント自体が消えてしまっているか、ロックされているか、見えなくなっているかということ。
加えて言えばSMTPサーバーも被害者の可能性があり、アカウントを管理しているLDAPサーバーのようなものが原因だった可能性のほうが高い。
したがって
iPhoneの設定確認やリセット処理など一通り試てもらった後、iPhoneを復元してみますとのこと。復元後メール設定をしてみると、なぜかメール受信ができるようになってました。
とアカウントをリセットするのはマニュアルどおりのテキトーな処置ではなく、むしろ論理的な問題判別に基づいたアクションといえる。「なぜか」じゃねーよｗ
関連記事を見ると、同じ症状の方もいるようだ。
あと「IMAPならPCでもiPhoneでもできるはず」っていう意見に対する反論はこの辺の記事が参考になる。
ここまで分かれば、ブコメのIMAP厨（笑）がいかに見当違いなことを言ってるかが分かると思う。
「IMAP」という言葉に過剰反応して問題が見えなくなってる。
覚えたての言葉を使いたがる子供ですか？IMAP言いたいだけちゃうんかと。
最後にブクマのバカなコメントに突っ込んでおこう。こういう輩を放っておくと、第二第三の被害者が出かねないからな！サポート的な意味で！
http://b.hatena.ne.jp/entry/d.hatena.ne.jp/iwa/20090904/1252016930
「良く分からん」のに「鯖側ちょいと直せば済む」と言い切るエスパーぶり！具体的にどこをどう「直せば」いいんですか？
「メールプロトコルの話」ではないでしょ、プロトコル以前のサーバー側の問題なんだからｗ知ったか乙ｗｗｗ
b:id:mnemo プロトコルの問題なのに PC という語に過剰反応する、このサポートレベルのぶこめが多くてびっくり。
プロトコル以前の問題なのに IMAP という語に過剰反応する、このサポートレベル以下のぶこめにびっくりｗｗｗ
b:id:noraora サポート外もなにも、IMAPなんだから今まで正常だった機能が使えないってことはPC、iPhone関係なしにIMAPサーバ側の問題だろ
IMAP（キリッ）だっておｗｗｗ
b:id:sy0ta PCでアクセスするのはおかしいとかコメントしてる人は頭おかしいの？PCからIMAPでアクセスしておかしくなるってことは、それはIMAPじゃないってことだろ。できて当たり前のことをサポート外と言い切る姿勢がおかしい。
日本語でおｋ。どこにIMAPをフルスペックでサポートする、なんて書いてあるんですかｗｗｗそもそもIMAPが悪いなんて誰も言ってねーしｗｗｗ
b:id:hirok73 わかんないので詳しい人教えてください：iPhoneでしか読めない（特定のMUAでしか読めない）状態でIMAP対応と名乗るのはありなの？
どこの公式情報に「IMAP対応」なんて書いてある？あとRFCをフルスペックでサポートしてないMUA、MTAなんていくらでもあるよｗ代表的なのがoutlook様だｗ
もちろんブコメもバカな意見ばっかりじゃなくて、まともな意見もある。
b:id:maakunh iPhoneのアカウント設定が壊れていたのかな？壊れた状態で何度もアクセスすることで、サーバ側で不正アクセスと判断され、アカウントロックされたとか・・・
b:id:z0rac ん？それIMAPの問題じゃなくメールボックスがアクセス不能になってる。/つうかアカウント消えてね？
サポートの立場としては、「こういうことが起こってる可能性が高い」と説明し、コンセンサスを取った後初期化処理を行うべきだった。その点では、お互い不幸な事件ではあったのだ。
ちがうにょー
デバッグに梃子摺る人が初心者に多いわけは、主に次の３つに起因するにょ。
エラーメッセージの見方を知らないからエラーメッセージを全く見ない。エラーが出ている場所と内容まで事細かに記してあるコンパイル時エラーメッセージや実行時スタックトレースを前に絶望してしまい、慌ててソースコードを１から読み直してしまう。特によく耳にするのが『どこが悪いのかわかりません』だけど、数行のエラーメッセージに答えがずばり書いてあることがほとんどだったりします。
特にプログラミングに慣れていない初心者が陥りがちなのが、制御フローばかりに目が行ってしまい、制御フローから類推できるデータフローには気を配らないという現象。例えば値「１」を返す関数が「２」を返してきてしまった。確かにそういう場合には制御フローを辿ることも重要だけど「２の源流をたどってみる」ことをすれば、意外とすんなり原因が見つかることも多かったりです。
見たままの文字にばかり注意してしまい、例えば半角空白と全角空白とタブを見分けていなかったり、他にも行末に１個空白が紛れていて「なんで上手く処理されないんだ」と悩んでしまう人が意外といる。他にもコンパイル時エラーで多いのが ; の有無だったり () の対応だったり。原因の目星がついても、最後の最後で躓くのはおおよそこういうポイント。慣れればぱっと見で気付くことなんだけど、このあたりが前述２つの理由と相まって、意外と疎かにされやすいところなんだよね。
総じて、デバッグを出来ない初心者に共通する原因は「結果から原因を探ることに慣れていない」ということに集約されたりする。そもそも結果を見ていなかったり、結果から原因を逆算する手法を知らなかったりするのが、「慣れていない人」というわけです。
http://news.dengeki.com/elem/000/000/153/153004/
MS、Xbox 360本体の“E74”エラーに関する保証期間を延長
マイクロソフトは、Xbox.comのサポートページで、Xbox 360本体の“E74”エラーに関する保証内容を変更すると発表した。
これは、Xbox 360本体を起動した時に“E74”というエラーメッセージが表示される問題を指す。同社はこのエラーが出た場合、保証期間を購入日から3年間に延長する。保証期間中、ユーザーは無償で修理を受けられるようになる。すでに“E74”エラーで有償修理を受けている人には修理代金が返還される。詳しくは、 Xbox.comのサポートページを参照のこと。
エラーが頻発する事が前提みたいな言い回しはやめてくれ・・・
仕事が忙しく、日中家にいられないためコンビニ受取を初めて使った。
コンビニ受取のヘルプとよくある質問のページを確認して、コンビニで受け取れない商品があるときは
注文途中でエラーメッセージが出るということだったので、欲しい商品を3つほど注文。
Amazonから発送のメールが届いたのでコンビニで商品の受取をしに行ったら、商品が届いていなかった。
配送ステータスを確認したら受取拒否になっていた。
訳がわからず配送業者の窓口に連絡したら、配送された荷物のサイズがコンビニ受取できるサイズを超えていた為
返送されたという事だった。
どういうことだ？受取できないなら注文途中でエラーメッセージがでるんじゃないのか？
Amazonはコンビニに配送するときにサイズを確認してないのか？
意味が解らない。
Amazonに問い合わせようとしたが、携帯電話での問い合わせができなかったためメールにて
問い合わせをしている。しかし返事はまだない。
はやくFallout3がやりたい・・・。
Could not load class (App::Mobirc::Plugin::HTMLFilter::DoCoMoCSS) because : Can't locate XML/LibXML.pm in @INC (@INC contains: /home/pc/mobirc/lib /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /home/pc/mobirc/lib/App/Mobirc/Plugin/HTMLFilter/DoCoMoCSS.pm line 5.
どっか変なところある？
真っ当なエラーメッセージだと思うけど。
Webは便利な物が次々出てくるんだけど、ちょっとでもメインストリームから外れると、途端に放置される物が増える気がする。機能がどんどん便利になるのはいいんだけど、むしろいらない物が増えて重くなってしょっちゅう落ちるとか、便利だった旧来のサービスにメンテナンスが行き届かないとか増えていってるような気がする。
便利な機能を追い求める人がネットの世界では目立つけど、もう機能はたくさんでそれよりも従来のサービスを大事にしてくれよと言う人も一定数いるんじゃないだろうか。
私の環境だけなのかもしれないが、楽天は検索してるうちにブラウザが死ぬ事がよくあった。突然エラーメッセージが出て、今だに使っているIE6が閉じてしまう。検索した商品数が多いと途端に重くなり、毎回のようにそういう現象が出ていた。
楽天が無いと死ぬ！というほどでもないし、問い合わせしてぜひとも楽天を改善したいという意気込みも無いので、ほしい物はamazonで検索して買っている。
ひょっとしたら私の環境の問題だったのかもしれないので何とも言えないが、私と同じような環境でブラウザが固まって何も言わずに去ってしまう人は、ひょっとしたらいるのかも知れない。いないのかも知れない。
言いたいのは、全てのユーザーが新しい機能ばかりを追い求めているというわけでは無いという事。企業は躍起になっていろんなサービスを追加するけど、従来のユーザーにとって逆に不便になったりしちゃうとユーザーを逃がしちゃうんじゃないかという事だ。
新しいサービスを追加するたびにいろんな環境でテスト繰り返すとか、不具合への指摘に対応するために人員を割くとか、そういう地味なところも結構重要なんじゃないかと思う。
いろんなインターネットのサービスで、ああ、ここはメインストリームから外れてるんだなというところを結構見かける。ネットで感じる侘しさだ。
ユーザーが指摘しているのにもかかわらず、何ヶ月も放置されている不具合とか時々見かける。一度は指摘してもずっと放置されたままだと言う気も無くなってしまうのだろう。ずっと放置されたままだ。そういうIT企業は大丈夫なのか？と思う。
はてな匿名ダイアリーで毎朝のように出現するログインも出来ないような重さは、数年前のいろんなブログの重さを思い出させてくれる。はてなは、大丈夫か？
おりしも世界経済は大変な事になっている。今後インターネットのサービスがバタバタと倒れていっても全く不思議は無い。IT企業は厳しい選択と集中を迫られると思う。新たなサービスに打って出るのも大事だが、従来のサービスのユーザーを失わないように足元を固めてはどうか。
いろんなニーズがあると思うけど、機能を追い求めるのはほどほどにした方が良いのではないだろうか。手当たり次第、ギャンブル的に新たなサービスを出して、失敗してもやっていけるという時代は終わってると思う。
はてなブックマークがリニューアルされるらしいが、高機能に走りすぎて重くなったりしないか気になっている。今まではてブは、シンプルで軽くて使いやすいところがどこのSBMよりも魅力だったと言う気がする。その長所を失わずどれだけ新しいものを出してくれるのか、すごく期待している。
（参考）
Firefoxなら、そんなエラーメッセージをガン無視して入力できるぜ！
もちろんJavaScriptのあたりをごそごそいじった自分の設定じゃないと無理だけど。
まぁ、縛られてなさいってこった。
俺はちょっとPCに詳しいので、たまに友人・知人からヘルプが飛び込んでくる。
たいがいの問題は些細なものだ。しかし、すぐに解決することはまずない。なぜなら彼らは自分がトラブルに陥ってることはよく伝えるが、どういう経緯でそこに至ったのかを全く説明しないからだ。
「エラーが出ている、助けて！」
…それだけ言われても困るのだ。俺はエスパーじゃない、エラーメッセージを一字一句教えてくれ。そうすればググって調べるから。
「ネットにつながらないよ！」
…俺はお前がどういう風にネットにつなげているか知らないのだ。ISDNなのかADSLなのか光なのか、プロバイダからはどう設定しろと言われたのか。そうすればちょっとはわかるから。
こういうことを毎回言う羽目になるのがちょっと辛い。ちなみに頼んでもエラーメッセージを一字一句返してくれる人も少なくて、自分なりに「解釈」した結果を返されることが多い。たいてい見当違いだ。
俺はちょっと詳しいだけなので、多くのトラブルの解決方法はググって調べている。だからわざわざ俺にメールやら電話するより、トラブル主がググって調べる方が遙かに速く、確実なはずなのだ。そこまで気が回らないのだろうか。いや、だからこそトラブルに陥るのか。
サポセンの人は大変だなぁといつも思う。
諸君、私はC++が好きだ
諸君、私はC++が好きだ
諸君、私はC++が大好きだ
テンプレートが好きだ
STLが好きだ
Boostが好きだ
FC++が好きだ
Macで
BSDで
演算子の意味が変わり、直感的なコードが書き下せる時など心がおどる
動的言語の優位性を語っている奴等にそれを見せた時など胸がすくような気持ちだった
Boostが好きだ
Boost::lambdaを使って(_1 + _2)と二つの引数を足算した結果を返す無名関数を定義した時など感動すらおぼえる
Boost::regexで正規表現を書く時などもうたまらない
Boost::shared_pointerでオブジェクトが自動的に解放されるのは最高だ
納期に追われて急いで書かなければならないパーサを
Boost::spiritでBNFを記述して書いた時など絶頂すら覚える
そんなC++が複雑だと思われているのはとてもとても悲しいものだ
テンプレートが好きだ
諸君 私に付き従うC++好きの諸君 君たちは一体何を望んでいる？
更なるC++を望むか
糞の様なC++を望むか？
BoostやFC++によってさらに変態的になっていくC++を望むか？
よろしい ならばC++だ
だが、LL全盛の時代の陰でもはや組み込みかHPCぐらいでしか使われないという中傷に耐え続けて来た我々には
ただのC++ではもはや足りない！！
我々はわずかに小数
Perl、PHP、Python、Ruby、JavaScriptに比べれば物の数ではない
だが諸君は一騎当千のBinarianだと私は信じている
ならば我らは諸君と私で総兵力100万と1人のコンピュータサイエンティスト集団となる
我らを忘却の彼方へと追いやり、インタプリタしか知らない連中を叩きのめそう
髪の毛をつかんで引きずり下ろし 眼(まなこ)をあけて思い出させよう
連中にインタプリタでは実用的なプログラムが書けないということを思い出させてやる
C++には奴らの哲学では思いもよらない書き方がある事を思い出させてやる
1000人のBinarianの集団で 世界を変態的なコードで埋め尽くしてやる
逝くぞ 諸君