2005.07.28

Subclipse

メモ。

Subclipse は Eclipse の Subversion プラグイン。
正直 Subversion そのものの理解がいまいち足りないような気もしているがそれはそれとしておく。

■やりたいこと
Eclipse でプロジェクトを作り、ある程度開発を進めたところで Subversion に突っ込む。ただ突っ込むだけなら「プロジェクトの共有」で一発だけど trunk とか branches とか tags とか (以下この三つをひっくるめて強引に tbt と呼ぶ) を考慮した構成にしたい。

ただし「リポジトリルート/tbt/プロジェクト名」という構成は Subversion の公式マニュアルと比較して違和感があるので却下。あくまで tbt はプロジェクトに付随するものというのがおれの認識だ。よって「リポジトリルート/プロジェクト名/tbt」を目指す。

■共有する
SVN Repository Exploring Perspective で予めプロジェクト名 (以下 project) のディレクトリを切っておく。リポジトリルートを http://localhost/svn/repos/ とすると http://localhost/svn/repos/project/ となる。

Java Perspective か Resource Perspective に移ってプロジェクトの共有を実行する。その際にモジュール名を trunk にし、http://localhost/svn/repos/project/ に登録すれば http://localhost/svn/repos/project/trunk で取れるようになる。

■ブランチする
SVN Repository Exploring Perspective で予め project の下に branches ディレクトリを切っておく。つまり http://localhost/svn/repos/project/branches/ となる。

Java Perspective か Resource Perspective に移ってプロジェクトのブランチを実行する。ブランチ名を branche-1 とすると、ブランチ後の URL は http://localhost/svn/repos/project/branches/branche-1 を指定する。

ブランチで作業する場合はもちろんそちらにスイッチすること。自動的にスイッチしてくれないので注意。

■タグを付ける
基本的にブランチと同じ。ただ、タグなら編集不可にしないと不味いような気がする。運用でカバーするのかシステム的にオーバーライト不可にできるのかは不明。まあうっかり上書きしたところでタグを貼った時 (ブランチした時) の一番古い履歴を取ればいいから致命的な問題にはならないと思うけど。


ざっとこんな感じ。もっと勉強しないとな。

| | Comments (0) | TrackBack (0)

2005.02.15

Linux体験講座

少し古い話題で 2004 年 8 月 20 日の話。
べつにおれが参加したわけではないので念のため。


参加者レポート。
http://jp.rubyist.net/magazine/?0001-RubyCourseReport

講習内容。
http://ecs.riko.shimane-u.ac.jp/~nawate/2004_linux/

課題。
http://ecs.riko.shimane-u.ac.jp/~nawate/2004_linux/exercize.html


で、課題に挑戦してみたわけだ。実際には講習で取り上げた知識だけで作らねばならなかったようだが知ったことかー。

# 1. サイコロの目を出すスクリプト
# 乱数発生のメソッド rand を利用して 10 回サイコロを振って、
# 順に出た目を表示するスクリプトを作成しましょう。
10.times do
  puts rand(6) + 1
end

まあ楽勝。

# 2. Loto6
# Loto6 のような 1 から 48 までの数を 6 個作るスクリプトを考えましょう。
array = []
while array.length < 6 do
  num = rand(48) + 1
  array.push(num) unless array.include?(num)
end
p array.sort

loto6 なら 1 ~ 43 だが細かいことは気にしない。最後の Array#sort はオマケ。模範解答を見て ruby ではあのように書くものだと誤解する人がいたら嫌だ。

# 3. 配列の要素の並び替え
# 次に示す配列の要素を小さい順に並べ直しましょう。
# array = [21, 5, 3, 15, 7, 9, 33, 2]
array = [21, 5, 3, 15, 7, 9, 33, 2]
p array.sort

こっちは Array#sort 使ったら課題の意味ないわな。

| | Comments (0) | TrackBack (0)

2005.01.21

eval

Persica は Javascript と相性が悪いことが判明。eval が消化不良を起こしてしまう。動けばいいやと良く分からないまま書いた箇所だ。とりあえず調査中。

| | Comments (0) | TrackBack (0)

2005.01.16

Persica V0.40 公開

【Persica】

果たして使う使わない以前にダウンロードした人がいるのだろうか。

| | Comments (0) | TrackBack (0)

2005.01.14

Persica 改良案

Persica の今後の機能追加についてつらつらと考えてみた。

0.30 に至ってなお面倒に感じるのは、Recent プラグイン使用ファイル(以下 Recent ファイル)の扱いである。このファイルは、Recent プラグインの機能と目的を考えれば、他に変更されたファイルがある限り、それ自体に変更が加えられていなくても毎回必ず変換しなくてはならない。

しかしながら現時点では、変更されていないファイルを変換するためには -f オプションを指定する必要があり、そうなると全てのファイルが変換されるので、ファイル数が多い状態で特定のファイルに細かい変更を何度も加えることになると、数秒のわずかな待ち時間であっても結構なストレスになるのだ。特に Amazon プラグイン使用ファイルの変換に掛かる時間が馬鹿に出来ない。

当初は最後の最後に -f 指定で実行すればいいと気楽に考えていたのだが、意外に -f 指定実行後に誤字や誤記に気付く(しかもそれを繰り返す)頻度が高いことが判明した。まあ、単におれがそそっかしいだけと言えばそうなのだが、考えてみれば -f オプションは本来スキンファイルに変更が加えられた場合への対応が目的であって、Recent ファイルの面倒を見るには挙動が大袈裟に過ぎる。

では今求められている機能は何か。突き詰めて考えれば、「-f オプションの有無に関わらず毎回必ず変換されるファイル」という概念の導入である。もう少し練りこむと、更に「他に変更の加えられたファイルがあれば」という条件を追加したくなるのだが、そこまで窮屈にしなくても実行時のストレスを軽減する効果は得られると思う。

実装レベルで考えると、変換元のテキストファイル内に常時変換を意味する何らかの記号を記述しても意味がない。変換対象ではないファイルはそもそも内容を走査しないからだ。ここはもちろん $source_dir/.status に書くべきだろう。このファイルには $source_dir 配下の全てのファイル名が記述されている。そして Persica は Recent プラグインに渡す情報を取得するために、起動後まず真っ先にこのファイルを読み込む。これ以上の適任はあるまい。

$source_dir/.status には現在、変換元ファイルの (1) $source_dir からの相対パス、(2) 更新日、(3) MD5値 が記述されている。この末尾に変換種別を示す記号を追加すれば良い。

しかしユーザが $source_dir/.status を直接編集するのは面白くない。個人的なこだわりではあるが、キカイが書いてキカイが読むものに人間が手を加える必要性も権限も認めたくはない。

となると変換種別を人間はどうやって指定するのか。上で「意味がない」と書いたものの、結局のところ、そのファイル自身に記述するしかなさそうである。それが一番簡単で確実なのだ。どんなファイルでも作成時と内容の変更時は絶対に変換される。その際に $source_dir/.status に記録してしまえば何も問題はない。タイトル行の先頭文字で判断するのが分かりやすくて良いだろう。無関係の文字であれば指定なしと判断するわけだ。

最大の難関はその記号を何にするか。おれはネーミングもそうだが、その辺のセンスがまったく欠如しているのだ。

……とりあえず「!」にしとくか。

| | Comments (0) | TrackBack (0)

2005.01.13

Persica V0.30 公開

【Persica】

例によって変更点などは付属ドキュメントを参照のこと。

| | Comments (0) | TrackBack (0)

2005.01.12

Persica V0.20 公開

【Persica】

変更点などは上記ページか付属ドキュメントを参照のこと。
まあどうせおれしか使わねえし。

一応おれが不便を感じない程度には機能も安定性も充実してきたが、逆に言えばおれがあまり必要性を感じていない「なんとなく」実装した機能はかなりヤバい。気をつけろ。

| | Comments (0) | TrackBack (0)

2005.01.11

Net::HTTP

メモ。

Net::HTTP でハマっている。正確には Net::HTTP::Proxy である。いまいち良く分かっていないのだが、どうも start で刺さってしまっているらしく、しばらく待つと Timeout:Error が返って来る。

問題が発生するのは例によって Persica の Amazon プラグイン。しかしテスト(Amazon プラグインのインスタンスを生成して apply_block を呼び出すだけ)を書いて実行するときちんと正常な結果を返すのだ。

……と悩んでいたのだが、ふと思いついて amazon プラグイン使用ファイルだけを変換してみたら問題なし。ならば、とファイル単位でGC.startを実行するようにしたら、案の定、何事もなかったかのように正常に動作するようになったとさ。めでたしめでたし。

| | Comments (0) | TrackBack (0)

2004.12.26

バージョン0.10b

マニュアル等最低限のドキュメントが揃ったらbを取ろうと思う。いつになるんだろう。その間も思いつくままにソースは改変されていくだろうに。以下、徒然なるままに。

----
テキストファイルの一行目の末尾に[yyyy.mm.dd]があると作成日付情報として扱われていたのだが、これがないと一部のプラグインが困るので、ない場合は強制的に付与することにした。形式も[[yyyy.mm.dd]]に。これ、今気付いたけどブラケットネーム形式じゃないか。もはや無関係と言えばそうなんだけど、なんとなく気持ち悪い。<<yyyy.mm.dd>>にしようかなあ。でも面倒臭いなあ。

----
現在テキストファイルが変更されたかどうかの判定はしていない。Recentプラグインは単純に全ファイルをmtimeでソートしたリストを受け取って新しい順に指定数分拾っているだけなので色々面白くない挙動をしてくれる。そこでMD5を使って比較判定するように変更しようと目論んでいるのだが、そうなると前回の値を記録しておく必要が生じるわけだ。面倒臭いなあ。

----
コマンドラインオプションの処理が出鱈目なのをなんとかしないと。面倒臭いなあ。

----
そういやAmazonプラグイン以外のプラグインが全部default.rbに入ってるってどうなの。ContentsとかLsとかNaviとか外に出そうか。でも面倒臭いなあ。

----
ああそうだコンフィグ。コンフィグファイルで設定できる必要のある項目とそうでない項目の切り分けも真面目に考えないと。面倒臭いなあ。

----
なんと言ってもマニュアルだよな。一応手元の最新版ではコマンドラインオプションでコンフィグファイルを指定できる機能を追加してマニュアル用のスキンを用意したので後は中身を考えるだけなんだが、やっぱり面倒臭いなあ。

----
面倒臭くなったので今日のメモはここまで。

| | Comments (0) | TrackBack (0)

2004.12.24

Persica - ペルシカ -

【Persica】

今まで ccweb と呼んできたアレの正式名称が決定した。
ついでに勢いで公開してしまったが、ドキュメント類が一切付属していないので多分誰も使う気にはならないだろうな。

| | Comments (0) | TrackBack (0)