MANABIYA -teratail DEVELOPER DAYS- 1日目 のメモ取りの記録です。
参加したセッション
- インフラ: AWS上のサービスをスケールする際に取り組むべきこと
- インフラ: 分散処理とコンテナ化インフラの面白い関係
- 生存戦略: テックリード/リードエンジニアとしての生存戦略
- XR: VRのこれまでから学ぶ、VR開発の始め方
- モバイル: CrossSession
- AI: CrossSession
- XR: CrossSession
- LT大会 インフラ/DB
個人的にツボだったポイント
- AWSの通信網の図をもうちょっと眺めていたかった(荒木さんの発表の中で使われた図をみて)
- 田籠さんの発表の分散システムの歴史の説明とコンテナの歴史の説明の絡め方が鮮やかだった
- テックリード生存戦略セッションの締めの増井さんの「技術はあとから追いつけるが、そうじゃないところの積み重ねをいかに作れるか」的なメッセージに深みを感じた
- 「Coding CDN in Money Forward」がLTとは思えない濃さだった
(超個人的)テンションあがったこと
- ネット上で以前から気になってたこにふぁーさん、ばんくしさんを生で見れた(自分の分野的に遭遇機会が今までなかった)
- 生(?)のじゃロリおじさんを見れたこと
- 超熱い人だった
以下、聴講メモです。
インフラ: AWS上のサービスをスケールする際に取り組むべきこと
- 登壇者
- AWS シニアマネージャ 荒木靖宏さん
- サービスをスケールさせる
- これらもスケールだという例
- 新機能追加
- 面倒のアウトソース
- 地理的な拡大
- これらもスケールだという例
- AWSには100以上のサービスが存在
- 「新機能追加」に使えるサービスの例
- AWS Media Services
- 放送品質レベルのメディアワークロード向けマネージドサービス
- 放送向けのサービスを作るときの必要要素
- プロダクションからとってきて、アーカイビングして…
- AWS Media Services
- 「面倒のアウトソース」に関するサービスの例
- AWS PrivateLink
- VPCエンドポイントを利用して、AWSを利用する他ユーザにプライベート接続でサービスを提供できる
- プライベートなサービスを、パブリックIP付けなくても他のAWSに使ってもらえる
- Inter-Region VPC Peering
- 異なるリージョンのVPCをピアリングする
- リージョン間の通信はAWSのプライベート回線。パブリックに出ない。
- Direct Connect Gateway
- 同一アカウントに所属する複数リージョンの複数ロケーションから複数リージョンの複数VPCに接続できる
- AWS PrivateLink
- 「地理的な拡大」に関するサービスの例
- DynamoDB Global Tables
- グローバルでひとつのDBとして使えるDynamoDB
- Multi-Region。どこかひとつのRegionで止まっても大丈夫
- DynamoDB Global Tables
- AWSのリージョン拡大
- 大阪ローカルリージョン開設
- 法令上、日本の中で別のデータセンターに置いて冗長化しなければいけない、というニーズに対応
- 12/12 中国2つ目のリージョン Ningxia
- 12/19 ヨーロッパ4つ目のリージョン Paris
- 大阪ローカルリージョン開設
- AWSのリージョン間の接続
- 冗長化した100GbEのネットワーク
- ファイバ切断してもインパクトがない運用
- (中国を除く)全世界に十分な容量を確保
- 冗長化した100GbEのネットワーク
- AWSのAZ
- AZはデータセンター群。データセンター間をAmazon運用の光回線でつないでる
- 外部との雪像を担うトランジットセンター
- 東京に2箇所、大阪に1箇所
- トランジットセンターに関してはデータをまったく置かず、データが流れるだけの中継基地
- 一般的なネットワークでは、内部ネットワークのサーバ間の通信の速度をあげるのはあまり頑張ってないが、AWSではカスタマイズルータを開発している他、カスタムチップ(25GbE)によりパフォーマンスを突き詰めている
- Everything fails all the time
- 壊れることを前提に、壊れた時にすぐに取り替えられるようなアーキテクチャにしておこう
- 故障しない率(MTTF)よりも、故障したときにすぐ修復できること(MTTR)を重視
- 設計の考え方
- Auto Scalingに対応させる
- リソースの変動を前提とし、自動で対処する
- Ａｕｔｏｍａｔｉｃ Feedback Control
- WAFの運用するときなどで、事前に完璧なルールを準備するのではなく、来たアクセスを見ながらフィードバックかける
- Lambdaなど活用
- WAFの運用するときなどで、事前に完璧なルールを準備するのではなく、来たアクセスを見ながらフィードバックかける
- Continuous Delivery & Test Automation
- CodePipiline,CodeBuild,CodeDeploy
- Gameday Testing
- 非常事態に備えた訓練
- AWSで本番環境を壊れてもすぐ直せるテンプレートを作っておくなど
- CloudFormation
- Error Injection 障害注入
- 意図的に障害を起こさせる
- Netflixの取り組み
- Chaos Monky,Chaos Gorilla, Chaos Kong
- リージョンまるごと意図的に落とすということをやっている
- Netflixの取り組み
- 意図的に障害を起こさせる
- Auto Scalingに対応させる
インフラ: 分散処理とコンテナ化インフラの面白い関係
- 登壇者
- Treasure Data, Inc. 田籠聡さん
- 発表資料
- 開始前雑談
- Dockerをデプロイに活用するメリット
- アプリケーション、configとかの環境をまるごとパッケージングできる
- Dockerをデプロイに活用するメリット
- 最近のモダンシステムのパターン
- パターン
- 分散システム
- マイクロサービス
- デプロイメントのサイクルを速くしてサービス改善速度をあげる
- コンテナ化
- サーバーレス,FaaS
- アプリケーション開発者はその実行基盤について気にする必要がない
- これらのパターンは下記の特徴がある
- ベアメタルサーバから離れている
- ライフタイムが短い
- アプリケーションの更新頻度を高める、という方向性
- アプリケーションデプロイ、リソース最適化に焦点
- クラウド事業者側からは助かる。ラムダが安く提供できている理由でもある
- ローカルファイルシステムの存在を前提としていない
- 外部に保存する
- パターン
- 分散システム
- 歴史は長いが、近年になってOSSで我々もそれを利用できるように
- 分割の単位がどんどん細かく
- コンテナシステム
- 歴史が長い FreeBSD Jail,Solaris containers等
- 近年
- Docker,Kubernetesが登場
- Dockerfileという定義ファイルを書いて実行すれば簡単に再現できる環境として立ち上がるのが革命的
- Docker,Kubernetesが登場
- 近年のパターン
- Webアプリケーションなど、汎用的な目的でコンテナ
- データ処理プラットフォームとして分散システムが使われている
- 問題
- このアプリケーションってどこで動いているの？どれだけのリソースで動いているの？
- 集中管理プロセスはどこに置くの？
- 問題は下記に集約される
- ストレージ管理
- 設定を持ってくる方法
- 状態管理
- リソース管理
- マスターをどこに担わせるか管理
- 歴史の話
- 分散システム
- Hadoop登場(2006)
- 2003,2004のgoogleの論文で社内でどのように分散ファイルシステムを実現しているかが分かった
- それを受けて2006にYahooの人がHaddopを開発
- これで誰でも分散ファイルシステムを利用できるようになった
- 2011にHadoop 1.0リリース
- Hadoop 0.1.0時代
- タスクは分割されてJVMプロセスとして実行される
- データはHDFSで格納
- マスターノードが落ちた瞬間にすべて落ちるという分かりやすいSPOFを抱えていた
- Hadoop 2.2.0 2013年
- HadoopはMapReduceのためのフレームワークではなく、他の色々な機能も含めた汎用的な分散処理のフレームワークとなった
- 広く使われるミドルウェアとしての進化
- Zookeeper(分散キーバリューストア)が入ってきて、コンフィグ、ステート管理がされるようになった
- ノード側から自分でクラスタに入ったり、抜けたりという処理ができるようになった
- 調停者の仕組みが入った QJM
- Hadoop登場(2006)
- コンテナ
- 2013年 Dockerリリース
- 最初は開発用途、テストの用途での利用だった
- オーケストレーションの機能が貧弱で、本番で使うのは厳しかった
- 解決すべき課題は、割と近い過去に分散システムの文脈で解決されてきたのと同質
- Kubernetes
- 2013年 Dockerリリース
- 分散システム
- Kubernetesでもまだ解決できていない問題
- データ格納先
- 今はAWSのRDS等のKubernetes外で対応している
- クラウドサービス上で使っているならいいけど、そうでない人は？
- データの種類は？
- 設定？ノードのステート？
- アプリケーションが永続化するデータ？
- データの種類は？
- ストレージを管理するのは、コストがかかる
- データ格納先
生存戦略: テックリード/リードエンジニアとしての生存戦略
(本セッションはパネルディスカッション形式でした)
- 登壇者
- モデレータ
- メルカリ VPoE 是澤さん
- パネラー
- メルカリ CTO 名村さん
- トレタ CTO 増井さん
- Speee CRubyコミッター 村田さん
- モデレータ
- OSS的な活動について
- 増井さん
- Pukiwikiでプロダクトオーナー的なことをやってた
- 伽藍とバザールを参考に
- その経験として、自分にはマネジメント系が向いてないなと思った
- OSS活動でのgithubのstar数が多かったおかげで、アメリカの会社に入るときに役立った
- 名村さん
- メンテできなくて飽きちゃう
- Cassandraやってたこともあったが
- 勉強の方法なにかよい方法あります？(是澤さん)
- 村田さん
- OSSで何かターゲット決めて読むといいかも
- 名村さん
- コアライブラリは勉強になる
- Java,Goとか
- 村田さん
- Rubyだと田中哲さんが参考になる
- 村田さん
- 増井さん
- どんなスタイルでコード書いてますか
- 増井さん
- 風呂に入って書いてます(会場笑い)
- クラブでも書きますよ。DJと間違われます(会場笑い)
- 移動中、待ち時間にも書いたりする
- 名村さん
- (増井さんの流れを受けて)アメリカお風呂ないんで…(会場笑い)
- リゾート行ったときに余った時間で書くと捗った
- 是澤さん
- カフェ良い
- ニコ動、アニメみながら、といった、ながらプログラミングスタイル
- 村田さん
- カンファレンスでコード書くと捗る(笑)
- 増井さん
- こんなこと言ったら怒られると思うんですけど会議中も結構はかどりますね(笑)
- (まとめ: 限定された環境、それをやる以外にない状況だとはかどる傾向があるっぽいですね)
- 増井さん
- 海外エンジニアと日本エンジニアの違い
- (アメリカは人が辞めるの早いという話題に対して)国限らず会社が儲かっているか儲かっていないか、転職しやすいかどうかが、行動に影響与えてそうですね
- (文脈的にアメリカを想定)年齢を聞いたらダメだし、履歴書にも書かない
- 自分で変えられないものを聞いたらいけないし、それを理由に評価してはいけない
- (文脈的にアメリカを想定)ジョブ・ディスクリプションがはっきりしてるかしてないか
- 海外の人の方が積極的、グイグイくる
- ビジネス側から速くあげてほしいという要求があることがあるが、どのように折り合いをつけているか？
- ビジネス側の傾向として、一旦動くものを作ると落ち着くことが多いので、一旦動くところまで作ってから、その後にキレイにする期間を設けるのもひとつの手段
- 企画側にエンジニア入れて調整できるところは調整する
- Googleとかみたいに基準を敷くとか
- 締めにひとこと、アドバイス的な
- 毎日コードを書いて毎日コードを読む(村田さん)
- 求められているものの120%をどうやって返すか、プラス部分をどうやって提供できるかを考えること(名村さん)
- 自分が心がけていることとして、年イチで個人でプロダクト作ること、英語で登壇すること(増井さん)
- 技術はあとから追いつけるので、そうじゃないところで積み重ねがものを言うものを作っていく
XR: VRのこれまでから学ぶ、VR開発の始め方
- 登壇者
- コロプラ 中原圭佑さん
- VRとは
- 「見かけや形は原物そのものではないが、本質的あるいは効果としては現実であり原物であること」
- HMDの仕組みの説明
- 左右の映像に視差があることで立体的に見える
- ヘッドトラッキング
- ヘッドトラッキングの遅延(レイテンシ)を少なくすることが重要
- ポジショントラッキング
- Outside-in方式
- 外部カメラからのトラッキング
- Inside-out方式
- HMDにカメラがついている
- Outside-in方式
- デバイス時系列順紹介
- Oculus Rift DK1,DK2
- DK1
- 開発者向けのきっと
- ヘッドトラッキング
- ポジショントラッキングはできなかった
- DK2
- 外部カメラがついてポジショントラッキングができるようになった
- DK1
- GearVR,Cardboard,ハコスコ
- モバイルVR
- Oculus Rift,HTC Vive,PSVR
- ハイエンドVR
- 2016年 VR元年
- Windows MR
- 外部センサ不要
- Oculus Rift DK1,DK2
- デバイス比較
- Oculus Rift
- コントローラはギュッと握りこむ感じ
- 前にセンサカメラを置くので、プレイヤー背後はトラッキングできない
- HTC Vive
- 銃を持つ感覚のコントローラ
- Oculusよりも広い範囲をトラッキングできるが、一人暮らしの部屋だとスペース的に厳しいかも？
- Windows MR
- 様々なメーカーが製造
- メーカーごとの性能は一緒
- 付け心地と値段が異なる
- コントローラはOculusとViveのものを足し合わせたような感じ
- 電池燃費は悪い
- HMD単体で取り回し可能
- バックアップPCで無限に歩きまわれるような気もするが、コンテンツ側がそのような対応をしているかによる
- WindowsMR Ultraと無印がある。
- PSVR
- ポジショントラッキング
- 横範囲が狭い感じ
- ソファに座った状態であまり動かない状態での使用を想定
- PSVRは重いが、重心設計が良いのか、他のと比べて疲れるとかはない
- ポジショントラッキング
- シェア: Steamプラットフォームでは、Oculus RiftとHTC Viveでの使用が9割を超える
- Oculus Rift
- 各デバイス対応の知見
- TITAN SLAYER開発時の話
- これは前からしか敵が来ないゲームである。Oculusは背後トラッキングができないため、ゲームデザインの時点でそのようにしている。
- OculusとViveとで銃の向きが異なるので、ユーザテストを実施して違和感がないようにそれぞれ調整
- TITAN SLAYER開発時の話
- 配信ストア
- Oculus Store
- VR専用ストア
- Steam
- コンテンツ数が豊富、利用者が多い
- Microsoft Store
- WindowsMRのコンテンツが唯一このストアのみ振動対応(現時点)
- Oculus Store
- 配信ストアの開発者プログラム
- Oculus StoreのOculus Start
- かなり手厚いサポート
- SteamのSteam Direct
- タイトル公開に1タイトルにつき100ドル必要で、売上1000ドル突破で返金
- Microsoft Store の Microsoft Developer
- 登録に数十ドル必要
- Oculus StoreのOculus Start
- VRコンテンツを作るには
- ゲームエンジンの活用
- Unity or UE4
- ゲームエンジンの活用
セッション5 15:40-16:20 モバイル: CrossSession
- 登壇者
- モデレータ
- Swift愛好会 七島さん
- パネラー
- 岸川さん
- iOSエンジニア
- 小西(こにふぁー)さん
- Rails -> Android
- 最近はFlutterをやってる
- 中田さん
- ReactNativeでお仕事してる
- 田淵さん
- Japan Xamarin User Group 主宰
- 岸川さん
- モデレータ
- モバイル開発をやるようになった経緯
- 田淵さん
- 営業の仕事上で触っていたら、楽しくなってきてそのままやるようになった
- 中田さん
- Reactが盛り上がり始めていた時期で、ReactNativeはまだまだの時期。当初自分の売りがなく、ReactNativeがくるだろうと踏んで、生存戦略的考えからその道に進んだ
- (ReactNative固有の知識は必要ですか？)
- ReactNativeに関してはそこまででもないが、Reactの知識は必要
- (もともとWebだったのなら、デバイス固有の知識も身につけなきゃで大変じゃなかったですか？)
- カメラとかジャイロとかそのあたりはデバイスの知識が必要だが、それ以外に関してはそこまでデバイスの知識が必要というわけでもない
- こにふぁーさん
- 始めたきっかけは、当時の会社が潰れかけで、背水の陣で会社で取り組み始めたときの役割分担の結果
- 妻からAndroidしか作れない半人前扱いされるのでiOS開発できるようになりたかったが、ReactNativeのエラー時の真っ赤な画面がつらくて、タイミングよくFlutterが発表されたのでやってみた。Flutterはそこまでつらさはなかった。
- Flutterの開発をするうえで、iOSのプラットフォーム知識面で困ることはなかった。一番iOSで苦労したのは審査だった
- DartはJavaに近くて、JavaやKotlinやってる人にとってはとっつきやすい
- (中田さん)今からDartをやるのはつらい。Flutter以外ではDart使う部分ないし。型がほしいならTypeScriptやったほうがいいと思うし
- Dartはコンパイラ仕様の面で性能がよい
- (岸川さん)言語が死ぬとかはそうないと思うし、言語選択はその場その場の適材適所かなと思う
- (中田さん)今からDartをやるのはつらい。Flutter以外ではDart使う部分ないし。型がほしいならTypeScriptやったほうがいいと思うし
- 田淵さん
- なぜ我々はWebアプリではなくネイティブアプリを作るのか
- 岸川さん
- WebアプリでできるならWebアプリでやりたいが、今はストアの力(※1)も無視できないなと思う
- こにふぁーさん
- プッシュと、触り心地の面でネイティブの方がいいだろうなと思う
- PWAよりも触り心地がよい
- 中田さん
- WebでできるならWebの方がよい
- 今はストアの力があるのと、デバイス最適な触り心地を
- (これが解消されたら、俺はWebアプリを作るぜ、というのはありますか？)
- 中田さん
- 自分はもともとWebよりのバックグラウンド
- ネイティブ機能ごりごり必要とか、若年層向け(ストアから落とすものだと思っている)を考えると、ネイティブなのかなと
- こにふぁーさん
- カメラアクセスがもうちょっと使いやすくなったら
- ただ、Googleが出しているPWAのサンプルを見ると、保守の面でPWAはまだつらいイメージがある
- 岸川さん
- 前提として、Webかネイティブのどちらかにこだわりがあるわけではない
- 今作ろうとしているサービスをどのように使ってもらうか考える
- それによって、最適なものを選ぶのがよい
- 中田さん
- 岸川さん
- モバイル開発の今後の展望
- 岸川さん
- モバイル開発,Web開発に限らずソフトウェア開発は複雑化の道を。ソフトウェアエンジニアはますます必要とされるだろう。その複雑な問題を解決する能力があれば大丈夫なのでは。
- こにふぁーさん
- Googleが進めている流れ的に、通知周りだけで完結するようなアプリが増えていく
- ちなみにFlutterについては、どうなるかは正直なところ分からない。Googleの今後の発表次第なところはある。
- 中田
- ReactNative選んでおけばどうにでもなる。
- ネイティブ作れるし、ReactにいってPWAできるし。
- ReactNative選んでおけばどうにでもなる。
- 田淵
- Xamarinが捨てられる可能性はあったが、オープンになったので、一旦安心。
- 岸川さん
※文脈的に「ストアの力」=「送客力」ということかな
セッション6 16:35-17:15 AI: CrossSession
- 登壇者
- モデレータ
- ウサギィ 比留間さん @kazoo04
- パネラー
- ヤフー 河合さん @vaaaaanquish
- ヤフオク広告まわりの機械学習担当
- クックパッド 染谷さん @ayemos_y
- 機械学習は社会人になってから
- DeNA 内田さん @yu4u
- KDDI研究所勤めからエンジニア転向
- TIS 久保さん @icoxfog417
- コンサルタントとしてキャリアスタート
- arXivTimesの運営
- 機械学習の英語論文を翻訳したうえで要約したものをアップしてる
- ヤフー 河合さん @vaaaaanquish
- モデレータ
- 現在のAI技術のうち、これからのスタンダードとして残っていくものについて
- 転移学習(久保さん)
- 少ないデータに対応できる技術として
- メタラーニング(久保さん)
- 学習方法を学習する
- これも少ないデータに対応できる技術という文脈
- ネットワークに対する職人芸がいらなくなる
- 学習方法を学習する
- ResNet(内田さん)
- 畳み込みは画像に対して有効である
- ニューラルネットワークの形式化と、その変換技術(ONNX)(染谷さん)
- 検索に関するもの(河合さん)
- 転移学習(久保さん)
- AIにより奪われる職業ランキング一位はプログラマだと思っていますがどうですか？
- プログラマは最後まで残ると思っている。AIを作るのはプログラマ、問題が発生したときに止めるのもプログラマ(河合さん)
- なくなるというよりは、プログラマがやる仕事が変わるということはあるかもしれない(染谷さん)
- 機械語を書く必要がなくなって、作業のレイヤーが上がることはあるかも
- 例えば、AWSが出たからインフラエンジニアがいなくなったかというと、そうではない
- コストが10分の1になったら10倍の仕事をするだけだ
- 機械語を書く必要がなくなって、作業のレイヤーが上がることはあるかも
- どういう問題を解くのかを考える設計から始めて、作って、評価して、というのがプログラマの仕事。その仕事はなくらない (内田さん)
- 未来においてはプログラミングというものが、今僕らが想像もしないものになっているのでは。(久保さん)
- 生き残るには勉強をし続けなければならない、というのはある。
- 人工知能が与える、エンジニア界への影響は？
- 人工知能が出す回答はtrue/falseではなく、x%でそうらしい、という不確実なもの。それをどうシステムに組み込むのかというのは気になる(久保さん)
- 人工知能というよりは人工知能ブームがエンジニア界に影響を与えていると思っている。(内田さん)
- 論文が出ると、すぐに誰かが実装をできるようになったのは数年前だったら考えられない
- 実行環境の充実 python,jupiter notebook,Docker
- エンジニアがカバーすべき技術領域が増えて、エンジニアが大変になる未来(染谷さん)
- データ基盤を整える人は必要なので、インフラエンジニア的な人が増えるんじゃないか。(河合さん)
- AIで実用されているものと理想との差ってありますか？
- 商品検索でサジェスター作っても、ユーザがその結果を使わなかったりする(河合さん)
- 自分が作るものがユーザが求めているものなんだろうかという点が理想と実際のギャップ
- 使える場所が少ない(染谷さん)
- クックパッドで画像分類が活躍する場面は全体の中でどのくらいの割合だろうか。少ないと思う。
- 今はDeepLearningありきで何か作りたいになっちゃってて、適材適所で技術が使われるという感じではない(手段と目的の逆転)
- もっと技術がコモディティ化して気軽に使えるようになると、(手段と目的が逆転する状況が)解消してくるのかもしれない
- 認識100%できたとしてユーザビリティ向上するのか、効果あるのか、をそもそもちゃんと考えておかないといけない(内田さん)
- 「理想が追いついていないところがある」(久保さん)
- 機械学習を使わないと実現できないUXをまだ定義できていない
- AIの活かし方を思いつけてない
- 商品検索でサジェスター作っても、ユーザがその結果を使わなかったりする(河合さん)
セッション7 17:30-18:10 XR: CrossSession
- 登壇者
- モデレータ
- 比留間さん
- パネラー
- JapanVR Fest(旧OcuFes)主催 高橋さん
- コロプラ 中原さん
- テクニカルアーティスト ねこますさん(リモート)
- モデレータ
- ねこますさん「ガバガバFPSで〜す(モニタのアバターの動作がカクカクなことに対しての自虐ネタ)」「こっちは暖かいで〜す(会場が屋外で寒いことに対して)」
- (個人的感想)この空気感、本物ののじゃロリおじさんだ…！(感動)
- 今後VRでやってみたいこと
- 一体型VR(高橋さん)
- つまりスタンドアローンで動くように。
- VRを手軽にしなければいけない
- 人によっては毎日使うアプリケーションはすでにある(VRChat)(ねこますさん)
- VRChatみたいに人とふれあう系のコンテンツを作りたい(中原さん)
- XRの導入としてはある程度完成されたプラットフォームであるVRChatは手軽で良いと思う(ねこますさん)
- VRの世界で便利なこと、不便なことってなんなのかなあというのを掴む
- XRの導入としてはある程度完成されたプラットフォームであるVRChatは手軽で良いと思う(ねこますさん)
- 一体型VR(高橋さん)
- なぜVRやってみたいと思ったのか
- 1998年に新宿で体験したVRのゲームの筐体、2013年のOculus DK1をKickstarterでポチってVRの世界に(高橋さん)
- VTuberになろうとしたきっかけは就活用のポートフォリオを作りたいと思ったことから。VRに関してはソードアートオンラインの世界観が好きだったというところから。(ねこますさん)
- 2013年のOcuFesでOculus DK1を触ったのがきっかけ。(中原さん)
- XRの開発は他の開発とここが違う、ここが醍醐味
- オブジェクトとの距離が近いのが興奮もの。開発者的には普通のゲームと違って360度動けるので大変な面もありますが。(中原さん)
- 自分自身が別の存在になれるところ、没入感(ねこますさん)
- 究極的にはすべてのアプリケーションを包括したVRのプラットフォームアプリケーションがあればいいよね(ねこます)
- (↑について、しばし白熱)
- 究極的にはすべてのアプリケーションを包括したVRのプラットフォームアプリケーションがあればいいよね(ねこます)
- (会場から質問)自分はそこまでVRで没入感を感じられないタイプだったのだが、姿勢として、ユーザが自分で思い込むことが必要とされるのか？開発者が努力するべきなのか？
- ある程度のユーザ側が思い込む努力も求められるかも(高橋さん)
- 出来る限り開発者側で調整していきたい。個人差はオプションで補うとかも。(中原さん)
- まだ機器が追いついていない部分もあるかと(比留間さん)
- 極力ユーザが違和感を感じないようにするのがコンテンツ提供者側に必要。ただ、慣れの問題もあるかと思う。テレビだって中身がそこにあるわけじゃないのに違和感感じてないでしょ？(ねこますさん)
LT大会 インフラ/DB
- Coding CDN in Moneyforward (Yosuke Suzuki)
- 5分で分かる脆弱性スキャナVulsと無料パスワード管理システムbitwardenについて (@adachin0817)
- (@furu8ma さんのCloud SQL for PostgreSQL移行の苦労に関する発表)
- 歴史的経緯
- 元Oracle使いだけど、MySQLのSQL実行計画についてちゃんと調べた (@katsuhisa__)
↓続き。翌日分のメモ