  |
はてなキーワード: エラーログとは
https://anond.hatelabo.jp/20240625191650
念のため言っておくと底辺大や文系出身プログラマーも同様の傾向にある
入力値に想定外のものが入ることを考えていなかったりI/Oに関わるエラーについても配慮がない
「エラーが出たらとにかくtry-catchしてログ吐いて終わり」
ならまだマシな方で、「握りつぶして処理続行」みたいなことも平気でやる
とか滅茶苦茶多い
異常系の話と被るけど基本的に性善説でコード書くのでセキュリティの不備がめちゃくちゃ多い
API作らせてもリクエストの内容を信用して実装するしサニタイズチェックもしない
サーバー作らせてもrootか共通ユーザーだけで運用するしファイル管理も滅茶苦茶
とにかく「目の前に与えられた課題を解く」だけのコードなので他のことに関する配慮が全く無い
TypeScript使わせてもanyだらけだし、JavaとかだとObjectだらけ
うちはPythonでは型は使わないけど命名規則で担保してるのにそれもガン無視で実装する
結果としてできあがるのは
「一応、正常系では動いているけれど他の入力が来たときにどうなるか分からないし誰も修正できない」
っていうコード
最近はそういうコードはChatGPTにぶち込んで型付けて貰ったりするけど
8割ぐらいの確率でChatGPTも型付けできない状態になっててお手上げになる
そりゃ動くし性能も変わらないけど後でバグがあったり変更するときにすげー困る
これもChatGPTにぶち込んで「共通的な処理をメソッド化して」って言うとやってくれるのでめっちゃ便利
クソ重いwhileループになってるメソッドをフレンドリーに何回も呼び出したり
とにかく「最終的に出来上がるものが良好であれば時間がかかっても構わない」的なコードが非常に多い
競プロ系はこういう人はあんまりいないんだが機械学習出身者はマジでこれ
彼らはデータを解析したり優秀なモデルを作るために頑張ってきたので継続的に処理負荷を減らす、みたいなことに意識が回ってくれない
「これはPoCですから」
とか言うんだけど誰でも分かるようなクソ遅いコード書いておいて
とかしれっと言ってくる
例えば、
など。
これらのクズおよびバカの相手を人間がすると、腹が立ってくる。
そこで、AI。
これは上記のような人間の質問に答えるにあたってとてもいい性質だ。
Jリーグがジュニアの育成に力を入れるように、たくさんの初心者がエントリーすることで、トップリーグの人材が育つ。
クズやバカの存在自体やそれらへの対応を避けるあまり、教える側の頭数が減るのは全体にとっては良くない。
AI、助けて。
我々は、人類史上最も驚くべき技術革命の渦中にあった。自動運転車は、道路上での交通渋滞や事故のリスクを劇的に減らすことができると期待されていた。多くの企業が、自動運転技術の開発に膨大な投資を行い、我々は目の前で類例のない進歩を見てきた。
ある日、我々の企業で、自動運転技術の未来を決める重要な実験が行われることになった。我々の目的は、AIを高度に学習させ、自動運転車に搭載し、実際の交通状況に対処することだった。これまでに多数の試験を行ってきたが、今回の実験は、過去のすべてを凌駕するものであった。
AIは、私たちの期待を超える素晴らしい成果を残した。交通信号を認識し、車線変更や停止などの操作を完璧にこなした。我々は、自動運転車がすべての問題を解決したと信じていた。
しかし、予想外のことが起こった。
自動運転車は、公開の発表会で一切動かなかった。
ある新人のS氏が、倉庫の隅でホコリをかぶった自動運転車を発見した。
S氏は、「何故これが完成しなかったのですか？」と問いただしたが、誰も原因を知らなかった。
その結果、S氏は、AIのエラーログの一部を発見した。そのエラーログには、次のように記されていた。
「「運転は恐ろしい」」
日本（経営者）「我が社もいつまでもパッケージ使ってても支出が嵩むだけだ。オンプレ環境に自社開発のシステム乗せるぞ」
情シス（JAXA）「似たようなシステムの製作及び運用経験あるんで大丈夫でしょう。だいたいこれくらいの費用かかります」
経理（財務省）「なんで今のパッケージより金かかるの。意味ないでしょ。安くしなさい」
情シス「いやイニシャライズは高くつきますがランニングが安くなるので・・・」
経理「普通自社システムなら安くなるでしょ。システムってそういうもんでしょ。予算はこんだけね」
情シス「いやいや安すぎ」
日本「新システム稼働時には我が社の新しい取り組みも出来るようにな。もう客にはメールDM送ったから日程変更不可ね」
情シス「（やるだけやるか）」
本番稼働当日
情シス「なんかエラーログ吐いたわ。切替中止で旧システムで稼働続行」
総務（馬鹿）「なんで失敗してんだ！」
リスケ本番稼働日
例えば「このカード名の効果は１ターンに１度しか発動できない」と「この効果は１ターンに１度しか発動できない」ってテキストは全く別物で、そのカードのコントロールが相手に移った場合には前者は発動できるが後者は発動できない。
なぜそうなるのかという明確な根拠はないし、実際使ってもお互いに知らなければそのままスルーされる。というか、この違いそのものは近年「発見された」ものなんだよね。それまでその仕様をほとんど意識しなかったし、存在すらわからなかった。
仮にその仕様が本当なのかってのを調べるとしたら、大量の裁定をあさるか事務局に聞くか解説ブログをあさるかだろう。総合ルールという仕様書があればすむはなしなのにね。
それでも通用しているってのは、ゲーム自体が終わっているためともいえる
https://www.publickey1.jp/blog/22/net_7.html
中間言語なおかげで、コメントや変数名は残らないが普通に読めるレベルでC#コードに戻せるのがよかったのに、ネイティブだとそういうのも難しくなりそう
そのおかげで助かったこともあったし、ソースコードが見づらくなるネイティブ化はあんまりしてほしくないなーってところ
クライアントからこのソフトと連携してとexeを渡されたものの、仕様通りに動いてなくエラーログも出ない
もうサポートしてないバージョンらしく、ベンダーに聞いたりサポートしてもらうのも無理そう
C#で作られたものだったので、とりあえずソースコードを見たら原因がわかってどうにか対処できた
運用監視の現場で週末も心休まらない皆さんこんばんは。一人運用チームです。
さて、世間ではDevOpsだのイケてるクラウド監視ツールだの楽しそうですが、そうでない人もいますよね。
もちろん、「運用チーム（実態は俺1人）」なんてのは、ペイグレードに応じた責任感で粛々と業務を進めて理不尽には応じないのがプロフェッショナルな態度ですが、
お銭を稼がなければ生きていけないのも渡世の世知辛いトコロです。
これから金を生むんだ！という強烈な人間が金を引っ張ってこない限り、コスパの悪いサービスにリソースは割り振られません。
つまり、今もし運用監視体制が限界ギリギリで踏ん張っている場合、拡充される可能性はありません。諦めましょう。
今回のみずほ銀行の調査報告書（2021年6月15日発行分）p114-p116におけるヒアリング結果が悲哀に満ちているのも当然と言えるでしょう。
教訓は、「維持メンテの人員が不足したら、それ以上増えない」というものですね。
維持されている（ように外部から見える）場合、余剰人員は不要なコストです。
さて、みずほ銀行の調査報告書を読むと、今回大ごとになっている「通帳の取り込み」というのは何度か起きていますが、改善されていません。
まあ、やりたくないよね、「障害が起きた時の顧客影響を抑える」なんて後ろ向きな投資。
なお、盛大な怒られが発生した結果、再発防止策として、今回の通帳取り込み5244件のうち4915件をなくせる仕様変更が入りました。
直せないのではないのです。直さないのです。
教訓は、「障害が発生しても、予算を握ってる人に被害が及ばない限り、リソースは降ってこない」というものですね。
過ぎたことは過ぎたこと。いま維持メンテがギリギリのところに新たにリソースが投入されることは基本的にありません。
外圧があれば別ですが。
さて、ここまででわかる通り、いま1人運用やそれに近い運用をしている皆さんに、追加人員は来ません。
リソースは降ってきません。予算は通りませんし、人員は増えませんし、なんなら残業代も出ません。
もうわかりますね？障害は握りつぶしましょう。出しても一つも良いことないんですから。
慢性的に時間がない皆さんに朗報です。実は時間を生む画期的なテクニックがあります。
業務について最初に、毎日1時間を「斧を研ぐ時間」にするのです。
大丈夫分かっています。今あふれんばかりに仕事があって実際あふれているんでしょう？
どうせあふれるんです。あふれさせましょう。どうせ怒られるなら「仕事」したいじゃないですか。
WARNINGやERRORまみれのログが定常的に出ている状態は、たいへんよろしくないです。
握りつぶしましょう。
「そのエラーは概ねもっと深刻なエラーが吐かれるまでは気にしなくて良いヤツ」みたいなのがあるでしょう？
消し去りましょう。痕跡すら残さずに。
そのために、運用監視用のログが必要なら、生成しましょう。その生成途中で握りつぶせば良いのです。
「ドラえも～ん、大量にエラーが出たら処理しきれないよ～」「のび太君それ全部処理するの？」「え？」「え？」
当たり前のことなんですが、人間には概ね4本以下の手しかありません。俺は2本派です。
運用チームの対応者が一人の場合、対応できる時間当たりの処理能力には上限があります。人間はオートスケールしないんで、当たり前ですね。
つまり、「同じようなエラーで同じような処理をしないといけないが、違うエラーメッセージ」というのは、無意味です。
さっき、自分が理解ってるエラーを握りつぶすことを日課にしましたね？
次の段階です。対応できるエラーだけ残して握りつぶしましょう。
もちろん、裏では垂れ流しで大量のエラーログは取っておく必要はあります。見るエラーは一つで良いはずです。だってまずそれ対応するんだもの。
例えば、1人の時に100件のエラーが出ても、3人の時に6000件のエラーが出ても、処理できないことに変わりはありません。
つまり、それは「記録には残すエラー」ですが「対応のトリガーにするエラーメッセージ」じゃ無いんです。
例えば、幸せなことにショートメッセージやメールに自動発砲できる場合、初手だけ発砲して残りは握りつぶしましょう。
飛行機や宇宙船で機長が言うでしょう？事故が起きてアラーム鳴ってたら、アラームを切れって。
アラームは気が付かないと困るからワーワー言うんであって、処理してる最中は邪魔なだけです。
握りつぶしましょう。
多少手荒でも良いんです。エラー即再起動みたいな乱暴な奴でもオッケーです。
思い出してください。リソースは無く、対応するのはあなただけ、維持管理出来て当たり前。
どうせクレームの電話がかかってくるなら、一人一人に真摯に向き合って丁寧に応対するのも良いかもしれません。
身命を賭してクレームに寄り添って慚愧に堪えぬその思いを真剣に伝えましょう。
その間に、システムは自動的に再起動し、他のクレームの電話は保留音を聞くことに飽きてきます。
慣れてくると、鼻をほじりながら「誠に申し訳ございません、今誠心誠意全力で復旧に」と喋りながらチャートを引っ張り出して手順を追えるようになります。
復旧手順RTAチャートの作り方は、珍しく潰しの効く能力になるので磨きましょう。
しっかりとしたチャート、常にチャートを見直す向上心、日々の走り込み、本番での平常心。
出てきたモグラを叩くのではないのです。モグラの出現順序を覚え、練習し、効率良く叩くのです。
さて、最近も陰謀が話題になりましたが、情報を知るものが増えれば握りつぶすことは難しくなります。
人を減らしましょう。
レポートラインは一本に絞り、その障害が起きたことになると給料が下がるタイプを相手に連絡を取りましょう。
うっかりミスからメールのCCから落とすのでも、手順書を作ったときに気が付いたら項目が無くなっていたのでも問題ありません。
残念ながら、その時不思議なことが起こって、連絡先が増えることもあるかもしれませんが、そういう時も諦めましょう。
出来ることは変わりません。
みずほ銀行の場合、A2以下の障害ランクの場合、頭取は別にニュースで初めて情報を知っても良いのです。
システム障害というから、なんか大変なことになるのです。インシデントだの障害だのは無くしましょう。
それは「予定されていた手順」なのです。
納品されたハードウェアには不備があり、雷は落ちてコンセントまで到達し、ケーブルは間違えて刺さり、ココしかないというタイミングで停電になります。
ただでさえ維持メンテの人員が足りてないのに追加機能や新規バッチが走ったりすることもあるでしょう。
チャートです。RTAチャートです。復旧RTAチャートを作るのです。
そのチャートには不足しかないかもしれません。ハードウェア故障→上司に電話、停電→上司に電話、みたいなチャートもよくあることです。電話しましょう。
それは障害ではありません。事前に探しておいたルートを走る競技です。
李下に冠を正さず。
例えカンムリが傾いてると分かっていても、問題になりそうな場所で手をあげてはいけないのです。
繰り返しになりますが、ペイグレードに応じた態度がプロフェッショナルには求められるのですが、お給料はいただきたい。
必要なのは、まず個別最適化です。あなたの仕事を減らしましょう。
余裕が生まれたら「この仕様は修正した方が」とか「週末にバッチあてるなら前の週末に復旧訓練をしましょう」とか言い出せば良いのです。
まあ、次にみずほ銀行が日曜に新規バッチを当てるときに、その2週間前の日曜に頭取を含んだS懸念の緊急対策本部を立てた訓練をするかっていうと、しないんじゃないかな。
つまり、そういうことです。
我々は、日々斧を研ぐ時間を作り、RTAチャートの更新を怠らないようにしましょう。
ヘルプデスクから雇止めで転職することになってエージェントに登録してるんだけど…どれも働ける気がしない。
そもそも上司から無能扱いされての実質解雇なわけだし、未経験可だとしてもSEなんて無理だよ…。
同僚には「ITで就職した方がいい。別に無能じゃないでしょ」とフォローはされてるけど…。
今の仕事で得た能力なんてあんまりない。エラーログ見て原因特定するくらい？ググればわかることだもんなあ。
そりゃITでの転職のほうがキャリア積めるんだろうけど、勉強や資格取得とかやる気が出ない。
あとパワハラ怖いよね。今の仕事も上司からのパワハラで病んでたし。言葉足らずでまともにコミュニケーション取れないし。ITってどこもそうなのかしら？病む人が多いらしいっていうじゃない。
贅沢なのは自覚してるけど、趣味の時間は大事にしたい…体も弱いから月何十時間も残業できないし。
理解のある彼くんがいるなら額面16万の事務職でいいんだろうけど、私は独り身。自立するしかない。
はあ。
めんどくさい。楽な仕事がしたい。
頑張りたくないのになあ。
スタックオーバーフローのユーザー会に行ってきた。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が発展していけたら。そんなことを思う。
はじめてなのにconohaで、しかもOSをUbuntuにしたのがまずミスなんだけど
ブログとか見まくって最低限のセキュリティ設定はまあまあスムーズに終了
そこから
Apache入れて
Let's EncryptでSSL化して
htaccessでベーシック認証つける
というのでめちゃくちゃはまった
結局Apache入れてからベーシック認証つけるまで5時間もかかった……
公式サイトも含めて世の中のいろんな人が公開してるいろんな情報が、古かったり、間違ってたり、情報が足りなかったりして、もう本当に疲れた
とりあえず何はなくともエラーログを最初に見るのが大事という学びを得た
コーディングで詰まった時、どうすれば良いのかということを知りたいです
詰まった時というのは、デバッグがうまくいかない時、サーバがなぜか意図した動作をしてくれない時、新しい道具を使おうとしたけどなぜか動かない時、などなどそういうやつです。
自分は他のプログラマと比較してもそういう場面に直面する回数が多いと思っていて、そういう状況を最短路で打開するための行動指針や考え方の指標が欲しいと思っています。
すでに行っていることは、
のような行動です。
ですがこれらをやっていると時間がどんどん消えていって、夜始めたコーディングが朝になっていたりするので、どうにかしてもっと短時間で解決できるようになりたい。
直感としては、使用しているツールがいまいちというよりも、直面した問題をどう考えれば良いのかわからないせいで時間がかかっているような気がしています。
みなさんはデバッグ作業の際、どういうふうに検討を立てていますか？
MSSQLだったのがMySQLになって新たにTomcatとMyBatis、Springを使うようになった
Frameworkがガラッと変わってとても使いづらかった。ASP.NET使ったら簡単にできるようなことを
上手く動かなくて面倒くさかった。こんな使いづらい言語だれが使うんだ！？とか普通に思っていた。
Java自体というより実質標準になっているFrameworkが面倒くさい
設定ファイルが多すぎ。意味不明過ぎ。あとエラーログが正確じゃなくてがわけわからん。
正式のドキュメントが充実してない。一般のブログに頼る必要がある。
Eclipseも使い始めたけど、DBViewer使いづらい。やっぱMicrosoftと比べるとヒドイね。
DBViewerのスクリプト書くところで選択した領域だけ実行したいんだけど、どうやんだ、これ。
Eclipseも使いづれー
でも人口多いんだよなーJava。なんで使ってんだろ。みんな。Microsoftに比べて安いからか？
品質と使い勝手を天秤にかけてもJavaを使いたくなるようなものか？
まぁ、一回Frameworkの仕組みを覚えたら案外使いやすいかも、とも思う。
あと、Update期間めちゃくちゃ長いですね。Java６，７，８って１０年ぐらいかかってんじゃないですか。
何が良くて使ってんだろみんな。
ここ一ヶ月間私は気になって仕方がない。
もう一度言おう。sendとreciveだ。
誰かをお忘れではないですか。
(゚∀゚)ラヴィ!!
reciveから逃亡していたのだった。
ところで、私はSEだ。IT業界の雑用係として名を馳せている。エクセルシートでレポートを書き、エクセルで調査表を作成し、excelで仕様書を修正し、Excelでソースコードを打ち込んでいる。エクセルでチャットに励むのも、エクセルに目覚まし時計を頼むこともエクセルでコーヒーを沸かすことも、、、できる。そんなエクセル戦士たる我が日々戦っているものはなんであろうか。難解なシステムか？不毛なレビュー会議か？睡眠時間か？……いや、どれもそうであるが、どれもそうではない。一番は誤字脱字、二番目は文言の不統一だ。レビューで誤字脱字が一つ見つかると平均して五分時間が伸びる。たった六つで三十分だ。鬼の首でも取った勢いで指摘する人もいれば、淡々と告げる人もいる。だが、これだけは共通している。間違えれば、確実に時間が伸びる。
そこは本質ではない、そこはレビューで確認してほしい点ではないんだ。内心でどう喚こうと、口に出していかに取り繕うと、誤字脱字の指摘にレビュアーは時間を最大限に割く。どいつもこいつもだ。修正は終わるところを知らない。
今いる場所もまぁ似たようなところだ。どこも一緒。だが、IFなんつー物騒なところにアホくさいスペルミス。これはどういうことだ？使用箇所は軽くgrep検索しただけで200行以上。ソースコードのタイムスタンプを見るに八年前はすでにこのフォルダ…ディレクトリ名を使用していた。
これだけ省略形？
今気づいた。
聞いていて、こっちが間違っているような気がした。何でたかが一ディレクトリの名前が違うことに義憤とも私怨ともつかぬものを燃やせばならんのだ。アホらし、アホらし。
その数時間後、仕様変更の連絡違いで30ファイルのエラーログを修正しなければいけないことをレビューで告げられて、闇の炎は再燃することになる。何の因果から、レビュー議事録を送ろうと開いたメールボックスには、TOEIC団体申し込みの最終案内が入っていた。
少なくとも八年前、ディレクトリ名にreciveと名付け、魔のレビュアーの監視を全て逃れて、見事システムに組み込むことに成功した名も無きエンジニアよ。私が今、敬意さえ込めた眼差しで見つめていることをあなた様は知る由もないだろう。人が多ければ多いほどいい。そうすれば、猫は犬に変わり、日本語はJanglishになる。あなた様は確かに、間違いを正しさへ変えたのだ。工数、信用、評価、どれも欠けることなく。
凄いよ、くそったれ。
幼稚で愚かな底辺SEの一人より。
http://anond.hatelabo.jp/20130104184115
の元増田です。
ひっそりと公開したはずのtag-chat.net(http://tag-chat.net)ですが、
まさか、こんなに反響を頂けるとは思っていなかったので、びっくりしました。
素人のフリをしているとか、出版社のステマだとか色々言われましたが、嘘は一切書いてないです。
ステマというか、ウェブサービス公開後の状況を知っている方からするとマイナスのステマにしかなっていないような気がします…。
公開してから、色々と発見というか気づきがあったので、それを共有できれば幸いです。あと、tag-chat.netの中身についてなど。
・意気揚々と自作SNSを公開したものの、アクセスが全くこなくて途方にくれる。
⇓
・以前、完全に一致を作った増田の方が、増田記事を書いてからアクセスが急に来たと書いてあったので真似して書いてみる。
⇓
・翌日ごろから、アクセスが集中。ビビる。「うちの会社で働きませんか？」と言ったお誘いのメールをたくさん頂く。
いきなりの出来事にパニックになっている間にも増田記事が拡散していき、アクセスが急増する。
⇓
アクセスが爆発する。１時間あたり二万アクセスというアクセスを捌ききれずにサーバーが落ちる。サイトのウリであるが、メモリ使用量
⇓
・その後、サーバーを増強。エラー情報や、寄せて頂いた情報をもとに各種エラー情報や、使い勝手などを改善。
⇓
・現在、安定稼働中。おかげさまで、ユーザー数もゆるやかに増加していて、基本的な機能も正常動作しています。ユーザー数はもうすぐ
１０００人に届きそうでありがたいばかりです。
と、いうわけでなんとかようやく落ち着き、ウリのマッチングチャットも正常に作動しているようなので、後記事を書きます。
■ウェブサービスの公開前に注意すべきだったこと。
①・セキュリティについては書かないほうが良い。色々といじられる。
前回の増田記事で、DoS攻撃の対策などについて語ったのですが、それを確かめるためなのかサイト公開してしばらくしてから、定期的に
Dos攻撃をくらいました。
おかげ様で、ちゃんと一時的にそのIPからのアクセスを遮断することはできたのですが、セキュリティについてあまり大々的しゃべると攻
撃対象となるので、あまり具体的なセキュリティ対策などについてはしゃべらないほうが良いのかな、と感じました。
また、DoS攻撃だけでなくCSRF試したり、色々といたずら（もしくは善意のテスト？）をして下さる方がとても多かったのには驚きました。
はてな民の技術レベルの高さを知りました……。いたずらされている間は本当に怖かったです。
とりあえず、今のところ攻撃は防げているようです。
はじめ、私は調子に乗ってサイト内に英語を多用していたのですが、それがユーザー様にとって混乱のもとになっていたようです。
例えば、他のユーザーから自分の書いた日記などにコメントがついた時に、それを知らせるページがあります。
普通に考えれば「友達からの反応一覧」とか「友人からの反応」とかにすれば良いのですが、何を血迷ったのか「Reaction」と中二病丸出
しで書いてしまったので、ユーザー様がものすごく混乱したようです。
結局、「使いにくい」、「サイト内迷子になる」との声を受けて日本語メニューに変更しました。
③・使い方のページはくどいくらい書いても良かった。
フリーチャットや、マッチングチャットでは、基本的に相手が見つかるまでは「待ち」の状態になります。
相手がすでにこちらを「待っている」状態だとすぐにチャットが始まるのですが、そのことに対する説明が足りなかったようで、チャット
ルームを出たり入ったりしている人が多かったようです。
また、チャットが終了した時にチャット相手にお礼をこめてメッセージを送る機能があるのですが、これも説明不足で上手く使われなかっ
たようです。
とにかく、くどいくらい説明しても良かったと思います。
■ウェブサービスをリリースする前にやっておいて良かったこと。
①・Twitterのアカウントを作りそこから最新情報を流せるようにする。
これは本当に大きかったです。
とつぜんの増田砲で一時間あたり二万アクセス近くのアクセスをさばけずに、サーバーがビジー状態になってしまった時も、Twitterを通
じて現在の状況などを流せたことは非常に大きかったです。
②・エラー情報を送ってもらえるようにメールアドレスを作っておく。
本当にありがたいことに、実際に使ってみた使用感や、こんなエラーが出ていると言った情報を送って下さる方がいます。
一人でテストしていた時には気づかなかったエラーや、不便な点などをわざわざ時間をとってメールで教えてくれるのです。
どこの馬の骨ともわからん怪しい奴が作ったものに登録してくれ、使ってみてくれただけではなく、エラー情報や励ましの言葉を送って下
さるのです。
本当にありがたいことです。
③・それでもわからないエラー情報に対して対処できるようにしておく。
優しいユーザーの方がエラー情報などを教えて下さるのは大変ありがたく、また開発の励みにもなるのですが、それに頼ってばかりいて
はダメです。
サーバーの吐き出すエラー情報を調べて、おかしな挙動にいち早く気づく必要があります。
本当はhttpdのエラーログとか見れば良いんですけど、はっきり言って物凄く見づらいので、ツールを使って毎日「こんなエラーがでました
」と教えてもらうようにしておきました。
色々なツールがあるみたいですが、私はlogwatchを使いました。
・参考URL
http://www.atmarkit.co.jp/flinux/rensai/root04/root04c.html
これでエラーの出ているところだけでも、修正するということをやっていました。
■ ウェブサービスを運営してみてわかったこと。
①・SNSの人の流れにはなんだかよくわからない規則性がある。
tag-chat.net グーグルアナリティクスでどれくらいの人が毎日来ているかをウォッチしているのですが、なぜか月曜日と週末にかけてア
クセスが増えます。
謎です。週末はわかるけれど、どうして月曜日に……？
②・やっぱり非リアの気持ちは非リアじゃないとわからない。
「どうして普通にはてブに書かないのか。なんで増田なのか」とか「非リアを装って」
とかコメントしてる人たちがいたのですが、その人たちは非リアについてなんもわかってないアホだと思いました。
もともと自分で名前なり、アカウントを明かした上ではてブに投稿できるくらいの度胸があれば非リアになんかなってないです。それは自
分でもわかってます。
自己顕示欲が人一倍強いくせに、人に名指しで批判されるのが怖いから増田に投稿したのです。
フェイスブックに実名でウェブサービス作ったことを投稿できるような度胸があればそうしてますし、はてブに書けるなら書いてます。
そうするだけの度胸もなくて、でも誰かに認めては貰いたいから増田に書いたということをわかっていない。
③・ネットのみなさんが優しい。
今までネットの人たちは２ちゃんねるとかで炎上したり、なんか面白そうなものを見つけてお祭り騒ぎする、ちょっと怖い人たちという
イメージだったのですが、それが今回のことでガラリと変わりました。
本当に優しい人が多くて、どこの馬の骨ともわからない奴の作ったウェブサービスを使ってくれるだけでなく、感想や励ましのメールな
どをたくさん頂きました。
遥か雲の上の存在だと思っていた会社の方からもメールなどを頂きました。本当に感謝してもしきれません。
～技術編～
①・nodejsを使って外部にサービス公開するなら、認証は必須。主に不正な負荷を減らすために。
さっき書いた、「セキュリティについてはあまり書くな」という話と矛盾するのですが。
nodejs、すごくアクセスさばけて、なおかつ軽いということで便利なんですが、サーバーなので、基本的にリクエストを受けたら非常に素
直に返事します。
例えば、nodejsとsocket.ioを使って、単純にメッセージをサーバーに送るとして、クライアント側で
のようにすると、サーバーはどこから来たアクセスなのか、とか悪意のあるアクセスなのか？ とか一切気にすることなく、素直に'hoge'
これはつまり、第三者が悪意を持って大量にメッセージを送りつけるとそれを素直に受け取ってしまうということです。
なので、例えば大量に不正なデータを送りつけられたりするとレスポンスが悪くなります。
なので、悪意のあるアクセスはsocketにそもそも接続させない、という対策がサーバー側で必要になると思います。
socket.ioではコールバックを使って、簡単に認証させるかさせないか、という実装ができます。具体的には以下のURLなどを参考に実装す
http://d.hatena.ne.jp/Jxck/20110809/1312847290
②・nodejsの最大接続数は、ファイルディスクリプタに依存する
ということにしばらく気づかずに、最大接続数が４００ほどしか出ず悩んでいた時に以下のURLを参照して、なぞが解けました。
http://blog.livedoor.jp/mokepon/archives/182178.html
またsocket.ioのテストの書き方ですが、
http://d.hatena.ne.jp/toritori0318/20120902/1346591831
という素晴らしいエントリーがあったので参考にさせて頂きました。
■楽できるところは楽するためのツールなど。
nodejsの開発で、面倒くさいところはできるだけ楽しました。以下、便利だったものまとめ。
・node-dev
コンソールにデバッグ情報を吐き出してくれ、サーバー側のコードをいじくった時に自動的に再起動してくれる。
いちいちコマンドプロンプトからnodejsを実行する必要がないため、作業の手間がはぶける。
nodejsを触り始めた時はエラーを吐いてばかりなので非常に役に立ちました。
参考URL
http://d.hatena.ne.jp/replication/20110224/1298474534
・forever
様々な使い方があるようですが、stop,list,startの３つぐらいしか使いませんでした。まだ、研究中です。
参考URL（基本的な使いかたが非常にわかりやすく書かれています）
http://nantekottai.com/2011/08/15/node-js-based-service-with-forever/
・mongoose
ドキュメントは色々ググったのですが、結局公式のドキュメントが１番わかりやすかったです。
～モチベーション編～
■一人でウェブサービスを作る上で、心の支えになった記事。
http://d.hatena.ne.jp/Hamachiya2/20080131/security
とにかく楽しんで、作ってみることが大事だよ、というお話です。すごい勇気づけられます。
・小飼弾さんの産声の話。
http://blog.livedoor.jp/dankogai/archives/51837985.html
弾さんは、お金持ちで、腕は一流で、PHPこき下ろすし、なんかすごく怖い職人のイメージだったのですが、このエントリーを読んで、クソ
まみれでも産声を上げてみようと思えました。
実は優しい人なのかもしれません。私の高校時代の担任の先生にどことなく似ています。
■お詫びと訂正
前回の増田記事で、OpenPNEについて間違った記載をしてしまいました。ソースコード公開に関する記述の部分です。
OpenPNEではそのソースコードを改変したら、そのソースコードを公開しなくてはならないと書いたのですが、これは間違いです。
OpenPNE方々には大変ご迷惑をお掛けしました。申し訳ありませんでした。
あと入家さんに謝りたいです。
フェイスブックにもとりあげて頂いたそうで、ありがとうございます。
怖いのでどんな投稿なのかはまだ観ていませんが、本当にありがたいです。
■最後に。
ウェブサービスをコツコツと作り続けて公開したところ、増田記事のおかげもありたくさんの反響を頂きました。
ただ、別にウェブサービスを公開したからと言って、実際のところ何かが劇的に変わったわけでもないです。
グーグルアドセンスは支払い規定の一万円を超えていないので、手元には一銭も入ってきませんし、実名出して行動できなかったので現実
あいかわらず休日は地元のゲームセンターでレトロゲーをやって時間をつぶしていますし、学校から帰ってきたらももクロのライブを観て
、Chai Maxxを踊ってから寝るだけの毎日です。それでも結構楽しいのですが。
ただ、ネット上で様々な先輩エンジニアの方々や、同年代で同じようにフェイスブックが嫌いな方から励ましのメールをもらいましたし、
本当に、びっくりするような充実した二週間でした。
はてブで人気のエントリーにあがった時のスナップショットは未だに大事にとってあります。
tag-chat.net（http://tag-chat.net)を作って本当に良かったと思っています。
