ぱろっと・すたじお

技術メモなどをまったりと / my site : http://parrot-studio.com/

Developers Summit 2014 1日目 まとめ

devsumi2014

2009年から参加してますので、今回が6回目のデブサミになります

Developers Summit 2014：開発者のためのITカンファレンス

今回のテーマは「Story」だったのですが、
これはとても大事なテーマだと思います

何かの技術を適用する際に、その意図や背景、適用すべき状況、
いわゆる「コンテキスト」がとても重要です

実際、今回の発表では、「こういう状況で使える」といったコンテキストの話や、
「現実にはこのように適用した」という事例などが多数ありました

正直、デブサミで聞いた話が、実際の業務で即座に生かせるかというと、
私を含め、たいていの方にとって相当敷居が高いと思います
でも、「今」適用できないとしても、「いつか」は可能かもしれません

だからこそ、「いつか」が具体的にどのタイミングなのかを知るのに、
適用に至るコンテキストやプロセスが重要なのだと思います


なお、どうでもいい話として、
今までは紙でメモを取ってBlogに起こしていたのですが、
今回からはiPad mini + Appleキーボードでデジタルにメモを取りました

基本的には問題なかったのですが、
不安定な膝の上での入力はやっぱり大変なのと、
メモが長くなってくるとEvernoteが落ちたりで、なかなか大変でした(´-ω-)

あと、Win/Mac/AndroidはATOKで統一しているのに、
iPadだけ違うので、のってきた時に限ってイライラしました

Evernoteとの同期機能もあったはずですし、
次に同じようなメモを書くことがあったら、
ATOK Padを買っておいてもいいかもしれません

http://www.justsystems.com/jp/products/atokpad_iphone/


さらにどうでもいい話として、
昨年まではメモそのまま＋αの形式でまとめてましたが、
今回からは内容に対する感想とか気になる点を中心にまとめます

というのも、最近は講演の後すぐに資料が公開されるため、
不確かなメモに頼るより、そちらを見た方が間違いないからです*1

デブサミ2014、講演関連資料まとめ：CodeZine

ある意味普通ではあるのですが、
せっかくデジタルメモを取るようにしたのに、
それを使わないという矛盾が・・・Σ(ﾟДﾟ)ｶﾞｰﾝ

13-D-1 JavaからJavaScriptへ！HTML5適用から見えた次世代業務アプリケーション

エンタープライズ系の開発も今後HTML5になっていくというお話だったのですが・・・
おそらく、私が部屋を間違えたのだと思いますΣ(・ω・ノ)ノ

もちろん、業務系もHTML5になっていくという流れは間違いないと思います
だからといって、既存のやり方がもうダメってこともないはずです*2

現状でも、フロントエンドとバックエンドAPIは切り分けられている*3わけで、
フロントエンドがHTML5になったからといって、
バックエンドのJavaがすぐに変わるとは思えません

JavaにはJavaのメリットがあり、すぐにNode.js等に置き換わるわけでもなく、
HTML5を取り巻く技術環境にJavaが対応しない、というものでもないでしょう*4 *5
技術的概念と実装は必ずしも依存関係にあるものではありません

一番違和感があったのが、「NetbeansやEclipseを使わずGit」というお話です
「エディタ」と「バージョン管理システム」というカテゴリの違うツールを、
同じ文脈で比較されるのは違和感がありました

「JSPなんか捨てろ」という話もありましたが、これも実装手段の話でしかなく、
HTML5のコードをJSPで記述して出力してもいいはずです

「最新のツールや技術で開発していこう」ってメッセージはわかりますが、
「古いものを捨てていこう」には違和感があります

「マネージメント層」や「経営層」へのメッセージとしてはいいのでしょうけども、
「開発者」へのメッセージとしては違和感を感じた、ということです
なので、「部屋を間違えた」のかな・・・と (´-ω-)

13-B-2 グリーにおけるChef導入事例 ～既存の資産を活かし新しい技術を導入する～

エンタープライズ系の話は私には合わないと思ったので、
予定していたD-2からこちらに移りました

Blogで紹介されていた内容の詳細版とのことでした

グリーのインフラに Chef を導入した話 | GREE Engineers' Blog

最初からChefを使うと決めているケースはともかく、
普通は何か問題があるからインフラの一元管理を考え、
その手段の一つとしてChefを使うってことになると思います

実際、GREEでも最初は独自の管理システムを使っていたそうですが、
そこからChefにどう橋渡しし、共存しているかという、
現実的で参考になる事例だったと思います(｀･ω･´) ｂ

なお、資料があまりに良くできており、
そちらを見てもらえば全部けりがつくので、
メモ書きのまとめはしませぬ


13-B-3 社内システムの構造と設計、実装のはなし

実は、私の仕事はある意味「APIの整備」だったりするので、
この発表にはものすごく共感しました(｀･ω･´) ｂ

社内向けとしてもそうなのですが、Webサイトを運営している場合、
ユーザに提供するデータモデルと、社内に提供するデータモデルは紙一重だったりするので、
データ層でRESTfulなAPIを切っておいて、ビジネスロジック層で組み立てる、ということをしてます*6

しかも、View層とビジネスロジック層で言語そのものが違ったりしますが、
それでも問題なく動いてしまうのは、やはり「API」の力であり、
「REST」のすばらしさであり、「JSON」の柔軟性だと思います

発表にもありましたが、curlで気軽にテストできるってものすごい楽です
面倒な実装をAPIに閉じ込めておいて、
誰かに提供するときはcurlをsystemで読んでもらうとか簡略化もできますし

  • 社内システムほど連携を考える
  • Open Web
  • コストを誰が払う？
  • 互換性の問題
  • Close Web
    • 社内サービス
    • 機能＞性能
    • ライフサイクル長い
      • 使えるうちは使ってしまう
    • ターゲットユーザ＝自分
  • 問題点
    • 情報と権限の分断
    • 情報と機能が冗長
      • 無駄が多い
    • UXの欠如
      • 作りが適当
    • 「自動化」の障壁
      • サーバごとに仕組みが違う
    • 全部入りでアップデート不能
  • どう連携させる？
  • "シンプルにしたい"
  • 権限の分断を最小化
    • 普通の会社なら権限はフラットで良い
  • 参照は複数の方法を
    • ブラウザ/API
  • モジュール化
  • 社内システムほど他システム連携を考えてAPI化
    • APIが維持されていれば、裏側はどう変わっても構わない
  • APIの互換性を保つ
    • プロトコル
    • テータ構造
    • 意味的な一貫性（戻り値等）
    • クライアント要件の普遍性・不変性
  • "ドキュメントはどこかにいってしまう"
    • 人の目でわかるフォーマット
  • 運用できる＝アップデートできる
    • 人の目でアップデートの成否を確認可能
  • テストの容易さ
    • APIはcurlで確認できる
    • RESTful
  • パフォーマンスより容易さ
  • 動くことが大事
    • まず動かす
    • 必要になったら作る
  • 機能を切り刻む
    • 修正を最小化
    • 追加する機能を細切れにすす
      • 組み合わせて実現する
  • 将来の要件定義はそもそも難しい
  • 社内システムで新しいものを試す


13-C-4 iOSにAndroid、百花繚乱モバイル開発環境を比較する

先ほどのレポートでも書いたように、私の得意分野も仕事も、
どちらかといえばバックエンドAPIです

とはいえ、フロントエンドがあってのバックエンドであり、
大きな会社ならともかく、小さな会社では両方セット担当ってのはよくあるはずです
なので、フロントエンドの情報にも興味があります

とはいえ、AndroidではJavaを書き、iOSではObjective-Cとか、
正直いちいち面倒なわけで、
一度に書けるって怠惰ですばらしいと思うのですよщ(ﾟДﾟщ)

このセッションで誠実だと思ったのは、
全て「自分が触れたことがあるもの」に限定されていたことです
なので、比較されていた情報も、深掘りされたものが多くて参考になりました

個人的には「Sencha Touch」と「Xamarin」に興味をもちました

Delphiは・・・興味はあるものの、C++とかは使えないので(´･ω･`)

あとはやはり「Unity 3D」ですか
ここではあまり書けないのですが、某延期しまくりのネットワーク専用3Dゲーが、
どうもUnityで動いているようで、やはりゲーム界隈だと今は主流なんじゃないかと *7


  • 公式ツール
    • Andorid
    • iOS
    • メリット
      • 最新の機能に対応可能
      • 情報が多い
    • デメリット
      • 環境が強制される＝学習コスト大
      • 両方に対応が難しい
      • 基本API以外は提供されない
  • うまいこと両対応させたい
  • HTML5＋JS
    • PhoneGap
    • SenchaTouch
    • Titanium
    • メリット
      • みんな知っている
      • できる人が多い
    • デメリット
      • レベル差が大きすぎる
      • 出来上がりに差が出る
      • テクニックを知らないと難しい
      • それをツール側で吸収できるレベルに達してない
    • 用途：Webサービスのモバイル化に
    • おすすめ：SenchaTouch
      • 開発チームのレベルが高い
        • 裏でうまいこと最適化してくれる
      • Win/Mac/Android/iOS全部いける
      • キャノンが代理店をしている
  • Mono
    • Xamarin
    • Unity
    • メリット
    • Unityは事実上のデファクトスタンダード
      • UnityはBoo（=Python）/JS（UnityScript）が使える
    • デメリット
      • .NET への依存性
      • 利点でもあり難点でもある
      • AndroidではVMによる劣化が懸念？（ほぼない）
      • XamarinのGUIはネイティブツールで書かないといけない
      • UnityはUIが弱い（ゲーム向けなので） => NGUI
      • Unityは日本語が入力が難しい
        • ネイティブのダイアログで対応
        • 結果的にそこだけWin/Mac/Android/iOSでバラバラに作らないといけない
    • おすすめ
      • Xamarin：普通のアプリを作るには向いている（例：紅白アプリ）
      • Unity：ゲーム
      • 用途で使い分ける
  • Native
    • というかDelphi
    • メリット
      • ポインタが使える
      • AndroidでもiOSでもNativeコンパイル
      • OSのAPIにシームレス
      • 両方に完全対応
      • GUIも1ソース
        • FireMonkeyでOpenGLなのでOSネイティブではない
    • FireMonkey
      • 2D/3D両対応
      • DPI（解像度）フリー => スケーリングされる
      • Style機構 => それぞれのOSスタイルに対応
        • iOS7の対応も一週間程度
      • ネットワーク系やDB系コンポーネントを使える
    • C++
    • デメリット
      • Nativeであることが難点 => 例外機構などはVMが有利
      • Pascal系の言語
      • UIが独自で描かれている・・・が、ピクセル単位で同じ
      • IDEがWinのみ iOSの開発にはやはりMac
    • 用途：一般的なアプリ
      • Windowsアプリがそのまま動かせる
  • 最終的なおすすめ
    • 一般的なアプリ：Xamarin（MSサポート） / Delphi
    • エンターテイメント系：Unity3D
      • 会社（ゲーム）ではUnityばかり


13-D-6 快適さはWebサービスの生命線！Webアプリのパフォーマンスを最高にするために心がけること

「Akamai」については皆さんご存じと思いますが、
サービスの概要について、もうちょっと突っ込んだ話がありました

HTMLそのものを書き換えたり、画像URLを書き換えたりと、
思っていた以上にドラスティックな仕組みになっているようですが、
ユーザからすると「同じように見えればいい」わけです

画像なんかも解像度を落とす等、相手の環境に合わせて自動選択・配信しているようですが、
さすがにそのレベルの仕組みを自前で汎用的に構築するのは難しいわけで、
その辺がお金をもらうポイントなんでしょう

  • コンテンツをクライアントに表示させるまでの時間をいかに短縮するか？
  • Tim Berners-Lee says：混雑が最大のWeb阻害要因になりうる
    • MITで研究 => スピンアウトしてAkamai
  • ルーティングのコントロールが難しい
    • IXから1ホップでAkamaiのサーバにつながるようにサーバを配置している
  • 最大風速21.6Tbps
  • 1日のピーク10Tbps
  • Walmartの論文
    • コンテンツの表示が遅いほど注文に結びつかない
  • but、サイトはどんどんリッチ化複雑化
    • 外部のサイトを読み込まないといけない
    • レスポンシブ化＝複雑に
    • 画像の容量がUP
    • 外部参照ファイルの増大（JSライブラリ/CSS等）
    • Twitter/FB/Amazon等、外部サイトの依存性
    • レスポンシブWebは通信量が解像度に依存しない
      • 全部送ってクライアントで取捨選択している＝重い
  • 「状況に応じて最適化する」
    • AQUA Ion
  • アクセラレーション
    • HTMLを書き直す
    • 画像を生成し直す
    • オブジェクトの数そのものを減らしてしまう
      • HTMLの中の読み込みサーバそのものを書き換えて、並行ロードさせる
      • 見かけは変えない
    • スクロールさせた時に画像を読む
      • lazy loadをコンテンツを見て自動で
    • 空白をなくしちゃう
    • 元コンテンツを自動解析 -> キャッシュ等で最適化 -> サーバで適切に配信
      • 待たされるよりは荒い画像でもいいから「それっぽく」見せる
    • docomoの回線もあいぽん以降は速度解析可能に
    • JSを同意の上で元コンテンツに差し込み、実際の表示速度を分析する
    • CAが日本で最初にAkamaiを導入したっぽい？
  • 日本の回線は速い => キャッシュは効果が薄い
  • それでも他の要因で速度を上げられる



2日目に続く・・・

Developers Summit 2014 2日目 まとめ - ぱろっと・すたじお

*1: 決してメモを整理するのが面倒というわけでは・・・ないと・・・思ふ(´･ω･`)

*2: 「HTML5があればFlashはいらない」とじょぶずは言ってましたが、HTML5を捨ててネイティブにいったFBの事例もありますし、むしろAppleがどんどんプロプライエタリな方向に進んでいる気も・・・

*3: ・・・そうなんですね(´･ω･)？

*4: 実際、Java8は久々にJavaを触ろうかと思わせる、良い作りをしていると思います。既存仕様を生かしたまま、あれだけの変更を加えるのは大変だったでしょう

*5: そもそも、最近Scalaが人気だったりするわけで、ベターJavaの需要は十分にあるし、TwitterだってバックエンドはScalaです

*6: 昨年ちょっとだけ触れてます(´･ω･)っ http://parrot.hatenadiary.jp/entry/2013/09/03/112657

*7: そのゲーム、元々はPCゲーで長いこと評判だっただけに、クライアントの出来はいいのですが、ネットワークゲーが初めてということもあり、ネットワーク周りの設計が雑すぎたようで、クローズドβではあまりのひどさに閉口しました(´-ω-)　最新のテクニカルβはだいぶましになってましたが、ゲームとしてはまだ細かいところが見えてないのが難しいところで　キャラ造形のクオリティは高いのですが・・・　さて、どのゲームでしょう？Σ(・ω・ノ)ノ