株式会社エニグモ の技術ブログ
全241件
エニグモ でWEBエンジニアをやっております、大宮です。 今回は、先日英語版 BUYMA で行った、AMP対応についてまとめた記事をお届けしたいと思います。 そもそもAMPとは？ Acceralated Mobile Pages の略です。 その名称が示す通り、モバイル端末で高速なWebページを表示させるためのプロジェクト、またはそのための フレームワーク (AMP HTML)の事です。 フレームワーク は Google と Twitter により共同開発されています。2016年の2月にローンチされて以降、AMP対応を行っている企業は増え続けています。 Google からは今のところは明言されていませんが、メインの開発に Google が入っているということで、いずれ SEO の上位表示に影響してくるのではないかという予測も立てられているようです。 現に、一部の記事ページでは スマホ で検索するとカ ルーセル で検索結果の上位に表示されます。 近年は 新興国 でも スマホ 文化が普及する一方、回線速度の遅さが問題視されることもあり、AMPはこうした時代の流れにも対応したものと思われます。 国内を見ても 格安SIM や通信容量制限による低速化などにより、WEBページの体感速度の向上はますます重要な要素になってきています。 ページが速く表示されるだけユーザーの満足度は向上するというのは、想像に難しくないでしょう。 実際に見てみましょう 実際に対応された英語版 BUYMA のサイトを見てみましょう。 AMP未対応のページ（ベンチマーク計測：11.5秒） AMP対応のページ（ベンチマーク計測：3.5秒） AMP対応のページをキャッシュしたAMP Projectページ（ベンチマーク計測：0.76秒） ベンチマーク は低速な回線で撮ったものです。 体感でも表示速度が一番下のキャッシュ速度が速い事がわかるかと思います。 なお、上記AMPのページはPC版で見ると崩れているように見えますが、 CSS をモバイルに最適化した(PC対応の CSS を排除した)結果です。後述する実装でAMPを別URLとした場合、AMPのページがPCからみられることはありませんのでOKとしています。 なぜ速いのか？ AMP対応のHTMLは読み込みが非常に速いです。その理由を見てみましょう。 - AMPでは、非同期のAMP専用JSしか使用出来ない。 - CSS のサイズ制限＋外部ファイルに置く事を禁止している - 画像のLazy Load＋幅高さ指定の強制でブラウザの負荷を軽減 特に一番大きいのは最後のLazy Loadでしょう。 通常 Webブラウザ はページの表示時でページ内のすべての画像を読み込もうとしますが、AMPでは表示領域のみ非同期で画像をロードしてきています。 それを可能にしているのが <amp-img />タグ です。ampページでは通常の<img />タグは使用できず、すべてこちらに置き換える必要があります。 また、 CSS のサイズ制限があるので、リッチなコンテンツの量は増やしづらく、AMPページとしては余分なモジュールを削りおとすことになり、全体として読み込むファイルサイズが軽減されやすいということです。 さらに、これらのHTMLは、 AMP-Projectの CDN サーバーにキャッシュされ、検索結果での表示時にはキャッシュされたページを表示するようになります。 このキャッシュ時に、画像もモバイル用に圧縮をし、ファイルサイズを軽減しています。 さらに検索結果の表示時には、ユーザーが見ている検索結果の部分で、裏側でPreconnect / Prerenderingが走っています。 ユーザーが検索結果からページにアクセスしようとしてタップした時には、すでに裏側でページが読み込まれているため、ユーザー体験としては爆速に感じるということです。 AMPの三大制約 AMPを実装するにあたって、設計の段階で留意すべき制約は３つあります。 - JSが使えない* - CSS は50KBまで - Cookie が使えない ということ。言い換えれば リッチなページは作れません。 ログインユーザーに応じて出しわけ...などの機能は使えません。 ということです。 JSが使えないというのは、自前のJSは一切使用不可ということで、JSでよく使用される機能について、ある程度はAMP-Projectの方で用意されています。 例えば、サイドバー、カ ルーセル 、フォームのバリデーション等。詳細は 公式のこちらのページ に記載されています。 また、JSに関しては、2017年6月現在、 amp-bind という機能が開発中です。 リリースされればJSで自前の スクリプト を書いた時ある程度は同じような挙動を実現できるようになります。 具体的には、イベントトリガーでclassやInnerText, attributesの値を動的に変更するということが可能になります。 が、それでも既存のJSの流用はできないため、amp-bind用に書き直す必要があります。 URL方式の設計 まずは上述のように、できることとできないことをただしく把握する必要があります。 基本的に上の項目を把握されていれば問題はありません。 次に、AMP用に新規URLを作るのか、既存ページをAMP化させるのかを決めます。 モジュールを分けるかわけないかという選択ですね。 可能であれば、メンテナンス性を考えて同一モジュール...つまり今あるページをAMP化し、新規では作らないというアプローチが望ましいです。ただ前述の通り、AMPには制限がありますので、オリジナルページを残したい場合もあるかと思います。 その辺りはページのボリュームと、JS書き直しの 工数 （既存機能への影響）を加味して判断する必要があります。 ちなみに新規でページを作る場合には、最初からAMPに対応したものと作成してしまえば、既存ページへの差し替えで悩むことはなくなります。 画面の設計 基本的にはオリジナルページから何を残して何を削るのかを判断する必要があります。 オリジナルページをそのままAMP化しても、 CSS の容量超え＋JSの リッチコンテンツ で実現可能なものと不可能なものが出ると思います。 なので AMPページの要件として絶対に必須なものを厳選して残し、 CSS 容量や 工数 に余裕があれば別の機能の対応も行う というアプローチが良いでしょう。 実際に開発してみてできること、できないことが分かるという事もあります。 なお、前述の弊社サイト（商品詳細ページ）では、商品情報＋カート購入機能だけを残して、グローバルナビや検索バーといった要素は排除しています。これらの要素はAMPでも代替は可能ではありましたが、 CSS の容量制限の関係で断念した要素でした。 実際にAMPページにしてみる AMP専用の雛形がありますので、ご自身のサイトにあててみましょう。 bodyタグやheadタグや CSS は適宜調整していただければ良いかと思います。 これで、サイトはAMPとして扱われます。 なおAMP用に新規でURLを作る場合には、オリジナルページのHTMLのheadタグ内に下記を記述しましょう。 <link href="AMPページのURL(フルパス)" rel="amphtml"> これで Google にもAMPページが認識されます。 ただし、エラーが出る（多分） Chrome の開発者モードを開きURLの末尾に#development=1とつけましょう。雛形をそのまま使っていない限り、このように大量のエラーとなるはずです。 弊社サイトの対応途中で怒られていた内容としては、主に下記のような内容です。 img -> amp-imgに変換＋幅・高さ指定してください scriptタグの使用してる所を全部削除してください a href=" javascript :void(0);"など css をインラインで読み込みしてください css のファイルサイズを削減してください このエラーを解消しないと、 Google からAMPページとして認識されませんので、すべて対応しなければいけません。 根気よく対応していけば、いずれは下記のように「AMP validation successful.」となりますので、頑張って対応しましょう。 WEBアプリケーションの場合はVIEWにIF文があることも多々あるので、当然ながらその条件分岐は全パターンみておく必要があります。 晴れてエラーがでなくなれば、本番環境にデプロイして、完了となります。 この時本番環境でしか動いてない監視用のJSなどがあると、またエラーになってしまいますので、注意深く観察しましょう。 終わりに AMPはそれなりに 工数 もかかる上に、完成する画面としては真新しいものではありません。 むしろ既存の画面より機能が削ぎ落とされたものなので、パッとみた完成品は物足りなさを感じるかもしれません。 なかなか成果のわかりにくい改修ではありますが、実際にAMP対応によって数字の伸びた事例も挙がってきています。 何より低速回線のユーザーにも、快適な挙動のページをお届けするという意味で重要な要因となりますので、ぜひとも導入を検討していただければと思います。 本記事がその際の一助となれば幸いです。
みなさんはじめまして！ BUYMA で iOS アプリのエンジニアを担当している、松本と申します！ 先日6月2日に行われた Repro User Meetup #1 に登壇してまいりましたので、その様子をお伝えします！！ Reproとは？ Reproとはアプリに特化した、アナリティクスツールです。従来のツールと大きく違う点は、ユーザーの行動を 動画で確認 をできる点と リテンション分析・ファネル分析 といった機能によってユーザーの重要な行動を細かくト ラッキング できる点です。詳しくは、 ReproさんのHP をご覧ください 当日の様子 当日はReproを活用されている10社様が登壇され、様々なReproの活用法や成功事例が発表されていました。 各社様の発表内容はコチラから BUYMA でのRepro活用 新規ユーザーにまず継続的にアプリを使用していただくことは、どのアプリにおいても非常に重要な事と言えると思います。 Reproのリテンション分析では、特定のアクションを行ったユーザーのリテンションを測定するといったことも可能であり、今回のRepro User Meetupでは新規ユーザーに対して最も効果的なイベントをどう判断するかという事について発表を行わさせていただきました。 詳しい内容はこちらのスライドをご覧ください！ BUYMAにおけるRepro運用 from Takashi Matsumoto Repro株式会社取締役 CMO の中濱 康広様（中央）と弊社松本（左）と松永（右）
お久しぶりです。アプリケーションエンジニアの木村です。 BUYMA では、この記事を書いている時点で世界中から出品された約155万件の商品が検索可能となっていて、商品検索機能は世界中から自分の欲しい物を探すことを実現する、まさに「世界を買える」を実現するための重要な機能の１つとなっています。今日はそんな BUYMA の検索機能の裏側を支える基盤部分についてご紹介いたします。 BUYMA では検索機能実現のためにはSolrを導入していて、さらにSolrCloudを構成しています。 SolrCloudとは SolrCloud は、高信頼性、耐障害性、拡張性を運用コストを抑えつつ実現するSolrの クラスタリング の仕組みです。紙面の都合上あまりSolrCloudについて詳しく説明できませんが、下記リンクが参考になるのではないでしょうか。 https://cwiki.apache.org/confluence/display/solr/SolrCloud http://www.slideshare.net/kenhirose547/10solr-solr-cloud あまりWeb上に詳説された記事がないので、下の書籍も参考にしつつ構築にとりかかりました。 -『Solr in Action』Trey Grainger-Timothy Potter (2014) Manning Publishing. -『改訂新板 Apache Solr 入門』大谷純-他(2013) 技術評論社 . -『Scaling Apache Solr』Hrishikesh Vijay Karambelkar (2014) Packt Publishing. -『ZooKeeperによる分散システム管理』Flavio Junqueira-Benjamin Reed [著]、中田 秀基 [訳] (2014) オライリー -ジャパン さらに、上の２つ目の本も監修されている ロンウィットさんのトレーニングも受講 しました。最後の本はSolrCloudに組み込まれるZookeeperの本です。 BUYMA でのSolrCloudの構成 BUYMA のでのSolrCloudの構成を表したものが下の図になります。 更新のしくみですが、Solrを更新するバッチが常に動いていて、DBから更新がかかった商品情報を取得し、leaderのSolrノードへ更新リク エス トを送ります。するとSolrCloudの仕組みとして、leaderノードが他のreplicaノードへ更新を伝えて全ノードが更新されます。 検索は Rails のWebサーバーから直接SolrCloud内のSolrノードへリク エス トします。特に ロードバランサー 用のサーバー等は挟まず、SolrノードのIPをランダムに選び、そのIPへリク エス トを飛ばすように、 Rails アプリ側でロードバランシングしています。 耐障害性への取り組み Rails のWebサーバーから直接SolrノードのIPへ検索リク エス トが飛びますが、各Solrノードの IPアドレス はそれらを監視しているZookeeperから取得しています。したがって、いずれかのSolrノードで障害が起こった場合でもそれをZookeeperが感知し、リク エス ト可能なIPの一覧からダウンノードのIPを外してくれ、ダウン中や リカバリ 中のノードへは常にリク エス トが振られない仕組みになっています。 更新時も更新バッチがZookeeperからleaderであるSolrノードのIPを取得し、それに対して更新リク エス トを飛ばしています。もしleaderノードで障害が発生し、フェールオーバーして別のノードがleaderとなった場合でも、Zookeeperがそれを感知して更新バッチ側へleaderの変更が伝わる仕組みです。 実は、Zookeeperと連携してそこらへんの面倒な処理をやってくれる SolrJ というSolrCloudにも対応した Java 用のSolrクライアントがあるので、 JVM のWebアプリではそれを使ったり、そうでない場合はSolrJを使った API サーバーを検索クライアントとSolrとの間に挟む構成が通常なんだそうです。ただ、そのためのサーバーの運用保守もコストなので、 Ruby からZookeeperと連携するSolrCloud用の Ruby クライアントを自分たちで作りました。gemとして公開していますので、ご自由にお使いいただいてフィードバック等をお待ちしております。 https://github.com/enigmo/rsolr-cloud BUYMA の検索基盤クロニクル BUYMA がシステム面で今の形に近いものに生まれ変わったのは2008年ごろ（らしいの）ですが、その当時公開されていたSolr 1.3系の時代から検索機能にはSolrが導入されていました。その後2011年に3.x系へとバージョンアップがなされ、2015年6月まで稼働していましたが、商品数の増加とマスキャンペーンにより大量のアクセスが予想されたため、マシンリプレースと合わせて2015年リリースされた5.x系へとバージョンアップしました。さらに、運用し易さを求めて、構成をSolrCloudとしました。 SolrCloud導入以前は、マスタースレーブ構成でもなく、Solrノードを並列にならべてそれぞれの IPアドレス を更新-検索クライアントとなる全サーバーに固定値で持たせていました。更新バッチは全Solrノードへ同じ更新リク エス トを何度も送る必要があり、１ノードでも更新に失敗すれば検索結果がノードによってズレてしまいました。Solrノードでの障害発生時やメンテナンス時にもそれぞれのサーバーのSolrノードのIPを書き換えてやる必要がありました。商品数やアクセス数の増大に伴って、この先ノード数を増やす場合にこの構成では限界を感じていました。また、仮にマスタースレーブ構成にしたとしても、マスターが単一故障点になってしまったり、障害対応の時の手間は変わらないというのが難点で、マスタースレーブ構成への変更にも二の足を踏んでいました。 SolrCloudはそういった煩雑さから開放してくれ、まさに自分たちにとっては渡りに船でした。結果、 スキーマ 変更や設定ファイルのチューニング、ノードの障害発生時の対応やメンテナンスが圧倒的にやりやすくなりました。マシンリプレースの効果もありますが、パフォーマンスも、導入前より向上しました。 今後 Solrのバージョンが3.xから5.xとなり、機能面でも新たに使えるものが増えたので、 BUYMA の検索の機能面としても向上していければと思います。
はじめましてデザイナーの篠原です。 ECサイト のデザイナーならではのトピックをお伝え出来ればと思います。 はじめに私の担当は主に運営しているサービス「 BUYMA 」に関してのデザインになります。 「 BUYMA 」でのデザイン業務は大きくわけて、 1.トレンドと連動したキャンペーンページやバナーの作成 2.機能改善・新規開発に伴うページやUIの作成 になります。 細かく分類すると他にもありますが、大きく分けるとこんな感じだと思います。 今回は「トレンドと連動したキャンペーンページの作成」時に気をつけている事を、順序立てて書いていければと思います。 ざっとページ作成の流れはこんな感じ STEP1「構成」 STEP2「 ヒアリ ング」 STEP3「デザインイメージを探す、集める」 STEP4「デザインを考える (頭の中で)」 STEP5「プロトタイピング→デザイン(グラフィックソフトを使ったデザイン)」 STEP6「コーディング」 STEP7「ブラッシュアップ(もうひと頑張り)」 STEP8「公開」 STEPを通して、それぞれどんな事を考えているのかを書いてみようと思います。 STEP1「構成」 BUYMA では日頃からトレンドをウォッチしているMD担当のスタッフがいるので、 企画概要やデザインへ盛り込む要素などは、そのスタッフがあらかじめ決めることが多いです。 企画の規模によっては最初からデザイナーも入り共に構成を考えたりもします。 キャンペーンページでは特に売れ筋や定番人気の商品を BUYMA としてどう見せていくかを意識して考えていきます。 STEP2「 ヒアリ ング」 前STEPとほぼ同時の事は多いのですが、あらかじめ構成をもらっている場合にはこの段階で、 「テーマ」「ターゲット」「トレンド」「企画を考えた時に感じた事」「データからのユーザー分析」「スケジュール」 あたりをしっかり ヒアリ ングします。 内容を整理しデザイン面で懸念があればしっかり認識合わせをしておきます。 STEP3「デザインイメージを探す、集める」 ヒアリ ングで得たものから、同じテーマのデザインをネットで集めたり、 過去の経験から似たようなイメージを引っ張りだしたりします。 色が似ているとかフォントが似ているとか、なんでもヒットしたものを探して、 イメージを広げていきます。 印刷して実際にデスク上にバラバラと広げたり、 ホワイトボードとかにぺたぺた貼っていくとかも良いと思います。 企画を聞いてから色々と探してもいいのですが、 やはり普段から準備しておく事でスピードアップできます。 私の場合はとにかく「パッと見」でたくさんのものを見ておくことを大切にしています。 断片で覚えている方がよりクリエイティブな感覚をもたらすからと考えています。 ちなみにこの「パッと見」の際は、こちらのサイトとかよく見ます。 designspiration.net とか pinterest ですね。 BUYMA というサービスは海外との繋がりを楽しむ、または感じてもらうサービスなので、 海外のデザインからインスピレーションを得ることも多いです。 特にファッション性の高い見せ方、トレンドなどは常にチェックしています。 ついでに、ファションだけでなくカルチャー、経済、ゴシップネタまで、ユーザーの取り巻く環境を幅広く把握しておく様に、雑多に情報収集するのも良いデザインに繋がったりすると思います。 STEP4「デザインを考える」 前STEPで集めたものに対して、 「自分だったらこうする」という軸で考えていきます。 自分の審美眼をあてにしながら、色々と感じるままに考えていきます。 自分の関わるサービスに しっかりとした ブランディング がある場合は、「サービスに似合うのは何か」と考えていきます 。 BUYMA だとこちらの方が多いです。 この場合はサービスの審美眼をあてにしながら、という具合でしょうか。 STEP5「プロトタイピング→デザイン(グラフィックソフトを使ったデザイン)」 イメージがある程度まとまったら手を動かしていきます。 徹頭徹尾まとめてからだとうまくいかない事が多いので、ある程度がいいと思います。 アイディアの鮮度を大切に。頭がフレッシュな朝に回して手を動かすのでも良いと思います。 ちなみに手を動かすという事は文字通り手書きじゃなくても良いと思いますが、 イメージを素早く出すのは手書きが良い場合が多いなと感じます。 大事なのはイメージをどんどん頭から出す事 だと思っています、 頭からイメージを出していく事で新たなアイディアが入るスペースが出来るので、 短時間で様々なパターンを出す事が出来ると思います。 そもそもイメージが浮かばない場合はSTEP3に戻ってやり直します。 その後、 デザインが軽くまとまったらプレビューの場を設けます。 注意したいのはこのプレビュー時にデザインが出来上がりすぎている事 です。 意見の入る余地がないものを仕上げてからだと、 デザインへのこだわりが強くなっていて引けなくなっちゃったりしますし、 その思いが伝わって良い意見ももらえなかったりします。。。 なので、批判を恐れずにプレビューする事を心がけると良いと感じます。 方向性を定めてデザイン的に問題ないものが出来たら、 そのデザインに合わせたバナー作成もこのタイミングで行っていきます。 STEP6「コーディング」 ここは分業の場合も多いと思いますが、 僕らはデザイナーがコーディングまで担当する様にしています。 Webデザイナー は、各デ バイス 、ブラウザの特徴を把握し、 特性や利点を活かし、欠点を補うデザインが求められる職業だと考えています。 それはデ バイス 問わず成立するデザインを考えるということでもあると思います。 なので良いデザインをするためにコーディングの知識は必要と考え、極力担当をする様にしています。 また BUYMA ではエンジニアと一緒になってページを作る機会も非常に多いので、 HTMLだけでなく PHP や Ruby についてもデザイナー側に知識がないと厳しい 、 という経緯もあり普段からソースに触れる様にしているのもあります。 STEP7「ブラッシュアップ(もうひと頑張り)」 実際にはこのタイミングなのか、もしくは途中のタイミングでもあり得ますが、ページ公開に向けてブラッシュアップをしていきます。 ここで良く考えるのは(というより言い聞かす様にしているのは)、 ここまで試行錯誤しながら作ったものであろうが、今の完成度は80%だと思う事 です。 UI作成の場合はこの時点では改悪しないものが出来た、と思う様にしています。 誤解を恐れずに書くと、 ブランディング を考慮し、トンマナを守った上で出来たものはまだ完成度が80%程度なのだと思います。 ここからどこまでやるかは周りの反応だったり、それこそ個人の感覚が大きいと思いますが、 人を感動させるもの、気持ちを動かすもの、UIにおいての改善と呼べるレベルのものは、 ここからのブラッシュアップによって達成出来るものと考えています。 STEP8 「公開」 BUYMA では各担当者から公開依頼を一度システム管理者へ回します、 そこでサイトにクリティカルな問題がないかを確認した上で公開されます。 公開されたらもう一度自分が考えたデザインになっているかサイト上で確認を行い完了となります。 ページ公開後は、 良い反応があるかどうかをGAなどでチェックしたり、 実際にインタビューしたりなど、効果を追っていく流れになりますが、 こちらは担当Dirから共有してもらう事が多いので、デザイン作成としてはここで一旦完了となります。 という事で、だいぶ文字ばかりになってしまいましたが、 以上がデザインが出来るまでの基本的な流れです。 この様な基本となる流れを「素早く」「精度高く」こなす事で余裕が生まれ、 よりクリエイティブなキャンペーンページのデザインが出来る様になると思います。 最後になりますが、たまに休憩を取る事も大切なので、時折コーヒータイムでも挟みましょうね。 ではでは、良いデザイナーライフを。
はじめまして。エンジニアの小金澤です。 つい最近、類似画像検索という言葉がふと耳に入ってきたので、調査してみました。 意外と参考となる記事が少なかったので（というか...小難しい記事ばかりでした）、纏めるのに少々苦労しましたが、最終的には技術的検証まで行いたいと思います。 概要 画像検索には、TBIRとCBIRがあるらしい。 そしてTBIRとCBIRの両方を用いて画像検索を行うものがあるらしい... また、この２つ、TBIRとCBIR両方を用いて検索する方法が最も目的の画像を抽出することができる...らしい...... ということで本当に類似検索できるのか、まずは簡単そうな??CBIRについて調査・検証してみたいと思います。 また、軽くTBIRにも触れていきます。 1. 類似画像検索ついて TBIR (Text-Based Image Retrieval) 主にテキスト情報と画像を紐付けて画像を検索する手法のこと。つまり画像に対してテキスト情報を付け加えて情報を保持する必要がある。 CBIR（Content Based Image Retrieval） 画像の形状特徴や色特徴を基に類似する画像を分類し検索を行う。 2. 検索 アルゴリズム Earth Mover's Distance (EMD) 2つ ユークリッド 距離（ ヒストグラム ）を距離尺度を計算する。 EMDとは、A画像とB画像が持つ2次元 ユークリッド 距離（画像なので2次元としました。）比較しその距離間を計算します。 もっと簡単にちょー分かりやすくいうと、画像の特徴をハッシュ化しお互いの ハッシュ値 を比較する。※大分語弊ありありですが... また、特徴としては、画像を決められたY/X座標毎に分割し、分割した画像の ヒストグラム を計算しハッシュ化します。 そして分割したハッシュの総和を比較するというわけです。 ※ 画像に紐付いたテキスト情報も含めて、計算することもできるらしい。TBIR/CBIR２つの情報を元に計算することも可能。 Histogram Intersection 色の類似度を計算する アルゴリズム 。 こちらは、EMDに比べもう少しわかりやすいものとなってます。 色の比較です。単純ですね。赤（R）、緑（G)、青（B）の各成分が画像中に何 ピクセル あるかを計算し、比較するというものです。 Average Hash(aHash) Perceptual Hashを使い計算する アルゴリズム Perceptual Hashの生成方法は以下のとおりです。 画像のリサイズする（8x8=64ビット/16×16=256ビット） 色を削減する（グレースケールに変換） ピクセル 毎の色の平均値を算出 ハッシュを構築（各 ピクセル 毎に平均値以下か以上かを設定しハッシュ化する） 以下、この アルゴリズム の作成者（Dr. Neal Krawetz）のブログです。 http://www.hackerfactor.com/blog/index.php?/archives/432-Looks-Like-It.html 本格的なPerceptive Hash(pHash)を使って計算する場合は、離散コサイン変換(DCT)をする必要があり、また、コストがとても高い（重い）ため、現在は、Average Hashが話題になっているようです。 3. 次回予告 次回は、このAverage Hashを使い実際に以下のGemと画像を使い Ruby で検証していきたいと思います Gem github.com 画像 最終目標 aHashより算出した ハッシュ値 をDBへ保存 フロントから入力された画像のaHashより ハッシュ値 を算出 DBにある画像 ハッシュ値 と入力画像の ハッシュ値 を比較し類似画像を抽出!! 乞うご期待!!!
はじめまして、エンジニアの高松です。 今回は先日リリースした、「色・サイズ改修」でのフロントエンド開発についてお話したいと思います。 概要 「色・サイズ改修」は、主に以下を目的としたプロジェクトです。 購入可能な色やサイズが、ひと目で分かるようにする 次期リリースで、色とサイズを選択して購入できるようにすることで、誤注文を減らす 商品の色・サイズのデータを蓄積し、運営に活かす リリース時のお知らせが こちら です。 BUYMA はC2Cのショッピングサイトなので、改修は大きく出品側と購入側に分かれます。 開発は私と部長の2人体制、さらにデザイナーのチームで制作しました。 私: 出品側開発 部長: 購入側開発 デザイナー: 全般的なデザイン 開発の始まり 部長が先行して開発した部分を引き継ぐことから、開発は始まりました。 引き継いだのは、500行ほどの JavaScript でした。 検討中の画面の仕様と併せて見ると、動的な制御の多いポップアップ画面のコードの一部です。 $と_の量が多い事と、「ここは Ajax で取ってくるか?」というコメントが気になりましたが、続きを書き始めました。 行き詰まり 少しずつ画面が動き始め、行数にして1300行を超えた頃でしょうか、開発が日に日に辛くなってきました。 ちょっとした修正にも時間がかかり、どこかを直せば、どこかが壊れます。 私(と部長)の書いたコードが読みづらく、 子泣きじじい のように重くのしかかってくるのです。 「このまま作りきれるのか...」不安が募ってきたところで、一度書いたコードを捨て、Backbone.jsで書きなおすことを決めました。 一部ですが、既に BUYMA の中にはBackbone.jsで書かれた部分があったのが理由です。 Backbone.jsの導入 結果、Backbone.jsを使って書き直したコードは、以前よりずっと可読性が高いものに生まれ変わりました。 開発で使ったのは、View・Collection・Modelといった、Backbone.jsのベーシックな部分で、 ルーター などの機能は使っていません。 テンプレートエンジンには、 Handlebars.js を使いました。 Backbone.jsを利用して得られた、主なメリットは以下の部分です。 Viewとロジックが分離でき、イベントも所定の場所に書くので、処理が追いやすくなった。 CollectionがUnderscore.jsをラップしていて、使いやすい。eachやmapなどのコレクション系のメソッドや、findなどのファインダーメソッドが Ruby ・ Rails ライクで馴染みやすかった。 フレームワーク としてコンパクトで、学習コストは低かった。 結果として、ロジックの実装に集中できるようになったのが、一番のメリット。 逆にハマった部分です。 Backbone.jsのViewをappendすると、空のタグが入る。 jQuery のappendと、Backbone.jsのView::setElementを使い分ける必要がありました。 Viewが GC に入らず メモリリーク する。いわゆるゾンビビュー問題です。 ここは、ノウハウを貯めていかないといけないですね。 API だいぶ調子が出てきたタイミングで、部長と立ち話がてら、実装の話をしました。 部長: 「 API って Rails だよね?」 私: 「いえ、出品側は既存もあるので、全部 PHP でやってます。」 部長: 「いや、新規 API だから Rails で書けるじゃん。」 私: 「へっ???」 そうです、「ここは Ajax で取ってくるか?」のコメントを動かすために、 API を3本作りました。 以前の 部長のポスト に記載がありますが、 BUYMA のコードは少しずつ PHP から Rails に移行しています。 API は独立して作りやすいので、 Rails で書くのが社内では定石になっているのです。 新規でレガシーコードを増やしてしまいました、すみません... まとめ Backbone.jsの導入で、フロントエンド開発は随分捗りましたが、まだ課題は残ります。 共 通化 できる部分はexport、requireして読み込みたい サーバ側のModelとBackbone.jsのModelがほぼ一緒になるので、重複をなくしたい View -> Model、Model -> Viewの双方向のやりとりを多く書かなければいけない。 フロントエンドもテストが必要じゃないか? そうです、どれも最近のライブラリや フレームワーク が解決しようとしている問題ばかりです。 モダンなツールを導入して、解決していきたいですね。
Fluentdによるログ可視化が話題になってからだいぶ経ちますが、 エニグモ でも(念願の)ログの可視化を本番投入しましたのでその内容を紹介したいと思います。(完全系ではないですが、実用段階です！) 主な使用技術 Fluentd Elasticsearch Kibana AWS 構成図 構成の説明 各WEBサーバーが出力したログをFluentdが拾ってログ集約サーバーに転送、ログ集約サーバーが AWS にたてたElasticsearchサーバーにデータをPOSTするオーソドックスな構成となっています。 Kibana またログの可視化ツールではKibanaを使ってます。 Kibana4を使ってますが、Kibana3より格段に分かりやすくて気に入っています。 細かい話 使用しているFluentdのPlugin fluent-plugin-elasticsearch データをElasticsearchに送るため fluent-plugin-record-reformer ログを加工をするため 使用しているElasticsaerchのPlugin elasticsearch-cloud-aws AWS のEC2にElasticsearchをインストールして クラスタ 構成を組む場合、EC2 インスタンス 同士で通信しないといけないが、それを設定すれば簡単にやってくれる プラグイン 。あとS3へのSnapshotをとる機能のために使っている。 elasticsearch-head Elasticsearchを管理するための プラグイン 。一番良く使う。 elasticsearch-kopf 同じくElasticsearchを管理するための プラグイン 。TOPページで、"heap","disk","cpu"の使用率が横棒グラフで見れるのでそれは重宝しているが、他の用途には使っていない。。 Elasticsaerchの スキーマ 設定 Mapping Templateを使ってフィールドのデータ型や要素解析などを指定しています。 Elasticsaerchの定期的なSnapshotの作成/削除、定期的なIndexの削除 curator という大変便利なツールがあるので、 それを使って、Elasticsaerchの定期的なSnapshotの作成/削除、定期的なIndexの削除をおこなってます。 ログ可視化をして捗ったこと 平均レスポンスタイムの分析が容易。 レスポンスタイムが悪いURLが分かる。 端末別(PC or スマホ or タブレット or ガラケー )のアクセス数が把握が容易。 時間ごとの HTTPステータスコード の割合。 特定の時間だけ500が多いとかが分かる。 ある会員がどの画面遷移をしたかがすぐに分かる。 障害調査が素早くできる。特にこれまでは数十台のWebサーバーのログを grep していたので結果がでるまで何十秒もかかっていました。 等など 最後に 昔はログファイルを grep & AWK で頑張って解析していたのが、今は lucene queryでサクッと特定が出来ますし、遅い画面の集計や ステータスコード の集計も簡単にできるようになりました。 今後はもっとログ可視化システムを強化してもっと便利にしていきたいと思います。
こんにちは。 エンジニアの木村です。先日行われました ECNight#1 に参加しました。 発表しました。 ああいった場で発表するのは初めてで、発表順はくじで決まってまさかのトップバッターでしたが、時間も１０分ということでちょうど良かったです。 発表資料ですが、当日のものをよりスライドだけで伝わるように改変してあります。 迷っている人を後押ししてCVRを上げる from 慎太郎 木村 かなりユルい感じの、しかも上手く行かなかった取り組みについての発表でしたが、発表中の皆さんのいいリアクションを見たり、 Twitter 上や後の懇親会で良いコメントをいただけたりすると、発表しといてよかったなと思いました。勉強会マジックかもしれませんが。 この発表で少しでも社内の雰囲気が伝わればと思いますが、もちろん、もっとしっかりした取り組みもやってますということを申し上げときます。 感想 ライトな感じのイベントだったとは思うのですが、その中でも物流や決済についてのコアな話、ファッションECの歴史についての発表もあり、自身の仕事に直に関わるテーマばかりで、割と得るものが密に詰まったイベントでした。 懇親会も同じような悩みを持つ同業者間でア イデア やノウハウを共有できた貴重な機会でした。 それから、過去の 大川さんの記事 の最後も同じようなことを言っていますが、勉強会ドリブンというか、そういった気持で日々の開発に取り組もうという気持ちになりました。
こんにちは、デザイナーの 細田 です。 ECサイト のデザインにおいても、バナー制作は欠かせません。 今回は、私がバナーを作る際にいつも意識している「足し算と引き算」について書きたいと思います。 まずはじめに：「ECバナー３箇条」 私がバイマのバナーを作る際に、特に大事にしている３点があります。 通称「ECバナー３箇条」です。（私しか呼んでいませんが） Ⅰ アイテムが魅力的に見える・買いたくなる Ⅱ パッと目をひく Ⅲ しかしずっと見ていても疲れない 商品を売るサイトなので、Ⅰは大前提です。 そして今サイトが一番PRしたいもの＝バナーなので、 しっかりユーザーの目を惹きながらも、（Ⅱ）広告のようなギラギラと押し付けがましい印象にならないよう心がけています。（Ⅲ） バイマは「ファッションサイト」であるため、 “あくまでオシャレ、しかし目を引くバナーで商品をPRする” これを目指すゴールとしています。・・・なかなか難しいですが。 その１：バナーを「背景」「アイテム」「タイトル」の３要素に分ける 私はバナー制作をする際、「背景」「アイテム」「タイトル」の３つに分けて考えます。 通称「バナー３兄弟」です。（こちらも私しか呼んでいませんが） そうする事で、今回のテーマである「足し算と引き算」が行いやすくなります。 といわれても文章だけではイメージしずらいと思いますので、実践編を見てきましょう。 その２：実践してみよう 『背景が派手なバナー』 ジミーチュウの新作紹介バナーを、「華やかなイメージで」という依頼がきました。 指定されたアイテムを見ると、国旗など派手めなものもありつつ、黒や茶など若干ベーシックな印象を受けたので、背景は思い切ってピンクのラメを敷いてみました。 後はタイトルを入れれば完成ですね。 ・・・ 「華やかに、華やかに」と念じながら、タイトルも思いっきりゴージャスにしてみました。 結果、確かに華やかにはなったかもしれませんが、アイテムの印象が薄れ、見ていて疲れてしまいますね・・。 「まずはじめに」で挙げた３箇条で言えば、Ⅰ とⅢ が達成されていません。 これを３兄弟で表すとこうなります。 ここで登場するのが、「足し算と引き算」です。 ずっと見ていて疲れないバナーにするためには、「３兄弟で派手なのは１人だけ」 と私は考えています。 今回はタイトルを引き算してみます。 ・・・ タイトルを黒地にし、ぐっとクールにしてみました。 こうすることでアイテムが引立ち、背景の派手さもほど良く抑えられました。 ３兄弟はこうなります。 ECサイト では、アイテムはディレクターから指定される事が多いと思いますので、残る背景及びタイトルの「派手〜地味」を足し算・引き算していくことになります。 場合にもよりますが、「派手」「中間」「地味」がそれぞれひとつずつ というのが いいバランスなのではないかと感じています。 その３：実践してみよう 『アイテムが派手なバナー』 ミッソーニ のコラボバナーの依頼がきました。 ミッソーニ のアイテムはどれもカラフルで派手だったので、背景やタイトルは極力シンプルにしました。 ３兄弟だとこちら。 これでもシンプルで見やすいのですが、パッ見の印象を強くするため、もう ワンメイク してみましょう。 タイトルの色はそのままで、フォントを変えてほんのすこしの華やかさを足しました。 ３兄弟でいえば、タイトルを「地味」から「中間」にするくらいの足し算です。 こちらも、「派手」「中間」「地味」がそれぞれひとつずつ、となりました。 以上が、バナー３兄弟を使用した「足し算引き算」となります。 冒頭に述べた「ECバナー３箇条」 Ⅰ アイテムが魅力的に見える・買いたくなる Ⅱ パッと目をひく Ⅲ しかしずっと見ていても疲れない を達成するために、「なにを足そう、なにを引こう」と考えながらバナー制作をしています。 同じく ECサイト のバナーを制作している方の参考になれば、幸いです。
こんにちは。 エンジニアの木村です。 先週末、社内有志で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/