デブサミ2013で6つのセッションを聞いてきた!
developers summit 2013に参加してきました!
私は2月15日(金)だけの参加です!
web、アジャイル、という単語がついているもので探して参加しましたっ
やっぱり、知識が全然足りないな、と思いつつこのような知識を増やすきっかけがあることに感謝したいと思いました(*´ω`*)
以下、自分の中のまとめとしてメモっておこうと思います!
☆Webが生み出し始めた世界☆ 江渡さん
- 情報メディアについて
- 新聞、ラジオ、テレビ、Web どんどんWebに価値が置かれていっている
- ただ、将来Webを抜くものが出てくるのではないか?
- webの未来
- 未来は必ずしも魅力的ではない
- Webがメディアの頂点にたち、ユニミディウム化
- VRの世界へ(Google glassesのような)
常に動向をチェックして置いて行かれないようにしないといけないと思いましたっ
☆モバイルHTML5による世界の挑戦☆ 紀平さん
- FBの脱HTML5
- HTML5でいくつか問題がある
- アンドロイド端末間の互換性が絶望的
- CSS3をそれぞれの端末に対応するだけでも不可能な程の工数
- Canvasでも問題が多数発生する
- これらはIE6に対応するより大変
- 将来
- モバイルwebにおけるリッチアプリ
- webならでは
アプリを追い求めるのではなく、webならではを考える - JSを捨てる日
JSはすべてのブラウザで動く言語
しかし、速度がでない
メリットデメリットを考えて探っていかないとですね~
☆無償でここまで使えるアドビのWeb制作ツール☆ 轟さん
- HTML5あるけど、生産性はどうなのか…?
- 無料のweb制作ツール
- Edge Animate
- Edge Code
- Edge Reflow
閲覧でデバイスが異なることで、情報の優先度、重要度が変わることがある。
レスポンシブなレイアウトデザインする際のイメージ定義が大変。
そこで、このツール使うことできちんと実装をしなくてもイメージがつかめる。
Illustratorとかphotoshopなら使ったことあるけど、アドビさんで無料ツールってあったんですね!使ってみよう~
レスポンシブなデザインも必要ですよね…PCだと横に並べられるけど、スマホだと縦にしたり工夫しないといけない。ただ、縦にしてもスクロールが長いとかの問題もあるし…こうゆうのも大事ですよね
- 多くのアジャイルプロセスを…
- プロジェクトの時期に応じて体系化し、適用のガイドとしている。
エンタープライズ…複数の部門で構成されるような比較的大きい企業に向けた市場や製品
大きい規模ならそれの規模に適したやり方があるってことですかね。たぶん…違うかな…そういう解釈をしました!
☆増加するセキュリティ脆弱性の解決策☆ 安竹さん
- コード品質を高めても6割の脆弱性しか防げない。
⇒コードの品質を高めるだけでは足りない。
- セキュリティインシデントの対応にかかったコストは…28社/153社が5千万以上
- デフォルトアカウントのPWの設定…41%
- 運用環境のコンフィギュレーション…?メモれなかった
- インジェクション…36%
意外と基本的な部分が原因なんですね…
- 開発完了後にセキュリティテストが行われる。
- 開発者とセキュリティチームでは視点が違う
→開発中にうまくセキュリティを考慮してできないか?
- ホワイトボックスファザーとサニタイズ
- 発見した経路に汚染データを投入し、無害化されているか確認する
ペネトレーションテストわからないので調べてみた。
⇒侵入テストのこと。ネットワークに接続されているコンピュータシステムに対し、実際に既知の技術を用いて侵入を試みることで、システムに脆弱性がないかどうかテストする手法のこと。(引用wikipedia)
- まとめ
- 発見された脆弱性に対して、修正できる情報を持っているか?
- セキュアコーディングガイドがあるという認識
常に脆弱性についての情報を集めて認識をしておいたほうが、すぐに対処できるということですね…
開発中に、どこから汚染データが入ってくる可能性があるかを意識するだけでも違うのかなと思ったりしました。
☆反復型ソフトウェア開発の勘所☆ 津田 義史さん
津田さんの書籍!次これを読もう~!
- 作者: 津田義史
- 出版社/メーカー: オーム社
- 発売日: 2012/12/01
- メディア: 単行本(ソフトカバー)
- クリック: 1回
- この商品を含むブログ (2件) を見る
タイムボックスについて
- もし、当初の予定のタイムボックスよりあふれが出たら…
- × ムリヤリ詰め込む ⇒残業⇒体壊すetc…(品質)
- × 箱の大きいものに取り替える(リリース日を遅らせる) ⇒なかなかリリースできなくなる(納期)
- ○ 全部入れることをあきらめる(範囲)
1は記載の通りで…
2は一見良さそうと思ったんですが、リリース日を伸ばすことで、あれもこれもと詰め込み、それがさらにリリース日が伸びる可能性があるということなんですね。
3は、優先順位を決めて機能を削る。削った機能は後回しにする。このやり方がスマートですねっめりはりもありますし!
- タイムボックスの長さについて
- 箱の中にさらに仕切り箱があるイメージ
- タイムボックスの長さはそれぞれのプロジェクトによって良い期間を設定すれば良い。
何かしらの問題でリリースする機能削る必要がでたときに、タイムボックスが長すぎた時に機能を削るのが難しくなるから、そこはうまいことやる必要がありますよね。
- バックログ
- 作業内容(完了定義、条件)、見積もり、優先度
- 途中でバックログを増やしたいとき、あまりゴールを動かすべきではない。
- ただし、それを追加しないと作業が進まないなどの例外は除く。
- 途中でバックログを減らしたいとき、作業から手を放すことをパントする、という。
作業の完了定義は重要ですよね…。何度もふりかえりでタスクがなかなかDONEできなかった問題があり、DONEの定義が曖昧だったというのが多くあります。
DONEの定義は少しでも曖昧な点があるなら、遠慮せずに聞いていかなきゃなー
- 出口条件
- 残作業ゼロ、バグゼロ、出荷可能な状態にする
- ゼロ・バグ・バウンス
- バーンダウンチャートなどで継続的に見て、このままいけば終わりそうかどうなのかを把握していくことが重要
- フィーチャーボックス
- 実装する機能を固定
- 優先度をつける必要はなし⇒ただ、いつ終わるかわからない
- 納期を固定するタイムボックスでは、優先度は必要
ゴールが本当に初めからぶれないという前提であれば問題ないが、
現実には初めからぶれないことってそんなにないんじゃないかなーと思ってます。そうすると、やはり、適度に確認して軌道修正をしたほうが戻りやムダが少なく済みそうと思いました。
継続的インテグレーションについて
- CI…継続的にインテグレーションビルドする
- スティーブ・マコネル 「デイリービルドをプロジェクトの心拍とすべし」
いろんな方が著書を書いたりしていますが、つまりは昔からCIに関しては考えられてたってことですね
- 「ビルド」には二つの意味がある…
- 実行可能なソフトウェア
- 事項可能なソフトウェアを構築する
ビルドの例を料理に例えて説明されてました!
たとえば、ビルド手順⇒レシピ バグ⇒料理に虫が…
- いつ、誰が、ビルドしても同じビルドができる
- 以前と同じビルドができる
- CRISPなビルドが良い!
- 作者: アンドリューハント,デビッドトーマス,Andrew Hunt,David Thomas,村上雅章
- 出版社/メーカー: ピアソンエデュケーション
- 発売日: 2000/11
- メディア: 単行本
- 購入: 42人 クリック: 1,069回
- この商品を含むブログ (335件) を見る
- 料理のさしすせそに例えると…
さ再現可能
し情報提供可能
すスケジュール可能
せゼロからビルド可能
そそこかしこでビルド
- コミットした後に、問題があったと言われても困る。
- そこで、バディビルドの自動化をする
- バディとは相棒という意味
- コミット依頼⇒バディビルドとオートメーション⇒問題なければコミット
バディにビルドしてもらうことで、コミットする前に、
問題があるかどうかがわかる…という意味だったと思います…。
そのような仕組みもあるんですね~
- ビルドしては直しモデルはコードコンプリート後に統合するので、悪循環に陥る
- テストの目的⇒×バグを出すため
- 継続的に統合しながら開発
- CIビルド(不定期ビルド)とスプリントビルド(定期的ビルド)をきちんと分ける
テストの目的は、バグを洗い出すことだと思ってました。
そうではなく、品質を保証するということでした。
バグは開発中に継続的に統合しながら洗い出していくことが大事っ。
でも、バグなどをフィードバックしてもらうということは、テストの運用をする作業が発生するんですよね…?それをうまいことできたら良いですね!
むむっ
でも、こうやって開発の効率を上げるために日々何か仕組みだとかが考えられているんですね…自分でも効率を上げるために考えていかないと!
引き続き、勉強を続けていかないとですね~
津田さんの本を読めばわかるかな…汗