こんにちは。 エンジニアの木村です。 先週末、社内有志でBBQをやりました。BBQって人数は多ければ多いほど楽しいですよね。でもどうやってメンバーを集めるか、すごく悩みました。 （´-`）.｡oO（全社MLに流してもすぐ他のメールに埋もれて忘れられそう。。。） （´-`）.｡oO（とはいえ日頃話さない人に仕事以外で直接声かけるのもなぁ。。） しかし、外が気持ちいいこの季節、BBQやらずに冬なんか迎えられません。そこで考えたのは、みんなが１日何回も見てる開発環境に広告を出すことでした。 BUYMA の開発では、エンジニアじゃなくても、デザイナもディレクタも少々のHTMLの修正なら自分でやっていて、みんな開発環境を見ています。そこに広告を出せば目に留まらないわけがありません。 どんなふうに出るかというと、こんなかんじです。 クリックすると開きます。 こちらは開催１週間前。 結果、無事、程よく、男女比もいい感じに集まりました。この日は会場も天気も、集まったメンバーも最高でした。Couldn't be better. もちろん、やったよ〜の報告も忘れません。 それでは、次のBBQもお楽しみに！

メインサービスである BUYMA のシステム的な話がいままでなかったので書きます。 (2014/09 現在) PHP , Ruby , Java 主に使う言語は PHP , Ruby , Java です。 BUYMA のほとんどの部分は PHP / Zend Framework / Smarty で書かれています。なかなか年季の入っているもので、見通しが悪く保守性がアレなコードがあったり 、誰も PHP が好きではない などの理由で、絶賛 Ruby on Rails で書き換え中です。 "絶賛" と書いてしまいましたが、既存の PHP への機能追加・変更もしながらなので苦労もありますが、新しいものは Ruby で、古いものも手を入れるときにはできれば Ruby で書き換えたい、みたいな感じでやってます。そうはいっても既存機能に少し手を加えるくらいなら PHP でやってしまっています。 BUYMA のメイン機能とは別に、レコメンドシステムがあります。 こちらは Java / Struts2 /Spring/ Hibernate な構成でできています。レコメンドは独自ロジックで行っています。 また、社内で使う管理画面も同じ フレームワーク でできています。 この2つのシステムは同じ頃にできているので、その時のエンジニアの判断だったのだと思います。 MSSQL , MySQL , Percona 歴史的経緯により、メインのデータベースは SQL Server です。 その他、 MySQL もあったり最近ではPerconaも使っています。 最近 Percona を入れるときには、「 MySQL じゃだめなのか? PostgreSQL じゃだめなのか?」といった話し合いをしつつ、最終的には担当エンジニアが Percona がいいというならそれで。みたいな感じで決まりました。 Memcached , Redis 当たり前ですが Memcached もあります。当たり前ですね。 Redis は Rails から Resque でつかったり、キャッシュサーバとして使ったりもしています。 Apache Solr 検索エンジン として Apache Solrを利用しています。 いまは 3.2 をつかっていますが、そろそろ 4 にしたいですね。 Solr使ってるんですが、あまりうまく使えている感じがしないので、ノウハウを蓄積していきたいところです。 CentOS , Windows Server SQL Server があるので Windows Server もありますが、それ以外は CentOS です。5と6が混在しております。 Subversion , Git 古いものはまだまだ Subversion にはいっています。 Rails は Git/GitLab に入っています。 Subversion を使っているのがエンジニアだけじゃないこともあったり、履歴が膨大にあったりなどで、なかなかエイヤッと Git に移行できないでいますが、そのうちやりたいと思っています。 Virtual Box, Vagrant , Chef 開発環境は Vagrant を使って簡単に作れるようになりました。( 栗山さんの記事参照 ) それまでは Mac に PHP , Apache , ・・・・ って1日かかっていたものが30分寝ているだけで出来上がるようになりました。神様仏様栗山様です。 またこれに触発されてインフラエンジニアも Chef レシピを積極的に書くようになりました。Chef や Chef サーバは結構前からあったのにうまく活用できていないなぁと思っていたのでグッドバイブスですな。 その他 その他 Jenkins さんがいたり、情報共有には Slack や Qiita:Team を使ってたりします。 採用情報の中にも利用している技術 & ツールが載っています のでご確認ください。 まとめ このようにさまざまな歴史的経緯があり、日々、技術的負債を返したり、新たな負債を生み出したり楽しい日々を送っています。環境整備は一朝一夕には行かないので、少しずつですがモダンな環境を目指して改善して行きたいと思いつつ、人手不足で改善できていないところもたくさんあります。 サービス開発にも環境整備にも興味のある方がいましたら、お声がけいただければと思います。

エンジニアの栗山です。 最近になって、社内 CSS フレームワーク を作ったので、その共有をしたいと思います。   CSS フレームワーク ほしい… まず CSS フレームワーク と聞いて思い浮かべるのが、 Bootstrap ではないでしょうか。 これは非常に便利ですよね。デザインが苦手なエンジニアでも簡単に見栄えのいいサイトが作れます。 ぜひともこういった CSS フレームワーク を使いたいところですが、これをそのまま使うとデザインがBootstrapそのものになってしまうので、その会社そのサービスにカスタマイズした CSS フレームワーク が必要になります。 そこでベースとなる CSS フレームワーク を選定し、それをカスタマイズして社内 CSS フレームワーク を作ることにしました。(一から CSS フレームワーク を作るのは大変なので) ベースとなる CSS フレームワーク の選定 Semantic UI や Kube など、候補に上がった CSS フレームワーク としてはいくつかありますが、 人気とデザインの良さから Pure と Foundation が最終候補に残りました。 Foundationは機能が豊富でよさそうだったのですが、ゴリゴリのSassで書かれていたため、これをデザイナーさんがカスタマイズするのはちょっとハードルが高そう。 対してPureは CSS のみで作られていてカスタマイズが非常にしやすい。 ということでPureをベースの CSS フレームワーク に選びました。 ちなみに実際にPureをもとに CSS フレームワーク を作ったのはうちのデザイナーさんで、私は社内 CSS フレームワーク 周りの環境整備をやりました。 Sassが使いたい いまどき CSS プリプロセッサ 使ってないとかマジでなくね？ということでSassを使うことにしました。 Sassを選んだ理由はLESSやStylusよりもユーザ数が多く、またScss記法になって CSS に近い記法なりデザイナーさんも親しみやすい点からです。 Pureは CSS で書かれていますが、その css ファイルをSassファイルにしてSassで書けるようにしています。 (あと CSS フレームワーク でデザインが全て完結するわけではなく、そのページ特有のデザインのためにそのページ用の CSS を用意することがあります。 その CSS もSassで書くようにしました。) Sassといえば Compass ですが… Compass は有名ですが、ちょっと重厚です。 Compass でやれることのほとんどはGrunt プラグイン で実現できます。 また Compass はSassの コンパイル が非常に遅いです。 しかし Compass のMix-inは便利なので使いたい…。 そこで Bourbon を使うことにしました。 Bourbon は安心と信頼のthoughtbotが作っている"A simple and lightweight mixin library for Sass."です。 Mix-inも十分揃っていますし、ただのSassファイルの集合なので コンパイル も非常に速いです。 Grunt！ Sassの コンパイル や CSS の結合圧縮、 CSS スプライトの作成等々、フロントエンドのもろもろのタスクを自動化してくれる便利な味方、Gruntも使うことにしました。 Gruntの プラグイン は色々入れていますが、主なやつは以下です。 Sassの コンパイル のためのgrunt-contrib-sass CSS Lintを実行するためのgrunt-contrib-csslint CSS を圧縮するgrunt-contrib-cssmin CSS を結合するgrunt-contrib-concat LiveReloadのためのgrunt-este- watch 、grunt-contrib-connect Gruntの実行に失敗したらポップアップで通知してくれるgrunt-notify grunt-este- watch はPCの負荷が少なくて非常に良いです。 あとgrunt-notifyはエラーにすぐに気付けて地味に便利ですね。 また巷で言われるように、タスクが多くなってくるとGruntfile.jsが結構きつくなってくるので、 gulp を入れようか考え中です。。 スタイルガイド、いいよね 格好いい社内 CSS フレームワーク を作っても、そのスタイルを適用したらどんなデザインになるのかが簡単に分からないと、みんな使ってくれません。 簡単に言えば http://getbootstrap.com/css/#forms みたいな画面が作りたい。 こういうのを巷ではスタイルガイドと呼ぶようです。 スタイルガイドは有名どころでは、 StyleDocco や、 KSS 、 Kalei があります。 エニグモ では、スタイルガイド自体のデザインも出来るKSSを使うことにしました。 KSSはちょっと導入が面倒なのですが、それを簡単にする kss-node というものを使っています。 CSS 命名 ルールを決めたい CSS のクラス名の付け方とか結構迷いますよね。 最近では OOCSS とか BEM とか SMACCS とかが出てきています。 エニグモ ではシンプルで分かりやすい(けどクラス名が長くなる) BEM を使うことにしました。 ただ厳密にBEMを適用するとクラス名が長くなってしんどくなるのでほどほどに取り入れています。 この辺の 命名 ルールはまだ模索中です。 まとめ 他の会社でも社内 CSS フレームワーク を作りたいという欲求はあると思います。 ただ一から作るのは大変なので、うちのようにベースとなる CSS フレームワーク を用意するとよいのではないでしょうか。 また今回いろいろ環境は整えて前と比べてモダンな感じになったのですが、実際に社内 CSS フレームワーク を使っていく運用はまだ始まったばかりです。 特に大変なのが、既存の CSS と今回作った社内 CSS フレームワーク の共存です。 既存の CSS が思わぬ影響を及ぼしたりして地道な調整が必要になるのですが、そこはデザイナーさんが頑張っております。 プロジェクトの寿命が長いとどうしても開発環境がレガシーになってきてしまいますが、そうなると生産性やメンテナンス性に影響が出てしまうので、随時新しい技術を取り入れてモダンな開発環境を保っていきたいと思います。

はじめまして。エンジニアの栗山です。 エニグモ でも、ついに、 Vagrant と Chef で 開発環境を構築出来るようにしました。 経緯 以前は、開発者が各々の Mac に手順書にそって Apache をインストールしたり PHP を コンパイル したり等々していました。 しかしこれだと以下のような問題が出てきます。 本番は CentOS で動いているので、開発環境と本番で差異が出てきてしまう。 何か新しい ミドルウェア を入れたり、 フレームワーク のバージョンを上げたり、言語のバージョンを上げたりということが気軽に出来ない 新しい ミドルウェア を入れると全員のエンジニアがそれを自分のPCに入れる作業をしないといけない Mac を新しくするたびに開発環境を構築するのが面倒 デザイナーさんは自力で開発環境を構築できない ということで、一念発起して、Chefレシピを書き、 Vagrant も入れ、簡単に開発環境を構築出来るようにしました。 構成や使っているツール 構成を説明するとまず Vagrant があって、 Vagrant プラグイン として vagrant -omnibusとsaharaを入れています。 vagrant-omnibus は、boxにChefが入っていなければ自動的にインストールしてくれる プラグイン です。 sahara は、boxのスナップショットをとったり、スナップショットの状態まで ロールバック したりすることができるようになる プラグイン です。 Chefを書いていると"前の状態に戻したい！"ということが頻繁に起きるので必須の プラグイン となっています。 Chefのcookbookを管理するツールとして、 Berkshelf を使っています。 Berkshelfを使うとBundlerのように簡単に サードパーティ のcookbookが管理できて非常に便利です。 ちなみにboxファイル自体は、時雨堂さんの packer-templates を使ってboxファイルを生成しています。 生成されたboxファイルに対し、Chefレシピを実行する流れです。 Mac とboxファイル内の ソースコード の同期の仕方ですが、 Mac 側から ソースコード を修正することが多いので、shared foldersではなく nfs を使っています。 nfs のほうが速くて快適です。 まとめ Vagrant + Chefで開発環境が構築できるようになったため、デザイナーさんでも簡単に環境が構築できるようになり、またChefによって常にみんな同じ環境が保てるようになりました。 そしてChefレシピによって何をインストールしてどんな設定をしているかが見えるようになりました。 これから 今後はChefレシピを修正してGitにpushしたら、自動的に、 「boxファイルの生成、Chefレシピの実行、serverspecでのテスト、テスト結果の通知」 がされるようにしたいと考えています。

はじめまして インフラ担当のたかやまです。 先日(と言ってもだいぶ前)、サーバマシンを購入し、サービスに組み込んだのですが、なかなか全開の性能を発揮させることができず、地味にハマったので その時の話を。 マシンスペックとサーバ構成 購入したマシンは以下。 FUJITSU / PRIMERGY RX200 S7 CPU : Xeon E5-2670 ( 2 .60GHz ) 2CPU 16core Rails サーバにするため、以下の構成にしました。 ホストOS : CentOS6. 4 + Xen4. 2 仮想OS : CentOS6. 3 + Unicorn4 + Rails3 + Ruby2 既存 Rails サーバは以下。 Dell / PowerEdge RX200 CPU : Intel Xeon X5650 ( 2 .67GHz ) 1CPU 6core ``` 構成は同じですが、ホストOSのOSとXenのバージョンが違います。 ホストOS : CentOS6. 3 + Xen4. 1 仮想OS : CentOS6. 3 + Unicorn4 + Rails3 + Ruby2 大きな違いはCPU。　世代が変わって、かなり性能が向上しているそうです。 参考： 次世代データセンターの新基準へ インテルが「Xeon E5-2600/1600」を発表 性能比較 : なぜか既存サーバより遅い新規サーバ 既存サーバと新規サーバで条件を揃えて新規サーバをサービスへ組み込み、 Rails の1アクセスに対する"平均処理時間"を比較しました。 ・新規サーバ : 0.32秒 ・既存サーバ : 0.26秒 あれ？　既存サーバより遅い。。。 Unicorn はシングルスレッドアプリケーションですが、CPUの性能UPで"平均処理時間"も少しは速くなる想定でした。 対策その１ ： BIOS を性能優先に まず確認したのは BIOS 。 デフォルトでは"性能と消費電力のどちらも最適になる設定"になっていたので、性能が最優先になる設定に変更しました。 CPU Configuration ・Power Technology: Energy Efficient => Custom ・Energy Performance: Balanced Performance => Performance ・CPU C6 Report: Enabled => Disabled ・Package C-State limit: No Limit => C0 参考： PRIMERGY RX200 S7 環境設定シート 結果 多少改善されたのですが、既存サーバには及びませんでした。 対策その2 ： Xen のVCPU設定をチューニング その次に Xen の仮想OSのVCPU設定をチューニングしました。 以下は Rails サーバをホストOS内に2つ起動し、各 Rails サーバの Unicorn のworkerを32個起動した場合に最もパフォーマンスが発揮されたパラメータです。 ・VCPU数= Unicorn のworker数(物理コア数16コア×2CPUと同一にしました) ・VCPUへのコアの割り振り＝1CPUのコアを全てを割り振る ( Rails サーバ1は全てのVCPUでコア番号：0-15、 Rails サーバ2は16-31) # vi /etc/xen/<仮想OS名> vcpus = 32 cpus = [" 0-15 " , " 0-15 " , " 0-15 " ,・・・ ] 結果 それでも既存サーバには及ばず。。 対策その3 : ボトルネック 調査 ホストOSや仮想OSのCPUやメモリ等を確認しましたが、特にリソース不足は発生していません。 そこで、turbostatというツールでCPU動作クロックを確認しました。 以下のサイトを参考にさせていただきました。 CentOSにおけるintel CPU ターボブースト動作の確認 turbostatを実行すると、動作クロックと、CPUの省電力状態を表示し続けます。 (デフォルトだと5秒間隔でフラッシュします) C0とC1の欄がちゃんと表示されませんでしたが、 TSC の欄が標準クロックで、GHzの欄で実際に動作している動作クロックです。 既存サーバでは、ほとんど2.6GHz以上で動作していますが、 新規サーバでは、ほとんど2GHz以下で動作していました。 結果 やはり、CPUが全開の性能を発揮できていないことが ボトルネック だと判明しました。 新規サーバ # ./turbostat CPU %c0 GHz TSC %c1 %c3 %c6 %c7 %pc2 %pc3 %pc6 %pc7 **** **** 2 . 60 **** 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 **** **** 2 . 60 **** 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 1 **** **** 2 . 60 **** 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 2 **** 1 . 2 * 2 . 60 **** 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 3 **** 1 . 2 * 2 . 60 **** 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 4 **** 1 . 2 * 2 . 60 **** 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 5 **** 1 . 2 * 2 . 60 **** 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 6 **** 1 . 2 * 2 . 60 **** 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 7 **** 1 . 2 * 2 . 60 **** 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 8 **** **** 2 . 60 **** 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 9 **** 1 . 2 * 2 . 60 **** 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 10 **** 1 . 2 * 2 . 60 **** 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 11 **** 2 . 1 * 2 . 60 **** 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 0 . 00 既存サーバ # ./turbostat CPU %c0 GHz TSC %c1 %c3 %c6 %pc3 %pc6 **** **** 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 0 **** **** 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 1 **** **** 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 2 **** **** 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 3 **** **** 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 4 **** **** 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 5 **** **** 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 6 **** **** 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 7 **** 2 . 9 * 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 8 **** 2 . 9 * 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 9 **** 2 . 9 * 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 10 **** 2 . 9 * 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 11 **** 2 . 8 * 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00   最大の原因が判明！ CPUが全開の性能を発揮できていないということで、CPUの動作クロックをコン トロール している機能を調査しました。 サポートに聞いたり、ググったり、 BIOS でもない、 Xen でもない、OS(cpuspeed)でもない、くぁwせdrftgyふじこlp ・・・そしてついにCPU動作でクロックをコン トロール している犯人を発見。 Xen のCPUクロックをコン トロール する機能(cpufreq)が省電力モードになっていました。。 ※既存サーバでは Xen のcpufreqが無効になっていて、 BIOS のみの設定変更で全開の性能が発揮できていたようです。 性能優先にするため、親ホストで以下のコマンドを実行。(/etc/rc.localにも追加) # xenpm set-scaling-governor performance # xenpm set-scaling-minfreq 2601000 参考 Xen power management Xenpm command 結果 設定変更の結果、だいぶ改善されました。 # ./turbostat CPU %c0 GHz TSC %c1 %c3 %c6 %pc3 %pc6 **** **** 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 0 **** **** 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 1 **** **** 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 2 **** **** 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 3 **** **** 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 4 **** 2 . 9 * 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 5 **** **** 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 6 **** **** 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 7 **** **** 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 8 **** **** 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 9 **** **** 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 10 **** 2 . 9 * 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 11 **** 2 . 9 * 2 . 66 **** 0 . 00 0 . 00 0 . 00 0 . 00 もう1度、平均処理時間を比較。 ・新規サーバ 0.23秒 ・既存サーバ 0.26秒 おおー　(ちょっと)速い！ それに コアが多いので、同時に3倍近い処理を捌くことが可能です。 めでたし めでたし! 終わりに サーバ構成で書きましたが、 BUYMA は Rails で動いています。 実際には PHP の フレームワーク と Rails が混在しており、現在、 Rails に移行中です。 enigmoでは Rails で BUYMA を速くしたいエンジニアを募集しています。 → こちらまで

こんにちは、エンジニアの大川です。 先週の木曜(4/25)に行われた、 Consumer Service Engineer MeetUp Vol.1　~iOS編~  で発表してきました。 このイベントではコンシューマー向けの Webサービス を展開している アプリ開発 者が開発tipsやテスト技法、グロースハックなどについて発表するというものでした。 自分の発表は、現在開発している BUYMA の iPhoneアプリ の開発事例についてお話させていただきました。 スライドはspeakerdeckにあげてますので、興味のある方は見てみてください。  感想 自分の発表ではDemoありきなのにDemoアプリインストールするの忘れてたり、当日 Wifi がなくて焦ったりいろいろ反省点は多いんですが、それでも懇談会では「UICollectionViewってあ〜いう使い方少ないですけど、アリですよね」とか「勉強になりました」とか言って頂ける人が何人もいたので、割と突貫で準備したけどやってよかったなあと思いました。 あと他の方の発表を聞いていて、効果検証やテストなど、実装以外の部分でも色々工夫してるのがよく分かって勉強になりました。 NYCのコーディングガイドを参考に、自社のObjCのコーディングガイド< https://github.com/wantedly/objective-c-style-guide >作成( wantedly 川崎さん) iOS ライブラリを比較できるサイトがなかったら自分で作った。< http://cocoapods.wantedly.com/ >( wantedly 川崎さん) OHHttpstubs/NLTHTTPStubServerを使ってWeb API をテスト( はてな 加藤さん) 接続先変更、ログインリセットなどの デバッグ 設定を変更できる画面を開発(マインドパレット 小林さん) 案件優先で進めてると、中々仕組みの部分に手がつかないというか後回しになってしまいますが、そこらへんは勇気を持って手を付けたいなあと。勉強会で発表できるようなネタを常に作ることを前提にしてもいいかもしれない(勉強会ドリブン?BDD?)とふと思ったりもしました。

ご無沙汰しておりました。エンジニアの木村です。 エニグモ のエンジニア部門ではIMツールとして Slack を使っています。すでにたくさんの詳しい紹介記事があるようです。 http://blog.woopsdez.jp/archives/3658 http://sideci.hatenablog.com/entry/2014/03/19/142645 便利なIntegration エニグモ でも Integration と呼ばれる外部ツール連携機能を使って単なるIMツール以上に大活躍しています。 例えば、Jenkins CIというIntegrationが用意されており、テストがコケた時などに通知してくれます。 jenkinsというChannelを用意しておいて、そのChannel上でそのまま「〜〜の影響なので僕が対応しまーす。」などと書き込むことで、失敗した原因や誰が対応するかなどの共有がスムーズに可能になりました。 自分でIntegrationを作れる さらに、 API が公開されているので、自分でIntegrationを作ることができます。すでに様々なIntegrationが有志によって作成され、下のページでCommunity-built Integrationsとして紹介されています。 https://api.slack.com/community エニグモ のメンバー（というか僕）も、 はてなブックマーク でブックマークしたのを契機に、そのURLをSlackへ投稿するIntegrationとして hatebu-hooker を作りました。先ほどのページでも Ruby のCommunity-built Integrationとして紹介されています！ はてブのWeb Hook と Slack API を組み合わせて実装しています。 はてな とSlackのoauth2で連携させ、 はてブ の Web Hook キーを入力するだけで使用可能です。さらに、Slackへ投稿する・しないを特定のタグの有無によりコン トロール することができます（この機能は部長にプルリクしていただきました）！ 質問やリク エス トに答えてくれるSlackの開発チーム Slackには、まだomniauthのstrategyがなかったのでそのgemも作成しました。 http://rubygems.org/gems/omniauth-slack このgemを作るにあたって、その時点でSlackの API はまだ不十分なところがありました。oauth2を実現させるにはアクセスを承認したのは誰かという情報を返してくれる API が必要なのですが、当時はユーザ情報を返す API として、チーム全員分の情報を返す users.list しか提供されておらず、承認者を特定することができませんでした。 幸運にも、 API についての質問やリク エス トに答えてくれる Googleグループ が用意されていたのでそこへリク エス トしてみました。すると、もう実は開発されていたようで、ドキュメント化したという返事が程なく返ってきました（拙い英語ですが通じて何よりです）。 こうして本人の access tokenからその人の情報を取り出すことができる auth.test が使えるようになったわけです。 他のスレッドを見ると、「それ、必要なのはわかってるんだけど、たくさんTodoがありすぎてまだ着手できない！」などとSlackの開発者が答えていて、これからまだまだ発展していく様子が分かります。 そんなSlack、これからどうなっていくかが楽しみです。 今なら$100.00もらえる！ 下のリンクから登録＆アップグレードすると、期間限定でもれなく$100.00のクレジットが貰えるようです（僕らにも）！ slack.com それでは。

エンジニアのにのみやです。 bundle installでeventmachineのインストールがコケていろいろ大変だったので、同様のエラーでお困りの人の役に立てることを願いつつ記録として残しておきます。 概要 eventmachine gemのインストールでエラー発生 ⇒ Xcode を再インストール ⇒ Command Line Tools for Xcode を再インストール ⇒ 解決 OSは Mac OS X 10.9.1 ( Mavericks ), Ruby のバージョンは2.0.0p247です。 エラー内容 bundle installの途中で発生したエラーは以下です。 Installing eventmachine ( 1 . 0 . 3 ) Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension. /Users/ninomiya/.rvm/rubies/ruby-2. 0 .0-p247/bin/ruby extconf.rb *** extconf.rb failed *** Could not create Makefile due to some reason, probably lack of necessary libraries and/or headers. Check the mkmf.log file for more details. You may need configuration options. Provided configuration options: --with-opt-dir --with-opt-include --without-opt-include= ${opt - dir } /include --with-opt-lib --without-opt-lib= ${opt - dir } /lib --with-make-prog --without-make-prog --srcdir=. --curdir --ruby=/Users/ninomiya/.rvm/rubies/ruby-2.0.0-p247/bin/ruby --with-openssl-config --without-openssl-config --with-pkg-config --without-pkg-config /Users/ninomiya/.rvm/rubies/ruby -2 . 0 .0-p247/lib/ruby/ 2 . 0 . 0 /mkmf.rb:430:in `try_do ' : The compiler failed to generate an executable file. (RuntimeError) You have to install development tools first. from /Users/ninomiya/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/mkmf.rb:515:in `try_link0 ' from /Users/ninomiya/.rvm/rubies/ruby-2. 0 .0-p247/lib/ruby/ 2 . 0 . 0 /mkmf.rb:530:in ` try_link ' from /Users/ninomiya/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/mkmf.rb:616:in `block in try_ldflags ' from /Users/ninomiya/.rvm/rubies/ruby -2 . 0 .0-p247/lib/ruby/ 2 . 0 . 0 /mkmf.rb:609:in `with_ldflags ' from /Users/ninomiya/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/mkmf.rb:615:in `try_ldflags ' from /Users/ninomiya/.rvm/rubies/ruby-2. 0 .0-p247/lib/ruby/ 2 . 0 . 0 /mkmf.rb:1712:in ` pkg_config ' from extconf.rb:61:in ` ' Gem files will remain installed in /Users/ninomiya/.rvm/gems/ruby-2. 0 .0-p247@buyma/gems/eventmachine-1. 0 . 3 for inspection. Results logged to /Users/ninomiya/.rvm/gems/ruby -2 . 0 .0-p247@buyma/gems/eventmachine -1 . 0 . 3 /ext/gem_make.out An error occurred while installing eventmachine ( 1 . 0 . 3 ) , and Bundler cannot continue. Make sure that `gem install eventmachine -v ' 1.0.3 ' ` succeeds before bundling. gemインストール時のエラーとしてよくあるextconf.rb failedというやつです。 gem_make.outにログがあるよと書いてありますが、コンソール以上に有用な情報は見当たりません。 extconf.rbのオプションがいろいろと提示されていますが、ここらへんのオプション指定の問題というよりも、You have to install development tools first.とあるように開発環境の問題と思われました。 錯誤(1)  gcc 最新版をインストール 実は前機の Snow Leopard から現機に乗換えたときもiconvやら何やらでトラブって MacPorts をアンインストールしたり等開発環境をいじりまくったことがありました。そこで開発環境の要である gcc を最新版にしてみました。 brew search gcc とやるとgcc49が最新です。インストール方法も表示されるのでそれに従います。リンクは自分で作成しないといけないようです。 brew tap homebrew/versions brew install gcc49 ln -s /usr/ local /bin/gcc-4. 9 /usr/ local /bin/gcc ln -s /usr/ local /bin/g++ -4 . 9 /usr/ local /bin/g++ そして再度bundle installしましたが同じエラーが発生しました。 錯誤(2) brew doctor Homebrew周りがいけないのかと思い brew doctorで出てきた警告をいくつかつぶしてみました。 まず、config スクリプト が実行パスに入っているという警告 Warning: " config " scripts exist outside your system or Homebrew directories. `./configure` scripts often look for *-config scripts to determine if software packages are installed, and what additional flags to use when compiling and linking. とXQuartzが古いという警告 Warning: Your XQuartz ( 2 . 7 . 4 ) is outdated Please install XQuartz 2 . 7 .5: https://xquartz.macosforge.org は関係なさそうだったので無視しました。 Warning: Unbrewed dylibs were found in /usr/ local /lib. If you didn ' t put them there on purpose they could cause problems when building Homebrew formulae, and may need to be deleted. Unexpected dylibs: /usr/local/lib/libtcl8.6.dylib /usr/local/lib/libtk8.6.dylib といった余計なファイルの存在に対する警告がいくつか出ていたのでひととおり削除してみました。 随時bundle installしますが結果は変わりません。 /usr/local以下の所有者や権限も使っていくうちになぜか狂っていくので、このタイミングで修正しましたが効果ありませんでした。 Xcode 再インストール Xcode をアップデートしようとしましたができなかったので再インストールしました。 Xcode に紐付いた Apple IDを変更したかったのでキーチェーンアクセス内のdaw2. apple .comという項目を削除したりしましたが変更できません。 App Store に紐付いているアカウントは変えてあったのですが。 Xcode の削除にはAppCleanerというツールを使いました。そして Xcode 5.0.2を App Store からダウンロードし直します。 Apple IDを変更しての再インストールは問題なくできたものの、やはりeventmachineは入りません。 Command Line Tools for Xcode 再インストール 次に https://developer.apple.com/downloads/index.action でCommand Line Tools for Xcode を探してインストールしました。 再度bundle installしたところeventmachineを含め全てのgemをインストールすることができました。 Mac の開発環境整備について Xcode とCommand Line Toolsを入れないと開発環境・ツールが整わないのは不便だと感じました。Homebrewで gcc , autoconf, ...をひたすら入れて行くのは大変だしどこまで不備なくできるかも不明です。 GUI でインストールするのも疑問です。余計なものも入ってしまいますが、 yum だったら yum groupinstall "Development Tools"で済むので楽ですね。

こんにちは。 入社２ヶ月目、エンジニアの木村です。 「ノウハウ共有の手段として ペアプログラミング を取り入れたい」というリーダー小澤さんの言葉から、 ペアプログラミング をすることになりました。 学生のころから ペアプロ には興味があって、 ペアプロの本 も読んだことがあり、実は ペアプロ は以前からやってみたかったんです。 入社早々にこんなチャンスに恵まれるなんて！小澤さんの口から ペアプロ というワードが出た時は胸の高鳴りを抑えるのに必死でした。 そいうわけで、僕と小澤さんが最初のペアとして実践してみることになりました。 環境はこんなかんじです。シンプルですね。お互いの画面が見やすいように自席からオフィス内のカフェテリア席（夕方で外が暗くなっちゃってますが、昼間は いい景色 です）へ移動して ペアプロ 開始です。 基本的にドライバ（キーボードで打ち込む人）は自分のパソコンで作業し、ナビゲータ（もう一人の人）は横から覗き込むスタイルです。ナビゲータが我慢できなくなった時は「ちょっと貸してみ！」ってドライバのPCを取り上げて役割を交代します。 若手ドライバ、中堅ナビゲータ 当初は僕がドライバで小澤さんがナビゲータになって２時間でやってみようと始まりました。 ペアプロ の教科書に書いてあるんですが、 ドライバは常にやってることや考えていることを耐えず話し続けることを推奨 されています。実際やってみるとその重要性が実感出来ました。まず、フィードバックがリアルタイムで返ってきます。プログラムの最初の１文字を書き出す前の思考の段階から相手に伝わるので、ナビゲータがそれに反応して思考の方向性から補正してくれ、ゴールへの最短距離へ突っ走れる感覚がありました。また、ナビゲータを退屈させないということにも役立ちました。沈黙の中、横でカタカタやってるのを眺め続けるのはつらいものがありますよね（実際、少しでも黙ると、小澤さんは退屈して自分の作業を始めてしまうこともありました）。 また、 安心感とか自信のようなものを感じながらのプログラミング ができました。新しいプロジェクト、まして新しい会社で、新しいレビュアと、新しい言語、新しい フレームワーク での開発となると、一人でプログラミングしているときは、これでいいのかな〜と確信が持てない中書き進めることになりますよね。 ペアプロ では、ナビゲータが横で頷いてくれるだけで、そういった不安感のようなものがかなり軽減されます。 さらに、 わからない時に直ぐに教えられた・教えてもらえた のはよかったです。そんなの ペアプロ じゃなくても直ぐに聞けばいいじゃんという人もいるかもしれません。しかし、わからないことがあればいつでも教えますと言われていても、別の作業中の人に質問するコストって大きいですよね。質問の背景の説明 からし ないといけないし、その人が忙しいのかそうでもないのかとか。席にいなかったりとか。 ペアプロ では常に背景を共有しながら作業することになるので、そういった問題はなくなります。 気をつけるべき点だったのは、 いつもどおりのプログラミングを心がける ということでしょうか。横で人が見てると、なんかカッコつけたくなるのは私だけでしょうか。エディタで、いつも使わないようなうろ覚えのショートカットをつかって、あらぬ結果を招いてしまったり、焦るあまりに開いていたウィンドウを見失ったりと、いろいろありました。人が見てるからって気にせずに、自分のスタイルを貫いたほうがいいです。そのほうが、ナビゲータからより便利なツールを教えてもらったりとか、得るものが増えそうだと感じました。 中堅ドライバ、若手ナビゲータ ２時間をやり終えて、次は小澤さんがプログラミングをしてるところを見てみたいと僕が言ったところ、休憩を挟んで更に２時間、役割を交代し、小澤さんがドライバ役となって僕が前日に書いていた別のコードの リファクタリング をすることになりました。横で人のプログラミングを見ていると当然のことながら、色んな発見がありました。 まず、 いろいろと捗りそうな、自分でも真似したいツールやその使い方の発見 がたくさんんありました。ツータッチぐらいで一瞬で画面が変わってしまい、「い、いまなにやったんすか！？」ってやつです。例えば、画面に一瞬でCotEditorが出てきた時は、いまどうやってそれを開いたんですか！ということがありました。 また、 いろんな場面での気持ちの持ち方が自分には無いな と思いました。気持ちの持ち方なんて、 ペアプロ 以外じゃあんまり伝わってこないです。プログラミングを進めていると、急にテストが通らなくなったとか、急にエラーを吐くようになってしまったりすることがありますよね。調子に乗ってあれこれ書き進めた後だったり、元に戻しても戻んない！なんて場合は慌ててしまいませんか。泣きたくなりますよね、あるいは。先輩のプログラミングを見ていて、「こんな時はまずココを見て、そんで…」と淡々とした落ち着きが伝わってきました。たしかに、慌てても何も解決しないわけで。 あとは、 落とし所の判断の仕方が参考になりました 。プログラミングっていろんな方向から評価されますよね。見た目、品質、性能、書き上げる早さとか。しかもそれぞれ トレードオフ がある。どこかでスライダのつまみの場所を決めないといけないわけです。「あんまり無理せず、ここらへんにしときますか。」っていう判断って、価値観によるので組織とか個人によって違ってくると思います。その判断のプロセスがリアルタイムで横から見れたのはよかたです。 ナビゲータとして心がけたのは、 ドライバにおいていかれそうになったら常に質問する ことです。小澤さんの端末の画面がめまぐるしく変わるので、何回か置いて行かれそうになりかけたのですが、そんなときは「いまは〜〜をしようとしてるんですよね？」と絶えず質問していきました。これも教科書に書いてあって、実践してその重要性に気づいたことの１つです。 最後に 今回はさしあたって１回やってみての感想をお送りしました。これで一人でやった場合とトータルでどっちが効率的かとかはまだわかりません。 ただ、一人のプログラミングに戻っても ペアプロ で得たものは役に立っている気がします。困った時、あの人なら あーす るだろう、こうするだろう、こう考えるだろうというのがイメージしやすくなりました。 ペアプロ がもっと広がっていくといろんなメリット・デメリットが出てくると思います。得られたノウハウはまた今度お伝えします。

エンジニアのにのみやです。 トレジャーデータが新サービスを発表するというので行ってきました。 内容については以下のようなメディアで記事化されている他、 トレジャーデータ，新サービスを発表 ─高速クエリエンジンとデータ可視化エンジン トレジャーデータ、POSデータ300億件が30秒で処理できるビッグデータ分析 米トレジャーデータ、DWHのクラウドにアドホッククエリーなどを追加 以下ではパネルディスカッションの様子も詳しく書かれています。 『トレジャーデータ、新サービス発表！〜進化したクラウドデータサービス〜』に参加してきた なので、ここではこのような会に参加したきっかけや個人的な感想等を書いてみたいと思います。 エニグモ にはEG labという制度があり、エンジニアが技術的に興味があることを試したり作ったりすることができるようになっています。(参考:  金曜は午後フリー？！エンジニアの「やる気」に火をつける。エニグモのスゴい社員モチベート術 ) 以前からこの時間には ビッグデータ 関連のことをやっていました。バイマでは世界75か国に在住する4万5千人のバイヤーが随時出品を行なっており、それらを150万人の会員が購入しています。ここから得られる大量のページ閲覧データや取引データをもとに、商品詳細ページで提示するおすすめ商品を出してみたり(レコメンデーション)、ある商品Xを買った人は別の商品Yも買う傾向にあるといったルールを抽出(バスケット分析)したりするわけです。最初は自社でサーバを用意してCloudera Managerで管理するといったことをしていました。しかし、ラボとして試してみるにしてはサーバ管理といった周辺作業が面倒なのと、バイマの成長に伴ってデータ量も増大していくこと(スケーラビリティ)を考えると クラウド サービスを活用した方が良いということになりました。こうした中でSkytapやJoyent、そしてトレジャーデータのサービスを試用したことがあります。 そのときはウェブサーバのログをtd-agentで拾ってトレジャーデータのサーバに流し込み、ため込んだデータを分集計したりエクポートしました。その際、td-agent設定ファイルに書くログフォーマットについて太田さんとチャットしてカスタマーサポートを受けたことがあります。 今回は、そのトレジャーデータが新しいサービスを発表するというのでどんなものなのか気になったのと、太田さんが話すということなので参加してみることにしました。 新製品として発表されたのは アドホック 解析エンジンのTreasure Query  Acceleratorと可視化ツールのTreasure Viewerです。これまではエンジニア向けの機能しかなかったのですが、ついに マーケティング 担当者や営業担当者も使えるような製品を出してきました。 ビッグデータ 業界ではこのような流れがあるので特に驚きはないのですが、Treasure Query  Acceleratorは スキーマ レスである点が特長だということです。 上の写真はTreasure Viewerを太田さんがデモンストレーションしているところです。 ドラッグ&ドロップ で操作できるなどUIを工夫しているようです。 トレジャーデータを活用している顧客の例として回転寿司チェーンのスシローの話がありました。注文時に使用するタッチパネルのクリック(?)データを分析し、寿司ネタの表示配置を変更したところ売上が大幅に増加したということです。ウェブページのボタン配置最適化と似ています。 PentahoやTableauといった アドホック 分析・レポートツールや、ストリーミングデータをリアルタイムに処理するCEP(Complex Event Processing)は ビッグデータ の中でもアツい分野なので、EG labを活用して今後も注目していきたいと思っています。

エンジニアのおざわです。 エンジニア部門にはラボ制度というのがありまして、 売上とかいいかんじにみんなの見えるところに表示したい という取り組みを行いました。 結果 そうだね、見せられないね。 上の方に数値、下の方にグラフが表示されているのがわかるかと思います。 正直に申し上げますと、 Team Dashboardで目標数字をチームで共有する - komagata  というブログエントリを読んでやってみたいと思ったのでやってみたのです。 そちらのエントリにある通り、 Team Dashboard  というソフトウェアを利用しました。 Jenkins のステータスや Shell Command の実行結果をデータソースに数値やBoolean、グラフを表示したりできるのですが、今回は BUYMA の数値を取得するために http_proxy データソースを利用しました。 http_proxy はその名の通り、Team Dashboard から HTTP でデータソースにアクセスします。結果を JSON で返すと数値やグラフを表示できます。 そのために JSON を返す API をアプリに用意しました。 たとえば、 { " users " : { " total " : 300 , " today " : 10 } } みたいな JSON を返して、以下のように設定すると数値を表示できます。 [ { " target " : " PC " , " datapoints " : [ [ 0 , 1385737200 ] , [ 24 , 1385737800 ] , [ 40 , 1385738400 ] ] } , { " target " : " SP " , " datapoints " : [ [ 0 , 1385737200 ] , [ 65 , 1385737800 ] , [ 94 , 1385738400 ] ] } ] こちらの JSON は、グラフを表示するときに使います。配列の0番目が値、1番目がタイムスタンプです。target の数だけグラフを重ねて表示できます。 グラフの設定も簡単です。 Source を http_proxy にして、 Proxy Url にさっきの JSON を返す API を指定するだけです。Periods 、Targets で指定した値が API のパラメータに渡ってきますので、いい感じに JSON を返してあげてください。 今はこんな感じで執務室入り口の壁に表示しています。 以上、簡単ではありますがチーム ダッシュ ボードの紹介でした。 エニグモ では思いを壁にぶつけたいエンジニアを募集しています。 http://www.enigmo.co.jp/recruit/

EGテックブログを始めることになりました。 技術的なことを中心に、エンジニ アメンバー が持ち回りでブログポストしていきます。 宜しくどうぞ。 先ほどわかりやすく「テックブログ」と書いたわけですが、 エニグモ のエンジニア部門にはService Engineering本部というれっきとした正式名称があります。 その昔、運良く創業メンバーの安藤から声をかけてもらい エニグモ に入ることになったのですが、実は当時の エニグモ は システム開発 は全て外注していました。作れる人がいなかったためです（現在はフル内製化しています。その辺りはまた別途）。 そんな中たまたま一人目の技術系社員として入社しまして、当然一人しかいないので部門も何もないわけですがとりあえず部署名を考えることになりました。 「どうしよっか？」ということですかさずブレストが始まったわけですが、こだわったことは1つ。「システム」という言葉を使わないことでした。 「オヤジが出てきそうな響きで、嫌っすねぇ！」といった旨の発言をした記憶があります。 （語弊がありそうな表現ですがそこは見逃して頂いて）要は一度しかない人生、自分が納得するサービスを自分たちの力で作り上げていきたいという意気込みだけは当時からあったような気がします。 ユーザファーストとかUXとか、最近だとグロースハックとか色んな言葉やテクニックがあり、現に自分も勉強しているわけですが、何よりも大事なことは「自分ならこうしたい」といった情熱だなぁと最近つくづく感じます。 そんなサービスエンジニアリング本部。 エニグモ らしさを大事に、いいサービスを作っていきたいと思っています。 それでは！！