/ 最近 .rdf 追記 設定 本棚

脳log[2011-11-09~]



2011年11月09日 (水) もうずっと(※最初に認識したのは『ピエタ』だから今年の二月)アマゾンは発売直後の新刊を結構な頻度で「出品者から……」という状態におくようになってるし、このまえは Wishlistの 1ページ(※前から 2,3ページ目)のうち、納期が表示されてるのが 1冊だけであとは全部が「出品者から……」だった。その前後のページもほぼ同じ。サイトの使い勝手はいまも一番だけど、在庫が薄すぎる。アマゾンはもう自ら本を売るのはやめたもんだと見切りをつけたよ。電子書籍を Sony Reader向けにも配信するなら状況は一変するが、いまはまだこれ(の openを location.href=に変えたもの)を使ってる>アマゾンの URLに含まれる ISBNっぽい数字をジュンク堂で検索するブックマークレット。(20101125p01)■■■これまでであれば「2~4週間で……」と表示していたところが、「在庫あり」と「出品者から……」の二択になってしまうような環境の変化でもあったんだろうか。いずれにしろアマゾンで時価の本を個人売買せずともよそのオンライン書店には在庫があるわけだが。■■■@2017-05-08 難しくて全体は理解できないけど。「新刊については改善しつつある  問題がここ1年で飛躍的に改善したのが新刊である。新刊については、情報が出てから発売までに時間があるので、アマゾンの遅い発注判断でも、じゅうぶんな量の入手が可能になる。そのうえ、アマゾンも「新刊の追っかけ発注は入手しにくい」ということを学習したのか、発注量も多くなった。  新刊委託配本をしない出版社でも、取次とコミュニケーションを密にとれば発売即品切れを回避しやすくなった。  とはいえ、発注タイミングはやはり遅い。「発売前重版」になるような本がアマゾンで入手できず、一般書店には平積みになるようなことは多い。それは、書店としてのアマゾンの能力が低いということの証左だ。発売4週間前に発注しても入手できない個人書店の事情とは問題のレベルが違う。」(アマゾンの「バックオーダー発注」廃止は、正味戦争の宣戦布告である)■ブコメの反応はわりと辛辣だけど、俺はそれに与しない。消費者全体にくらべて本の読者は圧倒的に少ないし、目立つ声が目指すところは俺のとはたぶん違う。

最終更新: 2017-05-08T10:18+0900

[][javascript] アマゾンの URLに含まれる ISBNっぽい数字を紀伊國屋書店BookWebで電子書籍検索するブックマークレット。

void function() {
	var isbn = (location.href.match(/\b[0-9]{9}[0-9X]\b/)||[])[0];
	if (isbn) {
		var url = "http://bookweb.kinokuniya.co.jp/guest/cgi-bin/ebooksea.cgi?W-ISBN="+ isbn;
		location.href = url;
	}
}();
javascript:void%20function%28%29%7Bvar%20isbn%3D%28location.href.match%28%2F%5Cb%5B0-9%5D%7B9%7D%5B0-9X%5D%5Cb%2F%29%7C%7C%5B%5D%29%5B0%5D%3Bif%28isbn%29%7Bvar%20url%3D%22http%3A%2F%2Fbookweb.kinokuniya.co.jp%2Fguest%2Fcgi-bin%2Febooksea.cgi%3FW-ISBN%3D%22%2Bisbn%3Blocation.href%3Durl%3B%7D%7D%28%29%3B

「該当するデータがありません。」率が高すぎるだろうなあ。ブックマークツールバーのボタンをクリックするのがだんだん億劫になるだろうレベルで。

自動で背後で検索を実行してアマゾンの購入ボタンの下に BookWebへのリンクを挿入することも Firefoxの仕組みでできるんだろうけど、けど、リンクのプリフェッチと同じくなんとなく嫌だな。


2011年11月08日 (火) Sony Reader + Calibreのおかげで、ときどきの雑記帖さんところの元ネタをすでに読んでいるということが何度か。いいことだ。翻訳に恵まれた怠惰な日本人に対して読書「専用」端末が持つ効用である。でーも、その元記事は Readerで<pre>の中のコード片が折り返しもスクロールもできなくて後ろの方が全然読めなかったのだった。Calibreが作成する定期購読はリフローできるはずの ePubフォーマットだから Calibreの方で対応できることだと思う。


2011年11月07日 (月) 空気清浄機(MC75KJ7-W)。夏前に掃除したからと油断していたが、なんの気なしに開けてみたらフィルタにほこりがみっしり堆積していた。本をいっぱいバラしたからだろうなあ(風量を標準に固定して作業開始)。これを掃除機で吸い込んでごみ箱に捨てるのが快感なのである。耳掃除と一緒で。普段空気のような空気清浄機が仕事してる証でもある。設置してから明らかに PCの前面のメッシュ部分にはりつく猫の毛と底面の吸気口フィルタの汚れが減った。


2011年11月06日 (日) [SonyReader] コレクションを表示したり、コレクションからアイテムを削除したり、コレクションにアイテムを追加したりするだけですぐにハングして、リセットするとコレクションが分裂する PRS-650. 勝手に再起動して勝手に分裂したこともある。再起動したのはコレクションの中だけど、直前に読み終わった本のページ履歴がまだ更新されてなかった。コレクションが 3倍に分裂したところで Readerによるコレクションの管理はあきらめた。eBook Transfer for Reader ver.2.0(2011-10-19)による管理はメモリーカードの情報を読み出すのに 5時間かかりそうだったので完了率 40%(2時間待ち)であきらめた(※microUSBのコネクタに手をぶつけたりなんかしたら接続が途切れてやり直しになるんだぜ。USB1.1での接続になったり、このUSB機器は利用できないとか出て差し直しなんてしょっちゅう)。PDFファイルのリストを作り(※新着お知らせ機能付き)、ファイルごとにタグ(コレクション)を表すフラグをくっつけ、/Sony Reader/database/cache.xml内の <text id= sourceid= path= mime=/>と<item id=""/>を管理すれば OK. idは適当な連番。sourceidはわからんから既存のと同じ数字。PCのテキストファイルで管理するこの安心感と同期の速さはすばらしい。脆弱な Readerの調子を伺いながら作成した何百冊にもなるコレクションをもう三度も Readerに破壊されてるから。次はプリセットのコレクション「未読の書籍」を使えるものにしたい。自炊した本とマンガが元の PDF 800冊超の 9割以上は既読なのに全部が未読扱いだ。これは /Sony Reader/database/cacheExt.xmlの<text>タグに opened="true"をつけるだけっぽいから一回だけ手作業でやればいいだろう(一冊一冊確認しながら「<text path="([^"]+)"(/?)>」を「<text path="$1" opened="true"$2>」に置換)。


2011年11月05日 (土) かち。だいたい 4.5h/23kmでした。淡々と。暑いのでゆっくりと。


2011年11月03日 (木) [SonyReader] PRS-650. 評判通り頻繁にハングするようになってきたぞ。Readerがハングするから PCでコレクションを管理すべく初めて eBook Transfer for Readerをインストールして起動してみたが「SD メモリーカード 読み込み中 ○%」が 1時間で 20%も増加しない。5時間待ち?自動バックアップはオフなのに 32GB全部読もうとしてるの?それにしても遅すぎるが。eBookTransfer.exeの CPU使用率が 1コアフルロード(33%)+1,2%だから I/O待ちが原因じゃない?どんな高度な処理を行ってるんざんしょ。全く機能してないんだからこれはバグだよ。仕様を変更してでも解決すべき問題。発売からこれまで何をやってたんだ。馬鹿な機械や馬鹿なソフトウェアに対しては沸点が低くなることを自覚している。人間の足を引っ張るようでは存在価値などない。■■■テキストファイルにファイル名とタグ(コレクション名)の対応を記録して XMLファイルを直接操作するのが一番現実的じゃないかな。これを XMLファイルを採用したことの副次的な利点だとは言わないよ。SQLiteだってコマンドラインクライアントで SQLを実行できるんだから。■■■ハングしたからとリセットするとコレクションが分裂することがある。なくならないだけマシだけど、コレクションを表示していただけでこの様だよ!


2011年11月02日 (水) [SonyReader] 「Recently Opened on Homescreen Hack for T1」SQLite DBにトリガーを勝手に追加して、ホーム画面に最近読んだ 3冊を表示するハック。いいねいいねー。これ(20111101p01)と違って Readerが適当なときに自ら実行してくれるんだから。PRS-T1を選ぶ理由になる。スマートコレクションとか期待しちゃうなあ。やりすぎると電力消費とレスポンス低下が心配だけど。


2011年11月01日 (火) ひょっとして、この本棚を PRS-T1向けに無駄を削って file:///...pdfなリンクを表示するようにしたら iPodっぽいブラウズ画面として使えるのではなかろうか。(ビューアが開かずにダウンロードが始まったりしなければ)■■■タグとタググループも導入したいな。ふたつの関係は集英社と出版社と同じ。

最終更新: 2012-06-05T20:30+0900

[SonyReader] 新たに自炊して転送するまでやばすぎる本*がホーム画面に並ぶ羽目になったので

Readerに接続したメモリーカードのルートにこのスクリプトをコピーして実行するとそのメモリーカード内で最後に開いた 3冊の本がホーム画面に並ぶという、以前書いてたあれをすることに。並べ替えが PC接続時に限られるのがいまいちでその気はなかったのだけど。

方法は、ファイルの最終更新年を未来のものに書き換えてる。本来の更新年月日を最終アクセス年月日として保存してるのでアクセス日の記録は失われる。


 @2012-01-01

今使ってる版はこれ($3-touch_last3_opened_books.20120101.rb)。MemoryStickと SDカードの二枚差しになったのでメモリーカードドライブのルートで実行する代わりにドライブ文字をハードコーディングしてる。ところで、Rubyの 2038年問題って何?初耳。このスクリプトの「MAGIC_YEAR = 2035..2037」って部分と明らかに関係があるんだけど。

Bing検索でトップのスライドを読んだら Ruby 1.9.2で Timeが大幅にパワーアップしてるらしい。2038年以降だけでなく以前に書いた(組み込みの Timeが UTCと localtimeしか扱わないのがもったいない。任意のオフセットに基づいた日時を出力したいだけだから、DateTimeは牛刀な印象がある)、任意の時差も扱えそう。そもそも Timeの制約って OSの制約がそのまま見えてたってわけだったのか。

 @2012-06-05

今使ってる版はこれ。

$3-touch_last3_opened_books.20120605.rb (2.1KiB)

オプションを新設。--setオプションで最近読んだ三冊の更新日時を未来のものにセット。--resetオプションで本来の更新日時を復元。オプションなしで従来通り reset&set。

分離できるようにした理由は、更新日時の復元と更新の間に、robocopyで Readerと自炊ファイルの同期を行いたかったから。2035(,2036,2037)年のタイムスタンプがセットされたままだと Readerにある方が新しいと誤認されて転送されなかったりする。

それと、連続して --setを行うと本来の更新日時が失われる不具合を修正。何度 --resetして --setして --setしても同じ結果になるように。

* 作業した順番が悪かったせいで『4871826090』だとか『4871826198』だとかが。


2011年10月30日 (日) これほど賛同できない言説も珍しい。「池田信夫 blog : TPP参加による消費者の利益は生産者の損失より大きい - ライブドアブログ」 背後に見える無数の釣り針を誰かことごとくへし折ってくれないかな。意図的なんだろうな。Globalな(この場合は対米国境をまたいだ)お金の流れが説明されてない。貨幣ばっかり集めても食えないし、それすらも逃げていくように思えるというのに。国の根幹を明け渡したら足下を見られ続けるだけじゃないの? 利益はその後でいい。日本で国家を主体において考えてるのは誰?


2011年10月29日 (土) [BAD BOY] (タイトル欄の空きがないのでここになったが) 27日に(拡大移転してきた)自転車屋にメンテナンスを依頼してきた。ここのところアウター×ローでチェーンが内へ落ちるせいで発進が危険で踏み込めなかった。これは 4月末と同じ症状だ。そのときはチェーンとスプロケットを換えたのだった。伸び伸びのチェーンで 16000km(4月の数字)まで走り続けたせいでとうとうチェーンリングもダメにしたのかと覚悟して行ったが交換はしないという。クランクを外さなければいけないが外せないから持ち込んだのに拍子抜けだ。直ればいいのだけど、調整だけで直るものか大いに疑ってる。落ちるようになってからリアディレイラーの L側のネジを締めた(=ロー側への可動域を狭めたつもり)んだけど変わりなかったし。それとも足りなかったのか?全く使用していないフロントディレイラーか?■預けた帰りは徒歩一時間ちょっと。Rio SU30を引っ張り出してきて聞いていたがアルバムを一枚再生しきる前に力尽きた。iPodも同じ程度で切れるのを知ってたので軽い方を持って行っていたわけだ。内蔵のリチウムポリマー電池はこれだからおもちゃにしか使えない。

最終更新: 2012-11-03T16:19+0900

[SonyReader] PRS-T1の説明書(PDF)を読んで改善した点を挙げよう。

主観的な評価なのでどうでもいいと無視したもの、(PRS-650にて)未使用の機能につき評価不可能なものは含まれておりません。

  • 軽い。(が、これは質感を犠牲にしている。携帯するものなのだから恥ずかしいものは持てない。俺は旧型と新型を比較して(※残念ながら重さは伝わらない。それは質感も同じだけど)旧型を買った。"Function is Beauty"は好きだが実用一辺倒はダメ)
  • メモリーカードスロットに蓋がある。
  • 充電時間短縮&持続時間延長。
  • PCに接続したときにマスストレージモードと充電モードが選べる。
  • 戻るためのハードウェアボタンがある。
  • ホーム画面でメニューボタン(旧OPTIONSボタン)に役割がある。(5秒間時刻を表示)T1の説明書にこう書いてあったから改善点だと思ったが逆で、PRS-650だと OPTIONSボタンを押したらいつでも(メニューとともに)時刻が表示されていたものが、本を閉じてホーム画面に移動しないと表示されなくなったというのが実際のところ。PRS-650で本を読んでると頭を上げて時計を見るかわりに時刻を表示させることが結構あるのでこれは改悪。
  • 検索やリスト-サムネイル表示の切り替えなどコンテクストメニュー内にあったアイテムの一部がアイコン化して常駐してる。(なんでもアイコン化は好きじゃないけど 1クリックの節約は意味がある)
  • ページ移動パネルに 10ページ移動ボタンがある。(シリーズものを結合した何千ページもある PDFを読んでるとスライダーでちょっと移動するのが難しい。PRS-650の連続ページめくりは PRS-T1より倍くらい速いらしいがそれでもゆっくりだ。んん?これは書籍一覧画面の、ページ移動パネルなのか。A-Zあ-ん漢字を等間隔に配置したスクロールバーはなくなっちゃった?それだけじゃなく先頭ページへの移動もしやすいように考えられた優れものだったんだけど)
  • ページ移動パネル(こっちがたぶん書籍内移動)に「目次(しおり)」「移動履歴」へのショートカットボタンがある。
  • コンテンツごとに有効な余白、ページモード、明るさ、コントラストの設定。
  • 国語辞典(大辞林)搭載。

 (悪い意味で)変わらなかった点。(てきとーに。思いついたものだけ)

  • いま開いている本をコレクションに追加できない。(たぶん。中身も見ずに分類できるものばかりとは限らないし、タイミング的にもこれ以上ないくらい操作の対象が明白なのに)

 退化した点。

  • レッドモデルの赤色。(新型の実物は見てないけど、PRS-650の赤色は画像の通りで、深みのあるよいものだった)
  • 行き場のないスタイラス。
  • 自動スリープ(シャットダウン)をオフにできない。
  • 底辺が丸い?カバーなしで安定して立てかけられない?
  • ホーム画面 2ページ目(!)へ追いやられた定期購読アイテム。

 付加価値(どちらも PRS-650用)。

関係ないけど、Calibreが取得したニュースを転送する前に「デバイスから本の情報リストを取得」するんだけど、それが完了するまでに充電が終わってしまった。約一時間。今度は忘れずに接続前にメモリーカードを抜いておこう。問題ないかな?

Calibreは空のコレクションを勝手に削除する。


2011年10月28日 (金) Firefoxの今に始まったことではないタイミングバグ。だけど本日二回目。2タブ開いた状態で Ctrl+Wでタブを閉じようとするとなぜかウィンドウごと消える。再起動しても直近のセッションは復元されず、はるか以前のポップアップウィンドウ(二番目のウィンドウということでメインウィンドウと別に管理されてるのかも)が復元される。このウィンドウが消えるバグは以前からあって、タブが切り替わる瞬間(Ctrl+Tabや Ctrl+W直後。アクティブなタブが曖昧な瞬間)に Ctrl+Wを押すと起こりやすい印象がある、めずらしくない現象なんだけど、最近になって変わったのは、復元されるセッションが少し古いものではなく、はるか以前の別窓のものになったこと。ウィンドウの大きさもポップアップウィンドウと同じ小さいものになるのでたんび元に戻すのが面倒くさい。面倒くさい。

最終更新: 2011-10-29T21:40+0900

[ProjectEuler] Problem 333

 Problem 333

何時間もかかるこれがどうやったら速くなるでしょうか?

いまは可能な組み合わせを全て試してみて、できあがった数字をカウントしてる。その後で素数を順番に辿って生成カウントが 1のものを足し合わせたものが答え。上限が 10倍になるごとにどえらく計算量が増える。かけ算ならまだしも足し算の組み合わせに有効な考え方を自分が全く持ち合わせていないことがこれまでの問題からも何となくわかってる。どうすんの?

# PE333
require 'mathn' # Primeが使いたいだけなのに。グローバルフラグは悪。
UPPERBOUND = 100_0000
EXP3_UPPERBOUND = (Math.log(UPPERBOUND)/Math.log(3)).floor+1
EXP2_UPPERBOUND = (Math.log(UPPERBOUND)/Math.log(2)).floor+1

#  ×  2^0 2^1 2^2 2^3 2^4 2^5 2^19
# 3^0  1   2   4   8  16  32  524288
# 3^1  3   6  12  24  48  96
# 3^2  9  18  36  72
# 3^3 27  54
# 3^4 81
# 3^5
# 3^12 531441

primes = Hash.new(0)
q = []
sum_of_q = lambda{
	sum = 0
	last_exp3 = EXP3_UPPERBOUND
	q.each_with_index{|exp3,exp2|
		next if exp3 == last_exp3
		sum += (1<<exp2) * 3**exp3
		last_exp3 = exp3
	}
	return sum
}
fill_q = lambda{
	q.fill(q.last||EXP3_UPPERBOUND, q.length, EXP2_UPPERBOUND-q.length);
}
fill_q.call
until q.empty?
	exp2, pow2 = q.length-1, 1<<(q.length-1)

	next q.pop if q[exp2] == 0
	q[exp2], pow3 = q[exp2]-1, 3**(q[exp2]-1)
	sum = sum_of_q.call
	q[exp2], pow3, sum = q[exp2]-1, pow3/3, sum-(2*pow2*pow3/3) while 0 <= q[exp2] and UPPERBOUND <= sum
	next q.pop if q[exp2] < 0

	primes[sum_of_q.call] += 1
	fill_q.call
end

sum = 0
Prime.new.each{|pr|
	break if UPPERBOUND <= pr
	sum += pr if primes[pr] == 1
}
p sum
p Process.times #=> <struct Struct::Tms utime=25990.64, stime=150.806, cutime=0.0, cstime=0.0>

2011年10月27日 (木) [SonyReader] 一週間くらいで ChainLPによる JPEGフォルダの PDF化が完了。自炊データをすべて転送すると 32GBのメモリーカードの使用率が 88%。シリーズものは結合したので 550冊弱。気付いたのだけど未読の本を自炊して Readerで読む踏ん切りがまだついていなかった。最初から電子書籍を買うという選択も同様に(※こちらは電子書籍のアマゾンが存在してないことが一番の理由だが)。紙束を模倣するだけではダメで、紙を凌駕するメリットが欲しい。既読の本全て V.S. Sony Readerは Readerの圧勝だけど、いま読んでる本一冊 V.S. Readerは紙本の勝ち。自炊して Readerに「閉じ込める」ことにためらいを感じる。これは多デバイス展開を期待してるのではなくて、結局、古い習慣が体から抜けてないというだけかもしれないし、お風呂で読むための雑誌や本が必要だからというのも案外ウェイトがあるかも。■■■俺はいまでも 3G iPod(※それ以降は知らない)のブラウズ方法が至高だと思ってる。ジャンルからでもアーティストからでもアルバムからでも辿ることができ、その下層の曲を一覧・再生することももう一段(二段)フィルタリングすることもできる。単純なフォルダわけとは違う、その時々で選べる動的なツリー。同じ音楽ファイルとはいえ対象ごとに見つけ出すのに最適な絞り込み条件は異なる。ヒトの記憶ってそういうもんだ。それを検索に頼らず自然に行えるようにしたのが iPod(iTunes). この管理機能なくしては 512MBのシリコンオーディオプレイヤー時代に 15GBの HDDをひっさげて現れても、無駄にでかくてかえって使いにくいと文句の一つも口にしていただろう。Readerは 32GBのメモリーカードを扱う準備が全然できていない。そこにこそ Readerの明白なアドバンテージが存在してるというのに。


2011年10月23日 (日) 貪欲だ……。「○○○をショッピングカートに追加されたお客様におすすめします」