デブサミ 2009 2日目
代休使って行ってきました.マイレージ消費せずに行けるのはありがたい・・・・
これからのWebテクノロジーを予測する
自己紹介
- 仮面の人
- Asiajin の人
- ならべて.com
- プレゼン資料は akimoto.jp で公開予定
本日の発表内容
- 予想する?
- 「僕の」予想です
- どれぐらい先?今年から数年
予測の反省
- 2004年頃には RSS がすごい来ると思ってた
- が,予測は外れた,とも当たったとも言えない.
- 部分部分では使われている場合もあるが,世間一般の認知は得られていない
クラウドコンピューティング
- 今年熱いキーワード
- バズワードだけど定義も難しい
- 「スケールするバックエンドをネット越しに量り売りするサービス.それを使うこと」
- たとえば
- Amazon EC2/S3/etc.
- Akamai
- Salesforce
- Google App Engine
- 日本でやるところは?
- エンド開発者にはこないかも.企業向けかな.
OpenID
- Web に特化した SSO(Single Sigh On)
- OpenID は来るの?
- OP 側のメリットは大きい
- RP 側のメリットが見えにくい
- RP が得する方法を思いついたらすごいかもしれない.
OpenSocial
- Facebook App の対応
- Facebook/OpenSocial は儲かるの?
- 儲かる人はいるが....
- 日本のケータイアプリとどう違う?
- SNS の前提があるので,それを活用するアプリ
- ただし課金が依然として課題
- SNS の前提があるので,それを活用するアプリ
OAuth
- ブラウザべーsの認可
- 元サービスの資源を第3者サービスにアクセスさせる許可を与える仕組み
- twitter が限定ベータ中
OpenID/OpenSocial とどうつきあうか
- 技術者としては,ちゃんと見極めるべき
- どう使えるかとか
- エンタープライズへは?
- 社内では使われそう
- 技術者としてはちゃんと対応すべき
- システム間を疎に保つ
- コンシューマでこなれたものは,社内システムでも転用できるかも
- 社内では使われそう
ブラウザ
- 複数ブラウザ対応の苦痛は減ってきている?
- Web 標準に準拠すべき
RIA
- クライアントリッチなアプリケーション
- UI の統一性はいつも問題になる
- いろんなものが出来ると,世の中の大半と異なるものができる
- 差別化を図ると,それがさらに大きくなる
- いろんなものが出来ると,世の中の大半と異なるものができる
次に来るのは何か?
常に次は来る
- 主役交代の時には必ず技術も関与している
- なんでも作ってみること,公開してみること
まとめ
なんだかんだで,世界を変えるのはエンジニア!
- プレゼンを作ったのは S5 Reloaded
Delphi for PHP のエバンジェリストが,日本の PHP エバンジェリストと,PHP と IDE のいまと未来を語る
DEMO
- Designer は直感的にわかりやすい感じ
- 記述すべきコードも,Delphi や Visual Studio と同じように,わかりやすい.
- コードヒントもある
- コンポーネントの種類も多い.しかもあたりまえだが普通に Web で見ることが出来る.
- Chart など通常の HTML で存在しないものなどは JavaScript/Ajax を使ってる
- かなりかゆいところにも手が届く仕様のようだ
- データベースとの連携も簡単にできる
いろいろ聞いてみよう
まとめなど
- Jose さんは,OSC Tokyo/Spring 2009 にも来るそうだ
仮想化技術を用いた分散型システムの開発とテストの手法
- VMware の人
- ソフトウェア開発手法の進化
- TDD
- 自動テストや Commit 時にテストを実行するなど
- アプリケーションアーキテクチャの進化
- Monolithic -> Client-server -> 3-tier, n-tier, Service-oriented
- 今日の問題
- 一人の新規人員に対して,複数ハードウェア台数が必要になる(場合もある)
- 数人なら問題ないが,数十人になると?
- 専用の人員(エンジニアリングIT)を配置しても,人数が少ないと業務がパンクするかも
- 分散型アーキテクチャーが生む新しい問題
- サーバ数の急増
- サーバ管理コストの急増
- 自動化できない作業の急増
- 大規模でないと発生しないバグがあったりする
- サポートする環境が多いと,検証が大変になる
- サーバ数の急増
- 昔からある基本的な問題
- クリティカルなバグは出荷間際でなければ出現しない
- 仮想化された開発環境の特性
- 実行状態の保存と管理
- 障害時の状態を保存できる
- さらにいろんな場所で実行・再現できるという利点がある
- 物理リソースの迅速なプロビジョニング
- 複数の物理リソースにより構成される実行環境の変更管理
- テストに必要なすべての手順が自動化可能
- 実行状態の保存と管理
- 品質管理のブレークスルー
- スナップショットから過去の任意の時点でバグを検証することが出来る
- どの段階で混入したバグかがわかる
- 自動テストにより,品質も確保できる
- 実行環境そのものを出荷できる
- クライアントの環境でテストする必要が無くなる
- スナップショットから過去の任意の時点でバグを検証することが出来る
- 仮想インフラスタック
- 1つの物理サーバ上で複数の仮想マシンを起動
- マシンリソースの効率活用
- 1つの物理サーバ上で複数の仮想マシンを起動
- 自律的でオープンな開発プラットフォームの構築
- Repeatable
- Predictable
- Scalable
途中から力尽き果てた・・・・
モダン Perl テスト
- モダン Perl 入門の人
テストの話
- プロジェクトマネージャーの視点から
- 効率的に
- 合理的に
単位テスト
- 基本的なテストの充実が一番コストパフォーマンスが高い
- テスト == 追加作業だと思われるので,マネージャにいやがられる
- テスト != 追加作業 であり,テスト == 必須作業
- エンジニアにまともな生活をしてもらいたいがためのテスト
- つまり,質の高いコードを書いて,あとで泣きを見ないため
- あとで発覚したバグは追加工数
- => エンジニアソースの摩耗
- テストは予防措置であり,将来への投資
- 現実的な落としどころ
- 80% の機能を網羅する
- 100% は目指さない
- 80% の機能を網羅する
テスト内容
- 再現性のあるものだけ
- 前提として,「人間は必ず間違いを起こす」
- 手動テストは避ける
- 手動テストは作業者に左右される
- テスト内容のノウハウが口伝になってしまって,蓄積されない
- テストを実行することに時間がかかる
- 自動テスト
- 誰が実行しても同じ結果になり,テストのコストは限りなく小さくなる
- テストスクリプトを追加すれば,その問題を起こすことはなくなる
統合テスト環境としての Perl
Web アプリのテスト
まとめ
ひよこクラブ ver.Engineers
- 勉強の仕方など
- タイトルではなんのことかさっぱりわからんかった.
ひよこクラブ ver.Java
- vi がトラウマに
- OUTPUT すると 大きな INPUT が得られるよ!
- ブログに書くとググれる
- 便利
- 多言語で書いてみる
- 本の写経を移植するとか
- 百聞は一見にしかず的な
ひよこクラブ ver.JavaScript
- Roppongi.JS の人
- ソーシャルブックマークからタグで絞り込んだ RSS 見たり
- 仕様書見たり
- Web サイトのソースコードを見る
- JavaScript の利点
- jsbutifiler
- ブログ
- id:javascripter
- John Resig(http://ejohn.org)
- Ajaxian(http://ajaxian.com)
- ライブラリを読む
- 書籍
- サイ本か
- アウトプット
- 思ったことは実行してみる
- 作ったものは公開してみる
- アウトプット超重要
- 後日 Yahoo! Japan Tech Blog でエントリ書くらしい
Webセキュリティ好手攻防パネルディスカッション
- パネラー
- 竹迫さん
- はまちちゃん
- はせがわ ようすけさん
- 大垣さん
- 徳丸さん
- ひらがな名 vs 漢字名
- セキュリティ界隈では,関西の人の比率が多いのだろうか
XSS
- 信頼できない Web サイトでは XSS はどうでもいい
- IE ではなく Firefox を使う
- noscript で本当に信頼できるサイトのみ JavaScript を使わない,など
- JSON Hijacking の対策
- 「while(1);」を先頭につけるなど
- クライアント側に対策させていることになっているので,それはどうかと思う
- 「while(1);」を先頭につけるなど
- オープンな脆弱性の指摘は犯罪なの?
- メリットはない
- 訴えられることはないだろうが
- 会社的に訴える意味がない場合が多い
- 見つけたら IPA 経由で言う方がいい
- オープンソースだからって(脆弱|安全)と信じていいわけじゃない
- PHP を避けるべき3つの理由
- 言語処理系としてマルチバイト文字列に対応していない
- 文書化されていない仕様
- サポートライフサイクルが短すぎる
- PHP を使うにはバージョンアップに追従し続ける必要がある
- レスポンスヘッダに charset=(Shift_JIS|EUC-JP|UTF-8) をつける
- 多面的に脆弱性対策・防止策を考えるべき
- フレームワークが XSS 耐性などを持つようになるといいのでは
- お手軽に開発できるようになるのだから,セキュリティへ目を向ける時間ができればいいかな