最近のトラックバック

2017年4月
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30            

Google AdSense2

« 2009年8月 | トップページ | 2009年10月 »

2009年9月

Windows 7の「デスクトップの表示」機能の紹介とカスタマイズ

Windows 7の「デスクトップの表示」機能の紹介と各種カスタマイズについて書いてみた。



Windows 7から「デスクトップ表示」機能がいろいろと変更された。

・タスクバーの一部となり右端にボタン表示される。
・ボタンの上にマウスアイコンを乗せると全ウィンドウを透明化してデスクトップを強調表示する。
・タスクバーの右クリックメニューに「デスクトップを表示」追加。

■タスクバーの一部となり右端にボタン表示される。


■ボタンの上にマウスアイコンを乗せると全ウィンドウを透明化してデスクトップを強調表示する。


■タスクバーの右クリックメニューに「デスクトップを表示」メニューが追加。



デスクトップの表示ボタンにマウスアイコンを乗せた時の設定変更。

(1)タスクバーを右クリック→「プロパティー」メニューをクリック。
(2)「Aero プレビューの使用を利用してデスクトップをプレビューする」をONまたはOFF。

■(1)タスクバーを右クリック→「プロパティー」メニューをクリック。


■(2)「Aero プレビューの使用を利用してデスクトップをプレビューする」をONまたはOFF。



タスクバーに「Quick Lanch(クイック起動)」を復活する。
※Quick Lanchの中にはデスクトップの表示アイコンも含まれている。

(1)タスクバーを右クリック→「タスクバーの固定」をチェックOFF。
(2)タスクバーを右クリック→「ツール バー」→「新規ツール バー」を選択。
(3)フォルダテキストボックスに「%appdata%\Microsoft\Internet Explorer\Quick Launch」と入力。
(4)タスクバーに作成された「Quick Lanch」を右クリック→「ボタンの表示」および「タイトルの表示」をチェックOFF。

■(1)タスクバーを右クリック→「タスクバーの固定」をチェックOFF。


■(2)タスクバーを右クリック→「ツール バー」→「新規ツール バー」を選択。


■(3)フォルダテキストボックスに「%appdata%\Microsoft\Internet Explorer\Quick Launch」と入力。


■(4)タスクバーに作成された「Quick Lanch」を右クリック→「ボタンの表示」および「タイトルの表示」をチェックOFF。
(注意)下の画像はチェックONになっていますがOFFにしてください。


■変更後



テーマの「Windows クラシックモード」を利用するとタスクバーの端から「デスクトップの表示」ボタンが消え、 タスクトレイの一部にボタンが表示される。
※Aero機能も無効化されてしまいますが...。

(1)デスクトップで右クリック→「個人設定」を選択。
(2)「ベーシックテーマとハイコントラストテーマ」セクションの「Windowsクラシック」を選択。

■(1)デスクトップで右クリック→「個人設定」を選択。


■(2)「ベーシックテーマとハイコントラストテーマ」セクションの「Windowsクラシック」を選択。


■変更後のタスクバー右端



以前の[デスクトップの表示]アイコンの方が気に入っている場合、以前のアイコンを作ろう!
作成後、必要に応じてタスクバーに新規ツールバーを作りアイコンファイルを移動しよう!

(1)メモ帳を開き、以下のテキストを入力。
(2)「デスクトップの表示.scf」というファイル名で保存。


■(1)メモ帳を開き、上記テキストを入力。


■(2)「デスクトップの表示.scf」というファイル名で保存。


■作成イメージ






「一般利用者」「自作PC作成者」「アプリケーション開発者」「サーバ・インフラ構築/保守運用」の立場からみたWindowsの魅力

コネタマ参加中: あなたにとってWindowsの魅力ってなに?

「一般利用者」「自作PC作成者」「アプリケーション開発者」「サーバ・インフラ構築/保守運用」の立場からみたWindowsの魅力です。

※Microsoftの手先ではないのであしからず。
※個人ネタなので正確性は求めないでください。
※内容は全て個人的な感想です。



デファクトスタンダード(事実上の標準)なOSであり、利用ユーザ数が圧倒的に多いことです。
これ以上の魅力はないと思います。



他のOSと比べると、以下の点で優れていると思います。

■幅広い利用者がいる。
購入時のOS選択肢が少ないというのも要因ですが「子供からお年寄りまで」「1月未満のユーザから10年以上のベテランまで」幅広い利用者がいます。
ここまで誰も彼も利用するOSはないと思います。

■敷居が低い。
個人差はあると思いますが、1~2月あれば大抵の人は最低限の操作を習得できます。
少し話がずれますが、Windows XP等のクライアントOSの利用者がWindows Server系OSの利用者に ステップアップする際も非常に敷居が低いです。

■ソフトウエア・ハードウエアの対応製品の多さ
Windows以外にもパソコン系OSは沢山あるけど、Windowsに対応していないソフトウエア・ハードウエアは殆どない。
逆にWindows以外のOSは非対応という場合は非常に多い。
※XP・Vista等のバージョン違いによる対応/非対応という話は除いています。

■情報の豊富さ
ネットにも書籍にもWindows関係の情報が非常にあふれています。
初心者からベテランまで欲しい情報が手に入りやすい。

■トラブル発生時の対応のしやすさ
トラブルが発生しても、知人に聞いたり、ネットで調べると簡単に解決ができる場合が多い。
情報が見つからなくても、「教えて!goo」等の掲示板で質問すれば大抵は答えてくれます。
技術的なトラブルでもMicrosoftのサポートページは非常に広範囲にサポート情報が掲載されています。

■アプリケーション操作方法の統一性
Windowsはアプリケーション操作の統一がされています。
全く分野違いの新規アプリケーションを使い始めても100%ゼロから覚えるのはアプリケーション特有の機能だけに絞られます。
※現在は不明ですが、昔はアプリケーション開発におけるベストプラクティスがMicrosoftからダウンロードできた。



共通的なWindowsの魅力に書いたことは除きます。

■安定性・品質
ときどきLinux系のOSを使うことがありますが、コマンドベース操作(CUI)はともかくグラフィカル操作(GUI)の 品質・安定性はWindowsと比べ、まだまだな気がします。
なおMacは保有したことがないため対象外。

■上位互換性(操作方法)
パソコンが一般家庭に普及し始めてから10年以上経過しましたが、細かなエディションを除けば、 以下のメジャーバージョンアップがありました。
・Windows 95
・Windows 98
・Windows ME
・Windows 2000
・Windows XP
・Windows Vista
・Windows 7(パッケージは発売前)
「利用用途の拡大」「セキュリティ問題」「販促活動」等の理由でバージョンアップ自体は ある程度仕方ないところですが、バージョンアップ後に大きな操作の変更はありません。
幾つかのバージョンアップ時に、やや大きな操作方法の変更が発生しましたが直前バージョンの 知識の8割は次のバージョンで流用できるため「最初から覚えなおし」という試練(苦痛)は 発生していません。

■上位互換性(ソフトウエア)
10年前に買ったソフトウエアでも最新OSで動くことが多いです。
好例がMicrosoft Offic 2000です。
他にメーラ・圧縮・解凍ツール・エディタ・家計簿・スケジュール表等も10年前のもの でも十分動きます。
ゲームはWindows 2000以降の対応を表明していれば大概動きます。
システム調整ツールはOS依存性が高いので微妙ですが...

■上位互換性(ハードウエア)
古くても規格化されているハードウエアは大概動きます。
規格化されていない場合デバイスドライバ次第。
サポートを考えなければ、1つ前のバージョンのOS用に提供されているデバイスドライバを インストールすれば、7割ぐらいの確率で動きます。

■オールインワン
以下アプリケーションが標準インストールされています。
・Internet Explorer(ブラウザ)
・Windows Mail(メーラー)
・Media Player(メディアプレイヤー)
・各種アクセサリー
・etc.
初心者や既存インストールで満足しているユーザからみれば、購入後すぐ使えるのは便利です。
※Windows 7からはメーラー等の幾つかの機能が標準インストールされません。こちらも参考してみてください。
Windows 7 RTMを使ってみた



自作PC自体が「遊び・興味・趣味」「高性能ハードウエアを求めるゲームや動画編集ソフトを使いたい」という場合が 多いと思うのでWindows以外を入れるメリットは限定されると思いますが、とりあえず。
共通的なWindowsの魅力に書いたことは除きます。

■ハードウエアドライバのサポート状況
Windowsの場合、現在主流のOSのドライバは簡単に手に入りますが、他のOSの場合メーカ次第になってしまいます。

■OSインストールの簡易さ
Live CD等を持つLinuxを除けば、WindowsのOSインストールが非常に簡単です。
OS自体に含まれているドライバ種類も多く、OSの販売時期とハードエアの販売時期にもよりますが、ドライバの追加インストールも減ってきている気がします。
数年前から「ネットワーク越しにOSインストール」「USBメモリーにOSをインストール」等ができる環境が整ってきており 非常によいです。

■新しい技術に敏感
比較的、新技術への対応が早いです。
USBやUSB2.0が登場したときには、次のメジャーリリースですぐに対応していました。



アプリケーション開発もWindowsの魅力と言えないでしょうか?
共通的なWindowsの魅力に書いたことは除きます。

■システムコール(API)の違いとユーザ数
OSが異なるとシステムコール違いが発生するため、アプリケーション開発はOS個別で対応する必要が出てきます。
※Webアプリケーションは移植時ぐらいしか関係ない話ですが...

複数OSには対応するとアプリケーションを作ると開発コストが増えます。 また複数OSの「APIの違い」「できる・できないことの違い」も考慮する必要があります。
Windowsは、よほど特化したつくりでなければ、昔のアプリケーションが新しいバージョンのOSで動作します。
というわけで、圧倒的なユーザー数を持ち・上位互換性が高いWindowsは企画する側としても作る側としても利用ユーザとしても好都合です。

■長く使えるスキル
圧倒的なユーザ数であるためWindowsアプリケーションを求める企業が多く、Windows系の開発スキル(.NET Framework、VC等)は Java・C/C++と共に長く使えるスキルといえます。
また.NET Frameworkを使った開発は、Windowsアプリケーション・Webアプリケーションで似ている構成の フレームワークが用意されているため、スキルチェンジ(のとっかかり)が非常にしやすいです。
※歴史的にみると特定技術に胡坐をかくと突然の需要激減時に痛い目にあうけど...。



Windows XP / Windows Vista / Windows 7を搭載したPCはWindows Server Systemと連携をすることでネットワーク越しに管理がしやすい。
またセキュリティ対策や24時間稼働システムへの対策も豊富。
※ドメインを組んだり、追加のソフトウエア購入が必要ですが....

■ユーザ・コンピュータ等のリソース管理とポリシー
Active Directory

■ファイルやプリンターの共有
ファイルサーバ・プリンターサーバ

■ファイルサーバ上の共有ファイル閲覧権限の付与
Active Directory + ファイルサーバ

■データベースの上の機密情報の権限権限の付与
Active Directory + SQL Server

■社内向けのポータルサイトの構築
Active Directory + Microsoft Office SharePoint Server

■アプリケーションのライセンス管理や導入
Active Directory + Remote App

■メールやスケジュール表の一元管理およびメール送信規則等の設定
Active Directory + Exchange Server

■サーバ台数増加による運用コスト増加
Hyper-V

■サーバ性能や可用性の向上
MSCS・NLB

■業務推進アプリケーションのシングルサイオン
Active Directory + 業務アプリケーション (+ IIS の場合もある)

■業務推進アプリケーションのバージョンアップ
Active Directoryによるスタートアップスクリプト・Click once

■リモート操作
リモートデスクトップ接続・リモートアシスタント

etc.



■デフェクトスタンダードゆえの安心感。
世界的に利用ユーザ数が多数こといることを考えると、いずれWindowsが失墜するとしても時間がかかると思う。
失墜に数年かかればスキルチェンジするぐらいの時間は稼げると思う。



■OSのサポート期間が短い。
一番やなもの。
アプリケーションの互換性が高いとはいえ100%ではない。

■やや高い。(Windows XPやWindows Vista)
数年に1度の万円単位の出費は痛い。

■セキュリティホールに対する攻撃が激しい。
デフェクトスタンダードの宿命か...。
保険でセキュリティ対策ソフトを入れる必要がある。保守契約で年間数千円とんでいく...。

■独占状態。
デフェクトスタンダードの宿命か...。
利点も多いが、付け入る隙間が少ない。



この記事はあなたにとってWindowsの魅力ってなに?|コネタマ:@niftyに参加しているのだけどWindows 7販売まであと1月を切ったということが元ネタっぽいのでWindows 7も簡単に紹介。
エディションはWindows 7 Utlimate(64bitがメイン。32bitがサブ)。


1月ほどメインOSとして利用してみたが、Vistaと比較して非常に使いやすくなった。
全体的にマルチメディア面を強く出した感じだが、細かい操作が使いやすくなっている。
エクスプローラーやタスクバー等の普段使うツールの使い勝手の向上は非常にうれしい。
またライブラリ管理やデスクトップなどの特殊フォルダがすべてフォルダ指定できるためバックアップが容易だし、1つのPCでHDD毎に複数OSを載せている自分の環境では非常に使いやすくなった。
アクセサリーではペイントツールは利用することが多いため大幅拡張された点は評価したい。
パフォーマンス面での悪印象は全くない。

反面、悪い印象を受けたのは
①エクスプローラーの左画面で開いているフォルダとフォルダツリーの同期がなくなった。
 ※設定変更方法→Windows 7のエクスプローラ-フォルダーツリーの同期設定方法
②インストール直後に起動エラーが多発した。
 ※Windows 7起動中に固まる
③Aero Snap(ウィンドウが画面コーナーに吸い付くようにリサイズされる機能。)がウザい。
 ※設定変更方法→Windows 7のAero Snap機能紹介および無効化方法
④Windows Media Player 11の頃と比べると使い勝手が悪くなった。


※上記内容は本ブログの別記事から抜粋しています。興味のある人は下記の記事もみてください。
Windows 7 RTMを使ってみた




ASP.NET(C#)でIEのファイルダウンロードダイアログボタンをカスタマイズ

ASP.NET(C#)でIEのファイルダウンロードダイアログのボタンをカスタマイズしてみた。

※2010/02/03 続編(本サンプルの一部をJavaScript化)を追加
ASP.NET(C#)でIEのファイルダウンロードダイアログボタンをカスタマイズ(その2)
※2010/03/15 続々編(IE8限定技)を追加
ASP.NET(C#)でIEのファイルダウンロードダイアログボタンをカスタマイズ(その3)



IEのファイルダウンロードダイアログには「開く」「保存」「キャンセル」ボタンがあるが、以下のmetaタグを用意すると「開く」「保存」ボタンを非表示にできる。

※Windows XP SP2 付属のIE6以降のバージョンで対応。
参考: content Property (META, HTMLMetaElement Constructor) - MSDN ライブラリ


■content=""

■content="noopen"

■content="nosave"

他ブラウザで対応していないため用途は限定されるが、社内ネットワークでIEを標準ブラウザとしている等の限定条件が重なれば「ファイルを開かせたくない」「ファイルを保存されたくない」等の要望はあるはずだ。



上記機能とASP.NETを連携してファイルダウンロードダイアログのボタンを制御するサンプル。

実行結果及びASP.NETソースコードの確認




Windows 7のエクスプローラのフォルダーツリーの同期設定方法

Windows 7になってからエクスプローラの右側でフォルダを開いても左側のフォルダーツリーの同期がなくなった。
使いにくいなーと思っていたら同期設定があったので紹介する。

※Windows Server 2008 R2も同じ方法で設定できる。




(A)画面右側でフォルダを(ダブルクリック等で)開いても...




(B)左側のフォルダーツリーは変化なし



①「コントロールパネル」→「デスクトップのカスタマイズ」を選択。


②「フォルダオプション」を選択。


③「フォルダー オプション」ダイアログの「全般」タブ内の「ナビゲーション ウィンドウ」セッションで「自動的に現在のフォルダーまで展開する」をチェック。


※「エクスプローラ表示」→「Altボタンでメニューバー表示」→「ツールメニュー」→「フォルダー オプション」からでも「フォルダー オプション」ダイアログを表示できる。


■設定変更後

(A)画面右側でフォルダを(ダブルクリック等で)開くと




(B)左側のフォルダーツリーが同期して現在のフォルダを選択する。




Windows Server 2008 R2でデスクトップアイコンを表示

Windows Server 2008 R2でデスクトップアイコンを表示する方法について。


※本操作では「デスクトップ エクスペリエンス」機能を追加します。「デスクトップ エクスペリエンス」を追加すると以下の機能も有効になります。

  • Windows Media Player
  • デスクトップテーマ
  • フォト管理



Windows Server 2008 R2をインストール直後には「デスクトップ右クリック」→「個人設定」が表示されない。
「個人設定」にデスクトップアイコンの表示機能があるため、UI操作からデスクトップアイコンを有効にはできないようだ。

■「デスクトップ」右クリックメニューに「個人設定」がない


■「コントロールパネル」→「デザイン」に「個人設定」がない



「デスクトップ エクスペリエンス」機能を有効化すると「個人設定」を表示できる。
※個人的にはデスクトップアイコン表示/非表示ぐらいは追加インストールなしでUI設定したいのだが...テーマとの関係のせい?

設定方法は以下の通り

①「サーバーマネージャー」→「機能」ノード→「機能の追加」をクリック


②「デスクトップ エクスペリエンス」にチェック→インストール。
※必要機能で表示される「インクと手書きサービス」は追加。






③コンピュータを再起動




④再起動後には「個人設定」が有効になる。
■「デスクトップ」右クリックメニューに「個人設定」が表示される。


■「コントロールパネル」→「デザイン」に「個人設定」が表示される。


⑤「個人設定」→「デスクトップ アイコンの変更」をクリック。


⑥「デスクトップ アイコンの設定」ダイアログで表示アイコンを設定。



「デスクトップ エクスペリエンス」機能追加により、Windows Media Playerも使えるようになる。
※サーバ用途という意味ではあまり望ましくない気がするが...

■機能追加前はスタートメニューに「Windows Media Player」がない。


■機能追加後にスタートメニューに「Windows Media Player」が表示される。




ドメイン参加時にクライアントPC・サーバー設定で気をつけること

個人的な備忘録として、ドメイン参加時のありがちなトラブル対処方法をまとめておく。



本記事の操作手順は以下のOSで確認。
ドメインサーバ Windows Server 2008 R2
クライアントPC Windows 7

多少操作方法は異なるが、Windows 2000・Windows XP・Windows Vista・Windows Server 2003・Windows Server 2008でも基本は一緒のはず。


■別のPCから共有フォルダを検索できるようにしたか?
「コントロールパネル」→「ネットワークと共有センター」→「共有の詳細設定」から「ファイルとプリンターの共有を有効にする」にチェック。

これをしていないと以下の現象が発生する
①クライアントPCからドメインサーバが検索できず、認証に失敗することがある。
②クライアントPCからドメインサーバが検索できず、ログオン時に「現在、ログオン要求を処理できるログオン サーバはありません。」というエラーになる

■クライアントPCのコンピュータをリセットしたか?
「Actrive Directory ドメイン サービス」→「Actrive Directory ユーザーとコンピュータ」→「(ドメイン名)」→「Computer」をチェックし、 同名のコンピュータ名が存在するか確認。

同名のコンピュータ名が存在する場合、「同名の別コンピュータが存在」「PCの新調・交換時に同名のコンピュータ名を利用」「昔にドメイン登録した設定の残骸」のいずれかである。
「PCの新調・交換時に同名のコンピュータ名を利用」「昔にドメイン登録した設定の残骸」のケースの場合、「Actrive Directory ユーザーとコンピュータ」から該当のコンピュータ名を削除後に、クライアントPCから再度ドメイン登録を行う。

これをしていないと以下の現象が発生する
①クライアントPCからドメインサーバ認証で失敗する。

■DNSサーバサービスが止まっていないか?
※OS異常停止後やOS再起動後に
サービスが動いていないと以下の現象が発生する
①クライアントPCからドメインサーバ認証時にドメインが見つからない。


■優先DNSにドメインサーバIPを設定したか?
(1)「コントロールパネル」→「ネットワークと共有センター」→「アダプター設定の変更」内の「(該当の接続)」アイコンを右クリック。
(2)「ネットワーク」タブ→「インターネット プロトコル バージョン 4(TCP/IPv4)」のプロパティを開く。
(3)「次の優先DNSサーバのアドレス使う」→「優先 DNS サーバ」に、ドメインサーバのIPを設定。

これをしていないと以下の現象が発生する
①クライアントPCからドメインサーバ認証時にドメインが見つからない。

■ドメイン参加登録操作で完全修飾ドメイン名(FQDN)を指定したか?
(1)「コントロールパネル」→「システムとセキュリティ」→「システム」→「システムの詳細設定」をクリック。
(2)「コンピュータ名」タブの変更ボタンをクリック。
(3)「所属するグループ」→「ドメイン」テキストボックスに「~.com」とか「~.local」とかいうに完全修飾ドメイン名(FQDN)を設定。
※普段ドメインは省略名称(例えばMyDomain)を使うことが多いが、ドメイン参加時は完全修飾ドメイン名(例えばMyDomain.local)を使わないと駄目っぽい。

これをしていないと以下の現象が発生する
①クライアントPCからドメインサーバ認証時にドメインが見つからない。


PC固有問題は含まないよくあるチェック項目だけです。

■コマンドプロンプトからpingコマンドでドメインサーバのIPの接続確認。
(例)ping 192.168.1.200
接続NGならLANケーブル差込・LANケーブル断線・ネットワーク配線・ハブ故障等、物理的な問題が多い。
またはIP設定を忘れているとか

■コマンドプロンプトからpingコマンドでドメインサーバのコンピュータ名の確認。
(例)ping -4 MyDcServer
接続NGならDSN機能が働いていない可能性がある。
「コントロールパネル」→「管理ツール」→「サービス」内の「DNS クライアント」サービスを再起動してみる。

■エクスプローラのネットワーク検索でドメインサーバの共有フォルダが表示されるか?
別PCも同じ状態ならドメインサーバ側の問題かも。
該当PCのみの場合、ググって調べて...

■コマンドプロンプトからnslookupコマンドで完全修飾ドメイン名でドメインにアクセスできるか確認。
(例)nslookup MyDomain.local
接続NGならルータなどを利用しているならルーティングの問題。
または優先DNSの問題かも...

■ファイヤーウォールを無効化しても駄目か?
ファイヤーウォールが悪さをする場合が多いので、一時的に無効化して再確認。
※ファイヤーウォールの製品は大きく分けて「Windows付属」「ウィルスソフト付属」「個別の製品」に分かれるため、 該当製品ごとにファイヤーウォール無効化方法・ポートオープン方法を確認すること。

■複数のPCでドメイン参加できないか?
ハブやルーターを変えてOKなら機器破損。
それ以外ならドメインサーバ寄りの問題。

■ドメイン参加時のドメイン名・ユーザ名・パスワード名は正しいか?
管理者に再確認してね。

■上記設定を確認したか?
参照:クライアントPC側の設定


Hyper-V2.0上のWindows Server 2008 R2で80072EE2ライセンス認証エラー

※同じ現象が発生している人の為にメモっておきます。

Hyper-V2.0上の仮想マシンにWindows Server 2008 R2をゲストOSとしてインストール後にライセンス認証を行うとタイムアウトエラー 「80072EE2」が発生。



ちなみにHyper-V1.0上の仮想マシンにWindows Server 2008 R2をインストールしたときは同エラーは発生しない。

ありがちな原因であるファイアーウォールも切ってみたがエラー解消に至らなかった。

「80072EE2」でググってみたが多くはWindows Updateがらみの原因対策だったが、うちの環境ではWindows Updateは問題なかった。

検索中に「時間がたってみたら解決していた」というページがヒットしたので、半日ほど放置したらライセンス認証に成功!!



最後に認証エラーが発生してから設定を変更していないので認証サーバー側に問題がある気がする。


仮想マシン(ゲストOS)をHyper-V1.0からHyper-V2.0に移動

Windows Server 2008のHyper-V1.0 仮想マシン(ゲストOS)をWindows Server 2008 R2のHyper-V2.0に 移動してみた。

※Windows ServerはFullインストール版を利用しています。


  • Windows XP SP3
  • Windows 7
  • Windows Server 2003 R2 SP2
  • Windows Server 2008 SP1




■仮想マシンのエクスポート(Windows Server 2008のサーバーマネジャーを利用)

①仮想マシンにCD/DVDやISOイメージファイル等がキャプチャされていないことを確認。
※下記イメージはISOイメージをキャプチャー中なので解除が必要!!


②仮想マシンをエクスポート。


その後、エクスポートフォルダをインポート対象サーバにコピー。


■仮想マシンのインポート(Windows Server 2008 R2のサーバーマネジャーを利用)

①「仮想マシンの追加」を選択。


②エクスポートしたフォルダを選択後、インポート。


インポート結果



■インポート後の設定(ネットワークアダプタ設定変更)
仮想マシンの設定メニューからネットワークアダプタを変更。
※ネットワークアダプタ名がエクスポート時と同じ名称の場合は不要みたい。



■インポート後の設定(統合サービスセットアップディスクのアップグレード)
仮想マシーンを起動し「統合サービス セットアップ ディスク」をインストール。
※「統合サービス セットアップ ディスク」はHyper-V2.0からバージョンアップしているためアップグレードが必要。





移行作業自体は非常に簡単だった。

気をつけなければ...と思ったことは以下の通り。
①エクスポート前にCD/DVDやISOイメージファイルをキャプチャーしていたら解除しないとインポート時にエラー報告される。
 ※エラー報告だけであり、動作に影響はないようだ。
②エクスポートしたらフォルダごとバックアップを取っておくこと。
 ※インポートの際、Hyper-Vサーバがファイルを書き換えてしまう。作業が一発で成功すればよいが失敗すると復旧できない。
③インポート後に「ネットワークアダプタ設定変更」「統合サービスセットアップディスクのアップグレード」が必要。
 設定方法は前述の移動手順を参照


Windows 7のAero Snap機能紹介および無効化方法

Windows 7 RTMの新機能「Aero Snap」について調べてみた。




「Aero Snap」はドラッグ・リサイズ中のウィンドウがデスクトップの端に吸い付くように自動リサイズする機能。
  • キャプションを画面上端にドラッグするとウィンドウを最大化。
  • 左右どちらかにドラッグするとその方向にウィンドウをリサイズ。
  • 上下端までリサイズするとウィンドウが上下一杯方向にウィンドウをリサイズ。

■キャプションを画面上端にドラッグするとウィンドウを最大化。

  ↓

 ↓


■左右どちらかにドラッグするとその方向にウィンドウをリサイズ。

 ↓

 ↓


■上下端までリサイズするとウィンドウが上下一杯方向にウィンドウをリサイズ。

 ↓

 ↓



Windows 7を使い始めた当初は「Aero Snap」は便利に思えたが、複数ウィンドウで作業をするときは意外と邪魔な時も多い。
無効化する方法は、以下の通り。
  1. コントロールパネルを開く。
  2. 「システムとセキュリティ」→「コンピューターの簡単操作」→「マウス動作の変更」を選択。
  3. [マウスを使いやすくします]をクリックする。
  4. 「ウィンドウの管理を簡単にします」セクションにある「ウィンドウが画面の端に移動されたときに自動的に整列されないようにします」をチェックしたのち、OKまたは適用ボタンクリック。
■コントロールパネルを開き、「システムとセキュリティ」を選択。

 ↓
■「コンピューターの簡単操作」を選択。

 ↓
■「マウス動作の変更」を選択。

 ↓
■「ウィンドウが画面の端に移動されたときに自動的に整列されないようにします」をチェック。






C#でDIを実装

C#でDI(Dependency Injection)を実装するサンプルを紹介する。


■DIとは

依存性の注入 (いぞんせいのちゅうにゅう、Dependency Injection)とは、 コンポーネント間の依存関係をプログラムのソースコードから排除し、 外部の設定ファイルなどで注入できるようにするソフトウェアパターンである。
依存性の注入を利用したプログラムを作成する場合、 コンポーネント間の関係はインターフェースを用いて記述し、 具体的なコンポーネントを指定しない。 具体的にどのコンポーネントを利用するかは外部ファイルに記述することで、 コンポーネント間の依存関係をソースコードから排除できる。

依存性の注入 - Wikipediaから抜粋。

私の独自解釈では以下のとおり。

DIのインタフェースは主にStrategy パターンの為の規約であると考えている。
Strategy パターンはアルゴリズムを動的に切り替え可能な仕組みである。インタフェース(interface、base class)で内部構造を公開し、派生クラス先で独自の実装が可能とする。
複数の派生クラスの切り替え方法を設定ファイルを利用することでビルドを利用しない疎結合が生まれ、開発後に容易にアプリケーション内部の動作を変更できる。

※独自解釈の為、誤りや理解不足があると思います。話半分ぐらいで読んでいただけると非常に助かります。

■登場するクラス/処理
①インタフェース(intaface、base class)
②インタフェース継承クラス
③設定ファイルを基にインタフェース継承クラスのインスタンスを生成し、①②の変数に設定。
④③で作成したインスタンスをインタフェース経由で利用する処理。

■プロジェクト構成
本サンプルは以下の4プロジェクト構成となっている。
DLL/EXEファイル 概要 クラス/インタフェース プロジェクト名 プロジェクト参照/アセンブリ参照
DIBaseLib.dll 内部構造の公開仕様となるインタフェース/ベースクラスを含むクラスライブラリ。 DIInterface
DIBaseClass
DIBaseLib -
DIDerivedLib1.dll 公開仕様の派生クラスその1。
DIInterfaceまたはDIBaseClassの派生クラスを持つクラスライブラリ。
DIDerivedInterface1
DIDerivedClass1
DIDerivedLib1 DIBaseLib
DIDerivedLib2.dll 公開仕様の派生クラスその2。
DIInterfaceまたはDIBaseClassの派生クラスを持つクラスライブラリ。
DIDerivedInterface2
DIDerivedClass2
DIDerivedLib2 DIBaseLib
UseDIConsole.exe DIを利用するコンソールアプリケーション。
DI切り替えの設定ファイルも本プロジェクトで作る。
Program
Setting
UseDIConsole DIBaseLib System.Configuration



実際の開発時には上記のように複数プロジェクト・DLLに分けるのは必須ではない。
内部構造の公開仕様に当たるDIBaseLib.dllの部分を、外部の開発者に公開するつもりがなければ、1プロジェクトで完結することも可能だ。

■ファイル・フォルダ構成
各種ファイルは以下の配置をするものとする。
実行ファイルを起点とした相対パスでDI派生クラスDLL格納先binフォルダを作成する。

アプリケーションフォルダ
│  DIBaseLib.dll
│  UseDIConsole.exe
│  UseDIConsole.exe.config
│  
└─bin
        DIDerivedLib1.dll
        DIDerivedLib2.dll



なおGAC(グローバル・アセンブリ・キャッシュ)にアセンブリを登録する場合、DLLファイルの保管先は上記以外でも構わない。

■アプリケーション構成

・DIDerivedInterface1クラス・DIDerivedInterface2クラスはDIInterfaceインタフェースを継承。
・DIDerivedClass1クラス・DIDerivedClass2クラスはDIBaseClassクラスを継承。
・Programクラスは、Settingクラスを経由して構成ファイルを読み取る。※Settingクラスはプロパティ-設定するとVisual Studioが自動生成。
・Programクラスは、構成情報ファイルからインタフェース継承クラスを作成、インタフェースインスタンスに設定する。
・Programクラスは、DIInterfaceインスタンス・DIBaseClassインスタンスを利用して各派生クラスのShow()メソッドを呼び出す。


■内部構造の公開仕様となるインタフェース/ベースクラスを含むクラスライブラリ。(DI.cs - DIBaseLib.dll)

■公開仕様の派生クラスその1。(DIDerived1.cs - DIDerivedLib1.dll)

■公開仕様の派生クラスその2。(DIDerived2.cs - DIDerivedLib2.dll)
■DIを利用するコンソールアプリケーション。(Program.cs - UseDIConsole.exe)
■DIを利用するコンソールアプリケーションの構成ファイル。(UseDIConsole.exe.config → UseDIConsoleプロジェクト内ではapp.config)
<DIDerivedLib1.dllを利用する場合>
<DIDerivedLib2.dllを利用する場合>
<画面イメージ:UseDIConsoleプロジェクトのプロパティ設定>


■実行結果
<DIDerivedLib1.dllを利用した場合>


<DIDerivedLib2.dllを利用した場合>


※NET FrameworkのDI機能を一部のみ掲載。
機能 概要 利点 DIの交換部品 備考
DBProviderFactory
[ADO.NET]
DB操作の切り替え ■DBMS毎に用意することでDB操作のパフォーマンス向上とプログラム内の接続・参照・更新・トランザクション等のDB操作の統一化が可能。
■DBMSの種類を交換した時に対応しやすい。※DMBS毎のSQLの方言は除く。
■(金銭面や納期の関係で)テスト環境・運用環境で異なるDBやDB接続ドライバを使う場合に対応しやすい。
■ODBC接続(昔のDAO)
■OLE DB接続(昔のADO)
■SQL Server
■Oracle
■DB2
■MySQL
その他に各種ベンダーが提供。
ADO.NET Entity Frameworkの裏方でも使われている。
設定ファイルに複数登録できるためプラグインとしての要素もある。
セッション
[ASP.NET]
セッションデータ保存先の切り替え ■開発PC・テストサーバ・運用サーバのスペックに応じた保存先の変更が可能。
■運用後に保存先を変更しやすい。※プログラム改修は不要。環境変更だけで対応可能。
■セッションを使わない。
■セッションデータをメモリー上に保持。(高速。IISダウンや再起動でデータが失われる。負荷分散しずらい。)
■セッションデータを別プロセス上に保持。(中速。データ保持プロセスダウンでデータが失われる。)
■セッションデータをDBサーバ上に保持。(低速。DBサーバにクラスタリングやHDDにRAIDなどを用いれば、ほぼデータが失わることはない。)
ミッションクリティカル(24時間365日止まらないことを要求されること)に近づくほどセッションデータ保持方法は重要度を増す。
ASP.NETプロバイダモデル(認証)
[ASP.NET]
認証方法の切り替え ■ユーザ認証など保持方法や操作方法に関わらず操作の統一的化が可能。
■Windows認証を利用した。クライアントPC、ActiveDirecotyからのユーザ情報取得。
■DB等のデータストアからの認証データ取得・更新。
■その他、独自ロジックを用いた認証データの取得・更新。
ASP.NETプロバイダモデルはASP.NET2.0以降ではASP.NET Frameworkの重要な概念(だそう)です。
認証以外にもあるようだ。

詳細を知りたい場合、以下の文献を参考してみてください。
プログラミングMicrosoft ASP.NET 3.5 (マイクロソフト公式解説書 Microsoft Visual Studio 2008)
プログラミングMicrosoft LINQ (マイクロソフト公式解説書 Microsoft Visual Studi 2008)
ASP.NET 2.0 ~実践.NET Framework+Ajax Extensionsで実現するWebアプリ

これらの選択は開発前に考えることであるため、以下も参照してみてください。
開発前に考えること - niyoな日記


※注意
この考察は記事を書いた時点での記述者の考えです。
「全てのケースに対応」とか「一般的な考え」とか「ベストプラクティス」とかではありませんし、いうつもりもありません。
話半分ぐらいで読んでいただけると非常に助かります。

■DIはどんな時につくるの?
ほとんどが環境的な要因でアルゴリズムを開発中・開発後に変更する場合だと思う。
①単体テスト用のスタブ。他システム連携のインタフェースのスタブ。
②複数プロジェクトで使うフレームワーク作成し、なおかつプロジェクトに応じて部分的な内部処理を交換可能にしたいとき。
③DLLを分割することでビルド時間を少しでも短縮したい場合。
④コーディングが始まったがミドルウエアや接続ドライバが確定しない。または手元に届かなかった場合の代用品。

④を除くと、複数の企業が参加する大規模開発かつインタフェース抽出が可能な場合でないと費用対効果はほとんどないと思う。
もしくは独自フレームワークソフトウエア作成し販売する企業や、フレームワークソフトウエアを配布するオープンソースプロジェクトぐらいかも?

また、下記ページの内容も興味深いので参考してほしい。
InfoQ: 依存性注入(DI)は成功したか?
InfoQ: Does Dependency Injection pay off?(上記原文)

■そもそもDIて必要?
ほとんどのアプリケーション開発では不要です。
但し、フレームワークソフトウエアを提供側からみれば、ほぼ必須の概念です。

■仕様公開するのはインタフェース。それともベースクラス?
個人的にはベースクラスのほうがインタフェースよりも使い勝手がよいと思う。
理由はC#でプラグイン実装 - niyoな日記の 説明と同じです。
またプログラミングMicrosoft ASP.NET 3.5 (マイクロソフト公式解説書 Microsoft Visual Studio 2008)に「インタフェースと基底クラス」という以下のコラムがあります。


プロバイダモデルを最初にサポートした最初のASP.NETのバージョンであるASP.NET2.0のプリベータビルドでは、Strategyパターンの定義をそのまま利用した(つまり、インタフェースを使用)プロバイダモデルを実装していました。Bate 1の期間に、インタフェースは基底クラスに置き換えられ、リリースバージョンでもそのようになりました。ASP.NETチームは、この問題に対して結論を出したように思えますが、実際のところどうなのでしょうか?
インタフェースは、論理的に関連するメソッドを集めてたものでありメンバの定義のみが含まれ、コードは一切含まれません。インタフェース型は、型の部分的な説明であり、複数のクラスによってサポートされている可能性があります。良いインタフェースとは、何種類かの型によって実装されクライアントが使用したいと思うような便利で汎用的な機能をカプセル化したものです。IDisposable、IComparable、IFormattableのように、多くのインタフェースの後ろに「able」が付いているのはこのためです。インタフェースを実装する便利なクラスが1つしかないとしたら、それは不適切な設計を選択した結果でしょう。経験則として、新しいインタフェースは控えめに、深慮をもって導入すべきです。
基底クラスは子クラスのツリーに共通する振る舞いとプログラミングインタフェースを定義します。クラスはインタフェースよりも柔軟であり、バージョン管理をサポートします。ASP.NET2.0のクラスに新しいメソッドを追加した場合、そのメソッドが抽象メソッドでなければ、既存の派生クラスの機能はそれ以降も変化しません。だが、インタフェースではそうはいきません。
これらの点を踏まえると、可能な限り、インタフェースではなく基底クラスを使用すべきである、という規則が得られます(「常に基底クラスを使用する」ということではありません。)。筆者が思うに、プロバイダモデルに関する限り、基底クラスはすばらしい選択に思えます。
より一般的にいえば、基底クラスとインタフェース間の議論には簡単な答えはありません。実際、一部のアプリケーションに関しては、インタフェースで定義できる振る舞いに基底クラスを使用するのは、全体的な設計向上につながるカスタム基底クラスから新しいクラスの派生という選択肢を奪うものである、という意見もあるでしょう。ASP.NETは、そのプロバイダモデルに基底クラスを使用しており、そのパターンに従わなければなりません。


ASP.NETプロバイダモデルはDIの発展したみたいな概念であるため、DIでも一考の余地はあると思います。








Windows 7 RTMを使ってみた

Windows 7 RTM版を使ってみた。


OS Windows 7 Ultimate (32ビット)
CPU Intel Core 2 Duo E6700 2.66GHz
メモリー 6GB(有効メモリ2.94GB)
HDD 120GB(32bit版)
画面解像度 1280×1024

インストール直後の画面


ビルド番号(NT6.1 ビルド7600)


インストール直後のメモリー使用量(685MB)


インストール直後のHDD容量(10.6GB)


インストール直後のパフォーマンス


※起動・終了イメージはHyperV上でWindows7を起動・終了したときのイメージを利用しています。

起動中


シャットダウン



全体イメージ


デフォルト


すべてのプログラム


最近使った項目...アプリケーション毎に設定されるようになった。



全体イメージ...クイック起動バーがなくなった。


タスクスイッチ...タスクバーに表示されるの表示中のウィンドウがタイトル名アイコンからアイコンに変わった。


デスクトップの表示...タスクバーの右端に移動した。またマウスカーソルをボタンに乗せるとデスクトップが表示される。


ジャンプリスト...タスクスイッチの右クリックメニュー。「よくつかうもの」「すべてのウィンドウを閉じる」等が表示される


Aeroプレビュー...タスクスイッチにマウスカーソルを移動すると現在開いているファイル一覧がプレビューされる。



カテゴリ


小さなアイコン...幾つか新しい項目が増えている。



画面左側が変わった。アイコン毎にツリー表示できる。


ライブラリ管理。1つのライブラリに対し複数のフォルダを登録できる。


マイドキュメント


自由配置が可能になった。



スタートメニューからみたアクセサリー。


付箋...ガジェットから単体アプリに変更。URLのリンク移動も可能


数式入力パネル...計算は出来ないみたい。


ペイント...大幅修正。リボン化。
飛躍的に向上した。




ワードパッド...リボン化。機能はあまり変わっていない。


電卓...大幅修正。普通の電卓・関数電卓・プログラマ・統計の4種に分割&機能拡張。

通常の電卓
関数電卓

統計
プログラマ

Windows PowerShell...標準搭載された。ランタイムバージョンはv2.0.50727。
コマンドプロンプトやWSHの代わりになれるか?


Windows 7から、Messanger・メール・ムービーメーカー等は標準搭載されなくなった。
しかし、Windows Liveからダウンロードできる。
簡単なインストール手順は以下の通り。

①スタートメニュー→はじめに→Windows Liveを選択。


②ダウンロードボタンクリック。


③ダウンロード実行。


④必要なアプリケーションをチェックしてインストールボタンクリック。


■Windows Live メール


■Windows Live ムービーメーカー


Internet Explorer 8を標準搭載。





Windows Media Player 12を搭載。
エクスプローラーのライブラリ管理と連動している。






簡単に調べてみた。以下の通り
NO. ライブラリ 対応バージョン
1 .NET Framework 2.0SP2、3.0SP2,、3.5SP1
2 C,C++,MFCランタイム VC6以前なら動きそう。VC7以降ならアプリケーションと一緒に追加でインストールしないと駄目っぽい。
msvcirt.dll,msvcp60.dll,msvcrt.dll,msvcrt20.dll,msvcrt40.dll,mfc40.dll,mfc40u.dll,mfc42.dll,mfc42u.dllを確認。
3 VB6.0ランタイム日本語版 日本語版は入ってないがVB6.0ランタイム自体は入っている。
VB6.0でよく利用したocxはほとんど入っていない。
4 Direct X 11
※DirectX 9のエンドユーザーランタイムをインストールしないと動かないゲームがいくつかあった。上位互換はないのか?
5 WSH,VBScript WSH(5.8)、VBScript(5.8.16385)

Windows Vista(R)、 Windows Server 2008(R)、および Windows 7 における Visual Basic 6.0 のサポートについて


1月ほどメインOSとして利用してみたが、Vistaと比較して非常に使いやすくなった。
全体的にマルチメディア面を強く出した感じだが、細かい操作が使いやすくなっている。
エクスプローラーやタスクバー等の普段使うツールの使い勝手の向上は非常にうれしい。
またライブラリ管理やデスクトップなどの特殊フォルダがすべてフォルダ指定できるためバックアップが容易だし、1つのPCでHDD毎に複数OSを載せている自分の環境では非常に使いやすくなった。
アクセサリーではペイントツールは利用することが多いため大幅拡張された点は評価したい。
パフォーマンス面での悪印象は全くない。

反面、悪い印象を受けたのは
①エクスプローラーの左画面で開いているフォルダとフォルダツリーの同期がなくなった。
 ※設定変更方法→Windows 7のエクスプローラ-フォルダーツリーの同期設定方法
②インストール直後に起動エラーが多発した。
 ※Windows 7起動中に固まる
③Aero Snap(ウィンドウが画面コーナーに吸い付くようにリサイズされる機能。)がウザい。
 ※設定変更方法→Windows 7のAero Snap機能紹介および無効化方法
④Windows Media Player 11の頃と比べると使い勝手が悪くなった。





C#でプラグイン実装

C#でプラグインを実装するサンプルを紹介する。


■プラグインとは
ここに来る人ならプラグインがどんなものか知っていると思うが一応記述する。

  • アプリケーションソフトウェアの機能を拡張するために追加するプログラムの一種。
  • 誰でも差し替え可能になっているアプリケーションコードの一部分を、プラグインと呼ぶ。
  • プラグインを利用する者に開発者と同じコンパイラを用意させるのは現実的ではないので、プラグインの場合、ダイナミックリンクライブラリと呼ばれる機構を使って、アドレスを間接的に参照する事によりこの問題を回避する。

プラグイン - Wikipediaから抜粋。

というわけで、本サンプルでもDLLを利用しプラグインを実装する。
なお多く場合、C#ではインタフェースやベースクラスを利用したポリモーフィズム(多態性)を利用することになる。
デザインパターンでいえばStrategy パターンかな?

■プロジェクト構成
本サンプルは以下の4プロジェクト構成となっている。
DLL/EXEファイル 概要 クラス/インタフェース プロジェクト名 プロジェクト参照
PluginBaseLib.dll プラグイン仕様となるインタフェース/ベースクラスを含むクラスライブラリ。 PluginInterface
PluginBaseClass
PluginBaseLib -
PluginDerivedLib1.dll プラグインその1。
PluginInterfaceまたはPluginBaseClassの派生クラスを持つクラスライブラリ。
PluginDerivedInterface1
PluginDerivedClass1
PluginDerivedLib1 PluginBaseLib
PluginDerivedLib2.dll プラグインその2。
PluginInterfaceまたはPluginBaseClassの派生クラスを持つクラスライブラリ。
PluginDerivedInterface2
PluginDerivedClass2
PluginDerivedLib2 PluginBaseLib
UsePlginConsole.exe 上記プラグインを利用するコンソールアプリケーション。 UsePlugin
Program
UsePlginConsole PluginBaseLib



■フォルダ構成
プラグインDLLは所定の場所に置く必要がある。
実行ファイルを起点とした相対パスでプラグイン専用フォルダを作成する。

アプリケーションフォルダ
│  PluginBaseLib.dll
│  UsePlginConsole.exe
│  
└─Plugin
        PluginDerivedLib1.dll
        PluginDerivedLib2.dll



■アプリケーション構成

・PluginDerivedInterface1クラス・PluginDerivedInterface2クラスはPluginInterfaceインタフェースを継承。
・PluginDerivedClass1クラス・PluginDerivedClass2クラスはPluginBaseClassクラスを継承。
・UsePluginクラスのfnLoadPluginInstance()メソッドは指定フォルダからPluginDerivedLib1.dllとPluginDerivedLib2.dllをロード、 PluginInterfaceまたはPluginBaseClassを継承しているクラスを探し、インスタンス化したのち、継承元のリストに登録する。
・UsePluginクラスのfnUsePluginProc()メソッドはリスト登録されたPluginInterfaceまたはPluginBaseClassの派生クラスをShow()メソッドを介して、派生先でオーバライドされたShow()メソッドを実行。


■プラグイン仕様となるインタフェース/ベースクラスを含むクラスライブラリ。(Plugin.cs - PluginBaseLib.dll)
■プラグインその1。(PluginDerived1.cs - PluginDerivedLib1.dll)
■プラグインその2。(PluginDerived2.cs - PluginDerivedLib2.dll)
■上記プラグインを利用するコンソールアプリケーション:プラグイン利用クラス。(UsePlugin.cs - UsePlginConsole.exe)
■上記プラグインを利用するコンソールアプリケーション:Programクラス。(Program.cs - UsePlginConsole.exe)
■実行結果


※注意
この考察は記事を書いた時点での記述者の考えです。
「全てのケースに対応」とか「一般的な考え」とか「ベストプラクティス」とかではありませんし、いうつもりもありません。
話半分ぐらいで読んでいただけると非常に助かります。

■プラグインはどんな時に作る?
まず遊び心が必要です。
ついでに、
◆インタフェース/ベースクラスを抽出できるが、開発者サイドで全ての機能を用意できない(しない)場合。
◆処理拡張が必要で、かつインタフェース/ベースクラスを抽出できる場合。
◆画像・音楽・動画のように多種の既知・未知のファイルフォーマットを扱う場合。
◆一般公募や特典のオマケでゲームを拡張したい場合。
 ※アクションゲームの武器、カーレースで車種・パーツ拡張・格闘ゲームで追加キャラ等
◆ブラウザやオフィスソフトのようなアドオン機能を提供する場合。
◆既知・未知を含め複数デバイスをサポートするアプリケーションの場合。

■そもそもプラグインって必要?
ほとんどのアプリケーションでは不要です。

■プラグインはいつ構想・実装する?
開発初期から構想しておくほうが望ましい。。
初回リリースからプラグインを一般公開しなくても設計段階でインタフェース/ベースクラス抽出したほうがよい。
リリース後に必要に応じてプラグイン化も可能だが構造変更のインパクトが非常に大きい。

■仕様公開するのはインタフェース。それともベースクラス?
個人的にはベースクラスのほうがインタフェースよりも使い勝手がよいと思う。

<ベースクラスのメリット>
◆利用頻度の高いフィールド変数を事前に用意できる。
◆共通処理をメソッドとして提供しやすい。
◆デザインパターン「template method」やイベントが使いやすい。
◆提供側がバージョンアップ時の機能拡張がしやすい。

<ベースクラスのデメリット>
◆シンプルなインタフェースと違い処理を内包するため不具合が起こりやすい。
 →修正したモジュールの再配布率があがる。
  →修正モジュールの配布が非常に手間。
   →利用側が修正モジュールをテストをしてくれない。
    また不具合を利用したプラグインを作られると目も当てられない
◆多重継承ができないため、利用側の自由度が低くなる。






« 2009年8月 | トップページ | 2009年10月 »

Google AdSense


  • ---

Amazon ウィジェット

  • ウィジェット

@niyo_naのツイート

無料ブログはココログ

Google Analytics