Tweet

デブサミ初めて行ってきました。備忘のためにレポします。

Disclaimer

• 聞き取ったことのメモです。聞き取りミス等あると思います。
• 発表者のスライドで補填していこうと思っていましたが、2/23現在、まだあまりスライド上がっていないようですね。。。

---

下記、長文のため、先にまとめておく

まとめ

• デブサミ初参戦だった。
• 一番笑えたのは、ラストのコマのLT大会での、Seleniumコミュニティのやつ
• 次に笑えたのはドワンゴの川上さん
• 技術的に面白かったのは、paizaのDocker利用事例
• 結構スーツのおじさん多いなと思った。あと居眠り。
• ２日目のほうが顕著だったけど、スライドをカメラで撮るのは全く意味がないと思った（だってどうせ大半のスライドは上がるから）。
• 講演資料のまとめはココ

---

10:00～11:50【19-A-1】Growth！エンジニアとサービスと組織が成長するために 川上 量生〔ドワンゴ〕/喜田 一成〔ドワンゴ〕/簗島 亮次〔インティメート・マージャー〕/長尾俊〔ヒトクセ〕/筒井俊祐〔ヤフー〕/【司会】杉浦 正明〔ユーザベース〕/【司会】宮原 忍〔KADOKAWA〕

ドワンゴCTOとしての仕事

http://weekly.ascii.jp/elem/000/000/305/305784/

• ドワンゴ会長兼CTO　川上さん

• ドワンゴIT業界でハブられてる？

• TechCrunchをDISり,講演者をDISり

• 「勉強会に行って本当に勉強になる？」

• スタジオカラー取締役！（庵野秀明のところ）

• 象徴CTO制　→　名誉制、なにもしない！

• ドワンゴのエンジニア大量離脱

  • なんで？複数の理由

• 川上さんの勉強方法、独学多し（マーケティングなども）

  • 逆アセンブラ、マシン語、CAD開発

• 社会人の時に勝手にDB+LANを構築

• 起業はおすすめしない。安定しないから！　

  • 自身は起業したのに就職したりしてるｗ

• ドワンゴでも実は数十行だけコード書いてた

• まとめ：エンジニアとして実務的には最近全然〜

• 自分がエンジニアだとは言わない（外から言われるものも本意じゃない）

• CTOの最初の仕事↑

  • 過去のドワンゴ：社内の雰囲気わるかった
    • 時間にルーズだったのを、←女子マネ弁当
    • 会社が地味な場所←歌舞伎座へ移転
    • 開発言語への不満（PHP）
    • 給料が低い←「わりと」上げた。社員の労働時間あまり多くないと思うので、上げ過ぎないようにした

• 2年前のやつ　技術的負債、Scalaで書きなおしているはなし

  • 循環的複雑度　超高い
    • ↑作りなおしたほうがはやい！
    • 補足：循環的複雑度 とは、すごくざっくり言っちゃうと、そのソースコードのバグ修正の難易度

• ↑を応用して作らせたレポート

  • 法律の複雑度を分析　←ソフトでの分析を応用できないか？
  • ↑プログラムとしてはメンテしやすいのもあった。
  • 著作権法47条の10やばいｗ
    • 構造化するとコピペがあるｗ
    • 複雑度高い！　←専門家じゃないと改正不可
  • 法律の複雑度も上がっている。　←　書き直しが提言できるのでは。
  • これがCTOっぽい唯一の仕事ｗ

• CTOを３年やってみて

  • いまはスクリプトの時代
  • コンピュータの動作原理を知らないで作ってる
    • ブラックボックス
  • 性能限界は計測する（計算しようとしない）
  • 過去の知をもとに、議論がタブー化されている

• 半導体業界の人の話を聞いた

  • ムーアの法則
  • ↑膨大な数の「二流」の設計エンジニア
  • 優れた回路設計よりも　新しい向上でつくったほうが速い
  • ムーアの法則が破られつつあり、二流の回路設計エンジニアが食えなくなってきた
  • ↑WEB業界にも当たるのでは？

• サーバの性能が上がってきた、AWSらく。　←膨大な数の「二流の」WEBエンジニア　←総本山デブサミ

サーバの性能が上がってきた、AWSらく。　←膨大な数の「二流の」WEBエンジニア　←総本山デブサミ くっそｗｗｗ #devsumiA

— takudo (@takudo_dev) 2015, 2月 19

• 今後ドワンゴをどうするか

  • 技術の理論的限界でサービスを設計！（計測じゃないよ）
  • 自社のハード、データセンター、シェアハウス
    • シェアハウス一番やりたい

• ニコキャス帰ってきたらよろしくｑ

  • ニコキャスは読み間違えた、失敗（いままで大きな失敗したことなかったのに）
  • もう一回勝負したい！

質問タイム

• Q:技術的限界からサービスを考える、ユーザニーズからサービスを考える、どこでバランスを取る？

  • WEBは新しい世界。日々技術革新。できることが増えてる。企画者が開発のことを知っていたほうがいいかどうか（苦労をみるべきかどうか。技術的にできることを知っているかどうか）。　技術を知っていて、開発をした方がいいと思っている。←日本のWEB企業の戦略は違う。　開発者が起業するのが一番いいが、能力偏っている。そこの境界でベストを取るべき。
  • 今年の新卒から、企画職でもプログラミングを。角川でもやる。編集者なのにプログラミング研修ｗ

• Q: クラウドがあれば組織に属さなくても二流のプログラマでもそこそこの物が作れる。組織に属す意味は？

  • 世の中は個人では何も出来ない。
  • 一次的に個人が活躍できるタイミングがあるが、それはどんどんなくなってくる。
  • 今ある環境でなんでもやるエンジニアは一流。
  • 個人でできる競争は低い競争。すぐに太刀打ちできなくなる。
  • ソシャゲでも、個人でもヒット作は出せない（CMとか）
  • 個人で何でもできるっていう時代は終ってくる

• Q:社内の雰囲気は？

  • あんま会社いないからわかんないｗ
  • あんま社員と飲んだりしないｗ
  • なんとなーく
  • Twitterで社内情報漏洩ｗしてるからそこで社内情報補充

• Q:社員のことをネガティブなことを発言するけど、ドワンゴの強みは？

  • うちの会社は強くない。喧嘩したら弱いｗ
  • 危機感持ってほしいなと思ってる
  • ドワンゴエンジニア辞めない　→　居心地がいい
  • ギークたち（はみだしもの）をうまく使って成功してきた人たちいっぱいいる
  • 会社を作った動機が、競争じゃない。居心地がいいところを作ってしまった。

---

感想

• 象徴CTOってなにｗ

---

第二部：リレーセッション

• 司会の自己紹介

  • 杉浦さん　：newspics
  • 角川　宮原さん

• テーマはエンジニアのGrowth。4名のリレーセッション。

• 個人の成長と、会社の成長をどう一致させるか。

• 杉浦さん：新卒のときはSIer。社畜の鑑やってた。

ドワンゴの新卒エンジニアが新規サービスを立ち上げるまで　喜田さん @nalgami

• 「ニコニ立体」2014　5月リリース　３Dモデルをブラウザ上で閲覧
• 新卒エンジニアへすべてを投げたらどうなるか　
• はじまりは研修
  • 何かを3人で1ヵ月でつくる。言語問わず。
• ３Dモデラが投稿する場所がないことから、つくってみることに

• ３Dモデラの問題

  • モチベーションの維持（1体で数ヶ月単位）
  • 人が少ない（ノウハウ共有の難しさ）
  • モデル自体でなく、モデルを利用した作品が注目されがち。

• 3Dモデラが注目される場所をつくろう。

• ☆MMD

• 新卒エンジニア3名、内定エンジニア1名

• Rails, Azure, Unity

• Rails脱線

  • Unity Web Player の初期化がおそい。☆Railsのターボリンク機能
  • ActiveRecord　AzureSQLの相性悪し　SQLServerといろいろと挙動が違う。
  • ３Dモデルバリデータ。

• インフラ

  • みんなでやった
  • 監視　NewRelic （すごくいい）

• リリースのための社内調整

  • 事業計画、予算等の承認
  • サービス名の命名
  • 脆弱性診断
  • プロモーション戦略

• ユーザからの不満

  • 企画でも戦う！
  • 公開質問状への回答を真摯に答える（ユーザの不満を解消）
  • ライセンスフリーの３Dモデルを提供　商用利用も可
  • モデリングコンテスト

• 新卒エンジニアは何をえたか

  • 広い視野、キャリアパス
  • 色んなコトやったので、何に向いているかが見えてきた
    • インフラ、バックエンド、フロント、ディレクター、企画？
  • 営業に優しくなったｗ

---

プロダクトが完成するまでにいるものいらないもの

インティメートマージャー　簗島(やなしま)さん

• プロダクトをどう作っていくか
• グリーに新卒（2010）
• 2012 フリークアウト　→　会社やれといわれて2013から会社を
• データマイニング専門、統計専門、機械学習

• ハフポストで連載

• 属していた会社組織の規模

  • グリー　150 → 2500　（2年で急増）　→　いろんな人がいるけど統率が取れてない
  • フリークアウト 50人　何でも屋
  • 会社作った時　0人

• いろんな立ち位置でプロダクトに立ち会ってきたので、その経験から

• 一般的なプロセス

  • 開発内容の決定
  • スケジュール
  • リリース承認
  • βリリース
  • 改善

• あるあるシチュエーションから　いるもの、要らないものを。

• 開発内容の決定

  • 最初は夢が詰まった企画案が出てくる。仕様は「いい感じ」ゆるふわな画面遷移
  • 盛りすぎると何をやればいいかがわからなくなる
  • 現実は　諦める、有限
  • 最高のプロダクトのイメージを共有。
  • 有限の時間を考えて、諦めるものを考える（削る、削る理由が大事）

• スケジュール

  • ガントチャート全部同じ期間、優先度全部高い
  • 優先度の順番を決める
  • 念入りにいろんな人に話を聞く
  • スケジュールに責任者をつけて、「断る」
  • 最終的にスケジュールが最も圧縮できる形が理想
• • リリース承認
  • Ver1.0が出ない
  • 何をしたら出していいのかわからん
  • 完成度、改善案
  • リリースの責任者が火の粉をかぶる。逃げない
  • いろんな人から話を聞くが、全てを真に受けるべきではない

• 改善

  • いざリリースが終って疲れちゃう
  • 改善プロセスには新任の人を（既存を否定するので）

• 有限・諦め・断る

  • 要らないものは「責任の所在があいまい、なんとなくなもの」

---

開発者は足を動かそう

CTO ヒトクセ　長尾さん

• メタル好き
• ブレイクダンス
• 指向性スピーカー

これから事業を始める技術者の方へ

• 反面教師として

• WEB広告、リッチ広告、広告作成のサービス　ただ動く広告ではなくクリエイティブにかかわるところのソリューション

  • クリエイティブをデータドリブンに

• 2年前はお化けが出てた（小さいアパート）

• SmartCanvas　自分でアニメを作る！

  • ↑全然儲からなかった。
  • 顧客への理解が足らなかった
  • 失敗からいろいろな事業者からヒアリング。
    • 広告業界へ

• 自分本位から、ヒアリング駆動の開発へ

  • ニーズを見つける！
  • 技術にとらわれ過ぎる（技術はあくまで手段）
  • 開発が詰まってても、日に1、２件は外回り

• ユーザの心拍数によって広告を出し分けたい、という無茶ぶり例

  • 興奮度をがわかればいいのか？

• 技術は手段でしかないので、何通りもの解決策

• 相手にも技術を理解してもらう

  • 例：iframeのクロスドメイン制約など
    • 相手にはいちから説明をしている。
    • 営業にも高いリテラシーを求めている
    • ニーズが的確になる
    • 技術の信用度が上がる。

• 一歩先のニーズ

  • ネイティブアド
  • 特許出願中
  • 技術者がビジネスの最前線にいること。で新しいものが生まれる！

• エンジニアも外回りをしている　→　ビジネス理解

• クライアントの犬ではなく寄り添う開発者に！

---

Yahoo JAPAN エンジニアと組織とサービスが成長するために

筒井さん

2005年ヤフー入社。アプリ推進本部部長

• 起点アプリ部
• Yahooの黒帯

• Yahoo内のエキスパート人材を黒帯認定

  • 2000名の中でエンジニアは20名程度

• 成長

  • 登る山を決める
  • 一歩一歩進むことで成長

• サービス・組織・エンジニアの歯車を回すイメージ（成長サイクル）

• スキル成長

  • スモールチームの密なコミュニケーション
  • github Enterprise
    • レビューしあう！　レビューOKならマージで自動ビルド

• サービスの成長

  • KPIを毎日チェック
  • PDCAサイクルを回す。
    • 効果測定でちゃんと理由付け
    • 看板の導入で個人作業の見える化

• 組織の成長

  • 表彰する場を作る（スーパースターを表彰）
  • コメントやプレゼントなどで盛り上げ

• 成長を促す

  • 1on1　毎週、隔週で上長、PMといろいろはなす

• まとめ

  • 登る山をきめる

---

2015-02-19 12:10【19-C-L】2F C会場（華うたげ） エンタープライズ要件に対応する高品質なCordovaアプリ 田中さん @massie

• エンタープライズ　高品質なCordovaアプリ

• HTML5エキスパート

• CEO

• Apache cordova HTML5アプリ開発フレームワーク

  • エンタープライズ向け

• なぜエンタープライズで？

  • クロスプラットフォーム（業務用向いてる）
  • アプリの順位気にしない
  • Apple,Googleに振り回されない　←オープンソース
  • 運用　←　HTML５ベース（後方互換）
  • デファクトスタンダード
    • （？そうなの？もともと選択肢が少ない、とかは無いのかな？）
    • ほかには、PhoneGap
    • PhoneGapとの違い
      • PhoneGapがAdobeに買収（OSSからプロダクトに）
      • PhoneGapからCordovaに
      • PhoneGap←Adobeのプロダクト
      • Cordova←OSS　
      • Linux　ディストリみたいなもん

• Cordovaが様々なソリューションに組み込み

  • VisualStudio

• HTML5ハイブリッド大丈夫？

  • 昔２０１０年は携帯端末のパフォーマンスの問題あったけど、今は大丈夫よー（HTMLでも遜色ない）
  • Javascript のエコシステム
    • IoT
    • Mac のAutomation

• よくある課題

  • 遅い
  • JavaScriptの言語上の問題
  • 担当者がネイティブやりたい
  • HTML5のセキュリティ

成功するCordova（ハイブリッドアプリ）

• 要件定義は慎重に

  • クロスプラットフォーム、Web、アプリの洗練のどれが重要？
  • 開発のコスト
  • 対応端末の選定（２年前くらいの端末厳しかったり）
  • AltJS、開発フレームワーク選定

• UIとパフォーマンス

  • JSは遅くない、ライブラリが遅い（jQueryMobileなど）

• 実機テスト

  • ネイティブレイヤーの課題・バグは半分くらい
  • 常に実機でテストを心がける
  • 機種を一杯やるのをつきつめすぎない

• セキュリティ

  • XSS
  • アセットの難読化（ミニファイのこと？）

• Cordova勉強会は随時

  • 第五回は３月予定

Monaca ←Cordovaベース　アシアルで作ってるやつ

• Cloudベースでソース管理
• ローカルでの開発も
• Monaca for VisualStudio
• エンタープライズ向け開発プラットフォーム
  • 難読化　→　暗号化（HTML５リソース）
  • アプリの自動更新　（HTML5レイヤーはすべて置き換え可能）

Onsen UI フレームワーク（AngularJSベース）

• 海外でよく使われている

• OSS

• Monacaとは？

  • 開発環境
  • Cordova
  • Fork してね（github）
  • コードを書けない人のためじゃない

• 無料サポート、StackOverfloｗ上でやってる

• 書籍がAmazon１位になった

---

2015-02-19 13:05【19-E-3】2F E会場（華しずか）paizaのオンラインジャッジを支えるDockerとその周辺　吉岡 恒夫さん〔ギノ〕

• Paizaを利用して、Paizaに入った

• オンラインコーディング環境　paiza.io

• Docker の紹介、使っている理由、経緯、方法

• Docker コマンド叩いたことある　→　会場半分

• paiza内で作っているコンテナ数　→　月あたり520,000(2014/ 12)

paizaについて

• コーディングスキルチェック　→　企業とプログラマのマッチング
  • ？codeIQとの住み分けというかそのあたりは？
  • コードを提出すると、サービス側でテストケースを通す
  • ランクと対応した年収が出てくる
  • ジャッジシステムは、コードの実行と、出力の正解判定のところ

paizaジャッジの要件

• 不正不可（コードの保護など）
• 公平なリソース
  • CPU等はサーバ側で、一定のものが使われるように（性能差が出ないように）
• システムが壊されない！
• 自由な環境
  • 言語や実機同様の環境

• 速い、スケーラブル

• コードの実行環境の安定動作

  • コードの実行環境の孤立・独立化　←　仮想化向いてる
  • 仮想化の手段
    • ディレクトリ制限　☓　CPUなどのリソースの制限は不可
    • 仮想マシンか、コンテナ仮想化か。。。

Dockerについて

• Dockerの概要をつらつらと。。。

  • UnionFileSystem
  • cgroups（リソース制限）
  • NameSpace隔離

• Mac上でコンテナ１００台動くか

Docker 利用方法

• CPU　AWS c3.2xlarge

• コンテナごとのリソース管理どうしているか。

  • 何もしなければ運に左右されちゃう
  • コンテナのCPU数を制限（コンテナがCPUを独占するようにする）
  • サービスとコンテナでCPUを分ける
  • Intel系のハイパースレッディングとの関係
    • 1コンテナに、1物理CPUコアを対応させる（論理的には２CPU）
    • AWS上でハイパースレッディングOFFにできない
  • メモリ制限（言語ごとに設定はちゃんとしている、Java、PHPなど）
  • プロセスの利用制限
    • プログラム内でプロセスを複数作る
    • Docker自身では防げないので、Linux のユーザ資源でプロセス数を制限
  • Disk領域の制限
    • Linuxの機能（ディスクQuota）でユーザ単位のディスク制限を
  • ネットワークの利用管理
    • ネットワーク無効化（テストケースの漏洩防止）
    • bridgeでネットワーク仮想化
    • NATのコネクション管理
  • コンテナイメージの読み込み
    • メモリ上に保持して速い
  • 実行速度0秒の人がいるｗ
    • timeコマンドをいじれないように

• スケールアウト

  • リクエストはキューに入れてる（RabbitMQ
  • 間にキューを入れて、Dockerホストが取り出している？

• ジャッジシステムの活用

  • OnlineHackathon
    • 勝手に中国語版ができている
  • 最近の動画プログラミング学習サイト *（ ？言語選べるのかな？　）

Dockerの利用目的

• 軽量で高速　を利用
• 8つの利用目的
  • 管理のカンタン
  • 環境依存の削減
  • 開発・本番の環境の同一化
  • マイクロサービス化
  • サーバリソースの節約
  • デバッグがカンタン
    • （？理由はなんだったか？）
  • 複数テナント
  • デプロイ高速化

Dockerの動向

• ☆Rocket
• ☆LXD
• ☆Vagga

---

感想（というか疑問）

• DockerホストのOSは何を使っている？
• 今どれくらいDockerホストが立ち上がっている？（ホスト側もオートスケーリングしている？）

---

2015-02-19 14:10【19-B-4】2F B会場（夢扇）IoT は総合格闘技である(仮)　太田 寛〔日本マイクロソフト〕@embedded_george/大田 昌幸@masota0517〔日本マイクロソフト〕

• 参加者みんなデベロッパ

• IoTとは

  • モノ
  • ものをつなげる
  • モノのビッグデータ
  • ビッグデータ分析

• デバイス　⇔　サービス（クラウドてっとり早い）⇔　クライアント（分析系の端末をイメージ？）

  • データ活用の事業者、運用監視会社

• IoTアーキテクチャ概観

  • 要素いっぱいあるから　←　総合格闘技！
    • 要はやることいっぱいある（1分野だけやってりゃいいってことではない）

• Intel Gallileo

  • ブレッドボード持ってきてる
  • Windows開発ツール充実してる（デバイスマネージャ的な？）
  • Lチカ、距離センサー

• デバイスごとのコード書くのがしんどいのでツールの紹介

  • ガジェッター
    • デバイスを、GUIで操作（Form作るイメージ）
    • デバイスの接続方法を推薦してくれる

• .NET Micro Framework

• 各種連携していくこと

  • 沢山のデバイス　取りこぼし・レイテンシ　どうする？どうやってさばくか
  • 「EventHub」（MSのPaas）

• 隠し技　ExcelPowerQuery Galileoでとった距離データをエクセルに入れ込む

---

ここまでデモ

• 総合格闘技で勝つために
• StreamAnalytics
  • F１のロータスの組み込み版のやつ
  • リアルタイム蓄積・分析
  • MachineLerning
    • 予測（機械の耐久度など）
    • 分析
    • Excel Power Query で手元で分析
• またデモ

---

• 地下鉄の遅延状況、機械の状況など　→　メンテナンスを行ったり
• ドイツ　ThyssenKrup　（エレベータ会社）
  • エレベータの配置マップ
  • エレベータの稼働状況、トレンド
• .NETMicroFramework の実例、MSの３０F のオフィスで出てる

---

ここまでデモ

• IoTをすぐにやる会社多い。考える前にもうやっちゃう

  • 小さく始めて大きく育てる。失敗しても捨てられる、クラウドなら

• 守・破・離

• MS　でIoTキットのハンズオントレーニング

• IoYT 普及コミュニティー　3.15キックオフ　品川MS本社にて

---

感想

• さすがMicrosoftメイリオフォント
• Androidのところ、ちょっと流れがわからなかった

• AndroidのエミュレータもMS製なのか

• LondonのIoT（地下鉄のやつ）、これはアプリとして提供しているのか？（業務系っぽい）

• センサの誤動作とどうやって付き合っていくのか？

• まとめると、単にMSのツール紹介な感じ。手を動かすデモは良かった。

---

2015-02-19 15:15【19-D-5】2F D会場（華つどい）JavaScriptフレームワークの歩き方

※早すぎてついていけなかったので、あとでスライドで補完したい

JS全体観　まとめ

JS　MVC　 Wikipedia　Comparison of Javascript Framework

• Angular.js
  • DI 珍しいので把握しておくとよい

著名な奴の比較

Angular.js

• カンタン
• 手厚いサポート（これだけ開発している人がいる）
• 欠点
  • 使い方を覚える
  • 魔法だらけｗ
  • ☆関心の分離　の法則違反

Ember.js

• Ember Way という一貫した哲学　←　逆に捉えると、柔軟性に欠ける
• 問題解決済み
• ドキュメント良い！

Backbone.js

• 小さい　テスト済
• 多くの「基本的な」問題が解決　（？基本的？）
• Backboneをベースに、自分たちのフレームワークを作る必要あり

React.js （ビューのみ FWに入れていいか）

• ハイパフォーマンスレンダリング
• ステート管理の簡易化（状態の管理をシンプルに）
• 単なるView。。。
• テンプレートのSyntaxが不自然。←気持ち悪いらしい
• ファイルサイズ　大きめ

Undirectional Data Flow

• Action
• Dispatcher
• Store
• View

アンパサンド.js

• 柔軟性と結合性のバランスがいい
• コマンドラインツールの充実（反復性の向上
• 若い
• IE8以下のサポートなし
• ↑スピーカーの感じ、結構よさ気

オーロリア？.js

• 上書き・差し替えが可能
• ES6,ES7へのフォーカス（言語レベルで足りてないところを補足）
• モジュラー性が高い
• まだ若い　←　まだまだ感がある

• IE11以下のサポートなし　←思い切ってる

• どれがベストかは、時と場合による（全部メリット・デメリット持ってるので）

• ツールを探すことはゴールじゃない（問題が無いのに、探す意味が無い。）

プロダクトのステージはどこなのか？

• AngularとEmberはすでにできているものに組み込むのは難しい
  • Angularは初期ステージでこそスピード感が活かせる
  • Emberの堅さは管理画面などにこそ向いている
• 徐々にMV*な設計に
  • jQuery, Backboneなど向いている

• 変更に強い設計（WEBは25歳）

  • AngularもEmberもいつかは置き換えられる。
  • WebComponentsやES6,7が出てくる
  • 変わることを前提に！
  • 置き換えのしやすさを視点に　←　壊れた時に勇気をもって変更を！

• Unix哲学から

  • 小さいが正義
  • プロトタイプはさっさとつくる！

• Node.jsは新たなエコシステムを提供したなー

  • ツールの一部として注目しておいて損がない

• 変化に対応するために、Javascriptの基本を覚えている必要があるよ～　

  • まずはBackbone.jsのソースを読むといいよ（コメント含めて1200行なので読みやすい）
  • Underscore.jsのソースもおすすめ（関数型、
  • 読むべき本
    • オライリー「Speaking JavaScript」日本語訳無い
    • Eloquent JavaScript　基本を学ぶことに欠かせなかった
    • Effective JavaScript　←日本語訳あるよー

• CSSとHTMLを学ばないといけない

  • HTMLが汚いとCSSも汚い
    • スキルセットとしてHTML・CSSがちゃんと書けるか、みんな見なおすべき

　選定ポイント

• Lock in はどれくらいか
• 頑固な設計
• 不要な複雑性、フレームワークとどれ位戦わないといけないか？
• FWがテストしやすいか？　エコシステムもココを指しているのでは。ツールによる補助

終わりに

BOXのエンジニア（Dropboxみたいなやつ） JavaScriptはもう十分ｗ

JavaScriptは、全体を囲っている薄いレイヤ

安定性、パフォーマンス、Reach（なんて訳せば？「コンテンツを届けること」）

• プロダクトに責任をもちましょうー＞　作り手

*「すべての人が同意見なら、プログラミングはつまらなかった」Node.jsコントリビュータ * 答えを探すきっかけになれば

---

16:20～17:05【19-C-6】Android 5.0 と Android Wear で広がる最新アプリ開発技法 松内 良介さん〔グーグル〕

アジェンダ

• Android 5.0のAPIマテリアルデザインの話
• Androidの通知の状況（Wear,テレビ）
• アプリの品質

5.0 とマテリアルデザイン

• UI の試行錯誤（Gmailの例、ProjectKenedy
• Androidの表現統一感無い
• マテリアルデザインはガイドライン
  • 審査なんて無いよー
  • 時代に合わせた推奨の考え方
• 手触り、印刷物、意味を伝える動き、画面サイズ変化に対応 ### 手触り
• Z方向の高さ　←　例えばAndroidの厚さを意識した影の表現
• 吸い付く表現TranslationZ
• CardView（リスト表示でポピュラーになっていく

印刷物

• フォントの使い方
• 目立ってほしいものをとても大きくして、その他を小さく
• 色も重要！、PrimaryカラーAccentカラー
  • ダイナミックカラー
• FloatingActionButton　直感的操作に使える

意味を伝える

• 視覚的な修飾だけでなく、空間的な意味を伝える
• 遷移に連続性を
• Revealアニメ　ある点を中心に次の画面に遷移
• InterPolator　機械的ではなく、加速度をつけて、いきいきと動かす

画面サイズ変化

• 異なるデバイスで一貫した表現を
• RecyclerView　画面サイズの連続的変化に比較的楽に対応

---

• 開発者向け情報はサンプルコード、動画、ブログ記事の翻訳、「FORM SF」

---

Android

• Android Studio 1.0 （正式版出た）
• 64k メソッド上限対策
  • Dexファイルの分割
• 消費電力の最適化（Project Volta ）Battery Stats
• Dalvik→ART

Rich Notification

• 全4種類
• NotificationCompatクラスを使う　→　古いAndroidでは表現が省略される

AndroidWear

• アイコンを選ぶということはやらない
• 作成の方針：アプリの起動は自動で！、ひと目で分かるUIに、ユーザに提案するような対話型、操作を最小限に
• アプリの操作が難しくなってくるので、自動的に。IoTとかでもそういうふうになっていくのでは。環境の一部として考える。
• 通知の実装方法は、スマホ・タブレット向けと共通
• 音声入力がポピュラーになってくる（入力できないから）
• WatchFaceAPI
  • きせかえアプリ
• 開発者向け情報
  • サンプルコード、WatchFaceテンプレート、解説動画（Youtube）

Android TV

• 基本はAndroid5.0 UIはテレビ向けに
• NexusPlayer　テレビ向け端末（AppleTV的な）

期待されるアプリの品質

• ユーザ評価と収益性の相関

  • 4~5の星のものは収益性がそれ以下の星のものと4倍利益が違う
  • ↑アプリ内広告でも、重要。良い評価が必要
  • 星の数はどこから？
    • ネガティブな意見を分析
      • さくさく
      • Webよりもアプリが欲しい
      • プラットフォーム標準との乖離が無い　それが無いアプリだと、摩擦を感じる　→　とりまく全体として、標準的なUIに統一していくべき
      • ↑オレオレUIはストレスになるよー

• Nexus５/7以降のUIに合わせて作っていくべき

  • 標準UIを使えば、実装コストは低い

• （アプリの）劣化コピーーの悲劇

  • WEBアプリ　→　ネイティブなど（このコピー時に劣化）
  • コピーがちゃんとしていれば（プラットフォームごとの最適な表現）、でユーザの幸福度を

• 賢い通知

  • 例えば、夜中に天気予報を見たとしたら、気を聞かせて明日の天気をだす、など
  • うるさい通知は即効アンインストールされちゃうよ

• マルチデバイスだからこそユーザを魅了するアプリを

  • ひとつひとつのデバイスを丁寧に
  • ストレスレスに
  • 省電力に
  • 良いアプリの参考：goolgeのベストアプリの選出　（google社員が見てもよいもの）
    • Wantedly,iQONなど

• 開発者向けコンテンツの充実

まとめ

• マルチデバイス、マルチスクリーン化
• コンテクストを考慮したユーザ体験　アプリがうるさい、にならないように　より賢く
• 品質向上！　ユーザの期待値が上昇しているので、それにちゃんと応える

---

感想

• googleの人だった
• 情報量多いので後でスライド探そう
• AndroidTVは、ChromeCastとうまいことやってくれたりしないかなぁ。むりかなぁ。

---

2015-02-19 17:25-18:55【19-E-7】2F E会場（華しずか）デブサミ恒例！コミュニティLT2015

司会：まっちゃだいふく　さん

LT 制限時間 3:30

DevLoveさん

• 「DevLove はエモい？」
• 2008年からやっている rubykaigi
• 現場の開発誰が理想にしてくれる？　コミュニティを作るきっかけ
• 一人が関わることのできるプロジェクトは？
  • 限界あるので、いろんな人の知恵を得たい。他人の視点を得る
• 2名→2677人（東京）
• 300人月の壁を超えられる！
• 現場甲子園！
• 甲子園　といえば　灰になる青春を謳歌　←開発も一緒

Devlove pubさん

• publish のpub
• ラウンジで頒布している〜

• 技術系同人誌

  • コミケの1ジャンル
  • 艦これAPI　同人誌
  • 自分たちの気になること
    • アジャイルのラノベ　←　？仕事に役に立つ？ｗ

• コミケ　→　XP　→　コミケ冬　→　デブサミ

• 新刊紹介する

  • 翔泳社のひとAtomエディタ消化
  • 世界初　アジャイルラノベ

日本SoftLayerユーザ会

• IBMが提供するクラウドサービス　→　SoftLayer
• 2014年に出来たコミュニティ
• 日本語での情報発信を行っている
• ガチャガチャ
  • 運次第で何かが出る
• SoftLayer、物理サーバも時間貸し（ベアメタル）
• 実際オーダしてみた
  • 2core 2Ghz を注文した　→　サーバスペック高い！　マシンがなかったから無償でアップグレードしてくれた
• こないだSummitやった〜　全国でもやってる

java 女子部

• 去年出来たコミュニティ
• Javaで女子ならなんでもあり
• 超大和撫子（引っ込み思案）
  • みんなおとなしめ
  • アンケートぎっしり
  • 飲み会ではっちゃける
• Javaが肉食系だからついつい草食に
  • 「なにもしなくても30億のデバイスが迫ってくる...」
• ガツガツ女子を求めてる
  • ぜひ宣伝して欲しい

hcdvalue

• @chacahki
• 現場で使える人間中心設計の実践
• ISOできまってるHCDプロセスを勉強しよう、という集まり
• 職種や業種を問わずに募集している
• UXに興味があるひとのコミュニティ
• ☆「UX白書」
  • アプリの前後の体験もちゃんと考える
  • どうやってUXをデザインするかという研究
• これから
  • HCDの実践の素振り
  • HCDライブラリー本の読書会
  • ☆HDIfes 「人を巻き込む・チームを作る」4/12

JAZUG

• Azure
• @nnasaki
• Microsoft MVP
• Azure user group
• グループメンバ800名超えた
• 地方支部も

• GoAzure

• Azure なんでも使える

• Azure上のマシンも20％はLinux！

NPO IGDA

• ゲーム開発者を対象とした国際NPO組織の日本支部
• ゲーム開発者は自分がそう思えばそう
• ゲーム業界の内と外をつなぐ
• UXの可視化
  • ゲーム業界はUXの可視化をいち早く実践
  • 楽しい　→　コンティニュー　→　100円コイン（ちゃりん）
• 業界的インマニュアル、ドキュメント化が遅れている
• 習うより慣れろ！
• ゲームジャム　（ゲームのハッカソン）
  • コードを書かない人も参加
  • この週末にシリアスゲームジャム
    • 学生・プロ・セキュリティ専門家の混成チームで開発
• igda.jp

Debian JP Linux一般

• 食わず嫌いは良くない。まずは試す
• サーバだけじゃない
• 英会話スクールのクライアントPC、宇宙ステーションのPC、なども

• ディストリ日本だと偏っている？

  • CentOS
  • 証券取引所　→　redhat
  • Wikipedia　→　Ubuntu
  • Evernote → Debian
  • Openstack →　ubuntu
  • HP →　Gentoo

• 選ぶのみんな好きでしょ？

  • CentOSじゃなきゃいけない理由がなければ、違いを楽しんで下さい！

TOCfE Bootcamp

• ロジック好き、考えるの得意、コンピュータと対話、曖昧な言葉は
• 人との対話がバグだらけのことなんてないよね？
• 人との対話がバグる原因
  • 単語が意味不明
  • 文藻が曖昧
  • 因果が曖昧、因果が不十分
• いつやってる？（勉強会）
  • 次回　多摩川クラシコ
    • 対立を解決
  • 次々回　マフィアオファー
    • 断れない提案の仕方

アジャイルプロセス協議会

• 知働化フォーラム2015
• 2003~ 今年で12周年

Cordovaユーザ会

• ネイティブデベロッパーから嫌われている　（HTML5は使いたくない）
• HTML5、ネイティブAPI、クロスプラットフォーム
• Cordovaアプリも増えてきた
• LINEもCordova使ってる
• Cordovaのよくないところ　たくさんある
• ユーザ会を設立
  • お酒を飲みながらトークする
  • 月一でミートアップを

POStudy

• プロダクトオーナーシップ勉強会
• Scrumのプロダクトオーナーに特化
• より大きな視野での勉強会にシフト
• オンラインでの動画教材
• オフラインでの勉強会参加
• プロジェクトのマネジメントとプロダクトのマネジメントは別々の責任者を立ててる　←　海外
• 次やる　POStudy アイデアソン Tokyo

Selenium ユーザコミュニティ

• スライドのナレーションｗｗｗ
• 画面テスト・ツール　クロスブラウザ
• スマホはどうするのか？
• Appium
  • Seleniumと同じようなコマンド体系で
• コミュニティグループ
  • 2013/7 ~
  • オンラインフォーラム有り
  • 勉強会もやってる

Grails/Groovy UG

• 「javaはクソ」
• まともなJava、ましなJava
• Gradle　mvnやantの弱点を克服して、別の弱点を追加ｗ
• Jenkins,
• ☆Spock（テストツール Groovy でDSL）、
• ☆Geb（WebDriverでUIテスト　Groovyで作られてる）
• Vert.x,Rx-Java　
• ソフトウェア開発
  • 自分たちで小さな道具を作って、使う
• ワークショップ、ハンズオン
• ☆JGGUG G*Magazine
• Groovy Pivotalに捨てられる

OWASP Japan

• OpenWebApplicationSecurityProject
• グローバルなコミュニティ
• OWASP JAPAN
• Webアプリの脆弱性をTOP１０で紹介する「OWASP TOP 10」
  • ３年に１回
  • 日本語でも

• OWASP ZAP

  • 脆弱性診断ツール
  • OSS　無償

• ３ヶ月に１回、OWASP Night　カジュアルな勉強会

• デブサミブースあるよ

• 開発者の参加がちょっと少ない？

• bashとか、strutsの脆弱性とか　開発者にも考えてもらいたい

翔泳社なべしまさん

• 開発者、コミュニティをつなぐ
• いろんな気付きなど　いろいろ活動して欲しい