どうもJudaです。
Growlというアプリケーションのユティリティキット？みたいなものを夜フクロウを経由して知りました。「確かにこういうのがほしいんだよー」といった感じの機能でして、Focusのないアプリケーションにくる新着情報などを小さな”控えめな”Windowで表示してくれる憎い機能なのです。とりあえず主張がうるさくないし、Desktop上の滞在時間も文字列を全部確認できるぐらいの時間なのでいい感じ。
また自分でアプリケーションから呼び出しができるみたいで（当たり前）、なんらかの状態変化を通知する必要のあるアプリケーションではこの機能の利用はSmartかなぁ。まだなにも触ってないから苦労とか分からないけど、ちょっと気に入った。
9/27/2009
Pluginとマクロのための開発設計
どうもJudaです。
問題はこれらは設計段階でうまく考えておかないといくらリファクタリングしても、ほしい機能を実装するめどを立てられなくなりそうなので、いろいろ書いておく。
PlugInの機能をどうやって管理するのか。
たぶんこれは大別して2種類。
中間の形式が違うだけだ。入力:並べられたPlugIn、出力：呼び出し可能なPlugInの列挙。
マクロの問題を考えるなら、PlugInをインスタンス化できて、外部に公開されたメソッド名を使えば、そのPlugInをマクロで制御できるようにする構想も必要だ。
マクロ化するならば、内部的な関数の呼び出しも名前で呼べないといけないなぁ。
マクロを認めるなら、結局はスクリプトを認めることで、それならば内部にはParserが必要になる。この部分をPlugIn側にも認めるのか否かは。。。認めないといけないなぁ。
実際はそこまで考える必要性はないけれど、でもそこまで考えておかないと、未来の僕や僕の後を継ぐ人はかわいそうなコードをかわいそうなスケジュールでかわいそうな顔で変更したり、機能追加しないといけない。コメントをいくら書いても、できないものはできない。なので、イケテル設計(笑)をしないと。開発が嫌いになると困るので、十分調査していこう。
とりあえず、PlugInの管理は別の実行ファイルにしたい。それは、この機能は統合的には必要だけど、単体的には必要ない。だからDBもしくはCSV（Debug用）でPlugIn情報を表現する。
さて、ついでに必要になるのは、PlugInを単体でテストすることができる機能。これは開発者向けの必須ツールだ。最低限呼び出し可能かどうかのテストと、読み込んだデータに対して、期待したデータ処理ができるかが重要だ。できれば、テストデータをDefaultで用意できたり、ファイルの読み込みができたり、内部データを動的に表示したり、ログを取れたり、そういうのが絶対にその後の開発者の助けになるし、、、なにより自分がイライラしないだろう。うん、これは必要。
ほしい機能はとりあえず広げてみたけど、ざっくりまとめると
マクロ関係は基本の機能に依存するので、いったんは無視。
PlugInの部分の基本的な考え方は同じなので、これを優先的に作る。
マクロ機能に関しては、既存のスクリプト言語で代替可能であることが望ましい。
個人的にはIroｎPythonもしくはNativeのPython。大穴Scala？
PlugInの呼び出しは基本的にはShowDialog（）のような感じで、Dialogを出して、そこでパラメータを変更する。いくつかのメソッドをPlugIn側に公開する必要性があるので、ここを先に留意する。
後から来る人はかならずInterfaceの概念とCOMの概要は知っている必要性がある。この際にOptionとしてDebugのツールキットインターフェイスを引数に入れられるようにすると、、、、複雑度が上がるか。。。
問題はこれらは設計段階でうまく考えておかないといくらリファクタリングしても、ほしい機能を実装するめどを立てられなくなりそうなので、いろいろ書いておく。
PlugInの機能をどうやって管理するのか。
たぶんこれは大別して2種類。
- 内部に管理クラスをもつ実行ファイルがあり、それが内部で呼び出すPlugIn機能を利用する
- 外部に管理クラスをもった実行ファイルがあり、それが生成するDBを元にPlugIn機能を利用する
中間の形式が違うだけだ。入力:並べられたPlugIn、出力：呼び出し可能なPlugInの列挙。
マクロの問題を考えるなら、PlugInをインスタンス化できて、外部に公開されたメソッド名を使えば、そのPlugInをマクロで制御できるようにする構想も必要だ。
マクロ化するならば、内部的な関数の呼び出しも名前で呼べないといけないなぁ。
マクロを認めるなら、結局はスクリプトを認めることで、それならば内部にはParserが必要になる。この部分をPlugIn側にも認めるのか否かは。。。認めないといけないなぁ。
実際はそこまで考える必要性はないけれど、でもそこまで考えておかないと、未来の僕や僕の後を継ぐ人はかわいそうなコードをかわいそうなスケジュールでかわいそうな顔で変更したり、機能追加しないといけない。コメントをいくら書いても、できないものはできない。なので、イケテル設計(笑)をしないと。開発が嫌いになると困るので、十分調査していこう。
とりあえず、PlugInの管理は別の実行ファイルにしたい。それは、この機能は統合的には必要だけど、単体的には必要ない。だからDBもしくはCSV（Debug用）でPlugIn情報を表現する。
さて、ついでに必要になるのは、PlugInを単体でテストすることができる機能。これは開発者向けの必須ツールだ。最低限呼び出し可能かどうかのテストと、読み込んだデータに対して、期待したデータ処理ができるかが重要だ。できれば、テストデータをDefaultで用意できたり、ファイルの読み込みができたり、内部データを動的に表示したり、ログを取れたり、そういうのが絶対にその後の開発者の助けになるし、、、なにより自分がイライラしないだろう。うん、これは必要。
ほしい機能はとりあえず広げてみたけど、ざっくりまとめると
- PlugInの呼び出し、実行（ｄｌｌ）
- マクロ機能の呼び出し、実行、（変換機能：動的＋コンパイル済み）
- PlugInのテストツール
- マクロのテストツール
- PlugInのマネージ機能
- Debug用のお助けツールキット(オプション式)
マクロ関係は基本の機能に依存するので、いったんは無視。
PlugInの部分の基本的な考え方は同じなので、これを優先的に作る。
マクロ機能に関しては、既存のスクリプト言語で代替可能であることが望ましい。
個人的にはIroｎPythonもしくはNativeのPython。大穴Scala？
PlugInの呼び出しは基本的にはShowDialog（）のような感じで、Dialogを出して、そこでパラメータを変更する。いくつかのメソッドをPlugIn側に公開する必要性があるので、ここを先に留意する。
後から来る人はかならずInterfaceの概念とCOMの概要は知っている必要性がある。この際にOptionとしてDebugのツールキットインターフェイスを引数に入れられるようにすると、、、、複雑度が上がるか。。。
DevKANに行ってきました
DeｖKANに行ってきました。
まぁ、楽しい会でした。みんな開発愛にあふれていました。
個人的にはテスト工程の方々の苦悩やテスト工程の方々からの提案がとても身に染みました。やはり開発者の敵対関係にあるのは、特定の問題なのだと、より考えを明確にしました。
個人的には、開発ツールへの愛を語る方がいてもよかったかなぁと（じゃ自分でやれ？
LTも初めてみたのですが、とてもためになりました。
うんうん、ぜひぜひ関西にこの種が芽吹くことが願われます。（他人事？
次はコミュニティー参加は読書会へ行きたいなぁ。
読書会でどれぐらいの知識LVが求められるのか、知りたいなぁ。
#devkan2009
まぁ、楽しい会でした。みんな開発愛にあふれていました。
個人的にはテスト工程の方々の苦悩やテスト工程の方々からの提案がとても身に染みました。やはり開発者の敵対関係にあるのは、特定の問題なのだと、より考えを明確にしました。
個人的には、開発ツールへの愛を語る方がいてもよかったかなぁと（じゃ自分でやれ？
LTも初めてみたのですが、とてもためになりました。
うんうん、ぜひぜひ関西にこの種が芽吹くことが願われます。（他人事？
次はコミュニティー参加は読書会へ行きたいなぁ。
読書会でどれぐらいの知識LVが求められるのか、知りたいなぁ。
#devkan2009
9/23/2009
The Last Guy
どうもJudaです。
PS3専用ゲーム 「The Last Guy」
いまさらこのゲームなのですが、前から気にはなっていました。ちなみに２０００円でした。
音楽はそれなりにいいのですが、後１分のときの音楽のちょっぴりうるさいことがなぁ。
ゲームの難易度は高めで、大人ゲーマーでも複数回のチャレンジが必要だと思います。ゆとりゲームではないので、小学生ではこのゲームをクリアしていくのは厳しいと思いました。
ゲームをやってみて思ったことは、スタミナへの配慮と列の長さの把握がかなり比重を占めていると思います。あとは敵の巡回経路などもありますが、一貫した法則や索敵範囲がゲーム中で分かりにくいので、これよりもより列とスタミナの把握が重要でと思いました。とりあえず敵がみにくいので、目が疲れます。
PS3専用ゲーム 「The Last Guy」
いまさらこのゲームなのですが、前から気にはなっていました。ちなみに２０００円でした。
音楽はそれなりにいいのですが、後１分のときの音楽のちょっぴりうるさいことがなぁ。
ゲームの難易度は高めで、大人ゲーマーでも複数回のチャレンジが必要だと思います。ゆとりゲームではないので、小学生ではこのゲームをクリアしていくのは厳しいと思いました。
ゲームをやってみて思ったことは、スタミナへの配慮と列の長さの把握がかなり比重を占めていると思います。あとは敵の巡回経路などもありますが、一貫した法則や索敵範囲がゲーム中で分かりにくいので、これよりもより列とスタミナの把握が重要でと思いました。とりあえず敵がみにくいので、目が疲れます。
9/13/2009
VB.NET における メモリリーク問題
どうもJudaです。
最近はTwitterでつぶやきまくって、満足しているのですが、それではここの利用価値が上がらないので、割と重めな内容をPickUp
VB.NETで長時間運用するとメモリを圧迫してメモリリークを起こす問題がある。
http://support.microsoft.com/default.aspx?scid=kb;[ln];q313417
大学時代の製作物の中にこの問題にひっかかるものがあるので、コレに対処するべく調査中。
開発者として給料をいただいている身で思うことがある。
それは、プログラマに求められる以上のことだ。
自己を防衛するための機構の導入だ。
テストしかり、トレースしかり、デバッグプリントしかり、ログ機能しかり。
これらのものは、本来の開発ではオプションである。
しかしこれらを欠くと著しく後期の開発において欠損を生む。
近頃これをよく思う。
詳しくは後日説明を加えたいと思う。
それで後日談。
とりあえず.NETのガベージコレクタはそれほど賢くないので、なるべく明確にゴミを設定してやる必要がある。
それとその前に結果的にだが、プログラマはオブジェクトの所有権にその持ち方についてある程度留意する必要があるということだ。（スマートなポインタが売りだった気がするのだが。
結論としてDisposeのメソッドをもつことが最も確実なメモリ解放への配慮だったりする。
いくつかあるメモリへの配慮として、
ちなみに配列のEraseはすべての要素にNothingを入れるのとほぼ同等らしいです。
ここからが問題ですが、クラスの確保した領域の解放ですが、ここはさりげなくC/C++とそれほど変わらないというのが調べてみた感じです。
これは確かC/C++でmallocを行ったときに発生するプログラマのぼんやりから発生するメモリリークとそれほど変わらない。結局C/C++的な考え方を持ち込んでこないと問題を回避できないっぽい。
ここで、明確に破棄するための手段としてIDisposeの適応が考えられる。これによってプログラマは明示的に破棄方法を設定できる。これがもっとも問題の少ない解決法である。
これは憶測だが、Stringの解放が若干怪しい気がするが、基本型で用意されているので問題ないと思うが、C/C++的な考え方からするとこれは基本型ではないので、ちゃんと解放されるのか心配だ。
最近はTwitterでつぶやきまくって、満足しているのですが、それではここの利用価値が上がらないので、割と重めな内容をPickUp
VB.NETで長時間運用するとメモリを圧迫してメモリリークを起こす問題がある。
http://support.microsoft.com/default.aspx?scid=kb;[ln];q313417
大学時代の製作物の中にこの問題にひっかかるものがあるので、コレに対処するべく調査中。
開発者として給料をいただいている身で思うことがある。
それは、プログラマに求められる以上のことだ。
自己を防衛するための機構の導入だ。
テストしかり、トレースしかり、デバッグプリントしかり、ログ機能しかり。
これらのものは、本来の開発ではオプションである。
しかしこれらを欠くと著しく後期の開発において欠損を生む。
近頃これをよく思う。
詳しくは後日説明を加えたいと思う。
それで後日談。
とりあえず.NETのガベージコレクタはそれほど賢くないので、なるべく明確にゴミを設定してやる必要がある。
それとその前に結果的にだが、プログラマはオブジェクトの所有権にその持ち方についてある程度留意する必要があるということだ。（スマートなポインタが売りだった気がするのだが。
結論としてDisposeのメソッドをもつことが最も確実なメモリ解放への配慮だったりする。
いくつかあるメモリへの配慮として、
- 変数にNothingをSetする。
- 配列をEraseする。
ちなみに配列のEraseはすべての要素にNothingを入れるのとほぼ同等らしいです。
ここからが問題ですが、クラスの確保した領域の解放ですが、ここはさりげなくC/C++とそれほど変わらないというのが調べてみた感じです。
- 循環参照はうまく解決できない。
- Nothingを入れる前に入っている変数のサイズ分しか解放されないっぽい。
これは確かC/C++でmallocを行ったときに発生するプログラマのぼんやりから発生するメモリリークとそれほど変わらない。結局C/C++的な考え方を持ち込んでこないと問題を回避できないっぽい。
ここで、明確に破棄するための手段としてIDisposeの適応が考えられる。これによってプログラマは明示的に破棄方法を設定できる。これがもっとも問題の少ない解決法である。
これは憶測だが、Stringの解放が若干怪しい気がするが、基本型で用意されているので問題ないと思うが、C/C++的な考え方からするとこれは基本型ではないので、ちゃんと解放されるのか心配だ。
9/06/2009
Mercurialの有用性について
どうもJudaです。今日はコード管理について。
Mercurialというコードヴァージョン管理ソフトについてです。
まぁ、よく似たのにはGitがあります。
入門Mercurial Linux/Windows対応
Mercurial: The Definitive Guide
オライリーだとこれがありますけど、前述の書籍のほうが日本語だしいいかなぁって思います。
いまどきのソフトウェア会社でコード管理をしていない会社なんてほとんどないと思いますけど、個人ではまだやってないって言う人もいると思います。かくいう私も最近までは管理していませんでした。これは、単純にそういう管理面でのことを教えてくれる記事などがあまりないということが関係あると思います。しかし個人でのいかなるソースコードも資産として価値があると思います。だから管理しておくに越したことはありません。
ほかの管理ツールは
・Subversion
・Git
・Visual Source Safe
とかありますけど、個人で有料のものをつかっていくのはなかなか大変です。そもそも高いですし。その点で言うとオープンソースで開発されているSVNとかGit、Mercurialは有料ではないが、とても有用なプロジェクトの一つだと思います。
Mercurialの基本的な動きなどは、解説書に譲りますが、個人的に使うときに気づくと思うのですが、10Mbyte以上のデータは管理できないらしいです。あとGUI付のTortoise（トータス）系はWindowsのShellと融合して使いやすい反面、間違いを起こしやすいので注意。
あとは、管理といってもやることは簡単。でもちょっと違うことをおこなったときに、どうすればいいのだろうということは結構あります。実際にSubversionで”Working Copyを先にしてね”みたいなエラーは意味が分かりませんでした。もっとも説明書も読まずに使おうというのが間違っています。そして、その説明書が段階を踏んで説明されているわけではないので、解説書を手に入れると結構踏み台としていい感じです。
ちなみに日本語化をするととっても意味不明になります。そもそもの単語が意味分からないで使っているのに、それを日本語化しても分かりやすいわけはないので、なるべく英語のほうがいいです。そして検索の際にも英語で検索するほうが情報が手に入りやすいです。日本語で説明しているサイトや記事が充実していない状態ではなるべく言語パッチを当てないほうがいいです。
あとは大前提としては、英語の情報やプロジェクトのほうが多いので、それを読むことになれること。これは、もはや相対的な開発者の言語分布が英語が圧倒的に多いので、それを受け入れることである。嫌なら、日本語で同等か、それ以上のものを作るしかないです。まぁ、だから日本にはまだ市場があるんだけどね。
多くの事項は、Mercurial入門の日本語の本にあります。ぜひこれを買いましょう！話は戻って、SubversionとMercurial、Gitはなにが違うのか。それは情報の集積のやり方です。SubversionなどのCVSは中央集権的、Mercurialは分散型です。
中央集権的なSubversionは、すべてを管理するRepositoryがあります。個々のRepositoryをもつことは一般的ではありません。分散的なMercurialもRepositoryはあります。しかし個々のRepositoryがあるのです。中央集権的に振舞わせることもできますが、それではよさが活きません。分散型のよさは、中央が死んでいても、個々のレベルで情報を共有して、コード管理できます。これは、結構開発現場ではいいことなのです。たとえば、サーバがなにかの障害で使えなくなっても、個人のソースコードはいつもどおり管理できますし、中央を介せず、個々のレベルでもソースコードの同期を取れます。そのたびにマージがおきますが、このマージの方法も実に合理的です。
Subversionでは、UpdateしてMergeしてCommitします。MercurialはCommitしてPullしてMergeしてCommitしてPushします（たしか
重要なのは、自身の変更結果を自身でも保持しているので、途中で自分の変更がなくなったりしないのです。Subversionは結構マージでてこずると、マージ前に戻したいのに、戻せないことに気づきます。これは、ある意味絶望です。成果がパーなので。
ここらへんで、Mercurialの話は終わりますが、一番重要なのは、SubvesrsionとMercurialは共存できます。だから個人でMercurialを導入しても問題ありません。
そして、これはあくまで手段です、より効率よくソースコードを管理できるのであるならば、別の方法を採用するべきでしょう。というか、ちゃんとそこを理解しないと頭悪い感じになるなぁ。
Mercurialというコードヴァージョン管理ソフトについてです。
まぁ、よく似たのにはGitがあります。
入門Mercurial Linux/Windows対応
Mercurial: The Definitive Guide
オライリーだとこれがありますけど、前述の書籍のほうが日本語だしいいかなぁって思います。
いまどきのソフトウェア会社でコード管理をしていない会社なんてほとんどないと思いますけど、個人ではまだやってないって言う人もいると思います。かくいう私も最近までは管理していませんでした。これは、単純にそういう管理面でのことを教えてくれる記事などがあまりないということが関係あると思います。しかし個人でのいかなるソースコードも資産として価値があると思います。だから管理しておくに越したことはありません。
ほかの管理ツールは
・Subversion
・Git
・Visual Source Safe
とかありますけど、個人で有料のものをつかっていくのはなかなか大変です。そもそも高いですし。その点で言うとオープンソースで開発されているSVNとかGit、Mercurialは有料ではないが、とても有用なプロジェクトの一つだと思います。
Mercurialの基本的な動きなどは、解説書に譲りますが、個人的に使うときに気づくと思うのですが、10Mbyte以上のデータは管理できないらしいです。あとGUI付のTortoise（トータス）系はWindowsのShellと融合して使いやすい反面、間違いを起こしやすいので注意。
あとは、管理といってもやることは簡単。でもちょっと違うことをおこなったときに、どうすればいいのだろうということは結構あります。実際にSubversionで”Working Copyを先にしてね”みたいなエラーは意味が分かりませんでした。もっとも説明書も読まずに使おうというのが間違っています。そして、その説明書が段階を踏んで説明されているわけではないので、解説書を手に入れると結構踏み台としていい感じです。
ちなみに日本語化をするととっても意味不明になります。そもそもの単語が意味分からないで使っているのに、それを日本語化しても分かりやすいわけはないので、なるべく英語のほうがいいです。そして検索の際にも英語で検索するほうが情報が手に入りやすいです。日本語で説明しているサイトや記事が充実していない状態ではなるべく言語パッチを当てないほうがいいです。
あとは大前提としては、英語の情報やプロジェクトのほうが多いので、それを読むことになれること。これは、もはや相対的な開発者の言語分布が英語が圧倒的に多いので、それを受け入れることである。嫌なら、日本語で同等か、それ以上のものを作るしかないです。まぁ、だから日本にはまだ市場があるんだけどね。
多くの事項は、Mercurial入門の日本語の本にあります。ぜひこれを買いましょう！話は戻って、SubversionとMercurial、Gitはなにが違うのか。それは情報の集積のやり方です。SubversionなどのCVSは中央集権的、Mercurialは分散型です。
中央集権的なSubversionは、すべてを管理するRepositoryがあります。個々のRepositoryをもつことは一般的ではありません。分散的なMercurialもRepositoryはあります。しかし個々のRepositoryがあるのです。中央集権的に振舞わせることもできますが、それではよさが活きません。分散型のよさは、中央が死んでいても、個々のレベルで情報を共有して、コード管理できます。これは、結構開発現場ではいいことなのです。たとえば、サーバがなにかの障害で使えなくなっても、個人のソースコードはいつもどおり管理できますし、中央を介せず、個々のレベルでもソースコードの同期を取れます。そのたびにマージがおきますが、このマージの方法も実に合理的です。
Subversionでは、UpdateしてMergeしてCommitします。MercurialはCommitしてPullしてMergeしてCommitしてPushします（たしか
重要なのは、自身の変更結果を自身でも保持しているので、途中で自分の変更がなくなったりしないのです。Subversionは結構マージでてこずると、マージ前に戻したいのに、戻せないことに気づきます。これは、ある意味絶望です。成果がパーなので。
ここらへんで、Mercurialの話は終わりますが、一番重要なのは、SubvesrsionとMercurialは共存できます。だから個人でMercurialを導入しても問題ありません。
そして、これはあくまで手段です、より効率よくソースコードを管理できるのであるならば、別の方法を採用するべきでしょう。というか、ちゃんとそこを理解しないと頭悪い感じになるなぁ。
登録:
投稿 (Atom)