Python+OpenCVで画像認識をやろうと
Python+OpenCVで画像認識をやろうと思い立ったものの、OpenCVのインストールで手間取った。というか、Pythonの実行環境の構築云々がよくわからない。環境無しですぐに始められるjavascriptは別格としても、PHPの場合はレンタルサーバーで使えたらエディターでプログラムを書いてアップロードして済んでしまう話なので、環境構築云々で頭を悩ますことがない。さくらインターネットではPythonも使えるが、３ではなく２系統なので、ネットで調べて「面白そうだ」と思ってすぐに始めてようとしても特に日本語のところで随分と書き方が違ったりする。それと、PythonでWebページを記述する場合にはPHPとは違ってなんか色々あるらしい（調べる気力を失っている）。
要は、「PHPって学習コストがどうこう以前の環境構築コストが低い（ローカルに艦橋を構築せずに始められる）んだなあ」と、そんなことを思う。書き方としていい悪いは別に、HTMLの中にちょこちょこっと書いたりも出来る。そういうのから入るヒトも多いんだろう。自分もどちらかといえばそちらだ。XAMPPでローカル環境構築とかも挑戦したが、かったるくなってやめた。そう言われてみるとMySQLもXAMPPで動かしてどうこうしてた時は触るのも面倒でなかなか進まなかったなあ。
サンデープログラマーで、「プログラムでなにか動かしたい作りたい」人は環境構築で苦労すると厳しいのかも。そこで挫折する人、多いんじゃなかろうか。もちろん、サーバーの管理や環境構築まで含めてしっかり勉強したいということであれば、手間を惜しまずやるべきなんだろうけど、俺はどうやら「サーバー管理とか環境構築とかすっ飛ばして動かしたい作りたい」のほうらしい。
で、Pythonだが、だいぶ前に入れたAnacondaのPromptを管理者権限で立ち上げてしまえば大抵の事が済んでしまうことがわかった。実行環境も、AnacondaのPromptでもいいし、WindowsPowerShellでもいいようだ。opencvは「conda -install」でスルッと入った（けど、import cv2だと気づかずに import cv で試して「入ってないなあ（やる気減退）」という時間帯があったのは事実）。それと、IDLEがJupyterがipythonがどうこう言われるが、BOM無しUTF-8で保存できる保存できるエディタ（最近はMeryを使ってます）で書いて好きなフォルダに拡張子.pyで保存すりゃいい、そのうえで、WindowsPowerShellでそのフォルダに移動してpython ファイル名.py（もしくは、python .\ファイル名.py ）で動かせるということも理解した。仮想環境がうんチャラとか統合開発環境がああだとかは気にしなくてよかったということだ。この程度の手間なら全然我慢できる。
まだ基本的なことしか試していないが、Python＋OpenCVだと画像処理、簡単に書けることがわかった。年末年始は画像認識と機械学習に挑戦する予定。
久しぶりの六本木
11日オープンの文喫の内覧会へ。本来の担当者が休暇のため代理で。
六本木なんて何年ぶりだろう。最後になんの用事で来たかも忘れてしまった。
大盛況。時間で区切っているが、トータル300人ぐらい来るそうだ。
定員が百名と聞いて「ああ、そうか、座席があるから」と納得した。100名一度に入ることはなさそうだ。ということは、開店後も割と落ち着いた空間として維持されるはず。
近所に椿屋珈琲店があった。1000円超えでも喫茶店を利用する客層はいるということだろう。駅からも近い。利用客のイメージとしてはビジネスマンなどなのだろうが、地方から仕事で出てきて一日限りの拠点を確保したい、みたいなのも有りなのかも。ロッカーも完備していた。
外に出たり人と会ったりすることが減って数年経つので、知ってる顔も少なくなった。前の会社（と言っても、もう20年近く前なんだな）では、上司にあちこち引き回されて色んな人と会ったが、それは稀有なことであったのだと、今さら感謝しているし、オレ一人だと全然出ないし会わないというのに軽く絶望もしている（というほど大げさな話ではないが）。
帰りは大江戸線で。森下乗り換えだと六本木は近いなあ。いや、そういえば、何の用事だか忘れてしまったが、前に来た時もそう思った。ということは、大江戸線開業後に来てるってことだ。
何の用事だったかなあ。全く思い出せない。
『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を使う必要がある。
と、思ったら、こんなページを発見。なるほど。諸々納得。
