『Speed Racer』予想以上によかった
以前、アカウントを間違えて登録してしまったGoogleプレイの残高が残っているので消化したい。
ということで、見たいと思っていた『Speed Racer』を。なんだ、これ、予想以上に面白い。ストーリーは単純だし、映像もいかれてるんだけど、なんだろうなあ、分かりやすいのに惹かれてるのかなあ、家族の絆や勧善懲悪みたいなストーリー。まあ、全体通して見ると、明らかにいかれてるんだけど。
そのうちまた見たい。
Go! Speed Race!
Go! Speed Race!
Go! Speed Race! Go! マッハゴーゴー!
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を使う必要がある。
と、思ったら、こんなページを発見。なるほど。諸々納得。