デブサミ 2009 2日目

代休使って行ってきました．マイレージ消費せずに行けるのはありがたい・・・・

##これからのWebテクノロジーを予測する ###自己紹介

• 仮面の人
• Asiajin の人
• ならべて.com
• プレゼン資料は akimoto.jp で公開予定

###本日の発表内容

• 予想する？
• 「僕の」予想です
• どれぐらい先？今年から数年

###予測の反省

• 2004年頃には RSS がすごい来ると思ってた
  • が，予測は外れた，とも当たったとも言えない．

• 部分部分では使われている場合もあるが，世間一般の認知は得られていない

• 海外のRSSニュースを提供していたりした

  • アメリカ在住時の話
  • 会社のブログを書くことにしたので止めた

###Web 2.0

• だいぶ飽きられた感じ
• バズワード
  • いろんな思惑で使われてた
• なんとなく新しい特徴を備えていると，Web 2.0 的だという感じ

###クラウドコンピューティング

• 今年熱いキーワード
• バズワードだけど定義も難しい
• 「スケールするバックエンドをネット越しに量り売りするサービス．それを使うこと」
• たとえば
  • 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 の前提があるので，それを活用するアプリ
  • ただし課金が依然として課題

###OAuth

• ブラウザべーsの認可
• 元サービスの資源を第3者サービスにアクセスさせる許可を与える仕組み
• twitter が限定ベータ中

###OpenID/OpenSocial とどうつきあうか

• 技術者としては，ちゃんと見極めるべき

  • どう使えるかとか

• エンタープライズへは？

  • 社内では使われそう
  • 技術者としてはちゃんと対応すべき
  • システム間を疎に保つ
  • コンシューマでこなれたものは，社内システムでも転用できるかも

###CGM/UGC

• ユーザがデータを作ることで成り立つサービス

• 世界で一番でかい CGM は？

  • Google
  • コンテンツを集めたコンテンツ

• CGM を支える技術

  • レコメンデーションエンジン¹
  • スパム対策
  • 監視支援ツール

• 監視も CGM

  • Gmail スパムフィルタ
  • うごメモはてな
  • 子供のコンテンツを大人(はてなユーザ)が監視
  • Wordpress
  • Akismet スパムコメント検出サービス
    • 世界中のブロガーにスパム判定させている

• CGI の増加で監視が売りになる

  • 自動化・省力化がシステムで出来れば差別化に繋がる

###ブラウザ

• 複数ブラウザ対応の苦痛は減ってきている？
  • Web 標準に準拠すべき

##RIA

• クライアントリッチなアプリケーション
  • Flash
  • Silverlight
  • JavaFX
  • JavaScript
• UI の統一性はいつも問題になる
  • いろんなものが出来ると，世の中の大半と異なるものができる
  • 差別化を図ると，それがさらに大きくなる

###次に来るのは何か？

• 初めて Yahoo! を見たとき
  • Yahoo! がウェブの未来を支配すると思ってた
• Google や Microsoft 支配も永遠に続くとは限らない
  • アイデアだけじゃなくて，実行力が問われる
  • それを支えるのはエンジニアリング

###常に次は来る

• 主役交代の時には必ず技術も関与している
• なんでも作ってみること，公開してみること

###まとめ なんだかんだで，世界を変えるのはエンジニア！

• プレゼンを作ったのは S5 Reloaded

##Delphi for PHP のエバンジェリストが，日本の PHP エバンジェリストと，PHP と IDE のいまと未来を語る ###パネラー紹介

• 小山哲志さん
• 高橋邦彦さん(kunit さん)
• Jose Leon(Delphi for PHP Architect)
• 坂井 恵

###Delphi for PHP

• PHP の RAD ツール
• コンポーネントを Drag&Drop して，Event を attach すればいいようだ
  • Event-driven Development
• コンポーネント化されているので，必要な部分のみを記述すればよい
• Delphi for Windows と同じようにコンポーネントを使えるらしい

###DEMO

• Designer は直感的にわかりやすい感じ
• 記述すべきコードも，Delphi や Visual Studio と同じように，わかりやすい．
• コードヒントもある
• コンポーネントの種類も多い．しかもあたりまえだが普通に Web で見ることが出来る．
• Chart など通常の HTML で存在しないものなどは JavaScript/Ajax を使ってる
  • かなりかゆいところにも手が届く仕様のようだ
• データベースとの連携も簡単にできる

###いろいろ聞いてみよう

• Access や Excel などを社内で使っている人達にもいいかもしれない
• どういう人向け？
  • D4P はコードエディターなので，開発者向け
  • PHP で開発したい人であれば，誰でも使える
• テンプレート HTML を使うことでデザインされた HTML を使える
• PHP 5.3 への対応は？
  • もう少し時間がかかりそうです
  • PHP 6.0 が出たときに Unicode 対応と併せて対応したい
• チーム開発機能が見受けられなかったが
  • 今週ユーザアンケートが行われる²ので，そこで希望を書いて欲しい

###まとめなど

• Jose さんは，OSC Tokyo/Spring 2009 にも来るそうだ

##仮想化技術を用いた分散型システムの開発とテストの手法

• VMware の人

• ソフトウェア開発手法の進化

  • TDD
  • 自動テストや Commit 時にテストを実行するなど

• アプリケーションアーキテクチャの進化

  • Monolithic -> Client-server -> 3-tier, n-tier, Service-oriented

• 今日の問題

  • 一人の新規人員に対して，複数ハードウェア台数が必要になる(場合もある)
  • 数人なら問題ないが，数十人になると？
  • 専用の人員(エンジニアリングIT)を配置しても，人数が少ないと業務がパンクするかも

• 分散型アーキテクチャーが生む新しい問題

  • サーバ数の急増
  • サーバ管理コストの急増
  • 自動化できない作業の急増
  • 大規模でないと発生しないバグがあったりする
  • サポートする環境が多いと，検証が大変になる

• 昔からある基本的な問題

  • クリティカルなバグは出荷間際でなければ出現しない

• 仮想化された開発環境の特性

  • 実行状態の保存と管理
  • 障害時の状態を保存できる
  • さらにいろんな場所で実行・再現できるという利点がある
  • 物理リソースの迅速なプロビジョニング
  • 複数の物理リソースにより構成される実行環境の変更管理
  • テストに必要なすべての手順が自動化可能

• 品質管理のブレークスルー

  • スナップショットから過去の任意の時点でバグを検証することが出来る
  • どの段階で混入したバグかがわかる
  • 自動テストにより，品質も確保できる
  • 実行環境そのものを出荷できる
  • クライアントの環境でテストする必要が無くなる

• 仮想インフラスタック

  • 1つの物理サーバ上で複数の仮想マシンを起動
  • マシンリソースの効率活用

• 自律的でオープンな開発プラットフォームの構築

  • Repeatable
  • Predictable
  • Scalable

途中から力尽き果てた・・・・

##モダン Perl テスト

• モダン Perl 入門の人

###テストの話

• プロジェクトマネージャーの視点から
• 効率的に
• 合理的に

###単位テスト

• 基本的なテストの充実が一番コストパフォーマンスが高い
• テスト == 追加作業だと思われるので，マネージャにいやがられる
  • テスト != 追加作業 であり，テスト == 必須作業
• エンジニアにまともな生活をしてもらいたいがためのテスト
  • つまり，質の高いコードを書いて，あとで泣きを見ないため
• あとで発覚したバグは追加工数
  • => エンジニアソースの摩耗
• テストは予防措置であり，将来への投資
• 現実的な落としどころ
  • 80% の機能を網羅する
  • 100% は目指さない

###テスト内容

• 再現性のあるものだけ
• 前提として，「人間は必ず間違いを起こす」
• 手動テストは避ける
  • 手動テストは作業者に左右される
  • テスト内容のノウハウが口伝になってしまって，蓄積されない
  • テストを実行することに時間がかかる
• 自動テスト
  • 誰が実行しても同じ結果になり，テストのコストは限りなく小さくなる
  • テストスクリプトを追加すれば，その問題を起こすことはなくなる

###テストの準備

• フレームワーク
  • 使ってるのがあればそれで
• 仕様がメタメタなので，テストも無理矢理
  • フレームワークを使うことは厳しいんじゃないかな
  • 柔軟に対応できるのがいい
• そこで Perl ですよ

###統合テスト環境としての Perl

• テストフレームワークは言語に含まれている
• make test
  • t/ 以下のテストをすべて実行
• prove
  • make test の alias
• Perl はテスト好き
• 多言語との接続も簡単
  • CPAN なれば
• テストの書き方はシンプルであればあるほど良い
  • 簡単に欠ければ，何かしらテストを書く or 書かせるのも楽になる
• TAP を使えば多言語のテストも可能
  • Ruby はないのか

###Web アプリのテスト

• 設定が面倒でテストをさぼってませんか？
• Apache::Test
  • Apache の設定，起動，テストまで面倒を見てくれる
  • 別の Apache インスタンスが立ち上がるので，1台のサーバで複数人がテスト可能
• Selenium と連携させてテストすることも可能

###まとめ

• TDD/Extreme/XP/Eclipse とか，理想は理想
• Heterogenous な環境
• 現実的な落としどころとして Perl は担える
• 重要なのは
  • やらなければ行けないことをいかに簡単にやるか
  • エンジニアの時間を有効に使うこと
  • リスクの計算も重要

###Japan Perl Association

• 真面目に宣伝活動や企業向けの活動なり
• 「大人の」Modern Perl
  • 他の Perl Community が不真面目なので・・・・
• YAPC の運営やるそうだ
• daisuke@endworks.jp

##ひよこクラブ 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)
• ライブラリを読む
  • jQuery
  • Greasemonkey
• 書籍
  • サイ本か
• アウトプット
  • 思ったことは実行してみる
  • 作ったものは公開してみる
• アウトプット超重要
• 後日 Yahoo! Japan Tech Blog でエントリ書くらしい

###ひよこクラブ ver.PHP

• 形から
  • 象のぬいぐるみ(ElePHPant)をゲットしよう
  • PHPer (ぺちぱー)
  • 勉強会という焼き肉へ
• 身近に
  • http://php.net/関数名
  • 手元に PHP のコードを置いておく
• 慣れてきて
  • これには詳しいというのを1つ
  • Ethna とか
• だんだんマニアック
  • バグや仕様の問題などをブログのネタにしよう
  • phsh
  • pho-shell
  • readline が必要
• ソース嫁
  • make じゃなくて phpize と打つほどになれば完璧！

###ひよこクラブ Perl Programmer 兼 管理職な私の学習ノート

• プレッシャーにならない程度の勉強
• 未解決な問題をブログに書いてみる
• Open Source Contribution
  • Perl は CPAN に
• 雑誌・書籍に書くのは，非常に勉強になるらしい
• 管理職というのは
  • マネージャーのあるべき姿 : 優秀な人材であること

##Webセキュリティ好手攻防パネルディスカッション

• パネラー
  • 竹迫さん
  • はまちちゃん
  • はせがわ ようすけさん
  • 大垣さん
  • 徳丸さん
• ひらがな名 vs 漢字名
• セキュリティ界隈では，関西の人の比率が多いのだろうか

###XSS

• 信頼できない Web サイトでは XSS はどうでもいい
  • 逆に言うと，信頼されたいのなら XSS ぐらい直さないといけない
  • XSS はただのバグ
• IE ではなく Firefox を使う
  • noscript で本当に信頼できるサイトのみ JavaScript を使わない，など
• JSON Hijacking の対策
  • 「while(1);」を先頭につけるなど
  • クライアント側に対策させていることになっているので，それはどうかと思う
• オープンな脆弱性の指摘は犯罪なの？
  • メリットはない
  • 訴えられることはないだろうが
  • 会社的に訴える意味がない場合が多い
  • 見つけたら IPA 経由で言う方がいい
• オープンソースだからって(脆弱|安全)と信じていいわけじゃない
• PHP を避けるべき3つの理由
  • 言語処理系としてマルチバイト文字列に対応していない
  • 文書化されていない仕様
  • サポートライフサイクルが短すぎる
  • PHP を使うにはバージョンアップに追従し続ける必要がある
• レスポンスヘッダに charset=(Shift_JIS|EUC-JP|UTF-8) をつける
• 多面的に脆弱性対策・防止策を考えるべき
• フレームワークが XSS 耐性などを持つようになるといいのでは
  • お手軽に開発できるようになるのだから，セキュリティへ目を向ける時間ができればいいかな

comments powered by Disqus