2010年7月29日木曜日

rails helper の汚染ふたたび

 ヘルパの汚染が深刻なのである…。
active_scaffold を使っていると、helper にて

def options_for_association_conditions(association)
if association.name == :hoge
['hoge.funya = ?', 1]
elsif association.name == :fuga
['fuga.hoe = ?', 2]
else
super
end
end

なんてコードを書いて、リレーションの選択時に、コントローラで特有のフィルタリングを行ないます。
ところが、こいつも汚染されてしまう…。

 どう対処するか?ヘタレな方法だけども


class ApplicationController < ActionController::Base
before_filter :set_controller_name

def set_controller_name
session[:controller_name] = self.class;
end
end


として、


def options_for_association_conditions(association)
if session[:controller_name] == 'MogeController'
if association.name == :hoge
['hoge.funya = ?', 1]
elsif association.name == :fuga
['fuga.hoe = ?', 2]
else
super
end
else
if association.name == :hoge
['hoge.funya = ?', 2]
elsif association.name == :fuga
['fuga.hoe = ?', 3]
else
super
end
end
end


という指針にしますた。まだ何か落とし穴がありそうな… Object って危ないのねん、好きになれないな…。

2010/8/6 追記: appliction_controller.rb に

helper :all

の文字が…、こんなの知らねーよっ orz...

rails duplicate habtm 二重に多対多備忘録

 Hoges と Fugas が多対多の関係で欲しい場合は、habtm を使えばシンプルに済みます。しかし、この多対多の関係が、もうひとつ欲しい・・・となったとき、?????かなり悩んだ

create table hoges (
id serial primary key,
name varchar(16)
);
create table fugas (
id serial primary key,
name varchar(16)
);
create table fugas_and_hoges (
id serial primary key,
fuga_id integer,
hoge_id integer
);
create table another_fugas_and_hoges (
id serial primary key,
fuga_id integer,
hoge_id integer
);

このようなテーブルに対して

class FugasAndHoge < ActiveRecord::Base
belongs_to :fuga
belongs_to :hoge
end

class AnotherFugasAndHoge < ActiveRecord::Base
belongs_to :fuga
belongs_to :hoge
end

class Fuga < ActiveRecord::Base
has_many :fugas_and_hoges, :dependent => :destroy
has_many :hoges, :through => :fugas_and_hoges, :dependent => :destroy
has_many :another_fugas_and_hoges, :dependent => :destroy
has_many :another_hoges, :source => :hoge, :through => :another_fugas_and_hoges, :dependent => :destroy
end


class Hoge < ActiveRecord::Base
has_many :fugas_and_hoges, :dependent => :destroy
has_many :fugas, :through => :fugas_and_hoges, :dependent => :destroy
has_many :another_fugas_and_hoges, :dependent => :destroy
has_many :another_fugas, :source => :fuga, :through => :another_fugas_and_hoges, :dependent => :destroy
end



 うーむ・・・

2010年7月28日水曜日

iPadのPDFアプリ比較

 はじめにお断りしておきますが、この比較は、独断と偏見によるもので、完全に裏をとったものではありません。また、PDFも書籍をデジタルスキャンしたままの状態で、画像をの集合体というPDFに特化した比較となっています。その点を考慮にいれておいてください。テキストを含むPDFの評価はありません。

 Cloudreaders 1.12, iBooks 1.1.2, Bookman 1.3, FastPDF 1.2, GoodReader 2.8.1, iBunkoHD 1.03 以上が私の持っているPDFアプリです。これらのアプリを系統で分けると
  1. iBooks, iBunkoHD, Cloudreaders
  2. Bookman
  3. GoodReader
  4. FastPDF

になります。
 iBooks 等は、Apple が提供する PDFライブラリを駆使すると思われるもの
 Bookman は、ページ毎にPDF内のObjectタグから直接画像を処理して適切な解像度の画像を生成するもの
 GoodReader, FastPDF は、独自のPDFライブラリを駆使すると思われるもの

いきなり結論から言うと、A5版までの文字が極端に細かくない書籍を読むのに最適なアプリは、Bookman がダントツでしょう。インデックス用のサムネイル画像と、表示用の画像を事前に生成していると思われます。Bookmanの動作推定根拠は、一定以上は拡大しても解像度が固定のままであるし、ページの回転情報を無視して生の画像からページを生成しているので、PDFが指定する画像の向きと異なる表示になる事がある点です。これに見開きページの偶奇と、左右読み方向の設定に対応してくれれば、もう思い残すことはありません。それぐらい快適です。一般的な本を読むのに、Bookmanを愛用してます。

 どんなに重たい画像がきても落ちる事なく安定している凄アプリは、GoodReaderです。安定度No1と言えます。高解像度のカラー画像本(600Mにも及ぶ)を、いろいろなアプリで開きましたが、落ちなかったのは、GoodReaderとBookmanだけでした。他のアプリは落ちまくりです。Bookmanは、画像処理をやってしまうので落ちません。GoodReaderは、拡大した範囲しか画像を展開しないので落ちません。よって、困ったPDFは全部GoodReaderで開いとけば安心です。GoodReaderでは、解像度の変更もできます。<-Resizeというフォルダがインデックス化されているのを見て勘違いしてた。解像度の変更まではできません。

 さて、それでは、やや重たい程度の節度ある画像が含まれるPDFを読むのに適したアプリは?というと、FastPDFという事になるでしょうか…。正直、どれも決定打に欠けるのですが、適度な解像度をキープしてくれるのと、ストレスが少ない点が評価のポイントです。 結構、落ちるので、GoodReader 以外に選択肢は無し。

 iBooksは、eBookと同様にサムネイルを展開するので良いのですが、いかんせん、まともな解像度で表示されるまでの時間が長すぎて使い物になりません。iBunkoHDは、いろいろと裏技を駆使して落ちないように努力されているみたいなのですが、おかげで準備が整うまでページをめくる事ができないという現象が出てしまいます。

 画像ではないPDFは、評価の対象ではありませんが、iBooksはサムネイル対応あり、iBunkoHDは左右読み方向と見開き偶奇に対応ありで、一歩抜きん出ていると言えるかもしれません。




数学本などのスキャンでは神経質に1200dpiとかでスキャンしていますが、将来的には、これぐらいの解像度が当たり前な時代になるかもしれません。それまでの繋ぎとして、どうやって低解像度のPDFを効率よく生成するか?Windows限定な方法となりますが、画像梱包で画像を展開し、リサイズ超簡単プロ!で画像解像度を%指定で落とします。最後に、画像梱包でResizeフォルダを指定してPDFを復元します。

2010/8/2 追記: モノクロ画像だとカラー画像に変換されてしまうので、圧縮後のサイズが余計に大きくなってしまう…カラーPDFにしか使えない技だった…。しかも、ScanSnapの文字傾きの訂正とかは、読み取った後の画像に対してPDF的に回転角度を指定しているだけで、画像自体には、ちっとも手を入れていない。そのため、画像にバラした後は、向きを手動で訂正しなければならない。だいたい、PDFで画像を回転するという事は、それだけPDFでの表示が遅くなるという事だ。もう読み取り速度が遅くなっても、今後は縦方向スキャンしかしないし、文字の傾き訂正機能も使わないようにしようと思う。驚いた事に、角度は90度だけでなく、数度単位で回転を指定している場合もあった。頁の余白がなくて急に写真が出現する場合は、10度程度、頁が傾いてしまう事があるが、取り出した画像には傾きは見られなかった。空白を削除するのも、やめておいた方がいいだろうと思う。レイアウトが崩れるし、後で処理に困るからだ…。いやー、イラつく…。時間なんて全然無いのに、生産消費者の道を進めとの声が聞こえてきそうである…。

 Enjoy 自炊ライフ!

2010/8/1 追記: FastPDF は、結構な頻度で落ちる。おすすめは撤回した。
2010/8/29 追記:この後、FastPDF, GoodReader, iBunkoHDのバージョンアップが行われた。FastPDF は安定度が増したように思う。iBunkoHD は、大幅改修されてオールマイティに利用できる感じになった。どれも甲乙つけ難い。ポイントだけ列挙すると、FastPDF は、見開きにした時に1頁だけズラせる事ができるので、偶奇・奇偶とどんなタイプの見開きも見れるように調整できる点が良い。GoodReader のクリッピング領域を固定しながら頁をめくる機能が、かなり重宝される。余白の多いPDFでは、これが無いと読みにくい。iBunkoHDは、欠点が見当たらなくなってしまった。

 ところで、iPad では、写真フォルダを他のアプリから閲覧できるのだが、本に対しても同じような事ができないものなのだろうか?アプリに閉じ込められた本というのは、正直、取扱い辛い

2010/9/6 追記:Bookman のバージョンが上がって、死角がほとんど無くなってしまった。自炊に関しては、正直Bookman一本で良いと思う。ウェブからダウンロードするPDF用にはGoodReader、気分でソツない iBunkoHDをチョイス。といった所で落ち着いてしまいました。

2010/11/13 追記:グレースケールの大型本は、GoodReaderで読むようにしている。とにかく、Bookman, GoodReader の2大アプリさまさまだ。

2010年7月27日火曜日

今度はwindows7が止まる

でかいファイルをドラッグドロップすると、いちいちCOM Surrogateを経由するので、メモリが足りなくなって、反応しなくなる。タスクマネージャも反応しなくなるので、何もできずに30分以上見守るしかない。カーネルは何のためにあるのか?糞だろ。
素直にファイル名だけ渡せよ、あほか?
また、強制電源オフの悪夢がはじまるのか?
Oh no! The nightmare begins again.

2010年7月25日日曜日

自炊は続く

ここんところ、スキャンに勤しみ、本と対話の日々なのだ。iPadのbook系アプリの違いも見えてきた。モノクロ1200dpi相当と言うのは、ちょっとやりすぎで、実はぼやけて見えるのもアプリのせいだと言う事がわかった。へたれなことに、Windows上でのPDFレビューも、あまり良くないようだ。ただし、これはディスプレイの環境に依存しそうである。こんなところ(ディスプレイの表現力)にもアップルのデザイン力を強く感じる。
あとで、book系アプリの特色をまとめることにしよう。同じPDFを扱っていても、こうも違うものなのかと感心します。

2010年7月17日土曜日

iPadユーザには敷居の高いfujisan

Fujisanという書籍アプリがでていて、インストールしてみたが、ログインしないと使えない。なんだこれは?速攻アンインストールしようかと思ったが、猶予を与えておくことにした。アプリの、トップページにあるfujisanのロゴがリンクになって無いのも痛い。そして、苦労してfujisanのページに行ってもアカウントの作成方法が全くもってわからないのも痛い。極めつけは、ちょい読み機能がflashなのか、iPadユーザさまお断りで救いようがない。

2010年7月15日木曜日

CentOSでutvpnserverをサービス化

 お客さんからutvpnserverを使いたいという要望があったので、サービスで自動起動できるようにする必要があった。しょうがないので書いてみた。正直シェルスクリプトを書く機会は滅多に無いので自信がない・・・。${HOGE[@]: -1} とかで、最後の文字列が取れればビューティフルなんだけど、最後のキャラクタしかとれなかったので、ループを回す事に・・・。ま、出現位置が変わっても対応できるから、こっちの方が良いだろうと納得する事にした。

#!/bin/bash
#
# utvpnd Startup script for the utvpn Server
#

### BEGIN INIT INFO
# chkconfig: 345 88 16
# Default-Start: 3 5
# Deafult-Stop: 0 1 2 6
# Required-Start: $network $syslog sshd
# Required-Stop:
# description: utvpn server.
# processname: utvpnserver
# pidfile: -------------------- /var/run/utvpn.pid
### END INIT INFO

UTVPNSETUP=/usr/bin/utvpnserver

case "$1" in
start)
${UTVPNSETUP} start

;;

status)
PLIST=`ps -C utvpnserver | tail -n 1`
running=false
for i in ${PLIST}
do
if [ "utvpnserver" = $i ]; then
running=true
fi
done
if [ $running = true ]; then
echo "utvpnserver is running"
else
echo "tuvpnserver is stopped"
fi
;;

stop)
${UTVPNSETUP} stop
;;
*)
echo "Usage: /etc/init.d/utvpnd {start|stop|status}"
exit 1
;;
esac

exit 0

こいつを、/etc/init.d/ 下にコピーして

$ chmod 755 /etc/init.d/utvpnd
$ chcon system_u:object_r:initrc_exec_t /etc/init.d/utvpnd
$ chkconfig --add utvpnd
$ chkconfig utvpnd on

といったあたりで、OKだろう。動作確認は

$ service utvpnd start
$ service utvpnd status
$ service utvpnd stop
$ service utvpnd status

って感じです。

2010年7月11日日曜日

数学本のスキャン

 いやー、苦痛です。モノクロ600dpi相当でスキャンして、これはいけてると思ってました。ところが、いざiPadで読んでみると、添字の添字やら、ギリシャ文字系μ等の記号がわからない…。結局、モノクロ1200dpi相当でスキャンするよりありません。ものすごい時間がかかります。
 1200dpiで読もうと思ったら、横向きにスキャンしないと時間がかかってしょうがありません。横向きにスキャンしたら、裏表の向きが反対になってしまうんです。90度回転しても、奇数ページと偶数ページで逆向きになってしまいます。白紙ページを削除する…なんてやってたら、偶奇入り乱れるので、機械的に回転処理ができません。漫画をスキャンする時は、向きがグチャグチャになるので、スキャンした本の自動回転をオフにしていました。しかし、数学本を読む時は、横向きで、自動回転をオンにして1200dpiのモノクロでスキャンしてます。

2010年7月10日土曜日

自炊が気持ちイイ

 いやー、本の自炊、いいです。電子化してみると、いろんな事が見えてきました。

 まず、スキャンすべきか?せざるべきか?それが問題だ!
本を切り刻むという事は、元に戻せません。また、中途半端にスキャンしてから、切り刻んだ本を捨てると、再スキャンができません。例えば、微妙に写真の混ざっている本なんかだと、モノクロ2値スキャンではなく、グレースケールにすべきか?400dpi相当で留めておくべきか?600dpi相当まで上げるべきか?選択子は山のようにあって、決断を迫られます。そうやって、スキャンする本の値踏みを迫られる訳です。こうして、ああ、俺は、この本にこれぐらいの愛着を持っていたんだ…と、スキャンする過程で気付かされます。

 本棚から本を探して引っ張り出すコストの高さに愕然とする。
スキャンした本なんて読まないよー。と思っている方も多い事だと思います。しかし、逆でした。恐らく、この逆転現象が現れるのは、好きな部類の本だと思います。まだ、スキャンはじめて日が浅いので、自分でも良くわかっていないところがあります。例えば、HUNTERxHUNTER…正直、本棚に眠っていました。本来、全巻読もうと思ったら、両手に抱えて本を運んで山積みし、読まなければならないところ。それが、iPadの中に全部収まってしまうと、サクッと読めてしまいます。そして、拷問のように重たく大きい技術書…。えーっ?サクッと取り出せてしまいます。気が向けば、すぐに見れる。思い立ったが吉日です。これはほんとに敷居が低い。

 スペースが空いて楽しい
スキャンした後に、広がっていくスペース。いやー、もう、Space, the final frontiea... っす。楽しい。

2010年7月8日木曜日

activescaffold controller is nested call?

コントローラが、nested つまり、親コントローラの入れ子コントローラとして動作しているかどうかを判定したい…。こんな簡単そうな事が、意外と難しい。なんでもかんでも隠蔽しすぎているからだ。それだけ、activescaffold の完成度が高いとも言えるのだが…。

answer


<% if params[:parent_model] != nil -%>
...
<% end -%>


もちろん、コントローラ内でも使えます。

自炊開始

ついに裁断機が来ました!さっそくスキャン開始!手始めに、どうでもよさそうなドラッガー本を練習台にしました。縦にスキャンした方が、紙詰まりしにくい感じです。
続いてHUNTERxHUNTERをスキャン。紙質がしょぼいので、白が多いページは、裏が薄らと写りこんでいます。でも、上々!一冊五分ちょいでスキャンできました。
IPad のアプリですが、Bookman が熱いです。チェックだ!
そうそう、iPadのアプリを作成する方、ファイル数が多いと同期に時間がかかるので、少なくする努力をして下さい。でないと、せっかくのアプリも台無しです。そういうアプリはユーザに削除される可能性があります。

2010年7月6日火曜日

デジタル化は、ババか?

ディズニーやら過去の作品の著作権が切れて、ワンコインやツーコインで、DVDが売られていたりします。宝島社から、バグズバニーが、出ていて、買いました。だいぶ前の話です。ふと、DVDを眺めていると、このDVDは、無断で上映したり複製することができません…と、書いてあり混乱しました。著作権が切れてるから、こうして安価で売っているのでは?
しばらく考えて、字幕に著作権でもあるのだろう…という結論に達しました。何という、商魂たくましい戦略!なけてきました。
理想書店も、いっこうに品揃えが増える気配がありません。出版社に期待した自分が馬鹿でした。自分の業界ソフトウエア産業同用の道を辿るリスクを冒す必要は無いでしょう。せいぜいババをつかまないよう頑張ってほしいものです。
ブックスキャナと裁断機買いました。現在、裁断機の到着まちです。試しで少年ジャンプのブリーチだけ、スキャンしてみました。ハサミで適当にフリーハンドで切ったのに、感動的なスキャン速度と仕上りでした。ふと、毎号週刊誌を買っている人は、コミックの単行本を買わなくても良い気がしてきました。買いのがした分だけ部分買いするとか?恐ろしい…。デジタル化は、やっぱ怖いです。

追記:もしかしたら、著作権は、まだ切れていなくて、切れる寸前なのかもしれない…。