操作方法

• l キー: 次のページへ
• h キー: 前のページへ
• j キー: 目次ページへ
• k キー: 目次ページから戻る
• 目次ページでは j k キーで一覧を移動し、クリックで選択します

、ライブドアではエンジニア採用してます！！１

昨日までのあらすじ

ikachanを紹介しました。お陰ではてなでも導入してくれるそうです。でも今日は IRC は主題ではありません。

社内向けプレゼンでやろうと思ってたネタですが、もったいないのでOpen&Shareしに来ました。

僕(や、他の人)が入社して2ヶ月くらいで調えた開発環境諸々についてアウトプットします

死霊をまとめてたら40min用のトークになりそうでしたが、気にせずLTします。

〜入社当日〜

まずは可能な限りありったけのircチャンネルに入った

どういう感じなのかを掴むのはもちろんだけど、全体を俯瞰しておく事で「ちょっとツール書いたら」便利になるのになー的なネタを拾ってきやすくなる

入社1-2週間目

社内 gyazo サーバはすでにあったけど、専用クライアントないので mac 版だけ作って配布

折角あっても、エンジニア以外が簡単に使えるようになってないので意味ない

僕が作ったら、他の神先輩が win 版を配布してくれた

社内 nopaste にコマンド一発で送信出来る gisty の nopasete 版コマンド作った

Webブラウザ立ち上げてformにsubmitするの面倒

X code 入れてない not エンジニアが簡単に使えるように ruby で作っておいた

こういう便利ツールは、普及して common インフラでないと意味が無い

その他、 JPA 会長に既存の社内ツールのまとめ wiki 作ってもらった

新入社員で情弱なので、とてもたすかった

ikachan

自分のプロジェクトでは、 deploy 通知から一部バッチ処理の終了通知まで対応するようになって、 irc 見るだけでプロジェクトの状況が把握出来るようになってきた

他プロジェクトでも nagios 監視の通知系が irc に出てくるようになってきた

ikachan 入れ多目的は、既存 bot の置き換えだけをもくてきとしてなく、各種状態通知を irc に流しておく事で、プロジェクトの状態をメンバー全員に通知、しかもツールに組み込む事で手間なく通知して、社内の情報共有密度を多くするのが目的なので、ちょっとした事でも気楽にながせるようにはしたい

流量多過ぎてうざくなってから絞ったりして考えればいいし

〜ささいなツール〜

twitter の url を irc に張ったら tweet 内容を irc に書き込む bot

url をわざわざクリックするとかあほらしいので、自分が関連するプロジェクトのチャンネルに放流

一日1000url張られるとして、1clickに1秒かかるとして、社員が1000人いたら、クリックするコストが一日あたり、1_000_000秒=100万秒=11.5日分の時間が無駄になる。これが時給750円の高校生バイト換算にすると、一日あたり208_333円のバイト代のコストがかかり、一ヶ月あたり約625万円のコストで、年間7604万円もtwitterのurlクリックに会社が金を払う事になってしまう。一般的な社会人の時給が750円とかは無いので、年間億単位のお金をかけてtwitterのurlをクリックする作業に支払う事になる。

ちょっとツールを書くだけでこれだけのコストダウンを実現出来てすごいですよね。

〜ステージングサーバの環境〜

本題ですが、次に説明する事を順番に徐々に行ってきました

grader tools

• grader-create branch, grader-remove branch
• コマンド一発で、ミドルウェアの設定と必要なサーバプロセスの立ち上げ/削除が行える
• ブランチ毎のステージング環境の管理が簡素化

create/remove したときは ikachan に飛ばしてる

staging status server

• ステージングサーバの各種詳細状態をブラウザで見れるように
• 現在動いてるplack list、ブランチリスト
• crontab でステータスを取って、静的ファイル配信

sql schema pages

• crontab で定期的に、 SHOW CREATE TABLE して、スキーマをブラウザで見れるようにする
• table 毎に md5 して、更新の合ったテーブルの検出をしやすくする
• 最初はおもに、誰かがテーブル追加した時に参考するだけのページでした

非エンジニア向け改修

• ブラウザでステージングサーバのファイルを git pull して svc -t するページ
• ブラウザで grader-create してくれるページ
• デザイン変更等は、エンジニアが関わらない事もあるので、非エンジニあに優しくしておく

create/remove したときは ikachan に飛ばすように grader script が作られてるので、エンジニアも常に把握していられるし、わざわざ作業報告する必要がなくて面倒さが無い

〜ローカル開発環境〜

local 2 staging

• local環境の ip address を定期的に status server に報告する
• 誰がどの ip address になるか解ってるので、トラブルになった時にすぐ助けられる
• 一括で開発用ファームウェアをアップグレードするときにも使える

diag.pl

• 開発用のイメージは、エンジニア意外も作業するので、 git やらサーバ落ちてるトラブルがたまにある
• 診断ツールを入れてある
• コマンドを叩くと、プロセス一覧、git cloneしたディレクトリの状態等々をまとめたリポートファイルを作成
• 作ったファイルは、最初に出た nopaste script でアップロードして、 url を ikachan に

create_table.pl

• vmの開発環境とステージングの schema が一致しなくなる時がある
• status サーバを見れば最新の定義がわかるので、それをダウンロードして反映

staging create/update/remove

• vmのシェル環境から staging create とやると status サーバの API を叩いて、ステージング環境を作る
• 非エンジニア向けの機能を使ってエンジニアに優しい環境をつくる
• わざわざ ssh する必要がなくなるので便利

tests

• prove plugin 書いて、 make test する時 prove 叩いたとき、最初だけテストDB作る
• ci tools, ukigumo
• 割愛

今までの流れからみて解る通り、小さいツールをいっぱい作って組み合わせて便利にしてる。 UNIX 思想的

最初から大きい事をやろうとすると、本当に作るのが大変。特に新人とかは成果を小出しに解りやすくしないと誰も評価出来ない。

小さい便利な物を、多く作って行くと、そのうち少し大きな要件を既存のツールを組み合わせて作れるようになる、いつの間にか、組み合わせの組み合わせでとても大きなエコシステムが作れる。

大元が小さいので、開発コストも低く方向性が間違っていたらすぐに取り消せる、実際に自分も途中まで作って没にしてるツールがいくつかある。

〜まとめ〜

小さな面倒だと思った事は、すぐに小さいツールで自動化するととても良いし小さい積み重ねで良い感じに効率よくなる。ネトゲのステータスとにたもん。

というか面倒くさがりやこそがプログラマ、怠惰こそが perl の美学ですよね。ということで perl にこじつけた感じで終わります。

以上です。何か質問がございましたら、社内IRCもしくは後夜祭などでお願いします。あ、あと

あと、ライブドアではエンジニア採用してます！！１