VASILYでは、より良いアウトプットをするためにも デザインインプットの時間を週1回設けています。 画面遷移であったり、ちょっとしたアニメーションなど優れたUIをチームで共有し、 実際にiQONのUIやUXという部分に反映しようと日々、試行錯誤しております。 今回はその中で、VASILYデザイナーチームが2月に デザインインスピレーションを受けたアプリ をいくつかご紹介したいと思います。 1. Spring Apple Design Award 2014にも選ばれている、NY発の新コマースファッションアプリ。 ユーザ発信のコンテンツをブランドが上手く活用する という手法を取り入れています。 買い物本来の楽しさを味わってもらえるよう、あえてシンプルな構成 にしているそうで、全体的に 繊細で上品なアプリ というイメージを受けました。 2. Storehouse 写真、映像、テキストを織り交ぜながら1つのストーリーを作ることができます。 自由にレイアウトやトリミング可能なため様々な見せ方が可能です。 CEOが元AppleのUXエバンジェリスト ということもあり、公開されているストーリーは、どれも美しく、 思わず自分も投稿したくなるのがこのアプリの魅力 です。 また、ローディングアイコンの見せ方もきちんとデザインされていました。 Storehouseは Apple Design Award 2014 にも選ばれているアプリ でもあります。    3. Nat Geo View National Geographicが新しくリリースしたダイジェストアプリです。 曜日ごとに厳選されたNational Geographicの高画質な写真や映像を紹介してくれます。 厳選されているということもあり、見入ってしまう作品ばかりで、スクロールしたときの パララックス感や、フォント選び、マージンの取り方などとても参考になります。 また、動画のサムネイルの見せ方もただの静止画ではなく、 キャプチャー画像をアニメーションで見せ、再生しなくても映像の内容が楽しめる という部分は他のアプリではあまりない手法だと感じました。   4. YPlan 直近にある楽しそうなイベントを紹介してくれるアプリ。気になるイベントがあれば詳細情報を見ることができ、その場でチケットも購入可能。 デザインは 操作系のボタンまでアニメーションを使用 していたり、アクションシートまでもきちんとデザインされていて細かい部分のデザインにもこだわりを感じるアプリでした。 5. Timeline 歴史をたどることでコンテクスト（文脈）がわかるニュースアプリで、さまざまなジャンルのニュースを年表でたどっていけるのが特徴です。 最近目にするカード形式のデザインを採用しているアプリ でもあります。また、ローディングアイコンのアニメーションや、 コンテンツ間の切り替わりなどなめらかで使っていて心地よいと思うアプリ でした。   6. August  音楽、写真、動画、テキスト、などをシェアできるアプリです。 プルダウンで簡単に自分のお気に入りにストックすることができるUIが特徴 です。また、ユーザー画面をスクロールした際に背景画像がただ上に流れて消えるのではなく、奥に沈んでいくようなフェードアウトをしていて少し変わった表現でした。 7. Vurb    コンテキスト型検索エンジンアプリ。検索した情報が、検索エンジンを離れることなく見ることができます。検索カテゴリは、「場所、映画、テレビ、音楽、映像、イベント」などに大きく分かれいて、映画のカテゴリを選択すると、「公開中、近日公開予定、オンラインで観れるものなど条件を絞ることが可能です。映画の詳細画面に入ると、予告編、上映時間、レビューなども見ることができます。 また、 写真を全面に使用しながらカード形式のデザインを取り入れているのが特徴 です。iQONもカード形式のデザインのため、 カードごとでどのように情報が分けられているかなど参考になるアプリ でした。   8. FastCompany   米国ビジネス誌「Fast Company」のコンテンツアプリ。 FastCompanyが提供するwebサイトのコンテンツをすべて閲覧することができます。 コンテンツ間の動きがなめらか で、コンテンツを移動していてもストレスなく見続けられると感じました。またレイアウトでは写真に見出しがかかっていたり、 カテゴリを大胆にデザインして区切っていることなども他のアプリにはあまりみられない点だと感じました。 また、コンテンツの最後にいくと次のコンテンツの見出しと写真があり、 次のコンテンツに遷移したくなる仕掛けがされているデザイン でした。 最後に VASILYデザイナーチームがデザインインスピレーションを受けたアプリまとめ(2015年2月)はいかがでしたでしょうか。 ご紹介したアプリのように iQONのUI、UXデザインをもっとよくしたい！というデザイナーの方々、絶賛募集中です！ ご応募お待ちしております。 https://www.wantedly.com/projects/5485 連絡先：info[at]vasily.jp  

  「iQON AD」 VASILYでは2014年10月から、インフィード型ネイティブ広告「iQON AD」をiQONのiOSとAndroidアプリ、スマートフォンサイトに向けて配信しています。 国内最大級のファッションアプリ「iQON」、 女性向けネイティブ広告「iQON AD」を開始。 「iQON AD」は、iQON内に配置された独自広告ユニットに対して広告を配信できるサービスになります。本プロジェクトでの開発要素は主に以下の3つです。 1. ネイティブアプリ内の広告ユニット(SDK) 2. 広告管理ツール 3. アドサーバー サービスインしてから少し間があいてしまいましたが、広告配信システムについて簡単に紹介したいと思います。 「iQON AD」のシステム構成 広告管理ツールとアドサーバーはともにRubyで書いており、ミドルウェアも含めてすべてAWS上で運用しています。 広告管理ツール 広告の入稿、レポートの閲覧、配信データの生成と配信ログを使った集計などを行います。社内外の限られたユーザーが利用するシステムです。 Ruby2.0 + Rails4.0で書いています。 ツールから入稿される広告データはRDS(MySQL5.6)に貯めて、広告配信に必要な形に変換してRedisへと同期します。アドサーバーからS3に蓄積される各種計測ログを定期的に集計して、これもRDSに貯めます。広告の画像はS3にあげて、CloudFrontから配信しています。 アドサーバー 主に広告配信と各種イベントの計測を担当します。HTTPリクエストに対してJSONを返すWebAPIです。 コアとなるEC2インスタンスではSinatraベースのWebアプリケーションをunicornに載せ、unixドメインソケットでnginxとつないでいます。広告データはRedisから取得し、各種計測イベントは同じインスタンス内にあるfluentdを経由して集約用のfluentdからS3に蓄積。memcachedには消えてもクリティカルにはならないもの（かつ配信には必要なもの）を入れています。アドサーバーでは基本的に静的コンテンツ配信は行っていません。 配信ロジックを最適化しつつ高いスループットを確保することが要件であるため、Railsのような高機能はフレームワークは使わずRuby2.0 + Sinatra1.4で書いています。 アドサーバーの処理性能 ピークタイムでサーバー1台あたり30リクエスト/秒くらいの広告リクエストを受けていて、それを平均30~40msec程度で処理しています。 各種計測イベントなども受け付けるので、それも含めると実際にはもう少し多いリクエストを処理することになります。 広告配信の規模としても(一般的なアドネットワーク等と比べると)それほど大きいわけではないので、今のところ必要十分な性能となっています。 Ruby2.0? 現在のRubyの最新版は2.2なのに2.0を使っている理由はいくつかありますが、時間的制約が主な理由です。 プロジェクトの初期開発期間が非常に限られていたため、既存プロジェクトで運用実績のあるものを使うことでインフラ構築コストや未経験による運用リスクは最小限に抑えつつ、時間の大半をアプリケーション開発に最大限あてることでひと通りの機能を揃えることを優先しました。(VASILYではインフラ構築にはAMI＋Chefを使っています) Rubyのコードについてもあまり凝ったことはせずにわりと愚直に書いてあります。そのため、設計やパフォーマンスにもまだまだ改善の余地はあります。Ruby2.1以後GCまわりの改善によってパフォーマンスを改善できそうですし、今後はRubyバージョンアップも含めて色々と改善を図っていく予定です。何かしら成果があった時にはまた本ブログで紹介したいと思います。 以上、iQONの広告配信システム構築の紹介でした。 VASILYでは、広告配信システム開発だけに限らずエンジニアを募集しています。 https://www.wantedly.com/projects/7595 連絡先：info[at]vasily.jp

  社内にデザイナーが複数人在籍する場合、チーム内でのデザインクオリティの担保やスキルアップはどのように行われていますでしょうか？VASILYでは、デザインレビューや、インプット、セミナー参加など、チームでも個人レベルでも常に積極的に行いながら制作しています。 デザインレビューやインプットの仕方などは、デザイナー間でもよくあがる話題の一つだと思いますが、今回は弊社 デザイナーチームがスキルアップのために実際に行っている効果的な方法を3つ ご紹介したいと思います。 1. デザイナー全員でのデザインレビュー   ■チームとしての課題 スタートアップでは、制作と開発を速いサイクルで回していきながらも、デザインの質と量はどちらも担保していかないといけません。 これまでは、エンジニアへ依頼までの細かい確認と、実装後の確認をデザイナー1~2人や担当者内で進めていましたが、デザイナーが増えたこともあり、クリエイティブのクオリティアップと共通認識やルールの意識合わせは課題としてより重く認識するようになりました。   ■目的と効果 それにより 「週に各自どれだけの量を制作したか確認、そして制作物に対してもう一度見直して改善点を洗い出し、次制作のクオリティアップへつなげる」 ことを目的とした、週に1回30分〜1時間ほどのデザインレビューMTGを現在行っています。 制作物を完全に「見える化」し意識することによって、デザインレビュー開始初期に比べ 制作量は約2倍 となり、プロジェクト全体やチーム間での方向性を確認、修正、改善を行っていけるので、デザイナー全員が 自分のデザインに対して目的と意図をしっかりとプレゼン出来る ようになります。   2. 制作物をPinterestのシークレットボードで管理 ■実現、継続させるために デザイナーとして1番フォーカスすべきである「制作」のためにも、デザインレビューの運用方法は負担なく続けれるようにしたいものです。 「短い時間で確認出来るには一覧性も欲しい、1週間ごとに区切って誰が投稿しているかも確認したい」 を叶える最適な方法は Pinterestのシークレットボードでの管理 でした。 他にも、Slackでレビュー用のチャンネルを作成する、WikiやQiitaへのアップなども検討しましたが、情報が流れてしまい一覧で管理出来ない、編集コストがかかってしまうなどでデメリットが多く、今のところPinterestが一番ストレスなく実践出来ておすすめです。   ■実践方法とメリット 方法は以下の通りでとっても簡単。 1. 共有するPinterestのアカウント を作成し、 週ごとにシークレットボードを作成 2. チームメンバーをボードに招待し、 各自のアカウントで1週間の制作物をアップ 3. デザインレビュー時にプロジェクターで大きく映し出し、全員で確認し 出た意見はコメントに記入 上であげた要件以外でのメリットは、 どの端末でも簡単に実機で確認出来る ことです。 唯一デメリットとしてあげるなら、「1週間ごとにボードを作成して、その度にメンバー招待する」ということがあげられますが、週に一回の1分もかからない作業なので現在5人ほどのチームで運用してますがそこまでの負担はありません。   3. タスク確認とインプットの時間を全員で作る ■緊急では無いが重要なことをする 次から次へと降ってくるタスクの波に溺れてしまい、ついつい人は緊急なことから手を付けてしまいがちになります。 そのためVASILYでは、 週の初めにタスクの優先度を全員で確認 し合い、問題があれば調整してインプットの時間を捻出しています。 日々のインプットがないと引き出しも無くなるので、いいアウトプットに繋がるためにも強制的に時間を全員で作るようにしました。   ■実践方法とメリット 1.  タスクを週末にまとめて、全員での確認は 週始めの始業時間前 に行う 2.  インプットは 週1で担当者を変え 、事前にテーマを決めてメンバーにシェア 3.  時間は2時間ほど確保し、その日のテーマに沿った発見、学んだことを後で 各自Qiita:teamにまとめて共有 する メリットは、まだ人が少ない始業時間前にタスク確認を行うことで、焦ることなくささっと終わることができ、1週間を余裕もって気持ちよくはじめることができます。 また、インプットでは自身が主催者になることでさらに世間のトレンドや情報にアンテナを張り ファシリテーション能力も鍛えれる ようになります。 Qiita:teamにまとめて共有することもポイントです。作品に対しての評価を自分の意見として記録することで、 デザインの善し悪しを判断する習慣 となっていきます。   ■過去に実践して良かったインプット 代官山蔦屋で書籍から取り入れた新しい発見をまとめる 写真展を全員で鑑賞 ツールの勉強会 課題やテーマに合わせて、10分でデザインを探し出し、プレゼンしドット投票で一番よかった人を決める etc... 今後はエンジニアの方にも協力を得て、技術的なインプットもしていければと予定していますので、インプットの内容については、今後詳しくブログでまとめていきます。   番外編. UIデザインアドバイザーからのフィードバック 弊社では、 THE GUILD代表の深津貴之（fladdict）さん をUIデザインアドバイザーとして迎えており 、週1でUI改善や新規機能開発についてのMTGを行っています。 MTGでは、体験や機能を実現するためのUIを導きだすために、たくさんのプロトを作成し、デザイナーだけでなく、エンジニアや、ディレクター、プロデューサーも参加し、全員で確認してデザイン検討しています。 社内の人間だけで開発を進めていると分からなかった気付きや発見はとても貴重で、 社外からのフィードバックを盛り込む ことでよりスキルアップにも繋がります。 ■DesignSprintの実践 最近では、Googleのワークショップで参加した DesignSprint を深津さんとともに社内でも実践し、サービスアイディアを数時間で拡散&収束させ、ペーパープロトまで落とし込んで発表するという勉強会も開きました。 デザイン思考で開発していく文化 を会社に根付かせていくのもデザイン力アップのための大事な要素の一つとなりますので、開発手法も積極的に取り入れていけるようにしましょう。 終わりに 以上、VASILYのデザイナーがスキルアップのためにチーム内で取り入れている方法をご紹介しましたが、いかがでしたでしょうか。 「うちの会社ではこういう方法でデザインレビューしてるよ！」「もっと良いツールあるよ」といった意見などあれば是非情報交換させていただきたいので、オフィスにも気軽に遊びに来てください。 また、今すぐにでもこの環境でデザインスキルアップしたいというデザイナーの方々、 絶 賛募集しておりますのでご応募お待ちしております。 https://www.wantedly.com/projects/5485   連絡先：info[at]vasily.jp  

多くのiOSエンジニアが愛用していたβテスティングサービスのTestFlightですが、2015年2月26日をもってtestflightapp.comが閉鎖になるという 公式アナウンス がありました。 TestFlightを運営するBurstly社がApple社に買収され、現在ではiTunes Connectから TestFlightが利用出来るようになっています。今後は後継となる TestFlight Beta Testing の使用が推奨されていますが、従来のTestFlightと異なる制約が多々あるため、別サービスを検討している方も多いのではないでしょうか。 今回はTestFlightに変わるβテスティングサービスを紹介したいと思います。    TestFlight Beta Testingの問題点 TestFlight Beta Testingには、公式で提供されているからこそのメリットも多々あります。 しかし、多くのプロダクトでネックになるとても重要なことがあります。それは「 iOS 8以上のデバイスでなければTestFlight Beta Testingのアプリを使えない 」ということです。 まだまだiOS 7をサポートしているプロダクトは多いはずです。この理由だけで代替サービスを探そうと思う方は多いと思います。 代替サービスの選定基準 代替サービスに移行するのであれば、より自分たちのプロダクトに適したβテスティングサービスを選定したい気持ちがあります。今回は「 TestFlight Beta Testing 」「 Fabric Beta 」「 DeployGate 」の3つのテスティングサービスを比較してみました。比較の観点は6つあり、50名程度の社内テスターに、アプリケーションのバージョンアップ毎に配信することを想定しています。   ・ iOS7をサポートしているか ・ 導入が容易か ・ テスターの追加が容易か ・ 安価であるか ・ 配信時に手間がかからないか ・ CIとの連動が容易であるか 上記結果だけを見ると「TestFlight Beta Testing」については時期尚早だと感じて頂けると思います。 しかし、メリットが無い訳でもありません。次に各サービスのメリット・デメリット、使用感についてまとめます。 TestFlight Beta Testing ・ https://itunesconnect.apple.com/ 本記事でも何回も登場しているオフィシャルのテスティングサービスです。 【メリット】 ・ Releaseビルドでアプリを確認できる ・ 最大1000人まで外部テスターを招待でき、フィードバックを得ることができる ・ SDKが不要 【デメリット】 ・ iOS 7に対応していない ・ 外部テスターの登録に手間がかかる ・ 内部テスターの権限に融通がきかない ・ 端末のAppleIDと紐づくため、TestFlightアカウントの切り替えが非常に面倒 ・ CIとの連動が簡単ではない Releaseビルドでアプリが確認出来るのは素晴らしいメリットだと思います。 少なくとも開発者数名がテストを行うという意味では積極的に使用するべきだと感じました。 DeployGate ・ https://deploygate.com/ 国産の配信サービスです。元々はAndroidアプリのテスティングサービスでしたが、今ではiOSもサポートされています。mixi社が運営していましたが、2015年2月28日を持ってデプロイゲート社に事業譲渡されます。 【メリット】 ・ 国産なので日本語のドキュメントがしっかりしている ・ 配信だけならSDK不要 ・ CIとの連携もしやすい 【デメリット】 ・ 有料 弊社の場合はAndroidでDeployGateを使用しているため、テスティングサービスの統一や、すでに知見があるというのは大きなメリットです。Androidですでに使っている企業も多いと思うので、料金面が問題無いのであれば選定されるプラットフォームだと思います。 SDKを導入すればテスティング以外にも活用できます。 Fabric Beta ・ https://get.fabric.io/ Crashlytics, Twitter , MoPubが統合されたプラットフォームです。Tiwtter社が運営しています。Crashlyticsがテスト配信機能(Beta)をもっており、Crashlyticsを使っているアプリケーションは導入の手間をかけずにそのまま使えます。 【メリット】 ・ Crashlyticsを使用しているプロダクトであればBetaの導入が楽 ・ ビルドから配信までシームレスであり、グループ機能により配信範囲の選択も楽 ・ APIが公開されており、CI連携も可能 ・ ダッシュボードが見やすい 【デメリット】 ・ Crashlyticsを使用していない場合はSDKの導入が面倒 CrashレポートサービスにCrashlyticsを採用していたため、非常に簡単に「Fabric Beta」を使うことができました。ダッシュボードがとても優れており、テスターのインストール状況など直感的に分かりやすいUIが提供されています。 まとめ 今回は元々Crashlyticsを使っていたこともあり「Fabric Beta」を採用しました。 Crashレポートサービスとしても非常に優秀なので、未導入のサービスはこのタイミングでSDKの導入を検討してはいかがでしょうか。 先日TestFlight Groupsが発表されたりと、βテスティングサービスの選定は時代とプロダクトによって柔軟にしていく必要がありそうです。今回は比較対象に上げませんでしたが、以下のようなサービスもありますのでご紹介します。 HockeyApp http://hockeyapp.net/features/ 昨年Microsoft社が買収しました。 HockeyAppをMicrosoft社の製品に統合する計画らしいですが、引き続きサービスは提供される予定のようです。今後に流れに注目です。 EMLauncherv https://github.com/KLab/emlauncher http://www.klab.com/jp/press/140304.html KLab社が公開しているオープンソースです。 Burstly社が買収された際に、Androidエンジニアが試していることが多かったようです。 終わりに 今回のエントリをみて「こんなサービスもあるよ」「それでも◯◯というメリットがあるから××に乗せ変えた方がオススメ！」といったご意見もあると思います。そんな方、ぜひ情報交換させてください。 ご興味があればVASILYに遊びにきて頂ければと思います。 また、VASILYではエンジニアを募集しておりますので応募お待ちしております。 https://www.wantedly.com/projects/7595 連絡先：info[at]vasily.jp  

  先日 ThoughtWorks社 から最新の技術動向をまとめた Technology Radar の2015年1月版が発表されました。 このTechnology Radarですが毎回、 『技術』 『ツール』 『プラットフォーム』 『言語・フレームワーク』 と4つの領域に分けて紹介しており、絶賛流行中もしくは今後注目されるテクノロジーなどが紹介されています。 今回はそんな 『言語・フレームワーク』 の領域から厳選した11の注目テクノロジーを紹介します。 はじめに 各テクノロジーは 『Adopt』 『Trial』 『Assess』 『Hold』 という4つの階級のどれかに属しており、各階級は以下の意味を持っております。 ・ 【Adopt】 企業での使用が推奨されるレベル ・ 【Trial】 使用する価値はあるが、低リスクのプロジェクトで使用すべきレベル ・ 【Assess】 使用する価値があるか、使用方法やポテンシャルを検証すべきレベル ・ 【Hold】 先行きがわからないので取り扱いには注意すべきレベル 以下、多くの素晴らしいテクノロジーが登場していますが階級の意味はあくまでも参考程度に考えたほうが良さそうです。 Adopt 1. Go language まず最初は言わずと知れた「 Go 」。 VASILYのエンジニアでも個人プロジェクトで使用している人も多く、まさしく今一番流行っているプログラミング言語だと個人的にも感じています。 国内スタートアップでも導入実績が増えており、先日開催された dots. Summit で メルカリ や Gunosy で使用しているという話がありました。   2. Java 8 続いては「 Java 8 」。 ラムダ式 や Stream API など強力な機能追加で話題のJava最新バージョン。 残念ながらAndroid開発に関して現時点ではJava 8を使うことはできませんが、Java 8の新機能は今後Android開発者を含むすべてのJavaプログラマーが必須の知識になってくると思うので今から抑えておくと良いと思います。 ＊現時点のAndroid開発でも「 Retrolambda 」と「 RxJava 」を持ち込めばJava 8っぽく記述することができます   Trial 3. AngularJS Googleとオープンソースコミュニティによって開発されているJavaScriptの有名なフレームワークである「 AngularJS 」。 ちょっと前までは至るところで名前を聞きましたが最近は少し React.js に押され気味だと個人的に感じています。JS界隈はホントに動きが激しい。 少々取り上げるか悩んだのですが、現在 v2.0 が開発中らしいので今後盛り返しにちょっとだけ期待です。 ちなみに弊社開発アプリの iQON において裏の運用ツールの一部に使用しています。   4. Dashing イケてるダッシュボードが簡単に作れるRubyのフレームワーク「 Dashing 」。 この サンプル みたいなダッシュボードが、Ruby, HTML, Sass, CoffeeScriptを少し書くだけで作れてしまいます。 Ruby 1.9以上が入っているマシンで以下の数行を書くだけで始められるので、チーム内でのKPIの共有などに活用してみると面白いと思います。 $ gem install dashing $ dashing new sweet_dashboard_project $ cd sweet_dashboard_project $ bundle $ dashing start   # localhost:3030 にアクセス 5. Django REST Pythonの有名なフレームワークである Django をベースとしているRESTfulなAPIを開発するに適しているフレームワーク「 Django REST framework 」。 昨年末に大きな変更を加えた v3.0 がリリースになりましたが、多くの機能が追加されているため興味がある方は リリースノート を読んでみてください。 PythonでAPI開発を行う場合に候補に入れてみてはいかがでしょうか。   6. Ionic framework HTML5でハイブリッドなモバイルアプリが作れるフレームワーク「 Ionic framework 」。 このフレームワークは Apache Cordove をベースに AngularJS と Sass が標準で使えるように構成されています。 テンプレートが用意されているため、自動でコードが展開されすぐにビルドすることができます。 HTML5でクロスプラットフォームを意識したアプリが作りたい方は導入してみてはいかがでしょうか。   7. Retrofit AndroidとJavaのRESTクライアントライブラリとして有名な「 Retrofit 」。 開発は、Android界隈の神JakeWharton氏が在籍するSquare社。 非常に使い勝手が良いライブラリなので導入している会社はちらほらあるんじゃないかと思います。 ちなみにiQONのAndroid版においては Retrofit は使っていませんが『Otto』や『Butter Knife』などは使っています（この辺はまた別の機会にご紹介します）。   Assess 8. Lotus この1年で突如現れたRubyの最新フレームワーク「 Lotus 」。 Github を見てみると非常に面白いんですが、モジュールがすべて入ったフルスタックなプロジェクトもある一方、フレームワークをモジュールごとに分けたプロジェクトも存在しています。 このコードをある単位で分割が容易に行うことができる点がLotusの特徴になっています。 Sinatraみたいな軽量なアプリを作ることができ、かつRailsみたいなフルスタックなアプリも作ることができる柔軟なフレームワークになっています。   9. React.js 最近話題のFacebook製JavaScriptライブラリ「 React.js 」。 ざっくり言うとMVCでいうViewの部分をコンポーネント化して開発できると言ったUI周りに特化したライブラリになります。 この1年で急に盛り上がってきたと感じているんですが Facebook, Instagram はもちろんのこと Netflix, Yahoo, Airbnb, Atlassian などでも使われているそうです。 React.jsの一番の特徴は 仮想なDOM をJavaScript内に持っていることです。これにより従来の実際のDOMをこねくり回してた状態と比べ、必要最低限の更新のみで済むのでパフォーマンス改善に繋がるわけです。 他にもデータを子に渡していくという一方向なデータの流れのためコードも追いやすいという利点があったり、JSXが使用できたりといろんな特徴なあるライブラリです。   10. Rust Mozillaによって開発中のプログラミング言語「 Rust 」。 1月に 1.0.0 Alpha がリリースされ、来週には beta 1 がリリース予定になってたりと、そろそろ正式版がリリースされそうなこのタイミング。せっかくなのでRust触ってみてはいかがでしょうか。 Rust本体と、Rustのパッケージマネージャである Cargo を入れて、 このイントロダクション に沿って行けばRustの入り口を学ぶことができます。 言語としては、純粋関数型、手続き型、オブジェクト指向をサポートしている高機能な言語になっています。   11. Swift 昨年、突如として現れたiOS、OS Xのための新言語「 Swift 」。 つい先日も最新バージョンである Swift 1.2 が 発表 され盛り上がりを見せていますが、iPhoneアプリの開発者は今後絶対に抑えておかないといけない言語であることは間違いないです。 2つ前のエントリー でも紹介しましたが、まだ弊社も iQON には投入できていないものの新しいプロジェクトでは既に使い始めております。 以下のエントリーをまだ読まれていない方はぜひとも読んでみてください。 Swiftで会社の受付アプリを作った話とCADisplayLink まとめ 流行中のテクノロジーをいくつか取り上げましたが、最近はホントに流行り廃りが早いため来年にはいくつか消えているんじゃないかと思います（既になくなりつつあるものもありますが）。 そんな中ではありますが自分が好きだと思えるプロダクトを見つけて愛していくのはエンジニア冥利に尽きると思います。 今回いろいろと調べている際に、最近触っていない言語が気がついたらいろいろと進んでいてショックを受けたので定期的にいろんな言語に触れないとダメだと感じました。 VASILYに遊びに来ませんか？ 今回のエントリーに言及したい方、最新テクノロジーが好きな方はぜひ一度VASILYに遊びに来ませんか？ info[at]vasily.jp や @yoichinishimura などで気軽に連絡いただければと思います。 またVASILYではエンジニアを大大大募集しておりますので応募お待ちしております。 https://www.wantedly.com/projects/7595  

  iQONはAppStoreのレビュー4.5, GooglePlayのレビュー4.3と、嬉しいことにユーザーから高い評価を受けています。しかし、実際にユーザーが日々感じているアプリの良い点だったり不満点などの本音の部分は、レビューやTwitterなどのユーザーが投稿する文章の中に含まれています。特にサポートにお問い合わせをしてくださったユーザーからいいただくような改善を訴えるメッセージとは違い、Twitterやレビューに投稿している文章には現状ユーザーが感じている改善してほしい点やバグ等が、より意識せずに書かれている可能性が高いと考えられます。そのテキストの内容を解析できれば、開発者が認知している問題の中でもより多くのユーザーが改善してほしいと感じている点であったり、我々開発者が気づけていなかったバグの発見等が可能になると考えられます。 そこで今回、「評判分析はじめの一歩」と題して、iQONについて書かれている文章の評判分析を実験的におこなってみましたので、その内容と結果を紹介したいと思います。 評判分析とは？   評判分析とは様々なテキスト情報をテキストマイニングや機械学習の技術を用いて、肯定的な評価をしている記述と否定的な評価をしている記述に分類したり、実際にそのテキストを書いている人がどのような事を考えて記述しているか分析し、理解する事を言います。 ブログやSNSの発展や、AmazonなどのECサイトのレビュー機能が充実した現在、評判分析はユーザーの生の声を把握する事ができると期待されているため、研究分野でも盛り上がりを見せています。 実験概要 対象データ ・書かれている内容の精査等にコストをかけないため。 ・すでに評価の点数が振られている点。 評判分析とは様々なテキスト情報をテキストマイニングや機械学習の技術を用いて、肯定的な評価をしている記述と否定的な評価をしている記述などに分類したり、実際にそのテキストを書いている人がどのような事を考えて記述しているか分析し、理解する事を言います。 ブログやSNSの発展や、AmazonなどのECサイトのレビュー機能が充実した現在、評判分析はユーザーの生の声を把握する事ができると期待されているため、研究分野でも盛り上がりを見せています。 mattlawer/appstat の様なコマンドラインからアプリのapp_idを指定してレビューを取得する便利なサービスもあるのですが、今回は200件以上を取得したかったので、AppleのAPIのレスポンスをスクレイピングする形で取得しました。 評判分析ツール 「独立行政法人情報通信研究機構 旧知識処理グループ 情報信頼性プロジェクト」で作られているツールを使用して分析を行いました。(詳細はこちら :  http://alaginrc.nict.go.jp/opinion/ ) こちらは1行につき1文が書かれたテキストファイルを入力すると、① その評価情報を表す表現の抽出② その評価情報の意味的な分類③ ポジティブ / ネガティブ の様なその文章が表す「評価」に関する情報を抽出してくれるスクリプト群です。 以下のものが動く環境で、こちらのツールを使用する事ができます。 ・CRF++（Version 0.54 で動作確認） ・iconv (Version 2.5で動作確認) ・gawk（Version 3.1.6 および 4.0.0で動作確認。3.1.5ではエラーが発生します） ・gcc（Version 4.1.2で動作確認） ・perl（Version 5.8.8 および 5.10.1で動作確認） ・JUMAN（Version 6.0 および 6.01で動作確認。Version 7.0には対応していません。） ・KNP（Version 3.01 で動作確認。Version 4.0には対応していません。） 分析結果として表示される、評価タイプの種類と各タイプが持ちうる極性は以下の表の様になります。（+はポジティブ、-はネガティブを表します） 実験内容 ・スクレイピングで取得したレビュー300件を取得 ・アプリのバージョン × レビューの点数 ごとにファイルを分割 ・レビューの点数ごと/バージョン別に評価分析の結果をまとめる 取得した文章は一つのレビューの中で肯定的な意見と否定的な意見を混ぜて記載しているものが存在する理由から、分析スクリプトに流してもどのような意見を述べているか判定できない可能性が高いため、文ごとに区切って分析を行いました。 実験結果 全体の評価内容数 感情+        : 6 感情-         : 0 批評+        : 200 批評-         : 77 メリット+ : 150 メリット-  : 56 採否+         : 8 採否-          : 0 出来事+     : 0 出来事-      : 0 当為           : 28 要望           : 0 レビューという事もあり、「批評+-」「メリット+-」に関する意見が多い結果となりました。また、「当為」が多くレビューに書かれている事からアプリに何を求めているかを知る事ができそうです。 レビュー点数ごとの評価内容 レビュー5のコメント内で 評価内容 レビュー5のユーザーのコメントとしてはポジティブな意見が多く、特に ・コーデを作ることの楽しさ / 可愛さ ・買い物に便利 ・探していたものが見つかる 等の意見を多くいただきました。 レビュー1のコメント内で 評価内容 レビュー1をいただいたユーザーのコメントにはやはりマイナスな意見が多く存在しています。今回試してみたツールの結果のままでは、マイナスな意見に関してもいくつかプラスの意見として判定されてしまっているモノがありました。 大きく分けると バグ報告系 と 改善要望系 の2種類に分けられます。こちらが認知して今後改善を進めて行くバグや機能改修についても多くの意見をいただいていますが、「機能改善をする事自体に対する不満のご意見」がある事もわかりました。 最新バージョンのレビューでマイナス評価のもの 一番直近のレビューの中でマイナスの評価になったものとしては上記のお知らせに関してですが、お知らせを消す仕組みは現在のアプリにも実装されているので、そちらがユーザーにきちんと伝わっていない事がわかります。   結果からの考察と今後の話 今回は特に分析に関してカスタマイズ等をしていないので、評判分析の精度を上げる事には言及していませんが、ユーザーが投稿している文書を解析する事で ・ ユーザーが何に喜んでいるかがわかる ・ ユーザーが何に不満を感じているかがわかる 普段見逃してしまっているレビューの中にあるユーザーの意思をつかんでサービスに落とし込む事は確実にメリットがあります。 他にも、私たち開発者が気づけていないバグについて把握ができ、ユーザーがどこの機能を楽しんで、自分たちのアプリを使ってくれているか、自分たちのアプリの強みを知る事にもつながります。 今後進めたいこと 辞書/分析アルゴリズムの最適化 今回は「評判分析導入のはじめの一歩」という事で、分析ツールに特に学習データを与えて学習させたり、辞書をアプリをテキストマイニングするのに最適化するようなことはせず、一般的な評判分析用の辞書を使っています。 そのため、プラス/マイナスの評価の部分などでおかしいものが多々ありました。 ・分析がおかしい例 このように人間がみれば一発でマイナスの感情な意見でも、プラスな評価に判定されてしまっている解析結果が多々あります。今後はアプリの批評に関する言葉を学習させて辞書に追加していくなどして、より精度を上げた評判分析ができれば、アプリの改善等にプラスになるので進めて行きたいと考えています。 冒頭でもテキストマイニングを用いた評判分析の分野は研究で盛り上がっていると記載しましたが、調べている中で次に試せそうな面白い研究があったのでいくつかありました。ぜひ参考にしてみてください。 レビューの語の重みを考慮したテキストマイニングによるゲームソフトの評判分析   構文片を用いた意見・評判情報抽出手法 ツールによるビジュアライズ   今回はローカルのバッチを単発で回して処理をし、テキストファイルをアウトプットとしていました。今後は ・定期的に最新のレビューの分析結果を更新 ・ ツールでエンジニア以外も見れるように ・各アプリのバージョンごとでレビューにどのような変化が現れているかを見える化。 ・ レビューだけで無くTwitterなどに投稿されている文章も解析する ・プラス/マイナスそれぞれの評価の中で頻出な単語を形態素解析で分解しツールで見れるようにし、ユーザーが何かしらの媒体にポストしている内容でホットなワードは何かを見える化 等を進める事で、日々ユーザーに向けた改善をとれるような体制を作りたいと考えています。   最後に 今回はレビューに関する分析の実験内容をあげましたが、レビューやTwitter以外にも弊社アプリには様々なテキストデータや画像データがあり、ファッションに関するデータという意味では日本最大級のデータがたまっています。VASILYでは現在、これらのデータを使って今迄にない新しい価値を世の中に生み出して行きたいというエンジニアを大募集しています！ぜひ一緒にテクノロジーの力でファッション業界にインパクトを与えてきましょう！ 募集要項 連絡先：info[at]vasily.jp

iQONのiOSアプリはまだ全てObjective-Cで記述されています。 Swiftへの移行については「たいしてパフォーマンスが上がるわけでもないし…」と思って渋っていました。 そんな中、オフィスの移転をきっかけに来客の受付システムをiPadアプリで作ることになりました。 スクラッチでアプリを作るのならSwiftで、ということでSwiftで作りました。 今回は、受付システムの社員を呼び出すデータ通信と、トップページの時計に使ったCADisplayLink実装を紹介します。 完成品 www.youtube.com 呼び出したい社員を選択すると、twilioから各個人の携帯電話に自動音声の電話がかかってきます。 電話呼び出しと同時にSlackにも通知が飛ぶようになっています。 実装 データの流れは下記のようになっています。 アプリからはherokuのAPIをリクエストするだけなので、エラーハンドリングも簡単に済みました。 データ通信 iPadから呼び出したい社員を選択すると、アプリからHerokuのAPIにリクエスト HerokuのAPIがSlackとtwilioにリクエスト 社員のケータイに電話(自動音声)とSlackの通知が飛びます アプリの実装 ネイティブ側では下記のようなことをやっています。 ・ Swift製通信ライブラリのAlamofireを使用 ・ CAGradientLayerでiPhoneのロック解除のようなシマーアニメーションを実装 ・ 時計のアニメーションをCADisplayLinkを使って正確に描画 ・ UICollectionViewFlowLayoutをオーバーライドして、セル追加アニメーションを実装 ・ 呼び出しリクエスト中にAudioToolbox.frameworkで効果音を無限ループさせる ・ 通信中の波形アニメーションにCADisplayLinkを使ってアニメーション ・ アプリアイコンは基本的に見せないので、identiconでデザイン工数ゼロ その中の一つ、今回はCADisplayLinkの実装を紹介します。 時計のアニメーションとCADisplayLink アナログ時計のような無限に動き続けるアニメーションを実装するとき、NSTimerやdispatch_afterを使って0.01秒ごとに位置を修正する処理を実行するような実装が考えられます。 受付システムの時計のアニメーションの実装には、CADisplayLinkを使用しています。 CADisplayLinkは画面のリフレッシュレートと同期して描画させるタイマーオブジェクトです。 vs NSTimer NSTimerを使ったり、dispatch_afterをループしても同じような処理を実装できます。 例えば、NSTimerのインターバルを1秒に設定して、その処理の実行時間が1.5秒だった場合、処理実行中は次のタイマー処理がスキップされ、処理が実行されるのは2秒間隔になってしまいます。(いわゆるフレームスキップ) これはCADisplayLinkでも同じことです。CADisplayLinkの場合でもスキップはありますが、あくまでも呼び出されるタイミングは画面の更新に同期するのでアニメーションを使うには効率が良いのです。 CADisplayLinkの実装 CADisplayLinkオブジェクトを生成時にターゲットとメソッド名を登録します。 生成したCADisplayLinkオブジェクトをNSRunLoopのメインループに追加すると、画面描画のリフレッシュごとに登録したメソッドが呼ばれます。 let displayLink = CADisplayLink(target : self , selector : Selector ( "update:" )) displayLink.addToRunLoop(NSRunLoop.currentRunLoop(), forMode : NSRunLoopCommonModes ) 円を描く実装 実装の一部を一つのViewControllerにまとめました。 GitHubにサンプルプロジェクト を置いてあるので動かしてみてください。 こんなアニメーションが動きます。 import UIKit class ViewController : UIViewController { private let secondLayer = CAShapeLayer() override func viewDidLoad () { super .viewDidLoad() // 円のレイヤー let frame = view.frame let path = UIBezierPath() path.addArcWithCenter( CGPointMake(CGRectGetMidX(frame), CGRectGetMidY(frame)), radius : frame.width / 2.0 - 20.0 , startAngle : CGFloat ( - M_PI_2), endAngle : CGFloat (M_PI + M_PI_2), clockwise : true ) secondLayer.path = path.CGPath secondLayer.strokeColor = UIColor.blackColor().CGColor secondLayer.fillColor = UIColor.clearColor().CGColor secondLayer.speed = 0.0 // ※1 view.layer.addSublayer(secondLayer) // 円を描くアニメーション let animation = CABasicAnimation(keyPath : "strokeEnd" ) animation.fromValue = 0.0 animation.toValue = 1.0 animation.duration = 60.0 secondLayer.addAnimation(animation, forKey : "strokeCircle" ) // CADisplayLink設定 let displayLink = CADisplayLink(target: self, selector: Selector("update:")) displayLink.frameInterval = 1.0 // ※2 displayLink.addToRunLoop(NSRunLoop.currentRunLoop(), forMode : NSRunLoopCommonModes ) } func update (displayLink : CADisplayLink ) { // timeOffsetに現在時刻の秒数を設 let time = NSDate().timeIntervalSince1970 let seconds = floor(time) % 60 let milliseconds = time - floor(time) secondLayer.timeOffset = seconds + milliseconds // ※3 } } secondLayer.speed = 0.0 CALayer のspeedを0にして、自動でアニメーションが動かないようにする displayLink.frameInterval = 1.0 1フレームごとに処理を実行する secondLayer.timeOffset = seconds + milliseconds アニメーションの進捗具合を設定する CALayerの speed = 0.0 の状態で、 timeOffset を操作しているので、円が一周しても、また最初から描画が始まって無限に動き続けます。 Swiftで書いてみて思ったこと メリット コード量が減る 　　 .h/.m → .swift 一つになります 　　 型推論 Objective-Cでの不便なことが改善 　　 文字列の扱い、Switch、enum Optional Value (?, !) 　 ビルドせずに静的解析でバグに気付くことができます iOSエンジニアに以外の可読性向上 　 Objective-Cの独特な記法がなくなって、iOSエンジニア以外でもなんとなく理解できるぐらい読みやすくなりました これがきっかけでAndroidエンジニアがplaygroundを触るようになりました 普段アプリをObjective-Cで作っている人には、たいして難しくない (簡単というわけでもないですが) 何より書いていて楽しい デメリット Xcodeでメソッドの定義に飛ぶショートカット(Cmd+Ctrl+J)があまり効かない 　 optionキーを押しながら、コードをクリックして回避しています ライブラリの利用が面倒 　　 Alamofireをgitのsubmoduleを使ってインストールしましたがかなり面倒でした 　　 CocoaPodsでSwiftライブラリが扱えるようになるのは、0.36以降の予定です 　　　 正式リリースが待たれます メリットの方が大きいと思ったのでiQONのコードも新しいものからSwiftで書いていこうと思います。

  みなさんはAndroidアプリのリリース作業を自動化していますか？ 2014年GooglePlayベストアプリを受賞した弊社のファッションアプリ「iQON」では、リリース作業をCircleCIとDeployGateで自動化しています。今回、どのように自動化したのかを、昨年11月からVASILYで働き始めた堀江( @Horie1024 )がご紹介しようと思います。 概要 iQONの開発フローは、PullRequestベースで行われており、開発が完了したコードをreleaseブランチに随時PullRequestを送りながら開発を進めています。 releaseブランチを作成 releaseブランチにPullRequest 問題が無ければPullRequestをマージ 1~3を繰り返す そして、リリース作業は以下のような手順で行っていました。 releaseブランチをmasterブランチへPullRequest PullRequestをマージ masterブランチからAPKを作成 メールでAPKを社内配布 最終確認 GooglePlayにアップロード リリース完了  作業手順としては難しくないのですが、頻繁にあるリリースの度に作業が発生するのでとても面倒でした。 実現したいこと 今回、自動化することで以下の2項目を実現したいと思います。 APK作成の自動化 社内への配布の自動化 どう実現するか サンプルプロジェクト 解説用にサンプルプロジェクトを用意しました。 https://github.com/horie1024/CircleCISample 全体の流れ GitHubへ差分をPush CircleCIがビルドを開始 Slackへビルドの成否を通知 DeployGateへAPKをアップロード 検証端末にDeployGateアプリ経由でAPKを配信 APKをインストール APK作成の自動化 コマンドでのAPK作成 AndroidStudioでのプロジェクトのビルド iQONの開発には、AndroidStudioを使用しています。AndroidStudioでは、IDEとビルドシステムが疎結合になっているため、コマンドでのビルドが容易に行えます。 ビルドシステムには、Gradleが使われており、Android Gradle Pluginを使用してAndroidプロジェクトのビルドを行います。Gradleについてのより詳しい情報は、 Gradle 日本語ドキュメント 、Android Gradle Pluginについては、 Gradle Plugin User Guide をご覧ください。 ビルドスクリプト AndroidStudioでプロジェクトを新規作成すると、以下の2つのbuild.gradleがあります。 Project直下のbuild.gradle app module内のbuild.gradle app module内のbuild.gradleにAndroidプロジェクトをビルドするための設定が含まれています。 assembleタスク 新規作成したAndroidStudioでプロジェクトには、gradlewという実行形式ファイルが含まれており、gradlewを使いGradleのビルドを実行することが推奨されています。 gradlewでビルドを実行する場合、Gradleが自動でダウンロードされ、それを使用してビルドが実行されます。より詳しい解説は こちら をご覧ください。 Gradleによるビルドは、プロジェクト単位で一つ以上のタスクで構成されており、プロジェクトが実行可能なタスクの一覧は、tasksで表示できます。 $ ./gradlew tasks タスク一覧の中に、Build tasksがあり、APKを作成するには、assembleタスクを実行します。 Build tasks ----------- assemble - Assembles all variants of all applications and secondary packages. assembleDebug - Assembles all Debug builds assembleDebugTest - Assembles the Test build for the Debug build assembleRelease - Assembles all Release builds build - Assembles and tests this project. buildDependents - Assembles and tests this project and all projects that depend on it. buildNeeded - Assembles and tests this project and all projects it depends on. clean - Deletes the build directory. Androidプロジェクトは、デフォルトでdebug APKとrelease APKの2種類の出力を持っていて、assembleタスクを実行すると両方を出力します。出力を分割するには、 assembleDebug 、 assembleRelease タスクを利用します。今回は、GooglePlayへアップロードできる状態でAPKを作成したいので、assembleReleaseタスクでAPKを作成します。 ターミナルからのAPK作成 実際にターミナルからassembleReleaseタスクを実行すると、app/build/outputs/apk以下にAPKが出力されるのが確認できます。このassembleReleaseタスクを自動的に実行することで、APKの作成を自動化します。 $ ./gradlew assembleRelease 署名の設定 サンプルプロジェクトでは、設定していませんが、本来であればassembleReleaseでAPKを作成する場合には署名を付けます。Releaseビルドで署名を付けるには、app module内のbuild.gradleのコードを以下のようにします。詳細は こちら をご覧ください。 リリース作業手順の確認 リリース作業の手順を確認し、自動化する箇所を洗い出します。 releaseブランチをmasterブランチへPullRequest PullRequestをマージ masterブランチからAPKを作成 メールでAPKを社内配布 最終確認 GooglePlayにアップロード リリース完了 目的はAPK作成の自動化ですので、1~3の手順に注目すると、 「PullRequestのマージによってmasterブランチに変更が生じたらAPKを作成する」 とまとめられます。これを CircleCI を利用して自動化します。 CircleCI CiecleCIのようなCI as a Serviceでは、GitHubとの連携が前提になっているので、GitHubに差分がPushされたのをトリガーに、任意のコマンドを実行するといったタスクを簡単に定義できます。実際にCircleCIにどのような挙動をさせるかの設定は、 circle.yml という設定ファイルに書き、CI対象のリポジトリに設置します。 circle.yml circle.ymlの構造は6つのセクションに分かれており、上から順に実行されます。また、これらのセクション全てについて設定を書く必要はありません。 machine  : VMの設定の調整 checkout  : gitリポジトリからのclone dependencies  : ビルドの依存関係の解決 database  : テストのためのdatabaseの準備 test  : テストの実行 deployment  : デプロイの実行 各セクションは、bashコマンドのリストを持て、実行したいbashコマンドを指定していきます。もし特にコマンドを指定しない場合、CircleCIがリポジトリのコードから推測したコマンドが実行されます。コマンド実行時のオプションとして、以下3種類を選択できます。 pre  : CircleCIが推測したコマンドより前に実行 override  : CircleCIが推測したコマンドを独自に定義したコマンドで上書き実行 past  : CircleCIが推測したコマンドより後に実行 これら6つのセクションと3種類のオプションを覚えておけば、circle.ymlは問題なく書けると思います。より詳しい解説は、 Configuring CircleCI をご覧ください。 次に、実際にAndroidプロジェクトをビルドするcircle.ymlを書いてみます。 Androidプロジェクトのビルド Test Android applications を参考に書いていきます。 checkout セクションと database セクションについては、必要が無いので設定を書きません。 ▪︎VMの設定 ビルドを実行するには、 ANDROID_HOME の定義が必要になるため、circle.ymlのmachineセクションで定義します。environmentセクションで環境変数を定義でき、VMの /usr/local/android-sdk-linux にAndroid SDKが用意されてるので、そのPathを指定します。また、Javaのバージョンをopenjdk7に指定します。 machine: java: version: openjdk7 environment: ANDROID_HOME: /usr/local/android-sdk-linux ▪︎sdkのアップデート VMに用意されているAndroid SDKは初期状態のため、必要に応じてアップデートします。例えば、CI対象Androidプロジェクトのbuild.gradleの設定が、以下のようになっていた場合 android { compileSdkVersion 21 buildToolsVersion "21.1.2" } circle.ymlにSDK 21とBuild-tools 21.1.2をインストールするよう追記します。overrideとしてるのは、CircleCIが推測して実行する、gradle dependenciesによってビルドが失敗するためです。 machine: java: version: openjdk7 environment: ANDROID_HOME: /usr/local/android-sdk-linux dependencies: override: - echo y | android update sdk --no-ui --filter "android-21,build-tools-21.1.2" サポートライブラリや、GooglePlayServicesライブラリを使用する場合、filterに以下のidを追加します。 "extra-google-m2repository,extra-android-m2repository" また、filterに指定できるidは、以下のコマンドで確認できます。 $ android list sdk --all --extended ▪︎testセクション testセクションは、必ず実行されてしまうため、overrideでダミーの処理を行うようにします。 machine: java: version: openjdk7 environment: ANDROID_HOME: /usr/local/android-sdk-linux dependencies: override: - echo y | android update sdk --no-ui --filter "android-21,build-tools-21.1.2" test: override: - echo "Nothing to do here" Robolectric Gradle Plugin を導入している場合、testセクションでテストを実行します。 test: override: - ./gradlew test ▪︎APKの作成 deploymentセクションでAPKを作成します。deploymentセクションは、複数のサブセクションを持てます。サブセクションは、branchセクションを持ち、差分が生じたブランチが、指定したbranchにマッチした場合に、commandsを実行します。より詳しい解説は、 こちら を参照してください。 machine: java: version: openjdk7 environment: ANDROID_HOME: /usr/local/android-sdk-linux dependencies: override: - echo y | android update sdk --no-ui --filter "android-21,build-tools-21.1.2" test: override: - echo "Nothing to do here" deployment: master: branch: master commands: - ./gradlew assembleRelease ▪︎ビルドできるか試す CircleCIで実際にAndroidプロジェクトをビルド出来るか確認します。 CircleCIにログイン・サインアップ 　 GitHubのアカウントでログインもしくはサインアップします。 Add Projectsをクリック 　 左側のメニューのAdd Projectsをクリックします。 CIの対象とするプロジェクトの選択 　 1でアカウントを選択し、2でCIの対象とするプロジェクトを選択します。 初回ビルドの実行 　 プロジェクトを選択すると初回のビルドがスタートします。初回ビルドでは、circle.ymlが不正だったためビルドが失敗しました。 masterブランチに変更をPush masterブランチでcircle.ymlを修正し、再度Pushするとビルドがスタートします。circle.ymlが正しく修正されたため、無事ビルドが成功しました。 成果物 Androidプロジェクトがビルドでき、APKを作成できました。次にAPKをGooglePlayにアップロードできるよう、作成したAPKをダウンロードできるようにします。 CircleCIでは、ビルドを実行した結果発生する成果物は、 Build artifacts としてビルド毎にダウンロードできます。Build artifactsとしてダウンロードするには、ビルド成果物を保存する必要があります。 成果物を保存するには、generalセクションのartifactsセクションに成果物のパスを指定します。generalセクションは、6つのセクションとは別に、特定のセクションに属さない、ビルド全体に関する設定を書くことができるセクションです。 general: artifacts: - "app/build/outputs/apk/app-release-unsigned.apk" machine: java: version: openjdk7 environment: ANDROID_HOME: /usr/local/android-sdk-linux dependencies: override: - echo y | android update sdk --no-ui --filter "android-21,build-tools-21.1.2" test: override: - echo "Nothing to do here" deployment: master: branch: master commands: - ./gradlew assembleRelease masterブランチでのみタスクが実行されるようにする ここまでで、GitHubでPullRequestをマージもしくは変更をPushすることで、CircleCIのタスクが実行されるようになりました。ですが、master以外のブランチへPushした場合でもビルドが実行されてしまいます。そこで、masterブランチへのPushでのみビルドが実行されるようにします。 Specifying branches to build を参考に、circle.ymlに設定を追加します。generalセクションにbranchesを追加することで、masterブランチへのPushでのみビルドが実行されるようになります。 general: branches: only: - master artifacts: - "app/build/outputs/apk/app-release-unsigned.apk" machine: java: version: openjdk7 environment: ANDROID_HOME: /usr/local/android-sdk-linux dependencies: override: - echo y | android update sdk --no-ui --filter "android-21,build-tools-21.1.2" test: override: - echo "Nothing to do here" deployment: master: branch: master commands: - ./gradlew assembleRelease 以下のように、testブランチをPushしても 「Not Run」 となります。 Slack連携 Slackと連携させることで、ビルドの成功・失敗を通知させることができます。 SlackのConfigure IntegrationsからCircleCIを選択 通知したいchannelを選択 channelを選択するとWebhook URLが得られます。 CircleCIのProject SettingsでWebhook URLを登録 Notifications > Chat NotificationsからSlackを選び、Webhook URLを入力後、Saveをクリックします。 OOM問題 自動化してしばらく運用した中で実際に起こった問題なのですが、build-toolsのバージョンを21に上げたタイミングでOut Of Memoryでビルドが頻繁に失敗するようになりました。これは既知の問題のようで、CircleCIのドキュメントにも OOM killer ran として載っています。 Androidプロジェクトで発生した場合の対策ですが、プロジェクトによって原因が異なる可能性があるので確実ではありませんが、Gradleのバージョンを2系に上げることで改善できました。 社内への配布の自動化 DeployGateの利用 社内へのAPKの配布には、 DeployGate を利用します。DeployGateは、APKをアップロードすることで、専用アプリを介して開発中のアプリを簡単に配布できるサービスです。 DeployGateでのアプリの配布方法 DeployGateでのアプリの配布方法は、サインアップ後のチュートリアルがわかりやすく、すぐに理解できました。また、 こちらの資料 も参考になりました。 DeployGate APIの利用 社内への配布を自動化するにあたり、 DeployGate APIのPush API を利用することで、cURLコマンドで簡単にAPKをアップロードできます。 $curl -F "file=@sample.apk" -F "token=YOUR_API_KEY" -F "message=sample" https://deploygate.com/api/users/YOUR_USER_NAME/apps APIキーの取得 APIを利用するには、APIキーが必要になります。APIキーは、DeployGateへ新規登録することで発行されます。新規登録後に、 https://deploygate.com/settings#apiKey にアクセスすることで確認できます。 ターミナルでの実行 Macのターミナルから実行し、DeployGateにアップロードされることを確認します。DeployGateのダッシュボードにアップロードしたアプリが表示されれば成功です。 $ curl -F "file=@PATH_TO_YOUR_APK" -F "token=YOUR_API_KEY" -F "message=sample" https://deploygate.com/api/users/YOUR_USER_NAME/apps CircleCIでのビルドから社内配布までの流れの詳細 実際の配布の流れは、以下の通りです。 CircleCIがAPKを作成 CircleCIがDeployGateへAPIを使いAPKをアップロード DeployGateがDeployGateアプリへ配信 検証端末でDeployGateアプリを起動し、APKをダウンロード・インストール DeployGateからの配信を受けるには、DeployGateアプリをインストールしておく必要があります。 CircleCIとの繋ぎこみ CircleCIからコマンドを実行し、APKをDeployGateへアップロードします。masterへのPushからAPKがDeployGateへアップロードされるまでの流れは、以下のようになるはずです。 masterへ差分をPush CircleCIが検知し、APKを作成 DeployGateへのアップロードを実行 したがって、circle.ymlを以下のように記述します。 general: branches: only: - master artifacts: - "app/build/outputs/apk/app-release-unsigned.apk" machine: java: version: openjdk7 environment: ANDROID_HOME: /usr/local/android-sdk-linux dependencies: override: - echo y | android update sdk --no-ui --filter "android-21,build-tools-21.1.2" test: override: - echo "Nothing to do here" deployment: master: branch: master commands: - ./gradlew assembleRelease - curl -F "file=@app/build/outputs/apk/app-release-unsigned.apk" -F "token=YOUR_API_KEY" -F "message=sample" https://deploygate.com/api/users/YOUR_USER_NAME/apps deploymentのcommandsで、APKを作成とAPKのDeployGateへのアップロードを実行しています。ここで、APIキーが直書きになってしまっているので、CircleCIの環境変数に登録し、それを参照するようにします。 CircleCIの環境変数への登録 Project SettingsのTweaks > Environment variablesから設定します。NameとValueというformがあるので、NameにDEPLOY_GATE_API_KEY、ValueにAPIキーを入力し、Save variableをクリックします。するとDEPLOY_GATE_API_KEYとして環境変数が登録されます。 登録した環境変数を使用するように書き換えます。 general: branches: only: - master artifacts: - "app/build/outputs/apk/app-release-unsigned.apk" machine: java: version: openjdk7 environment: ANDROID_HOME: /usr/local/android-sdk-linux dependencies: override: - echo y | android update sdk --no-ui --filter "android-21,build-tools-21.1.2" test: override: - echo "Nothing to do here" deployment: master: branch: master commands: - ./gradlew assembleRelease - curl -F "file=@app/build/outputs/apk/app-release-unsigned.apk" -F "token=${DEPLOY_GATE_API_KEY}" -F "message=sample" https://deploygate.com/api/users/YOUR_USER_NAME/apps このように、登録した変数は、circle.ymlから参照できます。 コマンドの別ファイルへの切り出し circle.ymlを見やすくするために、コマンドを別ファイルにまとめてしまいます。 ./gradlew assembleRelease curl -F "file=@app/build/outputs/apk/app-release-unsigned.apk" -F "token=${DEPLOY_GATE_API_KEY}" -F "message=sample" https://deploygate.com/api/users/YOUR_USER_NAME/apps その結果、最終的なcircle.ymlは、以下のようになります。 general: branches: only: - master artifacts: - "app/build/outputs/apk/app-release-unsigned.apk" machine: java: version: openjdk7 environment: ANDROID_HOME: /usr/local/android-sdk-linux dependencies: override: - echo y | android update sdk --no-ui --filter "android-21,build-tools-21.1.2" test: override: - echo "Nothing to do here" deployment: master: branch: master commands: - ./deploy.sh 動作確認 うまくいけば、DeployGateアプリにビルドしたAPKが配信されます。 また、ArtifactsからAPKをダウンロードできます。 自動化した結果 APKの作成から社内配布まで自動化することができました。PullRequestのマージが行われるとAPKが配布されるようになり、リリース作業がかなり効率化されました。 自動化前 releaseブランチをmasterブランチへPullRequest PullRequestをマージ masterブランチからAPKを作成 メールでAPKを社内配布 最終確認 GooglePlayにアップロード リリース完了 自動化後 releaseブランチをmasterブランチへPullRequest PullRequestをマージ CircleCIがAPKを生成するタスクを実行 DeployGateを介して社内配布 最終確認 CircleCIからAPKをダウンロード GooglePlayにアップロード 7. リリース完了 まとめ CircleCIとDeployGateを利用して、リリース作業を自動化してみました。昨年11月から実際のリリース作業に組み入れ運用していますが、思っていた以上にストレスが減り、快適に開発を行えるようになりました。チームメンバーからの評判も良く、やってみて良かったと思います。 しかし、まだまだ改善できる点があり、継続して改善していこうと考えています。現在、GooglePlayへのAPKのアップロード自動化を組み込んだ開発フローおよびリリース作業手順をテスト中です(実験した内容は Qiitaに上げました )。また、今回紹介出来なかった内容もありますので、近日中にご紹介できればと思います。 最後に VASILYでは、自動化や新しい技術が大好きエンジニアを大募集しています！少しでもご興味のある方は是非オフィスに遊びにいらしてください！ また、1月28日にSmartNewsさん、Wantedlyさんと ベストアプリ勉強会 という勉強会を開催します。私も会場にいますので、お気軽にお声掛けください！ 募集要項 連絡先：info[at]vasily.jp

twitterで下記のようなコメントがあり、弊社も新卒採用などやっていることから、Matzさんに新卒エンジニアの給料について伺ってみました。   質問 新卒エンジニアの適正給料はこれだとするならいくら位だと思いますか？ざっくり。   Matz 日本ということ考えて…理系大卒で600万くらいかなあ でもねぇ、大卒はだいたい粒ぞろいだと言っているのと同じ。個人差は無いものとしているってことなので、それだとおかしいよね。 ただ、コンピュータサイエンスの学科を出て、プログラミングできるっていう学生が300万とか400万とかしか貰えないと、彼の持ってる技能はあまり評価されてないってことじゃないかなと。特殊技能を持っていると思われてないってことじゃないかな。 プログラミングするのに国家試験はいらないので誰でもなれるって思われてるんだけど、実際はプログラムかける人とかけない人の差ってものすごいあるじゃないですか。 プログラミングを好きで、ものすごい苦労して特殊技能として伸ばしてきた訳だから。かつ、それを仕事で使って会社に貢献するはずなのに、普通に大学出て、プログラミングできません、これから仕事ですから勉強しますって人と同じ扱いをされると、全然評価されてないってことで、どういうことなんだろなって。 スタープレーヤーだと大学卒業してすぐでも1000万超えるくらいじゃないと夢がないんじゃないかなって。 逆に、使えなかったらバッサリ切る。凄い大学出てたとしても。 新卒みんな丸ごと高いっていうのはおかしいけど、スタープレーヤーに対して普通の給料しか出していないと、「俺、普通の人と同じに働いていれば良いのかな」ってなる。できない振りするのは簡単なので。 だいたいプログラマって、野球選手が野球にかけるのと同じくらいの時間かけてるじゃないですか。優秀な人は。 野球もそうなんだけど、頑張った人がみんなプロ野球の選手になれる訳じゃないんだけど、少なくともトップの人は凄い成功して、あの人みたいになりたいっていう憧れの存在って、プログラマーだとあんまりないよね。 経営者の方では凄いエンジニアがいればそのエンジニアの開発能力をお金にかえて欲しいし、エンジニアの方は自分の能力を正当に評価してくれるところに行ってして欲しいし。 VASILYの皆様にも、持ってるテクノロジーをお金に換えるってところは頑張ってほしいよね。   ---------- 新卒の皆さん・採用担当の皆さんは就職活動がヒートアップしてきたと思いますが、是非是非参考にして見てください。 VASILYもテクノロジーをお金に換えるところ、頑張ります。 VASILYでは2016年の新卒採用を行っています。自分こそがスタープレーヤーだと思う方は是非是非ご応募ください！ 2016年度 新卒採用

  質問 RubyKaigi、楽しみにしていますが、これをもっと楽しむためにはどうしたら良いですか？ 参加者として楽しむには勉強しておくといいことなどあれば教えてください、登壇者を事前にネットストーキングすると楽しいとか。 Matz まあそれもいいかも(笑) カンファレンスの内容って、殆どのものってネットを調べればわかる情報なんですよね。 わざわざ会場に行ってっていうのは、スピーカーで話を聞くことよりもむしろネットワーキングっていうか、人と人とが繋がることのために行くんだと思ってるんですよ。 でも、それってあんまり言われないので、多くの人たちってただ行って話を聞いて「ああいい話を聞いた」って帰ってしまうことがかなり多いので、ちょっともったいないなと。 この業界の人はあんまり積極的に知らない人と交流する人ばかりじゃないんだけど。そこはちょっと置いといてですね、人と人のつながるみたいなことを主眼に置いたらいいんじゃないかなと思うんですよ。積極的にスピーカーに話しかけるとか、休憩室で隣に座った人に「あなた何やってんの」みたいに話しかけるとかいうことをすると120%か、まあ200%かもしれないけど、カンファレンスを有効活用できるんじゃないかと思うんですよね。 有料になってるので、せっかく行った分を取り返すためにはどうしたらいいかっていうと、そうやって人と話すっていうのが大事なんじゃないかなと。 質問 RubyKaigiでは、人と話せるチャンスはどこら辺なのでしょうか。 Matz 一番やりやすいのは懇親会ですよね。そこはあまり苦労しなくてもできるので、頑張った方がいいと思うのはコーヒーブレイクが途中にあるじゃないですか。あれをいかに有効活用するのかっていうのが狙い目じゃないかと思うんですよね。 そういった時間は知った人とつい喋ってしまう。VASILYの人とか、元々知ってる人とばかり集まって、「あの話はどうだったね」みたいな話をしがちだけど、それはオフィスに帰ってからもできるから。 そうじゃなくて、色んな人と喋るみたいなのをやるといいかなと。 まあ私にやれと言われても結構辛いんですけどね。性格上(笑) 質問 MatzさんはRubyKaigiで非常に多くの人と話すと思うのですが、どういった話をしている時が楽しいですか？ Matz RubyKaigiの場合は来てる人みんなRubyに関心があるか好きな人なので、そういう意味で言うと誰と話してても楽しいのは楽しいんですね。 あと言うと新しいアイディアの話をするのは結構好きなので、「こんなことやってみたんですけど」みたいな話をするのは楽しいですね。それはいろんなレベルだけど、Rubyそのものに対してどうしたいみたいなアイディアもウェルカムだけど、「Rubyでこんなことやってみました」みたいな話も面白いですよね。特に「今までやったこと」みたいな話ばかりではなくて、新しいこと、「こんなこと試したい」とか「試してるんですけど」みたいな話を聞くのはすごい好きですね。 質問 Matzさんは今年もKeynoteがありますよね。外にも様々なプレゼンをされているんですが、エンジニアとしてのプレゼンのコツって何かありますか？ Matz 心当たりあるのは数ぐらいしかなくて、やっぱり数をこなすと聴衆が何を期待しているのかとかが大体把握できて、だいぶ楽になりましたよね。 あとは、エンジニアなのでテクニカルな話はするんだけど、テクニカルのレベルを上げすぎちゃうと8割9割の人は付いて来れなくなるので、そこは「もっと詳しく知りたい人はあとで来てね」みたいな感じで抑えとくっていうのはエンジニア向きの話としても結構大事な気はしますね。 ジェネリックな話っていうか一般論の方がみんな好きなことが多いみたいで。だから詳細には立ち入らないんだけど「こんなことが今大事なのでこれちょっと頑張ろう」みたいな。いろんなのがあるんだけどここが大事、みたいな戦略的な話をするのは結構重要かなと思います。 あと、大体のことって一次元では決まらないじゃないですか。バトルもののランキングとかとは違って、このことは得意なんだけどこっちは苦手みたいなのは常にあるので、そういうトレードオフを意識した話をするようには心がけています。 一つのアイディアがどこでもオールオッケーみたいなケースってエンジニア的にはほとんどないんですよね。こういう前提条件があればこのアイデアはいいけど、前提条件が成立しないときはまた別のという風なことになるので、こういうトレードオフでこれを選んだんだけど、前提条件が成立しないときはそうでもないよねっていう話はよくしますね。 まあ、フェアでありたいと思ってますね。マーケティングの話とかだと、この技術で何でも解決みたいな、「これさえあればなんでも解決」みたいな話をしがちなんだけど、現実はそうではないのでそこはちゃんと言うようにしてます。   ---------- RubyKaigi 2014は9/18〜19。MatzさんのKeynoteは19日9:30〜です。 盛り上げて、楽しみたいですね！ (弊社VASILYもGold Sponsorとして参加＆Matzさんの衣装コーディネートもしますので、楽しみにしていてくださいませ！)

こんにちは、バックエンドエンジニアのBoBです。 今回は皆様にお知らせがあります。 弊社VASILYと、株式会社ハースト婦人画報社共催で、日本初のファッションをテーマとしたハッカソン 「THE FASHION HACK in TOKYO powered by Hearst Fujingaho & VASILY」 （以下、THE FASHION HACK）を 2014年9月6日(土)~9月7日(日) に開催する事となりました！ 「THE FASHION HACK」は、エンジニアやデザイナーなどのクリエイターが1～3人1組のチームで、与えられた24時間で新たなアイディアのもと、実際に動くプロダクトを開発するハッカソンイベントです。 今回はファッションに普段から興味があるエンジニアの方にとっても、そうでないエンジニアの方にとっても、このハッカソンイベントがいかに魅力的かを伝えたいと思います。 1. ファッション×テクノロジーはまだまだ未開拓 今回のハッカソンイベントのテーマは、「ファッションとITテクノロジーを掛け合わせて、新しいものを作る」です。それ以外に特に縛りはありません。 近年、弊社iQONをはじめ、インターネットのファッションメディアがユーザー数をどんどん増やしたり、ハースト婦人画報社の様なファッション業界の会社がデジタル戦略を加速させたりと、テクノロジーでファッション業界にイノベーションを起こそうという企業が増えています。しかし現状、まだまだ開拓されていない領域です。 また、ウェアラブル端末であったりIoT(Internet of Things)の分野が盛り上がりを見せており、ファッション業界からも大きな注目を浴びています。メガネ専門店「JINS」を運営する株式会社 ジェイアイエヌが発表した、JINS MEMEは記憶に新しいかと思います。これらの分野は今後確実に伸びて行く分野であり、かつファッションとは切っても切り離せない分野となっています。 今回のこのイベントをきっかけに普段気になっている新しいテクノロジーに触れ、このチャレンジングな分野に興味を持ち、イノベーティブなものを形にしてもらえればと思います。   2. 普段はさわれない、国内最大級のファッションアプリ「iQON」のAPIを使った開発ができる ファッションコーディネートアプリ「iQON」は、投稿されたコーディネート数は100万件を超え、掲載されているファッションアイテムも400万件以上と、国内最大級のファッションコンテンツが集まるアプリに成長しています。 そのiQONのAPIを今回のイベント限定で、参加者に公開する予定となっています。 またハースト婦人画報社が所持している、ファッション記事に関するAPIも当日公開される予定となっています。 もちろんその他、ファッションに関わらず様々なAPIを使って開発していただいてかまいません。   ぜひ普段さわれないiQONやその他のAPIを自由に使って開発を楽しんでいただきたいと思います。   3. 通常のハッカソンでは出会えないような人との出会い ハッカソンの醍醐味としては、普段話さない人たちとの新しい出会いがあると思います。 特に今回のハッカソンに関してはエンジニアやデザイナーだけでなく、審査員やスタッフも含め、ファッション業界の方にも参加していただく予定となっております。詳しい審査員の情報は専用サイト（ http://www.thefashionhack.com ）をご覧下さい。   イベント後の懇親会も予定していますので、今ファッション業界ではどのようなテクノロジーに注目しているのか、今後どのようにファッション業界とテクノロジーの関係は変わって行くのかなど、普段なかなか聞けない話を聞く事ができるイベントとなっています。   4. 採用につながる可能性も。。。 私たちVASILYは、テクノロジーで世の中にインパクトを与えたいエンジニアを常に募集しています。 弊社エンジニアも当日会場にいますので、VASILYに興味がある方はぜひぜひ参加して話してみてください。 詳しいイベント概要の確認、ハッカソンへの申し込みは専用サイト（ http://www.thefashionhack.com ）からお願い致します。 皆様からのたくさんのご応募、お待ちしております！     

  VASILYではエンジニアが海外で行われるカンファレンスに参加できる制度があり、毎年iOSアプリのエンジニアが WWDC に、Androidアプリのエンジニアが Google I/O に参加しています。 今年もAndroidアプリのエンジニアである私、 @yoichinishimura が6月25日、26日に行われた Google I/O に参加してきました。 今年のI/Oでは、 Material Design やAndroid関連の多くの発表がありましたが、その中で私が一番に関心を持ったのが Android Wear でした。 半年ほど前に公開されたPreview版のSDKにはさほど興味は湧かなかったのですが、正式なSDKが公開されたのと、会場で参加者に配られた Samsung Gear Live を身につけていたら急に興味が湧いてきました。 今回は Android Wear とはいったいなんであるのか ということをI/Oのセッションや公式ドキュメントで学んだことと、私の考察を混ぜながら紹介したいと思います。 1. Android Wearとは I/Oに行く前は 『 Android Wear とはGoogleが提供するOSを取り入れた時計、つまりスマートウォッチのこと』と勝手に思っていたのですが、どうやらスマートウォッチのことだけじゃないと Wearable computing with Google というセッションで知りました。 セッション内で Google Glass が Android Wear に対応するという発表があったのですが、つまり対応後は Google Glass も Android Wear という扱いになるそうです。 つまり Android Wear とは Androidと通信することができるウェアラブル端末すべて を指すのです。Androidが起こすIoTの時代がやってきたと感じました。 Android Wear イメージ的には以下の画像の下部にあたると思います。 2. 既存アプリのAndroid Wearの使いどころ Android Wear の開発をはじめる方は Googleが出している公式ドキュメント を一読することをオススメします。 Android Wear の一番の基本機能は Context Stream と呼ばれるカードリストを表示させるところです。 「Google Nowに似たもの」とイメージすればわかりやすいと思いますが、1画面に1カードAndroidから送られるNotificationなどの情報を表示します。 デバイスの操作は、スマートフォンと同様にタップやスワイプ、Yes or Noなどの簡単な操作、音声入力などが行えます。 実際に使ってみるとよくわかりますが、スマートフォンに比べて行えることが限りなく少ないですし画面も非常に小さいです。 そのため既存アプリを上手く対応させようと思うとかなり苦労すると思います。 話は戻りますが Wearable computing with Google のセッションで以下の図が出てきました。 Wearableの開発をするにあたっては従来の デザイン・開発・デバッグ(テスト) の工程に加えて UXイテレーション が重要になるそうです。 開発者が意図するUXを実現してもらうため、Webやスマートフォン以上にWearableの開発にはUXに関わる時間を使う必要がありそうです。 iQONでも Android Wear 対応をするには既存機能の中で何の機能を実装するのが最適であるのかを考えてみたのですが、定期的にユーザーにGCMで送っている以下のような情報を Android Wear に最適な形で対応すると効果が高いと考えました。 Likeしているブランドのアイテム追加情報 アイテムが割引になった際のセール情報 Likeしているアイテムが売り切れ間近の在庫情報 常に見たい オトクでタイムリーな情報 を配信するのは Android Wear 冥利に尽きると思いますし、使い方としては間違っていないと思います。 先日 Android Wear 対応するのに必須な Google Play Services のバージョンアップも済ませたので、近日 Android Wear 対応したバージョンを配信する予定です。 3. Android Wear開発のはじめ方 最後に、簡単にはじめられる Android Wear 開発のはじめ方を紹介します。 Hello World!出力 まずは Android Studio をインストール 、もしくは v0.8.0 以上にアップデートしてください（SDKの更新も忘れずに）。 https://developer.android.com/sdk/installing/studio.html New Project を立ち上げて、 Select the form factors your app will run on まで進んで、 Phone and Tablet と Wear にチェック を入れてください。あとはポチポチとNextを押下してプロジェクトを作成してください。 プロジェクトが出来上がると mobile wear と見慣れないディレクトリ構成でプロジェクトが立ち上がります。 mobile の Configuration を選択し Android のスマートフォンの 実機 or エミュレータにビルドを行い、 wear の Configuration を選択し Android Wear の 実機 or エミュレータ にビルドを行うことで、各デバイスに Hello World! を出力することができます。 サンプルコードで学ぶ SDKマネージャーから Android 4.4W のパッケージをインストールすると以下のパスにいろんな利用シーンを想定した17個サンプルのプロジェクトができています。 それをビルドしながら実際に動かし、コードを読み進めていくと Android Wear でどういうことができるのかを効率良く学ぶことができます。 $ /samples/android-20/wearable/ 併せて 公式の開発ドキュメント を読みながら Android Wear から新しく登場したクラスを探ってみると更に理解が深まると思います。 4. まとめ ざっくりと Android Wear について紹介しましたが、実際に手にとって使ってみないと良さがわからないと思うので興味のある方は発売開始したスマートウォッチを手に入れてみてください。 時計や眼鏡は常に身体に身につけているものなので、手に取って操作しないといけなかったスマートフォンでは提供できなかった新しい体験が Android Wear では提供できると思います。 最後の最後に現実の話をしますと Android Wear と連携できるのは Android 4.3 以上の端末のみ です。 2014年7月14日現在、世界全体の25％のユーザーしか対応OSを使っていないですし、iQONに至っては12％のユーザーのみです。そこから Android Wear 端末を購入して使うユーザーがどのくらいいるかを考えるとかなり少ないと思います。 Android Wear 対応を急ぐことはありませんが、前述の通りシンプルそうに見えても効果を最大限に対応するにはかなり難しい印象です。 そのため今からスタートダッシュで開発を進めノウハウをためるのがベストだと思います。iQONも先陣を切ってウェアラブル対応を進めていきます。 iQONを開発しているVASILYでは先陣を切って世界にインパクトを与えたい Androidエンジニア を大募集しております。 【Android】世界で勝ちたいAndroidアプリエンジニア募集 また情報交換なども随時行っていきたいと考えているので勉強会などの開催、参加についても気軽に相談頂ければと思います。 info[at]vasily.jp や @yoichinishimura などで気軽に連絡いただければと思います。

  VASILY新入りエンジニアのEricと申します。 フィラデルフィアから来ました。好きな漫画はHUNTER x HUNTERです。 今回は使える英語コミットコメントを10個紹介します。 Fix, Change, Reviseなど、日本人の方には違いが分かり辛いものも、実際の使い所が分かるようにしてみました。 是非知って、使ってみてください！ 1. Fix 意味:  直す, 修理する 使い方: バグなどが出たためコードを書き直す必要があう場合に使います。何か問題を直して、正確な操作に戻すニュアンスが強いです。 例: 　Fix inequality in LinesComponent 訳:　 LinesComponentにおける不等式を書き直す 2. Revise 意味:  変更する、修正する 使い方: バグは出ていませんが、不十分なところや修理が必要としたところがあって、コードをよりよくする時に使うことが多い。考え直して、改善するというニュアンスを持っています。 例: 　Revise User class variable types 訳:　 Userクラスにおいている変数の種類を修正する 3. Change 意味: 変更、変える 使い方: 前もっていた状態を変えるというニュアンスが強い。ある値を持っていた変数に別の値をつけたり、クラスなどの造りを変更したりする時に良く使います。 例:　 Change var names for consistency 訳:　 一貫性のために変数名を更新する 4. Update 意味: 更新する、新しくする 使い方: 最新の情報などに対応するためにコードやドキュメントを変更する時によく使います。最近変化した別のものにマッチするというニュアンスが入っています。 例: 　Update documentation to show new methods 訳:　 ドキュメントを新しいメソッドを反映するようにアップデートする 5. Upgrade 意味: 更新する、改善する 使い方: プロジェクトなどの部分やライブラリーのバージョンを更新する時によく使います。Updateとの違いは微妙ですが、バージョン番号などが変わる時に使うことが多いです。 例: 　Upgrade to markdown-preview@0.74 訳:　 `markdown-preview`をバージョン0.74に更新する 6. Clean up 意味: 片付ける、奇麗にする 使い方: 分かりにくかったり、無駄があったりしたところを片付けて、分かりやすくする時に使うことが多いです。 例: 　Clean up specs based on feedback. 訳:　 フィードバックに従ってスペックを片付ける 7. Remove 意味: 削除する、取り除く、除去する 使い方: 以前コードに入っていたものを取り除く時に使います。 例: remove decoratorType instance var 　`decoratorType`というインスタンス変数を削除する 8. Revert 意味: 取り消す、元に戻す 使い方: プロジェクトなどを元の状態に戻す時に使います。 例: 　Revert to version 1.0.9 訳:　 バージョン1.09に戻す 9. Add 意味:  追加する、加える 使い方: 今までなかったものを追加する時によく使います。 例: 　Add `has-selection` class to the editor div 訳:　`editor`　div に`has-selection`というクラスを追加する 10. Implement 意味: 実装する 使い方: ある追加したい機能やフィーチャーがあって、実際にコードを書いてプロジェクトに入れる時に使います。 例: 　Implement removeDecorations class 訳:　 `removeDecorations`というクラスを実装する   英語でコミットコメントが書けると、githubなどで世界中のプロジェクトに参加して多くのエンジニアと一緒に仕事ができるので刺激的です。 挑戦してみてください！   VASILY iOSエンジニアによるApple WWDC報告会を開催します！ ・日時：6月27日（金）20:00〜22:00 （20:00〜21:00 Apple WWDC報告会、21:00〜22:00 オフィスで懇親会） ・場所：東京都渋谷区恵比寿3-42-13 1F 　　　　株式会社VASILY（ http://bit.ly/1mQQMDs ） ・参加費：無料 ・定員：15名 ※ご参加は学生、社会人問わず Apple Developer Programs に加入していらっしゃる方のみとさせて頂きます。 ※定員制のため、応募者多数の場合は抽選とさせていただきます。ご招待する方のみ 6/20(金)にメールにてご連絡いたします。 VASILY iOSエンジニアによるApple WWDC報告会のお申し込みは こちら から

VASILY iOSエンジニアの庄司です。 同じくiOSエンジニア荒井とチーム全員(2名)でサンフランシスコで開催中のWWDCに来ています。 今回のKeynoteは既にご存知の通り、「OS X Yosemite」、「iOS 8」、新言語「Swift」など盛りだくさんの内容でした。 SwiftはRubyと似たような記法があり、 Rubyを使っている会社 の一員としてはとっつきやすくていい感じです。 さて、WWDCの開催期間は5日間ありますが、大きく報道されているKeynote以外にも たくさんのセッション が開かれています。 そのセッションの様子は WWDC2014の公式サイト で見ることができます。 Keynoteもセッションも現地に行かずに見れるのに、なぜ高い参加費を払って現地に来るのでしょうか。 今回は「現地に来るべき理由」をいくつか紹介します。 WWDCの現地に来るべき理由 1. Labs WWDCの会場にはAppleのエンジニアが直接技術的な相談に乗ってくれるブースがあります。(基本的に英語。一部日本語のわかるエンジニアもいるそうです) 日本にいるとAppleのエンジニアと話す機会はなかなかありません。英語に自信がなくてもコードでなら会話ができます。 僕達も実際にLabに行ってみました。英語が苦手でも一人ひとりに理解できるまで丁寧に教えてくれて、抱えていた問題が解決しました。   2. Bash WWDC期間中の一通りのセッションが終わった後、会場の隣の公園でWWDC参加者が一同に会するBash(打ち上げ)が開催されます。 去年はここで「こんなに日本人来てたのか」というぐらい、多くの日本人エンジニアと話すことができて、帰国後も交流が続いています。 毎年有名なアーティストが招待されており、企業のお祭の域を超えた盛り上がりを見せます。 3. Stump the Experts 毎年WWDC期間中に開催されるイベントで、ステージ上のAppleエンジニアvs観客のエンジニアのクイズ大会です。 クイズの問題はAppleに関する超マニアックなもの(例: 粉々になったプラスチック片を見せて、これは何年のmacのどのパーツ?)が多く、僕なんかはさっぱり答えがわかりません。 Keynoteと同じ会場で席は半分ほどしか埋まっていませんでしたが、Keynote以上の歓声と熱気がありました。 4. 現地で開催されているイベントに参加 AltConf WWDCのチケットの抽選に外れてしまったエンジニア達が有志で開催しているイベントです。WWDC期間中、会場の近くで開催されています。 僕が見に行った時は、ベルリンから来たエンジニアがXcode Pluginについて語っていました。 当然WWDCのように最新技術については触れられませんが、デザイン関連のセッションやマーケティング関連のセッションもあり、WWDCのチケットを持っていても行ってみる価値はあると思います。 おまけに、無料なのにTシャツまでもらえました。 AppAdviceのパーティー WWDC開催の前日、会場の近くでAppAdviceというアメリカのレビューアプリのメンバーが主催するパーティーに行ってきました。 日本人は僕達だけでしたが、WWDCのジャケットを着たエンジニアがたくさんいたので、積極的に交流してきました。 お互いに自身のアプリを紹介し合い、エンジニア同士貴重な情報交換が出来る場であったと思います。 パーティーの趣旨はよくわかりませんでしたが、iQONの宣伝も忘れずにしてきました。 こういったイベントはこの時期よくやっているようです。 5. 現地の企業に行く 知人の紹介でYahoo! inc.で「Yahoo! News Digest」のPMを担当している方とお知り合いになりました。 WWDCが落ち着いた後、Yahoo! Inc.のオフィスにお邪魔してくる予定です。 6. とにかく話しかける 正直なところ僕は英語が苦手です。英語だと会話のキャッチボールがうまくできませんが、自分からボールを投げ始めることはできます。 セッションに並ぶ行列中に話しかけたり、隣の席に座った人のmacを覗きこんで話しかけたり… この行動のおかげで去年あった外国人と現地で再会することができました。 7. 話しかけられる 写真にあるようにVASILYのメンバーに借りた着物を着て行きましたが、効果抜群でした。 みんなが笑顔でこっちを見てくれるし、多くのエンジニアに声をかけられました。話しかけてくれた人の中には「Oh, Jedi...」とオビ＝ワン・ケノービと勘違いしている人もいました。 チャイナドレスのエンジニアがいたら僕も話しかけたくなるので同じ心理だと思います。 まとめ 5. については、たまたまいい人を紹介していただけたのでラッキーだったとは思いますが、それ以外のことはチケットを購入できれば自分の努力でどうにかなります。 また来年WWDC参加を狙っている方は全力で楽しむために、今回紹介した内容を試してみてはいかがでしょうか？ 惜しくも抽選にもれてしまった方は、現地に行った方から話を聞くと何かしら発見があるかもしれません。 さいごに この記事を読んで来年こそはWWDCに行ってみたいと思ったあなた、一緒にiOSアプリを開発してWWDCに行ってみませんか? (もちろんチケットが取れればの話ですが) WWDC仕込みのメンバーとNo.1のアプリを作るiOSエンジニア募集  

  まつもとゆきひろさんが弊社の技術顧問に就任する事となりました。せっかくなので、「ベンチャーの重要性」「世界での勝ち方」「sierのヤバさ」「モルモン教とエンジニアリング」など、まつもとさんに色々聞きたかった事をぶつけてみました！  vasily officeにて 質問 我々は、小さい会社ながらも技術によって世の中にインパクトを与えようと頑張っています。 他にもそういった会社が増えていますが、思う所など教えてください。 まつもと その逆は大企業とかだけど、関わっている人が多くなればなるほど、辛くなりますよね。 僕はビジネスマンじゃないので、エンジニアが幸せかどうかしか分からないけど、自分で決められないエンジニアは不幸なんですよね。 この技術の方が絶対いいのに、「上司が説得できないから従来のやり方で頑張りましょう」みたいな空気で腐りながらやるのは、エンジニアにとっては不幸なんですよね。 小さなとこだと自分で何をするか決められるじゃないですか。それはエンジニアにとっては幸せなことだと。 あとは、ネットのスピード感を維持するっていうのはむしろ、小さな組織でなければできない。 「大企業があります。ビジネスがあります。大企業がそのシステムが欲しいから発注します。」みたいな構図はもう、なくなっていくかなと。 テクノロジーを担うのは動きの速い小さな組織しかないんじゃないかな、と思いますね。 質問 我々はテクノロジーを足がかりにして世界と戦おうとしています。 rubyは世界進出に成功したプロダクトだと思いますが、その経験を踏まえて成功するのに必要な事は何だと考えますか？ まつもと なんでも人間が相手なので、人気が出るとか広く使われるとかは人が決める。一人一人がサイトだったりサービスだったり、あるいは言語だったりを選ぶ事によって決まるわけですよね。 それを選ぶかどうかっていうのは、好きかどうかとか、便利かどうかで、それって文化に依存する。 rubyの場合はプログラマーのマインドとか、ハッカー文化みたいなものに寄り添って、そこに最適化していて。そこが特定の国に依存してないものだったので、上手く行ったと。 現状、本当に世界規模で何かをやるには、国に依存しない共通な何かの文化を見つけ出して、それに最適化しないと難しいんじゃないかと思いますね。 iqonは成功するために日本の文化・ファッションの文法によりそっているわけですが、これを海外に持っていくためには、この日本への最適化そのものが障害になる可能性が出てきますよね。 あるいは、この日本のファッションという文化ごと世界共通語を目指すといいのかもしれないけど。 質問 エンジニア、プログラマーの幸せって何だと思いますか。 まつもと 満足しているかどうかってことかな。 自分の待遇だったり境遇だったりに対して、満足しているかどうかっていうのは一番大事だと思っていて、プログラマーとして満足なのは何っていうと、 一つは面白いものを作っているかどうか。 テクニカルもエキサイトできるかだし、もちろん収入もそうだし、忙しいかどうかも。時間の使い方だとか。 あとは自由とか裁量。 自分がほんとうに素晴らしい、正しいと思う事を聞いてもらえるか、説得できる余地があるかどうか。 エンジニアが何を言っても駄目だって諦めていると、そこは違うだろうみたいな。 で、最後にそれに繋がるものっていうのは、自分がエンジニアとして、技術を持っている人として、テクノロジーを使ったパワーを持っている人としてリスペクトされているか。 「お前の持っている技術だったら俺のやりたい事ができるかもしれない。一緒にやってくれないか」って言われたら、リスペクトされている気になるじゃないですか。そうするとすごい力が出てくる。 逆に「お前がどう思ってようが関係ない、俺の言った物作れ」っていうのはリスペクトされないわけですよね。 質問 リスペクトされていない状態の人達もいると思いますが、そういう人はどうしたら良いですかね？ まつもと やめる。 すごく我慢する人が多くて、景気がすごく悪いのは続いていて、ここにいないと僕はニートになってしまうかもしれないっていう恐怖感はあると思うんだけど、そのリスペクトしない人に対して奉仕しちゃうと、どんどん立場が下がっていく。 最終的には奴隷になっちゃう。it奴隷に。 それはダメだと思うので、どうするかっていうと、昔からそういう時は反乱を起こす。そういうエンジニアをリスペクトしない連中は見捨てるっていう。 どうせエンジニアがいなけりゃシステム作れないんだから。 そういうのをみんなでやって、技術者を大切にしないと自分の事業は立ちいかないっていう状態に追い込まないと、良くならないと思うんですね。 例えば、金山さんが「ファッション界に変革を起こしたい、itは単なる道具」という態度であればvasilyと共感できなかったと思います。 しかし、実際には金山さんも魂はエンジニアで、「テクノロジーが世の中を変えることができる、我々のフィールドはファッションだ」というテクノロジードリブンな発想だったので、これならお手伝いできるなと思いました。 質問 ちなみに、「こういう会社は気をつけた方が良い」っていう物はありますか？ まつもと 「si」っていう単語が使用されている会社は8割9割ダメ。 siの、お客様の為にシステムを作るっていう構造が、win-winになりにくい。 顧客は出来るだけ安く、出来るだけ良い物を作ってもらいたい。作る方は出来るだけ少ない仕事で出来るだけ沢山お金を貰いたい。一緒の方向を向いていないんですよ。 作る方も最初に作りますって言った仕様を満たす最低ライン出せば良くて、納めてしまえば終わりで、お客様が成功したかなんて関係ないんですよね。 ほとんどの会社はシステムを売ってはいないから間接部門なのでコスト部門なんですよ。 社内でも切れ切れって言われていて、ちょっとでも安くしないとって物なので買い叩かれるのですけど、それだとエンジニアは幸せになりませんよね。 最悪のビジネス構図です。 なので、siはもう見捨てるしかないかなと。 システムインテグレーションっていう業種が壊滅したらもうちょっとマシになるんじゃないかな。 大企業にいて苦しんでいる人には「辞めたらいいんじゃない」って毎回言っているんですけど、やっぱ怖いんですね。フリーランスになるとか小さな会社に行くとかは。 心理的な障壁が大きいんですね。「頑張って大企業に入りました。それを辞められますか」と。 心理的な障壁に甘えて、siみたいな幸せにならない構造を維持していくのはどうかというのはありますね。 質問 まつもとさんはモルモン教の宣教師だったのですが、それがプログラミングやエンジニアリングに与えている影響ってあるのでしょうか？ まつもと 相対化できないので、同じ条件でそういう経験のない私と今の私とは比べられないので、なかなか難しいですが。 大学生の時に2年間宣教師として奉仕したんですけど、人と凄くたくさん話をしたんです。何万人と。 その時割と人間を見たんですね。そういうのが役に立っているかもしれないなと思う時はありますね。 itってテクノロジーなんだけど、最後のファクターは人間なんですよね。 テクノロジー的にはトレードオフを提供できる。このボリュームをこっちにあげるとこうなって、こっちをあげるとこうなってっていうのはできるけど、じゃあ、そのトレードオフのボリュームをこうしますっていうのは人間が決めるんですよ。 絶対的な真理はなくて、100人が100人納得する意見っていうのはないので、テクノロジーを人間に合わせる部分が大事なんですね。 そこは多くの人と話をしたのが役に立っているかもしれないですね。 あとは2人1組で活動する事が多くて、だいたい僕の相棒はアメリカ人とか外人が多かったので、英語を使っていましたね。 今、僕が英語を喋っているのも基礎みたいなのはそこでできたと思いますね。 この2つは影響があったんじゃないかと。 質問 ざっくりとした質問で恐縮ですが、プログラミングの将来ってどうなるのかをお伺いしたいです。 まつもと 近い未来だと、ソフトウェアの規模はどんどん小さくなるんじゃないかな。小さいのをたくさん作るみたいな感じになるんじゃないかと思います。 それは何かというと、フレームワークであるとか、ライブラリであるとかが充実してきて、それを組み合わせるだけで一通りの事ができるという。 その時にrubyみたいな言語ってのはクラスライブラリとかを提供していって、プログラマーはスコアリングの調整やapi取り込めば良いだけみたいになって。 ターンアラウンドタイムがだんだん短くなっていくんじゃないかと思います。 遠い未来だと、コンピュータが人間の言葉を理解して、人間に変わってコンピュータが計算してくれてとか、いい感じにビジュアライズまでして出してくれるとかっていう感じになると思うんですけど。 そうするとプログラミングの楽しみがなくなるんだけど、僕はちょっとおじいさんになってもプログラミングしていて、「おじいちゃんがまた年寄りの趣味やってるよ」とか、「もう何十年前のやり方なんだろうね」っていうのをプログラムやりながら言われてそうな気がします。 今でも現実に普通の人はいろんな事を探すより先にgoogleしますよね。 あれがどんどん自然言語に近づいていって、「何かが知りたい」とかいうと、今でも普通に文章を打ち込む人結構いるんだけど、適当に出てきて用が済んじゃうみたいな。あれがどんどん進んでいくんじゃないかな。 あとはフロントはsiriみたいになって、どんどん自然に。 質問 その仕組みを作る側にも人はいるんですよね。 まつもと もちろん、当面はいますね。 でも、それもどっかから自動化されて。コンピュータの知能が十分高まっていくと、聞いただけで言葉を理解して、持っている情報からそれっぽいのを作り出してくれるような気がしますけどね。 プロプログラマーの仕事は2極化して、アカデミックな最先端のことやるのと、本当に簡単な事をやるのと。 個別のニーズに合わせて、「この業種だからこういう組み合わせをする」というのをやるエンジニアは当面はいると思います。 でもそれは誰でも出来ちゃうんで、何を差別化するかっていうところはキーポイントですね。 まつもとゆきひろ氏を囲んで 以上、当日話した内容のごく一部ですが紹介いたしました。 他にもエンジニア同士で言語や仕事、マネジメントについてなど、踏み込んだ話で盛り上がりました。 vasilyでは、一緒に切磋琢磨できるエンジニアの仲間を探しています。 まつもとさんを迎え、vasilyはエンジニアにとってさらに成長できる環境になりましたので、ご興味ある方は是非是非↓こちらまで！ 世界を変えたいエンジニア募集

VASILYのiOSエンジニアは今年もWWDCへ参加しています。 同時に、WWDCへ参加する世界各国のエンジニアたちとの交流も深めています。 和服で来ています     WordPressのエンジニアと   ものすごい熱気です   iOSエンジニアとしてノウハウや今後の動向を学ぶだけでなく、文化や魂など、色々お土産を持って帰ってくる予定です！    

Androidエンジニアの村田です。チームメンバーが増えてきてますますテストコードの必要性を感じています。 ということでAndroidアプリの開発でユニットテストを導入しました。 挫折しないでユニットテストを始めるための３つのポイントを紹介していきたいと思います。 なぜ始めたか？ まずはじめにそもそもなぜ始めたのかの理由を３つ紹介します。 プロダクトの品質を仕組みとして保ちたかった コードレビューはしてるが、あくまで人の目の確認となり抜け漏れが生じてしまいます。クラスやメソッド単位での品質は仕組みとして担保したいと思いました。 チーム内でクラス、メソッドの仕様についての共通認識を高めたかった そのコードは何を受け取ったらエラーとするのか？テストコードを書けばわかりやすくなると思います。自分のためにもチームメイトのためにもなると思います。 仕様変更によるバグ発生の回避 たくさんの機能をハイスピードで開発、改善、廃止などしていくうちにちょっとしたコードの変更が思わぬバグを生むことがあります。 予めテストが書かれていればコードを微妙に変えても異変にすぐ気がつけると思います。 このように始める理由は結構ありきたりな理由でした。 それでは本題に入っていきます。挫折しないようにユニットテストを始めるための３つのポイントを紹介していきます。 1.現状分析&シンプルな導入 2.自分のコードは完璧じゃないと疑う 3.メリットを明確に納得する 現状分析&シンプルな導入 始めるにあたってアプリケーションのどの部分から始めるかを決めるのは大事です。 どこから始めるかをしっかり絞って優先付けをしていくことで迷わずにユニットテストを導入することができます。 iQONではクラス単位でざっくりどういう役割があるのかを把握することから始めました。 iQONのAndroidアプリのクラス数 Activityクラスの数:73 Fragmentクラスの数:32 Adapterクラスの数:15 View関連の共通クラス数:30 モデルなどのデータ処理系のクラス数:45 iQONの機能のほとんどはバックエンドのAPIサーバ+画像サーバとhttp通信をすることで実現しています。 この処理を担当するのが1番下のデータ処理系のクラス(45クラス)になります。 ユーザから見えにくい処理はユニットテストにうってつけ ViewとかActivityとか表面に見える部分のバグは実機テストするときに人の目でも検知できますが、データ処理系は目視では検出しにくく、本当にその挙動が正しいのか正確に判断できないことがあります。こういった処理はユニットテストでバグを検知するにはうってつけだと思います。 処理の重要度で優先付け データ処理関連はアニメーションなどの表現に関する処理に比べるとシビアなのでまずはテストすべきだと思います。どんなにすごいアニメーションで表現しても肝心の処理がうまく行ってなければ本末転倒です。 導入は簡単に、シンプルなものから始めてまずは文化づくりから ユニットテストを始めるときに、あんまりいろんなことを最初からやってはいけません。気持ちの問題ですが、最初からあれこれやり過ぎて導入、開始までで疲れてしまって挫折してしまうこともあるかと思います。まずは簡単な仕組みから始めてテストをかく習慣、文化を作ります。 実際に導入するテストツールはいろいろ検討しましたが、Javaで書かれたコードをユニットテストするのにもっともメジャーでシンプルなJUnitを採用しました。弊社ではAndroidStudioを使用しているので、実際かなり簡単に始めることが出来ました。 具体的な導入については次回以降のエントリーで紹介していきたいと思います。 という3つの理由からJUnitによるユニットテストを開始しました。 自分のコードは完璧じゃないと疑う ちゃんと動いていると信じていたメソッドも意外とまともに動いてない テストコードを書くとなると容赦ないパラメータをメソッドに投げるわけですが、変な値を投げると意外とうまく動いていないことがあります。 設計を見直す良いチャンス テストコードを書き始めると、「あれ？テスト書きにくいクラスがあるな」と思うことが出てきます。これはテストが書きにくいクラスなのではなく、設計があんまりよくないクラスの場合が多いと思います。ちょっとiQONであった実例を紹介します。 public void setJSON(JSONObject json) { try { if (!json.isNull("category")) { String category = json.getString("category"); if (2 < category.length()) { // 省略(categoryを適当に変更する処理) this.category = category; } else { // 省略(categoryを適当に変更する処理) this.category = category; } } else { // 省略 } // 省略（他のインスタンス変数に対する処理がこのあとも多数続く） } catch (JSONException e) { e.printStackTrace(); } } バックエンドのAPIから返ってきたJSONのレスポンスを上のようなメソッドに渡して、 インスタンス変数の値を設定する処理がありました。 このメソッドは300行近くに達し、とても見通しの良いコードではなかったです。本来ならsetterを実装してそこで値の検証をして、インスタンス変数に値を設定するのがいいと思います。 public void setJSON(JSONObject json) { try { if (!json.isNull("category")) { String category = json.getString("category"); setCategory(category) } else { // 省略 } // 省略（他のインスタンス変数に対する処理がこのあとも多数続く） } catch (JSONException e) { e.printStackTrace(); } } public void setCategory(String category) { try { if (2 < category.length()) { // 省略(categoryを適当に変更する処理) this.category = category; } else { // 省略(categoryを適当に変更する処理) this.category = category; } } catch (JSONException e) { e.printStackTrace(); } } このようすればsetCategoryメソッドでいろんな値を設定してインスタンス変数の変更に関するテストがかけるようになります。 ちょっと設計を改善すれば、テストが書けるようになります。逆にテストを書こうと思ったので設計の見直しができたと思います。（今回の例だともともと処理を切り分けたいと思っていた気持ちがより強くなりました） メリットを明確に なぜテストをやるのか？そのメリットを明確にしてやるべきだと思います。 私自身もテストを書くのに挫折したことがありましたが、挫折する理由の一つとしてメリットを納得できてなかったからだと感じています。 自分なりに納得したポイントをざっくり上げたいと思います。 1. コードの品質があがる 言わずもがな、テストをかけばその分コードの品質は上がります。これは保守するコストを下げるメリットがありますね。 2. テストを意識した、きれいな設計を保てる きれいな設計を保てるということは保守するコストもそれなりに下がっていきます。これもメリットですね。 3. テストが用意されているので思い切った開発ができるようになる テストが用意されているので、ちょっと処理の内容を変えてもテストを流せばおかしいところはすぐに検出できます。 この処理を変えたらあちこちに影響ないだろうか？と開発時に迷う気持ちを抑えられると思います。不安ならテストを流せばいいわけです。 あれこれ影響範囲を調べたりする開発時のコストを下げることもできそうです。これもメリットと言えるでしょう。 4. テストコードが仕様書になる どんな値を受け取って、どんな場合にエラーを返すか。みたいな仕様はテストコードを見れば一目瞭然なので、仕様書の代わりになります。ドキュメントとして細かい仕様をまとめるのも大事ですが、テストコードを代わりにしてみるといろいろ無駄が省けるかもしれません。 まとめ 現状分析&導入はシンプルに 現状のアプリの中でテストを書き始められる箇所がどこか見極める。大掛かりなしくみを最初からやろうとしないで小さなことから始めてみる。最初から飛ばし過ぎると導入の時点で疲弊して続きません。 自分のコードを疑う 自分が書いたコードは完璧じゃないと疑う。テストコードを書いてみて初めて気がつくことはよくあります。 メリットを明確に メリットを明確にして、きちんと納得して始める。 次回は実際の導入の紹介やTravisCIとの連携などを紹介していきたいと思います。 しばらくテスト関連のエントリーが続きますが、楽しみにして頂けたらと思います。 さいごに iQONではエンジニアを募集しています。一緒に世界を目指すAndroidアプリの開発をしませんか？ 【Android】世界で勝ちたいAndroidアプリエンジニア募集 情報交換なども随時していきたいと思いますので勉強会などの開催、参加についても気軽に相談頂ければと思います。

iOSエンジニアの庄司です。 先月2月20日、『【第2回】iQONエンジニアセミナー ～進化し続けるiQONを支えるグロースハック的エンジニアリング手法とは？～』と題して、エンジニアセミナーを開催しました。 会場となった弊社オフィスにたくさんのエンジニアの方々に集まっていただきました。 当日は、弊社エンジニアが『グロースハック』をテーマに各プラットフォームがどのようにiQONのグロースハックに取り組んでいるかを発表しました。 当日の発表資料をSpeaker Deckにアップしたのでぜひ御覧ください。 グロースハックを支えるエンジニアリング CTO 今村 Androidファースト／より早く提供するための開発手法 Androidチーム (西村/村田) グロースハックさせるためのiOS開発手法 -ログ収集編- iOSチーム (荒井/庄司) iQONを支えるバックエンド バックエンドチーム (吉田/大貫) グロースハック的開発 最初の一歩 LT枠 (かとあつ) まとめ グロースハックにフォーカスしての各プラットフォームで発表しましたが、時間の都合上紹介できたのはグロースハックに関して取り組んでいることの一端にすぎません。 この他に取り組んでいることをどんどんこのブログで紹介していきたいと思います。 各資料の最後でも触れていますが、今回のセミナーや発表資料でiQON面白そう！と思っていただけた方をお待ちしております。 日本最大級のファッションサービスiQONをぶっちぎりにするエンジニア募集！

ウェブサービスに限らず、アプリの継続率を上げるためには離脱率や離脱ページの計測は重要です。 離脱率の高いページを知り、改善することでアプリの継続率やコンバージョン率の向上につなげることができます。 特に新規ユーザーの離脱ページを改善すると継続率への影響は大きいでしょう。 今回は、iOSアプリの離脱ページ計測について3点にわけて紹介します。 iOSアプリにおける離脱とは 最前面のUIViewの特定 最前面のViewController (離脱ページ) の特定 iOSアプリにおける離脱とは iOSアプリにける離脱とは、ホームボタンを押したり、かかってきた電話に出たりなど、そのアプリケーションの利用が終了することと同義です。 このタイミングは UIApplicationDelegate の applicationWillResignActive: というデリゲートメソッドで検知できます。 このタイミングで最終的に表示していたページ（＝ViewController）を取得できればよいのですが、アプリケーションの実装によっては同時に複数のViewControllerが存在するため特定が困難です。 ここでは applicationWillResignActive: が呼ばれた時点で最前面にあるViewControllerを離脱ページとして計測すればよいでしょう。 最前面のViewControllerを取得するには、下記の2ステップです。 最前面のUIViewを特定 そのUIViewが属するUIViewControllerを特定 Google Analyticsなんかでもやってることでしょ？ Google Analyticsでも画面ごとの離脱率を計測することができます。 ですが、今回は新規ユーザーについてのみ、どの画面で離脱したかを計測するために実施しました。 最前面のUIViewの特定 最前面のUIViewを取得するには UIWindow から始まるsubviewsツリーの最後のViewを再帰的にたどって行くことで最前面のUIViewが取得できます。 最終的に applicationWillResignActive: で取得するので、UIApplicationDelegateのクラスでメソッドを実装します。 アプリケーションの最前面のUIViewを取得する処理の実装例 @implementation MyAppDelegate - (UIView *)foregroundView { // UIWindowから始まるView階層を再帰的にたどる UIView *foregroundView = self .window; while ( 1 ) { UIView *tmpView = nil ; for (UIView *subview in foregroundView.subviews.reverseObjectEnumerator) { // 非表示のviewは除く if (!subview.hidden && subview.alpha > 0.f ) { tmpView = subview; break ; } } if (tmpView) { foregroundView = tmpView; } else { break ; } } return foregroundView; } @end 最前面のViewController (離脱ページ) の特定 さきほど取得した最前面のUIViewのレスポンダチェーンをたどって行くと、そのUIViewが属するUIViewControllerが取得できます。 UIResponderクラスのカテゴリのメソッドを実装します。 UIViewのレスポンダチェーンから自身が所属するUIViewControllerを取得する処理の実装例 @implementation UIResponder (Addition) - (UIViewController *)belongingViewController { UIResponder *responder = self ; while ( 1 ) { if (!responder) { return nil ; } else if ([responder isKindOfClass:[UIViewController class]]) { return (UIViewController *)responder; } else { responder = responder.nextResponder; } } } @end 最終的に最前面のUIViewControllerを取得して計測する処理は下記のようになります。 最前面のUIViewControllerを取得して計測する処理の実装例 @implementationMyAppDelegate - (UIViewController *)foregroundViewController { // 表示されている最前面のViewControllerを返す UIViewController *vc = self .foregroundView.belongingViewController; if ([vc isKindOfClass:[UINavigationController class]]) { // UINaviagtionControllerの場合はtopViewControllerを返す return ((UINavigationController *)vc).topViewController; } else { return vc; } } - ( void )applicationWillResignActive:(UIApplication *)application { // 会員登録から24時間以内のユーザーのみログを落とす if ([[NSDate date] timeIntervalSinceDate:USER.createTime] <= 60 * 60 * 24 ) { UIViewContrller *vc = self .foregroundViewController; // ロギング処理 } } @end 再帰処理をたくさんやってるけどパフォーマンスは? 計測処理が遅くてアプリケーションの使い勝手が悪くなるような事態は避けなければなりません。 今回は再帰処理を使っていますが、実機で確認してみたところ、1msecかからず返ってきました。 subviewsのツリーとレスポンダチェーンをたどるだけの処理なので、大した負荷はないようです。 まとめ 離脱率を計測するために、アプリケーション終了時に最前面のViewControllerを取得する処理を紹介しました。 レスポンダチェーンをたどることで、UIViewのサブクラスからView自身が所属するViewControllerを取得することもできますが、ViewがViewControllerの存在を意識する必要はないのでおすすめしません。 計測をすることはサービス改善の第一歩です。計測結果を解析してサービス改善に役立ててください。 最後に 今回の記事に物申す！という方はこちらまで↓ 【iOS】Appleも認めたiQONにさらに磨きをかけるエンジニア募集

近年O2O（Online to Offline）が販売促進のマーケティングなど様々な分野で脚光を浴びていますが、O2Oを絡めた機能をアプリで提供するために不可欠な要素として 位置情報サービス があります。 今回はAndroidアプリで位置情報サービスを効率よく使うための2つのTipsと実装例を紹介していきます。 １，『最新の位置情報サービスの罠』を対策しアンインストールを回避 ２，最新機能『Google Play ServicesのLocation API』を使って効率UP Tips1:『最新の位置情報サービスの罠』を対策しアンインストールを回避 Android4.4（KitKat）から位置情報サービスの設定画面が変更されました。大きな変更は以下の2点になります。 高精度・バッテリー節約・GPSのみ の3つのモードから選択できるようになった 位置情報サービスを直近で利用したアプリが一覧表示されるようになった 特に後者の「アプリが一覧で表示される」変更に関しての対策は、今後の位置情報サービスを使うアプリ開発においては非常に重要な要素になってくると考えております。 実はこのアプリ一覧の各アプリの項目はタップすることができ、タップするとアプリ情報の詳細ページにIntentされる仕組みになってます。 ご存知の通り、このページに来るとアプリのアンインストールができてしまいます... 電池の減りの早さに悩んでいるときに「高い電池使用量」という文言を見かけ、アンインストールできるページにIntentしたら普通ならどうするでしょう？ 位置情報サービスを使う際には 仕様にあわせて最適な選択をし、必要以上に位置情報サービスを使わない ということが今後は鉄則になってきます。 そうすることで アンインストールのリスクを回避 することができます。 iQONでの位置情報サービスを利用した事例 先日iQONでは、Androidで先行して天気コーデ機能をリリースしました。設定したエリアの天気予報と、天気予報にマッチしたコーデが見れる機能になっています。 当たり前な話ですが天気は地域によって全く異なってくるものです。そのためユーザーに自分が住んでいる場所を選択してもらう必要があります。 ただ、膨大な地域情報から自分が住んでいる地域を選択していく操作は手間がかかり、機能の利用率向上の足かせになります。 そこでiQONでは手動での位置情報設定に並行して、位置情報サービスを使った自動位置情報設定の機能を提供しました。位置情報の取得に関しては従来の仕組みである android.location.LocationManager android.location.LocationListener を使っています。 先ほども記載しましたが、位置情報サービスは 仕様にあわせて最適な選択をし、必要以上に位置情報サービスを使わない という鉄則が大事になってきます。 これを頭に入れた上で、以下の2つのポイントに気をつけて実装を行いました。 天気エリアは大まかな位置情報が取得できれば十分な機能を提供できるため精度は多少落ちても良い 一度位置情報が取得できれば機能に利用できるので位置情報を継続して取得し続ける必要はない public class WeatherSpotAutoSetActivity extends Activity implements LocationListener { LocationManager locationManager; public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.weather_spot_auto_set); locationManager = (LocationManager) getSystemService(Context.LOCATION_SERVICE); String gpsStatus = android.provider.Settings.Secure.getString(getContentResolver(), Settings.Secure.LOCATION_PROVIDERS_ALLOWED); if (gpsStatus.indexOf(LocationManager.NETWORK_PROVIDER) > 0) { // 位置情報の取得処理開始 // 大まかな位置情報が取得できれば要件を満たせるのでネットワークで取得する処理を走らせる（省電力） locationManager.requestLocationUpdates(LocationManager.NETWORK_PROVIDER, 0, 0, this); } else { // 位置情報サービスがOFFの場合は処理を終了 finish(); } } @Override protected void onDestroy() { locationManager.removeUpdates(this); super.onDestroy(); } @Override public void onProviderDisabled(String provider) { } @Override public void onProviderEnabled(String provider) { } @Override public void onStatusChanged(String provider, int status, Bundle extras) { } @Override public void onLocationChanged(Location location) { String latitude = String.valueOf(location.getLatitude()); String longitude = String.valueOf(location.getLongitude()); // 【重要】緯度経度が1度でも取得できた時点で処理を終了 locationManager.removeUpdates(this); // 取得した緯度経度を使って処理を行う（処理の詳細は省略） } } iQONではネットワークからの取得に絞っているため、位置情報サービスの設定画面には「低い電池使用量」としか表示されません。 Tips2:最新機能『Google Play ServicesのLocation API』を使って効率UP 前項でiQONは現状 android.location.LocationManager android.location.LocationListener を利用して位置情報を取得していると紹介させていただきましたが実はこれは古い仕組みで、2014年3月現在では Google Play ServicesのLocation API を利用するのが最も新しい形になります。 昨年のGoogle I/Oで新しく発表された機能です。 OSのバージョンがAndroid2.2以上、「Google Play 開発者サービス」がユーザーの端末にインストールされている必要がありますが、リアルタイムで位置情報を取得しないといけないアプリに関してはLocation APIを使用した方が圧倒的に効率が良くなります。 iQONにおいても今後の展開を考えて、近日中にLocation APIに乗り換える予定です。 Location APIは従来の仕組みと比べていくつか優れた仕組みがありますが、その中でも実際に使ってみて一番良いと思った仕組みは Fused Location Provider というものになります。 従来の仕組みでは位置情報を取得する際には LocationManager.GPS_PROVIDER や LocationManager.NETWORK_PROVIDER と指定する必要がありました。 Criteriaクラスをオプション的に用いて精度や消費電力を指定して組み合わせる方法もありましたが正直使い勝手はあまり良くありませんでした。 Fused Location Provider は、従来の仕組みとCriteriaクラスが統合されたような仕組みになっていて、精度と消費電力のどちらを優先させるかを選択するだけでProviderの指定は行う必要がなくなりました。 利用シーン１：高精度でリアルタイムに位置情報を取得したときの実装例 public class TestActivity extends Activity implements ConnectionCallbacks, OnConnectionFailedListener, LocationListener { /* * implementsするLocationListenerはcom.google.android.gms.locationのもの * 既存の仕組みから移行する場合にはこれに気をつけないとハマります */ private LocationClient mLocationClient; private LocationRequest mLocationRequest; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.test_activity); // Google Play Services が利用できるか確認 int resultCode = GooglePlayServicesUtil.isGooglePlayServicesAvailable(this); if (ConnectionResult.SUCCESS == resultCode) { mLocationClient = new LocationClient(this, this, this); } else { // 従来の仕組みで代用するなりのプランを考える } } @Override protected void onStart() { super.onStart(); mLocationClient.connect(); } @Override protected void onStop() { mLocationClient.disconnect(); super.onStop(); } @Override public void onConnectionFailed(ConnectionResult connectionResult) { // 接続が失敗したときの処理はここに記載 finish(); } @Override public void onConnected(Bundle bundle) { mLocationRequest = LocationRequest.create(); mLocationRequest.setInterval(5000); // 5秒ごとに位置情報を取得 mLocationRequest.setPriority(LocationRequest.PRIORITY_HIGH_ACCURACY); // 高精度で取得 if (mLocationClient.isConnected()) { mLocationClient.requestLocationUpdates(mLocationRequest, this); } } @Override public void onDisconnected() { // 切断したときの処理はここに記載 if (mLocationClient.isConnected()) { mLocationClient.removeLocationUpdates(this); } } @Override public void onLocationChanged(Location location) { String latitude = String.valueOf(location.getLatitude()); String longitude = String.valueOf(location.getLongitude()); // 取得したLat,Lonを使って処理を行う（詳細の処理は省略） } } } 利用シーン２：ある程度の精度で常時位置情報を取得したいときの実装例 public class TestActivity extends Activity implements ConnectionCallbacks, OnConnectionFailedListener, LocationListener { ... /* 他の箇所は利用シーン１と同様のため省略 */ @Override public void onConnected(Bundle bundle) { mLocationRequest = LocationRequest.create(); mLocationRequest.setInterval(3600000); // 1時間ごとに位置情報を取得 // setIntervalはあくまでも目安のため、状況によって間隔が変わる // そのため長時間取得取得する場合はsetFastestIntervalも設定する mLocationRequest.setFastestInterval(300000); // 取得の頻度は最低でも5分は空ける mLocationRequest.setPriority(LocationRequest.PRIORITY_BALANCED_POWER_ACCURACY); // 精度と消費電力のバランス取って取得 if (mLocationClient.isConnected()) { mLocationClient.requestLocationUpdates(mLocationRequest, this); } } ... } 利用シーン３：大まかな位置情報を1度だけ取得したい場合の実装例 public class TestActivity extends Activity implements ConnectionCallbacks, OnConnectionFailedListener, LocationListener { ... /* 他の箇所は利用シーン１と同様のため省略 */ @Override public void onConnected(Bundle bundle) { mLocationRequest = LocationRequest.create(); mLocationRequest.setPriority(LocationRequest.PRIORITY_NO_POWER); // 電力を使わない範囲で取得 // PRIORITY_NO_POWER よりも精度が高い PRIORITY_LOW_POWER でもテストをしてどちらを使うか決める if (mLocationClient.isConnected()) { mLocationClient.requestLocationUpdates(mLocationRequest, this); } } @Override public void onLocationChanged(Location location) { String latitude = String.valueOf(location.getLatitude()); String longitude = String.valueOf(location.getLongitude()); // 取得できた時点で処理を終了させる if (mLocationClient.isConnected()) { mLocationClient.removeLocationUpdates(this); } // 取得したLat,Lonを使って処理を行う（詳細の処理は省略） } ... } パラメータの値は実装する機能にあわせて細かくテストして最適な形にする。 まとめ 位置情報サービスは非常に便利ですが、今後は利用するアプリは一覧表示されて晒されることを理解した上で利用してください。 そのため 仕様にあわせて最適な選択をし、必要以上に位置情報サービスを使わない ことを徹底しないとアンインストールのリスクに繋がります。 また位置情報取得は従来の仕組みでもいいですが、 Google Play ServicesのLocation API はより細かい設定ができ使いやすいのでオススメです。 さいごに 日々成長している 日本最大級ファッションサービスiQON を一緒に成長させてくれるエンジニアを絶賛募集しております。 我こそはという方お待ちしております。 【Android】世界で勝ちたいAndroidアプリエンジニア募集 日本最大級のファッションサービスiQONをぶっちぎりにするエンジニア募集！