自分用メモ
必要な機材や具体的な手順などはいくらでも例があるので、ここでは自分のための設定や忘れそうな注意点などをまとめる。
目的は月刊コミック誌のスキャン。紙質が悪くページ数が多いものが対象。カラー白黒混在。
スキャン、後加工ともに手間はかけない方向で。そのためエクセレントの白黒ではなく、スーパーファインのグレー取り込みを中心に進める。
- 設定
元ファイルは300dpiのPDFで保存する。必要に応じてjpg等に加工。
-
- 画質:スーパーファイン
- カラーモード:カラー または グレー。
- 継続読み取り:カラーの場合は無効、グレーの場合は有効(カラー原稿を別に読み込んでグレー原稿に挿入するため)
- オプション:全てOFF
- 圧縮率:3または2
カラーモードは自動判別でも良いが、モノクロ原稿がほとんどの場合はグレーのほうが手っ取り早い。自動だとグレーでスキャンしてほしい所で白黒tiffになったりする。
- 雑誌の分解
ヒートガンで雑誌の背中部分を暖め、接着剤を溶かす。1000Wのものなら10秒も暖めると背表紙が剥がせるようになるので、ゆっくりと剥がしていく。表紙、裏表紙を破らないように注意しながら分離する。剥がした表紙、背表紙には接着剤が付いているので無理にScanSnapで取り込まず、フラットベッドスキャナで別途取り込む。またはA3キャリアシートを使う。
- 雑誌の裁断
接着されている部分は余裕を持って全部切り離す。接着剤が残ってしまうとスキャナの破損、原稿自体の破損に繋がってしまうので、思い切って切断する。大型裁断機の場合、あまり大量に裁断すると裁断面がゆがんでページサイズが変わってしまうので、500枚切断可能とあっても無理せず200枚程度(1〜2cm)に分けて裁断する。
- スキャン
事前に原稿をばらし、接着剤が残っていないことを確認する。最初にカラーページ含め数枚をテスト読み込みして、ゴミ・接着剤の付着による縦線が発生していないか確認する。
- スキャン後
ScanSnap Organizerでページ順、抜けなどを確認する。カラーとグレーを別々に読み込んだ場合はここで結合する。
- ScanSnap意外のスキャナで作成したPDFの処理
表紙を別のスキャナでPDFにした場合、ScanSnap Organizerでの結合が出来ない。ただし内容によっては、PDFファイルのプロパティをScanSnapで取り込んだ文書のように見せかければ編集可能になる。
PDFファイルを PDF InfoMaker で開き、「文書情報」の「作成」を「PFU ScanSnap Organizer 4.1.14」に、「PDF変換」を「Adobe PDF Scan Library 3.2」に変更する。
BitNami::Redmine Windows版のインストールに失敗した場合
BitNami Redmine Stack のインストール時に発生した問題とその対応策をメモ。
(ただしWindows2000にインストールした場合の話)
- MSVCP60.DLL が無いと言われる
事前に VC6RedistSetup_jpn.exe をインストールしておく。
- CORE_RL_magick_.dll が無いと言われる
インストール先のフォルダ内にある \imagemagick にパスを通しておく。
- インストールの最後でエラーメッセージが表示される
Problem running post-install step. Installation may not complete correctly
Error running C:\Program Files\Bitnami Redmine Stack/apps/redmine\scripts\redmineini.bat : rake aborted!
No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb)
C:/Program Files/Bitnami Redmine Stack/ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2377:in `raw_load_rakefile'
(See full trace by running task with --trace)
rake aborted!
No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb)
C:/Program Files/Bitnami Redmine Stack/ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2377:in `raw_load_rakefile'
(See full trace by running task with --trace)
インストール先フォルダ\apps\redmine\scripts\redmineini.bat をもう一度実行する。
TicketChangePluginを動作させるための変更内容メモ
こちらの記事(http://d.hatena.ne.jp/ohgui/20091120/1258724595)を見て、そういえばTracLightning2.2.5とTicketChangePlugin(r4748)を組み合わせた時に、そのままではうまく動作させられなかったなあと思い出したのでその時の改造内容をメモ。
この改造自体、どこかのサイトを参考にしたはずなのだが思い出せない…。
TracLightningを更新すると、また改造が必要になるのだろうか。
@@ -1,5 +1,5 @@ +# -*- coding: utf-8 -*- # Ticket changing plugins - from genshi.builder import tag from genshi.filters import Transformer from genshi.filters.transform import StreamBuffer @@ -34,12 +34,12 @@ def insert_change_link(): cnum = list(buffer)[0][1][1][0][1] - return tag(" ", tag.a("Change", href=("../ticketchangecomment/%s?cnum=%s" % (ticket.id, cnum)))) + return tag(" ", tag.a("変更", href=("../ticketchangecomment/%s?cnum=%s" % (ticket.id, cnum)))) - filter = Transformer("//div[@class='change']/div[@class='inlinebuttons']/input[@name='replyto']/@value") + filter = Transformer("//div[@class='inlinebuttons']/input[@name='replyto']/@value") return stream | filter.copy(buffer).end() \ - .select("//div[@class='change']/div[@class='inlinebuttons']/input[@value='Reply']") \ - .after(insert_change_link) + .select("//div[@class='inlinebuttons']") \ + .append(insert_change_link) return stream # IRequestHandler methods @@ -168,7 +168,7 @@ old_author, old_comment = cursor.fetchall()[0] cursor.execute("UPDATE ticket_change SET newvalue=%s WHERE ticket = %s AND time = %s AND field = 'comment'", (comment, id, time)) db.commit() - self.env.log.info("Ticket #%d comment of '%s' by '%s' has been updated by '%s':\nold value: '%s'\n\nnew value: '%s'\n" \ - % (id, strftime('%A, %d %b %Y %H:%M:%S', localtime(time)), old_author, author, old_comment.replace('\r', ''), comment.replace('\r',''))) + #self.env.log.info("Ticket #%d comment of '%s' by '%s' has been updated by '%s':\nold value: '%s'\n\nnew value: '%s'\n" \ + # % (id, strftime('%Y/%b/%d %H:%M:%S', localtime(time)), old_author, author, old_comment.replace('\r', ''), comment.replace('\r','')))
チケット画面にリンクが「変更」と表示されるように修正し、UnicodeDecodeError発生部分をコメントアウト。とりあえず動いたのでこれで良しとしてしまったが・・・pythonを知らずに改造しているので本当に正しいのか自信がない・・・。
追記：今確認したら、TicketChangePluginの最新版はr5333になっていた。改造したものは、一つ前のr4748。
追記２：2008/11/6にTrac0.11系へアップデートした時にこの改造を行っているので、それ以前にどこかに情報が出ていたはずなのだが(自分ではpythonのコードが書けないので)、今検索しても該当しそうなページが見つからず・・・。
追記３：UnicodeDecodeErrorに関しては、sitecustomize.pyで解決出来るという情報も。時間をつくってなんとか試したい。TracLightningでは 「sys.setdefaultencoding("utf8")」 設定済みのため関係なし。
http://www.okisoft.co.jp/esc/cygwin-15a.html
svnsyncでコピーしたリポジトリにはsvn switch --relocateできない
後々問題になりそうなのでメモ。
svnsyncでリポジトリのレプリケーションを行った場合、UUIDが異なるためにsync元とsync先のリポジトリ間でsvn switch --relocateする事が出来ない。元のリポジトリからチェックアウトした作業コピーは捨てて、sync先のリポジトリから再度チェックアウトする必要がある。
単なるバックアップとして使うのであれば、svnsyncよりもFSFSのホットコピーのほうがマシかもしれない。今回はWebDAV透過ライトスループロキシを使おうとしてハマってしまった。
後からググったところ、同じパターンではまった方が。
Agonizing Days: svn switch --relocateではUUIDが異なるリポジトリのSwitchはできない
http://agnozingdays.blogspot.com/2008/05/svn-switch-relocateuuidswitch.html
将来的には『--ForceオプションによるUUIDチェックの回避』が入るかもしれないが、今の所は再チェックアウトが必要になりそう。
テストケースのボリューム
TestLinkでテスト内容を管理するとして、その内容はどのくらい細分化すれば良いのだろう。
当初は１つのバグに対して１つのチケット(Trac)、１つのテストケース(TestLink)としていたが、これではテストケースの内容が巨大化しすぎる。
かといって、１つのテストケースに確認項目は１つだけ、という形で分けてしまうと、相互に関連するようなテストがバラバラになってしまう…。
中間のテストスイートを作って、そこにまとめるようにすれば良いのだろうか？
特定のテストスイートにまとめた時に、各テスト間を繋ぐための追加条件でも付け足すようにすれば良いのだろうか。
試行錯誤中…。
追記：ここ読んでやり直したほうがよさそうだ。
きちんと学びたいテストエンジニアのためのTestLink入門：第6回 テストケースの作成 ｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/testlink/0006
TracとTestLinkを連携させるために必要な設定
新プロジェクトでTestLinkを使おうとしてハマったのでメモ。
設定出来てない状態でTestLinkの「バグ管理」やっても、何も起こらないだけでエラーメッセージ類が出ないんだよなあ。TestLinkのイベントログからは何が起こってるのか読み取れないし…。
こちらの内容を参考にしました。
TracLightning の Apache 環境で動かした TestLink を Trac と連携させる - かおるんダイアリー
http://d.hatena.ne.jp/kaorun55/20090415/1239784203
TracLightning の Apache 環境で TestLink を動かす - かおるんダイアリー
http://d.hatena.ne.jp/kaorun55/20090415/1239783737
プロジェクト管理システムTracとTestLinkの統合手順-Benri/TestLinkTrac-PukiWiki - TEF有志によるテスト管理システムTestLink日本語化プロジェクト
http://testlinkjp.org/modules/pukiwiki/?Benri%2FTestLinkTrac
- XML_RPC 権限の付与
まず、 anonymous ユーザに TICKET_VIEW , XML_RPC 権限を割り当てる必要がある。
新プロジェクトでは authenticated から上位のパーミッションにしか TICKET_VIEW , XML_RPC 権限を割り当てていなかったので、まずここを変更。(ホントはanonymousにTICKET_VIEW割り当てしたくなかったんだけど仕方なし)
\testlink\cfg\trac.cfg.php を開いて、以下のセクションを修正。
/** Mapping TL test project name vs trac project url */
$g_interface_bugs_project_name_mapping = array(
'TLProject1' => 'TracProject1',
'TLProject2' => 'TracProject2',
'TLProject3' => 'TracProject3',
);
コミットコメント
svnのフォルダの話、ソースのコメントの話と来て、今度はコミットコメントについての話題を目にしました。
コミットコメントの書き方 - watawata日記
http://d.hatena.ne.jp/wyukawa/20090918/1253280437
コミットのやり方 - まさたか日記
http://d.hatena.ne.jp/masataka_k/20060820/1156064203
せっかくなので、メモ代わりに自分のやり方を。
基本的にはすべて自己流で、誰かに教えられたり確固とした理由付けがあってしている手順ではないので問題があるかもしれません。ぜひコメント下さい。
コミット時の注意点
- 複数の変更(チケット)を同時にコミットしない
TracなどBTSとsvnをリンクしている場合は、複数のチケットにまたがるようなコミットをしないように注意する。
チケットごとにブランチを切っているような場合は特に問題にならないと思います。
- 変更内容を一度に全部コミットしない
これは一般的じゃないかも。
変更内容によりますが、例えば何か新機能を追加する場合、「新機能に必要な定義、宣言の追加」「新機能の呼び出し部分、インターフェース部分などを追加」「新機能の実体部分を実装」のように、変更時の流れにそってある程度分割コミットしてます。
- 最低でもコンパイルが通る事を確認してコミットする
バグまで潰した上でコミット出来れば良いのですが、実際にはなかなか難しいのでせめてコンパイルだけは通る状態に。
コミットコメントの注意点
- ソースのコメントと同様に「意図」を書く
コミット時にどんな変更をしたのかは差分を見れば一目瞭然なわけなので、
「何のためにこの変更を行ったのか」
「どんな目的でこのコードに変更したのか」
など、差分から読み取れない、読み取りにくい情報をコミットコメントとして付加します。
（私の場合、ソースのコメントにこういった内容がすでに書かれているためコミットコメント自体はソース内コメントの要約になる事も多いです）
- コメントに複数の内容が交じる場合は、コミット内容自体を分割する
一度のコミットでは、一つの事しかやらないように。
コミットコメントを書いていて、複数の項目に分かれるようならコミット自体を分割するようにしています。
実際の流れ
- バグ/追加発生。変更作業のためのブランチ作成(1チケット1ブランチが理想だがsvnだと難しいのである程度まとめて)
- 変更実施。出来るだけこまめにコミット。
- 規模にもよるが数回〜十数回のコミットで作業完了。
- チケットごとに1つずつトランクへマージ。できるだけ、複数チケットの内容を一気にマージしないように注意。
以上、とりあえず思いついたまま書いてみました。
