LINE DEVELOPER DAY 2017 - Report

9/28(木)に渋谷ヒカリエ9F ヒカリエホールでLINEのLINE DEVELOPER DAY 2017(以下略:linedevday)がありました。

URL: LINE DEVELOPER DAY 2017

linedevdayは、今回が3回目で過去最大の参加応募があったそうです。
去年も参加し、去年は、Messaging APIが発表され、今年は、Clovaの発表でした。

『LINE DEVELOPER DAY 2016』 VS 『LINE DEVELOPER DAY 2017』

個人的には、去年の方が印象が大きく、全てのセッション的にも満足度が高かったですが、今年は、デバイスを用意するところから必要であるため、「Messaging API」と比べて「Clova」は、初期コストから高い印象で手が出しにくい感じがした。
また、去年のアンケートを元に建てられたセッションとのことで、聞きたかった内容が少なかったです。

CIやビルド、テスト周りをどう工夫しているのかのセッションや、去年はあったが今年はなかったLINE GAMEsのセッションが欲しかった。

去年との違い

去年は、2つの会場でしか発表がなかったが、今年はLTのような枠を設けて3つ目のセッションスペースが小さい規模で作られてました。
そこの内容も見たかったものの、去年同様に2つの会場であったセッションの方に入ったため聞くことが難しかった。
後ほど、資料が共有されるためそれを期待しています。

Opening Session

現状のLINEとLINEのコンテンツについて発表されてました。
世界中で使われているLINE、そのプラットフォームに関連しているシステムと今後の取り組みが簡単に紹介されてました。
また、去年発表したMessaging APIについて作られたBotの数や関連イベントの詳細、次の取り組みとしてClovaと一部のユーザーに販売したWAVEについて詳細を発表されてました。

資料: Opening Session

ClovaとWAVE

Clovaは、AppleのSiriと同様のAIシステムでLINEとWAVEの仲介に位置する存在であり、LINEというプラットフォームを最大限に生かすことで様々な使用方法ができることと、ユーザーのライフスタイルに密着させ、より良い生活スタイルが生まれることを謳っていました。

資料: The Technologies in Clova

その際、今年のFIFAサッカーのハーフタイムのCMで初めて公式に公開したCMが会場に流れて、その可能性を動画を使って会場にいる参加者達にイメージさせていました。

• LINE「Clova」が未来予測？FIFAサッカーのハーフタイムCMで騒然 #日本代表
• 【公式】Clova: TVCM ～ もうすぐ来る未来篇(60秒) - YouTube
• 【公式】Clova: TVCM ～ クマとタヌキ 篇(60秒)

※クマとタヌキ 篇は後から見つけて仕事中見たんですが、、泣きそうになったw

---

直接聞いたセッションについて

10:40からオープニングがあり、11:00からはClovaについて詳しく発表がありました。
その後は、お昼が挟んで13:00から各セッションが始まりました。
当日聞いたセッションは以下になります。

Central Dogma：LINE の Gitをベースにした高可用性サービス構成レポジトリ

Central Dogmaを初めて聞いたことと、サービス構成の話について気になったのでセッションを聞きました。

• 資料: 【B-1】Central Dogma：LINE の Gitをベースにした高可用性サービス構成レポジトリ

Central Dogmaとは

ただググっただけでは、分子生物学の概念のWikiに書かれている堅っ苦しい情報しか出てこなかったので、もしかしてその理論を応用した何かと思いきや、LINEが作ったGit、ZooKeeper、HTTP / 2をベースとしたオープンソースの高可用性バージョン管理サービス構成リポジトリでした。

Central Dogma
line/centraldogma

ふりかえり

• Central Dogmaの紹介
• プロダクトへの導入とその結果について
• 「Apache License 2.0でLINEがOSSで出しているので、みなさん使ってプルリクやissueをください。」とのこと

　

Paying back technical debt - LINE Androidクライアントの事例から - JP

もともとAndroidのネイティブ開発をしていたため気になってセッションを聞きました。
個人的には、今回、一番好きなセッションでした。

資料: 【A-4】Paying back technical debt - LINE Androidクライアントの事例から -

LINEのAndroidアプリについて

このセッションでは、如何に技術的負債を開発フローと一緒に並列でAndroidアプリのLINEに対して実施してきた内容を事例を元に紹介されていました。

• トピック
  • 技術的負債について
  • 技術的負債をどう返したのか

Why do we need to pay back the debt?

どうして技術的負債を返す必要があったのか、例題をもとに話されてました。

• LINEというアプリは、日々アップデートしている。
  • 長い年月をかけて開発・運用がされてきたプロダクトであり、新機能やフィードバックの対応など入るため、追加しやすい、改修しやすい状態にする必要があった。
• イベントリスナーからメソッド管理だけにすることに。
  • イベントよりもメソッドにすることで管理しやすくなる場合もあるということ
• 膨大な機能は、デザインパターンを使ってキレイに管理することに。
• リファクタリングは、開発を継続しながら、リファクタリングを行う必要がある。
• 技術的負債を行うためには、環境づくりから。

What did we improve?

技術的な負債の対応と負債を生まないために取り組んだ改善方法に関して話されてました。

• Code・CI・Teamの環境
  • Code
    • 新しい技術を使う: ReactiveX, data binder, Kotlin
    • ベストプラティクスを参考にしたコーディング規約を作る
    • ライブラリーのラッパーを作る
  • CI
    • コードの変更を容易にする
      • レビューをしやすいようにする: PR comment bot
        • jenkins→job→Github comment API
      • ブランチマージャー
        • Auto Maerge: わざとコンフリクトにする
    • ルールを強制する
      • All code must be tested by QA
        • PR comment bot
    • コードの状態の可視化
      • grable-verions-plugin
  • Team
    • 文化を変える
      • Boy Scout Rule
        • 自分が触る前よりもキレイにして対応を終えるようにすることに
    • 知識や技術の共有
      • テックトークやLTをやっている

ふりかえり

• 技術的負債は生まれてしまうものであるため、どう向き合って対応していくか、チーム内でしっかりと方向性を決めて対処していくこと。
• 一番効果的なことは、環境を変えること。
• 一人ではできないことが多いため、チームで取り組んでいくこと。

　

なぜLINEではウェブトラッキングシステムがフロントエンド開発チームに よって構築されたのか - JP

Webのトラッキングシステムってなんぞやと気になり、LINEのフロントエンド開発チームって何してんだろう？ってことで発表を聞きました。
LINEのフロントエンド開発チームは、アプリ側でWebViewを実装して、WebViewを通してコンテンツを提供している作りをしているとのことでした。

• Agenda
  • Webフロントエンドの背景
  • Webトラッキング開発
  • 活用事例

資料: 【A-5】なぜLINEではウェブトラッキングシステムがフロントエンド開発チームによって構築されたのか

LINEのフロントエンド開発チームについて

• サービス事例
  • NEWS TAB
    • 毎週リリースしている。前日もリリースしていた。
  • COUPON BOOK
    • 海外のある国で起きた不具合
      • Issue of Error Page Displaying In Singapore -> Page Not Found
        • 手元で確認できないエラー
        • エラーログをトラッキングした
        • エラーログの可視化

ある不具合対応でエラーログのトラッキングをやったことで、Webトラッキングシステムを作ることになったとのこと。

Webのトラッキングシステムの事例について

• LINE Analytics
• Mochigome
  • kibanaを使っていたがデメリットがあったため、社内ツールを作った。
  • 8月のインターンに大きく貢献してもらった

ふりかえり

• あまり効かなかったり使ったことないサービスを使ってトラッキングシステムを作られていた
  • Kibana・fluentd・kafkaなどを知ることができた
• 不具合を手元で再現することができない問題に対して別の視点から考え取り組んだ
• 厄介ごとほどツールを作る
  • 他プロダクトへにも導入し、会社全体的をよくすることも視野に入れて取り組む。

　　

動画を見ながらトークできる PIP機能の開発について - Ja

LINEの動画周りの扱いについて何か吸収できたらと思いセッションを聞きました。
PIPとは、LINEアプリの中で動画を開いた時に小さいウィンドウにするなどの機能をライブラリ化したやつで、その紹介と発生した問題の解決方法について発表されてました。

資料: 【B-4】動画を見ながらトークできるPIP機能の開発について

LINEのiOSアプリについて

• リリースは2011の1月
• 言語について
  • 70%: Objective-C
  • 30%: Swift
• 開発拠点
  • 日本、韓国、台湾、中国
• ツール
  • Git submodule/CocoaPods/Carthage

PIPについて　

Picture in Picture(PIP)は、チャットルーム内でチャットしながら動画を観れる機能である。

• iPad(iOS9)でしか公式APIがなかったため、iPhone用に作った。
• PIPの開発とリリース状態までに2ヵ月弱かかったとのこと
• 動画や画像の利便性を上げたい
  • 動画を見ている時にトークが飛び交う
• 動画の画面を小さくしたウィンドウで動かせる
  • Youtubeですでに実装されている機能

Implementationの実装

PIPのView周りの実装に関して

• Create PIP ViewController
  • 動画の画面を小さくしたウィンドウ
  • PIP presentable protocol
  • from Swift 3.2
  • Choose PIP size
    • 動画のサイズによって的確にリサイズする機能
• Create Container ViewController
  • PIP ViewControllerを乗っけるためViewで目には見えない一番上にあるレイヤのViewController
  • PIPLayerViewController
  • overlap PIPLayer
    • LineRootViewController
    • 正統的な作りにしているとのこと
    • チャットとリストにPIPLayerViewControllerを適応させるためのコントローラ
• Create PIP display logic
  • Calling PIP
    • LineRootViewControllerにPIPLayerを渡してPIPLayerViewControllerに渡す仕組み

AudioSession managementの実装

開発期間が一番かかった、約一ヶ月半ほどかかった、ここが一番時間がかかって辛かったとのこと。
そもそものAudio管理が1対nで直操作する作りになっていたため、PIPの仕組み上、チャットも行いながら動画を観たりするケースがあるため、今までの管理方法ではいろんな問題が発生してしまうことがわかったため、まずは、Audio管理からアップデート作業に入ったとのこと。

• Update AudioSession Management
  • Status管理で優先順位や音声制御を管理するコントローラーを作った
  • メリット
    • VoIP依存性を減らせた
    • 新しいオーディオ機能の追加を容易になった
    • 状況をよりよく予測することができる
  • 実装上の問題
    • Stateリークリスク
    • AudioSessionを変更するその他のプロジェクト
    • AudioSessionの無効化
• AudioSession Management（1ヵ月半かかった）
• Update AudioSessin management
  • Create a middle layer
  • AudioSessionState: ステート管理にした、そこで3つの問題が発生。
    • State leak risk
    • Other projects modifying AudioSession
    • Deactivationg AutioSession
      • Give up on deactivation: 別で問題発生...
        • BGM does not resume after VoIP ends
        • Features that do not generally stop the BGM end up stopping the BGM
  • このように問題が多数
  • オプションと条件時によって初期化などを入れた

まとめとして

• ViewControllerの構成を変えた
• PIPのViewControllerを作成
• 中間管理のクラスを追加した
• 問題解決のためにオプションを追加

　

LINE Login - new features and mechanism - JP

LINEのログインがどういう実装をしているのか気になったのでセッションを聞きました。
基本、OAuth 2 protocolとのこと。

資料: 【A-7】LINE Login - new features and mechanism

• 2015〜2017の間に大きく6回のアップデートがあった
• これまでのLINE Loginはセッション管理などなく、毎回ログインする手間があった。
  • そのため、毎週、ユーザー視点からどのようなシステムが一番好ましいのか議論が絶えなかったとのこと

ログインのセッション管理

新しいエンドポイントから使える機能

• Auto Login
  • 今までは、各デバイスでログインしようとした時に毎度ID/PASSが必要だったところを、1回ログインするとどのデバイスでログインしたのかセッションセッション管理され、2回目以降はAutoログインとなる。
• Active Sessions
  • ユーザーは、ログイン後にメニューからログイン状況の一覧を確認することができて、Autoログインの設定を制御することもできるようになったとのこと。

Bots

ボットは、emailよりもボットの方がリンククリック率が4倍もあるとのことでした。
新機能の話がありましたが、まだ使えないとのことで後日アップデート予定の話でした。

また、ボットがもっと扱いやすくアップデートがあっているとのこと。

OpenID Connect

ユーザー情報が欲しいケースがあるものの、親密な情報であるため権限問題があった。
そこで新しいログインのAPIでトークン取得時にIDトークンが発行され、そのIDトークンで新たに親密な情報（電話番号やメールアドレスなど）を取得できるようになったとのこと。

ふりかえり

• LINEのログインAPIのアップデートがあった
• ボットがもっと扱いやすくなって増えていっている
• もっとLINEのサービスを活用しよう！という感じがした

　

Parallel Selenium Test With Docker - En

dockerをパラレルで、しかもテストに使っているってなんだ！！？って気になってセッションを聞きましたー
登壇者は、台湾のQAエンジニアでLINE NOWを担当しており、主に以下のツールを使って仕事にしているとのことでした。

• Selenium Test
• Docker

資料: 【B-6】Parallel Selenium Test With Docker

Selenium WebDriver

Seleniumが各ブラウザへのテストをサポートしており、1回のテスト項目を各ブラウザで実行する機能を紹介されていました。
これによってテストのコストを抑え、無駄なくテストができる点を強く伝えていました。

テーマに書かれているパラレルとは、テスト項目は複数あるため、それらを並列に各ブラウザでテストするためパラレルという言葉を使っていました。
※図が資料にあるため詳しくはそちらを

その中で

• Test Runner Server
• Selenium Grid Server

の2点をDockerにして管理したとの話でした。
これによって無駄ない管理とDockerを知っていれば誰でも管理ができる的な話が上がっていました。

Selenium + Docker

この連携では、Build→Ship→Runの流れで説明がありました。
Dockerfileにライブラリの依存関係やSelenium、Test Code/Dataなどを管理し、Jenkins Slaveとしてコンテナを構築していた話でした。
また、これら全体のパイプラインの図があるため、詳しくは資料を見てください。

Zalenium

次にZaleniumについて以下の3つで説明がありました。

• Selenium Grid Extenision
• Create Node On Demand
• Video Record

Zaleniumは、Seleniumが各ブラウザにテストを実行させている大枠に位置する監視的なツールとして紹介されていました。

ふりかえり

• SeleniumとZaleniumを知ることができた
• Selenium + Zalenium + Docker + jenkinsを連携させて効率よくテスト運用する全体図を知ることができた

　

セキュリティのためのデータ分析 / ログ分析プラットフォーム Monolith と LINE Spam対策の現状 - Ja

セキュリティとデータ分析についてどういう話があるのか気になってセッションを聞きました。
ここでも、Kibana,hadoopが出てきて、logstash,elasticも出てきました。

資料: 【A-9】セキュリティのためのデータ分析 / ログ分析プラットフォーム Monolith と LINE Spam対策の現状

セキュリティ関連の取り組みについて

攻撃の分析と可視化の対応、そして実際にあった攻撃をすぐにLINE NofityでLINEグループに通知するようにして対応したとのことでした。

Monolith

• 各環境ごとにログが保管されている、これらを1つにまとめることが考えられた。
• ログを収集する環境に作り変えた。
• SSHアクセスを気をつけることにした。
• Monolithにログを全て管理し、可視化して管理画面で確認することで柔軟対応ができる。
  • ただし、ダッシュボード(管理画面)で確認するのは人間で、限界があるため、人間以外の領域を管理するために対応を考えた。
• ElasticsearchがMachine Learningをサポートしたためフル活用した。
• Machine Learningを使うことで高性能な通知が実現できた。
• 自動的に不正なアクセスを対処したり、自動的に不具合対処ができるように、Orchestration型を目指している。

スパムについて

• 日本と台湾のスパムが多い、この２点に絞って対処を考えた。
• 国によってスパムの傾向が異なるとのこと。
• LINEでブロッグするだけでは、スパム対策ができない。
  • 現在、電話番号とfacebookアカウントでLINEアカウントが作られているため、対処が難しい。

スパムの分析と対策

• ビックデータやkafkaからのデータを元にPythonで解析し、Logstash→Elasticsearch→Kibanaを連携させて分析と可視化を行なったとのこと。
• Blocing Flow
  • Rule-based Filter
  • ML-based Filter
  • Monitoring System
• ML-based Filter
  • 本当のスパムのブロックと間違ったブロック、嫌いになってあるアカウントをブロックしたなどが考えられるため、ある条件でスパムかそうでないかを振り分ける作業を行なっている。ここにはMachine Learningをもとに、毎度学習しながら制度を高めた。
• Monitoring System
  • 80~90%は自動で10~20%は人間が対応している。
  • 間違ってユーザーアカウントを排除しないことを注意している。
  • スパムアカウントの排除を逃しても問題ないとしている。

まとめ

そもそもの目的が、スパムを全滅させる的なことではなく、スパムは必ず出てくる問題であることから、自動でスパム対策の運用化を目指したとのこと

　

BOT and the new Comfortableness - Ja

去年も参加したのでボットの最新情報や状況が気になってセッションを聞きました。
去年、マイクロソフトのエヴァンジェリストでlinedevdayに参加していたが、今年転職してLINEのエヴァンジェリストになった方が登壇されていました。

Messaging APIの使用で、130,000Botsの成果が上がったとのこと。
また、20万人のユーザーがBotを扱っていることで、100万人のユーザーがBotにメッセージしている結果も出ているとのことでした。
まだ決定でないものの、Bot Awards 2が楽しみ。

資料: 【A-10】BOT and the new Comfortableness

アップデート

Messaging APIの機能の紹介から次のバージョンから機能追加される紹介がありました。

• Messaging API with LINE Login
  • Auto Login to Web with LINE Login V2
• Group member IDs/Profile
  • Using UserID in a Group Effectively
• Flexible Rich Menu
  • リッチメニューのサイズ変更ができるとのこと
  • 画像でメニューのカスタマイズができるようになるとのこと
• Rich Menu API
  • ユーザーの状態に応じてメニューを変更する起動が追加されるとのこと
  • キーボードの制御ができるようになるとのこと
• LINE Developers（管理画面）がアップデートしたとのこと

Communication Ready

SDKとかAPIとかをGitで公開しているからissueやプルリクくれって話でした。
あとは、LINEはこれからももっといろんな開発者とコミュニケーションをとって、世界をもっとより良い環境にしていきたいという話もしていました。

感想

ほとんど去年発表したMessaging APIとBotの状況とこれからの話でしたが、最後のLINE API Expertの話でLINEの今後の動きについて話されていました。内容は、これらの提供を元にもっと良い製品にしていきたいからフィードバックを待っている的な話でした。会社の技術がOSS化しているようなイメージですかね。

あとは、依頼をくれれば状況に応じて対応していくから、例えばC#のSDKが欲しいならissueでくれれば対応するからって話をしていました。この動きは関心でした。公に話すってことは、それだけの対応力・技術力にはLINEにはあるって言ってたようなもんだし、BotAwardといったハッカソンイベントを定期的に開催していくことで、もっと使ってもらって、ダメなところを見つけて出して、もっと良い製品にしていくからって流れをすごく強調していて、今の日本の企業にはなかなか無い取り組みでやってる会社だなぁと実感しました。
　

---

Closing Session

LINE DEVELOPER DAY 2017 Closing Session

最後に新しいオフィスの話や新しい取り組みなどの話でイベントが終わりました。

ふりかえり

全体的に通して見ると参加してよかったイベントでした。
気になるセッションで新しい技術を知ることができたこと、LINEが早いスピードでいろんな取り組みをやっていることを知れて楽しかったです。
フラストレーションとモチベーションが一気にたまりました笑

Colovaは、去年のLINE Developer Dayの準備していた9月ごろからプロジェクトができたとのことで、まだ1年でここまでの製品に仕上がって出せたと話がありました。
まだまだやることはあるけれど、それらは開発者とともに良いものにしていきたいと話していました。

個人的にまたBotで何か作っていこうと思いました。
まずは自分が日常的に役立って欲しいと思えるものを作って、それを公開してブログにしていければなと考えているところです。

また来年も参加したいー