Furyu
[フリュー公式]

Tech Blog

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

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テストを上手く活用しながらどんどんサービス改善をしていきたいと思います!


2018年12月20日

Hashimoto Naoto

複数のファイルの中身を検索して、条件に一致した行だけ消す方法

ピクトリンク事業部開発部インフラ課の「アドベントカレンダー3記事目で若干ネタ切れの気配を感じ始めたエンジニア」の橋本です。

むしろ12月中はもろびとがこぞってアドベントカレンダーするので、6月くらいにやったほうが目立てるんじゃないかなとか現実逃避しています。梅雨明けとか讃えましょうよ。

 

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

今回は、複数のファイルに横断検索をかける方法、ヒットした情報だけを消す方法をご紹介しようと思います。

どういう時に便利?

いろんな場面で活用できる余地のあるテクニックだと思いますが、実例をあげるとメーリングリストの管理などに便利に使えます。

mlsample1

このように、ひとつのメーリングリストにユーザ名を連ねる形で運用している場合を想像してみてください。
社内の関係者に一斉に情報が行き渡るよう、いい感じにメーリングリストが構築されているような環境ですね。

 

この状態で、「桐島、弊社やめるってよ」と言われた場合にリストの管理者がやらないといけないのは、

mlsample2

ファイルの中に「桐島」が含まれるものを全て探し、

mlsample3

このように「桐島」を削除した状態で上書き保存する必要があるはずです。

 

この例だとファイルは3つだけですが、これが20も30もあったら大変面倒なうえに、そのうち作業ミスも発生しかねません。

 

これをスクリプト一発で終えることができたら幸せですよね!

実際のスクリプト

以下の例は「ファイル名が.qmail-から始まるファイルから対象者を探して消す」スクリプトです。

以下のようにして使います。例のごとく実行権限付与を忘れずに。

実働部分の解説

「本当に消していいの?」と聞く部分が長いだけで、中身は至ってシンプル。

これで探して、出てきたファイルのリストを

これで対象者を削除して上書き保存しているだけです。グッバイ桐島。また会う日まで。

 

対象となるファイル名の.qmail-* があまりにも長すぎるとオーバーフローを起こしてしまう可能性があります。その場合はxargsを使うなど調整してみてください。

おわりに

今回はメーリングリストの管理を例にしましたが、

「複数にまたがったファイルから条件に合致するものだけを探す」

「ヒットしたものを置き換える、削除する」

などの操作は、ときおり発生するものです。

 

一回だけで済む場合はこの限りではありませんが、何度もやらないといけない可能性がある場合は、少しでも楽に運用できるようにしていきたいものですね。