読者です 読者をやめる 読者になる 読者になる

inFablic

Fablic開発者ブログ

Android版フリルでの商品画面リニューアルにおけるCollapsingToolbarLayoutを用いたレイアウト構築

Android

この記事はFablic Advent Calendar 22日目の記事です。 http://qiita.com/advent-calendar/2016/fablic

こんにちは。Androidエンジニアの @nakamuuu です。

フリルは2016年10月、ロゴやアイコン、アプリ全体のカラーリングの変更を含む大規模なリニューアルを行いました。

Android版フリルではリニューアルに合わせ、商品画面の改修もしています。今回はこの商品画面でのCollapsingToolbarLayoutを用いたレイアウト構築、特に各Viewに指定されている fitsSystemWindows のパラメータの役割について実装時に少し掘り下げて調べてみたので書いていきたいと思います。

f:id:nakamuuu-muuu:20161222111315j:plain

続きを読む

デザイナーが1人でキャンペーンを設計から運用までしてみて良かったこと

f:id:kobachicchi:20161222180151j:plain

こんにちは。Fablicのデザイナーのkobachiです。 現在は主にキャンペーンの運用をしています。

この記事は、 Fablic Advent Calender 2016 20日目の記事です。

Fablicでは、デザイナーも1からキャンペーンを設計・実装・運用を行います。 1から…と聞くと大変そうに聞こえるかもしれませんが、 やってみて良かった点がいくつかあるので、ぜひ紹介したいと思います。

続きを読む

Fablicでの Codenize.tools を使ったインフラ管理について

この記事はFablic Advent Calendar 19日目の記事です。 http://qiita.com/advent-calendar/2016/fablic

こんにちは、Fablicでサーバーサイドエンジニアをやっている yutadayo です。

今回は AWS の環境設定をコードで管理できる Codenize.tools の紹介と弊社での運用事例についてご紹介しようと思います。

インフラのコード化について

みなさんは、infrastructure as code を進めるにあたってどういうツールを使っていますでしょうか。 AWSの構成管理は CloudFormation や 最近では Terraform などが注目を集めているようですね。

弊社では chef でサーバの設定やデプロイをしていますが、AWSの操作は Management Console でポチポチしている部分も多かったので、既存の環境をコードで管理できる Codenize.tools を導入してみました。 導入する前は下記のような悩みを感じていました。

  • Management Console で行った操作の履歴を残すのが困難
  • 操作する際の心理的安全の欠如
  • 大量の設定をするときにポチポチ設定が面倒、時間がかかる
  • インフラ構成変更の依頼フローが統一されていない

これらの悩みをツールの導入によって、解決したいなと考えていました。

Codezine.tools について

Cookpadのwinebarrelさんがメンテナンスされている、AWSをDSLの記述で管理できるツール群です。

既に本番環境で稼働しているAWSの設定を管理したいと思っていたので、特別なセットアップや用意をしなくても、 簡単に導入できるという点で、大変魅力的でした。

また、Codenize.tools はどのツールも、簡単かつ直感的に使うことができ、生成されたコードも、Githubで管理できるので、上記のような問題も解決できると考えました。

弊社では RoadwokerPiculetRadiosonde など複数のツールを使っています。

導入

Codenize.tools を見れば、ほとんどのことが記載されていますし、 各AWSサービスを扱うのに必要なポリシー設定がされているアカウントがあれば、すぐにでも導入が可能です。

例)Roadworker

RoadworkerはRoute53の管理を行うツールです。

$ bundle exec roadwork -e -o Routefiles/example.jp.route --target-zone "^example.jp"
Export Route53 to `Routefiles/example.jp.route`

-e オプションを指定して、既存の環境設定をDSLとして出力できます。 出力された、ファイルの中身は下記のようになっています。

# -*- mode: ruby -*-
# vi: set ft=ruby :
hosted_zone "example.jp." do
  rrset "example.jp.", "A" do
    ttl 3600
    resource_records(
      "xx.xx.xxx.xxx"
    )
  end
end

--dry-run コマンドを使って、事前に適応内容を調べることができます。 上記のファイルの resource_records を更新して、コマンドを実行すると下記のようなログが流れます。

$ bundle exec roadwork -a --dry-run
Apply `Routefile` to Route53 (dry-run)
Update ResourceRecordSet: example.jp. A (dry-run)
  resource_records:
    -[{:value=>"変更前IP"}]
    +[{:value=>"変更後IP"}] (dry-run)
No change

冪等性が保証されているので、Route53がすでに定義ファイル通りの設定の場合は何も変更は行われません。

$ bundle exec roadwork -a
Apply `Routefile` to Route53
No change

Codenize.tools は Roadworker 以外にも沢山ありますが、どのツールもコマンドのインターフェイスは 統一されていて、基本的な操作の流れは変わらないので、非常に扱いやすいのも魅力です。

ディレクトリ構成

一つのAWSアカウントで複数の運営サービスを管理されている場合や、運営サービス毎にAWSのアカウントを分けている場合があるかと思います。 いずれにせよ、exportしたときのファイルが膨大になってしまうので、弊社では運営サービス毎にexportするディレクトリを分けて運用しています。

f:id:yutadayo:20161218205044p:plain

RoadworkerやPiculetで出力されるファイルはホストやリージョンによって設定を分けた方が見やすいので、 ファイルを分割し、Routefile内で他のファイルをrequireする構成にしています。

# -*- mode: ruby -*-
# vi: set ft=ruby :

Dir::glob('./Routefiles/*.route').each do |file|
  require file
end

また、使用時には AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEY を環境変数に設定しないといけないのですが、 AWSアカウントやAWSサービス毎に毎回変更するのは面倒です。

この問題には direnv を導入し、各ディレクトリに .envrc を設定することで 該当ディレクトリに移動すると、必要な環境変数が設定されるようにしています。

.envrc の中身は下記のようになっています。

export AWS_ACCESS_KEY_ID='xxxxxx'
export AWS_SECRET_ACCESS_KEY='xxxxxx'

運用について

Github上にCodezine.toolsで生成されるコードを管理するリポジトリを用意し、構成変更を行う際は issue を作り、変更差分の Pull Request を出してもらうフローで運用しています。ワークフローは下記のように行われます。

  1. インフラの設定変更の依頼をGithubでissue立て
  2. 設定変更の修正をPull Request
  3. Pull Requestをレビュー(dry-run)して問題がなければマージ
  4. masterブランチに merge して、本番環境に適応

f:id:yutadayo:20161218192043p:plain

Elasticsearchなど複数のEC2インスタンスでクラスタを組んだりする際に、インスタンス全てに監視の設定をポチポチしていくのは大変な辛さがあったのですが、コードで管理しているので、既存の設定をコピーできて作業が大変楽になりました。

運用後の効果

変更内容の履歴が残る

スタートアップではインフラ専門のエンジニアの確保はなかなか難しく、運用が属人化しやすいと感じています。 問題と感じていた構成変更はGitでコードとして管理されるようになったので、いつ誰がどのように変更を行ったかが diff や履歴を追うことで分かるようになりました。

オペレーションフローができた

Slack上でのチャットやMTGでの依頼ベースで運用していたインフラの構成変更に、Github Pull Request を用いて運用できるフローができたのは良かったと思っています。また、変更の適応もコマンドを実行するだけなので、オペミスを防止することができます。

運用効率の向上

大量の設定をポチポチしながら変更していた運用も、既存コードのコピーで済ますことができ、開発効率が向上しました。

おわりに

上述の悩みは、Codenize.tools の導入で解決することができました。 しかし、各コマンドの適応作業は今の所、エンジニアが手動でコマンドを実行しているので、今後はPull Request がマージされたタイミングでの自動適応を行なって完全な自動化をしていきたいと思っています。

また、Terraform 0.7 のリリースから 既存リソースの import 機能が提供されるようになっているので、 部分的に代替となるツールの選定も進めていきたいなと思っています。

最後に、これほど便利なツールを提供してくださってる winebarrel さんをはじめとした開発者の皆様に心からお礼を申し上げます。

Railsログを美しく Beautiful::Log

この記事はFablic Advent Calendar 15日目の記事です。 http://qiita.com/advent-calendar/2016/fablic

はじめまして、Fablicでサーバーサイドエンジニアをやっている岸と申します。

今年の6月、Fablicにジョインして初めてRuby/Railsに触りました。

それまでJavaがメインだった*1僕にとってはRailsは気がきいて柔軟性がハンパないので、超楽しく開発しています。その一方で、Atom/Vimとターミナルでの開発は、立派な無償IDEであるeclipseと比べるといささか心もとない気がしました。*2

一番に気になったのはログ周りでした。Logger/Appenderのことにも触れていきたいのですが、一番身近なのは開発中や不具合調査中のコンソールログ

これをキレイにするgem、beautiful-logを作ってみたのでご紹介します。

https://github.com/nogahighland/beautiful-log

*1:GroovyというRubyを参考にしたJVM言語と、Railsを参考にしたGrailsというフレームワークも一応使っていたんですよ

*2:RubyMineとかもっと良いのかもしれませんが、有償IDEにまだ抵抗あり使ったことない…

続きを読む

フリルのiOSアプリ開発におけるエンジニアとデザイナーの作業分担について

こちらはFablic Advent Calendar 2016の記事です。

こんにちは。FablicのiOSエンジニア、shobyです。

iOSエンジニアの皆さんは、デザイナーとどういった形で仕事を進めているでしょうか。

iOSアプリの開発はWebの開発と異なり、UIとロジックを完全に分離することが困難なため、エンジニアとデザイナーの責任範囲が曖昧です。 どこまでエンジニアが担当し、どこまでをデザイナーが担当するかは悩みが多いと思います。

現在、フリルのiOSアプリ開発は、デザイナーがSketchでデザインし、エンジニアがSketchファイルを見ながらUIを実装する方式で進めています。

フリルではこの方式を取り入れることで、デザイナーにStoryboard上でのUI調整を任せていた時期に比べ、開発速度が向上するメリットが得られました。

この記事では、フリルのiOSアプリ開発における、エンジニアとデザイナーの作業分担を、どのように行ってきたかお話しします。

続きを読む

芯を通すリブランディング -デザインに入るまで- (@wariemon)

f:id:wariemon:20161214114759p:plain

こんにちは。Fablicのデザイナーのわりえもん (@wariemon) です。
この記事は Fablic Advent Calender 2016 の記事です。
 
フリルのリブランディングを担当した際に、新規のブランドつくりと違うチェックポイントが存在することに気づきました。
その上でリブランディングにおいて、非常に重要な「デザインに入るまでのプロセス」についてお話させていただきます。
 
 

Elasticsearchの1系から2系への移行

サーバサイドエンジニアの@sinamon129です。

FRILのサーバサイド開発・インフラ・チューニング・検索・運用など幅広くやらせていただいております。

9月に、全文検索サーバとして使っているElasticsearchを1.7.2から2.3.5へ移行をしました*1*2。現在、2.4系で運用しています*3。また、2系へupdateしたので、シングルクラスタだとMarvelがProduction環境でも無料で使えるということで、導入しました。

*1:翌日2.4.0が前日に出ていたことに気づいて泣きたい気持ちになりました。その後2.4.1にアップデートしました。

*2:年始に今年何やりたい?って言われた時にElasticsearchのupdateと言っていたぐらいには念願でしたw

*3:5系がでてしまったので、またバージョンアップします

続きを読む

Fablicの効果検証を支えているGoogleスプレッドシートのお気に入り便利機能5つ

文化

こんにちは。 こちらはFablic Advent Calendar 2016 9日目の記事です。

Fablicでデザイナー兼マネージャーをしている@yuki930です。

フリルのAndroid版のUI/UX担当→Web版のPO兼UI/UX担当を経て、 今は購入全体を見ているチームのデザイナー兼マネージャーをしております。

Fablicのデザイナーは、定性的なユーザーの何気ない声をヒントにし、定量的な大量のデータから執念深くユーザーの行動を分析をしていき、その上で今どこに問題があるのか、どう解決することができるかを日々考えながら仕事をしています。

そのあたりについての詳細はこちらの記事をぜひ御覧ください。

定性と定量の間で考える http://in.fablic.co.jp/entry/2016/12/05/193334

UIデザインのKPI設定 http://keisuke.tsukayoshi.com/blog/3161

今回は、これらで上げられている調査や効果検証の際に活用しているGoogleスプレッドシートについて、いくつかのおすすめ便利機能をご紹介したいと思います。

続きを読む

FablicでのRedash導入事例

プロダクトマネージャー兼エンジニアのid:ninjinkunです。この記事はFablic Advent Calendar 2016のエントリーです。

Fablicでは今年の9月頃からOSSのBIツールであるRedashを導入して、誰でもSQLを叩ける環境を整備しました。以下、運用してわかったRedashの良い点、悪い点、課題などについて述べていきます。

なお、接続しているのは本番データから個人情報を抜いた分析専用slaveです。他にも時系列のデータが入っている別の分析DBや、BigQueryも接続されています。

f:id:ninjinkun:20161206195338p:plain

続きを読む

Picasso にパッチを当てた話

Android

こんにちは。Androidエンジニアの黒川(@hydrakecat)です。

この記事は、Fablic Advent Calendar 2016 のエントリーです。

本日は、Androidのライブラリにパッチを当てた話をしたいと思います。先日、Picassoという画像ライブラリのバグにより、弊社のフリルで一部のユーザーさんに問題が発生しました。この記事では、その問題を解決するために、なぜパッチを当てることにしたのか、どのように行ったのか、どういう問題があったのか、という話をいたします。

続きを読む