Monthly Archives: 2月 2016

2016-02-26

[github謹製hubot]×[docomo雑談対話API]×[あんずちゃん]x slackが社内で愛されたbotのお話

こんにちわ!
GMOアドマーケティング インフラグループのあだちんです。
さてさて、みなさん「hubot」を知っていますでしょうか!?
今回はhubotとは何なのか。まずはこちらから説明していきましょう!

■そもそもhubotってなに??

GitHub社が開発したチャットbot開発・実行フレームワークで、
開発フローに組み込むことで開発を楽にすることができます。

■社内では??

本来の使い方はそんな感じなんですが、弊社ではslackと連携して
定例の時間になったら通知してくれたり、雑談したり社内の雰囲気を明るくしています。
中でもダントツに面白いのが「docomo 雑談対話API」です。
社内の余ったサーバで導入してみたので、インストールから設定までブログしていきます。
↓ちなみに「あんずちゃん」です笑

a01


■インストールする前に

slack側でhubotの設定をしましょう

1. slack hubotのapiを作成
https://slack.com/apps/search?q=hubot
アクセスしたら以下のように画面が出るのでトークンキーなど確認しましょう。
h01h02

トークンキーはあとで使うのでメモしときましょう。saveしたらhubotの構築です。


■hubotのインストール

1. 二行でインストール(CentOS6.7)

2. yoコマンドでbot作成

ちゃんと適宜変更してくださいね。今回はadapterはslackです。

3. 起動スクリプトの作成

4.hubotの起動

5. slackチャンネルにhubotを追加する

好きなチャンネルにhubotユーザを追加しましょう。
テストとしてpingと打ってみてください。
そうすると・・・・
できたら雑談対話apiを導入しましょう。


■docomo雑談対話APIの登録〜設定まで

1.API取得

https://dev.smt.docomo.ne.jp/?p=docs.api.page&api_name=dialogue&p_name=api_usage_scenario
登録は無料なので、適当に新規でAPIを発行しましょう。

2. APIをslack.shに追加する

3. hubot-docomo-dialogue

4.scriptsディレクトリにてcoffeeスクリプトを設置

https://gist.github.com/RVIRUS0817/cf1200e556359708f65f#file-docomoapi-coffee

5.hubotの再起動

6.コミュニケーションを取ってみる

チャンネルの場合はちゃんと@付けてお話してくださいね。スクリーンショット_2016-06-16_午後5_49_53


■まとめ

構築が簡単だったのでみなさんも導入してはいかがでしょうか。
社内のコミュニケーションも増えるし、場も和みます!
最近メンテナンスをしていないので他にもランチbotなど時間があるときに作っていこうと思います。

※ブログ掲載のプログラムのインストールは、自己責任で御願いします。インストール等の結果にかかるハードウェアの不稼働等は、 当ブログでは一切サポートしておりませんので、予め御了承下さい

2016-02-19

PHP7.0とPHP5.6の比較(WEBアプリケーション編)

JWordのO.Yです。
今回はPHP7.0とPHP5.6のパフォーマンス比較をやってみたいと思います。
前の記事ではscalaとpythonのプログラムを書いていましたが元々私はPHPらーなのであのPHPが爆速になった!!・・・と言われるとやはり興味がわきます。

PHPはphp-fpmとして起動してnginxからリクエストをunixドメインソケット経由でphp-fpmに送信し処理するようにします。
アプリケーションはEC-CUBE3.0をインストールしてトップから購入完了(セッション制御の関係上確認ページ以降にはすすめませんが)までの遷移をjmeterのプロキシサーバー機能でテスト計画を自動生成してそのテスト計画を用いてベンチマークします。

EC-CUBE3.0を使用する理由ですが私はEC系の開発をしていた時期があり、その時度々触れる機会のあったEC-CUBEはデフォルト状態で使用しても適度に重く自分で何かアプリケーションを書くよりも有用なパフォーマンステストができるだろうと判断したからです。
またバージョン3.0という最新バージョンを使用したのは新し物好きだからではなく、PHP7.0で動作するEC-CUBEはこのバージョンだけだったことも理由の一つです。
(他のバージョンはPHP7.0で動かそうとすると下位互換性の問題で動きません)

詳細なインフラ条件・ミドルウェアの条件は以下の通りです。

【ベンチマークツール】
jmeter2.12

【サーバー仕様】
Conoha(CPU6core,メモリ8G) x 3

【サーバー用途】
WEBサーバー2台、DBサーバー1台

【サーバー1(PHP7.0がインストールされたWEBサーバー)】
・PHP7.0
・php-fpm(PHP7.0)
・nginx1.0.15
・EC-CUBE3.0

【サーバー2(PHP5.6がインストールされたWEBサーバー)】
・PHP5.6
・php-fpm(PHP5.6)
・nginx1.0.15
・EC-CUBE3.0

【サーバー3(MySQLがインストールされたDBサーバー)】
・MySQL5.6

以下はPHPのコンパイルオプションとphp,php-fpm,nginxの設定です。
またMySQLに関しては設定は変更してません。

(PHP7.0とPHP5.6のコンパイルオプション)

(/etc/php.iniの内容抜粋)

(/etc/php-fpm.confの内容抜粋)

(/etc/nginx/nginx.confの内容)

(/etc/nginx/conf.d/eccube.confの内容)

server_nameにeccube.jword.jpとありますがDNS設定はしてません。
windowsのhostsファイルにipとの紐付けを記述しただけです。

(jmeterの設定)

jmeter-screen-capture
前述しましたようにテスト計画はリバースプロキシ機能により自動生成されたものを使っています。

<<<結果>>>

それではいきなりですがベンチマークの結果を見てみましょう。
まずはPHP7.0の方からです。

jmeter-results-php7

平均レスポンスタイム(リクエストを開始してレスポンスデータの全てを受信するまで):959ms
平均レスポンスタイム偏差:534ms

次はPHP5.6です。
jmeter-results-php56

平均レスポンスタイム(リクエストを開始してレスポンスデータの全てを受信するまで):12258ms
平均レスポンスタイム偏差:23322ms

PHP5.6はあれよあれよという間にレスポンスタイムが増加していき、最後に1分以上かかるようになってきてしまいました。
ですので途中でテストを中断し、その結果が上記となります。
PHP5.6がインストールされているサーバーでtopコマンドで各プロセスの状況を確認してみるとphp-fpmのステータスがD状態となりCPU使用率が高止まりしたままで解放されない状態となっていました。

まとめるとPHP7.0はPHP5.6と比較するとおおよそ3倍はパフォーマンスが良くしかも安定した性能を発揮できてると言えるのではないのでしょうか。
動的ページに対する大規模トラフィックを捌くには正直サーバーを増やすかキャッシュを返すかしか選択肢がなかったPHPですが、今までよりPHP7.0を使えばサーバーコストの削減になるかもしれませんね。
多分まだバグが結構あるとは思いますが、これからが楽しみなPHP7.0の紹介でした。

2016-02-08

HBase shellでも日本語を表示したい!

最近はレコメンドウィジェットTAXELの開発をやっているCTO室のHadoopエンジニアのJ.Nです。

HBaseで日本語を取り扱う時、日本語データはバイト列で格納されるためHBase Shellでデータを確認したい時はバイト列がprintされます。

このままだと、HBaseのデータを確認したい時に実際に何が入ってるのかが不明なため非常に困ります。

HBaseにはJRubyが内包されており、HBase ShellもJRubyで書かれてるため、JRubyでバイト列を文字列にするスクリプトを書けばとりあえず確認できるので書いてみました。

テストデータの準備

テーブルを作成

HBaseに日本語付のデータを投入

scan でデータ表示

バイト列でデータが入っている

JRubyで日本語表示できるプログラムを書く

print_jr.rbというファイル名で保存

実行(コンソール表示)

結果

実行(ファイル保存)

汎用的な日本語表示プログラム

先ほどのプログラムを改良し、汎用的なものを作りました。とりあえず日本語を表示したい、またはパイプラインでファイルに保存したいといった時に以下のプログラムが使えます。

使い方

引数が足りない場合(HELPを表示)

引数がある場合

他に、日本語表示する冴えたやり方があったら是非教えてください(;><)!

2016-02-01

Codeigniter3を大幅に機能向上させるSprintPHPの紹介

こんにちは、JWordのY.Nです。

PHPのフレームワークについて

PHPのフレームワーク、日本中では一般的にCakePHPがよく使われていて、最近はlaravelがよく使われてきているみたいですね。

詳細は以下の記事がわかりやすいと思います。

【2015年版】PHPフレームワーク人気比較してみました!

重いフレームワークほど流行っている?

この記事の中でも言及されていますが先に挙げた2つのフレームワークは重めとなっています。

各フレームワークのベンチマークについては結構最新の情報だと以下の情報がわかりやすいです。

Hello World Benchmark

重いフレームワークがそれでも人気なのは各フレームワークに用意されたコマンドラインを用いて必要なファイルを自動的に生成し元となるデータに対してCRUDな環境を構築するのが容易だからだと考えています。
個人的にね!ソースはない!

そんな思い込みからこんな風に考えています。
動作の速度が遅いのは悪ではあるけど、開発のスピードが遅いものはより悪であるのではないかと。

そして僕は個人的にCodeigniterを使っています。
このフレームワークは非常にわかりやすく且つ軽快に動作していてとても好きなんです。

Codeigniterのまま高機能なCRUDな機能を導入したい

でも昨今のCLIよる自動生成の波には打ち勝てず他のフレームワークも活用することを検討していました。

それと同時にCodeigniterの良さを残したままCRUDなものを導入できないかを検討していました。

それにより見つけたのが以下の2つ。

Grocerycrud

Sparksによりインストールできます。
Codeigniter3に導入するときはディレクトリやファイルの大文字小文字を調整する必要があるので気を付けてください。

非常にたくさんの機能があって使いやすいです。
社内システム開発の業務もこのアドオンを使うことで非常にすばやく構築できました。

基本的なCRUDはもちろんのことテーブル同士をJOINしての制御が可能でした。
ログインしたユーザーの権限などで項目を出す出さない特別な項目にするといったこともサクサクっと構築できました。コーディング必要ですけどね。

大きな問題点としてXSSに弱い部分があったこと。
これはいただけない。

一般的に公開するシステムではないのでGroceryCrudのソースを直接いじったりして問題を無くしましたがこのライブラリ自体が修正されたわけではないのでなんとも言えない感じです。

Bonfire

Codeigniterをベースにしているみたいです。
実は触ってないですw

というのもこの開発している人たちがSprintPHPというもっと軽量でありながら同じ方向性をもったフレームワークを開発していたからです。
名前的にもSprintPHPの方がいいなーっと思いました。

なのでBonfireを試すよりもSprintPHPを試す方が先になったわけです。

SprintPHP

SprintPHPの特徴としてはCodeigniter3をベースとしていることと以下の通り。

https://github.com/ci-bonfire/Sprint#whats-in-the-box

  • Powerful MY_Model with standard CRUD, db wrappers, observer methods and in-model validation

  • MY_Controller with simple theming, rendering methods for other data types (like json) and more

  • Extended Router to include module support, named routes, HTTP verb-based routing, Restful resources and scoped routes/areas.

  • Simple, but flexible, Template system

  • Module Support, without being able to call other controllers. That simply gets too complex and causes too many problems. Instead, it’s simply the ability to keep MVC triads in modules that can still be called from the URI.

  • Better Database Migrations, with CLI tool for building and running

  • Database Seeding with CLI tool

  • Markdown-based documentation system.

  • Flexible Events system with priotized publish/subscribe methodology.

  • Simple, GUI-less cron controller that can be used through standard crontab or scheduled tasks.

  • Settings library for maintaining system-wide settings, either in the database, config files, or a combination.

  • Simple, but expandable, Authentication and Authorization system with flexible Password strength checking

  • Email Queue system allows for very flexible email generations and sending.

  • The Forge – a code builder with simple generators in place, but fully customizable and easy to add your own.

気になった点を抜き出すと、

  • MY_modelがすごいよー。CRUD付だよー。
  • Router機能が拡張されているよー。(なんとサブドメインにも対応しているんだ!)
  • これまでのMVCは保ったままモジュール機能に対応しているよー。
  • CLIからデータベースのマイグレーションができるよー
  • マークダウンによるドキュメントシステムもあるよー
  • イベントシステムもあるよー(たぶんWordpressのイベント処理みたいなやつじゃないかな?)
  • 認証システムもシンプルだけど拡張可能になっているよー
  • The Forgeだよ

という感じです。

実際に導入してみましたので別記事でお楽しみください。

SprintPHPをCloud9で使ってみた。

Codeigniterの今後について思うこと

紹介したSprintPHPはCodeigniterの現在のリード開発者が担当していているみたいで、そこから思うのはCRUDなことはSprintPHPやBonfireになってもらってCodeigniter自身はさらに軽快さを求めていくのかなと思います。

開発者自身のブログに次期バージョンのCodeigniter4に対する感想が年末に載っています。

http://blog.newmythmedia.com/blog/show/2015-12-30_Initial_Thoughts_on_CodeIgniter_4

It’s Fast
CI4 gave around 2500 requests per second, while CI3 clocked about 2250 requests per second. That’s about a 10% improvement.

これまで通りのシンプルさと拡張性、さらに追加機能で他のフレームワークに負けないぐらいの便利さを手に入れつつも速度の向上が実現するのかなと。

悪の部分がなくなりそうですね!

それではまた。