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++の設計と進化

GC読書会

そういえば、土曜日ですが、
『ガベージコレクションのアルゴリズムと実装』読書会＠関東 : ATND
これに参加してきました。
主にマークスイープGCとインクリメンタルGCを読み合わせして、
各所で質疑的な何かをしていました。

詳しくは、きむら(K)さん参照。
ときどきの雑記帖
shinhさんも記憶をダンプしておられました。
2010-04-25 - 兼雑記

で、なんでガベージコレクションかというと、
「ほら、ガベコレある言語って楽じゃん？」
って、日頃思っているとガベコレが羨ましくて調べたくなるからです。

実体験としてはLuaのときにインクリメンタルGCには凄くお世話になって、
かつ、ステップ実行できることを知っていたのですが、
それがどういう仕組みで行われているかはいまいち把握してなかったので、
（GCしている最中にオブジェクトの関連は変わるわけで、これどうなるんだ？　みたいな）
そういうものを氷塊させる意味でも凄く意義のある読書会であり、本でした。

多くの場合、GCがある言語ではメモリを意識する事は殆どないですし、
GCの動きをコントロールするよりメモリの使い方やアルゴリズムを見直した方がアプリケーションの最適化には寄与するのですが、
「GCは面白いので」という一言でGCは勉強する価値があると思います。

本はこの本です。

ガベージコレクションのアルゴリズムと実装

しかし、
本当にメモリで困っている人はこっちの方が実用書です。

省メモリプログラミング―メモリ制限のあるシステムのためのソフトウェアパターン集 (Software patterns series)

お仕事変わりました

とにかく年末は死んでいたので、お仕事変わりました。
ただ、色々柵で短期の仕事をしているので、
あと数ヶ月したら、もっときちんとしたところにいくです。
たくさんコードを書ける場所を探し中。
（というか、俺にちゃんとコードを書かせてくれるところ）
面白い仕事がしたいのです。面白くなくても面白さは自分でつくるので良いです。

Visual Source Safeを使用するのは狂気の沙汰

きっかけ。
元ネタ。

俺はVSSを使用しようというプログラマを信用しない。（と宣言しておく）
割と適当訳なのでご了承ください。

時々現れる、どのバージョン管理ツールをつかうのかという宗教的議論の中で、
私はマイクロソフトのVisualSourceSafeが一貫して叩かれている事に気付きました。

私はこれほどまでに憎悪を集めるような別のソフトウェアプロダクトを考えることができません。

私のプログラミングキャリアの日々では幸運なことに、svnを使う場所で働いていおり、さらに最近ではgitだったので、私はVSSを一度も経験したことがないということです。

VSSは本当に皆が主張するくらいに悪いものですか？

はい、そのとおりです！！
私はgit、svn、cvs、tfs、及びvssを使いましたが、VSSは最も悪かったです。
それには、みんなで作業を分離するという概念が全くありません。
ファイルを操作するとき、あなたはそれをロックします。
マージの概念は持っていません。
そして、それはただただ共有ドライブにおいてあり、ネットワーク操作ですべてを行います。そして、ぶっ壊れます。

> そして、ぶっ壊れます。
本当に！　そして、それはしばしば起こる！

早期、かつ頻繁に壊れる！

それが、VSSがVisual Source Shredder（ソースシュレッダー）と呼ばれる理由です。

私の会社では、１つのファイルを戻そうとしたために、仕事のコード全体を破壊しました。
恐ろしい、恐ろしい。
我々は常にバックアップをとるのが良い考えです。

右でも左でも競合がおきた。共有の問題もおきた。
離れた場所（例えば自宅）から簡単な修正を行うこともできない。
私はCVSのようなものが好きです。

完全に同意。
あなたは何ヶ月、何年もの仕事を絶対に失うでしょう。
数ヶ月、それを使用した誰でもそれを知っています。

VSSがロック方式でしか動かないという訳ではないよ。
ロックレスモードであなたのVSSを構築することもできます。
ただ、VSSは理解しがたいUIを持っており、それをすることはさらに悪化する場合があります。

VSSはマージできないというのは戯言です。
それは、悪いですが、まぁ、そんなに悪くはありません。
マージをすることができます。

Hateすぎる。
VSSで困っているのは世界共通なんだね！
で、こういう人もいるのだが、

七年以上、私たちは、6人の小さいチームで独立したVSSと共に働いています。
私たちにはどんな破損もありませんでした。
私たちはsvnに切り替わる必要はなくて、小さいチームにVSSは十分です。

私たちの開発者の大部分は、他の何かを一度も使用したことがないので、
私たちがVSSを使用していたとき、どう使いにくかったかがわかりませんでした。
SVNに切り替わって、私たちのいずれもVSSに戻って構わないとは思わないでしょう。
SVSを使用し始めるなら、あなたはVSSを使っていたときに比べ作業フローと生産性の向上に楽しくなり、驚くかもしれません。
あなたの経験は私と同じかも。

私に教えてください。
VSSからSVNに切り替えたら何を得られますか？

利点の説明が始まる。

多くの利益があるのですが、大きいものとしては、
・分岐
SVNは分岐を迅速に簡単にできますし、ディスクスペースを効率的に使ってくれます。
経験ではVSSで分岐をするとき、ブランチの必要性が考えられるケースに非常に慎重になり、殆どそれをしませんでした。
それをするのに時間がかかって、うんざりするプロセスであったので。
SVNの下では、必要なとき分岐すればいいのです。
バグや新機能はそれら自身のブランチで固定していて、容易に主コードに戻すことができます。

・速度
SVNはファイルやディレクトリ、また全体のプロジェクトの履歴を得るのに、VSSでできた速度より遙かに高速に動作します。

・バックアップ
SVNリポジトリは簡単にバックアップすることができます。
SVNのリポジトリはあなたのサーバのファイルシステムのフラットなファイルです。
アクティブな利用されているリポジトリをバックアップできますし、バックアップ中もソース管理システムを使うことができます。

・メンテナンス
SVNはオフラインでのメンテナンスや解析を必要としません。
メンテナンスを行う場合にシステムを長時間利用できないなんてことはありません。
*1

・リモートアクセス
HTTP（通常Apacheを使います）で容易にSVNにアクセスできます。
VSSではこれができないので、Source Offsiteのような別の製品を必要とします。

・コマンドラインツール
SVNには、包括的なコマンドラインツールがあります。
そもそも、SVNはコマンドラインツールですが。
テストのようなケースで、自動ビルドしたりすることが簡単になります。
これは、多分、それが利用可能になるまで（私の経験に基づいています）それがどんな活用性を持っているか想像できない領域の１つです。

・エクスプローラの統合
フリーで利用できるTortoiseSVNは、VSSの全ての機能をGUIで提供します。
Windowsのエクスプローラ上で、どのファイルが最新であるかを可視化できるようになります。

・ツール統合
多くのIDEやテキストエディタがSVNと統合できます。
あなたのツールにそれが存在していないなら、SVNフックはそのような統合環境を書くために利用可能です。
これは、ことによるとあなたがそれを試みるまで役に立つことが分からない領域です。

おまけ。
VSSの糞仕様について憤慨している人。

・それは、バカで効率の悪い方法でファイルを保持します。例えば、あなたがファイルの１つのキャラクタを書き換えるならば、小さい差分を保持するのではなく、ファイルの真新しいバージョンを保存します。あなたが別のものにある分岐を作ろうとするなら、深いファイルコピーをします。バカみたいに大容量のデータベースサイズになります。

・それは非常に遅いです。（特に、大容量になったデータベース）

・同時に複数のファイルをチェックインすることができないので、チェックイン操作において、複数のファイルへの変更を分類できません。（従って、貴方が個別にファイルを預けるとき、ソースの変化が激しい際に、同時にヒストリをブラウズして、どんなファイルがチェックインされたか見ることができません）

・システムに対する操作は何時間もかかるかもしれません。（トップレベルディレクトリを改名すると、あらゆるファイルを遡って再帰的に行わなければならないので、一個のフォルダを改名するのに何時間もかかりました）

・ツールサポートが最悪

・ファイルを編集するのに、そのファイルのチェックアウト（「チェックアウト」はSVNのロックと同等です）に依存しています。これはより遅い仕事となり、同じファイルを同じ時間に触ろうとしている人々をブロッキングします。（マージがそれを解決するとしても）

・データベースは崩壊します。私たちは、それを修理しようとしましたが失敗しました。私たちはバックアップから回復して、皆に最後の一日分の仕事を再びチェックさせるよう強制されました。

それは、ものすごく不快な製品です。
よりよい無料の代替手段があります。
あなたはそれを使用するというのなら、狂気の沙汰です。

結論、VSSを使用するのは狂気の沙汰。

*1:VSSは修復の際にオフラインにしなければならない