開催前から話題先行しまくりのペアプロ合コンを3/24(土)に開催してきました。
言いだしっぺ@happa_no_koのもと20人近いスタッフで協力しなんとか開催できました。

ご参加いただいたみなさまありがとうございました。
おかげさまで楽しくできました。

KDDIwebコミュニケーションさまありがとうございました。
あの会場だからこそ、こんなに楽しくできました。

スタッフのみんなお疲れさま！
いろいろ不安もあったけど、予想を上回る大満足のできだったね。
やってみて改善点も見えてきたので、ちょっとずつでも次回以降に活かしていきましょう。

※念のため※

このエントリの記載は私の個人的な意見とか見解なので、 ペアプロ合コン運営チームとしての意見ではありません。

当日の雰囲気

準備段階でいろいろ工夫してきて、まずいことにはならない確信はあったんだけど、正直なところここまでイイ感じになるとは思ってなかったです。

ちなみに運営からのお題は 「マイクロブログ」 に決定。 これは、認証なしならscaffoldで簡単に実装できるだろうと踏んでのことでした。

当日の段取りは概ね下記なんだけど細かい時間は覚えてません。

• 会の趣旨説明
• ペアプロの心得説明
• ペアプロ
• 休憩+ワールドカフェ
• ペア替え
• ペアプロ
• 懇親会
• 中締め
• 二次会@居酒屋

中締めまでが13:00〜19:00、その後は終電近くまでワイワイ、という感じでした。

参加者視点での雰囲気はtogetterなどを見てみてください。

はっきり言って羨ましかった。

いろいろ想定して見張りワンコする予定だったんですが、 いらなそうなので暇を持て余し別会場で開催中だったチューニンガソンに飛び入りリモート参加させてもらってました。

開催の裏側

せっかく運営側なので、今回の運営秘話というか、 いろいろ気にしていたところを公開してみます。

いろいろイベントしてきましたが、 正直なところここまで真剣に詰めてやったのは初めてです。

大原則は 「いかに女子に満足してもらうか？そのために男子が頑張る」 でした。

以下ツラツラと。

メンバー募集

なんせまず心配だったのが、女性が応募してくれるかどうか、来てくれるかどうか。 集客についてはオンラインでの告知、女子部カンファレンスなどのリアルイベントでの告知によりひとまず定員達成して安堵。

男性については全く心配してませんでした。 きっと友人知人だけでも十分あつまるだろうなー、と。。。

男性側がリードできる状態にしておく

※ただし実際にリードするかどうかはペア次第で

このために、男性側はご参加いただくに際して 本当にコードが書けそうな人 にさせていただきました。

本当にコードが書けそうかどうか確認するために、githubアカウントを教えてもらい、スタッフが 全部 確認しました。
→このgithubアカウント教えてください連絡に返事がない人が多数だったので、実際の倍率はそんなに高くなかったんですヨ

zusaarのメッセージ送信機能で何度かpushをしたのですが、返事をくれたのは20〜30名程度でした(うろおぼえ)。 「コードが書けることを確認したい」「締め切りは来週」など、 割とわかりやすく いままでの蓄積がなくても、何か作っておいてくれればいいよ 感を出したつもりだったのですが いまいちうまく伝わっていなかった方もいたようで残念です。。。

また、男性側の当日準備として ローカルPCにコーディングと稼働環境の作成 をお願いしました。

ちなみに、コーディング環境作成に際して、テキストエディタばりに普通のエディタも用意してもらえるようお願いしました (「なんでvim/emacsだけじゃダメなんだ！」とか言う時点で向いてないと思う)。

男女で組めるようにしておく

コレ超大事。行って男同士だったらドンビキだものね。。。

実現するために、スタッフで男女3〜4人ずつの 念のため要員 を確保しました。 RoR/CakePHPとスキルが2種類あったので大変だった…。

ちなみに当日ふたをあけてみると女性のほうが参加率が高く、男性スタッフが多く出動しました。

男子がんばれよぅ

女性に気持ちよく楽しんでもらえるようにしておく

このために、ある程度のスキルマッチングをしておきました。

応募時点のアンケートでプログラミング経験や希望などをアンケート調査しました。 女性側の結果から、環境をRuby on Rails/CakePHPに決定。

また、途中でペアを変更できるようにして何かあった時に気分転換できるようにしました。 ただ、我々も勝手がわからず続けたほうが満足感が高いかもしれないという面もあり、 当日迷いが出てしまいグダグダでした(^^;)

司会も迷いまくりで

• 「みんな目をつぶれ！」
• 「ペア続けたいやつは手を上げろ！」
• 「よし！手を上げなかった奴は教室の後ろへ移動！」

ってアナウンスを聞いた時はずっこけましたｗ

ちゃんと交流してほしい

ペアプロ中の見回りを予定してましたが、どんよりした感じのペアがなかったので暇でした。 むしろ割り込めない。

休憩時間のワールドカフェはスタッフが随時入り…ましたがやっぱり雰囲気がよすぎてやることないので、 スタッフ同士でワールドカフェしてました。 まぁぼくはチューニンガソンしてましたが。

懇親会ボッチ対策も考えてたんですが、ぼっち少なすぎてやることなくて酔っ払っちゃった(´ε｀ )

次回以降

楽しかった。またやりたいね！

あと、今度は混ざりたい！

いろいろ至らない点もありましたが、 まぁ気がついた順とやりたい順で改善していくものと思います。

「こうしたらいいな」はいろいろあったんだけど、 何より開催することに意義があると思うし、 減点方式よりも加点方式で暖かく見守っていただければ幸いです。

個人的にはエンジニア向けイベントの開催経験が何度もあるので、 今回は主催とかチームをまったり見守る…つもりでしたが、 ちょっと前に出すぎたかもしれません。

次回はもっと後ろで…ペアプロしてようかな…30歳独身だし…。

ちょっと諸事情あって現地できちんと参加はできなかったのですが、 @zakiさん、@KenTamagawaさんはじめ皆様のご好意で、 なんと途中からリモート参加させていただきました。 ありがとうございました！

今回はjavaのblojsomだったんだけど、 CPUのusr張り付き回避がテーマだったので jvmチューニングに終始しました。

とりあえずひと通りOSチューニングしたあと、 jvmをJRockitに変更してゴニョゴニョ。 ドキュメント読みきる時間がなかったから、 いかに計測時にjitが温まった状態にするかを何度か試してました。 MySQLはボトルネックじゃないからノータッチ。

何度か計測するとJRockitがコア吐いて落ちていたため、 急遽cronで落ちてたら起動する(+jit温める)スクリプトを書いて その場をしのいだりとドタバタ。

いま思えば、最速構成は↓だったなぁ。

• 別のtomcatをフロントに立てる
• 「URL baseでキャッシュしてPOSTがきたらそのキャッシュをリフレッシュする」プログラムを書いてフロントにデプロイ

レギュレーション的にギリギリの線だけどアウトではないはず…。

いろいろお願いして無理矢理参加させていただ割に ますだっｋに負けるという感じで結果振るわず申し訳ないんですけど 次回もできたら懲りずに参加したいです！

著者はあの松信さんなので、もう期待大。
すでにkazeburoさんやら銀河さんこと桑野さんやらはてな田中さんやらりーおさんやらがreviewしていますので内容はさておき、感想とオススメポイントを紹介します。
(りーおさん同僚だからサインとかもらっちゃうのかな)

どんな本？

正直なところ、1st stepの入門書としては難しい(カタい)。まさに実践入門。

どんな人にオススメ？

• 開発/運用など現場で体当たりでやってきたけどイマイチ伸び悩んでいる人、なんだか不安な人
• 基礎の大切さが胆落ち(ハラオチ)した人

ソフトウェア工学とか計算機化学の基礎の大切さに薄々気づいてきた人にぜひ読んで欲しい！

ここがステキ！

• 「データを入力し、データを出力する」というITの基礎の基礎を振り返るきっかけになる！

そもそもシステムというものはデータを入力して加工して出力するするものなので、 「データ」はUI・UX / application / infrastructure / business など、 すべてのレイヤーにまたがるテーマなのです。

データを いつ / だれが / どれを / どのように 入力・加工・出力すべきか、改めて考えてみやしませんか？

↓と、いうわけで、一家に一冊ぜひどうぞ！

大層な話じゃないです。

あとfluentdをdissりたいわけでもないです。
使ってみてすごい使いやすかった。すばらしい。
ただちょっとだけ気をつけとかないと、という話。

遭遇した問題

• 前提
  • fluentd-0.10.11(td-agent)
  • アクセスログ(データ不正的な感じ)を複数行まとめて投入してtailで読み込み
  • アクセスログの2行目以降にUTF-8なマルチバイトが含まれる
  • アクセスログをparseしてfileに書き出したい
• 事象
  • 複数行投入したうち、マルチバイトを含む行以降がfileに出力されず
  • ログファイルに元データが出力されず。ログには unexpected error error="\"\\xEF\" from ASCII-8BIT to UTF-8" が出力

どういうこと？

まとめて投入した一連の途中で出力処理がエラーになっていて、以降の処理(=マルチバイトを含む行の次の行以降を出力する処理)が実行されない。

マルチバイトを含む行はエラーとして別の(システム側の)ログファイルにデータをまるっと出力しつつ、次の行以降の出力は継続してほしかった。

んで？

解析データの収集ツールとして使う分にはいいと思います。すごい使いやすいし、解析しやすい。使ってみて感動した。

ただし、現状ではログが消失する可能性があるので、ログ収集という意味合いでは使えないのです。
想定外のログ出力が消失してしまうので、不正アクセスみたいな問題があった時にトレースできなくなっちゃう。

syslogの代替に、って考えてるひとはご注意を(いないかな?)。

とても楽しく、貴重な経験ができていい2日間でした。
金曜20:00に集合して、初日はいきなり23:00頃まで懇親会。
懇親会中にテーマ決め&チーム分けをして、その後はチームごとにひたすら作業。

好きな時に寝て、好きな時に起きるスタイルで翌日18:00までコツコツとがんばりました。

テーマ・チーム決め

テーマは主催さんたちが3つほど用意していましたが、それよりも思いついたやりたいものを優先ということで3チーム中2チームが自由選択でした。
懇親会でワイワイ話してる中でなんとなく気になることが形になってきて、なんとなくその場の流れでテーマごとにチームをつくるという極めてオトナな方法でテーマ・チームが決まりました。

今回は @sguaynさん、@do_akiさん、@yut148さんと4人で「Ruby on Rails or Redmineのプロファイラ作ろうか」って話でスタートしました。
命名:チームますだっく、だったんですが、チーム決めの中で@masudaKさんが移籍流出してしまい名前負けに…(ﾉД`)

ちなみに採用されなかったけど、「WordPressをhiphop対応させる」なんてアイデアも出てました。

紆余曲折

懇親会から帰ったらすぐに作業開始。
なんせテーマがフワフワしてるので、まずは各種言語のプロファイラを調査…してたら眠い…ということでうちのチームは1:00頃に早仕舞。
翌日がんばることにします。

翌日になってみたらみたで、さてどうしましょうという感じ。
最終的には「大事なのはデータのvisualizationだ！」ということで、ログをvisualizeするツールをつくることにしました。
もう思いっきり@kazeburoさんインスパイアって感じ。

このログがメンバー持ち込みのリアルログなもんだから、このあといくつかの問題を引き起こすことに…

ようやっとスタート

最終日の朝にテーマが決まるというスロースターターぶりを披露した我々ですが、アーキテクチャをざっくりと決めて9:30頃(うろおぼえ)には手を動かし始めました。
決めたことはざっくりこれだけ。

• アーキテクチャ: fluentd -> mongodb -> node.js -> JavaScript側でグラフ描画
• 担当
  • ログファイル -> fluentd @netmarkjp
  • fluentd -> mongodb @yut148
  • mongodb -> view @do_aki
  • visualize @sugyan

fluentdはTreasureDataのリポジトリからtd-agentをyumでさっくりインストール。fluent-plugin-mongoも入っててラクチン。
mongodbも10genのリポジトリからyumでさっくりインストール。
node.jsはちょっとよくわからなかったけど、nvmからインストール。 構築超簡単。

自分はfluentdもmongodbもnode.jsもちゃんと触ったことなくてどうなるかドキドキだったけど、簡単でえがった。

決まってからはさすがにみんな手が早くて、色々な問題に遭遇しつつだったけども18:00の締め切りまでになんとか形にすることができました。

↓発生してた諸問題(一部)

• fluentdにencodeできない文字列を渡したとき、複数行まとめて入力してfileに出力していると途中で出力が途切れる(未解決)
  • リアルログならではの「想定外のデータ」が引き起こした問題でした
• fluentd -> mongodbデータ連携してるときに、一気にでかいデータを渡すと buffer_chunk_limit を小さく設定しても Exceded maximum insert size of 16,000,000 bytes のエラーになる(@repeatedlyさんが対応してくれてる)
• highcharts.jsで棒グラフに3分分(3〜4桁くらい)のデータを渡すとブラウザが固まる。折れ線グラフなら大丈夫。(未解決)

18:00で作業終了して、発表会。
みなさんちゃんと形にしてて、やっぱ作れる人はいいね〜と思った次第。

解散した後は有志で月島までいってもんじゃしながら打ち上げしてきました。うまかった！ｗ

まとめ

どうにも締まらない文章で大変申し訳ないんですけど簡単にまとめると、とても充実した2日間(1.5日)でした。
普段なら組めないような人とチームを組んで開発できて、対応とか問題解決の速さに驚くことしきり。とても勉強になりました。
また機会があれば参加したい！

運営のみなさん、お疲れさまでした。ありがとうございました。

今年は地震の影響で考えることが多かった。
地震がきて、いろんなことを「リアルに」感じて考えるようになった気がする。

人生観が変わったひと、変わらなかったひとがいたみたいで、人によってさまざまなのは当然。
自分に限って言うと、人生観はかなり変わったと思う。
体を動かしたり、声を出したり、人と交わったり…身体性の高いことを重視するようになったなぁ。

あと、考えることが多くなった。

考えることの一番は原発かなぁ。

声高に賛成も反対も言えてないけれど、原発怖いなと思ってる。

とても手に負えないものなんじゃなかろうか。

原発止めると経済が…って理屈で原発推進してる人もいるみたいだけど、 その理屈は、実は戦時中の

「米兵につかまるくらいなら玉砕もしくは自決すべし」

とかそういう視野狭窄と同じなんじゃなかろうかとも思っている。

でも判断材料がないんだよなぁ。

いままで自分からは遠い話だった原発のこと、 身近に感じて考えるようになってきた。

IT産業で電気をじゃぶじゃぶ使ってる身だからこそ、 いろいろ考えて行動していこう。

とりとめもないけど、何かの折に思い返すきっかけとして残しておこう。

ちなみに作成した図はアプリケーション構成を表す図です。
厳密に記法など決めているわけではないですが、 トラブルシュートなどのときに大まかな構成を把握するのに使います。

できた図 & wishlist

• ネストしたグループのラベルが重ならないようになってほしい
• ネストしたグループのサイズがきっちりになるので、大きい方は少し余裕をもったサイズになってほしい
• ノード間接続のラベルが重ならないようになってほしい
• ノード間接続のラベルのサイズを自動拡張してほしい(…にならないように)
• apache -> mysqlのところとか、disk -> diskのところとか、ノード間接続で直角線コネクタと曲線が選べるといいなぁ
• ノードの縦サイズをテキスト内容にあわせて自動拡張してほしい(特に改行が入っている場合)
• apache -> diskのところは縦一列にならんでくれるとキレイだなぁ
  • apache -> diskのところを子groupにすることで解決できた！(2012.1.5追記。ソース未反映)

誰かなんとかしてくれないかなぁ。
自分で書けって話かなぁ。時間かかりそうだ。。。

ソース

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

diagram {
 
    internet [shape="cloud"];
    firewall[label="firewall\n(shared)"];
    vip_lb[label="VIP",shape="beginpoint"];
    keepalived_lb01[label="keepalived"];
    keepalived_lb02[label="keepalived"];
    keepalived_lb01 -- vip_lb[folded];
    keepalived_lb02 -- vip_lb[folded];
 
    proxy_web01[label="proxy"];
    apache_web01[label="apache+php"];
    disk_web01[label="disk",shape=flowchart.database];
    proxy_web01     -> apache_web01;
    apache_web01    -> disk_web01[folded];
 
    proxy_web02[label="proxy"];
    apache_web02[label="apache+php"];
    disk_web02[label="disk",shape=flowchart.database];
    proxy_web02     -> apache_web02;
    apache_web02    -> disk_web02[folded];
 
    mysql_db01[label="mysql\n(master)",shape=flowchart.database];
    mysql_db02[label="mysql\n(slave)",shape=flowchart.database];
    mysql_db01  -> mysql_db02[folded,label="replication"];
 
    internet    -> firewall -> vip_lb;
    vip_lb      -> proxy_web01,proxy_web02;
    apache_web01,apache_web02 -> mysql_db01[label="insert/update"];
    apache_web01,apache_web02 -> mysql_db02[label="select"];
    disk_web01  -> disk_web02 [folded,label="rsync"];
 
    group lb_group {
        color="#882222";
        textcolor="#660000";
        shape=line;
        style=dashed;
        label="Clusterd Load Balncer";
        group lb01_group{label="lb01";keepalived_lb01;};
        vip_lb;
        group lb02_group{label="lb02";keepalived_lb02;};
        };
    group production_group { 
        color="#882222";
        textcolor="#660000";
        shape=line;
        style=dashed;
        label="production";
        group web01_group{label="web01";proxy_web01;apache_web01;disk_web01};
        group web02_group{label="web02";proxy_web02;apache_web02;disk_web02};
        group db01_group{label="db01";mysql_db01;};
        group db02_group{label="db02";mysql_db02;};
        };
 
    stg-proxy_web01[label="proxy"];
    stg-apache_web01[label="apache"];
    stg-disk_web01[label="disk",shape=flowchart.database];
    stg-apache_web01    -> stg-disk_web01[folded];
 
    stg-mysql_db01[label="mysql",shape=flowchart.database];
    vip_lb  -> stg-proxy_web01;
    stg-proxy_web01 -> stg-apache_web01;
    stg-apache_web01   -> stg-mysql_db01;
 
    group staging_group { 
        color="#882222";
        textcolor="#660000";
        shape=line;
        style=dashed;
        label="staging";
        group stg-web01_group{label="stg-web01";stg-proxy_web01;stg-apache_web01;stg-disk_web01};
        group stg-db01_group{label="stg-db01";stg-mysql_db01;};
        };
 
    }

今日はさらにコアなネタに。

みなさん、シリアル通信することってありますよね？
ネットワーク機器に接続して設定したりとか、とかとか。

そんな時にもscreenが使えちゃうんです。 ちなみに私はMac(MBA Snow Lepard)で使ってます。

screenでシリアル接続する

1. ケーブルをつなぐ。最近はUSBタイプのものですね。ドライバとかは入れておいてください
2. screenでつなぐ

たとえば、USB接続のシリアルが /dev/tty.usbserial に接続できた場合は下記のように接続します。
※Ctrl-aではなくCtrl-zの場合

screen -e ^z^z  /dev/tty.usbserial 115200

xmodem転送する

ネットワーク機器のファームウェアアップデートのために、xmodem転送でデータを送信したいことってありますよね！
そんな時にもscreenでうまいこといけちゃうんです。

step0. lrzszをインストール

準備は簡単。brewでlrzszをインストールしておきましょう。

brew install lrzsz

では使ってみましょう。

step1. 接続する

上にかいてありますね。 ここでは特別なことはありません。

※Ctrl-aではなくCtrl-zの場合

screen -e ^z^z  /dev/tty.usbserial 115200

step2. 転送する

※Ctrl-aではなくCtrl-zの場合(しつこいかな)

Ctrl-z
:exec !! /usr/local/Cellar/lrzsz/0.12.20/bin/lsx -kb /Users/baba/Desktop/firmware.img

※パスとかは適宜読み替えてください！

・・・とまぁこんな感じで、懐かしのxmodem通信もできちゃいます。
xmodem通信とか、パソコン通信時代に◯☆△◇な画像をダウンロードする時にしか使った記憶がないんですが、 知っておいて損はないと思います。
得があるかはわかりませんが気にしたら負け。

ノリと勢いでAdvent Calendarしたくてそのためにblogを移設したんだけど、 実はそんなにネタなかったりして。

と、いうわけで、今回は手持ちのtipsを紹介します。

その1. ログインしたら自動でscreen

.bashrcに自動でscreenが起動するように仕込めば、 今日からあなたもとても自然にscreen使いになれちゃいます。

自動screenデビューしたい？ そんなあなたは↓のコードを .bashrc に書きましょう。

if [ $TERM != "screen" ]; then
    if [ $TERM != "dumb" ]; then
        screen -e ^z^z
    fi
fi

ポイントは次の2つ。

1. 無限ループしないように、 $TERM が screen の時はscreenを起動しない
2. SCPが使えるように、 $TERM が dumb の時はscreenを起動しない

その2. 画面がチラチラするのが嫌！

screenでは、TAB連打で候補を出す時などにaudio bellの代わりにvisual bell(画面がチカチカする)が発動します。 でも、visual bellって画面チカチカするしすんごい見づらいですよね。 そんな私に共感してくれるあなたは ~/.screenrc に↓を書くと幸せになれるかもしれません。

vbell off

その3. 敢えて hardstatus を使わない

~/.screenrc に、頑張って hardstatus 云々って書くと、 画面上に時計やらウィンドウ一覧やらを表示できるんですよね。

これがまたカッコいい。 サイバーな感じで、こうなんというか、ハッカーっぽい！

でも私は、敢えて hardstatus を使わないのがお勧めです。

例えばMySQLで show table status した場合、 横幅広すぎでTerminal上では見づらいので、 手元のエディタにコピペしたくなりますよね。

そんな時も hardstatus を使っていなければ安心。 ターミナルソフト(MacならTerminalやiTerm)のスクロールバーを利用して少しだけ楽をしましょう。

なんとスクロールバックすれば出力がまるまる残っているではありませんか。 この出力をターミナルソフトの機能でコピーしてあげればokです。

データの移行はとても簡単。
ちゃんとパーマリンクも保持できます！

1. [MT] MTの管理画面からExportでデータをファイルで出力
2. [WP] 設定＞パーマリンク設定 をカスタム構造の /%year%/%monthnum%/%postname%.html に設定
3. [WP] プラグインのMovable Type and TypePad Importerをインストール
4. [WP] ツール＞インポート から1.で出力したファイルをアップロード
5. [WP] MySQLに直接ログインしてパーマリンク修正
6. [WP] Analyticsのtop30くらいを見て、不具合がないか確認。見栄えを適当に修正

※パーマリンク修正方法

$ mysql -u <WP_DBUSER> -p <WP_DBNAME> -h <WP_DBHOST>
mysql> UPDATE wp_posts SET post_name = REPLACE(post_name ,'_','-');

サーバ設定

以下はデータ移行には関係ないけど・・・

今回は思うところがありフロントにnginx、バックにapacheをおいて、 apache側でwordpressを動かしてます。 そんなわけでちょっとだけ設定をメモ。

nginx

server {
    listen       80;
    server_name  netmark.jp *.netmark.jp;
 
    access_log  /var/log/nginx/log/netmark.jp.access.log  main;
 
    location / {
        proxy_pass   http://localhost:8002/;
        proxy_set_header        Host            $host;
        proxy_set_header        X-Forwarded-For $remote_addr;
    }
}

apache

UseCanonicalName On
Listen 8002
<VirtualHost *:8002>
        ServerName  netmark.jp:80
</VirtualHost>

これで今んとこうまく動いてます。