素人によるSQLパズルゲーム

2015/1/31 [12:49:15] (土)

ここにあるのは素人芸なのできちんと調べるなら
「図でイメージするOracle DatabaseのSQL全集」
https://www.oracle.com/technetwork/jp/articles/otnj-sql-image1-308625-ja.html
をオススメ。

以下は、このORACLEのページを元ネタにして雑記帖のカテゴリをいじくった時のメモ。
（具体的にデータベースの構造を晒すのはセキュリティ的に問題があるような気がするので端折った）

「カテゴリを元に雑記帖の記事をリストアップしたい」

・雑記単位で一意のIDがある
・雑記に紐付くカテゴリがゼロ以上複数個ある

という雑記帖詳細テーブル

というカテゴリ詳細テーブル

このふたつを繋ぐために

という雑記とカテゴリを紐付けるテーブルがある。各々のIDから詳細テーブルがわかるので内容を引っ張りだせる。

「電子書籍」というカテゴリがついた雑記を引っ張りだすには、雑記IDで雑記カテゴリを繋ぐ。inner join、内部結合というやつ。
select 雑記ID from 雑記帖詳細 inner join 雑記カテゴリ ON 雑記ID=雑記カテゴリの雑記ID AND 雑記カテゴリのカテゴリID=電子書籍ID
でシンプルにあっさり。


複数のカテゴリから雑記を引っ張りだすのが少し面倒くさい。

その1 和集合

A「電子書籍」か、B「kindle」のどちらかのカテゴリのついた雑記を引っ張りだすには
select 雑記ID from 雑記帖詳細 inner join 雑記カテゴリ ON 雑記ID=雑記カテゴリの雑記ID AND 雑記カテゴリのカテゴリID in (電子書籍ID,kindleID)
これでカテゴリに「電子書籍」か「kindle」がついた雑記を引っ張りだせるけど、両方ともついた雑記が2回出てくる。

雑記3のケース。
IDが重複していると、同じ雑記を表示することになってしまうので、重複IDをひとつにするために distinct を使う。
select distinct(雑記ID) from 雑記帖詳細 inner join 雑記カテゴリ ON 雑記ID=雑記カテゴリの雑記ID AND 雑記カテゴリのカテゴリID in (電子書籍ID,kindleID)


その2 積集合

A「電子書籍」とB「kindle」、両方のカテゴリがついた雑記を引っ張りだすには intersect を使ってふたつの検索結果であるテーブルの積集合をとることになるらしい。
select 雑記ID from 雑記帖詳細 inner join 雑記カテゴリ ON 雑記ID=雑記カテゴリの雑記ID AND 雑記カテゴリのカテゴリID=電子書籍ID intersect select 雑記ID from 雑記帖詳細 inner join 雑記カテゴリ ON 雑記ID=雑記カテゴリの雑記ID AND 雑記カテゴリのカテゴリID=kindleID
1行目のselect文で電子書籍IDのついた雑記を引っ張りだし、3行目のselect文でkindleIDのついた雑記を引っ張りだす。
intersect が、ふたつから共通する雑記IDだけを引っ張りだしている。

この引っ張りだした結果を select で括って条件でフィルタしたり順番に並べたりする。
select * from ( select 雑記ID from 雑記帖詳細 inner join 雑記カテゴリ ON 雑記ID=雑記カテゴリの雑記ID AND 雑記カテゴリのカテゴリID=電子書籍ID intersect select 雑記ID from 雑記帖詳細 inner join 雑記カテゴリ ON 雑記ID=雑記カテゴリの雑記ID AND 雑記カテゴリのカテゴリID=kindleID ) where文 order by 並び順 limit 個数 offset どこから


積集合じゃないけど、両方のカテゴリがついた雑記を引っ張りだすもうひとつのやり方。
ひとつの雑記に「電子書籍」「電子書籍」などとカテゴリは重複しない。ということを前提にすると。
select 雑記ID from 雑記帖詳細 inner join 雑記カテゴリ ON 雑記ID=雑記カテゴリの雑記ID AND 雑記カテゴリのカテゴリID in (電子書籍ID,kindleID) group by 雑記ID having count(雑記ID) = 2
というのもありかも知れない。
・カテゴリに「電子書籍」か「kindle」がついた雑記を引っ張りだす
・雑記IDごとにグループ化＝集計する
・集計結果が「2」であればカテゴリがふたつともある
最初はこっちで実装してみた。

intersectを使ってtableをふたつ結合するのは処理が重い＝遅いんじゃないかと思ったんだけど、計測してみたら全然差がなかった…たかだか（現状）2700程度の数だし。
それなら、カテゴリの重複はない、などと前提条件がつくよりは素直にテーブルを結合させた方が安心安全、かな。


https://t2aki.doncha.net/index.pl?cat=5%2C43
↑カテゴリをコンマで繋いで複数カテゴリのリストアップ。
これは「日野裕太郎」と「doncha.net」の組み合わせ。

日野裕太郎は紙本（商業・同人）があるし、ウチ以外からの電子書籍もあるので細かいコンロールをしたかったんだよなあ。

いろんな場面でカテゴリの組合せが使えるのがスゲーありがたい（自画自賛芸）


perl にしろ SQL にしろ、ネットの情報・紙の解説本が豊富なので、わたしのような素人なら素人なりにレベルに応じて使えるので本当に助かります。

» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」

»電子書籍制作代行についてはこちら

Kindle KDPでTINはもう不要

2015/1/31 [09:15:18] (土)

昨日twitterで見たんだけど。
現在jpとmxとauとcaとinについては米国の30%源泉徴収を適用していないとのこと

そういえば、以前、KDPの管理ページで販売地域の選択がなかったような記憶。iTunesでは地域選択があって、価格を決めるので、KDPは価格設定が販売地域も決めるのか、と思った。今月、久しぶりに登録してみたら、販売地域の選択があったんでいつからあったっけ、と。

販売地域がjpだけの場合にはTINは不要になるのかも知れない。

元ネタはフォローしている漫画家さん・粟岳高弘（‏@AwatakeTakahiro）さんの一連のツイート

これが事実として公式に確認できたらビッグニュース（ご当人ももっと話題になってもいいのに、と）
個人がKDPに参入するのに一番のネックになってるのがこの税金処理。
電子書籍を作る環境は出揃っているので、このうっとーしー税金処理さえなくなれば参入する個人作家が増える・コンテンツが増えるのは間違いない。

「Kindleの電子書籍に消費税適用へ　2015年度から　Googleの広告にも」
https://www.huffingtonpost.jp/2014/06/25/kindle-consumption-tax_n_5531962.html
あたりが関係してんのかな。


[2015/02/17 08:55:12]追記。

Amazon Kindle公式のヘルプ「米国以外の出版者の源泉徴収税」に
* 米国以外の Kindle ストアで得たロイヤリティについては、Amazon は米国の源泉徴収税の徴収を行いません。 
https://kdp.amazon.co.jp/help?topicId=A1CTSIBPDAAJ0M
と明記されていた。
 

粟岳高弘（‏@AwatakeTakahiro）さんのツイート通り、日本で売る限りEINやITINを取得する必要はない、ということだな。

もちろん、米国で売れるとその分に関しては30%天引きされるんだろうけど、日本語で書かれた本が米国で大ヒットするとは思えないので面倒な減免の手続きをすることもない。


上記した電子書籍に消費税適用のほか、日米租税条約の改正が去年暮れだか今年あたりに発効とかも影響があったか。
「外務省：日米租税条約改正議定書の署名」

所得に対する租税に関する二重課税の回避及び脱税の防止のための日本国政府とアメリカ合衆国との間の条約を改正する議定書」

文字通り、二重課税防止のための条約ということなので、遵守しろよ、と厳しくなったんかねえ。

» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」

»電子書籍制作代行についてはこちら

読書・蔵書記録のための本のデータ

2015/1/30 [20:36:11] (金)

「何を今さら」で「大昔からあちらこちらで語られてる」ネタなんだけど、本のデータについて自分備忘録。
図書分類は知らなくても、ECで5年やってたことがあるので、商品のデータ構造やその表示について、という側面から。

本が好きな人は、読書・蔵書記録をつけるのも好きであろうと思う。たとえばWEBサービスを利用したり、パソコンでソフトを使ったり、手書きでノートにつけたり。

本の最低限のデータをエクセルにすると、ありがちなのはたぶんこんな感じ。

タイトルと著者名があれば、それでOKだと思う。

でも、これはあっと言う間に破綻する。
著者が複数の場合があるし、その人数もわからない。

著者欄をある程度人数が入るように作っておくのは無駄だしキリがない。
ここにさらにイラストレーターやカメラマンなどの欄が欲しくなるだろうし、自分なりのカテゴリ欄や感想・メモ欄も欲しくなるのが人情というものだ。そのどれもがいくつの欄が必要になるのかわからない。

1タイトルを1行に納めるのは無理だというのがわかると思う。

なもんで、じゃあ「本ってなぁに」ということから始まるんだけど、別にメタな話ではなくて、具体的な話。

とりあえず「本というのはタイトルにいろいろくっついたデータの集り」ということにしておく。
（本に限った話じゃないとか、タイトル改題とかどうすんのとかは無視）

これさえあれば、付随するデータはバラで用意しておくといろいろ捗る。

とか

とか

とか

とか

「サイボーグブルース」というタイトルを持つデータを集めれば「サイボーグブルース」という本ができあがる。著者の人数の制約もなく、イラストの他に「いろいろ」に出版社や定価なんてのを追加するのもスグ。

今度は逆に「いろいろ」の中から「平井和正」を集めれば、「サイボーグブルース」や「死霊狩り」「狼男だよ」などの「タイトル」をリストアップできる。
さらにそのリストアップされた「タイトル」にくっついている「いろいろ」の「カテゴリ」を集計して「平井和正」の傾向を見ることもできる。

…なんだ、リレーショナルデータベースの話かよ、というのはその通りで、本のデータをゴソゴソいじるのにリレーショナルデータベースはちょお便利。ウチのサイトのデータベースはまだあれこれあるんだけど、基本はこの程度。

ただ、気楽に使えるリレーショナルデータベースというのが検索しても見当らなかった。
わたし自身はWEBで定番のデータベースを使ってるけどちょっとハードルが高いかなぁ。パソコンで使えるものとなると、ACCESSやファイルメーカーらしいんだけどお値段がちっとアレ。

エクセルで表にする時、上記したような形式ではなくてこんな感じにするといいかもしれない。

ぱっと見、わかりにくいけど「データ」→「フィルタ」をいじるとデータをいろいろな切り口で眺められるので面白いですよ。


…て、SQLの和集合、積集合や内部結合についてメモしようと思ってたのに、なんでこんなこと書いてんだか。SQLパズルについてはまたそのうちメモしよう。

» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」

»電子書籍制作代行についてはこちら

オレオレCGMでランディングページ

2015/1/26 [12:04:29] (月)

この雑記帖はperlで自作のcgi。
最初1998年頃は、テキストエディタでHTMLを書いてFTPでアップロードする昭和の世界だった。さすがに面倒になったのでperlでcgiにしたのが2000年。当時はMovableTypeもWordpressもなかった。
それ以来、ダラダラ続けて、その場その時の思いつきでいろいろ機能を付け足し現在に至る…18年め。

kindleだけだった頃とは違って、今は楽天koboも始まって配信するストアが増えてきた。

今のところ雑記帖では、Amazonへのコンテナを表示して、それ以外のストアはオマケの扱い。kindleありきで作ったコンテナ。
でも、ヨタ・ネタの雑記ならともかく、日野裕太郎の作品ページでそれはどうなの。だいたいゴチャゴチャしたコンテナでなんのことやら分かりにくい。ユーザー行動を誘うwebページでは情報は整理されるべき。

kindleもibookstoreもkoboも、ストアへの動線は同じ扱い。ゴチャついたコンテナ表示を止めて購入ボタンっぽくして並べることにした。

作品ページに表示する情報も統一した。
表紙画像、タイトル、定価、キャッチ、ページ数、本文一部抜粋。
アマゾンレビュー、twitterの感想ツイート、取り上げられたブログや掲示板。
その他関連記事。
サンプル表示リンク。

管理のためにデータベースに書誌情報などをブチ込んで、と思ったんだけど、この雑記帖以外でも使う可能性があるので、とりあえずは perl のデータとして記述。これならどこからでもスグに読み込んで使い回せる（そのうちデータベースに入れる、か）

今回の作品ページ機能追加は「ストアありき」ではなくて「タイトルありき」ということ。
昔からよく言われてるんだけど、別サイトを立ち上げるのもしんどいので、オレオレCGMの雑記帖に機能追加。
 
『おかえりください』https://t2aki.doncha.net/?id=1363395220
↑Amazonのコンテナ廃止。各ストアへ購入ボタン風味
↓従来のAmazonコンテナ使用

» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」

»電子書籍制作代行についてはこちら

SigilのEPUB2をEPUB3に仮変換してみた

2015/1/20 [10:55:31] (火)

EPUB2をEPUB3に変換するネタ。
去年から地味に「Sigil EPUB3」とか「EPUB2をEPUB3」とかで検索されていて、去年暮れぐらいからさらに検索ボリュームが上がった感じ（ぼーっとアクセスログを眺めて目についた、という程度だけど）
epub2をepub3に変換したい、というリクエストが増えてんだろうなあ。

EPUB2のファイルをEPUB3のファイルに変換するより、元原稿からEPUB3ファイルを作り直した方が早いと思う。

とはいえ、呆け防止のパズルに途中放置していたepub2からepub3への変換スクリプトをいじってみた。

・epub2ファイルを解凍する。
　→ unzip EPUB2ファイル
・解凍したフォルダで、ターミナルあるいはコマンドプロンプトを開いてスクリプトを走らせる。
　→ perl sigil2epub3.pl
・epubcheckでエラーのないepub3ファイルができる（_temp.epubという名前のepubファイル）
 
※WINDOWSの場合はactive perl（https://www.activestate.com/activeperl/downloads）とコマンドラインで使えるzipが別途必要（https://github.com/bmatzelle/gow）

やってることは。
・content.opfを書き換える。
・新規にナビゲーション文書を作る。
・各XHTMLのヘッダを書き換える。
・epub3のチェックでエラーになるタグなど除去。

ちなみに、epub3でエラーになるタグを除去するので、レイアウトデザインは保持しない。
元のOEBPSフォルダはOEBPS.origという名前で保存するので、epub3にコンバートされたOEBPSと比較して調整＆対応。


やっつけ仕事というか、かなりテキトーなシロモノで、コンバート後にepubcheckのエラーになんなきゃいいや、ぐらい。
サンプルに使わせてもらったepub2のファイルは素直でシンプル。ちょっと複雑なモノだとエラーを吐かないとも限らない。
また、決め打ちしてるところもあって使い回しがきかないだろうと思う。

てな感じのスクリプトはこちら→https://t2aki.doncha.net/tmp/sigil2epub3.zip
（※ 一発芸ネタは直リンクできないようになっておりますので、このリンクからご入場ください）

ぐちゃぐちゃで汚いのは素人芸ということでご勘弁くだされ。
…うーん、やっぱこりゃ、時間の無駄だわ。

» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」

»電子書籍制作代行についてはこちら

小説同人作家さんのKDPとKWL

2015/1/13 [21:59:53] (火)

創作文芸見本誌会場HappyReading（https://books.doncha.net/happy-reading/）というサイトを作って2011年12月から運営している。

ここの本の詳細ページに、kindleとkoboを作家名で検索した結果を表示するようにしてみた。

「はじめてのかた」に書いたように

【ここは何のサイト？】
創作文芸、一次創作の同人小説誌を紹介、応援することを目的としたサイトです。
コミケやコミティア、文学フリマなど、同人誌即売会イベントで、文章系は手にとってもらって、中身を知ってもらうところから始まります。
ここでは「立ち読み」のテキストを、まず気軽手軽に読んでもらうために用意しました。
「をを！これ面白い！」「こんなの好きかも」という機会に繋がればいいなあ、と思います。
立ち読みしてみて、興味を持ったら、twitterボタンで、ぜひ作者さんとその小説を応援してください。

というのが目的のサイト。

なので、原則として紙の同人誌、即売会イベントが前提。
2011年に作った時点では電子書籍はPDFぐらいでkindleもkoboもなかったし。
2012年暮れにkindleが始まって、登録している作家さんが電子書籍で出すケースが増えてきていて、なんとかそっちもピックアップできないかなあ、と思ってた。

でも、amazonやibookstore、楽天にページができるし、そちらの方が当然ながらSEOも強いし、こっちでページを作ってもあまり効果があるとも思えなかったので、なんとなくだらだら放置してたんだけど、koboも始まったことだし久しぶりにサイトをいじった。

何度も繰り返しになるけど、電子書籍の最大のメリットは「その場でダウンロードしてスグに読めること」

同人誌は街の書店で買えるものではなくて、イベントで買って読んで面白いと思っても、その作家さんの本を買うには次のイベントまで待つか（どのイベントに出るか不明だったりするし）通販になる。

その隙間を埋める・読者を繋ぐのに電子書籍は最適だろう。
amazonや楽天にSEOではてんで相手にならないとはいえ、HappyReadingは今日時点で620冊の小説同人誌が登録されている（著者:423人、サークル数:176）イベントが近づくとアクセスも1日300UU程度はある（pvは指標としてアテにならないのでユニークユーザー数）

紙の同人誌から電子書籍への動線があれば少しは役に立てるかも。

詳細ページの検索結果表示例。
https://books.doncha.net/happy-reading/detail.pl?uid=93165147&bookid=614
https://books.doncha.net/happy-reading/detail.pl?uid=203488059&bookid=549
https://books.doncha.net/happy-reading/detail.pl?uid=14879977&bookid=691

・安直に著者名で検索してるだけで同姓同名対策はしていない。
・検索するのは本の著者がひとりだけのページ。


ちなみに。
まだまだ「紙か電子か」で紙が好きで電子には否定的というひとが多い界隈だけど、「紙か電子か」じゃなくて「紙も電子も」ということで個人出版が盛り上れば面白いと思う。 

» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」

»電子書籍制作代行についてはこちら