MacのGitは1.8.5からcore.precomposeunicode = trueがデフォルト

MacでGitを使うに当たって

git 1.7.12でUTF8-MAC問題が解決 | Butaman-kun Project

ちなみに、このバージョンでgit cloneやgit initすると、リポジトリの設定として「core.precomposeunicode」が明示的にfalseとなっているため、global設定を変えても反映されない。

上記の記事が書かれてから1年半経っているし、そろそろ最初からtrueになっていても良いのではないかと、git version 1.8.5.2 (Apple Git-48)でgit initしてみたら、なってた。

リリースノートを眺める限りでは、git 1.8.5からそうなっているらしい。

https://raw.github.com/git/git/master/Documentation/RelNotes/1.8.5.txt

• On MacOS X, we detected if the filesystem needs the "pre-composed unicode strings" workaround, but did not automatically enable it. Now we do.

確認のため、Homebrewでgit 1.8.4.3とgit 1.8.5を入れ、git init直後の.git/configを見比べてみる。

git 1.8.4.3

[core]
  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true
  ignorecase = true
  precomposeunicode = false

git 1.8.5

[core]
  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true
  ignorecase = true
  precomposeunicode = true

『伝え方が9割』を要求分析の観点で考える

『伝え方が9割』
http://www.amazon.co.jp/伝え方が9割-佐々木-圭一/dp/4478017212

大勢の人が関わるプロジェクトでは、いかに正確に「要求を伝達する」ことができるかが非常に重要な要素である。
この本は、そのような「正確な伝達を行う技術」を教えるものではなく、基本的には「要求を受け入れてもらう技術」を教えるものである。 しかし『第２章　「ノー」を「イエス」に変える技術』は「正確な伝達」にも通じる技術であり、とりわけAmazonの内容説明でも紹介されている以下の例については、「要求分析」の観点で考えてみるとなかなか面白い。

「デートしてください」

こう言ってみました。あなたのピュアな気持ちそのままですね。
これだと断られる確率が高いですよね。
ですが、コトバ次第で結果を変えることかができます。

「驚くほど旨いパスタの店が
あるのだけど、行かない?」

こう言ってみました。相手は行っていいかも、と思う確率がぐんと上がるコトバです。

「デートする」というのは、なんらかの要求を実現するための「ソリューション」である。ソリューションがなんの目的もなく発生するわけはなく、そこには必ず「ステークホルダ要求」、デートであれば「一緒に居たい、話したい」などといった要求が存在するはずである。「デートしてください」と言うのは、要求分析で言うところの「ソリューション要求」だけを提示しているのと同じ状態である。親しい相手であれば「ソリューション要求」からステークホルダ要求も想起（トレース）してくれるだろうが、親しくない相手ではそうもいかないだろう。
通常、要求アナリストは「ソリューション要求」だけをもって要求の実現には移らない。要求の引き出しが十分に行われず、要求トレーサビリティが不十分なプロジェクトは、往々にして有名な「顧客が本当に必要だったもの」の図のような結果を引き起こすからだ。そのような結果を避けるために、「デートしてください」という「互いにとっての利害がまったく見えない（見せていない）」誘いを断るのは至極合理的な判断と言える。

「旨いパスタを食べに行こう」というのは、これ自体「ソリューション要求」と「ステークホルダ要求」の両方の要素を持つ。この要求によって実現されなければならない成果は「旨いと思われるパスタを一緒に食べに行った」であり、それ以外の成果はこの要求からは求められていない。これくらい成果が分かりやすければ、誘いも受けやすいのではないだろうか。

要求を出す際に注意することは、なにはともあれ「利害を明確にすること」である。たとえ「相手にとっての利益がない」と感じる場合であっても、少なくとも「自分にとっての利益を伝える」ことは、「一切の利害を伝えない」場合に比べてその要求を受け入れてもらえる可能性を高めるだろう。無論、その内容如何では反感を抱かれる可能性もある。それを避ける必要がある場合、それこそこの本が教える「要求を受け入れてもらう技術」が役に立つところだろう。

ところで、著者は「自分の頭の中（お願いや願望など）をそのままコトバにしない」ことを勧めているが、そのままコトバにした例が「デートしてください」というのは興味深い。「デートしてください」というのは既に言ったとおり「ソリューション要求」であり、お願いや願望そのものではなく、お願いや願望を実現する手段である。つまり人はお願いや願望そのものをコトバにしているつもりでも、実際には頭の中で自然に要求分析を進め、お願いや願望を実現できそうなソリューションの方をコトバにしてしまうのである。

仕様に不適合のNULLをチェックするというフールプルーフ

以下のC++関数はコメントが関数仕様の一部であるとした場合。

/**
 * @param[in] foo なにかのオブジェクトのポインタ。NULL不可
 * @note fooが無効オブジェクトを指している（!*fooが真である)ならば何もしない
 */
void Hoge(Foo* foo)
{
    if (! foo)
    {
         return;
    }
    if (! *foo)
    {
         return;
    }

関数仕様としてNULL不可と書いている以上、NULLを引数として関数を呼び出した方に全面的に責任がある。とはいえ人間には間違いもあるからと「NULLを渡された場合は念のため何もしないであげる」ことを可とするか否か。

/**
 * @param[in] foo なにかのオブジェクトの参照
 * @note fooが無効オブジェクト（!fooが真である)ならば何もしない
 */
void Hoge(Foo& foo)
{
    if (! &foo)
    {
        return;
    }
    if (! foo)
    {
         return;
    }

「適格に定義されたプログラムには、空の参照は、ありえない（JIS X 3014:2003 §8.3.2/4）」ので、言語規格上は空の参照を引数として関数を呼び出した方全面的に責任がある。とはいえ適格にプログラムを定義できる人ばかりではないからと「空の参照を渡された場合でも検査可能な（実際に逆参照されるまで不正な参照とならないような）処理系があるなら識別して何もしないであげる」ことを可とするか否か。

これはおそらく「コーディングルール次第」となる。

1. 「関数仕様を守らない」と「言語規格（言語仕様）を守らない」はどちらも等しく「仕様を守らない方が悪い」ので、どちらのNULLチェックも不可と判断する
2. ポインタ渡しの方は少なくとも言語規格には適合しているので可と判断し、参照渡しの方はそもそも空の参照という状態が言語規格で未定義なので不可と判断する
3. ターゲットの環境では空の参照であっても逆参照されるまでは違反にならないから、参照渡しの方のNULLチェックも可と判断する

開発者の能力や、成果物に求められる品質次第で、どのルールも選ばれ得る。もっとも、3番を選ぶくらいなら「参照の使用を禁止」した方がスマートだと思うが。

svn:eol-style=CRLFは改行コードをCRLFに変換してチェックインする

http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style

native

This causes the file to contain the EOL markers that are native to the operating system on which Subversion was run. In other words, if a user on a Windows machine checks out a working copy that contains a file with an svn:eol-style property set to native, that file will contain CRLF EOL markers. A Unix user checking out a working copy that contains the same file will see LF EOL markers in his copy of the file.

Note that Subversion will actually store the file in the repository using normalized LF EOL markers regardless of the operating system. This is basically transparent to the user, though.

CRLF

This causes the file to contain CRLF sequences for EOL markers, regardless of the operating system in use.

LF

This causes the file to contain LF characters for EOL markers, regardless of the operating system in use.

svn:eol-style=nativeが「LFに正規化してリポジトリに格納する」と明言しているのに対し、svn:eol-style=CRLFは「改行コードとしてCRLFが使われるようにする」。実際にどのように実現するかは明示されていないが、挙動を見る限りでは「CRLFに変換してリポジトリに格納している」ようである。

たとえば、改行コードCRLFのテキストファイル3つそれぞれにsvn:eol-style=「native」「LF」「CRLF」を設定し、TortoiseSVN 1.7.11でリポジトリに追加する。それをTortoiseSVNや、TortoiseGit 1.8.2.0 git version 1.7.11.msysgit.1でチェックアウトしたところ、改行コードは以下のようになっていた。

svn:eol-style	TSVNでチェックアウト	TGitでチェックアウト
		core.autocrlf=false	core.autocrlf=true
native	CRLF	LF	CRLF
LF	LF	LF	CRLF
CRLF	CRLF	CRLF	CRLF

TGitの方は、git-svnがsvn:eol-styleを解釈しないため、改行コードはGitの設定のみに従って展開されている。

これだけ見ると、SVNとGitの併用で一番安定感のある改行コードはCRLFのように見える。しかしGitには「CRLFでチェックインさせることを強制する属性がない」ため、Git側では個人の設定次第で「リポジトリにはLFで格納することができる」ことになる。

.gitattributesのeol=crlfは改行コードをCRLFに変換してチェックインするものではない

https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html

eol

This attribute sets a specific line-ending style to be used in the working directory. It enables end-of-line normalization without any content checks, effectively setting the text attribute.

Set to string value "crlf"

This setting forces git to normalize line endings for this file on checkin and convert them to CRLF when the file is checked out.

Set to string value "lf"

This setting forces git to normalize line endings to LF on checkin and prevents conversion to CRLF when the file is checked out.

eol=lfが「改行コードをLFに正規化してチェックインする」と明言しているのに対し、eol=crlfは「改行コードを正規化してチェックインする」としか言っていない。あくまでも「チェックアウト時にCRLFに変換する」機能なので、リポジトリにCRLFで格納することを強制する用途で使うことはできない。

以下はTortoiseGit 1.8.2.0(git version 1.7.11.msysgit.1)における動作確認記録。

「.gitattributes」が存在せず、「core.autocrlf=false」が設定されているリポジトリでは、テキストファイルは以下のように扱われる。

• 改行コード LF のファイルを追加すると、リポジトリには改行コード LF のままコミットされる
• 改行コード CRLF のファイルを追加すると、リポジトリには改行コード CRLF のままコミットされる
• 改行コード LF のファイルをチェックアウトすると、作業ツリーには改行コード LF のままチェックアウトされる
• 改行コード CRLF のファイルをチェックアウトすると、作業ツリーには改行コード CRLF のままチェックアウトされる

「.gitattributes」が存在せず、「core.autocrlf=true」が設定されているリポジトリでは、テキストファイルは以下のように扱われる。

• 改行コード LF のファイルを追加すると、リポジトリには改行コード LF のままコミットされる
• 改行コード CRLF のファイルを追加すると、リポジトリには改行コード LF でコミットされる
• 改行コード LF のファイルをチェックアウトすると、作業ツリーには改行コード CRLF でチェックアウトされる
• 改行コード CRLF のファイルをチェックアウトすると、作業ツリーには改行コード CRLF のままチェックアウトされる
• 改行コード CRLF のファイルをチェックアウトして行を追加してコミットすると、リポジトリには追加した行も含めて改行コード CRLF のままコミットされる

「.gitattributes」で「eol=crlf」指定されているファイルは、「core.autocrlf」の設定によらず、以下のように扱われる。

• 改行コード LF のファイルを追加すると、リポジトリには改行コード LF のままコミットされる
• 改行コード CRLF のファイルを追加すると、リポジトリには改行コード LF でコミットされる
• 改行コード LF のファイルをチェックアウトすると、作業ツリーには改行コード CRLF でチェックアウトされる
• 改行コード CRLF のファイルをチェックアウトすると、作業ツリーには改行コード CRLF のままチェックアウトされる
• 改行コード CRLF のファイルをチェックアウトして行を追加してコミットすると、リポジトリには全行改行コード LF でコミットされる

Windows上でチェックアウトする開発者が複数存在する場合、core.autocrlfをtrueにする人とfalseにする人が混在すると、リポジトリに格納されるファイルの改行コードも混在することになる。 できるだけ「.gitattributes」で「text=auto」「eol=crlf」を指定して正規化を強制するか、「-text」を指定して正規化させないことを強制しておいた方が、いろいろすっきりする。

SkyrimとENBと星空と

PCの構成を変更してスペックに余裕ができたため、SkyrimをENB有りでプレイするようにし始めた。基本的な画作りについては、どのENBを選んでもそれぞれの個性として受け入れられるのだが、Enhanced Night Skyrimを入れた星空だけは、どうもENBなしの方が良く見える。

実際、ENBによって星空がどのように変わるのか、以下のModを入れた状態で撮り比べてみた。撮影にはSteamのスクリーンショット機能を使っている。

• Project Reality - Climates Of Tamriel - Final Edition 2.1
• Enhanced Night Skyrim - Enhanced Night Skyrim v04 Color Galaxy
• Enhanced Night Skyrim - Enhanced Night Skyrim v04 High Stars

ENBなし

Project ENB v1_8 for Climates Of Tamriel

RealVision ENB V1_3h

RealVision ENB V1_3h + Realistic Lighting Overhaul 4_0_7c

VandB_enb_COT_170/Ultra

The Wilds ENB 3.0 LIGHT INTERIORS/Climates of Tamriel

Skyrim Enhanced Shaders FX 2-0 Preview 4

Skyrim Enhanced Shaders FX 1-0 pure

SkyRealism - ENB Evolved 2-3 Vannila

SkyRealism - ENB Evolved 2-21 Vannila

Phinix Natural ENB 1-45

傾向として、EdgeAAがtrueになっているENBは星がぼやけて見える。これはEdgeAAの特性なのか、私の設定の問題なのか。

「バックアップと復元」のコントロールパネルに何も表示されない

なにかエラーが出るわけでもなく、マウスポインタが砂時計になるわけでもなく、ただ真っ白なウィンドウが出るだけ。いつからこのような状態になっているのかは不明である。一番“らしい”のは「Samsung Data Migrationを使って古いSSDから現在使用しているSSDにシステムを移行したとき」だが、ほかにもいろいろな作業をしているため確証はない。

なんにしろバックアップ機能を使えないのは困るので解決を試みる。

Windows7 バックアップ設定ができません（クリックできない） - マイクロソフト コミュニティ

また、コマンド プロンプトを管理者として起動し、以下のコマンドで実行ができるか確認してみてください。
・「sdclt.exe /kickoffjob」→ 今すぐバックアップ
・「sdclt.exe /configure」→ 設定の変更

sdclt.exe /configure

を実行すると次のようなダイアログが表示される。

---------------------------
Windows バックアップ
---------------------------
内部エラーのため、バックアップ アプリケーションを開始できませんでした:



指定されたサービスは無効であるか、または有効なデバイスが関連付けられていないため、開始できません。 (0x80070422)。
---------------------------
OK   
---------------------------

バックアップがエラーコード(0x80070422)により設定の変更ができない。 - マイクロソフト コミュニティ

１）「スタート」-「コントロールパネル」-「システムとセキュリティー」-「管理ツール」-「サービス」を開く
２）以下のそれぞれのサービスの設定状態を確認
　　　　Remote Procedure Call (RPCSS) - "自動"
　　　　COM+ Event System (eventsystem) - "手動" (私の手元のマシンでは"自動"と設定されていました)
　　　　System Event Notification Service (sens) - "自動"
　　　　Volume Shadow Copy (VSS) - "手動"
　　　　Microsoft Software Shadow Copy Provider (SWPRV) - "手動"
　　　　Windows Backup ? “手動”

私の環境ではWindows Backupが“無効”になっており、これを“手動”に切り替えることで、無事バックアップと復元を行えるようになった。