未分類

ロリポタッチ iPhone版でモノクロ写真ばかり載っけるホームページ作りました。

かの昔、FTPでアップロードしていたことを考えると本当に簡単にサイトが作れるの便利。

lolipotouch.com

 

1 Post

157 Users

136 Pockets

ロリポタッチ | サービス終了のお知らせ

http://lolipotouch.com

mackerelでユーザメトリックのグラフを作れるので、先日作ったlxc-cpu-usageを
利用してホスト上で稼働しているコンテナのCPU利用率を表示させる様にしてみました。

mackerelでは、ユーザ定義のメトリックを送出するのには

# /etc/mackerel-agent/mackerel-agent.conf
[plugin.metrics.vmstat]
command = "ruby /path/to/vmstat-metrics.rb"
type = "metric"

といった内容を設定ファイルに追記する必要があって、
ここで [plugin.metrics.****] が項目名、command の部分が実際にメトリックを取得するコマンドになって、
Mackerelのドキュメントを参照すると、このコマンドの出力は以下のフォーマットで出力されることが期待されています。

{メトリック名}\t{メトリック値}\t{エポック時間}

ということで、lxc-cpu-usage のコマンドを拡張して以下の様な形でオプションを渡せる様にしました。*1

$ lxc-cpu-usage --name="remp001|storyboards001|castory001|mongo001|manage001" --metric
storyboards001  0.09    1401521140636
remp001 0.17    1401521140647
mongo001        0.53    1401521140652
castory001      0.02    1401521140659
manage001       0.12    1401521140669

--name のパラメータとして"|"区切りで複数のコンテナ名を渡せる様に対応して、 --metric でタブ区切りでコンテナ名, CPU利用率, エポック時が表示される様になっています。

これを利用して、Mackerelの設定ファイルを以下の様に追記します。

# /etc/mackerel-agent/mackerel-agent.conf
[plugin.metrics.lxc]
command = "lxc-cpu-usage --name='remp001|storyboards001|manage001|castory001|mongo001' --metric"
type = "metric"

Mackerel agentをRestart

$ sudo /etc/init.d/mackerel-agent restart
* Restarting  mackerel-agent
...done.

しばらくするとMackerel上で各コンテナのCPU利用率が確認できる様になります。

とてもあっさりと任意のメトリックが追加できて便利。

HubotをREMPチームで使っているLingrで使ってみたのでその際のメモ。

Hubotはgithub社が作ったnode.jsで実装されたbotフレームワークでチャットサービス上で稼働させるbotを稼働させることができます。
特定のチャットサービスに依存しないので、IRCやGoogle Talk, Skypeや今回試してみたLingrでも稼働させることができます。*1

メリットとしては、botに作業をさせる、あるいはチャット上の特定のワードに反応する処理をcoffee scriptあるいはJavaScriptを使って実装することでます。また、その時の実装にNode.jsの豊富なライブラリ(npm)を利用できます。

Hubotの導入

Hubotを稼働させるには、

• Node.js
• coffee script
• Redis

が必要になります。既に上記一式が稼働できるものとして...

$ npm install -g hubot
$ npm install -g coffee-script
$ hubot --create remp_hubot
Creating a hubot install atg remp_hubot
(略)

とすることで、hubotを稼働させるための一式が --create オプションで指定したディレクトリ以下に作成されます。ディレクトリの中身は以下の様な具合になっています。

$ cd remp_hubot
$ ll
total 48
-rw-r--r--   1 hideack  staff    36  4 22 09:05 Procfile
-rw-r--r--   1 hideack  staff  5903  4 22 09:05 README.md
drwxr-xr-x   4 hideack  staff   136  4 22 09:05 bin
-rw-r--r--   1 hideack  staff     3  4 22 09:05 external-scripts.json
-rw-r--r--   1 hideack  staff    40  4 22 09:05 hubot-scripts.json
-rw-r--r--   1 hideack  staff   609  4 22 09:05 package.json
drwxr-xr-x  15 hideack  staff   510  4 22 09:05 scripts

試しにローカルで稼働させてみます。先ほどhubotコマンドで作成したディレクトリ配下で、

$ bin/hubot

と実行するとチャットサービスを介さず直にHubotを操作できます。お約束のping-pongをした様子。

LingrとHubotを接続する

Hubotは稼働させることができましたが、まだチャットサービスで接続できていないので次にLingrと接続します。hubot-lingrというAdapterが既にnpmに登録されていますので、これを活用します。

先ほどのhubotコマンドで作成したhubotディレクトリの配下で、

$ npm install hubot-lingr --save

でインストールをすることができます。これで接続に必要なHubot Adapterが準備されます。

次にLingrに接続するためにLingr botの設定をLingrで行います。Lingrの開発者向けメニューのbot作成画面で必要事項を入力させます。

hubot-lingrを利用してHubotとLingrを接続する場合、Lingr上のチャットルームでの発言をHubot側に通知させるためにHTTPのCallback URLを指定する必要があります。このAdapterを入れてHubotを起動した場合、/hubot/lingrというHTTPパスがLingrからのコールバックを受けられる様になります。

この設定が完了するとbotのID及び、Secretキーが発行されるので、これを以下の2つの様な環境名で定義します。

• HUBOT_LINGR_BOT
  • Lingrで設定したbotのID
• HUBOT_LINGR_SECRET
  • Lingrで発行されたSecretキー

この設定が行えた状況でHubotを起動します。次はLingrと接続を行うので -a オプションでアダプターを設定します。

$ bin/hubot -a lingr

hubotが無事に起動すれば、次にLingr上でHubotを稼働させたいRoomでbotを招待します。

• http://lingr.com/room/(ルーム名)/manage_bots
• 

上のフォームで先に作成したbotのIDを入力します。

無事に招待が完了し、且つ、Lingr上で発言された内容がHubot側にコールバックされる状態となっていれば、LingrのRoom上で発言した内容にHubotが反応するはずです。

以上の様な手順でLingr上でHubotを稼働させることができる様になりました。

Node.jsで開発しているプロジェクトでGruntを利用しているときに、タスクによって環境変数を定義したい場合、grunt-envを利用すると便利ですよ。という話。

npmでgrunt-envをインストール。

$ npm install grunt-env --save

次にGruntfile.jsを編集します。以下の様な具合。

module.exports = function(grunt) {
grunt.loadNpmTasks('grunt-env');  // grunt-env追加
grunt.initConfig({
env: {
dev: {
NODE_ENV : 'development'
},
production: {
NODE_ENV : 'production'
}
}
});

上の様に定義した上で、例えば既に、serverというタスクにコンパイル及びNode.jsの起動のタスクが登録されていた場合、それらのタスクの前に env:dev というタスクを加えると

NODE_ENV=development

という環境変数を定義した上でコンパイルとNode.jsの起動が行われます。具体的には以下の様な形でregisterTaskの修正を行います。

// 'env:dev' を追加
grunt.registerTask('server', ['env:dev', 'compile', 'runNode']);

こうすることで、gruntでタスクを実行するだけで、process.env.NODE_ENV で参照できる環境変数が定義されます。

grunt-env とても便利。

FPGAでmemcachedを！的な話をブログに妄想として書いたり、雑談で人とすることがあったりしたのですが、世界では実装されて既に発表されていました。*1

• Achieving 10Gbps Line-rate Key-value Stores with FPGAs
  • https://www.usenix.org/conference/hotcloud13/workshop-program/presentations/Blott

ざっくり中身

• NICに対してFPGAをオンボードしてその部分でmemcachedのプロトコルを解釈して直接DRAMに値を書き込む
  • ハッシュテーブルの大きさは200万レコードで24GByteのストレージを持つ
• NICに入ってきたパケットを以下の順で処理する
  • memcachedプロトコルの解析
  • ハッシュテーブル問い合わせ
  • ハッシュテーブルへの値の格納・取得(DRAM書き込み or 読み込み)
  • memcachedプロトコルとしての応答生成
• 上の一連の処理が156MHzのクロック駆動481サイクルで完了する
• これを並列化且つパイプライン化
• 実験
  • memcachedのGET命令を1秒辺りの応答数 vs パケットサイズでグラフ図示
    • FPGA単独の場合、パケットサイズが96byteであれば13,000 req/sec くらい (グラフ赤線)
    • 但しNICのボトルネックがあるのでパケットサイズが大きくなるとXeonサーバと同等の req/sec になる
  • 過去のFPGA実装と比較すると大幅にパフォーマンスがよくなっている (グラフ黄線との比較)
    • 過去の実装はこれと思われる

• First Results of Memcached Evaluation
  • Xeonサーバと比較してもパフォーマンスよかった
  • 応答時間も100倍程度良くなっている
  • 1W当たりのリクエスト処理数はXeonサーバに比べて大変良い(=エコ)
• 今後の課題
  • ハッシュテーブルの大きさの制限
  • 実際のアプリケーションでの利用
  • 他のアプリケーションでの活用を見つける(=恐らくWebアプリで利用されるキャッシュ以外での活用の模索?)

そしていろいろ調べると既にFPGA入ったアプライアンスとして世の中に出ていることを知った。*2

• Convey Revs Up Memcached With Hybrid X86-FPGA Appliance
  • http://www.enterprisetech.com/2013/09/24/convey-revs-memcached-hybrid-x86-fpga-appliance/

このあたり今年ぐらいから盛り上がったりするのだろうか。

今年も大晦日になったので振り返りエントリ。

一年を通して

• まずは自分が大きな怪我や病気をせずに過ごせたのは本当によかった。家族に感謝。
• バクツイ 作った！
• REMPやSTORYBOARDSを改良し続けられた！
  • SEO的なところにも気を回せる様になってきて、いろいろ手探りではあるけど試せた。

技術的なところ

REMPやSTORYBOARDSをコンスタントに整備していて機能を新規に追加したり、
運営していくのに便利な画面を作ったりしていたところが多くて、利用者数が爆発的に増えているといった状況では残念ながらないのだけど、
確実にサービスを使って喜んでいる人の声が聞こえ始めたので来年も引き続きカイゼンを繰り返していきたいと思います。

そんな中だとccchartというライブラリを使ってグラフを描いたというエントリはそこそこ検索経由とかでも参照されていて
お役立ちエントリになったのかな。と。

• ccchartでグラフを描画する
  • http://hideack.hatenablog.com/entry/2013/05/04/101732

あと、この2サービスについては運用環境をVPS上のLXCに移したりもしました。

• VPS上のLXCを利用してサーバを再構築した
  • http://hideack.hatenablog.com/entry/2013/12/08/163142

LXCという言葉だけは知っていたのだけど、実際に自分で手を動かしてみて理解できたところもあったし、構築する際にChefを利用して
構成管理を始めたりと小さいことではあるのだけど一歩前進できたところかなと思ったりしています。

あと、特に目新しい話ではないけど、REMP用のChrome拡張を作ったりもした。はじめてChrome拡張を作ってみたのだけど、
JSだけで完結する世界でブラウザを拡張することができてこれはとても面白かった。

また、利用してもらった人からは好評価だったので、これはこれで嬉しかったり。

• Chrome拡張 "REMP it"
  • http://hideack.hatenablog.com/entry/2013/10/19/084843

「Webサービスとガジェットを組み合わせたものを何か試してみたい！」というのが昨年の振り返りエントリにあったのですが、
会社でちょうど文化祭が企画されてその際に来場者をカウントするガジェットをArduinoで作ってみる
機会がありました。実際にやってみるといろいろ多々課題あり感*1はあったのですが、まずは試すことができたのは非常によかった。

• ArduinoでHTTPリクエストをホスティングサーバに投げる方法
  • http://hideack.hatenablog.com/entry/2013/05/15/220726

ただ、「これは！」という技術も持たないまま、一層、広く浅く感もあって、ますます自分としてはこれでいいのだろうかという感じが2倍増し位になった
一年になった感は否めないのですが、来年は1つでもそういった技術を持てる様に精進したいと思います。

Youtube動画を連続再生できるREMPで利用しているRubyのアプリケーションフレームワークのPadrinoのVer.0.11.0がリリースされたのでバージョンアップさせてみた。

ほぼ特に問題なく移行できたのだけど、作成していたrakeタスクが動かなくなったが、プロジェクトのルートにRakefileが作成されていなかったのが原因だったので以下の様なファイルを作成して完了。

# Rakefile
require File.dirname(__FILE__) + '/config/boot.rb'
require 'thor'
require 'padrino-core/cli/rake'
PadrinoTasks.use(:mongoid)
PadrinoTasks.use(:database)
PadrinoTasks.init

Padrinoのマニュアルを見て手習いしたのだけど、ここにはpadrino rake (タスク名) で実行する場合、特にRakefile置かなくても大丈夫よ。とあったので作っていなかったのだけど、必須になった様ですね。

あと、@hika69もjQueryのバージョンを2.0に上げる作業をしていて機能面じゃないところもREMPは進化していますよ。というお話でした。

朝から病院に行ったり図書館行ったりしていた。図書館ではこの本を借りた。

www.amazon.co.jp

起源のインターネット | 喜多 千草 |本 | 通販 | Amazon

http://www.amazon.co.jp/exec/obidos/ASIN/479176191X/hatena-blog-22/

Amazonで喜多 千草の起源のインターネット。アマゾンならポイント還元本が多数。喜多 千草作品ほか、お急ぎ便対象商品は当日お届けも可能。また起源のインターネットもアマゾン配送商品なら通常配送無料。

• 作者: 喜多千草
• 出版社/メーカー: 青土社
• 発売日: 2005/05
• メディア: 単行本
• クリック: 17回
• この商品を含むブログ (7件) を見る

午後からREMPの開発。REMP自体に幾つか機能を追加しようとしていて黙々とAPI開発など。
結構面白い機能になりそうなので、ささやかにご期待ください。

先週の金曜日にペパボ社内で第2回LT大会があったので参加してきました。
LTというと技術系のカンファレンスで行われるイメージが強いですが、このLT大会ではジャンル全く縛りなしに好きなテーマで参加者が話す純粋なLightning Talkです。
参加者の職種もエンジニアだけに縛られずディレクター、デザイナー、CS、総務と職種問わず更に、テーマも最近読んだ本の話からドラゴンクエストの話, 徒歩通勤の話 etc... 幅広く繰り広げられました。

私も第1回目から参加して今回は機動警察パトレイバーの話をしてきました。漫画の連載が1988年からなので完全に知らない人もいた感じ…。ジェネレーションギャップ。
あと、手前味噌ですがストーリーボードを利用してきました。*1

LT大会終了後はストボチームで作成したステッカーを配布して終了。
社内の方に結構配っていたのですがお渡しできていなかった方もおられたのでちょうど良い機会。

普段の業務レベルのみでは交流のない他部署の人の意外な面や、興味を持っていることも知れてとても素敵なイベントだと思うのでこれからも積極に参加していきたいな。と思う次第。

4月中旬某日。REMPプロジェクト オンラインチャットルーム。

ところで(全然話は変わる)
プレゼンテーションソフトを作ってみたいのだけど、みんなで作らない？
githubに簡単なテキストファイル置くとプレゼンテーションできる様なやつ。
スマホにWebアプリのコントローラが出てきて押すとみんなが観てる特定のURL上にあるスライドがめくられるという様なもの。
…って字にすると難しいな。
また何か食べながらミーティングするかw

ということで始まったプロジェクトがちょうど数ヶ月後に控えてていたペパボのお産合宿6を経て形になりました。
名前は "STORYBOARDS"(ストーリーボード)。

プレゼンテーションアプリの「次」はなんだろう。をテーマにフロントエンドを
@hika69 が、デザインを @getsukikyu 、そして私はバックエンドを担当して一緒に作りました。
STORYBOARDS(以下略してストボ)の特徴は、

• Markdown記法で簡単にプレゼンテーションを作成できる
• プレゼンテーション1つにつき、プレゼンテーション操作用ページと閲覧用ページが作成される
  • 更にプレゼンテーション操作用ページでページめくりをすると、閲覧用ページのスライドも同期してページめくりされる。

といった特徴があります。

想定としては、例えばプロジェクターが無い様なところでスライドを見せながらのプレゼンテーションをしたいときなどに、閲覧用のURLさえ共有できていれば、すぐにプレゼンテーションできるといったシチュエーションを想定しています。

また、根本的にプレゼンテーションを作っていく時にmarkdown記法でメモ書きを繰り返していくといつの間にかプレゼンが完成しているというプレゼン作成のフレームワークとしても確立していければと思っています。

技術的なところは、バックエンド側はPadrino + MongoDBで実装しています。
REMPでは、Sinatraを利用していたのですが、APIの実装が増えるにつれ、コントローラが肥大化してしまったのですが、Padrinoではジェネレータ等が準備されているのでプロジェクト自体がすっきりと実装することができました。

また、操作用ページから閲覧用ページへのページめくりの操作を行う際にはwebsocketを利用したりしています。
Webアプリ版REMP(http://remp.jp) で培った @hika69 がフロント側で自分がバックエンド(API)を作りこんでいくというスタイルがしっくりくる様になってきました。

アプリケーション自体はとてもシンプルですので、気楽に使ってもらえると嬉しいです。
現状β公開ということで、応募頂いた方へ先に限定的に公開させてもらっていますが、個別にリクエストいただければ、招待可能かと思います。*1

最後に一番重要なことですが、そもそもこういうものを作りたいと自分が呼びかけた時にやろうと乗ってくれるエンジニアやデザイナーの仲間が近くにいるというのは本当にありがたいなと改めて思ったのでした。