時々、同じ夢を見る。それはいくつかあって、同じ設定、同じ場所、同じ行動。

細部は多少違うけど、ほぼ同じで夢を見ながら、またここか、またこれか、と。

今日見た夢もそのうちのひとつ。

山に入っていく川沿いの細い道。緑の濃い森の中を延々と続く上り道と上りの細い石段。まだ登るのかとうんざりしながら疲れを覚える足を運ぶと、少し開けたところに出る。そこはどこにでもあるような鳥居と神社。またここかとほっとするような懐かしいような。

…で、目が覚めて、毎度同じでイメージが貧困だなあ、と呆れる。

この夢、というかこの場所、この道、この石段を年に何度か見てる。

記憶が確かなら、奈良吉野の天河神社に行ってから、時々見るようになった夢だ。

天河神社はいわゆるパワースポットと言われていて、その手のひとやメディアの御用達。「月刊ムー」や「東スポ」あたりも取り上げたことがあるんじゃないかな。

自分の中に神社を抱えているとかいうとそれっぽいんだけど、リアルでは残念ながらそっち方面とは無縁。

崖みたいな細い道を進むバスに揺られて峠をいくつも越えてたどり着いた天河神社、というか天川村の夏の風景が強烈に印象的だった、ということだろう。

小学校低学年の頃、6，7歳の頃、母親の実家の淡路島で夏休みを過ごすことが多かった。山を越えて、といっても淡路島に険しい山などないので、ちょっとした峠を越えると、目の前、視界がいきなり真っ青。夏の空と海。海水浴が夏休みの日課だった。

デジャヴというには遠すぎるけど、天河神社に行って真っ先に思い出したのが子供の頃の淡路島。自分なりの「原体験」ということなのかな。

今日見たこの夢、この場所。

みけさんを入れたキャリーバッグを持ってここに行く途中、道に迷って行ったり来たりする夢だった。

還暦を過ぎて道に迷ってるようじゃロクな死に方せんな、おれ。

天河神社のオフィシャルWEBページでも貼っておこう

https://www.tenkawa-jinja.or.jp/

わたしが行った頃とは違ってトンネルが開通したり、交通の便がかなりよくなってるっぽい。

夏休みにオススメ。みんなが思う夏休みがそこにあるんじゃないかな。

[更新]2024-04-30 07:52:32

砂インフレイベント、ウォーターフェスティバルが今日で終了。いや、本当に美味しいイベントだった。ほしのかけらも使いつつポケモン捕獲、卵孵化、ジムへの木の実で、気づいたら10万溜ってたりしたんで、強化の砂にまったく困らなかった。

砂お大尽期間に強化できた伝説のポケモンリスト。

基本的に各自が持っていた飴の分だけ。

ホウオウとルギアについては不思議な飴を投入。まずはホウオウとルギアをカンストだ。

ここんとこ書いてるように、種族値の高い伝説ポケモンを強化したら無双ジム戦が面白い。ジムを落とすというより、CP3000クラスのポケモンを狙いうち。試し斬り、みたいなもんだ。

ホウオウとルギア以外の伝説も様子を見ながら強化を続けるか。

このほかに、コミュニティデイでうちおとすを覚えさせたバンギラス(卵孵化)に砂を投入して砂9000飴12まで強化した。

短期間にこれだけのポケモンを強化したのは初めて。

これはクセになる、というか麻薬だなあ。いつくるのかもわかない砂イベントが待ち遠しいぞ。

[更新]2018-08-03 05:42:00

タイトルが大嘘ですみません。

AndroidタブレットZenpadにtermuxでLinux環境を作って仕事・作業もこれで間に合わせよう、というネタ。

電子書籍、EPUBファイルの作成仕事をいただいている。

作業環境というか制作に使うのはエディタとperl。

そして作ったepubファイルが正しくできているかチェックするのに必要なのがepubcheckというjavaで走るスクリプト(プログラム？)。これでチェックしてエラーや警告のないことが納品の前提となる。

wordやinDesign(の出力したepub)をエディタで確認、epubファイル生成用の独自タグを埋めこんだりその他タグの調整をして、perlのスクリプトに食わせてepubファイルのできあがり。

とりあえず作ったepubファイルをepubcheckにかけてエラーの確認。

使っているスクリプトは各クライアント用にカスタマイズ済なので、初めての案件でもない限り、ほぼエラーは出さない。

このエラーのないepubファイルを電子書籍リーダー(Kinoppy)に読みこんで確認・修正作業となる。圏点や太字の漏れや、字下げ、文字サイズ、空行の調整などを原稿(WORDやPDF)を見て、該当するxhtmlファイル(epubファイル)をエディタで開いて手作業での修正だ。

わたしは雑な性格なもんで、ここでエラーを紛れこませてしまう(なので、できるだけスクリプトにして極力手作業は避けるようにしている)

せっかくepubcheckでエラーのないファイルを作っても、その後の手作業修正でエラーにすることがある、ということだ。

ファイルを修正するたびに必ずepubcheckでエラーの確認をしている。

なのでAndroidタブレットでjavaがない、epubcheckが使えないのは致命的。

termuxでjava(jdk-8)を動作させているハッカーのひともいるけど、素人のわたしはパッケージとして用意してもらわないとまず無理。

歓喜の持ち歩けるLinux環境が宝の持ち腐れだ。

わたし得意の「とりあえず」の「やっつけ」で、epubcheckは無理だけど、できたファイルをチェックする程度のスクリプト(perl)を「でっちあげた」

前提として、epubcheckの通ったファイルであること。

手作業で紛れこませるエラーは、タグの不整合(閉じ忘れ・削除し忘れ)、追加や変更があってopfにファイルの登録し忘れ、といったところがほとんど。これらを潰せればだいたい問題はない。

タグの不整合チェックにperlのHTML Lintを入れてみたんだけど、ちょっと使い勝手が思ったのと違うので見送り。タグの数をチェックするだけで十分てことにした。

また、META-INFのcontainer.xmlから辿って、opfファイルを読みこみ、ファイルの有無、manifestとの整合もチェックする。

もちろん、この程度のものが業務実用になるとは思わないので、納品前にはepubcheckを通す。ただ、途中途中、外出先などでの確認作業はこれぐらいで十分だろう。これで急ぎの対応なんかも可能となる。自画自賛。

termuxのコンソールで走らせてニヤニヤした勢いでこの雑記を書いてるんだけど、こりゃただの日常雑記、何の役にも立たんな。

いや、ほんと申し訳ない。

ポケモンGOのイベントがひと段落したら、本格的に持ち歩きLinux環境の稼動だ。

[06/21 19:26:40]

EPUBファイルと同じ階層にスクリプトを配置。

引数にEPUBファイルを渡すと

1)unzipを呼びだして解凍

2)フォルダ構成を表示

3)opfに登録されているファイルが、EPUBパッケージの中で登録通りの場所に配置されているかチェック

4)逆にEPUBパッケージに配置されているファイルが、opfに登録されているかチェック

5)タグの不整合のチェック

・opfに登録されている「contents014.xhtml」ファイルが見当らない

・「cover00.jpg」「contents020.xhtml」がEPUBパッケージ内にあるけど、opfに登録されていない

・spanタグがおかしい。開始タグが1つあるのに閉じタグがない

・contents001.xhtmlの42行目あたり

てな感じ。

昨日書いたように、epubcheckの代わりになるものではない。あくまでも、とりあえず最低限(にも足りないけど)の確認だけ。epubcheckをちゃんと使って確認していることが大前提。

こっちのPCではepubcheckが使えるけど、こっちのPCだと使えない、というような場合の緊急避難的安心感を得るためのもの。いや、こんなんでもけっこう助かる、おれは。

電子書籍を書店で買うのか、ということなんだろうけど、わたしはこれなら十分ありだと思った。

写真がショボくてわかりにくいけど、店内の柱部分を使って電子書籍ダウンロード用のカード「BooCa」がずらっと並ぶ。

（こっちが詳しい→「楽天とBookLive!が参加ーーリアル書店で電子書籍が買える「BooCa」4書店で提供開始」）

実際に見るとけっこう楽しい。

神保町の三省堂は以前からLideoのコーナーというか電子書籍のコーナーもあって、チラシ・パンフレットと実機があるんだけど、これだと何か電子教材でも売ってんのかぐらいにしか見えなかった。

今回のBooCaはカード。

1つのカードが1つのタイトルとなっているので「へえ、あの本が電子書籍で売ってんのか」「ん？これってどんな本だろう」と、とてもわかりやすいし、興味を引かれる。表紙が印刷されていると強い・キャッチー（底本を元にしたイメージと注意書きがあって、権利関係など大変そう）で、つい手を伸ばしてしまう。

書店にいて飽きないのは「ぶらぶら歩いて表紙や背表紙を眺めて引っ張り出して、ぱらぱら立ち読みする」のが楽しいから。カードになってると書店内回遊の流れの中に違和感なくすんなり入るから回遊時間も伸びる。巡回しなきゃいけないエリアが増える。

もともと書店は1つのタイトルでハードカバーがあって文庫本がある。どちらを選ぶかは買う側の理由。これらに電子書籍がカードという現実になって選択肢の１つになったということ。カタチとても大事。

帰りの電車で読みたいというのなら紙本を買えばいいし、今日は飲み会だし帰ってから読めばいいやというのなら電子書籍も選択肢に入るだろうし。

カードは中身を丸ごと立ち読みはできないので、せめて冒頭の何ページ分かをカードに掲載してほしかったかなあ（同じ売場にその本があるからそっちを読めばいいだろうというのは怠慢）

んで、こんなことを書いておいてアレすぎるんだけど。

対象の電子書籍ストアは楽天koboとBookLive!…いちおう楽天koboの会員ではあるけど今回はまだ買っていない。

自分で売る側から言うといろんなストアに並べるべし！とか言ってんだけど、買う側として現状kindle一択。

「あの本どこで買ったっけ？えーっと」

と、本棚以前にアプリを開いて探してまた別のアプリを開いて探してというのがけっこう面倒くさい。

…という自分都合でちょっと腰が引けた。書店での販売が常設になるなら考えないとなあ。

神保町交差点の立ち食い蕎麦「いわもと」美味かった。

[更新]2026-02-01 12:47:48

その０．

購入ボタンはこんな感じ

<form name="_xclick" action="PAYPALSERVER" method="post">
<input type="hidden" name="cmd" value="_xclick" />
<input type="hidden" name="business" value="EMAILADDR" />
<input type="hidden" name="currnecy_code" value="JPY" />
<input type="hidden" name="item_name" value="ITEMNAME" />
<input type="hidden" name="item_number" value="ITEMNUMBER" />
<input type="hidden"  name="amount" value="100.00" />
<input type="image" src="PAYPAL PURCHASE BUTTON" />
</form>

item_number以外は必須。item_numberも、商品IDとして使うので、わたしの場合は必須。ユーザーがPaypalから戻ってきたとき・Paypalから即時通知があったときに、この商品IDでデータベースに照合する。

あらかじめ、Paypalで個人設定を仕込む。（以下とは別に、文字コードを日本語、UTF8に設定しておいた）

その１．

「ウェブペイメントの設定」

→自動復帰 オン

→復帰URL ユーザーが帰ってくるURLを設定

→支払いデータ転送（PDT） オン

→暗号化されていないウェブペイメントの受領拒否 オフ

購入ボタン自動生成で暗号化してないので、最後の設定はオフにしておく。

購入ボタンをクリックしてPaypalにいったユーザーが支払いを完了して「マーチャントに戻る」リンクをクリックしたら、復帰URLにパラメータを持って戻ってくる。それをスクリプトで解析する。以下はほぼほぼPaypalにあるサンプルコード（perl版）まんま。

    my $query  = join(’&’， "cmd=_notify-synch"， "tx=$form->{tx}"， "at=PAYPAL_AUTH_TOKEN")；
    my $ua  = new LWP::UserAgent；
    my $req = new HTTP::Request("POST"， PAYPAL_SERVER)；
    $req->content_type("application/x-www-form-urlencoded")；
    $req->content($query)；
    my $res = $ua->request($req)；
    return if($res->is_error)；

    my @response = split("\n"， $self->html_decode($res->content) )；
    my $status = shift(@response)；
    my %tx；
    if($status eq "SUCCESS"){
        foreach( @response){
            my ($key， $val) = split("="， $_)；
            $tx{$key} = $val；
        }
        return \%tx；
    }
    else{
        return；
    }

戻ってきたら、GET でパラメータ＝トランザクションIDを取得して、Paypalの管理ページ、個人設定にある、auth tokenと、定型のコマンドとともに、PaypalのサーバーにPOSTでアクセス。

そこで取得できるcontentを改行でばらして一行ずつ、って先頭の行がSUCCESSであればOK。それ以外だと決済が完了していないので、どうなってるのか調べる必要がある。

というのが「PDT」というヤツ。

ところが、これはユーザーが「マーチャントに戻る」というリンクで戻ってくれないと、情報が何も取得できない。もちろん、Paypalの方からメールがくるし、Paypalの管理画面を見れば、取引状況はわかるので、調べてユーザーに返事を出すこともできる。

でも、今回やりたいのはダウンロード販売。

支払いが終わったらすぐにダウンロードページに行きたいよね…といいつつ、Paypalの「マーチャントに戻る」リンクがまるで目立たない。これじゃ、ユーザーはここでブラウザを閉じて終了、だろう。現に戻ってくる率は２０％もない、という記事もどこかで見かけた。なので、こちらは、もしユーザーが戻ってきたら、ありがとうございましたとか、確認にしばらくお時間くださいとか、表示を選択するためのモノとして使う程度。

そこで、以下のIPN（支払い即時通知）の出番。

その２．

「即時支払い通知（IPN)」

→通知URLを設定

支払いが生じたらPaypalから、通知URLあてに、パラメータを抱えてアクセスがある。それをスクリプトで解析。以下はサンプルコード（以下同文）

    my $query；
    read (STDIN， $query， $ENV{’CONTENT_LENGTH’})；
    $query .= ’&cmd=_notify-validate’；

    my $ua = new LWP::UserAgent；
    my $req = new HTTP::Request("POST" ， PAYPAL_SERVER)；
    $req->content_type("application/x-www-form-urlencoded")；
    $req->content($query)；
    my $res = $ua->request($req)；

    my $cnt = 0；
    my %ipn；
    my @pairs = split(/&/，$query)；
    foreach my $pair ( @pairs ){
        my ($key， $val) = split(/=/，$pair)；
        $val =~ tr/+/ /；
        $val =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C"，hex($1))/eg；
        $ipn{$key} = $val；
        $cnt++；
    }
    if( $res->content eq ’VERIFIED’ ){
        my $err；
        $err = 1 if($ipn{’payment_status’} ne ’Completed’)；
        $err = 1 if($ipn{’receiver_email’} ne MY_PAYPAL_EMAILADDR})；
        $err = 1 if($ipn{’mc_currency’} ne ’JPY’)；
料金などのチェック
        if( $err ){
            open(OUT， ’>>’ . ’_err.txt’) || die；
            foreach (keys %ipn){ printf OUT qq{[KEY]%s ::: [VAL]%s\n}， $_， $ipn{$_}； }
            close(OUT)；
        }
        else{
エラーがなければデータベースに登録したり
ユーザーにメールを出したり
        }
    }
    else{
        open(OUT， ’>>’ . ’_err.txt’) || die；
        foreach (keys %ipn){ printf OUT qq{[KEY]%s ::: [VAL]%s\n}， $_， $ipn{$_}； }
        close(OUT)；
    }

POSTされたパラメータをそのままに、コマンドを付加して、Papalに返すと、パラメータが正しいか間違ってるかだけ教えてくれる。パラメータが正しければ、料金を確認したり、トランザクションIDをチェックしたり。エラーがあったら、ログを吐き出し、正しければデータベースに登録してユーザーにダウンロードURL案内のメールを出す。

わたしはperlが少しわかる程度。それでもサンプルコードどおりに書けばほぼOK。ダウンロード販売ということで、データを受けてデータベースを使って商品を特定したり、ダウンロードURLを作ったり、というところがちょっと面倒だけど、難しいもんじゃない。

最悪、うまくいかないケースが生じても、Paypalからメールが来るし、Paypalの管理ページに行けば履歴を確認したりキャンセル処理ができるので致命的なことにはならない、はず。

それに、ダウンロード販売なので、面倒な在庫管理は不要。

ちなみに、無責任なことに、これを書いてる時点ではまだ本番でのテストはやってないので、あしからずご了承いただきたく。忘れないうちに自分メモ。

原稿があるなら、Paypalを使って、ダウンロード販売ですよ。たぶん、儲けるのは無理だけど、原稿を塩漬けにしてるぐらいなら、ネットに並べておいてもいいんじゃね、と。個人書店があちこちにできて相互にリンクできれば宣伝にもなって面白いんだろうから、お手伝いしますよー。