UI Live ! in Kanazawa に参加してきた
90c0ba03fdaf930c0a4048bb06.doorkeeper.jp
まとまらないまとめ
インハウスデザイナーの新規事業開発での動き方
elmyとCuncableのデザイン。
クライアントワークスと、インハウスの違い。
クライアントワークス
- 作業分担されている。(ディレクタとかデザイナとか、エンジニアとか)
- デザイナはディレクタ→代理店→クライアント(窓口)→クライアント(社長)
- 鶴の一声でひっくり返る
- ゴールが、前提や関係者で変わる。
- UIデザイナ→サービスデザイナへの興味
インハウス
- コストをかけず、スピーディーに。
- 1チーム3人前後。意思決定スピートが早い。
- ビジネス・デザイナ・エンジニア
- 理解力・決断力が必要。
- 役割の制約を作らず、できるところまでやる。
- 最短のリリースを目指して全員が動く。
- ビジネスの人と同じアプリを使ってみる。
- iOS/Androidのガイドラインの違いを考慮。
- デザイナがXcodeを学習。(StoryBoardを使ってる)
- GAなどで定量分析、ユーザ心理を定性分析。
- PDCAを回し、壊すことを恐れない。
まとめ
- インハウスのいいところ
- スキルの幅が広がる
- 本質的なモノ作り
- ユーザの声をそのまま聞ける
- DeNAでは100名ほどのクリエイターがいる。切磋琢磨できる環境。
質疑応答
- クライアントワークでは、いろんなものを作れ、経験にはなる。
- Xcodeを使うにあたって、まずは心理的ハードルがあった。
- 毎日数時間とか、ちょっとずつやることで、ハードルが下がった。
- GUIで直せるのが良い。
- エンジニアがsketchを勉強したり、相互に歩み寄る姿勢が大事。
- 属人性は社内勉強会で、ワークショップしてみたり。
- ビジネスとは、同じアプリを使うことで、共通言語を増やす。
- 毎日30分とか話す。
- XXアプリのYYの画面、とかって言える。
- 読んだ記事、本を紹介し合い、互いの理解を深める。
- 新規事業でユーザの学習コストを減らすため、一般的なアプリを使い、そのデザインを盗む。
プリプリしないアプリ開発
www.slideshare.net
動画配信アプリなどの開発。
アプリのデザインは経験1年ぐらい。
人任せにするから、プリプリする。 そうなる前に、デザイナが出来ること。
- アプリ開発の流れ
- デザイナ・ディレクタ・システムエンジニア
- 画面イメージを決定する際に、システムの人間が関与する方が良い。
- イメージ決定する際に、デザイナからシステムさんにも承認を得る。
- パーツ書き出し
- デザイン:パーツ受け渡し用のスプレッドシートを作る(画面ごとにタブ)
- デザイン:画面イメージをそこに貼る
- システム:欲しいパーツを書いていく(ファイル名も決める)
- デザイン:パーツ書き出し
- デザイン:基本のトンマナはシート分け、画面イメージに追記していく
- システム:確認し、問題なければ終了
- アプリ実装で、デザインが確認してない。
- 毎日、作られた分を確認し続ける。
質疑応答
- 反省会を開き、そこで改めて相談することで、今回の解決策を思いついた。
- 次のアプリでは、今回の解決策を適用して、上手く行った。
- アプリの動きについては、文字ベースや口頭で伝えている。
- 文字だけでなく、質問・回答しやすい状況にする。
良いUIをエンジニアに作ってもらうために、デザイナーができること
www.slideshare.net
デザイン5年、フロントエンド1.5年
運用・改善をしていくサービスのUI、良いUIを作り続けることが、今回の対象。
デザイナもエンジニアも、担当領域が違うだけで、作るものは同じ。
デザイナの仕事は、PSDを作ることではない。
どう実装されているか、エンジニアが何を考え行動しているか、を知るべき。 デザイナが頑張るところなのか、エンジニアが頑張るところなのか。
UIデザイナが作るのは、サービス。 例:スタイルガイドを作るなど、エンジニアが使いやすいアウトプットを作る。
スタイルガイドの運用・保守はデザイナが行う=サービス全体のデザイン。
- エンジニアに無理難題を求めない
- 要求を下げるのではなく、手を取り合うこと
- デザイナ語は使わない
- 抽象的な言葉ではなく、サンプルアプリを伝えたりする
- Photoshop仙人にはならない
- 便利なツールがいろいろ出てくる
- 例えばsketch
質疑応答
- 情報共有
- 自分の見つけたものを、必要なチャンネルに共有する。
- それを相互に行う。
- 1つのPSDに情報を詰め込み過ぎない。
「使いやすい」だけではユーザー体験が上げられないサービスでのデザイン手法
Material Designスタイルでプレゼン。
グラフィック→WEB/INTERACTIVE→サービス
iPhone出て早9年 当時は、専門的なデザイナがおらず、エンジニアだけで作っていた。 今では、UIデザイナの地位が確立され、ガイドラインが作られた。
1→2的なグロースハック系は、「使いやすい」というのが役立つ。 0→1的な新規事業では、雰囲気みたいなものが大事。
UI/UXの記事を鵜呑みにして適用しても、うまくいかない。
さんぽジスタを作るときに、「使いやすい」ではただの歩数計になってしまう。
今日の歩数:達成感・やる気を起こさせる。 キャラ:「何が変か」を具体的に調整していく。 背景:画像検索で世界観を知る。
自分で使ってみて、つまらなかったので、コンテンツ追加。ブラッシュアップ。
質疑応答
- 自分で使って、客観的に見る。
- 何か変えてみて、また使ってみる。
- 社内でターゲットになるような人に使ってみてもらう。
- DeNAは、思ってることを言いやすい環境。
- 自分の作ったものに責任を持つ。
- ターゲットユーザがチーム内にいない場合
- まず、インセプションデッキを作った。
- ある程度仮設を立て、作り、ユーザの動きをアナリティクスで見て、拡張していく。
これからの「フロントエンド開発」の話〜(デザイナー所属の)フロントエンドエンジニアでも知っておきたいこと〜
認証会員基盤のエンジニア フロントエンドのチームリーダー
金沢すきま旅というのを作った。
エンジニア目線な話
UXセミナーのストーリーボードを見て衝撃を受けた。
エンジニアは、細かく検証し、問題があればすぐ修正したい。
Dockerをローカル開発環境として使う。 継続的インテグレーションの流れを、デザイナにも知っておいて欲しい。
質疑応答
- Dockerを布教中
- ハンズオンを開催し、体験してもらう
- GUIもあるおかげか、デザイナ側も抵抗感が少なそう
- ストーリーボードの何が衝撃を受けたのか
- いままでは、完成されたワイヤーから関わっていた
- そのワイヤーに至る理由が見えるので、理解できる
フロントエンドエンジニアが、機能開発の企画オーナーとなってリードした話
エブリスタに関わっている。 6年ぐらいあるサービス。
負債が多い状態で走り続けている状態だった。
使いづらいものを、抜本的に改善したいけど、既存文化や技術障壁を考慮する必要がある。
- 現状を分解する。
- 原因を探る。
- 「なぜ?」を問う
- →ガラケーのUIを引き継いでいた
- チームの共通認識とする
- 解決の方向性を定義する
- 他のアプリを参考にしたり
- 解決案を試作する
- プロトタイプ作ってみたり
チャンスを掴む働き方
- 状況を作る
- "何か"を期待して雇われている
- コアスキルを使い、チームが抱える課題・問題を解決する
- 重要なのは期待を超えること
- 圧倒的な能力を持っている必要はない
- チームの課題を、チームメンバーが感じられる状態にする
- 仲間に入っちゃう
- 呼ばれてないけど、MTGに入ってみる
- 他のメンバーが困ってそうな仕事を、会話してみる
- 信頼を得る→期待が生まれる
生存戦略
フロントエンドエンジニアのキャリアパス コアスキル以外のところも鍛えておく。 プライベートで何かを作ってみる。
質疑応答
- 出来無さそうな話が流れていたら
- 自分のできるところまで分解してみる。手伝えることはいろいろありそう。
- タスクのトレードオフ
- コアスキルの部分を終わらせるのが大前提
- 事前に素振りしておくことで、工数を減らして、時間を余らせる
- 上司に相談して、アサインを変える
- 優先度をつけて、今のタスクが本当に必要なのかを問う
- だれにリソース管理されている?
- 個人でタスクをアサインしている。
- 1日5hの作業をタスクとしてあてる。
- 見積もりミスのバッファに使ったり、改善に使ったり。
パネルディスカッション
3年前との違い
- 与えられた情報を鵜呑みにしていたけど、そこから疑問を持つようになった
- ユーザ体験だけでなく、ビジネス的な目線もついた
- コアスキルへの自信がついた
- 受け身だったけど、今は取りに行くぐらいになってる
- 井の中の蛙だったのを今は知っている
- 言ってみたら変わることを知った
会社間で聞きたいこと
- キャリアプラン
- デザイナ・フロントエンドエンジニアの不可侵領域
- 入ってきてほしくないと言われることが多い。作業に入る前に確認する。密にコミュニケーションをとる。
- 色を変えるとか、簡単なものはしてもらっている。
- デザインしてもらいたい。意見も欲しい。元々の理屈はあるけど、気づかない視点もある。
- サービスデザインは論理的に出来ている部分が多い。
- いちユーザとしての意見は欲しい。
- てきとーに作業はしてもらいたくない。
- 自分が責任を持てるところまで踏み込む。
- システムからの意見はうれしい。
- 知識としては、領域外のこともしていくべき。
- 領域外のことをすることで、作業効率が上がるかも
- もっと踏み込んでいって良さそう。
他職種とのコミュニケーションのコツ
- 単語の意味をちゃんと伝えて、その単語を使う
- 1回飲みに行くのが良かったり、話しかけてみたら意外とwelcomeだったり
- わからない話をそのまま流さず、質問する
- 相手のやりたいこと・時間がかかることを理解する。
- いろんな職種の人に話しかけに行く。
- 自分の影響範囲を知る。やりたいことの根回し手段を知る。
- 相手の郷に従う。相手のコミュニケーション文化に乗っかってみる。
- 相手の領域を経験することで、相手のことを知れる。
- 前提条件を合わせる。話し合うことで、お互いの認識を合わせる。
具体的なコミュニケーションツール
- Slackは常に入ってる。
- メールやLINEも使ったり。
- 静かだけど、Slackだと話していたりする。
- デザインの思考プロセスを、Slackに流している。アイコンも使ったり。
- esaを使って日報を書いている。もやもやを吐露していたり。
- コミュ症の翻訳をしたり。
- Skypeで文字ベースでやりとり。東京とはfacetimeで対面で喋ったり。
- Slackの絵文字。reactionとか。
- Prottを使って、プロダクトについて会話。絵があると、話が進みやすい。
- Slackで雑談部屋。英語専用の部屋。
- ホワイトボードに意見を貼るとそこから話が始まる。
懇親会
- リモートワークに関心は高いらしい。いろんな人に聞かれた。
- Dockerを本番運用しているところもあった。ただ、そこではユーザに直接開放する部分じゃないっぽい?
- いまだにObj-CでiOSの実装を始めることもあるっぽい。企業の体質に依るのかな。
- ポケモンgoの話題は誰にでも通じるぐらい。
- 飲み屋にポケストップあると回し放題(喋ってると忘れるけど)
- PSDの切り出しまでエンジニアがやるのは、やりすぎだと思うデザイナもいるらしい。
- Androidのソフトキーのために、縦横比が変わるってのを、あまり気にしてないデザイナもいる。普段iOSを使ってると気づかないだろうな。
- リスト系の画面だと、あんまり気にする必要無いし。
- デザイン系学部の人たちが、電博にいってしまう。それをIT系に引っ張ってきたい。
- 渋谷とかの大きな会社合同で説明会みたいなのをしては?地方の学生はまとめてあると助かる。
Kanazawa.rb meetup #45 に参加してきた。
最初に感想
- あらためて、CIとはなんのためにやっていたのか、を再認識出来た。
- 様々なCIサービスがざっくり紹介されたので、あとで調べる。
- CircleCIとGitHubの連携はやっぱり便利。ハンズオンの時間が余るぐらい簡単。
- 内容は知ってることが多かったけど、DMMのオフィス綺麗だったし、いろんな人と関われて良かった。
- Gitの運用を悩んでるところは多いんだなー。
- LTっぽいものしたけど、スライド無くてもなんとか喋れた。内容はほとんど伝わってないだろうけど、キーワードでも刺さってればいいな。あとQiitaのストック増えてよかった。
- 飲み会で飲めないのはまだなんとかなるけど、酒のうまそうなバーに行って酒が飲めないのはつらいw
イントロ
https://www.thoughtworks.com/continuous-integration
- CIとは、ビッグバンテストではなく、継続的に結合する。
- 3ヶ月前に書いたものは覚えてない。
- 問題を速く発見する。
俺とCI
- むかしむかし、「ビルド担当者」というものがいた。
- ソースコード集め→マージ
- ビルド担当者が槍玉に上がる(自分のところでは動くけど、マージされたら動かないとか)
- そもそも、人間がやることが間違い。
- Jenkinsとの出会い。
- 時は流れ、ビルド担当者→デプロイ担当者
- DepOpsという単語が出てきた。
- 日経メディアで、Jenkins Redmine Chefが三種の神器とか言われた。
- iOSとかで、またビルド担当者が出てきたらしい。
- さまざまなモチベがあり、それの導入を容易にするために様々なツールが出てきている。
CIサービス紹介
https://speakerdeck.com/wtnabe/introducing-todays-ci-services
- 基本的にはSaaSで使えるもの。
- 基準:メジャー、OSS版がある、Windowsとか、おまけ
- TravisCI
- CircleCI
- CodeShip
- GitHub / Bitbucket
- Shippable
- 安い
- 設定がちょっと煩雑
- Drone.io
- BITRISE
- モバイルアプリに特化
- AppVeyor CI
- ブラウザテスト
- SAUCELABS
- SeleniumテストとUnitテスト
- 手元のバージョンをリモートからテストも出来る。
- BrowserStack
- 上と似た感じ。どっちが良いかはわからない。
- カバレッジ
- Coveralls
- Travis CI / CircleCI対応
- CODE CLIMATE
- 静的解析
- 選び方
- 金で解決
- 人的リソースは有限。
- 当たったサービス以外はそこまでリソースを割けない。
- CI環境そのものが腐っていく。
- 弊社の例
- CircleCI + Codeshipの無料枠
JAWS-UG金沢 第10回勉強会 に参加した話
https://jawsug-kanazawa.doorkeeper.jp/events/43543
AWSトラブルシューティング!早期復旧のための心掛け
と同じ資料っぽい。
- Developer.IO 2016で喋った内容
- 日次・月次・年次・不定期で分ける
- 日次は可能な限り自動化
- データリストアを、運用前に確認する必要がある。
- 監視で障害があったとき、次のアクションを明確にする。
- リソースではなく、サービスや処理状況を監視する。
- URL監視がこけたら急いで対応。
- SESのバウンス率が高いと、
- メールをチケット化するサービスを使っている。
- 障害→CloudWatch→Zabbix→Twilioで電話がなる
- AWSの障害も結構ある。
- 春と秋はEC2のリタイアメントが多い。
- APIの呼び出しに失敗することもある。
- Design for Failure
- 負荷試験ではなく、限界試験をやるように言っている。
- EC2Configが古い
- APIコール失敗の場合は、エラー判定して、Exponential Retryするべき。
- AWSサポートが最後の砦だけど、ちゃんと情報を送らないとあしらわれる。(このログを送って下さいで返ってくる)
- 緊急度 x 重要度 = 優先度
- 調査には、システム構成図・ELB/CloudFrontのログ・CloudTrail・MySQL show full processlist
- システム構成図には、データの流れがわかるように。
- ELBのログがoffのままの場合がつらい。
- CloudTrailは全リージョンで有効にすべき。Keyが漏れた時に、10分後に全リージョンでEC2を立てまくられた。
- 負荷試験では、3〜10倍の負荷をかける
- 限界試験で、どこがボトルネックになるかを知っておく。
- フルボッコというCloudFormationテンプレートがある。
- トップページ・ランディングページの試験は重要。一番リクエストがくるはず。
- 負荷試験後、ディスク使用量を確認する。
- 障害試験
- サーバを止めてみる。
- DBをファイルオーバーさせてみる。再接続するか確認。
- 障害が検知できるかを確認しておく。
- 検知されたメールを確認する。何に問題があるかが、メールだけでわかるか。
- オペトレ
- 手順書を、書いた本人以外が試してみる。(情報に抜けが無いか確認)
- Trusted Advisor
- リリース前には必ず見る。
- REDは無くす。
俺と「AWS外部から観測」
- 立場が違えば、"通常"の意味が変わる。
- ゲームなどのサーバが止まると、ユーザはありとあらゆる手段で連絡を取ってくる。
- 機会損失も含め、かなりの損害。信頼を取り戻すのにも時間がかかる。
- 内部からの観測では、実際のレスポンス時間などは計れない。
- 内部からのアクセス用に管理ツールを表示してたのに、外部からも見れてたりってのは開発者は観測しづらい。
- さくらのシンプル監視。月額21円。Slackに通知したりも出来る。
- 外部のJenkinsからレスポンス速度を定期的に取得しておくと、簡単にグラフ化したり出来る。
センターSEがインスタンスので止め忘れを監視してみた
- 大きいインスタンス1台を、1週間立ち上げてるだけで3万円かかってしまう。
- CloudWatch Eventsのcron指定でLambdaを叩く。
Zabbix 監視と課題
- 障害対応は、こちら側で先に対応したい。主導権を握りたい。
- Zabbixでアイテム数3万以上、トリガー4,000以上。
- RSSの更新情報もZabbixで通知できる。
- 通知内容に多くの情報をのせる。連絡先とか、次のアクションとか。
- 通知は日本語にした方が、日本人には伝わりやすい。
今月のブログ収支報告
感想
なれるSEを読んで、運用って部隊が必要なことは知ってたけど、 自社ではそこまできっちり分かれてなくて、そんな世界もあるんだなーと実感。 大抵RDSで詰まるとか、Trusted Advisorは必ず見ましょうとか、具体例が多くてためになった。
運用保守のことも、ちゃんと考えていかないといけないのかも。
懇親会で、日付変わるまで金沢の飲み屋にいて、 そこから富山市の自宅まで帰ったら2時ぐらい、ってのはつらい。 ただ、終電とか気にしなくて良いのは楽。 終電でバタバタ帰るより、こっちの方が気持ちは楽かも。酒飲めないけど。
詰め共円のサーバ移行で悩んでいる件
toyamarb.doorkeeper.jp で書きました。
前提
現在、Google App Engile + Cloud Datastoreで、無料の範囲内に収まっているサーバを、AWSに移したい。 意図としては、
- GAE/Pythonに飽きた。
- インフラ持ってれば、試せることが増えそう。
- Let’s Encryptとか。
- WebSocketとかやってみたいし。(Channel APIってので出来るらしい?でもgaeにロックイン。
- オプション:Dockerとか使ってみたい。
- オプション:AWSのサービスをいろいろ使ってみたい。(SNSとか)
データストアの検討
DynamoDB
- テーブル数 x アクセス速度による課金っぽい。
- http://qiita.com/YU81/items/e1e336990ed8cfb938d9
- 5テーブル x 最低限だと、500円/月ぐらいになりそう。
- でも、SIMPLE MONTHLY CALCULATORでてきとーに入力しても、$0。謎。
- 現状、既にNoSQLなので、移行コストもそんなではない気がする。
- ただし、データの移送とかは考える必要あり。
- DynamoDBを操作するGemも発見。 https://github.com/Dynamoid/Dynamoid
Cloud Datastore
- 安い。
- 今使っているものをそのまま使えるので、移行コスト0。
- 良いGemが見つからない。
RDS, ElastiCache
- 時間課金なので、高い。
- ElastiCacheの一番安いので、$20弱/月
コンピューティングの検討
ElasticBeanstalk
- ELBだけで$19.77/月over
- EC2は1年リザーブドだと、$14.64 -> $10.5に。(t2.micro)
- EBSは必要だけど、30GByteで$3.6/月
- 合わせると、$33.87。高い。
- ElasticBeanstalkとして書いたけど、結局EC2+ELBなので、直接でも良いかも。
Google Container Engile (GKE)
- 5ノードまで無料。(よくわからんけど、安い)
- インフラ持てないじゃん。→却下。
Heroku
- $7/月
- インフラ持てないじゃん。→却下。
まとめ
- AWSで、インフラを持ってみたい、ということでEC2を直接使うしかない感じ。
- ElasticBeanstalkを使うのか、OpsWorksとか使うのか、Terraformとか使うのかは検討。(レイヤーバラバラだけど。。
- Google Cloud Platformは安いけど、Railsを動かす環境としては、ちょっと大変そうな印象。(Gemの量とか)
結論
$30over/月ぐらい。なのか? http://calculator.s3.amazonaws.com/index.html?lng=ja_JP#key=calc-9C121C01-B126-43EC-8F3F-8D37D455C46F
第二回!チキチキ Agile x Kanazawa.rb に参加してきました。
表示してたスライドは、たぶんこれみたい。
Modeling in the Agile Age - JP
メモ
- 全体像を知るために、モデリングが必要。
- 捨てるモデルと、保存するモデルを分ける。
- コードからリバース出来るものは、捨ててしまう。
- コードに現れないものは、保存してメンテする。
- Keeps
- Architecture
- Domain Model
- Key UseCases
- Architecture
- システム全体の構造的な表現
- MVCの依存関係を、パッケージ階層で示すなど。
- Domain Model
- 問題領域の概念とそれらの繋がり
- 現実世界をモデリングするのは難しい。対象となるシステムがベースになる。
- 唯一正しいモデル、というものは無い。
- Key UseCases
- アクターが大事。"ユーザ"ではなく"開発者"など絞る。
- コミュニケーション図で、何が同動くかを記述する。
- astahのマインドマップが使いやすい。
- 他にKeepするもの
- 設計の理由。WHY。
- チームで話し合って、追加・削除をしてメンテしていく。
- モノ・コト・モノ パターンと、ヘッダー・明細パターン
- 図書館と本屋では、モデリングが違う。図書館では蔵書という概念があるが、本屋では数しか見てないはず。
- 問題と解を得るために、分析モデルと設計モデルを分けて考える。
感想
メンテ出来なくて、特に重要じゃないモデルは、書いても捨ててしまえばいい、というのはいいと思った。 書いてもメンテしなきゃ、と考えると書きづらいし。
また、用語集・辞書を最初に作って、それをメンテしていくのはやっぱり重要なんだなーと。 メンテに際しては、誰もが見える場所で、更新が通知されることが重要っぽい。(みんなで作ってる感というか。 ただ、誰もが見える場所とはいえ、プロジェクト関係者以外に見えたらダメだと思うので、どこに置けばいいのかなーと。
「リモートチームでうまくいく」倉貫義人さんと語らう会に参加しました。
に参加してきました。 自分もリモートワークしてるので、そのへんのつらみの解決策が聞ければなーとなんとなく考えてました。
セッション
- 求人で来る人が地方が多い。都内は比較的少ない。
- 会社としては、リモートワークが前提。都内にいても、行っても行かなくてもいい。
- 間口広げるために、募集をリモート前提にした。
- Skypeで音声繋ぎっぱなしは、人数が多くなるとつらい。
- Results-Only Work Environment アメリカのものは、完全に個人のもの。
- ただ、アメリカでも個人主義の考え方をやめ始めている。チームで助け合う。
- エンジニアの評価は、短時間では出来ない。悪いコードを量産した方が、短期的には良く見える。
- チームでやるとは、スポットの仕事をさせるわけではない。受発注ではない。
- リモートワークという言葉の定義を浸透させたい。クラウドソーシングではない。
- 会社とは概念的なものであり、ソフトウェアで表現できる。
ビアバッシュ
ビアバッシュでは、いろんなことを聞けましたが、立ってピザ食べながらだったのでメモもなく、印象に残ってるものだけ。 (ニュアンスが異なっていることは多々あると思います)
- SonicGardenでは、営業活動をほぼ(?)していない。お問い合わせから依頼来る。
- これまで、新卒採用はフォームすらなかった。その中で応募してきた人たちなので、その教育などは他では流用出来無さそう。
- セキュリティ対策とかでガチガチにするぐらいなら、そういうのが必要無い人を採用するところにコストをかける。「なんでそんなに信頼ならない人を採用してるの?」
- 毎週の振り返りで、「先週は夜遅くまでやって、ここまで出来ました!」がKではなくPである、という風に教育していく。何が良い・悪いなどの社風はそうやって受け継がれていっている。
- 基本リモートワークしてるので、会社の椅子的なキャパが余ってる。家を借りようかと考えてる。
- 会社では、Skype打ち合わせが輻輳するようになってきている。(他の打ち合わせの声がうるさい、みたいな)
- SonicGardenは裁量労働制。
- リモートワーク推進協議会的なものを進めている。"リモートワーク"の言葉の定義を正しく認知してもらう。推進する会社を増やしていく。
なんとなく、SonicGardenはエンジニアにとっての理想郷を目指している感じは受けました。 さらにそれが一般認知されており、お客も採用も上手く回っている感じ。 売上の向上とかを至上命題にしなければ、こんな会社の運営の仕方もあるんだなぁと。
全員がリモートワーク前提でやっている、というのはかなりうらやましい。 Monstar Labでは、ほとんどが中目黒で、他に島根(4人)、鹿児島(1人)、富山(自分)という状態なので、リモートがマイノリティ。 なので、認識の内外で、リモートだから、、、という遠慮はある気がしてる。 なので、SonicGardenのやり方がそのまま持ってくることは出来ないけど、参考になるところを取り入れていきたいとは思う。
先週の富山合同勉強会もそうだけど、こういった有名な人の話を富山で聞けるってのはありがたいなー。 運営側はお疲れ様でした。 2週間後には平鍋さんの話も聞けるので、楽しみ。 Meetup #42 - Kanazawarb
富山合同勉強会2016
JavaOne 2015 San Franciscoフィードバック、そしてJava EE 8についてのアップデート
- JavaOne 2015は1万人超
- Sunの頃よりはまだ少ないけど、近づいてきている。
- IoTの活用が強めに話された。
- 2016のJavaOneでは、さらに事例がふえると予想。
- Java8が出た後で増えてきている。
- JCPへの参画拡大。営利団体でも無償化。
- キーワードはIoT, DevOps, microservice
- IoT
- DevOps
- Microservices
- JavaEE8アップデート
- 最初のドラフトのレビュー中やレビュー完了の状態。
- クラウド絡みのものは遅れ気味。
- 7,8団体がレビューしている。
- early draftの策定中であれば、まだ意見が通りやすい。後ろになれば通りづらい。
- HTML5 / Web Tier
- JSON-BはJacksonがメインで考えられている。
- プロバイダの変更も可能。XML
- JSON-PにJSON-Pointerが追加される。
- "/0/phones/mobile"とかで特定のデータを取得・更新できる。
- JSON-Patchでは、JSON形式で変更出来る。
- MVC1.0が策定中。
- 既存のJavaEEテクノロジーを組み合わせて実現。
- JAX-RSとCDIとJSPとか。
- HTTP/2
- Server pushがServlet4.0の中に入ってくる。
- CDIの範囲がMVC / JAX-RS / JavaSEに広がる。
- 2つのパーツに分けられる。Full CDIとCDI Light。
- Junit内でインジェクションが、標準で出来るようになる。
- Adopt a JSR https://glassfish.java.net/adoptajsr/
- まずは見るだけでも。
- JavaOne 2016に行こう。
Project Jigsawではじめるモジュール
http://www.slideshare.net/skrb/module-programming-with-project-jigsaw
- 使い方を中心に。
- Client Side Javaを中心にやってる。Java SE, JavaFX。
- Huge Standard Lib
- Hadoopは130のjarを読みこんだり。
- JARが抜けてたり、依存関係のバージョンがズレてたり。
- No Dependency, No Version, Public is TOO Public
- 始まりは2005年。friendsを入れよう、という話が出た。
- JSR 277は炎上中断、JSR 294はmoduleとして続く。
- 2009年にProject Jigsawが始まったけど、2017のJava SE9に入る。
- スコープの問題(OSGiをどうする?とか)で混沌とし、スコープをかなり狭めてSE9に入れる。
- SE9で入る、ということが重要。
- module extends JAR { dependency; exportation; version; }
- module-info.javaに書く。src直下に置く。
- module (モジュール名=パッケージ名にすることが多い) {}
- requires javafx.controls;とかで依存関係を明示する。
- exports (パッケージ名);で外部に公開する。
- mainメソッド持ってるクラスはexportsに入るようにする必要がある。
- requires public javafx.graphics;とやると、第三者にもpublicになる。
- gradleはJigsaw対応を進めている。
- コンパイル時には"-mp"を付ける。
- モジュール作るときは"--create"が必要。"--module-version"でバージョンを指定できる。以上・以下は比較出来ない。
- 実行時にも"java -mp"とかする。
- rt.jarを全部読み込む必要が無いので、メモリに優しい。ちょっとだけ。
- classpathに指定すると、unnamed moduleとして扱われる。
- JavaSE8から、rt.jarを分けれる。循環参照とかをきれいにした。
- module-info.javaに書かなくても、jdepsというツールで確認できる。
- JLINKというカスタムJREを作れる。IoTとかでメモリの使用量を減らせる。
- https://jdk9.java.net/jigsaw/ に既にあるので、すぐ使える。
Microsoft Java
- AzureはLinuxでもdockerでも立てれる。
- MicrosoftはJavaVMのパフォーマンス改善とかにも参加してる。
- Azure上でのホスティングの選択肢
- IaaS
- Cloud Services(PaaS)
- App Services(PaaS)
- Container
- マイクロソフトはFeedBackを、本気で求めている。
Ruby 2.3 のてざわり
- Java to rubyでIDEを使わなくなった。REPLで試しながら書くようになった。
- self navigation operator=ぼっち演算子。
- SQUIGGLY HEREDOCはインデントを取り除ける。
- digはJSONとかで便利
- Enumerable#grep_vはgrepの否定。正規表現マッチしないものを取得できる。
- the did_you_mean gemはirbとかrails consoleで便利。
- NameError#receiverはdid_you_meanで使われている。デバッグのときにも使えそう。
- Hash#to_procは使いどころが思いつかない。。。
わたしの Ruby の楽しみ方
- rackアプリケーションでTwitterのOmniAuth使ったアプリが100行レベルで書ける。
エンジニアが出来る貢献
IoTで除夜の鐘を作った話
正確には、除夜の鐘"っぽいもの"ですね。
http://www.bonno.xyz/ が完成した物です。
ぜひ、Twitterで #煩悩 付けて、今年やり残したこととかをつぶやいてください。
経緯
会社でラボスペースってのがありまして、週1でそこでIoTとか新しい技術について話をしています。 そこで、年末に向けて何かやりたいねー、という話が出て、除夜の鐘とか作ったら面白いんじゃね?となり、作ってみた感じです。
本題
物理的な部分は、鐘を目覚ましのベル部分、撞木をドライバーで作りました。
撞木を動かすのにサーボモータを利用して、それをArduinoで制御、それをmac book経由で遠隔操作する流れです。 (ホントは、raspberry piでやりたかったのですが、時間がなかったのでmacでやってたのをそのまま使っています。)
Arduino
Arduinoの方は単純で、シリアル通信を受け取ったら、サーボモータを回転→逆回転させます。
#include <Servo.h> Servo myservo; // create servo object to control a servo int dir = 0; // -1: back, 0: stay, 1: ahead int val = 0; void setup() { pinMode(8, OUTPUT); myservo.attach(9); // attaches the servo on pin 5 to the servo object Serial.begin(9600); // some servos doesn't work without Serial } void loop() { int inputchar = Serial.read(); if (inputchar != -1 ){ Serial.write(inputchar); dir = 1; } if (dir == 1) { val += 4; } else if (dir == -1) { val -= 4; } if (val < 1) { dir = 0; } if (val >= 130) { dir = -1; } String valString = String(val); Serial.print(val); myservo.write(val); delay(16); }
スケッチの書き方があまりよろしくない気はしています。とりあえず動いたからいいかなーと。
mac book上のArduino制御プログラム
こちらは、websocketによるイベントを受信すると、Arduinoにシリアル書き込みを実行します。
const client = require('socket.io-client'); const socket = client.connect('http://www.bonno.xyz'); // Serial setting var SerialPort = require("serialport").SerialPort; var serialPort = new SerialPort("/dev/cu.usbmodem14221", { baudrate: 14221 }); serialPort.on('open', function () { console.log('serial open'); }); socket.on('kane-wo-tsuke', function() { serialPort.write("1\n", function(err, results) { console.log('err ' + err); console.log('results ' + results); }); setTimeout(function() { socket.emit('kane-wo-tsuita'); console.log('kane-wo-tsuita emitted'); }, 700); });
websocketとシリアルポートの準備をしておき、websocket経由でkane-wo-tsuke
を受信すると、"1\n"をシリアルポートに書き込む感じ。
サーボモータが行って返ってくるのに数百msecかかるので、それが大体終わったぐらいで、kane-wo-tsuita
をwebsocketサーバに送信します。
(実際には、それ以上にustreamが遅延しているので、意味ないですが。。。)
組み立て
100均でいろいろ買ってきました。
鐘を吊ったりするのにやぐらが要るだろうと思ったので、割り箸と結束バンド(タイラップ?)で作りました。
目覚まし時計のベルがいい感じの(?)音だったので、これを鐘にしました。
やぐらの土台として割り箸をボンドで立てました。 また、鐘の中心にいい感じに穴があったので、割り箸を突っ込み、結束バンドで落ちないようにして、ボンドで固めました。
撞木をドライバーにすると、想像以上に音が出かかったので、ビニールテープで裏から押さえました。 自宅でやってるので、近所迷惑にならないか、ビクビクしながらやってます。。
ドライバーに、「ケーブルまとめるねじねじするやつ」を2つ付け、それぞれからビニール紐を伸ばし、サーボモータに付けました。 これが、割り箸でやると軽すぎて上手く当たらなかったり、1本の紐で吊るとくるくる回っちゃったりで、無駄に時間がかかりました。 ティッシュ箱2つ分の高さがいい感じだったので、その上にサーボモータを置いています。
そんなこんなで除夜の鐘が出来ました。
サーバサイド
サーバサイドはGitHubに全部上げちゃってるので、見て頂ければと。 後で、詰まった所とかは細々書く予定。 Heroku上で動いています。
その他環境周り
mac bookでは、ブラウザ上でustreamの配信を行っており、
マイク:ECM-PCV80U カメラ:UCAM-DLE300T
を使っています。
あと、実際に動かしてみると、動いている感が全く無かったので、時計を置いて動いてる感を出しています。
余談
ページ見てもらえば分かる通り、デザインとライティングの能力の無さを再確認しました。 誰か助けて。。。
Android Bazaar & Conference Diverse 2015 Kanazawa(2日目)
テクノロジー&クリエイティビティ
- team Labは400名いる。
- エンジニアが70%。
- デジタルアートはだいたい5年前から。海外の評価が先行。
- もともとWebのエンジニアの人が、機械学習とかやる。
- 画像処理は結構アカデミックなところから人引っ張ったりしてる。
- 障害はほぼ発生しなかったが、キャリアの基地局がパンクした。
- アートだけではなく、テクノロジーと繋げる。
- キャンドルリレーは音で伝えた。機種依存が大変だった。
- ペッパーのイベントでは、四方にスピーカーを置いて、それらの音から三点測量的に位置を検出した。
- 共創をキーワードに、他との差別化を図っている。
RoBoHonのRoBoHonによるRoBoHonのためのプレゼン
- https://www.youtube.com/watch?v=HQtIlxe_ZkY&feature=youtu.be ツッコミたいところが幾つかある動画w
- コンセプト動画にあるものは、基本的にやる。
- 四角いスマホに喋ったり、喋りかけられたりするのは違和感がある。
- COCOROBOという喋る掃除機も作ってる。
- ディスプレイはいちおう付いているが、基本的には音声で。
- 意外と激しく踊る。たまにコケるらしい。
- OSはお察し下さい。
- CEATEC JAPANでは大盛況。
- ロボホンを輸送するときは、100均のタッパが便利。
- 作る側とマーケ側がCEATEC出すときに結構戦った。
- まだ開発中なので、個体差がある。踊れない子もいる。
- 2016年の前半に発売予定。
- 価格はまだ。
- 開発ツールも検討中。
- IS01を開発してた人と、新しい人と
- 電池としては、1日持たせる(踊り続けはしない)
- サーボの電流は大きい。
- 騒がしいところでも使えるように。
- 学習機能もある。
- 人格を複数とかもやりたいけど、コンセプトがブレる。
- サーボの制御はオープン化出来るように考えている。
Androidアプリのマーケティング/マネタイズ
- Androidアプリ出してる人、広告入れてる人は、会場には少なめ。
- AARRRモデル
- 獲得・活性化・継続・紹介・収益
- 本日は獲得と紹介の話。
- Androidは項目多すぎて、上位アプリしか見られてない。iOSはシンプルなので、100位ぐらいまで見てくれる。
- Google Playのランキングは、DL数・アクティブ率・評価が指標になっているっぽい。
- 有効ダウンロード率が意外と重要。
- Google Playのランキングで上位に上がるのは難しい。
- iOSは直近数時間の断続的な新規ダウンロード数で、ランキングが変動しやすい。
- 検索は、タイトル・説明文で触れてるアプリだけではなく、関連度の高いアプリも出てくる。
- タイトルには重要ワードを突っ込む。
- 説明文は、濃度が重要。ターゲットワードは5個ぐらいにする。
- 検索結果数が多いキーワード+自分のアプリならではの部分。
- ASO対策することで、DL数が10倍になることも。
- Androidでは、レビューサイトに紹介されてもそれほど伸びない。積み上げるしかない。
- 流入に対して、一番自分たちでコントロール出来るのは、ASO。
- 1日に100DL取れてれば、結構良い。
- 紹介を得るためには、ツイートへのインセンティブ or シェアしたくなるコンテンツ。
- カジュアルゲーム作ってた会社は、最近廃業が多い。
- 音楽再生(動画)・ゲーム攻略・マンガ・定番ゲーム
UE4ハンズオン
- ゲームエンジン自体のハードルが上がってきてる(いろんな機能はあって当たり前)
- アーティストやデザイナーがコーディング無しで使えるように。
- エンジニアはもっと深い部分に注力できるように。
- 四半期30万を超えるぐらいにならないと、費用は発生しない。
- E3 2015で65タイトルがUEを使ってた。
- ドキュメントの日本語化も、数日遅れとかで反映されてる。
- Youtubeでは、半日かけてやったようなハンズオンも上がってる。
- Perforceがオススメ。20人まで無料のライセンスもある。Gitとかだと、バイナリが辛い。
今さら聞けないVRコンテンツの作り方
- 追体験型なのか、非日常型なのか。
- スマホ前提なのか、専用HMDなのか。
- oculusは基本WindowsPCでしか開発できない。
- Cardboardで綺麗なものを表現しようとするのは辛い。
- VRコンテンツ製作は3Dゲーム制作の延長上にある。
- Cardboard向け開発
- Unityが楽。(OpenGLとか、UE4とかより)
- そんなに高性能なPCは必要無い。
- Oculus Rift向け開発
- UnityやUE4を利用。
- Oclus社で作ってるのは、UE4
- スペックの高いWindowsPCが必要。
- 理想のPCとしては、58万ぐらいで売ってる。現実的には20万程度のゲーミングPC。
- アセット(データ)が無いとゲームは作れない。
- ネット上にある3Dデータを使うのも可能。ただし、権利関係に注意。
- 中野シスターズは便利。
- ステージは比較的作りやすいので、自分で作ればいいと思う。
- VRでは、手元が見えない。コントローラあってもボタン配置が見えない。
- 視線・モーション・Oculus Touchで操作。
- 不用意な挙動をすると酔う。
- 座って体験するのが前提。
- 13歳以下は体験不可。
- ソードアート・オンラインは見たほうが良い。
- ゲームウォーズも同じく。
アプリ開発者が社会課題に取り組むABC
- オープンデータ・Civic Techはまだあまり知られていない。
- 「寄り合い」という地域コミュニティが強かった。
- テクノロジーで社会貢献ができる。
- オープンデータは国としての重要課題。
- 5374や保育園マップの事例。
- エンジニア・デザイナだけではなく、市民・行政など様々なプレイヤーを混ぜる。
- 経済的効果ではなく、教育や市民参画など社会にどれだけ広く影響を与えたか。=social impact
東京から地方へ〜ピグマルはなぜ拠点を地方に移したのか
- ドロイド君ロボットとか作ってた。
- FourBeatはAPI提供している。
- 上田市は16万人。
- 上田に行き着くまでに、国内・海外含めていろんなところに1ヶ月程度とか暮らしてみた。
- どこにいてもある程度開発出来るけど、ではそこにいる意味は?社会的異議。
- 長野県が募集していた。
- 長野市 or 上田市は県の判断だった。
- 仕事場はコワーキングスペース。多業種の人が集まる。
- 東京と地方の違いは、人の多さ。
- バスに人いない。勉強会が無い。口コミが機能しない。
- 東京は人が多い分、同じ興味分野の人でも集まれる。異業種の人と関わるしかない。
- それぞれの分野では、それぞれの課題がある。エンジニアが当たり前にやってることがありがたがられることもある。
- Try & Errorのやり方はエンジニアの得意領域なのでは?
- 成功・失敗に関わらず、客観的に評価できるアウトプットを出す予定。
- 2/20-21で上田でメイカーとメーカーが出会うイベントを開催予定。
- 半年後に上田にいて欲しいと思われるように頑張る。
研究室の活動や進路の話
- 高専の5年って、外で言っても伝わらない。
- インターンシップや共同研究から就職に繋がるケースがある。
- http://www.ishikawa-nct.ac.jp/info/20140820-0840.html プロジェクションマッピングとかやった。
- 小矢部ともイルミネーションとか、プロジェクションマッピングとかいろいろやってる。
LT大会
JAGがAndroidのアプリ教材を作りました。 http://techinstitute.jp/material/02/ 気持ちよくなる系が多い中で、結構網羅的な教材。日本語。 NPOとしてと、コミュニティーとしての日本Android(アンドロイド)の会
https://kzgame.doorkeeper.jp/events/33759 第4回 Oculus Game Jam in Japan 石川会場の告知。
授業変更が多い。 WEBで学内なら見れるが、自動スクロールしかない。 とりあえずAndroidアプリ化したけど、外では古いデータがみれるだけ。 オープンデータ化は大人の事情で出来なかった。 Googleアカウントが配布されているので、その認証を必須にすることで回避。 今後はネイティブ化してPUSH通知を付けたい。他データとの結びつきもつけたい。 球技大会の予定+結果速報表示も作った。
アンドロイドな女の子 OSじゃないアンドロイド 質量を持った仮想現実 機耳(ロボミミ) 思考を現実化する。
hackforPlay HPを書き換えることで、ボスを倒したり。 小学生が楽しみながらプログラミングを学べる。
Raspberry piでラズベリーパイを焼ける。(釜の開閉を制御) Huginで展開できる。 h264が扱いづらかったのでrtspで。 フレーム描画崩れたりした。 Unityでもやってみたけど、MotionJPGである必要が。 three.jsに乗り換え。 時間が来たので終了。また、今のAndroidで動くかは不明。
ABC来てね。 コミュニティなので、暴走・逸脱する人もいる。 誰かがやらないと、楽しいイベントは開催できない。 イベントに参加する人は、全力で楽しんで下さい。
全体的な感想
金沢でこんなにいろんな人の話を聞けて、ありがたかった。 富山や石川にいる人はもちろん、それ以外からの人も多く、色んなエンジニアと話せてよかった。 VRコンテンツが結構簡単に作れたのも驚きだった。ちょっと何かに使ってみたい。 あと、石川高専すげぇ。なんで富山に無かったのか。(違
Android Bazaar & Conference Diverse 2015 Kanazawa(1日目)
Unityで作るカジュアルVRアプリ
http://www.slideshare.net/kinneko/part3-unityvr
Unityを使えば、結構簡単にVRコンテンツが作れた。 PC上で見ると、こんなもんかーという感じだったけど、タオバイザーを借りて動かしてみたら、かなりちゃんと立体に見える。
marshmallow時代のAndroid入門
https://drive.google.com/file/d/0BwoRjQoZfQUlaWxmaFJ2QWttTlE/view
- Google Play Servicesが生まれたのは、Kindle Fireとかの勢力と差別化するために生まれた。
- 旧来のActionBarはシステムの部品として、上に何か(NavigationDrawableとか)を置けなかった。
- AppBarLayoutをかぶせると、文字色が白くなる。
- Android Design Libraryのサンプル https://github.com/chrisbanes/cheesesquare
- 通知にprivateとかが増えてるので、publicとかpriorityをちゃんと設定しないと。NotificationCompatが吸収してくれる。
- 2.3で落ちたりする
- https://github.com/keiji/AsUpdateChecker では、PreferenceFragmentCompatの表示バグがあったので、build variantを切り替えた。
- marshmallowでは、onAttachでActivityではなく、Contextが渡されるようになった。
Android6.0のセキュリティ事項
http://blog.riskfinder.co.jp/ にあとから上がるらしい。
※追記:上がったので追加
ABCD金沢の講演資料 (Android6.0のセキュリティ) - RiskFinder株式会社ブログ
- 新しいのは、Runtime permission model
- チェック結果を保存したりしてると、裏で不許可にされたときに困る。API実行前に毎回確認すべき。
- permissionはgroup単位でしか指定出来ない。READのみとかは出来ない。ただし、WRITEも使うのであれば、今後のバージョンで変更される可能性があるので、いちおう指定しておく。
- uses-permissionは必要。
- Android-RuntimePermissionsというサンプルコードがある。
- 剥奪しても、SecurityExceptionとかは出ない。空データが返ってくるものが多い。(互換モード)
- ただし、Cameraは落ちる。
- 不許可にするときにエラーメッセージが出るから、対応しないという選択肢もあり。
- checkSelfPermissionは注意。
- PermissionCheckerのを使いましょう。(互換モードで戻りが違う)
- 許可を求めるタイミングの設計。
- アプリの本質に関わるものは、起動時に聞く。
- 許可の説明が必要になってくる。
- なるべく早くやったほうが、他アプリとの差別化要因となる。(権限が要らないアプリの方が、インストールしてもらえる)
- dangerousレベルのpermissionはユーザに聞かないと行けない。
- オープンソースで多くの人が使ってるからといって、安全ではない。
Androidに対する攻撃事情 (2015年版)
- Stagefright
- Certifi-Gate
- mRSTに見つかった脆弱性
- mRSTには認証機構があるけど、その実装がマズイ。
- 認証をごまかし、本来システムレベルの権限で動かせてしまう。
- 報道が的を射ていない場合が多い。
- なにもないところからインストールするケースはまだない。
- マルウェア
- SMS送信マルウェア(日本だとあんまり無い)
- 架空請求マルウェア
- 日本で発生し、脅迫の効果を高めようとしている?
- サンドボックス回避(root化)が2015年に3種類。Shedunとか。
- 出荷時の状態にリセットを行っても消えない(システムに書き込まれる)
- Google Play上にはほとんど公開されていない。(非公式マーケット)
- 日本独自端末は意外とやりづらそう。
- Moplus SDK
- iOSでは、Party Trackを組み込むと、アプリ全体のTLS/SSL通信が危険になるのがあった。
エンジニアとコミュニティ活動
- ブログ読んだこと無い人はいるかもしれないけど、本読んだことない人はいない。けど、本出す人は少ない。
- 円卓で企画会議してるらしい。14人とか?
- 読みたいものを出しあう。デスノート的。
- Wordはやばい。バグ混入しまくる(見出しのサイズが揃ってないとか)
- 本をビルドするCIサーバはDockerイメージとして配布してる。
- 普通の本は半年以上かけるけど、テクブの同人誌は1,2ヶ月で作ってる。
- 趣味に必要な作業的なものを、テクノロジーで減らしていく。
- 金銭的な報酬は、見合わない。
- 中国語とか英語で本をかけるのであれば、けっこう儲かるかも。
- 電子書籍は20%以下。
- コミケは年に2回しか無いので、辛さを忘れちゃう。
Windows 10 とマイクロソフトのクロスプラットフォームへの取り組み
- 昔、エヴァンジェリストはIBMとMicrosoftしか無かった。
- エヴァンジェリストの意味としては宣教師。
- Windows8.1の次を考えた段階で、スマホ・タブレット+次のデバイス(IoT)まで戦場が広がっていた。
- Windows10はPC用だけではなく、様々なプラットフォームで同じOS。
- Cortanaという音声アシスタントが付いた。Siri的な。
- キーワードを設定してアプリを作ると、パラメータ付きでアプリを起動してくれる。
- IE12は出ない。IEのバージョンアップは利用企業が怒る。
- EdgeのUAは他のUAの全部入りみたいな感じ。
- Visual StudioでCordovaが使える。
デバイスコネクト(デバイスWebAPIコンソーシアム)ハンズオン(仮)
- GotAPI:スマホ上でWebサーバを立てるときの仕組みを仕様化したもの
- IPネットワーク層を経由し、ネイティブ上の仮想サーバからデバイスを操作できる。
- セキュリティ面でいろいろ頑張ってる。
- サービスIDを指定してGETリクエストを投げると、各デバイスの情報を取得できる。
Oculusによる最新VR動向とGear VR開発テクニックについて
- ソーシャルメディアがテキスト→写真→映像→の次はVR/AR
- ハードウェアはほぼ原価で売る。VRを広める。
- 儲けはVRプラットフォームで得る。
- Oculusは社名で、製品名はRift。
- DK2より製品版ディスプレイが良くなってる。ヘッドホン内蔵(取り外し可能)。IPD調整可能。
- GearVRは、センサ類は独自に持ってる。
- 白猫など、日本のデベロッパーもアプリを作ってる。
- Riftをかぶるとストアが表示される。
- Touchというデバイスで、手の位置や回転をトラッキングできる。
- VRは体験してみないとわからない。
- 社内でスタジオ作って、動画とかを作ってる。
- 快適な体験を第一に。一度酔ってしまうと、次から試してみなくなる。
- 快適レベルがストア上で表示される。
- ベクション(目で感じる加速度)
- 目の入力と三半規管の入力が違うと、体調不良として脳がエラーを出す。
- テレポートで移動させる仕様にすることで、VR酔いを防いだ。
- VR向きのデザイン。
- 格ゲーをスマホでやるのは辛いのと一緒。
- アセットを共通化するだけで、別のものを作ったほうが早い。
- フレームレートをキープする必要がある。
- 開発リソースは全部無料。デバイスがあれば、できる。
- 資料の日本語化を頑張ってる。
- Unityにネイティブで対応している。チェックボックス1個で対応。
- http://ocul.us/jplinks
LT大会
数十人規模の前でのLTは初めてでした。 かなり緊張しましたが、多少笑いも取れた気がします。 また、Qiitaのストックが5件増えたので、良かったかなと。
AndroidWareの話は「まっぱで出来る」がキーワードでした。 ただし、そのまま風呂に入ってはいけない。
浜松は、うなぎの出荷額はそこまでじゃないらしい。 餃子の消費量は1位か2位らしい。静岡市を足すと1位。 浜松支部は、BBQとか楽しそう。
秘密結社の発表はかなり面白かった。 THETAとか買うと高いし、ある程度制限されるけど、Raspberry Pi+カメラモジュール+レンズで作れるらしい。 レンズの調達が難しそうな印象。