TortoiseSVN 1.7.3 でコミット時にユーザディレクトリにアクセスできないエラー
年末に TortoiseSVN 1.7.1 から 1.7.3(2011/12/16公開) にアップデートしたら、「<ユーザーディレクトリ>へのアクセスが拒否されました」エラーが発生した。
いろいろ突っ込んである環境だからと思って再インストールしてみたが、その直後でも同様の症状が発生する。
そこで手持ちの 1.7.1 や 1.7.2 にしてみたところ、正常に動作した。どうやら、 1.7.3 特有の問題らしい。
現在は 1.7.2 を使用しているが、なぜか日本語か言語パックが当たらないorz
一度 1.7.3 をインストールしてからアンインストール後に 1.7.2 をインストールした状態だからかもしれない。
今更再インストールするのも面倒なので英語版で使い続けることにする。
大きな定数値を Int32 に変換する
状態などをビット値で表現するのは良くあるケースだと思うけど、このビット値を DB に登録するにはちょっと手間がかかるかもしれない。
int 型では負数に相当する定数値を int 型の変数に代入しようとするとコンパイルエラーが発生する。このエラーはキャストしても解決できない。
んじゃどうやって解決しようかなーと思って、BitConverter を使う方法を考えてみた。まず定数値のバイト表現を取得し、次に Int32 型として解釈するという寸法。
ところで CS0221 エラーを読んでみると、 unchecked キーワードについて言及されている。MSDN によると、
unchecked コンテキストでは、式がチェック先の型の範囲外にある値を生成した場合、結果の値は切り捨てられます。
てことだったので Int32.MaxValue になるかなーと思ったけど、んなこたーない、想定通りに変換してくれた。こっちの方が便利かな。
確認用コード(C#)
// int int_val = 0xFFFFFFFF; // CS0266 エラー
// int int_val = (int)0xFFFFFFFF; // CS0221 エラー
int int_val = BitConverter.ToInt32( BitConverter.GetBytes(
0xFFFFFFFF ), 0 );
int unchecked_int_val = unchecked( (int)0xFFFFFFFF );
Console.WriteLine( "unchecked_int_val: {0,10}, Bites:{0:X}",
unchecked_int_val );
Console.WriteLine( " int_val: {0,10}, Bites:{0:X}",
int_val );
実行結果
unchecked_int_val: -1, Bites:FFFFFFFF
int_val: -1, Bites:FFFFFFFFuint 型から int 型へはふつーにキャストできちゃうので、実運用上、あまり使う機会はないかもしれない。
Windows7 の ホームディレクトリ変更
わんくまの方に書こうとしたら、いつまで経っても「接続中」のまま先に進まないのでこっちに待避。
現在のメインマシンは、システムディスクを 2.5インチHDD 2台による RAID 0 で構成している。
こんないつ壊れるかわからない怖いところにデータを置いておくわけにいかない。
そこで、ホームディレクトリを物理的に別のディスクに移動することにした。
当初は C:\Users を丸ごと移動しようと思ったが、この操作は少々複雑である。(参考⇒ Windows 7でユーザプロファイルフォルダ(C:\Users)を別ドライブに移してみる)
しかしこのPCを使うのは私一人だけで、アカウントもメインアカウント一つしか作っておらず、この先ユーザーが増える見込みもないため、 C:\Users の配下にあるアカウントディレクトリを移動するだけで目的を十分に達する。
ということで、アカウントディレクトリを移動し、C:\Users\<アカウント名> からのシンボリックリンクを張ることにした。
ここでは <アカウント名> を "guicheng" として作業手順を以下に示す。
ただし若干の改変と記憶に任せている箇所があるため、正確ではないかもしれない。
※ 2012/01/03 追記
クリーンインストールしながら手順を修正。たぶん、正確だと思う。
1. 管理者アカウント Dummy を作成する。
2. PCを再起動してセーフモードで立ち上げ、Dummyでログオンする。
3. コマンドプロンプトを立ち上げ、"guicheng" のアカウントディレクトリを移動する。
robocopy C:\Users\guicheng D:\DATA /MOVE /COPYALL /E /R:0 /W:0
4. アカウントディレクトリを削除する。理想的にコトが進めば、この手順は不要のはず。
rmdir /S C:\Users\guicheng
5. D:\DATA へのシンボリックリンクを張る
mklink /D C:\Users\guicheng D:\DATA
6. PC を再起動して元のアカウント(guicheng)でログオンする。
7. 管理者アカウント Dummy を削除する。
二週間ほど運用してみたが、WZ Editor7上でダブルクリックによる単語選択をすると不正終了する不具合が発生したのみ。
この不具合は、WZ Editor7 の最新バージョン(7.0.9)を上書きインストールすることで解消した。
もとのWZ Editor7は旧環境からインストールフォルダごとコピーしてきたものなので、それが原因かもしれない。
2012/01/03 追記
手順3. のコマンドに /E を追加、/R、/W の数値を 0 に変更。
/E はサブディレクトリも含めたコピーを行うためのスイッチで、これをつけないと「ドキュメント」をはじめとする肝心のディレクトリが移動されない。これを忘れたまま手順4.でユーザーディレクトリを削除すると、Explore がぶっ壊れるというオチが待っている。
/R, /W はエラーが発生した場合のリトライ間隔と回数を指定するスイッチで、双方に0を指定しておくとエラーが起こってもリトライされない。手順3. の移動操作では、クリーンインストール直後でも結構な数のエラーが出る。これらは一切無視してかまわないが、鬱陶しいのでリトライを禁止すると良い。
なお、理想的にことが進めば 手順4.を行うまでもなくユーザーディレクトリが消えているはず。
robocopy のスイッチの意味は robocopy /? で参照することができるが、今回使用したスイッチだけ転載する。
コンプライアンスって、わざわざ喧伝するものかいな？
うちの会社の社長は「コンプライアンス」を声高に掲げているんですが、私はものすごい違和感を感じています。
前の会社に限らずIT業界の全体的な傾向として、法律を守るのは当たり前、その上のモラルを守っているかがポイントになっていると思います。
そのせいか、コンプライアンスを掲げているのをみると「なんでその程度のことを声高に喧伝するんだろう」と思ってしまうわけです。
もちろんIT業界にもブラックな会社は多々ありますし、違法行為スレスレでやっと赤字回避なんて話はなんぼでも聞きますけどね。
さて、ソフトウェアは知的財産権の固まりのようなものです。
ということは、ソフトウェアを開発する会社は自身の収益を守るためにもコンプライアンスの意識が芽生えやすい業界構造があるのではないかと思います。
また、私がテストとか品質保証といったものに興味があるからこのような違和感を感じるのかもしれませんね。
品質保証は製品の価値を高めることが目的の一つですから、法令よりもさらに厳しい自主基準を課すのが普通です。
とすれば、「法律は守って当然」という考え方が強くなるのも宜なるかな。
あとは、仕様とか規格といったものに普段から触れているからというのも考えられますね。
たとえばメールアドレス一つ取っても、俺様ルールでアドレスを決めてしまってはどんなメールサーバーやメールソフトも対応できません。
そこまで極端でなくとも、たとえばDoCoMoの携帯用メールアドレスの規格に切れたことのある開発者の方は多いのでは？
だったら各種RFCに従って、標準規格に沿った作りにすることが重要です。
いろいろと理由を考えてみましたが、コンプライアンスを掲げる会社の企業価値は、実はあまり高くないのではないかというのが私の考えです。
「はかり」って精密機器なんだよ？
TVなどで、リンゴの選果場の映像を見たことがあるでしょうか。
コンベアのラインにちょうどリンゴ一個分の皿が設置されており、リンゴがそれぞれの枠のところにくると皿がカシャンと倒れて選別されるというものです。
この手の選別機は重さで分類していまして、それぞれの枠に設定された重さ以上のリンゴが転がり落ちる仕組みになっています。
近年の選別機は枠の上流で一回だけ重さを量り、その値に応じて対応する枠のところで電気的に皿を倒すという構造になっています。
しかし数十年前に設置されたような古いタイプでは、選別枠のそれぞれに天秤はかりが設置されており、はかりに乗せられた分銅以上の重さのリンゴがくると天秤が動いて皿が倒れるという、機械式のものもあります。
先日、とある食品系のお客様から後者のような機械式選別機の点検をしてほしいという依頼がありまして、私が行ってくることになりました。
# 実際に見てきたのはリンゴの選別機じゃないよ
んで見てみたんですが。
まともにメンテナンスされていない古い機械ということもありまして、信頼性を担保できない状態だということが触ってすぐにわかりました。
一つのはかりに分銅を設定し、同じ重さのダミーウェイトをいくつかの皿に置いてみたら倒れるもの倒れないものが出てきたり。
ならばと思って一つの皿に対して倒れる閾値を取ってみたら、閾値がばらついていたり。
それでも確率論的に閾値を求めてみたら、数時間後には閾値が変わっていたり。
いやー、天秤も皿も信用できやしねぇorz
いかに無体な使われ方をしていたのかがよくわかりました。
さて何人かの方と話をしてみて驚いたんですが、「はかり」が立派な精密機器であることはほとんど認知されていないようです。
確かにはかりの構造は単純で、部品点数も非常に少ないです。
しかし、そのそれぞれが高い精度で作られ、緻密に組み合わさっています。
そして要素の一つでも破損すれば、はかりの信頼性は格段に落ちてしまいます。
たとえば天秤ばかりの場合、支点にちょいと傷を入れるだけで精度がガタ落ちになります。
というか、再起不能ですね。
小学校の理科で、上皿天秤を片付ける際には皿を片方にまとめるように教わったと思いますが、これは支点をすり減らさないためです。
はかりは公正な商業活動をする上で最も重要な機器の一つです。
それ故に、その精度を保証する「計量士」になるには国家資格に合格しなければなりません。
年間200人程度しか合格者がいないと聞きますから、非常に貴重な資格かもしれませんね。
以下余談。
私は計量に関する専門的な勉強をしたことがありませんが、先述の機械に対しては意外にもアプリケーションテスト技法が役に立ちました。
真値がわからないものに対して値の範囲を狭めていくあたりは、レガシープログラムに仕様化テストを適用している気分でしたね。
はかりも皿も信用できないことがわかってからは、メモリリーク箇所の探索の様相を呈していましたが。
建築業界の業務は恐ろしく細分化されている
建築業界ってのは業務がえらい細分化されてまして、そのそれぞれに職人さんがいます。
たとえば保冷倉庫(倉庫本体と空調機だけの簡単な構造)を造る場合、内装だけに限っても大工、コンクリ屋(室内機を据え付ける基礎を作る)、軽天屋(軽量鉄骨で天井を貼る)、吹き付け屋(天井や壁に断熱材のウレタンを吹き付ける)、板金屋(室内機の保護フェンスを作るなど)などに声をかけることになります。
構造や外装も含めたら、そりゃもう、かなりの数の職人さんが出入りすることになるわけです。
そうそう、大工と型枠大工(コンクリートの型枠を作る)とは別の職種だと聞かされたときは驚きましたね。
んでそれぞれの職種ごとに担当範囲がきっちりと決められていまして、自らの判断でそれを逸脱することは絶対にありません。
それこそゴミ処理一つとっても、他の職人さんが出したゴミには一切手を触れないんです。
フォークリフトを動かすにもわざわざゴミを避けて走りますから、実に徹底しています。
まぁ工事監督さんからの指示があれば業務外のこと、たとえば電気屋さんがウレタンの補修をするようなこともやってくれますが。
これをプログラム業界に当てはめると、たとえばデータグリッドビューの職人さんはビジネスロジックはおろか、フォームにボタンを配置することすらしないくらいの勢いです。
ンなコトされたら、プログラム業界では仕事になるわけがありません。
ただし徹底的に業務が細分化されている建築業界でも宮大工だけは特殊な存在で、丸太を製材し、建築、内装に至るまでの全てを一手に引き受けます。
現在のプログラマーは、宮大工に近い存在かもしれませんね。
ところが建築業界の業務細分化も、プログラム業界が参考にすべき点があります。
たとえば吹き付け屋のウレタン調合は、電気屋の配線に影響しません。
これはそれぞれのインターフェースが確立されており、クラス間での相互作用が徹底的に排除されていると見なすことができるのではないでしょうか。
最初は宮大工しかいなかった建築業界が1000年の時を経て現在の形に進化したとすると、プログラム業界の目指す道はコンポーネントをポトペタで組み合わせるラピッドプログラミングでしょうか。
まぁ、これがおもしろいかと問われると微妙ですけどね。
私はできることなら「宮大工」のままでいたいところですが、いずれ現れる「ぽとぺた職人」は「宮大工」の想像外のスキルを極めているのかもしれません。
ヘルメット
工事現場ではヘルメットの着用が義務づけられます。
素人目にはどうやったら頭をぶつけるんだよと言う場所は多々あるんですが、それでも不測の事態って起こるんですよ。
たとえば目の前に垂れ下がっているパイプにぶつけたり、ちょっぴり張り出したパレットの角にぶつけたり。
高所作業車の近くでは上からモノが降ってくる可能性がありますし、地面を掘っていれば壁に頭を打ち付けることだってあるわけです。
職人さんのヘルメットを見てみると、表面がそりゃもうガサガサです。
手荒に扱っているせいもあるでしょうが、実際にぶつけた回数も数多いんじゃないかと。
まだ数回しか現場に出ていない私ですら、ヘルメットがなかったら出血騒ぎを起こしただろうなというケースが何度かありました。
# 前述のパイプやパレットの件なんかは、もろに私の経験orz
さすがにヘルメットは誰でも着用してくれてるんですが、安全帯なんかはなかなか使ってくれないのが困りものです。
特に経験のある職人さんだと落ちるわけがないと思っているんでしょうが、いつ起こるかわからないから不測の事態なんですよね……
大手のゼネコンだと、安全帯は二本着用する義務があるそうです。
例え一本切れても、もう一本で支えることができるからだとか。
ディズニーランドの天井灯は基部での据え付けの他に安全ワイヤーまで張ってあるという話を思い出しました。
参考：「ディズニーランドが苦手な俺が行ってきた」の48
さて、ふと思ったこと。
プログラマーがその気になれば、かなりの危険予知ができるんじゃないかな、と。
プログラマーとかSEと呼ばれる人は物事を細分化して検討するのが仕事ですから、かなりの想定能力を持っています。
私の経験ですが、工場での工事では、ほぼチラ見でも職人さんたちの動線を見抜くことができました。
あとは動線近辺に転がっているモノを片付けたり、トラップになりそうなモノを始末したりすれば、安全性は非常に高まるでしょう。
世の中には様々な安全用品があります。
これらのポテンシャルを完全に引き出すことができるのは、意外とSEと呼ばれる人かもしれません。
