HgInitの試訳

どうもJudaです。

JoelがMercurialの入門手引きを書いたので、かっとなって日本語に訳してみた。最初の頁のとちゅうまでだけどね。

--以下訳--

私の会社にいるプログラマたちがSubversionからMercurialへ乗り換えることを決めたとき、ジョエル少年は混乱してしまった。

はじめに、あらゆる乗り換えるべきでないくだらない理由に付き合ってくれた。”私は中央サーバにリポジトリを保持すべきであり、それが安全だと思う。””君はしっているのか？君はあまり詳しくないだろうがMercurialでは全ての開発者が自らのハードディクス上にリポジトリ全体のコピーをもつんだよ。それは実際にはより安全だろう。なにより、大抵のMercurialを採用したチームは中央サーバもつかうし、君がBackupをとらなければならないという強迫観念にかられるようなら、そうしよう。また君は3層にもなるセキュリティー、Cylons、Stromtroopers、またはをささやかな開放的な領域を構築できるよ。"

"煩雑なバージョン管理によるトラブルはブランチすることによってすぐに起きてしまうし、ブランチをつくることは常に問題を起こす。””結局この考えも良くない。いずれ悪い結果がおきる。Subversionでブランチすることは問題を発生するのは、Subversionはマージ処理をおこなうのに十分な情報を持っていないからだ。Mercurialでは、マージは苦痛じゃないし、簡単だ、そしてブランチはありふれたことだし、害もない。

”そいつはいいね、つかってみるよ。でもとても僕には理解できるようには思えないよ”僕はJacobにMercurialでSubversionで行っていた事と同等のことをできるようにCheatSheetをつくってくれるように頼んだ。

いま、私はこのCheatSheetを君にみせれる、でもしない。それは数カ月のものあいだ混乱のもとだったからだ。

結局のところ、Subvesionをつかっていたとしよう、それは君の脳をすこし、えっと礼儀正しく言うにはどうすればいいのかな。その、イカれちまってる。おっとこれはよくない。君には少し再教育が必要になる。私が半年の間MercurialがSubvesionよりも複雑だと考えることによってイカれちまった部分を探してみた。でもそれは私がMercurialがどういう働きをするのか理解していなかったから、一度分かれば、ちんからほい、Mercurialはある意味簡単だ。

だから私は君のために手引書を書いている。この手引書では、慎重にSubvesionの意味で説明しないようにした。それもこれ以上の混乱のもとをなくすためだ。もう混乱のもとはたくさんだ。代わりにSubvesionからきた人たちのためにMercurialを勉強するために可能な限り綺麗な状態に戻そうと一章つかってやってみようと思う。

Subvesionを使ったことがないのなら、次の章にいくといいよ。見逃さないでね！

準備はいい？いくよ。ここで簡単なクイズ！
Q1. 初回で完璧なソースを書けますか？
もし君がはいと答えたら、君はとんでもない嘘つきだし、詐欺師だ。君は失格。また試験を受けてくれ。

新しいコードはバグに満ちている。ちゃんと働かせるには、すこし時間がかかります。その間の時間、チームの他の開発者の苦痛になります。

このとき、Subvesionはどのように働くか、
新しいコードをチェックインするとき、みんなトラウマコードを取得します。
君の書いた全ての新しいコードはバグだらけですので、君は悩みます。
バグのあるコードをチェックインして、他の開発者に苦痛を与える。
バグがなくなるまでの間、チェックインをしないようにする。
Subvesionは常にこの苦しいジレンマを起こします。リポジトリはバグで満ちている。新しいコードを入れてもバグを含むし、また新しいコードを管理しないならそれもバグだ。
Subvesionをつかうひとなら、このジレンマが存在しないことを想像できないでしょう。

Subversionをつかうチームはしばしば何日もあるいは何週間も何もチェックインしないことがある。Subversionチームでは、新入りはあらゆるコードをチェックインすることを恐れる。ビルドを壊してしまうこと、つまり年長の開発者のマイクさんやそういったお歴々を怒らせるを恐れる。マイクはすぐにチェックインによってビルドが壊れたことに腹を立てて、インターンのいるパーティションまでやってきて、彼の机の上のものを全部払いのけて、「てめぇはクビだ！」と叫ぶでしょう。（もっともそうならなくても、哀れなインターンはパンツを濡らしちゃいますけどね。）
あらゆるこの種のチェックインに関するおそれはみんながコードを何週もの間バージョン管理のご利益を得ずにソースを書くことをいみし、そしてこの状況に気づいたある年長の開発者がそれらをチェックインするように助けて回る。
どうしてバージョン管理が使えないのに、バージョン管理を導入したいと考えるだろう。

--ここまで訳--

確かにSubversionのジレンマはそのとおりだと思う。しかもこれでブランチを作りまくれば、まぁ大変になるのも仕方なし。とりあえずはやく全部読む。

ADO.NET Data Serviceにおける注意点

どうもJudaです。

ADO.NET Data Serviceの暗黙的な制約があるっぽいので、注意を。

このサービスを作るときに.svc.csファイルに記述をしていくと思いますが、この時に注意があります。基礎となるデータ構造へのアクセスを提供するIQueryableのプロパティを持つクラスはすべて一箇所にDataServiceと同じところに書いておかないとサービスが使えない。どうもそうらしい。もう少し厳密に調べてみる。それにしてもややこしいなぁ、このシステム。どうも最近VisualStudioのWizardが生成するコードとの相性が悪い。どうも道から離れているみたい。

追記

どうも原因が一定しないみたい。問題を捉えたと思ったら逃げられた。一箇所にデータを入れておいたのに、サービスが認識されない。要求エラーが表示されて、内部にエラーが潜在してしまう。作り方自体は、各種サンプルを参考にしているがどうしても問題点を捉え損なう。

バイナリ化しているものの参照がうまく行っていない気もするけれど、いかにしてそれを捕まえるのか分からない。最近こんなんばっか。はしごが外されている。

もいっちょ追記。

DataServiceのTが扱っているEntityにNullにならない一意なIDになるものプロパティがないと、駄目だ。これがないだけで、全てがおじゃんになる。あとはEnumの継承型をEntityに含めることはできない。使えないんだよ。だから、大抵はint,stringのオンパレード。ちなみにDateTimeも使えない。これが痛い。使えるのかも知れないけど、とりあえず直接は入れられない。とりあえずこうすれば、コードを分割して記述してもいけるし、DLLで参照もできる。これもEntityをDBから作らないから、エラー出力をする属性も分からないし、調べ方も分からない。

ADO.NET Data ServicesあらためてWCF Data Services

どうもJudaです。

ここにいい導入発見。いくつかの注意点をあとから洗い出します

Using Microsoft ADO.NET Data Services（http://msdn.microsoft.com/library/cc907912.aspx）

Silverlightのためのいくつかの話

どうもJudaです。
Silverlightリファレンスブック
ASP.NET MVC実践プログラミング―.NET Frameworkによる標準Web開発技法
Silverlightで開発するデータ駆動アプリケーション
とりあえずこの3冊は現状で手に入る日本語のSilverlightまわりの書籍としてはとってもいい。

リファレンスブックは、「そうなんだよ、この実装をどうやるか知りたかったんだよ」っていうものがちらほら。
ASP.NETは、「そもそもSilverlightのクロスドメイン回避するWebサービスが必要だな」ってときに助かる。
データ駆動は、「Silverlightを使い倒してやる」っていうアプリケーション開発者にはぴったりな一冊。

ADO.NET Data Servicesに関する情報は少ないし、そもそもWebアプリケーションに関するビビッとくる本に未だ出会えていない。誰かご存じないですかねぇ。

Silverlightのイベントについて

どうもJudaです。

Silverlight のイベントの概要

Silverlight のカスタム クラスのイベントの定義

RoutedEventは既存のSilverlightのコントロール以外には適応されないようです。

どうもJudaです。
いきなりSilverlightというか、WPFというか、
Bindingで使われるDependencyPropertyの話をMSDNの項目からかなり抜粋するが、
細かな部分だが結構込み入った使い方をする。
依存関係プロパティは、DependencyObjectに存在するPropertyのことで、
DependencyObjectプロパティストアに格納されている。
このプロパティストアを所有するDependencyObjectは、
public static readonlyで修飾されるDependencyProperty識別子を使って、識別される。
この依存関係プロパティを実装しようと思うと、通常のプロパティ(CLRプロパティ)をラップする必要性がある。
この依存関係プロパティがなぜ「依存関係」プロパティというのかという一因は、
あるプロパティが別のプロパティを値としてい持てるからであり、
実行時までその値を評価するのを遅延させることができ、
そのことによってプロパティに依存関係を作ることができるからである。
これはBindingとも関連する。
このプロパティを記法は似ているが、異なる添付プロパティが存在する。
例えば、Canvas.Leftのような個別のオブジェクトが所有していないプロパティである。
この添付プロパティの実装は、依存関係プロパティと似ているが、
設定された値が、自身ではなく、要素に対する付加的な意味合いがある。

カスタムしたイベント群を作っていこうと思うと、後半の添付プロパティをうまく使っていかないと、
XAMLで楽をできない。
ましてや、サポートされていない機能であるDrag&DropやDoubleClickの基本構造を適応していこうと思うと、
添付プロパティを使わなくてはとてもコーディングできると思えない。

ただイベントの登録をどうするのかが若干困りものではある。
大まかにはわかるのだが、
Propertyとして設定しようとして
そのプロパティを呼び出したときのオブジェクトを知らせてくれるならば、
オブジェクトとともにイベントハンドラを持てばいいのだろう。

関連付けさえうまくできればなんとかできそうではあるが、煩雑なことにはかわりない。
あとはListBoxからのDrag&Dropに関しても、内部で取得されるItemsSourceが不定であるので、
Converterを指定し、さらにDrag時の描画や、Dragのイベントなどの処理まで考えるとうんざりしてしまう。
ちょうどいいことにライブラリはあるのだが、Telerikのライブラリいいんだけど、10万も出せません＞＜
でもこの機能で10万は安い買い物だと思います。
ちなみに体験版もあるので、ぜひ！

Vimでのコメントアウトについて

どうもJudaです。

掲題の件に該当する記事のサルベージ

Vim Tip: Comment out multiple lines

commentout.vim : ソースをコメントアウト ←→ コメントアウト解除

とりあえず一番上の英語をオレオレ訳

Vimのプラグインなしで、一連の行をコメントアウトすることについて

ヴィジュアルブロックでコメントアウトしたい行を選択して、そのときに”I”を入力する。これは、選択した部分の頭に挿入を行うためだ。次にコメントアウト用の文字を入力する。PythonやShellなどなら＃だ。そのあとでESCする。

頻繁には使わないけど、時々使う便利なVimコマンドを忘れてしまう。ブログに書けばいいのに。

君はヴィジュアルラインで選択したものについては別の方法を使える。　”s/^/#”ってやつだ。

こいつなら行頭にコメントアウト用の文字をくっつけることをができるさ。

って感じか？

電子書籍の新しい形をサービスへ

どうもJudaです。

前回描いた電子書籍の新しい形をやっぱりサービスにしたい。

友人と話をしていてとっても勇気づけられたから、なんとか夏までにサービスに原型を作る。

そのときに新しくあるといい機能が出たので、メモしておく。

1. 本から別の本への参照機能
2. 気に入った部分のリスト機能
3. リスト公開機能
4. 書籍の情報入力の簡易化

とりあえずメモの共有機能をやるとどうなるのかやってみる。

電子書籍というよりも書籍型アプリについて

どうもJudaです。
今日は面白そうだと思った。電子書籍のやり方をぽつぽつと。

まずはTweet抜粋

書籍化されたアプリ。。。これは、面白い。　これに追加して、他人のメモが挟まっていたりするとおもしろいのではないだろうか？　 http://bit.ly/abQUHL

書籍化されたアプリというニュアンスはとても心地いい。そしてそれはこれから電子書籍をどうしていくのかについて、とてもいい指針を表している。 VerUpしていく書籍ということを考えていたが、これにMedia機能を盛り込んでいくことによって、これまでの書籍とは価値の違う書籍を提供できる。

実はその手前に電子カルテを見据えている。これの普及が日本での鍵かな。日本の出版業界には期待していないので。

何を考えているのかというと、既存の紙媒体の書籍と電子書籍の棲み分け。既存の紙媒体をただ代替するだけでは、あまりに電子書籍という考え方は面白くないし、そもそも出版業界が邪魔をするのでうまく普及できない。日本ではKindleが対応していないが、一応EPUBという形式はあるが、普及はしていない。既存の紙媒体の特徴というのは

1. 無電力
2. 高い保存性
3. 印刷したものは変化しない
   
4. 可読性の高さ
5. 自由度が高い
6. 版組がきっちりしている
7. 物理的なコンテナを持っている
8. 紙の感触をもつ
9. 重さがある
10. 手に入れるまでに時間がかかる
11. 索引があるけれど、検索はできない

これらが主な要素として挙げられる。そこで電子書籍はなるべくこれと競合しないように考えてみる。

1. 電気を使う
2. 電源を切ると見えなくなる
3. 買った状態から書かれている内容が変わる
4. 可読性は変化できる
5. 自由度は制限される
6. 版組を変更できる
7. 書籍自体の物理的なコンテナはない
8. 紙の感触はない
9. 書籍自体としての重さはない
10. オンデマンドに手に入る
11. 索引がなくても、全文検索などができる。

こうして考えてみると、現在のブログに近いところが多い。ここまで来てしまうと、情報という意味が強く押し出されてしまって、書籍らしさというものはない。もっとも書籍らしさというものも物理的なコンテナの制約がなくなる時点でとてもあやふやではあるとおもう。
さて話は戻るがここで一つ、試みを足してみる。それは他のメディアを補強するものとして、文字を使うことである。ちなみにこれはすでにペンギンブックスなどが試みている。しかし私は、この方向も面白いが、情報量的な制約によってできることとできないこともあるし、それ以上にこれでは書籍じゃない。雑誌のグラビアが動画になっているのもいいけれど、もっと猥雑さを足してみたい。
例えば書籍にメモを貼れるようにして、それをTwitterや、ニコニコ動画のようにみんなで共有する。現実の本で考えるならば、たくさんのポストイットが貼られている感じ。これがみんなで共有できるのは、オモシロイと思う。ブログに対してコメントを残していく事に比べて、敷居が下がるかどうかは、分からないが、動画にコメントをする行為が受け入れられているので、それほど悩ましい問題ではないかもしれない。
いままでこれをやろうとすると、どうしても同時性に欠けてしまったり、物理的に賃借しなければ読めないことなどがあるが、その問題は電子書籍ではなくなるし、そもそも本を読んでいる人の輪はネットワーク上で補填されるの、地理的な意味は薄くなる。
これは読者側の一体感や同時性を演出するための仕掛け。おなじコンテキストを共有することに対しての提案としての電子書籍。
もう一つ、書籍自体の改版のあり方について、変えてみたい。つまりはVerUpする書籍。あるいはBeta書籍。
現在の書籍は常に完成された形で生まれてきて、長い時間の間で若干の修正が入る。ServicePackがあたるようなもんだ。では、これをBetaで公開しましょう。Alphaで公開しましょう。もしこれを有償のサービスとしてやるなら、Alphaで参加した人は、Betaで参加した人よりも安く手に入り、作者は早い内から読者のFeedBackをもらえる。仮に完成したなら、それを書籍として物理的に発売してもいいだろう。これは、代謝の激しい技術書の世界で根づいてくれるなら、とても嬉しいサービスだ。
つまり技術書、とくにコンピュータ関係の書籍はVerUpによって変更がよく起きる。しかしそれは基本的なものを全部捨て去るほどのものではないし、次の版で、新しいVerのことが追加されて発売されることもままある。そのために良書の版違いをいくつも集めなければいけないことに忸怩たる思いをしている。その問題を解消することが狙いである。あとは、技術書ならば、サンプルを足してもいいし、わかりにくいところを補稿をしてもいい。つまり完全な書籍を販売できないので、不完全な状態から公開、販売し、それを継続的にケアしていく。
こうすることによって、電子書籍は紙書籍とは異なるプロセスで成長できるとおもう。現状の販売システムとは異なるものであり、販売のタイプはライセンス系の契約事項に似てくると思う。そこまで含めてケアできるサービスと、クライアントを用意できれば、これはとてもオモシロイと思う。文字情報をなるべく紙媒体で読みたいという要望は、いずれ電子ペーパーが近いものを提示してくると思う。でも、あくまで紙の代替ではないやり方を電子書籍が追求すると、とてもいい。
こういうビジネスをやりたいなぁ。

Silverlightとの戦い

どうもJudaです。
Silverlightと最近は格闘中ですが、面白いです。TemplateやBindingはパワフルで使い出のあるアドバンテージです。これらの機能を使いこなすことでコーディング量を劇的に減らすこともできますし、自分の中のデータとビューの関係性を捉え直す機会もくれます。実に取り組みがいのある技術です。この先には、まだまだ多くの発展技術がいることを考えると、挫けそうですが。
それはそうとSilverlight4RCがきましたが、まだ確認をしていません。それよりなによりVerUpの頻度が多い気がします。それ自体は悪いことではないですが、技術書が出揃わないうちにVerUpされると出版側が手を出しにくくなって、困ります。ただでさえ、少ないのに。
ブログなどもいくつも見ていますが、重要なのは基本的な機能に十分習熟することと、Bindingをコード側からも理解することがかなり重要ですね。特にとっつきづらいのはCanvasとGridの実際的な制約事項。
Canvasは自由配置できるのですが、Grid内に配置しても自由に配置を出来ること。Gridのみの場合には、自由配置が全くできないので、XAML側での構造の構築には気を使わなければなりません。あとはDrag&Drop機能を使おうと思うときには、構造をよくよく見れば明白ですが、ListBotのListBoxItemはListBoxの外ではそのまま使えないので、取り出したあとなんらかのコンテナを必要とする点や、データ自体の受け渡しのみならば、別のItemSoruceをもつものとも融通がきくことなど。
実際にコードを触らないとあまりに些末で考えなければならないことが多いです。

Silverlightのパス指定

どうもJudaです。

Silverlightのパス指定について、重要なことを一つ。

パスの区切りは\ではなく、/。ましてや￥は使えない。

これすごい重要。

VSでIntelliSenceのセンスがインテリでもセンスでもなくなったとき

どうもJudaです。

VS2008でIntelliSenceが使い物にならなくなりました。その解決方法は、devenv.exe のコマンドオプション　/resetsettingもしくは/resetskippkgsのいずれかを用いて、設定がうまく更新されない問題を再設定を行なうことによって解消します。

このオプションの存在を知らないと、延々と続く再インストールを行い、なおかつ設定が変更されていないので、結局IntelliSenceがつかいものにならないという事態が発生してもおかしくないので、なにかこまったことがあったときには実行ファイルをコマンドプロンプトで実行してオプションを知るのもいいなぁと感じました。それにしてもVSは知らない機能が多くありすぎて、使いこなせていないのも一つあります。また悲しいことにVSの説明書はどれも初心者のためのものが多くあり、中級で普段の使い方になれて、次の段階へ移行しようとする開発者にとっては使い物になりません。Keyboardの隠しショートカットの存在とか、アドオンの設定とか。