KLab若手エンジニアの これなぁに？

ご無沙汰してました! sasaki-k です。

遅れてしまい申し訳ございません。先日ご案内した表題の「チキチキIRCボットファイターズ!」社内投票と読者の皆様のはてなブックマークと、いいね！を合計した結果をご報告いたします。
Continue reading »

こんにちは!　もう一人の sasaki-k です。

以前からpythonの twisted でなにか作ってみようと思っていたので、技術の無駄遣いネタとして
「常駐型IRCプロキシサーバ」を作ってみました。

バッチプログラムからIRCへ何度も発言させようとすると下のように都度joinとquitしてしまい、
「邪魔だなあ」と言われることが多かったのが背景です。

23:02 *hoge-bot join #channel (~hoge-bot@xxxx.klab.jp)
(発言)
23:02 *hoge-bot quit (Remote host closed the connection)
23:02 *hoge-bot join #channel (~hoge-bot@xxxx.klab.jp)
(次の発言)
23:02 *hoge-bot quit (Remote host closed the connection)

そこで、 Continue reading »

暑い日が続きますが、皆様いかがお過ごしでしょうか。sasaki-kです。

さて、KLabでは社内コミュニケーションツールとして IRC を活用しています。
中にはIRCボットもおり、色々と仕事の役に立っています。

そこで読者の皆様に社内の雰囲気をお伝えするのと同時にお祭り気分を
盛り上げるため、この若手ブログの場をお借りして、今日から2週間程の期間で
KLabの社員が作ったIRCボットを自慢する会を「チキチキIRCボットファイターズ!」
として開催いたします。

作成したボットに特にジャンルは設けてなく

• 技術の無駄遣い
• ひらすらウケ狙い
• やっぱり実用本位

等々・・・法律、公序良俗に反しないものでしたらなんでもOK。

そこで本ブログの読者の皆様に少しだけお手伝いいただければと考えている
ことがあります。hatena book mark あるいは facebook いいね! ボタンで
「いいな」と思われた ボット を応援していただけますでしょうか。

この応援の数と社内の投票によって優勝者を決定し、この若手ブログ内で
お知らせしたいと考えております。

皆様、どんなエントリーがあるかお楽しみに！

以下要領となります。 Continue reading »

yoshida-kです。

社内で仙石CTOより、「このの本を読んでみたい人いないー？」っとの
メールが社内に流れたため、条件反射で手を上げちゃいましたｗ

yoshida-kは、最近負荷対策を行ったりすることが多く、「大規模サービス」だったり
「データ構造、メモリ、DB」などのキーワードに敏感に反応してみたりします。

この本は、株式会社はてな様のサマーインターンで、学生向けに行った講義内容を
元にかかれて、大きく分けて３つの話題が書かれています。

1.大規模サービスにおいて発生する「悩み」と悩みに対しての「考え方」の概論
2.大規模サービスの「悩み」に対しての「実践」と「実例」
3.大規模サービスを「運用」する上でのインフラ基礎知識
といった感じでしょうか？

それぞれをピックアップすると

読んでみた感想ですが、今後KLabに入ってこられる新卒の開発者の方や若手のアプリ開発者にぜひとも一度読んでいただきたい！！
とりあえずWebアプリは作れるが、負荷対策とかはさっぱりデスヨーーって方は特に！

なぜか？
その理由はいくつか（いくつも？ｗ）あります。

1.大規模の規模感の説明、そこから発生する問題の大きな部分から話が始まり、それぞれの問題を一つ一つブレイクダウンした形で解説されていく構成になっており、大規模サービスの負荷の全体像をつかみながら問題を理解していける本の構成

2.ヒットするかどうかが博打的なWebサービスにおいて、開発コストやスピードと安定性のトレードオフが存在する「現実」を前提として書かれているため、知識本で有りながら実用的な内容である点

3.ハードウェア・OSなどのプログラムを書くだけならばあまり気にしないが、高負荷サイトの開発時には気を配らなければならない点が、図解を添えて、どういう動作をしているから、こういう負荷になるといった形でOSやハードウェアに対しての知識がない人にも解るように書かれている点

この辺りが特に気に入った点でしょうか。

普段は慣例だったり、先輩方に教えていただいたknow-howなどでdisk readを避けたり、cacheを利用したりするコードを書いていたyoshida-kですが、この本を通して「なぜ早くなるか」、「なぜ必要か」といった知識を得れたことはとても大きい収穫でした。

あと、急いで読んじゃって中にあった課題にまだチャレンジできていません。
せっかくなのでチャレンジして、またブログに書かせていただこうと思います。

yoshida-k

特に若くもないuchikawa-yです。はじめまして。

KLabの「自由に研究していい」どぶろく制度でやったことを紹介します。

発端

電波時計はJJY(日本の標準電波)等の時刻情報の放送を受信して時刻合わせを行います。この放送は鉄筋コンクリートの建物内ではかなり弱くなるので電波時計はマンションやオフィスビル内では使えない場合が多いです(このことを知らない人が多いのも事実です)。
日本標準時プロジェクト　Q&A
日本標準時プロジェクト　標準電波（電波時計）の運用状況

弊社におきましても以下のようなことが起きたことがあります

1. 会議室などに設置する時計に電波時計を購入した
2. 初期状態で手動などで正確な時刻を設定したのでしばらくは正常に使える
3. JJYが受信できないのでそのうちに時刻がずれる　異常動作で大きくずれた時刻を表示したものもあった
4. 「故障した」と判断されて何台かは廃棄された

悲しい事件ですね。この後、私の雑な調査によれば本社オフィスでは電波時計が正常に動作するのは窓から2～3m程度の範囲に限られることがわかりました。

展開
鉄筋コンクリートの建物内で電波時計を使うための中継装置というものがあります。
Webで調べたところリズム時計工業という会社がJJYの中継装置を製造、CITIZENブランドで販売しているようです。通販などでは入手もできるよう です。
これは2万円程度するようなのでもっと安くなんとかする方法はないか考えました。

思いついたのは外部アンテナを使う方法です。外部アンテナをJJYの電波を受信可能な場所に設置し、同軸ケーブルなどの有線で電波時計の場所 まで送ります。電波時計とケーブルの間は数ターンのコイルで結合させます(具体的には電波時計に内蔵されているアンテナのありそうな部分に導線を巻きつけ ます)。

空中線(アンテナ)
JJYの放送局は日本に２ヶ所あります。福島県から40kHz、福岡県から60kHzで放送されています。東京の場合福島県の40kHzを主に利用しま す。これは長波と呼ばれる帯域で、通常は中波ラジオで使われるようなバーアンテナやループアンテナを使用します。今回は無調整で使用できて、バーアンテナ よりも性能の良いものが作れるマグネチックループアンテナを作ってみました。
これは以下のページに詳しい内容があります。　作成したアンテナは不平衡型です。
受信専用マグネチック・ループアンテナ

配線用のダクトをフレームにしました。サイズは(62cm×48cm)です。これに同軸ケーブル(1.5D-2V)を5回巻いたものをアンテナにして います。　電波時計との間のケーブルも1.5D-2Vです。
ケーブルの特性についてはたとえば 古川電工　メタルケーブルの「同軸ケーブル・高周波同軸ケーブル」のページにある詳細PDFが参考になります。
1.5D-2Vの減衰量は周波数が低くなるほど少なくなり、1MHzで24dB/kmです。つまり100m引き回した場合、減衰は50%以下です。JJYはさらに１桁周波数が低いので室内での使用に限れば気にするほどの減衰はないと思います。

マグネチックループアンテナは通常のループアンテナとは異なりループ面と平行方向に最大感度の指向性を持ちます。　社内のいくつかの場所で試したところ西側や北側に窓のある場所でもアンテナの最大感度方向を窓に向けた場合に高い受信感度が得られることがわかりました。

アンテナ

実験
市販のクロックタイプの電波時計を使って実験してみました。

市販の電波時計(アンテナなし)

窓からほんの4mほどのところにあるテーブルの上においた電波時計です。電池を一度抜いて完全にリセットかけています。1月1日木曜日だそうで調べてみると2009年のようです。1時間ほど置いてありますがこのように現在の時刻を表示してくれません。

次に先ほどのアンテナを窓際に設置(「実験中」の張り紙をして窓際にあるテーブルの下に立てました。ケーブルは他の社員が足を引っ掛けないようテープで床に固定です)して電波時計に接続します。　接続といってもアンテナのケーブルに細めの導線をつないで輪にして数回時計に巻きつけてあるだけです。

市販の電波時計(アンテナ接続)

ごらんの通りに正常に現在時刻が表示されています。なお時計の液晶面右上にある「～～」のような波型表示は受信インジケータらしいです。　外部アンテナを使う方法の有用性が証明できました。

裏側
実は市販の時計を使って確認するのはやりにくいです。設置してしばらく待たないと正常に受信できているかどうかわかりませんし、受信インジケータの表示もアンテナの設置方向を決めるには粒度が荒すぎてあまり役には立ちません。
なので試行錯誤している段階では自作のJJY受信機とトライステート社の 電波時計キット を併用しています。　JJY受信機については以下のページで紹介されているもののコピーです。
長波JJY受信機の製作
こちらでは「手持ちの部品に合わせて作った」というようなことが書かれています。私もOPアンプの入手しやすさや手持ちの部品に合わせて多少アレンジしています。

キットの電波時計をアンテナにつないで時刻データを取得

自作のJJY受信機

umjammer です、

VP8 オープンソース化されましたね。これから Web 動画の覇権はどうなっていくのでしょうか？私は以前動画関連の仕事をしていたときライセンス関係で苦労したのでライセンスフリーなコーデックは大歓迎です。

さて、発表即日なのにもうインストールしている人がいたよ。こちらを参照してください。

で、私もインストールしてみました。以下は h.264 と適当に比較してみた結果です。
サンプルはここからお借りしました。

WebM はパラメータなんて使わないよとのことなので

$ ffmpeg -i BD_Video.m2ts -s 480x272 sample_vp8.webm

h.264 のエンコーディングパラメータはここの Single-Pass Constant Rate Factor (CRF) Example を参考にしました。

$ ffmpeg -i BD_Video.m2ts -s 480x272 -acodec libfaac -ab 96k -vcodec libx264 -vpre slow -crf 22 sample_h264.mp4

結果です、WebM に bps が出ていないのではっきりと比較出来ていませんがファイルサイズで見ると圧縮率はあんまり変わっていないようです。

$ ls
-rw-r--r-- 1 foo staff 66834432 2010-05-20 20:12 BD_Video.m2ts
-rw-r--r-- 1 foo staff  1674461 2010-05-20 20:26 sample_h264.mp4
-rw-r--r-- 1 foo staff  1519316 2010-05-20 20:17 sample_vp8.webm

$ ffmpeg -i sample_h264.mp4
FFmpeg version SVN-r23201, Copyright (c) 2000-2010 the FFmpeg developers
 :
  Duration: 00:00:15.51, start: 0.000000, bitrate: 863 kb/s
    Stream #0.0(und): Video: h264, yuv420p, 480x272 [PAR 136:135 DAR 16:9], 761 kb/s, PAR 161:160 DAR 483:272, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc
    Stream #0.1(und): Audio: aac, 48000 Hz, stereo, s16, 95 kb/s
 :

$ ffmpeg -i sample_vp8.webm
FFmpeg version SVN-r23201, Copyright (c) 2000-2010 the FFmpeg developers
 :
  Duration: 00:00:15.55, start: 0.000000, bitrate: N/A
    Stream #0.0: Video: libvpx_vp8, yuv420p, 480x272, PAR 161:160 DAR 483:272, 23.98 tbr, 1k tbn, 1k tbc
    Stream #0.1: Audio: vorbis, 48000 Hz, stereo, s16
 :

画質は iPhone 用のサイズなのでよくわかりませんでした…

• WebM サンプル
• h.264 サンプル

ポーズしてみると若干 h.264 の方がキレイなんじゃないの？圧倒的な VP8 勝利を期待したのですが…動画に詳しい方ツッコミよろしくです。

VP8

h.264

お久しぶりです、amo-kです！
先日、若手インフラエンジニアにPHPでSessionストレージにmemcachedを使った場合
接続はデフォルトではpersistentなのかそうで無いのかを聞かれました。
最近ほとんどコード書けてないのですが、コードを読む機会ができましたｗ

彼には、そのWebアプリで利用している拡張モジュールのソースコードを読むのが一番早いよと言って僕はMTGに行ってしまったのですが、さすがに愛想無しだと思ったのと、久しぶりにコードと戯れようと思い、自分で見てみる事にしました。

さて、ということで以下にレポートします！
そのWebアプリではPECL::memcache 2.2.1を利用しているようでした。
まずはソースコードの入手ですね。

$ wget http://pecl.php.net/get/memcache-2.2.1.tgz
$ tar xvzf memcache-2.2.1.tgz
$ cd memcache-2.2.1

ぉっと、memcache_session.c コイツぽいぞ〜
はいはい、ありましたありました！！

PS_OPEN_FUNC(memcache)
{
...
        if (i < j) {
            int persistent = 0, weight = 1, timeout = MMC_DEFAULT_TIMEOUT, retry_interval = MMC_DEFAULT_RETRY;

...
                if (zend_hash_find(Z_ARRVAL_P(params), "persistent", sizeof("persistent"), (void **) &param) != FAILURE) {
                    convert_to_boolean_ex(param);
                    persistent = Z_BVAL_PP(param);
                }
...
}

一旦 0 で初期化して、指定されていれば代入という事ですね。
つまりデフォルトではpersistentでないということですね。

めでたしめでたしｗ

便利ツール(OSSのフレームワークや各種ツール)を使っていて問題が起こった時や不明点があった際に皆さんどうしますか？
Google検索して解決しなければ諦めるとか言わないで下さいね！！
特にOSSの場合はソースコードを取得出来ますのでWebに情報が無くとも、一番正確な情報(ソースコード)を確認すれば解決できるハズです！
KLab若手エンジニアは日々新たな技術と戯れる一方で、しっかりと技術の本質も追求しております。
便利ツールがたくさんあってWebにたくさん情報がある中、我々は「Google検索やツール使いの達人」に成り下がらず、技術者として発信/成長して行きますのでよろしくお願いします！！

どうも初めまして、
3月に入社したてピチピチのnakamura-tです。
みなさま今後とも宜しくお願いします。

さて今回は、日本の大手企業向けERPパッケージ「COMPANY」の開発元である
ワークスアプリケーションズ様と合同勉強会をさせていただきましたので、その様子のレポートさせて頂きます。

まずは弊社の鈴木による発表です。
KLabセッション(その1) ：Tokyo Tyrant + Lua Extensionで作るクエリキャッシュサーバ

Tokyo Tyrant（Tokyo Cabinet）の説明と、実験的にLuaで作ったクエリキャッシュサーバのパフォーマンス結果とその考察でした。
パフォーマンスが上がらない原因の一つにLuaの文字列処理系が遅いのかもとのことでした。
僕は以前、iPhoneアプリ開発をしてたのですが一番のネックはファイルアクセスだったので、ファイルシステムにアクセスしてもこの速さでinsert処理が出来るって事は個人的に驚きました。

Tokyo Tyrantは知らなかったのですがBarkleyDBとかSQLiteに比べ比較的パフォーマンスが良いらしく、mixiさんでログイン履歴の保存に使われてるそうです、時には10000QPSを1台のサーバでこなしてるとか。
あと日本からの技術発信というのも嬉しいものです、僕もいつかはと思わされました。

続きまして弊社、竹井による発表です。
KLabセッション(その2)：Android時代のミニ四駆考

うおおおおーーーーっい！！
これですよ！これ！！
子供の頃に学研の未来予想図ってのがありましたよね、空飛ぶ車に動く道路、ロボットの友達などなど。
毎日RSSで最新技術の記事は読めど実際に日常で見かける事はないですよね。
どこいったんすか？未来。
なんて事を日々思ってたんですが、。

素直に感動です。
ないなら作ろうよって事なんですよね。
考えさせられる良い刺激でした、ありがとうございます。

最後の電子書籍が読めるミニ四駆とはミニ四駆を転がすことによってPC画面上のスクロールバーがスクロールするというナイスなデモでした。

最後にワークスアプリケーションズ 川中様による発表です。
ワークスアプリケーションズ様セッション：クラウドと並列プログラミング

発表資料はこちら！

昨今のトレンドになってるクラウドコンピューティングについて。MVCにおいてViewのスケールアップは比較的に簡単、Modelも散々語られてきた。
そろそろControllerもスケールの対象にしよう。
しかし、複数のコンピュータでの並列計算となるとプログラミング的にもデバック作業などにおいても色々面倒な処理が必要になる。
ところが最近のプログラミング言語(Google GO, Scala)などではシングルスレッド感覚でマルチスレッドプログラムを書く仕組みが言語仕様として組み込まれていますよという話でした。

デスクトップの世界では随分と前から、CPUは単純にクロックを上げるより複数のコアを搭載するようにシフトしていると思います、でもデスクトップアプリのマルチコア対応があまり積極的ではない様に感じていたのですが、こういう原因も背景にあったのかもしれません。今後はいろんな分野で飛躍的にパフォーマンスのあがる可能性を感じました。

蛇足ですが、僕はobjective-cな人でした。
でMacのcocoaフレームワークにはマルチスレッド処理の為のNSOperationというものがあります。
それは、NSOperationサブクラスを作ってmainメソッドを定義して行いたい処理を記述、そのインスタンスをNSOperationQueueインスタンスに追加するだけで後は勝手にバックグラウンド処理してくれ、スレッドセーフとかロックとかややこしいのは比較的考えなくても良いというものでした。
しかも、Mac OS X. 10.6 Snow LeopardからはNSOperationQueueが内部的にはGrand Central Dispatchで実装されてるようです。
なるほどApple、エレガントです。

勉強会終了後は懇親会に移り、

技術の話や趣味な話を語り合う楽しい夜になりました。

お越しいただいたワークスアプリケーションズの皆様、本当にありがとうございました。

こんにちは。takada-atです。

先日開催されたアシアル株式会社、KLab株式会社の合同勉強会で発表しましたので、資料を公開します。

携帯絵文字の文字エンコーディング変換およびキャリア間のマッピングについてKLabでの対応をご紹介させて頂きました。

資料は以下にあります。

■携帯絵文字をutf-8エンコーディングにする話

先週の日曜日、弊社若手社員３人でICPC東京大会を観戦、懇親会にも参加させていただきました。
（ICPCの公式ページはこちら→ACM/ICPC Asia Regional Contest 2009, Tokyo, Japan）
今回は弊社もスポンサーとして、ICPCと学生プログラマーの支援をさせていただきました！

ICPCの会場に入るや否や、さっそく大きな歓声が！！
そう、そこで行われていたのは「Javaチャレンジコンペ」という、各チームが短時間で作成したAI同士の熱い戦いです。

こういったAI同士を競い合わせる競技は熱く盛り上げれますね。次回天下一プログラマー大会の参考にさせていただきます！

本選の優勝者は「HITORI#｣チーム。チームの一人は天下一プログラマーコンテストの優勝者です。他にも天下一プログラマーに参加されていた方々が多数入賞されていました。おめでとうございます！！

表彰の後の懇親会ではinada-nがスピーチをさせていただきました。

今後も、プログラミングコンテストの主催や後援を通して、学生プログラマーを応援していきたいと考えております！
夏に開催された天下一プログラマーコンテストが気になる方はこちらにアクセス！！