聞くのもやるのも。
月別: 2008年11月
iPhoneにコーティングしてみた。
Micro Solution のCRYSTAL COAT #01という製品を購入してiPhoneにガラスコーティングしてみた。
性懲りもなく、３枚目くらいのアンチグレアシートもはがして表面にも。
動機は、背面にいつのまにか亀裂が入っていたから。
落としたわけでもないのに亀裂が少しだけ入っていてびっくり。
もう、何度もアップルストアに行くのもあれだし、特に支障のないレベルなので、とりあえず様子を見ようかと思ってガラスコーティングしてみようと思い立った。
もう細かい傷が結構あるので、あまり綺麗にはならなかったが結構ツヤが出てきた気がする。
液晶表面も、結構綺麗に見える。指紋はつくけど、簡単に落ちるようになった（気がする。今までアンチグレアシートだったので無縁だった。）。
亀裂がちゃんと保護されたかどうかは疑問。
明日の２１時に４８時間経つので二度目のコーティングをしてとりあえず様子見。
それはそうと、iPhone OS2.2になってから、safariがほとんど、落ちなくなった。
特にmixiなんか見ると結構な頻度で落ちていたのに今のところ一回も落ちてない。
後は、スクロール中に少しカクカクする動作も無くなってスムーズになった。
絵文字も（使わないけど）追加されて、ストリートビューも追加された。
でも、やっぱりsafariの進化が一番嬉しい。
それにしても、今まで携帯やPDAを何回も買ってきたけど、４ヶ月経っても延々触り続けているのはiPhoneぐらいである。
iPhone OS 2.2アップデートきましたね
アップルは11月21日、iPhone OS 2.2をリリースした。事前の噂どおりに絵文字機能をサポートしたほか、マップ機能を強化。Googleストリートビューにも対応した。
絵文字やGoogleストリートビューにも対応「iPhone OS 2.2」をリリース:ニュース – CNET Japan
毎度のことながら、噂どおり。
safariの安定性が向上しているようなので家に帰ったら早速アップデートしないと。
出鼻を挫かれるとテンションが異常に下がる
OSXの置換コピーで泣いた
OSXで複数フォルダのコピーを行いたくて、それぞれのルートをコピペしてコピーを開始したんだけど、途中でコピーを中止したら
コピー先のフォルダが全部無くなった上で、今回途中までコピーされた分だけになっていた。
つまり、コピー元からコピー先にコピーしたファイル以外は全て消えて無くなった。
コピー元には残っているし、コピー先にしかないファイルも数個しかなかったので、たぶん、事なきを得ると思うんだけど、復旧中なので予断は許さない。余談が許されないのは、悲壮感の漂う会議中か。そして、これが余談というやつか。
まあ、時間的にもうすぐおやつの時間だし、結構しゃれにならないなぁ。
是非、置換するときも、元々あったファイルは消さないでいただけたらと思うのは、僕だけではないはず。
ちょっと、夜風に当たって頭を冷やしてこようかと思ったけど、それで風邪でも引いたりなんかしたら、それこそ予断を許さない状況になるので自粛。
まぁ、なんとかなるでしょう。明日のiPhoneの中にある曲は当社比０．１倍ですが・・・
Visual Studio 2003でVisual SourceSafe 6.0dとの統合がされていない時や統合されなくなった時の解決策
Visual Studio 2003でVisual SourceSafe 6.0dとの統合がされていない時や統合されなくなった時の解決策を説明します。
Visual SourceSafe 6.0dのexeのあるフォルダ（スタートメニューのVSSのプロパティを見ればわかる）に
SSINT.EXE
というファイルがありますので、それを実行します。
統合セットアップが起動しますので、そのままOKボタンを押下し,
Installed was successfull.
というメッセージが出たら成功です。
参考
xcodeには最初から構成管理をするための機能がついていた
スタバのタンブラの注意書きが日本語と英語で少し違う
xcodeプロジェクトの構成管理ってどうやってるんだろ
フレームワークを理解するために最も重要なたった一つのこと
私自身、社内のシステム開発用フレームワークを一人で設計・開発していて、ちょっと前までは、自分の参画するプロジェクトでのみ採用していた。
最近、私が参画しないプロジェクトでも採用するようになり、いろいろとサポートをする必要が出てきたのだが、その過程でフレームワークを理解するために最も重要な事というのが何なのかが分かったような気がする。
それは、
「フレームワークの機能に何があるかを知る」
事ではない。
勿論、フレームワークの機能を知る事で、ある程度フレームワークの能力を発揮する事が出来るかもしれない。
しかし、フレームワークの設計者が知っているであろう最適な使い方にはならないだろう。
だから、「まず最初にフレームワークの詳細な機能について知ろう」と思う必要は無い。
もっと大切な事を理解してからでも遅くない。
むしろ、その方が個々の機能について最適な使い方とセットで理解できるので有益だ。
では、何が最も重要なのかというと、
「フレームワーク自身が持っている思想を知る」
という事である。
どんな意図でフレームワークが存在しているのか。
どんな意図でフレームワークの設計がこのようになっているのか。
どんな開発手法を想定して作られたフレームワークなのか。
それを理解する事が最も重要な事であるように思う。
これが理解できれば、各機能の最適な使い方は自ずと知る事ができるはずである。
だから、フレームワークのセットだけポンと渡されても困るし、リファレンスだけ渡されてもなかなか最適解にたどり着けない。
むしろ、フレームワークとしては中途半端である。
ちゃんと、フレームワークを作った理由や設計思想、最適な開発手法まで一緒に渡してあげる必要がある。そこまで渡して初めてフレームワークとして機能するのではないだろうか。
なんて事を昔から思っていたのだが、より一層強く思うようになった。
下手なメタファは有害だが、それを覚悟で喩えるなら、
「言語が分かっても、その背景にある文化が分からないと、なかなかうまくコミュニケーションが取れない」
という事。