Developers Summit 2013レポート(1)
遅きに失した感がありますが、デブサミ2/14分のレポートです。
実はデブサミに参加したのは今回が初めてでした。 長い坂を降りて目黒雅叙園へ。 最初間違ってアルコタワーに入ってしまい、中から雅叙園へ回りました。後で聞いたところによると、エスカレーターを使って行けるルートがあるようですね。ぐぐるとすぐ見つかりました。
Webブラウザの時代は終わるのか？〜スマホアプリとHTML5の未来〜
- 14-A-1 @kazuho
- スライド
ウェブが破壊したもの
iPhoneの登場とスマホアプリ
- Apple社の戦略はOSメーカーとブラウザのつぶし合いとは違う
- アプリならではの長所を生かし、AppStoreというエコシステムを形成
- スマホへのブラウザアプリの最適化は不可能ではないとはいえ、専用にするならアプリの方が楽、クロスプラットフォームにしようと思うと互換性で苦労する
- スマホアプリ=進化したウェブアプリなのか? Webの通信を使いながら、より優れたUXを提供できる。ウェブが終わりってアプリの時代が来るのか?
ウェブ vs アプリ
哲学
- Webの基本3要素(Tim Berners-Lee)はHTML, HTTP, URI。一番重要なのはURI
- スマホアプリ=ウェブを補完する存在
- better UXでウェブをサポートするが、URIは扱わないか意識させない作り
市場
- スマホアプリ市場の規模感: 広告などと比べると小さい。日本のソーシャルゲームくらい
- すべてのウェブサイトはアプリ化するのか?
- メリットは業態によって様々。零細通販では開発費がペイできないかも
- アプリ化のデメリットももちろんある: 開発コスト、アップデート頻度低下
技術
まとめ
- スマホアプリ vs ブラウザアプリ: 対立というより相互補完の関係にある
- アプリ: UIに優れる、ブラウザ: 幅広い用途に対応
- 用途別分類: 横軸: 高度なUI←→機種非依存; 縦軸: 利用頻度としてプロットしてみる
Action!
- できないと決めつけていることはありませんか
感想
スマホアプリとブラウザアプリは相互補完の関係にあるというのは実感としてもわかります。上手な分担ができれば使い勝手はよくなりそうです。アプリとブラウザ間でログインセッションの共有がもっとスムーズにできるといいな、などと連想しました。
トランザクショントレース
パフォーマンスチューニングとは
- 要件を満たすための改善活動 → 目標がある
- 3つのアプローチ → ずらす、変える、増やす
- FAQ: 対策がわからない → 問題・原因がわかったつもりでクリアになっていないケースが多い
- クリアにできない: 解明手段がない、セキュリティー上見えない
- クリアにしたくない: メンタルな理由
パフォーマンス低下 - どうする?
トランザクショントレース技術
PurePathの仕組み
- タギングを使ってデータを識別
- 各サーバーにインストールされたエージェントがメッセージにタグをつけていく
- タグを分析サーバーに集約・分析
- 流れに付随する引数なども取ってくる
- 必要なコンテキスト情報をすべて取ることができる
- PurePathの特長
- ブラウザからDBまでを一気通慣で追跡
- 全てのトランザクションの性能を正確に測定(サンプリングではない)
- マルチベンダ・マルチプラットフォーム
デモ
チューニングのアプローチが変わる
- ログ分析 → トランザクショントレース
- 再現待ちという仕事がなくなる → すぐに分析
- 勘と経験 → 科学的、説明可能な分析
- → 標準化
Action!
- 快適なアプリケーションを通じて、快適な社会を作りましょう
Ruby 2.0
Ruby誕生
- 言語を作るのは大変。"Hello World"を動かそうとすると文字列を作らなきゃいけない。そのためには文字列オブジェクト、文字列クラス、Objectクラス、といもづる式にいろんなものが必要に。出力するにはIOオブジェクト……
- 最初のHello Worldが出るまでに半年かかっている
- 1995年12月 Version 0.95初公開
- 人にあげるたびに0.01ずつバージョンを上げていた
- 1998年の1.2以降、開発系と安定系で分かれる
- 盆と暮れに出すのが目標
- プロットすると、2.0前でサチってしまいそう
- 「これは本当に2.0にふさわしいんだろうか」という心理的ブロックがある
- 一昨年2.0を出すとアナウンス「2013年2月24日にRuby2.0を出す」
とうとうやってきた2.0
- Ruby2.0の話はこれまでずっとしてきていた
- 過去の2.0候補
- RubyConf2001 最初のRubyConf。キーノートで言及
- ここで言われていることはほとんどRuby 1.9で実現された
- 新VM → YARV ささだこういちさん Rubyバイトコード
- 新GC → 世代別GC ひやまさん 1.6→1.7 でメモリ割当てを変更したらかえって遅くなってしまった
- → 1.9ではLazy Sweepを導入。2.0ではbitmap marking
- native thread → 1.8まではgreen thread(ユーザーレベルスレッド)
- Ruby開発開始当時はマルチコアCPUもなかったし普通の人がマルチスレッド使う方が効率的という考え方はなかった
- キレイにプログラムを書けるようにスレッドを用意した
- 1.8ではthread切りかえのたびにスタックをまるごとコピー。リンクしたいネイティブライブラリがマルチスレッドだと相性が非常に悪い
- 1.9ではnative thread。すべてのライブラリの再入可能性を保証できないのでGiant Interpreter Lockを使った。IOするときはロックを外すのでOK。IO heavyなプログラムでなければ使えないと文句を言われる。JRubyはnative threadだよー、とよく自慢される
- 埋込API → 1.9では不採用。C APIについては互換性あり
現代のRuby2.0の起源
Ruby 2.0の新機能紹介
- キーワード引数
- Module#prepend
- メソッドコンビネーションの実現
- 既存のクラスの修飾
- alias_method_chain: Railsで多用
- 欠点: 名前衝突の危険、名前管理が必要、修飾のグループ化が困難
- メソッドコンビネーション: CLOS (CommonLisp Object System)から
- デフォルトで定義されているもの: before, after, around
- 正直言うとRubyにはオーバースペック
- 単純化したもの → Module#prepend
- prepend: 前につける: includeは後ろに追加、prependは前に追加
- includeは自モジュールが優先だが、prependは入れた方が優先
- 既存のメソッドをwrapし、superで呼び出す。その前後に追加の処理を記述
- Refinements: 既存クラスの拡張
- メソッドの追加、wrap
- オープンクラス: クラス再定義。mathn, jcodeで使用
- 実用するのは難しい。スコープ問題がある。クラスを再定義してしまうと、プログラムの他の部分に影響をおよぼす
- そこでRefinements
- module R内でrefine String do ... end
- using Rが有効なスコープ内でだけ、refinementsが使える
- 他の言語の試み
- Enumerable#lazy
- 関数型プログラミング?
- 関数型ワナビーとして
- メソッドチェーン (1..Float::INFINITY).map{..}.select{..}.first(3) → 動かない(途中のmap, selectがeager動作)
- 提案。遅延評価版のメソッドを作る: map_lz, select_lz (lazyが_lzになっている時点ですでになまけものだw)
- 全部を置きかえるのめんどくさい
- 遅延(lazy)を求めるものは怠惰(lazy)である
- 最初にlazyってやればいい → ナイスアイディア
- (1..Float::INFINITY).lazy.map{..}.select{..}.first(3)
- 中身はいろいろ大変
Ruby 2.0以後
感想
まつもとさん、いつも楽しそうにしゃべりますね。キーワード引数はすぐにも使いたいです。Module#prependは下手に手を出すと可読性に難が出そうですが、instrumentation的な使い方が面白くなりそうでしょうか。
RubyでiOS/Androidアプリを作るMobiRuby
mruby
MobiRuby
- 米国から日本への帰国便の中でiPhoneで動くことを確認
- What's MobiRuby
- iOS app development kit
- MITライセンス - mrubyと同じ
- Objective-Cで使える機能はすべてmrubyで書ける
- Android版も準備中
- AppStoreでmobirubyをさがせ
- Vision
- MobiRubyコードの例
- defineはほとんどObjective-C
- コード補完が効かないのが痛い
- Next Step
MobiRubyスタック
- mruby-cfunc: C言語の関数を呼ぶ。mallocも呼べる
- mruby-cocoa: Cocoaブリッジ
- CocoaはほぼすべてCから呼べるようになっている
- mruby-cfuncでたたけば何でもできる
- 速度が必要な部分などはCで書いた
- delegate, blockも使える
- キモイこともできる
- Objective-CのクラスをRubyで継承、さらにObj-Cで継承
- ひとつのメソッドだけRubyで定義
- メモリ管理方法のミスマッチ(refcount vs mark-sweep)
- 苦労して実装 → 遅い
- CocoaはほぼすべてCから呼べるようになっている
- mobiruby-common: iOS/Androidで共通にできるだろう機能
- mrubyにはrequire, loadがない(なぜならFileがないから)
- requireを作ってもらった
- mobiruby-ios: iOS用にパッケージングするためのモジュール
- ロードマップ
- Cocoa bridgeがなんとかできた。デバッグ中 ←ここまで2012年度中に
- パッケージング
- ドキュメンテーション
- Wrapped Apps
- current status
- テスト
- C側のテストはだいたいそろった
- ObjC側のテストをこれから作っていく
- Pros
- Cons
- 不安定。そもそもmrubyがまだバージョン番号もない
- class/functionsが少ない
- debugがつらいbacktraceがない
- FAQ: RubyMotionと比べてどうよ
- RubyMotion は2万円、MobiRubyは無料
- 安定性から言って、いますぐ2万円払う方がおすすめですw
- MobiRubyはMatz実装なのが大きい
- RubyMotion は2万円、MobiRubyは無料
Action!
- MobyRubyの動機: Ruby Powerを世界に
- JavaScriptでiOSアプリを作る会社にいた
- mrubyのα版をもらえるので作ってみた
- 競合はしない
- ワールドワイドのポートフォリオを作りたい
- 海外のカンファレンスでしゃべる
感想
@masuidriveさんのTLを見ていると、日々@mattn_jpさんとキャッキャウフフしながらmrubyの実装を進めている様子が伺えます。mrubyいろいろ試してみたいです。
こわくない関数型言語
- @takesako Shibuya.pm
- 中野さん 電通大 形式言語理論/定理証明支援系 @ksknac
- 上野さん 東北大 SML#
- 水島さん ユビレジ(iOS上のPOS) Scala
中野さん
- 関数型言語ってこわい?
- 「関数型言語である」と思う基準は?
- 関数が値として渡せる?
- 高階じゃないと関数型じゃない?
- 参照透過性? 副作用が隠蔽/分離されている? 型推論?
- 答: 問題が不適切です
- 「関数型」とはプログラミングスタイルである
- 言語に依存しない問題
- そもそも「関数」とは
- 数学の関数の定義と同じ。入力集合の全ての値に対して結果がひとつ定まる
- 関数でない例: 同じ値でも出力が変わってしまうもの、入力集合の一部に対して値が定義されないもの
- 関数はどれ?
- getchar(), putchar(int c), random(int p), inc(int* x)
- 答: 問題が不適切。入力集合A、出力集合Bが定義されないとわからない
- 入力は引数だけではない。出力は返り値だけではない
- 関数化する
- スライド参照
- 関数化の注意点
- f(g(x))のgを関数化する → gの入力集合が変わる → fの出力集合も
- 関数型言語?
- 入出力の集合を知らないといけないはず。どうする?
- 結局のところ定義が難しい
- 関数型プログラミングとは?
- ほとんどが関数であるような記述。非関数をできる限り小さく
- どんな言語でも書けるが、書きやすい言語は存在する
- 「関数型プログラミングが記述しやすい言語」
- 関数型のメリット
- 関数型: 便利な機能に慣れる必要がありますが理論まで理解する必要はありません
- Functional is Fun
こわくないSML#
- 上野さん
- SML# 1993年 .netより前からあるんだよ
- 2012年1.0リリース、2013年2.0
- SML#: 強い型付け、eager評価。MLファミリー。OCaml, Standard MLの仲間
- 関数型は輝かしい未来。Cとかはどろくさい現実。2つの世界は名状しがたい何かで分離されている。そこにはテクニカルな何かがある。SML#は2つの世界を結ぶ。輝かしい未来でなくどろくさい現実を指向した言語 #devsumiB
- 3Dアニメは関数: 動画(時刻 t) → 画像
- 多言語プログラミング
- 手続き的な処理はC、宣言的に書けるところはML
- pros
- MLでシステムプログラミング
- プロトタイピング
こわくないScala
- 水島さん
- こわそうなScala
- implicit conversion, implicit parameter
- 誤解1: 関数型の概念を理解する必要がある
- 誤解2: implicitなんとかを使いこなす必要がある
- スクラッチから書きときは必要ない
- 標準ライブラリを読むときに勉強すればいい
- 最初に全てを知ろうとしないことが大切
- 誤解3: 関数型なコードを書かないとたたかれる
- 誤解3: Scalazという難しいライブラリを普通に使う
- コアライブラリの作者が使っていたりする
18:39
ここでMBAが電池切れになってしまい、自分も電池切れになったのでその後のパネルが思い出せません。すみません。
Togetterをどうぞ。
感想
関数型言語は、やろうやろうと思いつつまだ勉強していません。数学の定義から関数を考える、というのが結構わかりやすい気がしました。
