こんにちは、エンジニアの大川です。 先週の木曜(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とか、最近だとグロースハックとか色んな言葉やテクニックがあり、現に自分も勉強しているわけですが、何よりも大事なことは「自分ならこうしたい」といった情熱だなぁと最近つくづく感じます。 そんなサービスエンジニアリング本部。 エニグモ らしさを大事に、いいサービスを作っていきたいと思っています。 それでは！！