最終更新: 2009-09-25T21:30+0900
けばけばしい色づかいのカバーと紙面を埋め尽くすスクリーンショットが満載のパソコン入門書(多分に想像混じり)を置くばかりでない書店が近所にできた(ゲーデルエッシャーバッハがあった!)。というのが、1年半以上ウィッシュリストに埋もれていた本 と、パタヘネとヘネパタの違いも分からないまま、カラー印刷、紙質の良さ、遺跡の写真、JVMや GCCといったリアルな単語、教科書チックな雰囲気*を持った本 を衝動買いした理由。昨日アマゾンで Boost本とかも 2冊買ったから、食費が、が、が。
* 帯に「世界最高の教科書が全面改定。……」って書いてある。正真正銘教科書だった。
最終更新: 2019-12-01T02:10+0900
既読は 8/100作品でした。しょぼっ。まあ、SFというラベルは読む理由にも読まない理由にもなってないからね。少ないからコピるのも余裕。
マイクル クライトン『アンドロメダ・ストレイン』も 100冊の中にまぜてあげて欲しかった。
Regular Expression Cookbook
Oreilly & Associates Inc
¥ 4,073
「XRegExp: JavaScript regex library」は、「SyntaxHighlighter(Ver.2.0)」で使われていたので知った。XRegExpの作者が、本の著者の一人、Steven Levithan。
XRegExp(Ver.0.6.1)が、Firefox 2,3、Internet Explorer 5.5-8β1、Safari 3.1、Opera 9.27の JavaScriptに付け加えて利用可能にする正規表現の機能は
後方参照も可。String.replace()での使用も可。
「.」が改行にもマッチ。
ほとんどの空白を無意味なものにしたり(=パターンを自由にインデントできる)、行コメント(#から改行まで)を利用可能にする。
(?#ここにコメント)
こんなの。\p{L}, \p{M}, \p{N}, \p{InHiragana}, \p{InKatakana}。否定は大文字のPで \P{}。
文字集合の中で使えないという制限があるが、若干の工夫でなんとかなる。
使い所が限定されていそうだったり、使い方が難しそうな機能として
(独り言) 名前付きキャプチャグループをサポートしたなら、そのキャプチャ結果をスタックして、そこにパターンを繰り返し適用する書き方を用意することで、matchRecursive()なんてスペシャルメソッドは不要にできるのでは? <何を言ってるのか自分でわかってないよ
XRegExpのコンストラクタに「脳log[2008-01-11-p01] 鬼車すごい。正規表現で再帰ができる。」で書いたようなパターン文字列を渡して、再帰を認識するマッチングを行いたいです。
正規表現に関連するいくつかのメソッドを上書きし、ブラウザ間の差異を吸収するとともに、仕様通りの動作に統一したりもする。
IEなどが、幅0の文字にマッチしたときに lastIndexを不当にインクリメントするのを修正。
(独り言) limitを指定したときに戻ってくる配列の要素数が limitと一致しない。XRegExpのバグ? もちろん separatorにキャプチャグループは使っていない。
例えば再帰の深さの上限を 10や 20と決めてしまって、XRegExpのコンストラクタでごにょごにょパターン文字列を展開してみればどうだろう。JavaScriptで正規表現を一から実装しようというプロジェクトではないから、自ずと制限が定まってしまうのだけど、上限付きでもそれが 20もあれば十分という気がする。
驚いた。大部分がライブラリの機能紹介という退屈な(<作者本人が一番よく知っているから)文章に紛れ込んだバグ報告(とも呼べそうにないもの)を不自由な Google翻訳から見つけ出すとは。
1.0のソースも眺めてみたいけれど巨大な変更履歴にちょっと後込み。そのうちね。
この本は私の本の中では、少々毛色の変わった本でありまして、何かというなら、これまでの「自転車って愉しいよ」「こんな発見があるよ」「こんなツーリングって面白いよ」「こんなテクニックもあるよ」というような趣味的な自転車話をまるっきり書いてない。全編通じて「自転車はこうあるべき」という、行政への、またインフラ整備の、さらに法整備に関しての注文だけに絞りました。
という本を書いた著者が
日本の自転車に関わる行政は、即刻「歩道、車道を問わず、左側通行の厳守」を実行するべきでしょう。
実は、私がこの本を書いた理由の半分程度は、この「左側通行」のメリットを提示することなのです。
とまでいう「左側通行」(注:歩道の左側部分という意味はありません)。俺は 99%の走行区間で実践している。( ̄^ ̄)エヘン。残り 1%は、目的地が国道1号線の対向車線側にあるので、直前の交差点で右側に渡って歩道を走っているから。 著者はそのような場合、右側を(歩行者として)押して歩くか、一旦行き過ぎてからUターンするか、目的地の位置によってどちらかを選べと回答を与えている(104-105ページ)。 俺の場合、200Mの徒歩か、600Mの自転車での大回りかの選択。 今の俺がやっている、右側の歩道を自転車で走行するようなショートカットが、許されないような、後ろめたく感じさせるような、人の目が生まれたらいいと思う。 そんな時には「無法な自転車がルールを守る。我が物顔の自動車が道を譲る。」なんて声高に主張するようなことではない当たり前のことになっているだろう。
本書の内容は、ヨーロッパの自転車先進国の事例、後進国(でも推進しようという意志のある国)の例、日本の自転車に関する法律、現状、理想、手始めにするべきこと、行政の成功例、失敗例といったところ。 外国の事例や日本各地の自転車行政については、日常、自転車に乗っているだけでは見えてこないことで大いに参考になった。
1 秋山瑞人 2 桜庭一樹 2 高殿円 4 野村美月 5 葉山透 6 米澤穂信 7 清水マリコ 8 西尾維新 9 乙一 10 古橋秀之 10 佐々原史緒 10 友桐夏 13 竹宮ゆゆこ 13 森橋ビンゴ 15 今野緒雪 16 十文字青 16 中村九郎 16 海猫沢めろん 19 冲方丁 20 谷川流 21 長谷敏司 22 中村九郎 23 片山憲太郎 23 支倉凍砂 25 桜坂洋 25 一柳凪 27 田中ロミオ 28 山形石雄 29 海原零 29 おかゆまさき 31 加地尚武 32 貴子潤一郎 32 細音啓 34 紅玉いづき 35 アサウラ 36 壁井ユカコ 37 藤原祐 37 海羽超史郎 37 豪屋大介 40 瀬尾つかさ 40 木村航 42 小林めぐみ 43 ヤマグチノボル 43 桑島由一 45 平坂読 46 竹岡葉月 47 有川浩 47 甲田学人
読んだことがあるのがだいたいこの順位までの作者。(何人か下位にこぼれているし、蒼穹の女神を評価している すずきあきら はリストにも入っていない)
桑島由一の順位が低いがこの人の名前は「桑島由一 <> ヤマグチノボル」の一回しか目にしていない。作家に明確な順位付けなんかしていないから、名前が出てくるたびに評価は上下するもの。一度しか名前が登場しないのでは、例えばこのばあい、桑島由一の評価は完全にヤマグチノボルに依存しているがそれは不正確。ましてこの二人の場合、引き分けを選ぶことしかできませんでしたよ。
<追記>そうだ。推移律。作家をソートするときに推移律が成り立つことを期待してはいけない。作家を評価する軸は作家の数だけあったっておかしくないし、それらの軸ごとに一定の重みを付けて評価をひとつの数値に落とし込むなんて不可能。なんて、今回の試みを真っ向から否定する発言。</追記>
ほんとうにソートしているだけだから選んでいる本人には結果に全く意外性がない。退屈。結果を見ると「高く評価している作品を」「何作も」出している人の評価が高いのがわかるが、そのように選んだのだから自分にとっては当然の結果。
2、3回ダブルクリックしてしまって選択を誤ったが、海羽超史郎という人の著作を読んだことはありません。
最終更新: 2010-03-22T05:44+0900
著者は ActiveScriptRubyの arton氏。
この本が出た当時、Mysterious SyndromeWindows Scripting Host Laboratoryの管理人むたぐち氏が、言語は Rubyであるが、COMや WSHの話題は VBScriptや JScriptと共通だし、他にこんなに突っ込んだ類書もないので、と(言葉と内容は全然違うが)自身の掲示板でおすすめされていたのをずっと覚えている。
タイミングを逸していただけなのだ。
Rubyの名前を初めて目にしたのもこの時だったかもしれない。(「何か」(当時)の名前を目にしたのもこの掲示板が……。美耳いいよね)
あくまで目にしていただけで、初めての CGIプログラムはサンプルの多い Perlで書いたし、すぐに嫌気がさして代わりの言語を探したときに Rubyを"再"発見している。そのときに、WSHに親しんでいたことと ActiveScriptRubyの存在が Ruby採用のきっかけになった、というのは多分にありそう。
思い出深い一冊ということ。この本を通して、気付かないまま Rubyとすれ違っていたのだから。
14日に「新刊のリストが手に入れば自分でフィルタリングするが」と書いたのを受けて、Amazon E-Commerce Serviceの 2007-06-13版のドキュメントを眺めてみた。
特定の BrowseNodeに属するニューリリースを取得することが可能。Booksという BrowseNodeも存在するので、本のニューリリースを取得できる。但し US locale限定。JP localeで使用できるようになれば本命。
検索条件を一つ以上与えないといけないので、BrowseNode=465610 という条件を加える。465610は JP localeで Booksを表す BrowseNodeId。(但し BrowseNodeInfoで得られる、この BrowseNodeIdの Nameは「ジャンル別」となっている。HTML表示のためだろう)
これはまあまあ、Amazonがどれくらいの数のクエリを許してくれるかを度外視した上で、成功した。ドキュメントには ItemPageパラメータは 1-400だと書かれていて、1ページ目の 2009-01発売の本から始まって、400ページ目までいってもまだ 2007-07発売の本が続いてるから、直近の新刊は取得できないかと思ったが、実際には ItemPageパラメータに上限は設けられていないようで、400ページ目以降も問題なく取得できた。
追記 エラーメッセージによると有効な値は 1から3200までだって。実際に 3300ページ目は取得できなかった。
追記:2007-09-10 9月からエラーメッセージでも 1から400までが有効だと言われた。実際に 3200ページ目は取得できなくなっている。ドキュメント通りになってしまった。
但し、この方法で取得できない本があった。BrowseNodeが全ての本に設定されてるわけじゃないものね。この本は「ジャンル別」(BrowseNodeId=465610)ではなく「出版社別」の BrowseNodeにしか属していない。どの BrowseNodeにも属していない本だってあるだろう。
BrowseNodeに依存する案1と案2では漏れがでることがわかった。
これは「author」「ISBN」「keyword」「language」「pubdate」「publisher」「subject」「title」というキーワードと「not」「and」「or」「:」「()」「""」「*」という構文要素からなる複雑な検索が行える。例えば、Power=author:"米澤 穂信" なら著者(Authorや Creator要素。Roleは関係なさそう)に「米澤 穂信」を含む本が取得できる。これで Power=pubdate:2007-07*を検索してやろうというわけだ。
結果は、先のリンクをクリックすればわかるけど「リクエストに該当する結果がありません。」とのつれないお答え。Power=pubdate:2007-07や Power=pubdate:2007-07-23でもダメなところを見ると、ドキュメントでは気付かなかったけど、pubdateキーワードがサポートされてないんじゃなかろうか。(US localeではもちろんサポートされてるだろう)。ガックリ。
コミックは比較的早め(それでも 1〜2週間前)に登録されるが、文庫は前日から数日前が多い。単行本は知らない。 速報性は求められないので、毎日、当日発売の本をチェックするのが妥当。
【続きを読む前に予備知識】 発売日 2007-06-31〜2007-06-01〜2007-06の本が含まれるのは現時点で 5?0から 15?0ページ目までの約1000ページ。
ひと月約1000ページとして 2000ページ目までには今月の刊行物が全て収まってるとする。 特定の日付の始まりか終わりの含まれるページを見つけるのに約11回(log2(2000)≒10.9)のクエリ。 そこから一つずつインクリメント(デクリメント)すること 30回(1000÷31)もあれば次の日付が現れるだろう。
平均して一日あたり 40回程度のクエリで当日発売の本が取得できる。(前述の通り「ジャンル別」の BrowseNodeに属していない本は漏れるが)
発売年月の情報しか持たない本については、どのタイミングで追加されるかわからないので、漏れとクエリを最小にするには、月が変わってから取得する必要がある。月が変わってから……。
Amazonを 25回呼び出して得られたのが以下の23日発売の本たち(といっても半分以上が雑誌だが)。25回の内訳は 2007-07-23が現れる最初のページを見つけるまでに 11回。データ取得に 14回。同じページを重複して取得するのを避けたら 1〜数回は呼び出しを減らせる。ラブやんがきちんと引っ掛かってるので自分的には成功。
これ、毎日起動してもいいのかな……かな?
毎日 01:00前に自動更新。リストは Amazon.co.jp NewReleasesにアップ。
最終更新: 2014-12-05T17:24+0900
と思うわけです。単行本を買うほどの作家の数は知れてるので、それでも破綻はしないけど、もうちょっとなんとかならんのか。
漫画の新刊はまんがの森か太洋社か漫画王倶楽部でチェックできるし、文庫は太洋社か漫画王倶楽部で、ノベルスは漫画王倶楽部で。文庫の中でもラノベならラノベの杜〜新刊案内〜でチェックできる。
新書と単行本(と CD)が穴だ。
新刊.netや e-honの新刊パトロールが一つの答え。でも検索条件を登録するのが面倒で、頑張ってもマイベスト作家トップ10をチェックするぐらいが関の山だろう。
Plagger使って出版社のサイトを定期的にスクレイピング。出版社の数だけプラグイン用意して、HTMLや URLの変更に追随しつづけるぜ、なんてのは考えるだけでお腹いっぱいです。
ブックスケジューラーというソフトが既に存在していた。Amazonで検索できるのはもちろん、bk1、e-hon、角川、芳文社、太洋社プラグインなども備えている。vCalendarや iCalendarとして出力もできるようだ。検索キーワードを必ず指定する必要があるみたいだけど、100や 200のキーワードを登録しても Amazonは平気だろうか? (太洋社や出版社のサイトは問題ないと思うが)。設定はテキストファイルで、GUIを通さずに検索キーワードを大量に追加できるだろうか?
Flinker.jpは著者にフォーカスした Webサービス。「ブックマーク」した著者の新刊を取得できる。単なるキーワード検索ではなく、利用者の手を借りて著作リストやシリーズもののグループ化などを正確なものにしていく仕組みがある。問題は著者ページが存在しない場合は申請しないといけなくて、ページが追加されるのは翌日になること。この時間差のハードルは大きい。表記の揺れなどで同一著者について複数のページが立つのを避ける意味もあるだろうし、新着著者リストがspamリストになる危険性もあるだろうけど、面倒だよ。面倒だよ。検索で著者ページが見つからなかったときは、Wikiのように、新規作成画面を表示して即座にページを追加できるようになると良い。何百という著者をブックマークして新刊をチェックするような使い方はできそうにない。始まったばかりだからなのか、どちらかというと、サービスを利用したい人より、著作データベースを作るぞ、という気概を持った人の方を向いている気がする。
Amazonには「持っている」本を多数教えてあるので、一肌脱いでいただきたい。「新刊著者の既刊を持っている」なんて情報は売り込みの参考として有望そうに思えるが。どうですか? あるいは新刊のリストが手に入れば自分でフィルタリングするが。
長門さんが『ゲーデル、エッシャー、バッハ—あるいは不思議の環』を読んでいる。これは結城さん*の愛読書だとか。
長門さんは多分『永久帰還装置』も作中で読んでいる。そのAmazonでのレビューに
手塚治虫のあのオセロの駒のような話、人生の岐路でもう片方に行っていたらどうなっていたか、という奇妙な話がありましたが、「どちらの世界が本当か」という問いを、問いを無効化することで解決するような話だと思いました。
とあるが、『涼宮ハルヒの分裂』自身がαとβの二つのルートを並行して書いていることと関係があるだろうか。分裂は『涼宮ハルヒの驚愕』に続くし、『永久帰還装置』も未読だし、今は何もわからんが。
* わかりやすいコンピュータ関連書籍を書かれる方です。イラスト付きのミルカさんに一票(独り言)。
二巻がもうじき出るが、一巻の宣伝ページを著者のサイトで発見。高橋メソッドだ。
http://www14.plala.or.jp/funore/tmethod/
この人のサイトはトップページに <SCRIPT>タグしか存在しないという面白いことになってて、初めて見たときは笑った。
Amazonで ISBNと ASINが一致しなくなるのが一番痛い。ASINの桁数を増やしてくれるのが楽なんだけど、Amazonにとっては楽じゃないんだろうなあ。
気になる AWSでの ItemLookup。 従来は [An ASIN]の部分に単に ISBNを入力するだけで本の情報を得ることができた。
http://webservices.amazon.com/onca/xml?Service=AWSECommerceService &AWSAccessKeyId=[Your Access Key ID Here] &Operation=ItemLookup &ItemId=[An ASIN]
これに
&IdType=EAN
というパラメーターを付ければ ItemIdとして ASINの代わりに JANを指定できる。新しい 13桁の ISBNは JANと一致しております。やったね。ただし、
If you select SKU, UPC, or EAN as the IdType for your request, you also need to include the SearchIndex parameter.
(IdTypeに SKU, UPC, EANを選んだら SearchIndexも指定する必要があるよ。)
SearchIndex is required any time you select SKU, UPC, or EAN as the IdType for your request.
(上と同じ内容だけど any time you select EANと書いてあって、よりハッキリ。)
と書かれているので、同時に SearchIndexも指定しなければならない。
Amazon.co.jpで許されてる SearchIndexの値は以下の通り
以上。本がありませんね。
2006-11-14版の ドキュメントによれば JANを使って ItemLookupすることはできないみたい。
https://affiliate.amazon.co.jp/gp/associates/network/help/t4/a7/
転載しちゃって良いかな?
自動化された方法、またはプログラムを組むことによって、13桁のISBNからアソシエイト・リンクを作成することはできますか?
はい、13桁のISBN(以下、新ISBN)への移行後は、Amazon Webサービスの一部である、Amazon E-Commerce Service (ECS) のシステムを利用して、新ISBNをもとにアソシエイト・リンクを生成することが可能になる予定です。Amazon Webサービスでは、現在、ItemLookupの機能を利用して、流通コードであるEANやJANをキーにしたデータ参照が可能であり、この機能に新 ISBNを使用したマッチングを追加する予定です。こちらのサポート開始時期につきましては、E-Commerce Serviceの開発者フォーラム(英語版または日本語版)や、ニュースレターによりご案内しますので、定期的にチェックされることをお勧めします。なお、Amazon Webサービスのご利用には登録が必要です。登録がお済みでない方は、こちらより登録IDを取得してください。
見覚えがあるから一度は読んだはずなのに。
* 2007年からです。知らなかったわけではありませんが、忘れていました。
♭ Steven LevithanHi. I translated this page using Google Translate. The la..