【Tech Women Advent Calendar 2014】今思えば笑える&背筋が凍る 私が犯したwebアプリケーション開発〜リリースまでの黒歴史（ゆるふわに10個）
※これはTech Women Advent Calendar 2014の1日目として書かれています。
こんにちは、@sinamon129といいますヾ[･ω･`●]
皆様からはしなもそとよばれています。
本題に入るまえに、この記事は、
Tech Women Advent Calendar 2014の一日目&私がカレンダー登録したということで、
少し前置きを。
http://qiita.com/advent-calendar/2014/tech_women
Tech Women Advent Calendar 2014 - Qiita
こちらのアドベント・カレンダーは、
TechなWomenのためのAdvent Calendarで、興味のあるプログラミングなどの話題（分野問わず）や、最近流行りの○○女子部（ex. Linux女子部,Android女子部, Pyladies等）での活動の様子などの発信をして、盛り上がっていく！ことが目的のカレンダーです！
techなwomen人口は少ないと感じているのですが、女子部系の活動も盛り上がってきていることですし、更に盛り上がっていければと思っております！
そんなところで、本題に。。
今思えば笑える&背筋が凍る 私が犯したwebアプリケーション開発〜リリースまでの黒歴史
今私は社会人一年目なのですが、大学生の時の昔話をしようとおもいます。
あれは大学三年生の冬でした。
当時関わっていた、当時学生のメンツだけで作っていたwebサービスがありました（今もあります）。
その頃、私のwebアプリケーション開発経験は今より本当に乏しかった時期に、
たまたま、関わっていたサービスがありがたいことに、テレビやSNSのシェアでアクセスが沢山来た時に、
色々奮闘した際にやった、今思えば笑える&背筋が凍る話。
（時系列が案外バラバラになってしまった）
1．バージョン管理などされていない！？開発機で上書きされまくり
第一バージョンを作っている時は、gitの使い方もあやしい時期だったので、複数人で同じサーバのデータを編集していました。
cssをなおして、よっしゃ！っておもってリロードすると、まさかの元にもどってる！？コードも元に戻ってる…うああああ。
その後バージョン管理をはじめました（学び）
2．本番DBを直接GUIツールで編集しまくり
特に深夜帯でもなんでもない、アクセスが集中する時間帯に、データ更新のために、レコードを直接編集したり、カラムを間違えて消したりしていた。
うわーしくったとかいいながら、消す前にとっておいたダンプファイルになおしていた。
3．コントローラーが全て しかもメソッド一個
フレームワークはCakePHPだったのですが、複雑なロジックも全部コントローラーに書いてある。もちろんテストなんて一個もない。コワイ
ひさびさによんだらこれはひどいって感じだった。
4．間に合わないところは全部静的ページ状態
エンジニアの手をつかわなくても更新できるとか、ピックアップ的なものを用意していたりしたのですが、間に合わなくて全部ただのhtml
最後まで仕組み化できず
5．データは頑張って手動でどうにかする
データの更新をエクセルでもらう
エクセルからcsvで保存&文字コード改行コード変換（coteditorで）
&DB格納用に変換（一応自前スクリプト）
（絶対自動化できる）
6．最初にアクセスが沢山きて、サーバが重くなった時、攻撃されてると思っていた
さくらVPSの一番低いプランのサーバ一台構成（DBサーバはもちろん別ではない）だった時期に、
重すぎてみれないという報告をうけ、
とりあえず本番サーバに入って、インターンで覚えたてのtopコマンドを打つ。
そしたらロードアベレージが見たことない数値（記憶があやしいですが、桁が二桁ぐらい違う？）。
意味不明だ！これは攻撃されている！やばい！
と助けを求めましたが、アクセスがたくさん来ているだけでした。
mysqlのテーブルに一個もインデックス貼ってないわ、キャッシュもなにも設定してない状態でした。
いろんな人に助けを求めて何とかチューニングをして事無きを得ました。（入ってる状態で固まって為す術がなくなり再起動しました）
7．明日はテレビだから、とりあえずサーバーを増築？しましょう事件
翌日テレビに出ることになったけど、そもそもテレビに出たらどれだけアクセスが来るかはかりしれず（なにもわかってない）。
出るのは朝のニュース番組で、日付が変わって当日（0:30ぐらいだった）になってから、やっとサーバーの設定をスタート（ようは6時間半ぐらいしかない）。
時間がないので、とりあえず増築というか、スペックのいいサーバに交換することに（DNSの再設定が必要）これが後あと悲劇を呼ぶのだった。。。
7.1 サーバを変えるために、設定して、リポジトリをクローンしたけど、アプリケーションが動かない
apacheの設定、mysqlを入れて起動したのに、動かない。なんでだああああ。
となって、チームメンバーと確認してたら、phpが入ってなかった（cakePHPでつくったアプリケーションでした）
7.2 深夜帯の作業のため、遠隔でやりとりしていたチームメンバーの連絡が途絶える
やっとアプリケーションがうごくようになったし、データも前のサーバからとってきたし、お名前ドットコムで設定も切り替えたし大丈夫だ！
っておもって、メンバーにできた！って報告したら、反応がない。
みんな寝落ち…ｗ（メンバーはみなリモートでやりとりして開発していました）
7.3 お名前.comページが見える
朝の情報番組で人が来ているのを無事analyticsで確認してチャットに書き込み、
とりあえずその日面接だし（就活生）仮眠をとって、電車に乗り込む。
そしたら、【お名前ドットコムのページがみえるんだけど…？】との連絡。
その日の夜、もう一本大きい番組の放送がまっていたのに、まさかのお名前トッドコムのページがみえる！？なんで？
実は、深夜作業の時に、DNSレコード設定で、まさかのリセットボタンを押していました…
その後、設定しなおしたのですが、まあリセットの設定が一度反映されてしまってるので…（察し）
7.4 IPアドレスをfacebookページに貼る
どうしようもなくなってしまったので、
テレビ番組に、アクセスが多くてつながらなかったら、facebookページをみてくださいと伝えてもらい、IPアドレスを書いた
8．mysqlとアプリケーションが同じサーバにあるのを２つ作ってロードバランサにつないだ
二箇所の別のマスターDBにデータが分散して格納される（しかもどうやって一緒にすればいいかわからない）みたいなひどいことが起きてた
9．バグったから、本番サーバを直接直す
テレビ放送何分か前に、git管理してた方のブランチがリリースできる状態じゃなくなり（masterしかなかったし、何処に戻ればいいのかすら謎だった）
しょうがないので、本番サーバのコードを直接直した。
