DLmarketがダウンしてもうすぐ2ヶ月
10月12日にDLmarketがダウンしてもうすぐ2ヶ月になる。毎月小づかい程度に売れ続けていた妻のアレンジ楽譜の販売も途絶えた。
たまたまその少し前に、3年近く続けていたYoutubeのピアノ動画更新も終了。まったくの偶然なのだが、店じまい感がひどい。
楽譜の販売そのものはどこかで継続しようということになったのだが、どこがいいかは特に決め手なし。プリント楽譜と＠エリーゼ（アットエリーゼ）は個人不可（＠エリーゼは以前に問い合わせを出して断られている）、同人音楽の森は俺が乗り気がしない。ミュッセでは販売できるし既に販売もしているが、サイトそのものが知られていないし全然売れてないし（ミュッセ経由でプリント楽譜で売ることは可能だが、マージンが増えるだけなので……）。
しょうがないので、自分でサイトをイチから作ってPayPalを導入することも検討。フルスクラッチかEC-CUBEか。決済とダウンロード販売の連動を考えるとフルスクラッチは、俺の技術力的に無理っぽい。EC-CUBEは良さそうだが、今から勉強し始めてすぐに使えるかどうかと言われると心もとない。あと、さくらインターネットでこれ以上DBの容量を増やすのは危ない。デルタだけで480MBとか使ってるし。
どちらにせよ、まずはパブリックドメインのクラシック曲のアレンジ楽譜だけに絞って始めることになる。なにかいい手はと考えた結果、BASEでショップを立ち上げることにした。これなら現状のピアノ教室サイトからリンク貼るのも簡単だし、SQLiteで作ろうと思っていた販売中の楽譜一覧サイトからもリンクだけで行ける。将来的にJASRACから許諾をもらって云々の時にも、まさにベースとして使えそうだ。
ということで、諸々準備中。近日中に（パブリックドメインの楽曲だけだけど）楽譜の販売を再開できそうだ。
とはいえ、DLmarketが再開してくれたらそれでOKなので、そちらも待ちたい。早く復活してくれ、DLmarket。
GFCF（グルテンフリー・カゼインフリー）食
家族のダイエットもだが、アトピーなどに効果があるかも、ということで、先週の日曜日、12月からGFCF（グルテンフリー・カゼインフリー）食を開始。今のところ、なんとか続いている。
スーパーでもコンビニでも、成分表示をじっくり見るため、買い物に時間がかかるようになった。それはそれで楽しい。「製造工程が同一で～」は、こだわらないことにしたが、小麦も乳成分も、思った以上に色んな食品に含まれている。毎回悩むのも大変なので定番を見つけたいところ。
とりあえず、近所のスーパーで、十割そばやグルテンフリーのパスタを発見。糖質ゼロ麺は以前から買っていたが、他もけっこう置いているようで、とても助かる。米粉・コーンスターチ・おから粉も扱いあり。たまに買っていた「おからドーナッツ」には小麦粉が使われていた。残念。グルテンフリーのパンは扱いなし。近所で他も当たったが、どこにもない。これは自分で米粉パンを作るしかなさそうだ。
和食はOKだろうという考えは甘かった。醤油（小麦を使っている）が壁だ。外食などでは諦めるとして、家では大豆だけのたまり醤油を購入。高いけど美味い。ありだな。いつも使っている米麹の味噌は小麦を使っていなかった。八丁味噌に含まれている水あめだが、製造の際に麦由来の酵素を使うことでグルテンが含まれる場合があるそうだ。このあたりはなかなか難しいなあ。
ハムやベーコンなどの加工肉はカゼインを使っているとのこと。これはさっくり諦めた。
とろみのある料理も全滅かと思ったが、米粉や片栗粉で問題ない。この土曜にはカレー粉と米粉でカレーを作ってみた。むしろいつもより美味いとの評価。よかった。近い内に麻婆豆腐にも挑戦してみよう。
おやつのたぐいはポテチや煎餅など、さきいか等々、探せばいくらでも見つかる。飲み物はお茶を中心に。ここ何年も、ルイボスティー・麦茶・コーン茶のカフェインレス中心なので全く困らない。
現時点で一番の難問は、冷蔵庫や冷凍庫、棚に残った麺類・粉物や乳製品の処理だ。とりあえず、俺が処理班になって必死で消化している。土曜は食べすぎて体重が増えた。
それと、水曜日は来年の春ぐらいに閉店するという「水道橋 とんがらし」で、「なす盛り ひもかわ」食べ納め。最後の粉物というつもり。
会社での昼食、今まであまり行かなかったやよい軒での塩さば定食が増えた。吉野家も醤油使用を諦めれば可。あとはおにぎりと豆乳か。
さばは最近になって健康食に近い扱いになっているようだが、水産業界の推したい圧力をひしひしと感じる。サバ缶も近所のスーパーでは品薄だ。
×preg_matchのパターン修飾子 → mb_eregに変更
会社のWebサイトに読み込む目次データ、スマホに対応したリッチなコンテンツにするために、ちまちま作業を進めているのだが、本日のデータは韓国語と日本語が混ざっていた。本によってフォーマットが違うのも悩みの種だが、今回は割とすんなり情報が整理できた。
で、HTMLだとキレイに表示されるのに、それを別のファイルからfile_get_contentsで読み込むと表示されないという状態に。ファイルサイズが大きいのかとか、そんなこと思って色々やってみるもうまく動かず。今日ほぼ一日かけた作業が無駄になるのかと落ち込んでいたが、気を取り直し、テスト用のスクリプトを書いてステップ毎に検証。PHPの正規表現検索関数（preg_match）で引っかかっていることがわかった。
そういえば、マルチバイトの時にうまくいかないとか、そんな話があったような気もするが、他の本の「はじめに」や「目次」で簡体字やハングルが混ざっていても平気だった。しかし、どうやらそこしか問題はないようなので、改めて調べる。そうすると、preg_matchでマルチバイトの正規表現を使う時は「u」というパターン修飾子を指定する必要があるとの記述を発見。uはutf8のu。えー、でも他でうまく動いているのに、と半信半疑で試したみたところ、あっさり解決。なんだ、これだったのか。ということで、今日一日の作業は無駄にならず。よかったよかった。
「はじめに」「目次」「本書の使い方」をどんどんWebに上げているわけだが、毎日何ページも作業をしていると、「あ、これ、前に失敗したな」という経験値が溜まってくる。今さらHTMLやCSSの習熟度を上げてどうするという気もしないでもないが、割と楽しい。なんなんだろうか。
翌日追記
などと浮かれていたが、次の日、今度は簡体字の含まれたファイルで正規表現のマッチングに失敗している。パターン修飾子の問題ではないなあ。マルチバイトの時はmb_eregを使うのが正しいのだと知る。mb_ereg_matchもあるが、preg_matchと対応するのはmb_eregのようだ（ややこしい）。
ところが、これがまたうまく動かない。PHPのマニュアルを見てもよくわからない。mb_regex_encodingをUTF-8で指定しても動かない。マニュアルの下に貼られたコメントをよく見ると、どうやら正規パターンの書き方が違うようだ。前後のスラッシュが不要？
簡単なパターンで試してみたら動いた。なるほど、mb_eregの時はpregの時に必要だった前後のスラッシュが不要なのか。わかりにくいなあ。
しかし、ここまでわかってしまえばどうということもない。前後のスラッシュが無い正規表現のパターンを書いて適用。
おお、動いた。
ということで、この二日間で、マルチバイトの正規表現関連は完全解決。
その後、pregとmb_eregでは、対応する正規表現のモジュールそのものが異なるということを発見。pregはPCRE、mb_eregはmbregex、PHPのマニュアルではPCREの正規表現については詳しく説明されているが、mbregexの正規表現については書かれていないそうだ。
うーん、弊社の場合は簡体字・繁体字・ハングルはもちろん、タイ文字やアラビア文字も扱うので、要所要所でmb_eregを使う必要がある。
と、思ったら、こんなページを発見。なるほど。諸々納得。
土日の宿題
土日の宿題は3件。
ひとつめは、デルタなどに「出版社のWebへのリンク」と「出版社名のヨミ」を表示ずるためのデータの整備。版元ドットコム・書協・出版協のリストをマージしてDBのテーブルに投入。いちおう表示まで完了。
しかし、思ったほど埋まらない。出版クラブと丸善とWikipediaのリストも追加したが、それでも1割以上埋まらない。しょうがないので、少し手作業で追加。残りも手作業だろうなあ。
それにしても、書協・版元ドットコム・出版協といった業界団体に所属していない出版社は沢山あるなあ。ウチだけじゃないってことだ。どこにも所属していない会社が全然売れていないかと言うと、そんなこともなくて、そこそこ売上があってもどこにも属していない社が多々ある。それ自体は不思議でもなんでもない。逆に、「業界団体に入っているからと言って売れるってわけではない」という当たり前を確認させられる。
が、しかし、そうだとすると業界団体の存在意義はなんなのか、なんとなく複雑な気持ちになる。
そうではなく、JPROは書協会員社以外に門戸を開いたところが素晴らしいという見方もできる。
んー、それもどうかなあ。結局、業界を網羅するようなDBなりなんなりってことを実現するためには門戸を開かざるを得なかったということか。
なんだかんだで900社近くの「ヨミ」と「WebサイトのURL」が整備できた。使いようによっては、また少し面白いことができそうな気がする。
それにしても、出版社のユニークIDが無いのはやっぱり困る。某オンライン書店も結局は文字列でぶつけてると聞いたが、こちらもそうせざるを得ない。出版社記号も取引コードも、ユニークIDとしては使えない。なかなかキビシイ。
あと、いまだにWebサイト用意してない出版社が割と沢山あって驚いた。SNSで充分という割り切り方もあるとは思うが、せめて名刺代わりに会社案内を載せたサイトとか、そういうのだけでもなあ、とは思う。思うが、ここでも色々考えさせられたが、Webサイトを持っていないからと言って全く売れていないというわけでもない。書店や図書館や採用などで回していたら無理してWebがどうこうとかって必要はないのかもなあ。一昔前は全部それで事足りてた。そして、問題なのは、今でもそれである程度回せてしまうということなのかも知れない。
ふたつめの宿題は楽譜販売用のDB整備とサイトの制作。サイトは今あるのにぶらさげる形で作るつもりだが、まずはデータの整備から。DL販売サイトから落としてきたリストで足りるかと思っていたが、かなり整理しないと難しいだろうということに。しょうがないので正規表現を使って諸々整理（そういえば出版社リストの整理も正規表現使わなかったら無理だった）。朝イチで作業して、午後再開しようと思ったら保存し忘れ。全部パア。で、イチからやり直し。二回目なので早い。が、最終的なサイトをどうするか考えてから付け加える必要のある項目が出てきたので、そこまで。これ、去年の年末も宿題だったので、今年こそなんとかしないと。
みっつめは、年末恒例企画のAPIをドットコムからopenBDに変更する件。去年やってなかったのか、オレ。ということで、これはサクッと完了。JSONのパースとか、わかってなかった時は本当に悩んだが、今となってはアッサリ。
年末恒例企画の参加者募集は明日以降メールで。去年は前年の参加者にまとめて送った。今年もそうしよう。
