プレゼンテーション中に聴衆を居眠りさせないためのティップス10+選
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます プレゼンテーションを行う人であれば誰でも、聴衆に興味を持って熱心に、注意深く聴いてもらいたいと思っているはずである。そして、あなたのメッセージを最も効果的に聴衆に伝えたいと思っていても、そもそも彼らが聴いてくれていなければ無理な話なのである。プレゼンテーションを行っている間、聴衆の注意を引き付けておくための方法は数多くあるが、まず手始めとして、聴衆をあなたのメッセージに積極的にかかわらせるようにするのが一番だろう。本記事では、聴衆をあなたのプレゼンテーションやメッセージに引き込むためのティップスを12個紹介する。 以下の内容は、Kevin Eikenberry氏の執筆した記事「Twelve ways to engage your lea
「IE 8.1」リークの報道は、エイプリルフールネタ
エイプリルフールの冗談ネタはあまり好きではなく、毎年、エイプリルフールを狙って登場する記事から、事実のみを取り出すのが難しくなっていると感じる。良い例が、今年の“「Internet Explorer 8.1（IE 8.1）」がリーク”という偽情報を報じたこのブログだ。 この記事をざっと読んでみたところ、IE 8.1リークといううわさは事実のように見える。もちろん、ここでうわさされている開発コード名「Eagle Eye」のIE 8.1はまだ不安定に見えるが、Acidテストへの対応強化、JavaScriptの性能が高速化などの機能は、うっかり信用してしまいそうになる。記事の作者の経歴をクリックしてみて、IE 8.1のコードがリークしたのではないと確信した。Jacob Gudeと名乗る作者の経歴は、以下の通りだ。 Jacob Gudeはニューヨークダンスカンパニーのプロのコンテンポラリーダンサー
次世代Web基盤技術「ISSEI（イッセイ）」提供開始
株式会社HOWS（以下：HOWS、本社：東京都台東区、代表取締役社長：大塚裕章）は、次世代Web基盤技術「ISSEI（イッセイ）」（開発コードネーム）を研究・開発し、2007年11月中旬より提供を開始します。 昨今、インターネット上、あるいは企業システムにおける、日々蓄積する膨大な情報によって生み出される集合知などに対して、既存の技術では、その効果的な管理とパフォーマンスが得られず、目の前にある貴重な情報資源を十分に活用できていない状況となっています。 そこでHOWSでは、この集合知を含む貴重な情報資源を超高速に検索・抽出し、利活用するための柔軟なデータ構造と最適なシステム設計技術を開発し、次世代Web基盤技術「ISSEI」として提供してまいります。 「ISSEI」は、従来のデータベースや情報管理システムとは一線を画す、新たな思想にもとづいて設計されています（特許出願済）。 本格的なWeb
サイト脆弱性をチェックしよう！--第5回：XSSの脆弱性を検査する方法
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 前回までは安全なウェブアプリケーションを作成する手法をいくつか説明してきた。今回からは代表的な脆弱性についての検査方法を説明していきたい。まずは、クロスサイトスクリプティング（XSS）の脆弱性について、その検査方法を紹介する。 XSSとは、入力として受け取ったデータに含まれている「Javascript」などのスクリプトやタグが、それらが有効な形で出力（HTTPレスポンス）に含まれているために、ブラウザが意図しない動作や表示を行ってしまう脆弱性だ。 この脆弱性を使った攻撃の被害者はサイトを利用している利用者であり、サイトが直接的な被害に遭うことはない。この脆弱性を利用すると、攻撃者が意図した通りにブラウザをコントロールすること（たとえば、
サイト脆弱性をチェックしよう！--第2回：“正しい”ウェブアプリのコーディングとは
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 前回の内容はいかがだっただろう。今回の内容を述べる前にひとつ補足がある。前回および今回の内容はサイトの脆弱性をチェックするより前の段階の話であるということだ。チェックはあくまで「確認」であり、設計やコーディングが正しく行われて初めて実行する意味がある。 脆弱性は正しく設計やコーディングができていないからこそ生じるのであって、そもそも正しく構築されているのであれば出現しない「はず」だ。“はず”というのは、ケアレスミスをゼロにすることは不可能であるからで、そのミスを発見するのがチェックの目的となる。 脆弱性は、設計やコーディングのミスの結果でしかない。そのミスを正せばおのずと脆弱性もなくなる。それでは、ウェブアプリケーションの「正しい」コー
サイト脆弱性をチェックしよう！--第1回：ウェブアプリケーションに潜む危険
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます ウェブアプリケーションに潜む危険は数多くあるが、これまでのセキュリティ対策で指摘されてきたのは脆弱性の種類から見た危険性とその対策だった。 たとえば、クロスサイトスクリプティングの脆弱性とは何か、SQLインジェクションの脆弱性とは何か、そしてそれらへの対策とは……。これらについては、既に的確な解説をウェブ上で見つけることができるので、この連載では改めてその視点での解説はしない。 この連載では逆の視点から、つまり原因となる行動に焦点をあてて、ウェブアプリケーションにおける脆弱性を考えていきたいと思う。 まず、ウェブアプリケーションの脆弱性が発生する原因だが、「既製品の脆弱性」および「カスタマイズアプリケーションの脆弱性」の大きく2つに分類
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
