やらなイカ?

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

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さん。DeNAでSWET→メルカリで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を使ったチャットボットの基礎と利用例

Tokyo HoloLens ミートアップ vol.4に参加してきました #HoloLensJP #TMCN

Tokyo HoloLens ミートアップ vol.4に行ってきました。参加するのは通算3回目(のはず)。

hololens.connpass.com

以下、各セッションのメモ。残念ながらLT前に離脱したのでメインセッションのみ。

俺たちが作るべきMR

ゆーじ@yuujiiさんの、例のハッカソンで例のVRアーティスト賞を受賞したHololensを使ったお絵描きアプリにまつわる話。

www.slideshare.net

  • すぐ近くの3Dオブジェクトを描画しない設定であるnier clipについて。HoloLensでは0.85(より近いものは描画しない)だが、ホワイトボードに投影しながら絵を描くという性質上0.3にした
  • 0.3より低くすると、ホワイトボードに近づきすぎてしまいトラッキングを失うため、あえて0.3とした

ARもVRもMRもまとめてドドンドーン!

前本 知志@peugeot106s16さんの、KINECT等を使って位置同期を行なう話。

www.slideshare.net

  • ARアプリでは、3DモデルとKinectが捉えた物体とのzテストでオクルージョンできる
    • 現実ではオクルージョンされるのが当たり前なので、誰もすごいと言ってくれない!(気づいてもくれない!)
  • 複数KINECTでの位置同期
    • GPSと同じ三点測位で、リアル世界にある原点に対する、KINECTカメラの相対位置を求める
    • depthが取れればKINECTでなくてもできる
  • KINECT, HoloLens Tangoで位置を同期する
  • 現実世界を基準に、仮想世界もそこに重ねる。各デバイスは覗き窓となる

多人数同期MR体験を実現するプラットフォームDAHLES

MIRO@MobileHackerzさんの、N高入学式で使用したHoloLens数十台運用プラットフォームの話。

  • 1対nで配信
  • 大域自己位置ポジショニング
    • HoloLensのアンカーの問題点
      • 全端末がspatial mapを持ってないとできない
      • 大規模会場ではdepthが届かない(ぜいぜい数メートル)
      • 似てると間違える。列が一列ずれる。四角い部屋だと90度・180度ずれることも
      • 一度誤認識されると、なかなか再認識されない
    • 可視光マーカーを併用する
      • マーカーで大まかな位置を知り、近くのアンカーを使って精細なポジションを得る
  • 無線ネットワークトラフィック管理・配信コンテンツ管理
    • 輻輳防止
    • 隠れ端末問題
    • ブロードキャストパケットによるイベント同期
    • どうしてもムリなところは無線を強くする
  • HoloLens端末の運用管理
    • アプリケーションのデプロイ
      • Device Portalを使うと結構できるけど、無線は遅いのでつらい
      • USBでもできるようにした
    • 装着オペレーションのサポート
      • 「こう見えていれば正解」という画面を装着案内時に表示しておくのは有効