やらなイカ?

たぶん、iOS/Androidアプリの開発・テスト関係。

Unityアプリを受託開発するときのライセンスとディレクトリ構成について

Unite Tokyo 2018のユニティ・テクノロジーズ・ジャパンさんブースで聞いたことのメモ。勘違いしていたので聞いてよかった。

受託開発の場合、受託開発する側は当然Unityライセンス必要として、顧客が納品されたアプリをApp Store等でリリースするケースで、顧客に何を買ってもらえばいいかの話。

Unityライセンス

原則は

「Unityライセンス(サブスクリプション)は、エディタを開いたりビルドしたりするのに必要」

とのことなので、

  • 受託側がビルドしたアプリを受け取って公開するだけなら、顧客(パブリッシャー)はUnityライセンス購入は不要
  • 受託側からソース(Unityプロジェクト一式)を受け取るとしても、Unityエディタで開いて検収・ビルドしないのであれば、Unityライセンス購入は不要
  • ソースをUnityエディタで開いて検収・ビルドする場合でも、エディタを使う期間だけサブスクリプションしていればよく*1サブスクリプションが切れてからもApp Storeに公開し続けて構わない

Asset Storeで購入したアセット

  • 納品物にソースとして購入したアセットを含めるのは再配布として扱う。再配布の扱いは各アセットのライセンスによる
  • 購入したアセットは除外して納品したとして、納品後、顧客側で個々のアセットを購入するタイミングでアセットがバージョンアップされている場合がある。Asset Storeから過去のバージョンのものはダウンロードできない点には注意

ディレクトリ構成の例

Asset Storeで購入したアセットを隔離する必要は感じていたので、以下のようにしています、という設定例です。以降はUnityさん推奨というわけではないのでご注意ください。また、後述しますが完全なものではないので、いいアイデアがあればぜひ教えてください!

Unityプロジェクトのディレクトリ構成

まず、プロジェクトのAssetsディレクトリ下に自社開発分を隔離するディレクトリを切ります(以下MY_PROJECT)。この下に、Editor, Prefabs, Scenes, Scripts, Tests*2など必要に応じて配置していきます。

Asset Storeや.unitypackageファイルをインポートしたものは、Assets/直下に配置ます。ディレクトリ名で別れてくれるものが大半ですが、EditorやPluginsの下に置かれるものもあるのでまとめて除外するためです。

.gitignore

.gitignoreファイルのベースを取得します。

$ curl -o .gitignore https://raw.githubusercontent.com/github/gitignore/master/Unity.gitignore

これに以下を追加します。

# PlayMode testing cache(たぶん)を除外
Assets/InitTestScene*.unity*

# 公開 or 納品するものであれば、自身のプロジェクト以外のAssetsを除外
/Assets/*
!/Assets/MY_PROJECT*

MY_PROJECTの後ろに/をつけてしまうと.metaファイルが漏れるので注意。

またもし、Assets/Editor/下やAssets/Plugins/下に置いているファイルがあれば、個別に除外指定(!ではじまる行)を追加してください。

課題

この方式では、以下の課題が未解決です。

  • リモートリポジトリをcloneしてそのままビルドできない。これはCI(continuous integration)を使用するときに致命的です。
  • Asset Storeからインポートしたアセットに独自の修正を加える場合。MY_PROJECT下に複製して修正するなどできますが、ライセンスを考えると問題ですし、差分に気づかない恐れもあります。
  • Assetの設定を自身のフォルダ下に格納するタイプの場合。EasySave2とか、Cross-platform Native Pluginsとか。これも差分に気づきにくいのがつらい。

このうちCIについては、開発機にあるフルセットのプロジェクトをUnity Collaborateに上げて、Unity Cloud Buildでビルドする方式を取っています。一人でやっているので大丈夫なのですが、チーム開発だと厳しい運用だと思います。

*1:とは言え最短1年ですが

*2:EditMode Testsだとprivateメソッドを直接呼べなくてストレスなのでPlayMode Testsを使っています

SRE-SET Automation Nightに行ってきました #automation_night

メルカリさんで開催された『SRE-SET Automation Night』に行ってきました。

この勉強会は、SRE(Site Reliability Engineer)およびSET/SWET(Software Engineer in Test)な人を対象をした、"自動化"にフォーカスしたもの。

connpass.com

以下、雑なメモ。

Data processing, workflow and us ~How to manage automated jobs~

speakerdeck.com

  • @syu_creamさん。メルカリのSREチーム
  • ログをBigQueryに送る部分を改善
    • fluentd
    • 当初、シェルスクリプトとcronで実現。途中経過が見えない、エラー時の再実行が困難などの課題
    • 会社の成長にともなってログも大きくなってきたので改善したかった
    • 改善
      • Digdagを利用。ジョブの進行をビジュアライズ、再実行が容易に
      • ログサイズを事前にsplitするようにした(upload前でなく)
  • 統計
    • オンメモリ処理だとメモリがつらくなってきた
    • シーケンシャルに実行していたが時間がかかるので並列化したい
    • 改善
      • Full managed ETL(extract, transform, and load) serviceを使う
      • Apache Airflowでジョブ管理

レビューのコストを削減するための施策

www.slideshare.net

  • @tarappoさん。DeNAでSWET、iOS/Android Test Night主催
  • レビューのコストが高いので、できるだけ機械に任せたい
  • レビュー対象は色々あるが、今回はテスト観点のドキュメントの話
    • ここで言う「テスト観点」は、対象プロジェクトにおいてテストで確認すべきポイントを機能単位にまとめたもの
    • QAが書いている
    • GitHubを使い、Pull Request(以下PR)でレビューを行っている
  • 運用の問題。コメント数が最大174のものもできた
    • 指摘を修正されてもチェックしきれない
    • レビュアーとして途中参戦したくない
    • どのPRをレビューすべきか判断できない
  • PRの内容が記載されていない、タイトルにWIPがついたままでレビュー依頼されるのが一因
    • Dangerで事前チェックすることで回避
  • 文書の問題はtextlintでチェック
    • 対象プロダクトの固有名詞辞書で表記ゆれのチェック
    • ですます調、である調、弱い日本語の禁止(〜かもしれない、〜と思う)
  • PRの前に各自textlintを流す(必須ではないけど、ほぼやってくれる)
  • PRのコメントに"review"と書く → CIでtextlintとDangerが走る → okならレビュアーにmentionが飛ぶ
    • JenkinsのGitHub Pull Request Pluginで、特定フレーズでキック
  • Danger
    • 内容のチェック
    • タスクが全て完了しているか、textlintが通っているか
    • 最終コミットがgreenになっているか
    • 通ると、ラベル"In Review"がつく
  • 導入後、表記ゆれ、typoが減った。PRが見やすくなった
  • 今後の課題
    • 辞書の登録が面倒
    • 定量的評価をしたい
    • レビュアーの選定を自動化したい(集中しないようにしたい)
    • API Docに適用できないか
    • Jenkinsからの脱却

Reliable Mobile Test Automation

www.slideshare.net

  • @vbanthiaさん。DeNASWT→メルカリでSET
  • Appium Docker DemoとかSTF Appium Exampleとか公開
  • Test Automation Lift Cycle
    • モバイルにおいて、自動テストだけを信じてリリースできるか?(会場では自動テストをやっている人は多かったが、信じられるか?の問に挙手した人は1人だけ)
    • 機能が増えてくるとQAチームがパンクする。振り返りで"We need automation!"となる
    • Development Teamから分割してSET/SWETなどに分けるケースが多い?
  • ツール選定・導入は比較的簡単にできる
  • たくさんテストを書く
  • そのテストをリリースまで使うのが難しい。問題になるのは、
    • Flaky tests(不安定なテスト。様々な要因で成功したり失敗したりするもの)
    • Test execution environment(実機を含めたテスト実行環境)
  • 結果、テストが信じられない。使われなくなり、メンテされず、捨てられてしまう
  • Flaky Tests
    • 原因として
      • User interface issue
      • Backend issue
      • 3rd party service issue
      • Hardware issue
    • problem is not flaky test. 問題は、テストがflakyなことではなく、テスト実行中に何が起きたか我々が知らないこと
    • 対策は"Record everything!"
      • Screenshots, Video
      • ADB logs
      • Timestamp of each UI action and test assertion
      • Test script logs
      • Appium logs
    • レポートの改善
  • Test Execution Environment
    • Cloud Serviceが使えればベスト、誰でも使える環境
    • 以前の発表、"Android e2e testing at mercari"を参照
    • Google Cloud Storageにapkをuploadして、DockerでOpen STF、Circle CIでDocker imageビルド、テスト実行
  • デモ
    • Slack上の対話Bot(名前は"BB-8")で実行できるようにしてある
    • UIで、ビルド番号、複数のデバイス、複数のテストケースを選んで実行できる
  • Mobile test automationはチャレンジングだが不可能ではない

Magic Podの活用を具体的に考えてみた

www.slideshare.net

  • 戸田さん
  • Magic Podについて、Selenium IDEを使っていた層に向けたもの、という印象を持った
    • コード書ける人、Excel+手動テストの人、という人たちがいて、その中間の層
  • アプリが完成してから自動テストを作るのでなく、ワイヤーフレームから仮のテストケースを作っていけばQAも並列作業できるのでは?
  • CLIもある。Travis CIでは検証した(TRIDENTさんのブログで公開)。Circle CIは検証中

Prometheusを導入した話

セキュリティ強化のための自動化

speakerdeck.com

  • @manabusakaiさん
  • freeeでは人やお金に関する情報を扱っている。情報漏えいは厳禁だし、よく攻撃もされる。
  • 1,000台のサーバをSRE 3人で見てるので、自動化で対応
    • セキュリティパッチ、すぐ適用したいけど難しい
    • 外部からの怪しい攻撃は自動的に遮断したい。攻撃されてから気づくことが多い?
  • CodeBuildを使いAMI作成
    • Golden AMI方式
    • 以前は、脆弱性が発見されると手分けしてやっていた → CodeBuildでPackerを流す方式に
    • 1コマンドだけ投入、並列実行できるので1hくらいで全インスタンス入れ替えを完了
  • AWS WAFを使った攻撃の自動遮断
    • 攻撃側のIPアドレスは頻繁に変わるので、security groupなどでは対処しきれない
    • ロードバランサにAWS WAFを導入、DoSっぽいアクセスがきたら、403を返してくれる
    • LBで遮断できるのでWebサーバの負荷は上がらない
    • 一次対応がこれでできるので、他の対処が必要な攻撃であっても人間は余裕をもって対処できる

1人インフラ運用チームで、自動化の作業時間を確保するためにやっている(た)こと

speakerdeck.com

Automation基盤提供のしかた

  • @tnirさん
  • 実行履歴が取れることが大事
  • 実行タイミングを制御できること
    • ナイトリービルド
    • マニュアル実行
    • イベントドリブン
    • 自動再実行、マニュアル再実行
  • 実行命令系との連携
    • dev: SCMとの連携
    • ops: Infrastructure as Code
    • ジョブと変数の分離
  • GitLab CI/CDを使っている
  • 社内への普及活動
  • 業務上は困ってないが、デザイン/パフォーマンスには課題。ほかも検証してみたい

所感

会場にSREな人は少なかったようですが(私も門外漢ですが)、"自動化"というキーワードでくくって広範囲な話が聞ける機会となり、とても面白かったです。

いずれも、導入から運用、改善のスパンが長くなる話なので事例そのものが貴重ですし、かつ今回は単に「試してみた」「導入してみた」を超えた話が聞けて大変ありがたいイベントでした。

第2回以降も(自動的に!)開催されそうな方向なので、期待して待ちます。

システムテスト自動化カンファレンス2017-2を開催しました #stac2017

ヤフー株式会社さんで開催された、テスト自動化研究会の旗艦イベント「システムテスト自動化カンファレンス2017-2」にスタッフとして参加してきました。

testautomationresearch.connpass.com

通算5回目、年1回の開催ですが、昨年分が15月にずれ込んでしまったため「2017」と銘され、今回が「シン・2017」ということになります。まぎらわしくてすいません。

今回はチュートリアルのTAとしてお手伝いしたため余り講演は聞けなかったのですが、今回からはじめた公募セッションやLTが入ったことで、扱う幅が広がったように思え、有意義なカンファレンスであったように思います。

Magic Pod チュートリアル

チュートリアルはキャンセルも出て想定より少ない人数での開催でしたが、その分TAの目が届きやすくなり*1、ほとんどの方がInstagramアプリを題材にした実践課題*2まで完遂できたようで、正直ほっとしました。

内容は、モバイル向けテスト自動化ツールであるMagic Podの使いかたを紹介するもので、これはappium導入のハードルとなっている「操作対象のUI要素を指定するためのロケータの検出」を自動化し、また、テストケースを(テストコードを書くのでなく)ブラウザ上のマウス操作で作成・実行できるというツールです。

Magic Podは無料で使い始めることができますので、興味を持たれた方はぜひお試しください。

www.slideshare.net

講演資料

以下、拾えた範囲でスライドを。追って、テスト自動化研究会の"イベント&アーカイブ"のページにレポートが出るはずです。

テスト自動化と機械学習(STAR機械学習分科会紹介)

TODO: 公開されたら貼ります

翻訳者の同僚が語る「初めての自動テスト」

www.slideshare.net

9月に発売された書籍『初めての自動テスト』について、翻訳者の玉川さんが本日来られないとのことで、同僚である太田さんによる講演。

書籍はこちら。

初めての自動テスト ―Webシステムのための自動テスト基礎

初めての自動テスト ―Webシステムのための自動テスト基礎

GebとSpockではじめるシステムテスト自動化

www.slideshare.net

楽天のレジャー・サービスにおける自動化の取り組みとその効果

www.slideshare.net

How we automate E2E tests at Mercari

TODO: 公開されたら貼ります

TypeScript + PhantomJSを利用した効率的なテスト実施

speakerdeck.com

SI-Toolkitでテスト自動化を実現する現場で遭遇した出来事

www.slideshare.net

自動化困難な状況での活動方法

www.slideshare.net

LT

テスト自動化の前の1.5年にやったこと

楽天の荻野さんのLT。タイトルはうろ覚えですすいません。

レガシーなシステムにテスト自動化を導入したときの、スクリプトを書く前に実施した、開発基盤の整備やQAマネージャのレベルアップといった施策の紹介。それらを整える期間は目に見えた進捗は少ないが、「あとはスクリプトを書くだけ」になってから一気に自動化が進んだ、というお話。

IoT基盤を活用したテスト時間の短縮

折田さんのLT。自動テストを実行するためのPCをたくさん積むという話をよく聞くが、PCはテスト対象の動作待ちがメインなのでスペックは低めでよく、むしろ夜間に通電したまま放置できるものが望ましい、そこでRaspberry Piを使う、というお話。

スタッフ反省会で実機(名前がR2-D2とK-2SO!)を見せていただきました。次は動いてるところが見たい!

テストも開発もするモバイルエンジニアのためのXCUITest/Espressoのすすめ

speakerdeck.com

appiumのメリットは語られるけど、実際にはそれほど楽に享受できるわけではなく、それならばiOSはXCUITest、AndroidはEspressoを使うほうが便利、というお話。

ちなみに私は、開発者テストとしてのIntegration Testingであれば完全に同意。システムテストとして、End to Endとして、という話になると、やはりappiumなどでリリース向けのパッケージ(ipa/apk)をテストすべきかな、とは思います。割り切りですが。

フォローアップのエントリはこちら。

woshidan.hatenablog.com

gaugeによるe2eテスト

テスト自動化ツールGaugeの紹介

テストケース構造をモデル化しよう!:テストカタマリー紹介

www.slideshare.net

*1:逆に介入が多すぎたと感じた方がいたら申し訳ない

*2:ログイン・ログアウトだけでも色々な振る舞いがあって複雑なのです

DevFest Tokyo 2017に行ってきたメモ #DevFest17

10/9に開催されたDevFest Tokyo 2017に行ってきたので、雑なメモ。

f:id:nowsprinting:20171009204630j:plain
会場で写真撮ってなかったので、途中にいたユニコーンガンダム

Tangoで踊らされたオトコがARCoreと向き合う話

  • Tangoではdepthセンサー必須だったが、ARCoreでは普及機のカメラで実現できるようになった(iOS 11のARKitに追随した形)
  • 3本柱
    • モーショントラッキング
    • 水平面の推測 (Environment understanding)
    • Light estimation
  • 画像解析にによる推定
    • TangoではToF(time of flight)
  • Tango → ARCoreで難しくなったこ
  • アプリの開発は、Android Studio 2.3, Unity, UE4
    • API Level 24以上
    • 描画はAndroidネイティブではOpenGLとかになるので、Unityなどを使うほうが楽
  • 実行環境(端末)に、ARCore process appをインストールする必要がある
  • Devices: Pixel XL, Pixel, Galaxy S8
    • Pixel 2/2XL
    • ほかの機種で動かす試みをしている人はいる
  • UX: ARのソリューションでなく、モバイルのソリューションであることを意識したい
  • JAG ARCore(Tango) Working Group - Google+

developers.google.com

github.com

React Nativeアプリをリリースし続けるために、最初に行う8つの取り組み

www.slideshare.net

  • 開発部分はJSにひとでもできるが、一部、Google Play, Xcode, iTunes Connectなど、ネイティブアプリ開発の知見が必要
  • ネイティブのノウハウが必要なところ:設計〜開発の継ぎ目あたり、リリース〜保守
  • init後の作業
    • src/index.jsを作る。ios_index.jsとandroid_index.jsには、import".src/"だけ書く
      • 0.49でそうなったので、0.48以前の人向け
  • application id(Android) , bundle identifier(iOS)
    • init直後は適当なものが入っているので必ず変更する
  • version
    • Semantic Versioningを採用している
    • プラットフォーム間でバージョン番号をそろえるか?
      • そろえたほうが楽、という運用になった
        • リリースノートの書きやすさ
        • Gitのタグ付け
      • package.jsonのversionを元にコピーしている
      • Google Playの制約。version codeは加算のみを許す
        • major+minor+patchを組み立ててGradleで自動生成する案
          • Google Playにアップロードしなおすために都度patchを上げる必要がある
          • 代替案:major+minor+patch+buildという構成(2.1.3-build4 → "2010304"とか)
  • build types
    • デバッグビルド(同じapplication id)を同じ端末にインストールしたい
    • アイコン、表示名も分けないと見分けがつかないので、適切に設定する(スライド参照)
  • 運用に便利なツール
    • Fabric/Crashlytics (JSのエラーは見えない)
    • Fabric/Beta
      • AS plugin/Mac appからリリースできる
      • Google Play/ iTunes Connectでもベータ配布はできるが、タイムラグがあるのとバージョンを上げる必要があるため
      • Deploy Gateでもいい
    • faselane
      • gitにtagをつけてpush → CIサーバがfastlaneでリリースタスクを実行
    • Firebase
      • アナリティクス、ストレージ、ABテスト、プッシュ通知
      • アナリティクスのためだけに使ってる
  • JSのクラッシュレポート
    • Sentryを使う

iOS版でアイコン切り替えができていない、というお話でしたが、デバッグビルド向けのビルドターゲット作り、そこでリリース版とは別のinfo.plistを指定、その中の記述を分けることができます。『iOSアプリテスト自動化入門』のChapter 6「ビルドと配布の自動化」に書きました。

iOSアプリテスト自動化入門

iOSアプリテスト自動化入門

Goによるプロダクト開発 〜設計、テスト、Go2に向けて〜

  • GAE/Goのaetestが遅い件
    • Travis CIからCircle CIに移行して少し早くなった
  • package構成
  • 実装の歴史的経緯を伝えるためにもペアプロは便利
  • 鵜飼さんのスライドを読む
  • 正規表現使いすぎない、map使いすぎない(LLの習慣でやりがち)
  • aetestが遅いので、テストを増やすと遅くなるので余り書けていない
  • メルカリUSはカバレジ80%くらい
  • AWAも80%くらい
  • テストを書いていくといい設計になる
  • Go2

FlutterでAndroid/iOS両対応のアプリ開発

speakerdeck.com

github.com

Unreal Fest East 2017に行ってきたメモ #ue4fest

10/8に開催されたUE4のイベントUNREAL FEST EAST 2017に行ってきたので雑なメモ。主にVR系セッションを聴講してきました。

f:id:nowsprinting:20171010070858j:plain
会場で写真撮ってなかったので、クイーンズスクエアにオープンしていたSHAKE SHACK

「VR ZONE SHINJUKU 極限度胸試しハネチャリ」ゲーム会社×映像会社で作るヤバイVR体験

「VR ZONE SHINJUKU」の知見、全て吐き出します!

  • 釣りVR
    • 「釣った」と「釣れた」は大違い。ほとんどの釣りゲームは技<運
    • 技>運にすると、インタフェースが増える(感覚を数値化する必要があるので)
    • 立つ、しゃがむがゲーム性に直結
      • しゃがむと有利だが、反射で水中が見えない。立つとバレやすい等
  • 恐竜サバイバル
    • やりたかったこと:多人数で、人間同士の協力や裏切り
    • 可動ベースでも酔う。ヨーイングをなめてた
      • 速度が遅いほど悪化
      • 障害物が近いほど悪化(ジャングルは最悪のシチェーション)
    • ボトムズの知見:暗くして、障害物を減らし、被写界深度を狭めることで酔いを回避
      • これを適用したら、マップがほとんど見えない、迷うようになった → ルートを一本道に変更
    • 8人でやると楽しくなってしまった → バラバラに → 脱出病棟みたいな体験になってしまった
  • ハネチャリ
    • 空を自由に飛べるようにしたが、物足りない(つまらない)
    • 顕在しているニーズ:空を自由に飛びたい
    • 潜在しているニーズ:人間は飛べない
      • スタートを一本橋にして、飛べない(落ちる)ところからスタート。これだけで以降のシーンの印象が変わる
      • 反射行動(条件反射、無条件反射)で動かす。あとから感情がついてくる
      • 油断するとちゃんと墜落する仕様
    • リアルだから取り乱すのではなく、取り乱すからリアルに感じる
  • マリオカート
    • 既存ゲームのVRアクティビティ化
    • 1〜2ヶ月でとりあえず動いたが「これでいいのか?」
    • VRアクティビティ化への3レイヤ
      • UE化
      • VR化(酔い対策)
      • 取り乱す化(体験デザイン) これをVR化とは分けて考える
    • UE化:解像度足りない → オリジナルエンジンからUE化。実在感への寄与は大きかった
    • VR化:主観視点化+体験の快適さ確保
      • ジャンプしてドリフト、水中で画面がゆがむ等は酔うので削除
      • 周回コースにはしない(ヨーイングを避ける)、急カーブは作らない
      • アイテムを当てた側がら見えるヒットリアクションは派手に、でも当てられた側は視点は変えずカートだけ回転
        • これでは当てられたほうが気づかないので、視界が炎上するようにした
      • 体感マシンで帳尻合わせ(映像でできるだけやった後)
    • 取り乱す化:既存ゲームだと特に、体験の想像がついてしまう
      • 体験デザイン、絶叫体験
      • すでにできている「遊び」「仕様」「データ」を変更する注文になるので、開発チームには嫌がられる
      • 「信じさせる」
        • 自然に行動できる → 世界を信じられる
        • 違和感行動は、夢から覚めるきっかけ
      • 「叫ばせる」
        • 実際にあのコースを走ったら、とんでもない体験に
        • 巨大なやつが襲ってくる:パックンフラワードッスン
          • 十分に予感させないと恐怖は発生しない → 遠くから見える、地面がえぐれているなどで、手前から恐怖をあおる
        • ジャンプ台は、一旦、自由落下で落とす(すぐにカイトを開かない)
          • あらかじめ、カートの重さを信じさせる。スタート直後の段差で落ちる、クッパの体当たり
      • 風船にぶら下がるアイテム、ハンマーで直接叩く動作
  • 絶叫がモチベーションを生む
    • スタッフのモチベーションが高い
    • 接客の自己改善が発生
  • 感情の爆発
    • 号泣などいくつかあるが、そのうちのひとつが絶叫
    • エンタメにとって最高評価

vrzone-pic.com

VRゲーム"Airtone"制作事例 ~VRを活かす3つのゲームデザイン的挑戦~

  • 与えたい体験を先に決める
  • 王道の音ゲー+遊び
  • アウトゲーム(部屋)を先に見る。ここでは実在槓のあるシェーディング、影をつける
  • インゲームはモーショングラフィック系
  • 部屋
    • 壁紙変更、物理を使った遊びなど、おもしろギミック
    • 音の遮蔽をoff。ネオンちゃんの足音など、正しい方向からのみ聴こえるように
    • 部屋のスピーカを部屋の中央に
  • Wwiseを使用している

音ゲー部分のデザインの話は(私の)メモが乱雑すぎたので割愛。講演動画が配信されるはずなので、そちらを参照してください。

store.steampowered.com

www.oculus.com

LINE Messaging APIでグループメンバーのプロファイルを取得する新API #linebot

今年5月、グループ/トークルーム内のトークを発信したユーザのIDをLINE Messaging APIで取得できるようになりましたが、ユーザIDからそのユーザのプロファイル*1を取得できないケースがありました。

新たに7月に追加されたエンドポイントでは、グループ/ルームのメンバーであれば制限なくプロファイルを取得できるようになりました。

過去記事のフォローアップとして、新エンドポイントについてまとめます。

Get profile APIの制約

ユーザのプロファイルを取得するには、GET https://api.line.me/v2/bot/profile/{userId}golang SDKではlinebot.Client.GetProfile())を使用します。

しかし、このAPIでは、指定したユーザがBotと友だち登録した状態でないと404エラー(golang SDKではlinebot: APIError 404 Not found)が返ります*2

グループ/ルームにメンバーとしてBotを追加して運用するケースにおいて、「すべてのメンバーがBotとの友だち登録を必要とする」というのは現実的ではありませんでした。

この(従来の)方式についての詳細は、下記エントリの「プロファイル取得の制限」セクションを参照してください。

nowsprinting.hatenablog.com

Get group/room member profile API

7月に、グループ/ルームメンバーのプロファイルを取得するためのエンドポイントが追加されました(golang SDKへの追加は9月)。

  • グループの場合、GET https://api.line.me/v2/bot/group/{groupId}/member/{userId}golang SDKではlinebot.Client.GetGroupMemberProfile()
  • トークルームの場合、GET https://api.line.me/v2/bot/room/{roomId}/member/{userId}golang SDKではGetRoomMemberProfile()

こちらを使用すれば、友だち登録状況に関係なくプロファイルを取得できます。パラメタとして、対象のユーザIDに加えて、グループ/ルームのIDが必要です。

友だち登録していないユーザ、また、友だち登録後ブロックしたユーザで試しましたが、いずれもこのAPIでプロファイルを取得できました。

簡単な(汚い)サンプルコードを公開していますので、参考にしてください。

github.com

Get group/room member user IDs API

7月の更新では、グループ/ルームのメンバー全員のユーザIDを取得できるAPIも追加されています。しかしこちらは「認証済みLINE@アカウントまたは公式アカウント専用機能」とのことで、未検証です。

参考

関連書籍

LINE BOTを作ろう!  Messaging APIを使ったチャットボットの基礎と利用例

LINE BOTを作ろう! Messaging APIを使ったチャットボットの基礎と利用例

*1:表示名、プロフィール画像URL、ステータスメッセージ

*2:以前は、友だち登録した後にブロックした場合でもプロファイルが取得できていましたが、現在はブロックしたら404が返るようになりました

LINE Messaging APIでグループメンバーへのメンションを送りたかった #linebot

結論から言うと「送れなかった」のですが、調査したことなどのメモ。

メンションとは

ここで「メンション」と呼んでいるのは、グループ/チャットルーム内で、"@"に続いてメンバーの名前を書くと通知が飛ぶ、という機能。

2017年2月にリリースされた機能ですが、LINE公式ブログなどでは正式な名称は書かれていませんでした。Twitterほかにならってメンションと呼ばれているようです。

official-blog.line.me

LINEアプリ上では、下のように青い文字で表示されます。

f:id:nowsprinting:20171001001204p:plain

なお、メッセージ入力欄に「@」と入力すると、メンションを送る候補としてグループメンバーの名前が表示されますが、ここにBotの名前は出てきません。

Botにコマンドを送るときに使えるのでは?と思ったのですが、ダメでした。

Webhookで受け取れるメンションを含むメッセージ

上のような、ユーザからユーザへのメンションを含むメッセージをWebhookで受け取ったとき、その内容は単なるプレーンテキストで

@テスト太郎 メンションのテスト

という文字列が受け取れました。

ユーザ名は、個々のユーザで異なるものに上書きできますが、Webhookで受け取れるものはメンションに指定されたユーザ本来のものです。

LINE Messaging APIからメンションを送ってみる

Webhookがプレーンテキストであった時点で無理そうでしたが、一応試してみました。

まず、"@"に続けてユーザID(golang SDKの場合、event.Source.UserID)を指定したケース。

f:id:nowsprinting:20171001003746p:plain

続いて、"@"に続いてユーザの名前(golang SDKの場合、linebot.Client.GetProfile()で取得したDisplayName)を指定したケース。

f:id:nowsprinting:20171001003803p:plain

ともに、メンション扱いはされませんでした。残念。

関連書籍

LINE BOTを作ろう!  Messaging APIを使ったチャットボットの基礎と利用例

LINE BOTを作ろう! Messaging APIを使ったチャットボットの基礎と利用例