いつまで画像で説明してるの? LICEcapを使ってGIFアニメでわかりやすくバグ報告しよう。

2014/08/25

こんにちは。 THE CLIPのイシバシ (@hisatake) です。
今回は開発には欠かせないバグの共有方法についてブログでご紹介します。

言葉と画像だけでバグを報告するのはもう古い!

プロダクトを作成している時に、バグはいつもついて回ります。
(昨日の自分は、今日の他人ということもありますがw)
ひとりで開発していればどういうバグかはわかるのでいいのですが、
チームで開発しているときは全てのバグを自分で直すわけではありません。
上手くチームメンバーへとバグの状況を伝えなくては行けません。

特に昨今jsリッチなWebアプリケーション、Nativeアプリケーションの開発等々
フロントの動きのバグの割合も増えてきているかと思います。
皆さんはどのようにバグを報告してるでしょうか?

言葉だけで説明していますか?
Aのボタンを押して、次にBのボタンを押した時に、ちょっとここの画像がおかしい。とか

スクリーンショットを撮ってもう少しわかりやすく説明しますか?
ここのアニメーションがちょっと遅い。とか

もしくは担当のエンジニアに声をかけてちょっと見てよ。
と声をかけたりしますか?

非効率でめんどくさいですよね。
素早くバグを開発していくにはいちいち文章で説明している暇はありません。

そこでLICEcapとGithubで効率的かつわかりやすいバグの報告をしましょう。

LICEcapとGithubで効率的なバグの報告方法

Cockos Incorporated | LICEcap

まずはLICEcapを入手しましょう。

後はLICEcapを起動して、実際のバグの再現手順を録画するだけです。
これだけで簡単にGIFアニメができます。

bug

お手軽!!!

あとは、このGithubでissuesを切って、画像を貼り付けるだけ。
GithubはGIFアニメをサポートしてるので、貼り付ければページ内で見れます。
便利ですねー。

更にはSlackと連携しているとSlackにもそのGIFアニメが貼り付けられて見ることが可能です。

爆速で開発を続けていく上でバグの修正も素早く行っていくことが必要です。
GIFアニメでバグを共有して爆速の開発しましょう。

デザイナーもコードを書こう!デザイナーとエンジニアの役割分担(Webサービス編)

2014/08/18

THE CLIPのケント(@kentymmt)です。弊社では自社/受託共に、Webサービス、iOSアプリ、Androidアプリなどの開発を行っています。弊社のコアメンバーはデザイナーの僕とエンジニアのイシバシですので、今回はこの体制でWebサービス(PC/スマートフォン)を開発する際にどのような役割分担やフローで動いているのかを紹介したいと思います。
使う技術はRails, GitHub, AWSなどです。開発スピード重視!

キックオフミーティング〜ベース作成

基本的な仕様とスケジュールが決まったらほなやりましょかという事でプロジェクトはスタートします。エンジニアはRailsプロジェクトを作ったりインフラ構築やデータベースの設計を始め、デザイナーは必要に応じて紙のワイヤーフレームなどを書いたり、カラースキームを決めたりしていきます。(ワイヤーフレームは基本仕様を確認するためのもので、ごくごく単純なものが多いです。)

Railsプロジェクト出来た

Railsプロジェクトが立ち上がったら、git cloneしてきてデザイナーもローカルで動かせるようにします。サービスの性質にもよりますが、全画面をPhotoshopなどのソフトで詳細に作り込んだりせずに、作るとしても主要な画面2,3つで、あとはHTML/CSSを書きながら進めて行きます。mixinやform、alert系などを含めた主要なUIコンポーネントを作りながら、表側のデザインを作っていきます。

Railsで自由にHTML/CSS/JSを書きたいんだけど?

$ rails g controller designs

designs_controller.rbに

class DesignsController < ApplicationController
 def index
  render "#{params[:path]}.html"
 end
end

config/routes.rbに

Rails.application.routes.draw do
 unless Rails.env == :production
  get '/designs/:path' => 'designs#index'
 end
end

これでapp/views/designs/ 以下に hoge.htmlを作ると localhost:3000/design/hoge でアクセス出来る上に layout/application.html 読み込んでくれるのでとても便利です。後々エンジニアが本番のviewに組み込む時にも大幅に工数を削減する事が出来ます。

本番viewへの組み込み

デザイナーがトップや検索結果等、表の主要画面を完成させたらエンジニアが本番viewへの組み込み、その間にデザイナーが管理画面など作成、出来たらエンジニアが本番viewへの組み込み、その間にデザイナーは表の主要画面のスマホ用デザインを作成、出来たらエンジニアが本番viewへの組み込み、その間デザイナーは上がってきた修正を、、というサイクルでスクラム的に開発していきます。タスクはgithub issueを使い、pull requestベースで開発して行きます。

デザイナーだけど黒い画面とかしらないんだが?

Railsの起動や操作でどうしても黒い画面を使わなくてはいけない場合がありますが、分からない事はどんどんエンジニアに聞きましょう!そしてエンジニアは優しく教えてあげましょう!お互いに歩み寄るのが楽しい開発のコツですね。とはいえデザイナー的にはGUI使って楽したい欲があるのでGitに関しては僕はTowerというソフトを使って操作しています。ちょっと高いけどとっても使いやすいです!

スクリーンショット 2014-08-13 17.13.56

http://www.git-tower.com/

ある程度出来てきた

/designs/から本番viewへの移行が終わった後も変更や修正点は必ず出てきます。ここからはデザイナーもviewをガンガン触っていきます。eRubyをなんとなーくでも覚えると捗ります。

デザイナーだけどHamlとがCoffeeScriptとか言われても書けないんだが?

弊社ではHamlではなくHTMLを使う事が多いですが、これはある程度覚えましょうという事になります。僕もCoffeeScriptはあまり書けず、jQueryなら、という感じなので、雑でもjQueryで書いて「こういうことしたいんす!」とエンジニアに言って書き直してもらったりしています。臨機応変に行こう!あれ、Sass/SCSSは、、、もうマストな技術ですね!

出来た

デザイナーはブラウザチェックをしたり、エンジニアは負荷テストをしたり、開発も大詰めです。問題がなければ完成です。出来たと言ってもサービスはリリースしてからが始まりですね!リリース後の開発サイクルも同じような形でやっています。ともあれ、お疲れさまでした!打ち上げだ!

まとめ

Webサービスはプロトタイピングしながら動きを検証していく事も重要であり、そもそもエンジニアは絶対的な作業量がデザイナーよりも多くなる場合が多いです。そういった点でデザイナーがマークアップをしGitなどを操る事は初期開発だけでなくリリース後の追加開発、仮説検証やバグ修正等の開発力に大きく貢献します。このような感じで今回はデザイナー1人、エンジニア1人という最小メンバーでの開発フローの一例を紹介しました!

Facebookアプリのテストユーザー運用が捗るTips

2014/08/08

はじめまして。

THE  CLIPの藤牧(@mackey_100)です。

Facebookアプリを作っていると、テストユーザーを沢山作って動きを確かめたくなることがよくあります。ただ、沢山テストユーザーを作ってダッシュボードから手動で管理しようとすると大きな手間がかかってしまいます。面倒な思いをされている方も多いのではないのでしょうか?

そこで、今回はGraphAPIを使って

  • テストユーザーを自動生成する方法
  • テストユーザー同士のソーシャルグラフを自動で構築する方法

をご紹介しようと思います。

テストユーザーを自動生成する方法

テストユーザーの作成方法

テストユーザーの作成にはtest-usersのAPIを使います。

END POINT

https://graph.facebook.com/APP_ID/accounts/test-users

METHOD

POST

PARAMETERS
installed #アプリをインストールしているか
permissions #インストール時のパーミッション
name #名前
locale #利用言語
access_token #アプリのトークン

日本人のユーザーを作成

テストユーザーの作成はダッシュボードからでもできるのですが、

Screen Shot 2014-08-08 at 6.12.35 PM

のように、どこの国の人か分からない感じになってしまいテンションが上がりません。
今回は日本人の名前でテストユーザーを作りたいと思います。日本人の名前はgimeiというGemがあるのでこちらを使います。Fakerの日本人版のようなものですが、なかなか便利です。

willnet/gimei · GitHub

Rake Task化

今回はRailsを使っているので Rake task化していますが、他の環境でも同じような書き方でいけると思います。

利用方法

$ rake dummy_user:create number=ユーザー数

これで日本語名のテストユーザーが作成されます。

Screen Shot 2014-08-08 at 6.13.45 PM

ほんのちょっとした違いですが、ユーザー名にリアリティが出てくるので開発のテンションも高まるはずです。
こういうの、大事ですよね!!

テストユーザー同士のソーシャルグラフを自動で構築する方法

次に、テストユーザー同士で友達関係を作る方法をご紹介します。アプリのテスト時にソーシャルグラフを活用する場面はよくあると思いますが、ダッシュボードから手作業で設定するのは骨が折れるのでAPIを使って自動化しましょう。

ユーザー一覧の取得

ユーザー一覧を取得します。ユーザー一覧取得方法はこちら

END POINT

https://graph.facebook.com/APP_ID/accounts/test-users?access_token=APP_TOKEN

友人関係の構築

次に、取得した一覧を使って友達関係を構築します。
詳細はこちら

友だち申請

https://graph.facebook.com/テストユーザーAのID/friends/テストユーザーBのID

テストユーザーAのaccess_tokenをパラーメーターとして渡してpostすることで、
テストユーザーAからテストユーザーB友達リクエストをすることができます。

友だち申請の承認

https://graph.facebook.com/テストユーザーAのID/friends/テストユーザーBのID

に、テストユーザーBのaccess_tokenをパラーメーターとして渡してpostすることで、承認されます。

idやaccess_tokenはユーザー一覧取得時に取れるので、そちらを使って下さい。

Rake Task化

こちらもRake Task化しました

利用方法

$ rake dummy_user:friends

貼ったコードの通りに実行すると、「1人目(0番目)のユーザーが21人目までのユーザーと友達」にすることができます。
開発においてそこまで頻繁に使うものではないので、ユーザー数等は固定してしまっていますが、もし頻繁に使うようであれば引数を使えるようにして汎用性を高めるといいと思います。

以上、簡単にご紹介させていたただきましたが、如何でしたでしょうか?
同じようなことをしようとしている方の参考に少しでもなれば幸いです。