Visual Source Safeについてチェックしておきたい５つのTips

こんなTB（）を戴いていたので。

別に VSS をディスル post じゃないです。お間違いなく。

……ということでVSSを使う場合にチェックしておきたい５つのTipsです。

１．なんとしてもVSSを使わないようにしよう

VSSは有料ですし、無料でさらに高性能なSubversionやGitがあるのでそちらを使いましょう。
できるだけVSSを避ける、というのが鉄則です。

２．VSSを使っているふりをしてSubversion/Gitで管理しよう

VSSをいれるように言われたらVSSで管理するふりをしてSubversion/Gitで管理して、
作業ツリーを適当にVSSにいれて誤魔化しましょう。
あたかもVSSで管理されているかのように見せかけることが大事です。

３．VSSを強要されたらAdmin権限を得よう

VSSにはAdmin権限を得ることでいくつかの設定を変えることができます。
（Visual Source Safe アドミニストレーターというソフトがあり、そこでいろいろ設定できる）
ここで、必ず「多重チェックアウト」をONにしましょう。
これでテキストファイルがロックされなくなります。
少しだけ糞みたいなロックモードが楽になります。
また、Admin権限があればロックされたファイルを強制的に解除することもできます。

４．VSSを強要されAdmin権限を得られなかった場合、ローカルではSubversion/Gitで管理しよう

面倒くさいかもしれないですが、VSSに任せておくとよくぶっ壊れるのでローカルで多重に管理しておくと便利です。
履歴を見るのにも良いです。

５．VSSを強要しAdmin権限を渡さない上にSubversion/Gitを理解してくれない会社を辞めよう

こういうケースでは、

VSS 派は Subversion 使ってないけれどね。なんか、ドキュメントのURL渡したら、読むの嫌らしい。ドキュメント書き下ろしてくれないと嫌らしい。

みたいなことが横行しています。
割と真面目にこういう事を言う人はいて、
阿呆の相手をするのは時間の無駄なので会社を辞めましょう。

結論が、バイナリの扱い（＝ロック型の利点）に集約しているような気がしないでもないですが。

まあ、なんか VSS の利点は
エクセルがコンフリクトしない
これしか聞こえてこないけれど、きっと素晴らしいシステムなんだよ！！
2005年移行リリースないけれど、きっと素晴らしいシステムなんだよ！！
いつの間にか、VSSじゃなくて、Team Foundation が出来てるけれど、きっと素晴らしいシステムなんだよ！！
Team Foundation があるからもう 2005 移行は絶対でないと思うけれど、きっと素晴らしいシステムなんだよ！！

一応、Subversionはロックがあるのでちゃんと運用すればエクセルはコンフリクトしません。
Gitは普通にコンフリクトしますが、別途Excelのマージ手段を用意すればコンフリクト解決できます。
マージ手段がなくても、声がけすれば回避できます。

不便ではありますが、そもそもExcelファイルがコンフリクトすることを回避するのが重要ならば、
別途バージョン管理するという手もあります。

とにかく、VSSはテキストを履歴管理するのには向いていません。

Emacsの凄いところを３つ挙げて見る

とりあえず、30歳まではEmacsを使った事がなかったよ、
という俺ですが最近はすっかりEmacsです。

いままで使ってきたエディタは、
WindowsではPeggy ProとEmEditor、OSXならTextMateでした。

じゃ、なんでEmacsにしたかというと、
偏に、
「WindowsでもOSXでも同じエディタを使いたいじゃん？」
ってことでした。

この辺は、Emacsはじめました - 神様なんて信じない僕らのためにでも書いたのですが、

あとは、ぶっちゃけ「Emacsくらい使えないとかっこうわるいなあ」ということ。

ほら、周囲がviとかemacsとか使っていると肩身の狭い思いをするわけです。
viいいよー、emacsいいよー、という話を聞くに、使わないとダメじゃない？
って感じになったわけで。

そんなにいいなら使ってみよう、って思いました。
まぁ、これが真の動機かも。

で、いまや手放せなくなった3つのelを紹介します。
っていうか、まずるびきちさんのEmacsテクニックバイブルを読むべき、ですが、とりあえず紹介。
あと、別途この本を読んでauto-installはいれておくべきです。
拡張をいれるのが本当に楽になるので。
少なくともEmacsを使いこなせてない感じがある人はみんなこの本を読むべき。

Emacsテクニックバイブル　?作業効率をカイゼンする200の技?

では、紹介を！

１．AutoComplete

言わずと知れた補完。
IDEとかでもよく使われますが、この補完はバッファ内から候補を探してくれるため、
ソースを書けば書くほど楽になります。
IDEとか使ってる場合じゃない！

(require 'auto-complete-config)
(global-auto-complete-mode 1)

EmacsWiki: Auto Completetitle

２．Migemo

ローマ字のまま、日本語をインクリメンタルサーチ。
なんていうかいちいち日本語入力に切り替えなくても検索できて快適！
気持ちよくコードを書いているときに日本語に切り替えてわちゃくちゃになるって嫌だしな！

(require 'migemo)

Migemo: ローマ字のまま日本語をインクリメンタル検索

３．Anything

なんじゃこりゃー、というかまだまともに使いこなせないですが、
上記の「Emacsテクニックバイブル」にまるまる章を使って解説されるほどの代物。
一言でいえば、複数の機能を1つにまとめてくれるのですが、
例えば、
M-x anything RET models.py
などといれると、
開いているBuffersの中と、Recentf（recentf-ext.el）中から、
開くべき機能の候補を複合的に補完して選び出してくれる。

簡単に言うと、入力した文字列に対応した動作やファイルなどを一覧に表示する、
という機能なので、何から何までanythingでいけちゃうぜ？
みたいな感じです。

(require 'anything-startup)

EmacsWiki: Anything

ということで、Emacsのすごいところ3つの紹介でした。
30からでも始められるEmacs、はじめてみませんか！

上記の本は、基礎は抑えてくれないので基礎はこちらでどうぞ。

入門 GNU Emacs 第3版

「最短経路の本 レナのふしぎな数学の旅」を読みました

きしださんの日記で紹介されていたので、つい買ってみました。
2010-06-18 - きしだのはてな
きむら(K)さんに

「今まで読んでなかったんかい」

Twitter / finalfusion: @isoparametric 「今ま��

と突っ込まれるくらい必読本でした。がはっ。

ということで、感想。
要するにグラフ理論の初歩を学ぶための本なのですが、
一般のプログラマ／エンジニアからしたらグラフ理論って、何か意味あるの？
って感じかもしれないです。

でも、
「最短経路を見つける」というアルゴリズムを書くことは結構あるんじゃないでしょうか？

最短経路を求める方法として、ダイクストラ法なんかが有名ですが、
ゲームなんかだとA*(AStar)アルゴリズムがよく使われます。

でも、これはアルゴリズムだけ知っていれば使えたりするので
実際に最短経路を求めるためにどのようなことをしているか？
というのは意外と知られていないのかなーとか。

あと俺は、プログラムを憶えたてのときは再帰で、経路探索を書いて、スタックオーバーフローしたりしてました。

……で、この本はその適切なアルゴリズムを提示するだけではなく、
「なぜ」というところを明らかにしており、
そもそもダイクストラ法がどういったアイディアから最短経路を求めているのか、
ということをきちんと段階を経て解説しています。

最短経路についてここまでしっかり書かれた本って他にないんじゃないかなー。
アルゴリズムって知っていて使えるだけじゃなくて、
理解するとさらに楽しいので
なんとうか、普通にお勧めです。

最短経路の本

面白かったので怖い話の反応に反応してみる

id:Dr_Caligariさんから面白い反応があったので、
俺も思ったことに対してつらつら反応してみます。
普通にコメントしようと思ったのですが長くなったのでTB返しで。

私が書くのはゲーム業界のプログラマーという狭い世界で生きている人間が思った事

ということで、俺もゲーム業界の片隅で生きていた事はあるのでその観点で反応してみます。

ディレクトリ構成が機能単位でなくプログラマの名前幽霊

これ実際に見たことあります。

アセンブラを使っていて、プロジェクトの規模が小さかった時代の名残らしいです。

恐らく俺が見たプロジェクトもアセンブリの頃の名残でした。
プロジェクト管理とかソース管理という構成管理の概念がなかったころなら、
別に良いとは思うのですが、今でもこれを引き継いでいてこれを「本気で」良いと思っている人がいることが恐ろしくもあります。

バージョン管理システムを使わない幽霊

そろそろ分散バージョン管理も試してみたいのですが、昔と違ってプロジェクトの規模が大きくなっているので、動きが鈍くなってしまったので、難しいですね。

今俺はgitで超便利ですが、頻繁にバイナリファイルをコミットすることが多いゲーム関連だとリソースをロックしたい、
という話もありますし、難しいかもしれませんね。
ゲーム業界だとPerforceやAlienbrainも検討の余地があると思います。

コミットは朝しろ　帰る前にするなと言う幽霊

コミットの谷間でたまたま通らないコードをコミットしたらしょうがないけど、どう見ても通らないソースをコミットして帰られたら、ムカつかないっすか？

いや、いるんですよ、マジで。

普通にマジで居るのは知っているので、寧ろそのためのHudsonです。
ビルド通らなければメールで通知が来ますし、
Hudsonをいれていてビルド通らないソースコードをコミットしたまま帰られた事は殆どありませんです。

不定アドレス塗りつぶしとか判りづらいバグ仕込まれたときに、本人居ないのはキツイ

のは確かですが、それがそのタイミングで仕込まれたバグならdiffみれば普通にわかりますし、
潜在的バグならとっておければ後々楽なので、俺はあまり気にしません。
勿論、イラッとしないことはないでしょうが、他人のバグもとれないプログラマはどうかとも思いますし。
（結構自分のソースしか読まない、他人のバグはとれない、という人もいますが）

手動でビルドテストしなければならない幽霊

ちなみにCEDEC2010の「タダで始めるゲーム開発自動化のススメ」というセッションで、Hudsonが紹介されます。

これからのゲーム開発には欠かせなくなりそうです。

残念ながら諸事情でCEDECはいってないのですが、去年もテスト系のセッションでHudsonは紹介されていたと思います。
自動ビルドは必須になりますが、ゲーム業界は感覚とか見た目のところもあるのでなかなか難しいですね。
GDCのセッションでも苦労している感がありますし。

オレオレコンテナしか信じない幽霊

これは難しいですね。

うちのプロジェクトはコンテナライブラリ自作してますし、EAもEA-STLというSTLに似たインターフェイスをライブラリ自作してますね。

ちゃんとインターフェイスとか規格を決めて、全社で使うとかプロジェクト共通で使うというのなら良いと思います。
EA-STLみたいにゲームに考慮した感じにつくってあるとか。
EA-STLとか普通にしらない人もいて、インターフェイス無茶苦茶で１人１人がかってに作ってるというのが最悪です。

で、STLは中華包丁という話ですが、STLは組み込み向けに最適化されているので、
protected継承などで使い勝手を買えることもできますし、
実際DS上でも実用になっています。
もしSTLがDSで使えないというのであれば使う側に問題があると思います。
例えば、どのあたりがtoo muchかあれば知りたいです。（vectorならメモリを勝手に確保するところとかですかね）
コードの展開をみても、そうそうおかしな処理をしないと思うのですが。
俺は配列もboost::arrayで統一してましたよ。

あと、勿論ハンドルクラス（weak_ptr的なもの）を自前で書いたり、
intrusiveなものを自作することはあります。ありますが、それはどうしても必要と言うときだけで、
それが汎用的な用途ではない、ということは多いです。

C++で「よくわからんから」多重継承は禁止すべしという幽霊

禁止はやりすぎたけど、積極的には使ってほしくないですね

「C++ 設計と進化」に書かれていある「多重継承は脱出用のパラシュートである。普段はいらないが必要なときには不可欠だ」というGrady Boochの意見に賛成です。

それと、ゲーム屋しか関係なくて申し訳ないですが、__m128のようなアライン必須のメンバ変数を持つクラスが多重継承すると管理が面倒なんですよね。

勿論、意味も分からず菱形継承したり、バリバリ多重継承OKというわけではないのですが、
「インターフェイス継承」がわからないのでそれも禁止という人がいたりするからです。
横断的にクラスにインターフェイスを提供した場合、どうしてもインターフェイス継承したい、ということがありますし、
vptrが問題になるようなアライン必須のメンバ変数を持つようなクラスはクラスをそもそも分離すべきです。

例えば、インターフェイスを継承する例として
「操作できる」や「フォーカスをあてることができる」というインターフェイスを差し込んだりする場合に、
インターフェイスを横断的に継承をすることがあります。
これら、インターフェイスを実装することで、等価なオブジェクトとして扱うための多重継承です。

ゲームだと、例えばキャラクタとその辺にある障害物は継承関係にないですが、
カメラフォーカスをあてられるので、カメラフォーカスに応答するインターフェイスはインターフェイス継承して、実装します。

C++は遅いしか言わない幽霊

確かにC++は遅くないのですが、前のエントリーにも書きましたが、遅くなる罠が埋まりやすいのが難しいんですよね。

実際にDSのタイトルでC++使ってないチームも居ました。

DSはメモリは少ないしCPUは遅いからキツイんだよねー。

言っていることは大変よくわかりますが、
DSの4M中、実際に使える実ヒープの2Mちょいの殆どをしめるのはメディアリソースなので、
クラス構造が持つ数byteがそのヒープを圧迫することは殆ど考えられないです。
それできついなら、リソース構造やアロケータを見直した方が良いです。
メモリがないない、といっている人はメモリの使い方が大抵無茶苦茶です。

あとARM946E-Sは結構早いと思いますよ。
67.024MHzというのは今では遅い部類に入るでしょうが、
DSレベルでやれることを考えれば普通に書いていれば遅いと感じることはないと思います。

描画周りで重いということはありますが、それはそれで不相応なことをやっているケースが殆どですし。

Luaとか既存のものより優れたスクリプトを作れるとか言い出す幽霊

コルーチン最高ですよね！

あれ無しでAI組むとか、もう無理です。

コルーチンは超便利ですね。
C++でもマイクロスレッドでいけなくはないですが。
ゲーム用スクリプトというのは社内で普通につくられたりしますが、
愚にも付かないものが騙し騙し使われていることも多く、
使い勝手が悪いが、Luaとか信用できないという理由で糞言語を使わされている感が満載なので、
LuaやSquirrelは普通に実用レベルとして使っていくと良いと思ってます。
糞社内スクリプトをつくる人はLuaを見て早く絶望して欲しいです。

……と、俺も思ったことを書きつつ反応してみました。
スライドからは省いた事もありますし、俺はこう思っていますよ、という感じです。
DSとかの開発経験は普通にありますしね。ｷﾘｯ

Python Hack-a-thon 2010.07で「本当にあった怖い話」をしてきました

土曜日のPython Hack-a-thon 2010.07で「本当にあった怖い話」をしてきました。
会場を提供してくださったオラクルさん、
そして、スタッフの皆さん、色々準備ありがとうございました。
また、参加者の皆さんお疲れ様でした！
（レポートは別途書きます）

で、俺のプレゼンは完全にネタなので、ご了承ください。（特にC++erの皆さん）
前半は前振りなので、あまり気にしないでください。

プレゼン中で某C++な人達の写真や、Twitter発言が引用してありますが、
もし問題があればお知らせください。

「ソースを読もう」とか意味ないですので飛ばすの推奨。
また、なんか話したいなあ。

C++の話（本当にあった怖い話）

View more presentations from Isoparametric .

あと、プレゼン中で「C++の設計と進化」を勧めていますが、
C++のことわからないとわからないかもと思いつつ、
言語の歴史を語るには必須と思うので、もし良ければお手にとってみてください。
なぜC++のような言語が必要とされたか、皆が文句をつけるC++はいかにして生まれたのかわかると思います。

C++の設計と進化

CakePHP1.3 バーチャルフィールドの動的指定

CakePHP 1.3からはVirtualFieldという機能がはいって、
モデルの実フィールドではないものを実フィールドであるかのように扱えるようになってる。
例えば、ユーザー単位での投稿数をCOUNT(Entry.id)でとりたい場合、今まではModelクラスのFieldであるかのように扱えなかったが、
扱えるようになった。

詳しくは、
CakePHP1.3移行ガイド - 新機能 > virtual fields

で、クラスにvar宣言してしまうと、JOINしたものをバーチャルフィールド化している場合、
JOINしてないSQLを発行したときにもバーチャルフィールドを使おうとするのでSQLエラーになってしまう。

で、これで良いと思うが、

        $this->virtualFields = array('entry_count'=>'COUNT(Entry.id)'); // SQL 発行前にバーチャルフィールド設定
        $users = $this->find('all', $options);
        $this->virtualFields = null; // 別のSQLを投げるときに邪魔になるので排除。

求む識者。

VSSが相変わらずフルボッコすぎる件について

「ゲームコーディング・コンプリート」より引用。
常識的に考えて嫌われすぎだろ……。

Microsoft製Visual SourceSafe

　Visual SourceSafeはMicrosoftのVisual Studioで使われているソースリポジトリである。「安かろう悪かろう」の良い例だ。
多くの人がこの製品に惹かれるのは、GUIインターフェイスが使いやすく、セットアップがとても簡単だからだ。タイプするのが遅くなければ、10分で起動できる。
　SourceSafeの一番の問題点は、ソースリポジトリをどうやって格納するかだ。リポジトリが格納された共有ファイルを探ってみると、AAAAAAAB.AAAとかAAACCCAA.AABのような奇妙な名前のついたファイルからなる大きなツリー構造のデータディレクトリがある。こうしたファイルの中身はプレーンテキスト（バイナリ化されていない）かそれに近い形だ。だからこの奇妙な名前のつけ方はセキュリティ上の理由からではない。理由をご存じの方はメールで教えてほしい。気になって仕方がない。
　それぞれのファイルは、リポジトリ内のファイルの、前のリビジョンとの差分を保持する。ファイルを改訂すれば新しくSourceSafeのファイルを作り、例の変な名前をつける。注意して見ていると、ソース変更が１文字程度の簡単なものであれば、作られるファイルの多くはかなり小さいとわかる。それなのに、SourceSafeがネットワークドライブに確保するスペースの量は、控えめにいっても容認できる限界を超えている。
　速度面でも深刻な問題がある。小さなプロジェクトでさえ数百のファイルの規模になり、大きいプロジェクトにいたっては何十万ファイルにもなり得る。SourceSafeはデータファイルをリポジトリディレクトリ構造に格納するので、ファイルの開閉にかかるアクセス時間は極めて長く、プログラマは最新のファイルかどうかをチェックするだけでも果てしなく待たされることがある。
　SourceSafeはブランチをサポートしておらず（ブランチについてはあとで触れる）、枝分かれさせたかったらツリー全体の完全なコピーを作らなければならない。お話にならない。
　SourceSafeにリモートでアクセスしようなどと思ってはならない。何千ものファイルをのろのろしたインターネットを介して検索するなどもってのほか。T1回線でもダメだ。最終的にSourceSafeのファイルインデックスデータベースは動かなくなり、ちょっとした分析ユーティリティにも降参し、やり直しだといってくる。私は以前、壊れたデータベースでプロジェクトを乗り切ったことがあるが、壊れた部分の影響が、もはや必要のない古いバージョンのファイルだけにとどまっていた。不幸中の幸いだった。
　SourceSafeには自ら壊れる癖もある。リポジトリ全体を役立たずの不可解なファイルの山にする。これは特に、サウンド、テクスチャ、ビデオなどの大きなバイナリ資源を格納するときに起こる。
　まだSourceSafe以外のものを使おうという気になってなければ、こういいたい。よく調べてほしい。Microsoft自身が使わないという噂を耳にしたことがある。もちろん単なる噂にすぎないかもしれないが、他の選択肢も検討してみる余地はある。

バージョン管理システムの紹介で、ダメだししか書いてないよー！

ただ、この本にもバグはあるので注意。
あまりにも典型的なバグをばらまかないでください - 好き勝手に・げーあにん？
など参照のこと。

ゲームコーディング・コンプリート 一流になるためのゲームプログラミング