Visual Studio 2003でVisual SourceSafe 6.0dとの統合がされていない時や統合されなくなった時の解決策を説明します。
Visual SourceSafe 6.0dのexeのあるフォルダ（スタートメニューのVSSのプロパティを見ればわかる）に
SSINT.EXE
というファイルがありますので、それを実行します。
統合セットアップが起動しますので、そのままOKボタンを押下し,
Installed was successfull.
というメッセージが出たら成功です。
参考
私自身、社内のシステム開発用フレームワークを一人で設計・開発していて、ちょっと前までは、自分の参画するプロジェクトでのみ採用していた。
最近、私が参画しないプロジェクトでも採用するようになり、いろいろとサポートをする必要が出てきたのだが、その過程でフレームワークを理解するために最も重要な事というのが何なのかが分かったような気がする。
それは、
「フレームワークの機能に何があるかを知る」
事ではない。
勿論、フレームワークの機能を知る事で、ある程度フレームワークの能力を発揮する事が出来るかもしれない。
しかし、フレームワークの設計者が知っているであろう最適な使い方にはならないだろう。
だから、「まず最初にフレームワークの詳細な機能について知ろう」と思う必要は無い。
もっと大切な事を理解してからでも遅くない。
むしろ、その方が個々の機能について最適な使い方とセットで理解できるので有益だ。
では、何が最も重要なのかというと、
「フレームワーク自身が持っている思想を知る」
という事である。
どんな意図でフレームワークが存在しているのか。
どんな意図でフレームワークの設計がこのようになっているのか。
どんな開発手法を想定して作られたフレームワークなのか。
それを理解する事が最も重要な事であるように思う。
これが理解できれば、各機能の最適な使い方は自ずと知る事ができるはずである。
だから、フレームワークのセットだけポンと渡されても困るし、リファレンスだけ渡されてもなかなか最適解にたどり着けない。
むしろ、フレームワークとしては中途半端である。
ちゃんと、フレームワークを作った理由や設計思想、最適な開発手法まで一緒に渡してあげる必要がある。そこまで渡して初めてフレームワークとして機能するのではないだろうか。
なんて事を昔から思っていたのだが、より一層強く思うようになった。
下手なメタファは有害だが、それを覚悟で喩えるなら、
「言語が分かっても、その背景にある文化が分からないと、なかなかうまくコミュニケーションが取れない」
という事。
「よっしゃ、WiFi設定OK！」と思ってSafariを起動すると、3Gネットワークで接続してしまいます。ここは落ち着いて、
・機内モード オン
・WiFi オン
に設定しましょう。これで3Gを経由せずに強制的にWiFiで接続するようになります。
中略
もちろんスピードは速いです。とはいえ、バッテリ消費も早いというトレードオフ関係にありますので、用途に応じて使うべき、という感じでしょうか。
個体差があるのかな。
私のと妻のiPhoneではちゃんと3GよりもWiFiが優先されるんだけどなぁ。
家でもWiFiが優先されるし。
何か私が勘違いしているのかな。
あと、3GよりもWiFiの方がバッテリの消費は少ないです。
iPhoneを使っていると
「この液晶って、今時の携帯に比べると低解像度なんじゃなかったっけ。」
と不思議に思う事がある。
低解像度である事を感じさせないUIを実現しているからだ。
いや、
「ああ、ある程度の解像度があれば、もう物理的な解像度なんかあまり関係ないんだな。」
という事に気づく。
むしろ、低解像度である事を感じさせないために低解像度である事のデメリットが無くなり、低解像度である事で必要なリソースが少なくすむ分、他の事にリソースを割けるようになっておりメリットの方が多いのではないかと思う。
今年も、秋冬モデルとかいって、HXGAやFWVGA等の高解像度な携帯が出てきているが、あの画面サイズで心地よく利用できる解像度を不必要に超えているように思う。
実際にUIが、その高解像度を有効利用できておらず、ただ表示のために必要なリソースを無駄に浪費するつくりになっているのでは無いだろうか。
そろそろ、CPUやGPU、メモリとバランスの取れた画面解像度で、いかに心地よいUIを実現できるかに腐心する時が来たのでは無いかと思う。
#とはいえ、iPhoneのメモリは今の4倍くらいほしい。
仕様書を書くときでも、何も処理しない場合は、あえて、「何もしない」など
と記述してますので、それがコーディングに反映している感じです。
仕様書と合わせる意味でも、わざわざ、Notを付けて、否定に書き換えたり
しないですね。
例??
If IsExists() Then
'何もしない
Else
fileName = String.Empty
End If
私は、空のIF文は書かないですね。
比較的許容できない方だと思います。
でも、そのプロジェクトのコーディングルールがそうなっているのであれば、従います。（仕事ですから。）
もし、仕様に残したくて、その上でそのIF文の処理が機能として独立しているのならば、メソッドアウトして、
Public Sub ほにゃ() If IsExists() Then Exit Sub End If ''処理記述
といった形にする事があります。
