Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2019年02月15日

furusin

GDG京都様と共催でミートアップを開催しました!

こんにちは。ピクトリンク事業部の古川です。

先日のブログで、GDG京都(Google Developers Groups)様との共催でGDG ミートアップ in 京都を開催することを宣言しておりましたが、ついに実現しましたのでご報告致します!

 

GDG ミートアップ in 京都

今回も合計で30名以上の方にご参加頂きました!

特色としては、海外からGDE(Google Developer Experts)が2名参加されることもあり、セッションのほとんどが英語となりました!

GDEの2名以外にもGDG NZ(ニュージーランド)の方も来られており、とても国色豊かなイベントとなりました。

GDG NZの方とGDEのうちの1名は、直前に東京で開催されていた日本最大級のAndroidイベント「DroidKaigi」にも参加されていたそうです。

(ちなみに私も参加していました。弊社はDroidKaigiのスポンサーでもあります!)

 

GDEであるEnrique Lopez Mañas さんの発表「 Kotlin/Native for Multiplatform development」

IMG_20190210_135625

 

GDEであるiñaki Villar さんの発表「 Diving in the WorkManager API」

IMG_20190210_142212991

英語のセッションということもあり、皆さんいつも以上に真剣に(必死に?)話を聞かれているなぁ、というのが印象的でした!

また、GDG京都のメンバーの兼高さんも英語で発表してくださりました!

IMG_20190210_153921186

Pin-point rebuildable and non-rebuild custom widget from cch-robo

僭越ながら、私も発表させて頂きました!

IMG_20190210_160011292

Build your first wear app from furusin

 

本来は私の発表が最後の予定だったのですが、懇親会のケータリングが届くまで時間が余ってしまいましたので、GDG四国、GDG京都のメンバーより発表を頂きました!

IMG_20190210_163719

 

MVIMG_20190210_164002

 

懇親会の様子

hoge

今回はたくさんの方が懇親会に関するツイートをあげてくださりました!嬉しい!

 

最後に

私たち京都Devかふぇとしては、イベントの共催は初の試みとなりました。

初の共催だし、英語ばっかりだしどうなることやら……と不安はありましたが、参加者の皆様にはとても楽しんで頂けたようで、

運営一同嬉しく思っております!

 

今後は色々なコミュニティと共催等を進め、技術コミュニティの活性化や発展により一層貢献したいと考えています。

ご参加頂いた皆様、ありがとうございました!


2019年02月5日

furusin

フリューにてGDG ミートアップ in 京都を共催します!

こんにちは。ピクトリンク事業部の古川です。

 

この度、GDG京都さん(Google Developers Groups)との共催でGDG ミートアップ in 京都を開催することとなりました!🎉

このイベントには、海外からGDE(Google Developer Experts)が2名来日して登壇してくださります。

京都でGDEが2名も揃って登壇されるのは今回のイベントが初めてとのことです!

非常に貴重な機会ですので、是非お越しください!

イベント詳細

イベント名

GDG ミートアップ in 京都

日時

2019/02/10(日) 13:10 〜 18:30

場所

弊社フリュー会議室 (京都銀行 京都駅前支店 6階)

詳しい行き方はこちらを御覧ください。

 

概要

下記2名のGDEがそれぞれ得意分野に関して登壇してくださります。

Enrique Lopez Mañasさん

登壇タイトル:Kotlin/Native for Multiplatform development

AndroidとKotlinのエキスパートで、2013年からGDEとして活動されています。

iñaki Villarさん

登壇タイトル:Diving in the WorkManager API

こちらもAndroidとKotlinのエキスパートです。

GDGバルセロナやGDGマジョルカ、GDGダブリンにて活動するなど、他方にて活動されています。

 

その他登壇者

GDG京都 兼高さん

登壇タイトル:Flutterに関する話題 (仮)

スマートフォンアプリ開発にて最近ホットなFlutterに関してお話頂きます。

兼高さんはGDG京都のメンバーではありますが、全国の勉強会にも幅広く参加/登壇されており、

Androidも初期バージョンの頃から携わられています。

 

フリュー株式会社 古川

登壇タイトル:Build your first Wear App

非力ながら、私も登壇させていただきます!

技術情報があまり豊富ではないAndroid Wear(Wear OS by Google)のアプリをどうやって作るのかをご説明します。

 

イベントの最後には懇親会もご用意しております!

GDEの方と直接会話できる機会はなかなかありません。

会話は英語になってしまうかもしれませんが、ぜひ勇気を出してお話してみてください!

きっと…きっと誰かが助けてくれます!

下記写真は以前の懇親会でご用意した食事の写真です。しっかりお楽しみいただけるかと思います!

IMG_20180914_200603

 

最後に

今後も、このように色々なイベントとの共催も進めていきたいと思っております!

ぜひお声がけくださいませ〜


2018年12月25日

adachi

チーム開発で Epic branch を運用した話

 
🎅Merry Christmas🎄
 

こんにちは。
ピクトリンク事業部 開発部の足立です。

 

とうとう念願の iPhone XSApple Watch SERIES 4 が手元に届き快適なガジェット生活を満喫しています。
Apple Watch すごくて第1世代の時はWorkoutのWalkingを使っている状態で電車待っててもそのまま計測を続けていたんですが、Apple Watch SERIES 4 だと「ねぇ?Workout終わる?」的な感じで通知してくれるんです。可愛いやつっすよね。

 

では、本題に入りたいと思います。

 

この記事は フリュー Advent Calendar 2018 の 12/25(火) の記事になります。
今回はピクトリンクアプリの開発で導入した Epic branch 運用 のお話です。

 

はじめに

みなさんはチーム開発をする際、どのように作業を進めていますか?
1人で担当できそうな機能開発であればソロプログラミング、少し大きめの機能開発をペアプログラミングなどしている感じでしょうか?

これらの機能開発では基本的にブランチは1本あれば十分ですよね。
 

では、もっと大きな機能をチーム内の複数人で開発するとなった場合、当然ですがブランチ1本を共有して作業するなんてほぼ無理ですよね。
というか、Git使っててそんな運用するなんてちょっと考えものですよね。

 

そこで Epic branch を導入する

はじめに

大きな機能の中にいくつものサブ機能があり、そのサブ機能を複数人で開発する。
例えばこんな感じ。

ニュース機能

  • 画面周り作成
    • プロフィール部分
    • タイムライン部分
    • アルバム一覧部分
    • お気に入り一覧部分
  • サービス層作成
  • API層の作成
  • 画面とサービス層つなぎこみ
  • ログ実装
  • デザイン調整
  • リファクタリング
  • 機能テストのバグ対応
    …..etc
     

ざっくりと例を示すためにタスクを大きく分けていますが、実際に作業する場合はもっと細かい粒度にしても良いと思います。
なぜかというと Github project と併用することで、 Epic branch での開発は活きてきます。
詳しくは Github project の導入事例 を見てください。
 

ブランチを用意する

まずは develop ブランチから Epic branch となるブランチを作成します。

$ git branch epic/enhancement-news develop
作成したらプッシュしておきましょう。チーム開発ですから。
 

次に「API層の作成」を行うとします。
ここで注意するのが develop ブランチからではなく、Epic branch である epic/enhancement-news から作成することです。

$ git branch feature/add-api epic/enhancement-news

あとは、通常の開発と同様に feature/add-api のブランチで作業を進めるだけです。
 

他の人が作業をする場合も、上記「API層の作成」と同様に epic/enhancement-news から作業用ブランチを作成すればOKです。

$ git branch feature/add-vc epic/enhancement-news

 

イメージ図
epic-branch-create
 

ブランチのマージは?

難しいことはなく、自分自身の親ブランチにマージすれば良いだけです。
PRを出す時に base のブランチを epic/enhancement-news に変更することを忘れないようにしましょう。
 

マージタイミングも基本的にはPRレビューが完了した任意のタイミングで大丈夫です。
他の人がすでにマージしておりコンフリクトが起きるようであれば通常通りコンフリクトは解消してあげてください。
 

イメージ図
epic-branch-merge

 

実際、何が良いの?

これだけを見るとメリットらしいものがイメージしにくいですよね。
実際に運用した時のメリットを挙げてみます。
 

  • PRのマージタイミングを調整できる
  • PRレビューの時の差分を必要最低限にできる
  • 指摘事項(機能テストバグとか、企画からの指摘)を即時対応しやすい
    • 仕様がFIXしていなくても作業を進められる
  • 他の機能開発と混ざらない
  • Epic branch のPRレビューはほぼ不要
  • 作業の終わった感を感じられる
  • Epic branch へのマージタイミングで確認用アプリが配布される
    • Circle CI/Deploygate の設定要
  • Github project のカードとして扱いやすい
     

など、色々挙げられそうです。
その中でも特に「作業の終わった感を感じられる」が意外と大きな功績だと思います。
「長時間の開発」「終わりの見えない開発」といったものほどキツイものはないですよね。
 

「タスクを分担し、どんどんタスクを終わらせる」ことを実感するためだけに Epic branch の運用をしてみるのも良いと思います。
Epic branch をチーム開発はもちろん、ソロ開発でもぜひ導入してみてください!!

 
 

adachi

ピクトリンク事業部 開発部 足立
ピクトリンク のiOS版アプリ開発を担当。Swiftでごりごりと書いています💻


2018年12月25日

Rancher完全に理解した

こんにちはこんばんは、フリューのジョンです。
この記事はフリューAdvent Calendar 2018の12/24分となります。(ちなみに弊社はお休みです)

Dockerやってたりすると、オーケストレーションをしたくなりますよね。
そこでよく使われるのがKuberneteであったりするのですが、やっぱり構成が大変だったり、取っ掛かりが難しいとかあるような気がしています。
それでよく使われるのが、GoogleやAWSのKubernete、GKEやKESなどのサービスが多いのかなと思います。

ただ、もしそういうのが使えない。。。という方、Rancherはどうですか?と思っています。

Rancherとは

GUIでポチポチっとdocker imageのオーケストレーション構成を簡単に組み立てられるありがたいツールになります。
内部でのLoadBarancerなどの配置、アプリケーションのスケーリングが簡単にできるのは良い点かなと思います。

最近Rancher2系がリリースされており、DockerHubでは rancher/rancher となっています。rancher/serverでは1系がダウンロードできます。

Rancherの起動はDocker(Docker Compose)を使います。docker-compose.ymlは以下のようになります

無事に立ち上がりましたら、https://(host名):8443 にアクセスしてみてください。ログイン画面が出ると思います。デフォルトはadmin/adminです。

スクリーンショット 2018-12-21 14.59.57

スクリーンショット 2018-12-21 14.57.48

今回触る上で試しに、構成としては下の図のような構成を作成しようと思います。

スクリーンショット 2018-12-21 11.06.59

Rancherをつかってみる

ポチポチやっていきましょう。まず、clusterを作ります。名前は「kotlin-sample-cluster」です。コマンドが表示されていますのでそれをコピーしておいてください。

スクリーンショット 2018-12-21 15.05.37

スクリーンショット 2018-12-21 15.06.50
次にアプリケーションを起動するサーバを登録します。先程のコマンドをサーバ上で叩いてください。

sudo docker run -d --privileged --restart=unless-stopped --net=host -v /etc/kubernetes:/etc/kubernetes -v /var/run:/var/run rancher/rancher-agent:v2.1.4 --server https://${①}:8443 --token ${②} --ca-checksum ${③} --worker

するとNodesのタブの画面で以下のようにサーバが登録が開始されているのを確認できるはずです。暫く待つと登録完了となるはずです

スクリーンショット 2018-12-21 15.23.46

スクリーンショット 2018-12-21 15.36.45

では実際にアプリケーションを配置します。
まずkotlin-sample-httpd(Apache)

スクリーンショット 2018-12-21 16.05.15

kotlin-sample-tomcat(tomcat)

スクリーンショット 2018-12-21 16.07.04

LB(LoadBalancer)

スクリーンショット 2018-12-21 17.01.08

kotlin-sample-httpd、kotlin-sample-tomcatは私が作成したアプリケーションをimageにしたものになります。

LBでkotlin-sample-httpdへ向けているので、しばらくしてから、http:(ホスト名)/hello にアクセスしてみてください。
hello, world!! という形で表示できていれば、Rancher完全理解したという状態になっているはず、、、です。

まとめ

Docker Imageをクラスタリングできました。ただし、プロキシ環境では難しくなってくるかもしれません。
皆様、困ったときにRancherを思い出してもらえればと思います!


2018年12月21日

araki

Firebase A/B TestingでアプリのABテストをしよう!

この記事は フリューAdvent Calendar 2018の12/21分です。

こんにちは。ピクトリンク事業部開発部の荒木です。普段はピクトリンクというアプリのAndroid版を開発しています。世間ではスマブラの話が多いなかで、まだスプラトゥーンをやってます。ウデマエはエリアのS+が最大なので、まだXに到達してません。知り合いの子供(ガチホコのウデマエX)に「エリアでS+ならすごいよ。僕はエリアはA+だし。」とフォローされて心が折れそうですが、Xになるまで頑張りたいと思います。

今回は、Firebase A/B Testingをピクトリンクアプリに導入した話を書きたいと思います。

Firebase A/B Testingとは?

https://firebase.google.com/docs/ab-testing/?hl=ja

Firebase A/B Testingを使うと、Remote ConfigまたはNotifications Composerを使ってアプリの画面や通知に関するABテストの実施ができます。A/Bパターンの振り分けはもちろん、結果の分析も実施され、Firebaseのコンソール上で見ることができます。

今回は、Remote Configを使ったABテストについて説明します。

Remote Configを使ったABテスト

テストの作成

ここからは、テスト作成の手順について説明します。画像多めでやっていきます。

① コンソールの左ペインからA/B Testingを選択

左ペインのABTesting

②「テストを作成」を選択

テストを作成

③ Remote Configを選択

RemoteConfigを選択

④ 基本情報の入力

④基本情報の入力

これが、Remote ConfigによるABテストの作成画面です。まずは、テスト名とテストの説明(任意)を入力してください。
今回は、ボタンの色を変えるテストを想定して「ボタンの色」としてみました。

⑤ ターゲット設定

⑤ターゲット設定

テスト対象となるユーザーを設定します。

ターゲットユーザー  アプリのIDやバージョン、ユーザープロパティによって対象を絞ります。
ターゲットユーザーの割合  ターゲットユーザーのうち、何%がテスト対象になるかを設定します。
100%ならターゲットユーザー全員が対象になります。
アクティベーションイベント
(任意)
 このFirebaseイベントが送信されることで、ユーザーがテスト対象になります。
たとえば、特定の画面に遷移したイベントなどを指定します。

⑥ 目標設定

⑥目標設定

コンバージョンの設定をします。

メインとなる目標としてFirebaseのイベントを1つ選択します。このイベントの送信が、コンバージョンとしてカウントされます。また、別のFirebaseイベントを追加したり、推定収益やクラッシュフリー率などを目標に設定することができます。

 ⑦ バリアントの設定

⑦バリアントの設定

次は、バリアントの設定です。バリアントの設定をすることで、Remote Configで取得できる値が変化します。「パラメータ」の部分には、Remote Configのパラメータキーを設定します。「値」の部分にはパターンごとにRemote Configが返す値を設定します。

今回は、 ab_test_param キーで、コントロールグループ(Aパターン)ではBLUE、BパターンではREDを返すような設定にしました。

この設定をしておくと、アプリ側でRemote Configを使って ab_test_param キーで値を取得するとBLUEまたはREDのどちらかが50%の確率で取得できます。

④〜⑦の設定が終わったら画面下の「確認」ボタンを押します。

⑧ テストの開始

⑧テストの開始

テストの内容を確認したら、「テストの開始」を押すとテストが開始します。

ちなみに、「テスト端末を管理」を押すと特定の端末でABパターンを固定する設定ができます。

テスト結果の確認

2週間ほど待つとテストの結果がでます(十分なサンプル数がない場合は終わらないかもしれません)。

下の画像のように、最も効果的なパターンが表示され、コンバージョン率や改善率も提示されます。

ABテストを終了する際に、オリジナルのパターンに固定するか、最も効果的なパターンに固定するかを選択することができます。

テスト結果①

テスト結果②

さいごに

この記事では、Firebase A/B Testingの導入方法と結果の確認について説明しました。Firebase A/B Testingを使うことで、とても簡単にABテストを実施することができます。

ABテストを上手く活用しながらどんどんサービス改善をしていきたいと思います!