こんにちは。 マイクロソフトの渡辺です。 アプリケーションのデザインパターンの1つである MVVM ( Model - View - ViewModel )。既に多くの実装例や MVVM パターンを採用した Framework が公開されています。 from Wikkipedia また、MVVM パターンは、C#/.NET/XAML の世界を中心に多く利用されてきましたが、最近では、JavaScript/HTML のアプリケーション開発で利用されることも多くなりました。 そして MVVM を理解する中で、また MVVM をサポートする Framework を利用する中では Model, View, ViewModel にとどまらず、Service, Command, Messenger, IoC, DI, Service Locator ..e.t.c といったキーワードに自然と出会うでし

2014-09-27: 該当サイト上にXSSがなくても攻撃可能であることが id:mayuki さんのコメントで判明しましたので全面的に書き直しました。ファイアウォール内であっても攻撃者はファイアウォール内のShellshock攻撃が通用するCGIのURLがわかっているだけで攻撃可能ですので早急に対応が必要です！会社のブログにも書いてますが、ファイアウォール内に置いてあるサーバで攻撃者が直接アクセスできないからといってbashの更新を怠っていると、条件によっては攻撃が可能となります。 条件としては、 そのサーバにはシェルを経由して外部コマンドを起動するCGI等が動いている(通常のShellshockの攻撃と同条件) 攻撃者がそのURLを事前に知っている(あるいは推測可能) となります。 攻撃者は、ユーザーを罠URLへ誘導し、以下のようなJavaScriptを罠ページ上で動かし、攻撃対象のW

バッチ処理とは 前回はWebアプリのアーキテクチャ設計の基礎を解説しました。今回はバッチ処理を円滑に行うためのアーキテクチャ設計のポイントを紹介します。 バッチ処理とは、蓄積された複数件のデータを、まとめて一括処理する処理形態のことを指します。このような処理形態においては、大量データの処理を一定時間以内に完了させるためのアーキテクチャを、さまざまな角度から検討していく必要があります。 また、画面オンライン処理とは異なり、ユーザーとの対話なく処理が進められます。よって、バッチ処理の途中でエラーが発生した場合の対応を考慮して、アーキテクチャを設計しなければなりません。バッチ処理の基本についてより深く知りたい方は、下記参考記事をご参照ください。 参考リンク:鉄板焼のお店から学ぶ、バッチ処理"超"入門（＠IT） バッチ処理におけるアーキテクチャ設計時の検討ポイント バッチ処理のアーキテクチャを考え

表題の作業をやったんですが、物凄く苦労しました。ググれば情報は出てくるんだけど、書かれた通りやっても上手くいかなかったり。 2020年版はこのページの一番下を参照。 サーバの構成とかによってもやり方変わるしね。詳しい方にアドバイス貰いつつ何とか出来ました。 サーバ Windows Server 2003 R2 SP2 SQLServer 2008 EXPRESS クライアント Red Hat Enterprise Linux 4 PHP5.2.14(PDOは使える状態) SQLServerと外部接続するにはODBCを使います。PHPで使えるのを調べてみるとPDO_DBLIBです。ネット上ではこれをインストールするには # pecl install pdo_dblib と書かれてたけど、エラーで出来ず。仕方ないので自分でコンパイルする事に。 その前にFreeTDSが必要なのでそっちを入れます

今回のお題は「MEF：Managed Extensibility Framework」。.NET Framework 4（Visual Studio 2010）で追加された、アプリケーションに拡張性を持たせることを目的としたフレームワークです。「re-buildなしにアプリケーションの機能拡張ができないか？」との相談を受け、MEFを試してみることにしました。 MEFは.NETライブラリですから、ピュアなC++では使えないけど「ほぼC++」なC++/CLIなら何とかなるんじゃないかと。MSDNで見つけたドキュメントを手掛かりに MEF：はじめの一歩をC++/CLIで踏み出しました。 DLL、COM、そしてMEF re-buildなしに機能拡張する手段はずっと以前からあります、WindowsではDLLがおなじみですね。DLLの中には関数名を埋め込むことができ、LoadLibrary()でDLL

こんにちは。望月です。 AWS上でシステムを構築する上で、「AWSのお作法に従う」のは印象以上に重要です。お作法に関しては色々とあるのですが、 *1その中でも一番大きいのは「サーバーは故障するものという前提で設計する」ことにあると思います。例えば、以下の様な点です。 WebサーバやAPサーバなどはロードバランサを介して冗長化し、単一障害点ではなくす 保管する必要のあるデータは全てS3に保管するか、EBSスナップショットを取得する等のバックアップを実施する DBはRDSをできるだけ利用することで、Multi-AZによる障害時自動フェイルオーバーによるサービス継続を実施する 上記１番目の「Web/APサーバの冗長化」ですが、オンプレミスからの移行の際にはこれへの対応が結構大変だったりします。例えば、アプリケーションからローカルのファイルを読み書きするような処理が入っている場合、そのファイルを両