タグ

ブックマーク / xtech.nikkei.com (6)

  • これまでと何が同じで,何が違うか

    クラウドコンピューティングという概念が提唱され,SaaS(Software as a Service),HaaS(Hardware as a Service),といったサービスと共に,自社でインフラやサーバーを持たず,開発者はアプリケーションの開発といったコアな部分に集中することが出来るメリットを持つPaaS(Platform as a Service)が注目を集めています。 この連載では,米Salesforce.com社のPaaS「Force.com」上における開発ノウハウ(共通点や相違点,注意点など)を,これまで従来型ソフトウエア開発を行ってきたSEやプログラマに向けて,紹介していきます。連載の後半では,実際にForce.com上でアプリケーションを開発し,クラウド上での開発の一端に触れ,そのメリットを肌で感じてもらいたいと思います。 標準的な開発プロセス Force.comを使用した

    これまでと何が同じで,何が違うか
  • 第10回 次につながる議事録づくりを!~チームを動かすための書き方~

    今回は「次につながる議事録づくりを!」と題して,議事録をどう書けばいいのかを解説しよう。 議事録には,会議での決定事項や決定に至るプロセス,残件などを明確にし,チームメンバーに行動を起させる,という大事な役割がある。議事録が配布されなかったり,配布が遅かったり,議事録の内容に問題があったりすると,会議での決定事項が実行されない恐れがある。それくらい,議事録は重要なのだ。 早速,前回のケーススタディの続きから,スタートしよう。 情報システム室主任の山田さとしがリーダーを務める,あけぼの産業の次期基幹システム再構築プロジェクトプロジェクト・メンバーはまず,各部門の業務・システムの問題抽出に取り組み,自部門の問題・課題をなんとか整理できた。山田は,問題・課題を全メンバーで共有し,他部門の観点から意見を出し合うための検討会議を開催。長時間にわたった検討会議もようやく終わろうとしていた・・・。 情

    第10回 次につながる議事録づくりを!~チームを動かすための書き方~
  • 第65回 [図解]Webサイト構築プロジェクト・ワークフロー - Webデザイン エンジニアリング:ITpro

    今回は,Webサイト構築プロジェクトのワークフローを俯瞰してみたいと思います。実際にクライアントから声がかかる場面から納品,つまり開発案件の完了までを12の「ステージ」に分けて図解してみました。思考のプロセス/人的配置/タスク/ツールなども一緒に記しています。少し大きな図になってしまいましたが,ご参考になれば。 図は,一番上は「4つのステップ/3つのタスク/12の要素(第62回 持続可能なWebサイト開発を支える12の要素)」。その下は,人的配置をロール(役割)ごとに記述しています。その下は,大まかなタスクのレベルです。それぞれの期間内に処理すべき項目を列挙しています。その下が,「ステージ」。プロジェクト全体を12のステージに分類して作業内容を整理しています。基的には,その流れの順で進んでいきます。その下は,それぞれのステージのアウトプットのイメージで,更にその下にはよく使うファイルアイ

    第65回 [図解]Webサイト構築プロジェクト・ワークフロー - Webデザイン エンジニアリング:ITpro
  • 第11回■制御文字や不正な文字エンコーディングによるぜい弱性を知ろう

    前回,入力値検証をセキュリティ対策として実施すべき理由を説明する中で制御文字や不正な文字エンコーディングの問題を指摘した。今回は,その具体例として「ヌルバイト攻撃」と「冗長なUTF-8によるディレクトリ・トラバーサル」を説明する。 制御文字悪用の代表格「ヌルバイト攻撃」 ヌルバイト攻撃とは,ASCIIコード0の文字(ヌル文字)を用いた攻撃である。リスト1に示すPHPスクリプトは,クエリー文字列pとして数値を受け取り,それを表示するというもの。結果を表示する前に正規表現関数eregを使って数字だけのデータかどうかをチェックし,数字でない場合にはエラーメッセージを表示するようになっている。通常,数字だけを使った攻撃は不可能であり,このような「安全な文字」だけを許可するような検査方法を一般に「ホワイトリスト検査」と呼ぶ。

    第11回■制御文字や不正な文字エンコーディングによるぜい弱性を知ろう
  • 第10回■保険的対策として欠かせない入力値の検証

    これまではアプリケーション開発以前の基盤の話題を説明してきたが,今回からいよいよ具体的な設計・開発におけるセキュリティ対策について説明する。まずは,Webアプリケーションへの入力値の取り扱いについてだ。 Webアプリケーションにおける「入力」とは,主にHTTPリクエストに含まれるクエリー文字列(Query Strings),POSTデータ(Post Data),クッキー(Cookie),その他のHTTPリクエスト・ヘッダー(Refererなど)といったものを指す。入力源としてはこれら以外にも,電子メール,ファイル,データベース参照などが挙げられる。 ぜい弱性はどこで発生するか 具体的なセキュリティ対策の説明を始めるに当たって,ここで改めてWebアプリケーションの基構造と,様々なぜい弱性がどこで発生するかを示しておこう。図1は,Webアプリケーションの動作を「入力/処理/出力」という古典的

    第10回■保険的対策として欠かせない入力値の検証
  • 第5回 XSLTの条件分岐,ノードのコピーを学習する

    前回に引き続き,今回もはてなダイアリー形式からJUGEM形式に変換するXSLTスタイルシートを例に,XSLTの基構文を学習します。なお,例1のXSLTスタイルシートは第4回と同じ内容です。 例1 はてなダイアリー形式からJUGEM形式に変換するXSLTスタイルシート ◇xsl:if命令 xsl:if命令(例1の38行目,41行目)は,test属性で指定された条件が真の場合にxsl:if命令の内容に記述されたテンプレートを実行します。test属性にはXPath式を記述し,真偽を判断します。 xsl:if命令による条件分岐

    第5回 XSLTの条件分岐,ノードのコピーを学習する
  • 1