はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #まえがき VRで酔わないための真のルールはそんなに多くない。これらを守ればワープやステップターンなど不自然な方法を使わなくてもまず酔わないものを作れる。 一般的な「VRで酔わないようにする」話は「酔わなかったこと集」を基礎においているのに対し、ここで紹介するルールは「酔ったこと集」を基礎においてそれらを排除することで作られているので「これを守らなければ酔う」という最低限の、真のルールにより近いものになっている...ハズ...たぶん...きっと...。 根本的なルールとして「挙動を感覚レベルで予測できるようにしておく」を挙げておく。「開

もともとpimplイディオムは個人的に「インターフェイスと中身の拘束が言語ではなくコードに依る(=誤りの元)」や「無駄にメモリ確保が必要」などという理由で嫌っていたが、C++では以下のようにすることでpimplイディオムは完全に不要になる。

※デザパタのAbstractFactoryと紛らわしいけど違うっぽい...でもGoFのアレは「パターン」と呼べるのか？ ...ともかく、抽象クラスのファクトリメソッドを呼んだら適切な具象クラスのインスタンスがnewされて返ってきたら便利だと思わないか？ だが親クラスは子クラスの実装は知らないのが原則(解放/閉鎖)なので普通にC++だけで組むと子クラスのファクトリメソッドを呼べなくて実装不可能...だと思ってたんだけど、ふと思いついてそれを可能にするテンプレートクラスを作ってみた。 template<typename T> class FACTORY{ FACTORY(); FACTORY(const FACTORY&); void operator=(const FACTORY&); public: FACTORY(T* (*f)()) : next(start), factory(f){

ツールが苦手なことをさせるとユーザーが苦労するので苦手分野で判断するといいと思う。 Gitは巨大なバイナリファイルが致命的に苦手だ。DVCSなのも災いしてリポジトリが膨れ上がるので映像関係の人とかはGitは避けるのが無難。 Mercurial(Hg)もDVCSだがHgの場合はファイルを--largeを指定して追加することでそのファイルだけ集中型扱いできるので巨大なバイナリも扱える。バイナリはマージできないのでロックベースで管理するしかないが拡張機能で一応ロックもできるようだし(ロックしないでITSのチケットで同じファイルを触らないように管理するほうがいいと思うけど)。 svnとP4は集中型なのでソースコードを扱う能力はDVCSであるGitやHgよりかなり劣る。ソースコードだけを扱うならこの２つよりはGitやHgの方がいい。ただP4のマージツールはよくできている(見やすい)。VCSにP4を使

まえがき、あるいは動機 ゲームギョウ界とかでよくあるのが「ソースコードと巨大バイナリを一緒に扱いたい」という状況。この場合Gitは容量を食いすぎて使えないが、Mercurial(Hg)ならDVCSでありながら巨大バイナリも現実的に扱える。ということでGitからHgへ移行する事を考えた時に躓きがちなところをまとめてみた。 bookmarkとbranch Hgのコマンド体系がSubversion(svn)ぽいところがある程度でGitとHgの中身はだいたい同じと考えていい(なので説明は省く)が、ブランチに対する考え方がかなり違う。 Gitから移行することを考えるとHgには二種類のブランチがあると考えるとわかりやすいだろう。一つはbookmarkでもうひとつはbranchだ。この二つの間に互換性はないので混ぜて使うことはできない。互いに見えないだけなので階層的に分けて両方使うのは問題ないが。 結論

なんだかその辺をググるとsubtreeラブな話が多いんだけど...。 subtreeを使う方がいい場合 subtree-mergeと呼ばれるようにマージしちゃうので修正を元のリポジトリに戻すのが面倒だが、マージした結果がリポジトリに含まれるので親リポジトリをcloneした時点で中身が入っている。 subtreeで取り込むとマージされてしまうのでsubtreeを使うのは 取り込むリポジトリに修正を戻さない場合 に限定するほうが良さそうだ。 変更をリポジトリごとに分類するのは人力 なので。 それと取り込んだリポジトリのアップデートを追う場合、取り込んだブランチでpullしてからそれを再マージすることになる。 submoduleを使う方がいい場合 リポジトリを取り込んでもリポジトリは分離されたままなので 取り込んだリポジトリに修正を戻す場合 はsubmoduleの方がずっと使い勝手がいい。sub

※独断と偏見です。何かあったら※欄でよろ ITSとの連携 ITSを使っている場合、トピックブランチの名前にはチケット番号を含める するとコミットメッセージにブランチ名が書いてあるのでITSのコマンドを書くのが簡単になる。またフックでコミットメッセージにコマンドを追加することもできる。 ブランチの構成 開発ブランチ 最初からある。名前はmasterでもdevelopでもいいけどリポジトリを作った時のmasterをそのまま使うのがいいんじゃないかと。また定期ビルドにはこのブランチのスナップショットを使う。 リリースブランチ リリースのための修正が必要で、かつ開発と並行作業したい場合は切る。でなければ不要。リリースブランチを切る、あるいはリリースブランチへマージするという事は機能固定するという事と同義となる。機能固定してリリースする分全ての修正が完了したらタグを打つ。 なお、ここに投入されたコミ