piu lentoの日々 (piu lento days)

ISRC(International Standard Recording Code)は音楽の演奏(正確には録音)固有の識別記号で、世の中のレコードでもCDでも何でも、同じ録音なら同じ値で示せる。つまり、コンピュータの文字ならUnicode、日本の何か良く分からないシステムｗならマイナンバーのようなものだ(どこかに書いてあった)と信じていたのだが、そうではなかったようだ。。。

というのは、今日、何の気なしに(という訳でもなく、別件の確認がてら)、開発中のシステムの再生履歴のページを見ていたら、表面的には何もなかったのだが、デバッグ情報に見慣れないメッセージが出ていたのだ。そして、再生履歴を確認したら、確かに再生したのに履歴に出ていない曲があったのだ。

その直接の原因は、どうも、「変なプレイリスト」を再生したからのようだ。いや、そもそもSpotifyなので、変なものはできないはずなのだが、海外の団体が作ったせいか、含まれている曲(の属性?)が日本には合っていなかったようなのだ。

更に詳しく書くと、そのプレイリストで再生した曲には他の曲同様にISRCが付いているのだが、それでSpotifyを検索しても出て来ないのだ。それではと、その曲の題名やアーティスト名で検索したら、ISRCが異なるものが出て来た。それだけなら、まあ、リマスターとかリミックスの可能性があるのだが、検索の結果はその1曲だけで、出て来なかったISRCの曲は含まれていないのだ。更に、MusicBrainzで検索したら、なんと、その曲には6個ものISRCが付いていた・・・ これって、ある人に6個のマイナンバーが付いていて、しかも、普通に検索しても分からず、それぞれ別の人に見えるのと同じことだ・・・ 破綻してるよ!

ちなみに、問題のプレイリストは"80s Classic Hits"で、曲は、Bon Joviの"You Give Love A Bad Name"(アルバムは"Slippery When Wet", 1986)である。「変な」ISRCはNLF059290010で、Spotifyで一般的らしいのはUSPR39402224だった。もちろん、それぞれSpotifyのIDも違う。Spotifyの検索API(Search for an Item)のwebでも出て来ない。ただ、SpotifyのIDから生成されるURLを指定すればちゃんと表示・再生できるので、日本では不可という訳ではないようだ。そして、MusicBrainzでは同じ曲(演奏)の扱いだ。もちろん、この曲だけでなく、変なのは他にもある(→ PS3)。

まあ、いろいろな可能性はあるだろうが、いろいろな国や地域のレーベルがいい加減なことをして、(その国や地域での)再発なのに新たなISRCを割り当ててしまったのではないか。システムを検討する時に参考にしたビートルズは厳密に管理されているから分からなかったが、普通のバンドではそこまで手が回らないのだろう。それは理解できるが、

全く困る!

これでは、何をもって、「この曲は聴いた」と判定すればいいのだ。曲の題名などでの判定なんて、全くできない。さまざまなバージョン違い(初出、再録、ライブ、リミックス・・・)があるからだ。もちろん、CDの型番なんて更にひどい。

という訳で、ISRCを曲(演奏)のIDに使っている、今作っている音楽再生履歴・評価管理システム(仮)の根幹が揺るいでしまった。実際にはISRC以外もIDとして使えるように考えていたので、全く無意味になった訳ではないが、結構ガクッと来た。

PS. まあ、西洋だからってものすごくちゃんとしている訳ではないってことだ(それでも日本よりはマシだと思うがｗ)。Unicodeだって、実際には妥協の産物のおぞましいもので(それでもJISやSJISやEUC、その混在よりはずっとマシだろう)、前にも書いたが、さまざまな似たような文字がてんこ盛りだ。

PS2. ISRCが駄目だとして、代わりをどうすればいいのか考えても、いい代替は浮かばない。現時点ではMusicBrainzのIDが一番まともだが、使うのは気が進まない。今はいいが、継続性に疑問があるからだ。

(5/29 13:25追記) 以前考えて保留にしているのは、音響指紋というものを使うことだ。簡単に言えば、その名のとおりだｗ 今はいろいろなプログラムが出ているようなので、計算するのは容易だ。ただ、計算が少し重いので気軽にはできないのと、その値をISRCのように短く表すことができない(MusicBrainzだと、アップロードしたものは短く表せるようだ)のと、公開DBがそれほどない(無料なのはMusicBrainz程度?)のが問題だ。

いずれにしても、なぜかMusicBrainzに依存するみちばかりで、ちょっと躊躇している。

まあ、MusicBrainzのサービスを使わなくても、指紋は演奏の同定だけに使うことにして曲情報はSpotifyやMusicBrainzやDiscogなどから(今は必然的にSpotifyになる)適宜取得するなら、MusicBrainzに依存しなくても行けそうではある。指紋を短くするのは、MD5とかCRCなどでダイジェスト処理すればできるから、(短くしたあとで重複しなければ、)それほど大きな問題ではないかも知れない。

この方法のメリットは、今回の問題のように、同じ曲なのに複数のISRCが振られていても、指紋は一緒になるはずなので、必ず(本当かなあ?)同じ曲だと分かることだ。

なんかいい感じがして来た(でも、今までの経験から、必ずどこかに落とし穴があるんだろう)ｗ

↓

さっそく落とし穴があった。Spotifyのような配信サービスでは、合法的に曲のデータ(ファイル)が取得できないから、自分では指紋が計算できない。サービス提供元が指紋を提供してくれるか、MusicBrainzなどの公開DBでISRCなどを使って検索して取得するしかない。

やっぱりMusicBrainzか・・・

指紋の取得元を特定のサービスに限定しないように作ればいい気もしたが、指紋の計算方式にはいろいろあるから、それは無理そうだ。この場合は指紋をDBに保存せずに、常にサーバから指紋を取得ればいいのかも知れないが、それにも欠点はある。

PS3. 他の「変な曲」は、これが問題に気付いた原因なのだが、ISRCでSpotifyを検索すると曲情報は出てくるが、その内容がおかしいのだ。形式的には正しいのだが、やっぱり元のプレイリストが「変」だったようで、そのプレイリストで再生した時の情報とは異なる曲しか出て来ない。例えば、検索で出て来た曲は、再生した時のものとはSpotifyのアルバムIDやトラックIDが異なっている(そして、普通に検索してもこれらが付いている曲は出て来ない)。そのために、僕の再生履歴DBの曲とマッチしなくて、再生履歴に出なかった。

こういう曲はISRCで検索できるからまだマシで、異なっている情報のうち、再生履歴DBにないもの(例: 曲再生用URL)はDBの内容(例: トラックID)で修復(補完)して表示できるようにした。ただ、DBにない情報は無理なので、例えばジャケット画像は出せず(「何か」出せばいいのなら、検索で出たものを使えばいいが、例えば、その曲が入った別のアルバムが出てしまう可能性もある)、そこが歯抜けになってしまう。

PS4. その後、Spotifyの検索API(Search for an Item)でISRCでの検索がまったくできなくなってしまったので、APIの機能が変わったのか(まだ、ドキュメントではできることになっている)、もともとあった不具合の影響が増大したのかも知れない。 (6/5 7:17) → 結局、この問題(ISRCで曲が検索できない)は、SpotifyのトラックIDで検索することで回避した。つまり、SpotifyのISRCはあてにならない(検索で出ないことがある)ようなので、そもそもSpotifyの曲なのだから、SpotifyのトラックIDで曲を検索すれば何も問題はなかったのだ。灯台下暗しとか、コロンブスの卵とでも言うのだろうか。 (6/5 19:51)

(6/5 7:17 加筆・追記)

動作確認や修正や暇つぶしにSpotifyの再生履歴記録・検索システム(仮)のページを眺めていたら、なかなかおもしろいことがあった。単にテストのために思い付いて入れたのだと思うが、(ビートルズの)"Sgt. Pepper's"での検索結果を見ていたら、本物以外に数多くのカバーがあった。

それは当然だから驚きもしなかったし、ほとんどは「いかにも『カバーしてみました』」って感じで全然興味が湧かなかったのだが、数が多いのに感心して下まで見ていたら、2作、目をひくものがあった。一つはある意味恐ろしい問題作ｗ、もう一つは感心するくらい良かった。こんなに幅広いとは、さすがビートルズだ。

まず、「問題作」は、大場久美子のカバー(シングル)、"Sgt. Pepper's Lonely Hearts Club Band"(１９７９?)である。そもそもこの人がこれを歌う意味や理由が不明だったが、「怖いもの見たさ」で聴いてみた。が、あえて書こう、

ひどい・・・ 下手過ぎる。

数秒ではなかったが、(記録によれば)1/3くらいで止めた。もちろん、評価を-5(最低)にした。なんでこれが発売されているのか謎なレベルだ。そういえば、これの入っていたベスト盤の曲目を見て、「あれ? 『狼なんて−』とか、ヒットがあったはずだが・・・」と思ったあとで誤解に気付いたのだが、大場久美子は「コメットさん」ではあったが、石野真子ではなかったのだ(もちろん、浅田美代子でもない)ｗ 石野には大変失礼なことをした。

気を取り直して、次のAndy Timmonsという人のカバーアルバム(ビートルズのと同じ曲目+1)、"Andy Timmons Band Plays Sgt. Pepper"(2011)を聴いてみたらなかなか良かったので、通して聴いた。一つだけ残念な曲("Being for the Benefit of Mr. Kite")※はあったが、それ以外はどれも好意的に聴けて、全体的にはとても良かった。

※残念だった理由は、この曲は大好きな曲なので期待して聴いたら、最初は良かったのに途中から"I want you"になって だらだらしてしまったからだ。本人としてはそうしたかったのだろうが、この曲はきびきび・活発で簡潔なところがいいのに、どろどろしてしまうのはちょっと違うと思った。

そもそも、なぜこれにひかれたのかは分からないが、ジャケットの雰囲気で期待させられたのだと思う。良くあるカバー作は、オリジナルを下手に真似てとてもセンスが悪いのだが、これは全くそうでなく、ストイックに、演奏したいからしたというような雰囲気が出ているところがいい。

石野真子とAndy Timmonsが並ぶ、シュールな再生履歴

※↑ 投稿時に酔っていたのだろうか、「大場久美子」と書くべきところを「石野真子」と書いていた。本当に混同していた証拠だ。申し訳ないので、訂正せずに恥を隠さないことにする。 (5/28 20:04)

という訳で、このシステムの検索機能はまだまだ開発途上ではあるのだが、それでもいろいろ遊べることが分かって「ご満悦」であるｗ それ以外に、昨夜、やっぱりテストや好奇心で検索結果を見ていたら、今まで聴いたことがないラフマニノフのピアノ協奏曲第3番の演奏(Lukas Vondracekのエリザベートコンクールでの演奏, 2016)が見付かって、早くも本来の用途に役立ったから、改良すれば便利になりそうだ。※

※これを書くのに、その演奏が誰の何だったか調べようとしたのだが、履歴検索はまだ手軽にできなくて(SQLの一部を打ち込むので、気軽に日付で検索するなんてことはできない)ちょっと苦労したけど(日記やDBブラウザを見れば一発だが、意地で使ってみたｗ)、ちゃんと見付かった。

SpotifyのRelease Radarで新作を聴いていたら、中に竹内まりやの「ドリーム・オブ・ユー~レモンライムの青い風~」(1979)が入っていた。そういえば、近頃入ったというのを読んだのを思い出した。もちろん曲は懐かしかったが、ジャケットを見て更に懐かしくなった。

竹内まりや "UNIVERSITY STREET" (1979)

テニスのラケット! そして、ファイル(みたいなの)! まさに絵に描いたような女子大生だ。そして、ポニーテールと白いTシャツがいい。(実際に見たことはないが、)昔の都会にはこんな女子大生が大勢居たらしいけど、見事に絶滅したねぇｗ 呼び方もJDなんて味気もセンスもないものになってしまったな。

PS. (典型的な女子大生の写真やイラストを見て)当時から不思議に思っていたのだが、これだけの物しか持たずに済んでいたのだろうか? ファイルみたいなのは教科書数冊のこともあるが、それ以外の教科書や資料やノートや筆記用具は要らないのだろうか。文系の学生は授業が少なくて、そういうのは余り要らなかったのだろうか。あと、スマフォや携帯電話やゲーム機など(それらは当時はラケットだった??)は当時はなかったがｗ、お金や定期券や、女性なので化粧品などは不要だったのか。今となっては謎が多いｗ

Spotifyの再生履歴記録・検索システム(仮)が大分できて来た。まだまだやりたいことは多いし、修正・改良すべき点も多いが、一段落した感じだ。

見た目が前回とほとんど変わらないのが残念だがｗ、7割くらいはできた気がする。それにしても、いつものことだが、体感で半分を超えると、ぐっと進みが遅くなる。できあがるにつれて、完成度を高めるために作業量が増えるうえに、動き出して使ってみると新しいアイデアが出てくるので、更に作る量が増え、そのために修正や動作確認をする時間も雪だるま式に増えて、逃げ水のようにゴールが遠くなる。

前回からいろいろやったのだが、見た目のインパクトが大きいものは、ボタン一発でSpotifyの再生履歴が出せるようになったことだろうか。前回は再生中の曲だけだったのを、(DBのコマンドを駆使して)指定した数の過去に再生した曲を取れるようにした。もちろんSpotifyアプリでも出るが、自分で作ったので随分使いやすい。例えば、評価やコメントをあとから手軽に書けるようになった。他には、webなので、タイトルなどをコピーできるのは誰にでも便利な気がする(もちろん、web版Spotifyでもできるが)。

あとは「できたてのほやほや」(でまだ満足に動かないｗ)のアルバム表示機能も便利だ。検索結果や再生履歴に表示されている曲のアルバム名をクリックすると、そのアルバムの曲が全部表示される(書くと当たり前の機能ではあるな・・・)。他に、Spotifyのアルバムやトラックへのリンクも表示するようにしたので、日記やブログで参照するのも楽になりそうだ(ミニプレーヤーでは簡単だが、アプリだとメニューを数段階移動しないと取れない)。

逆に、苦労して作ったけど意外に使っていないのは再生機能だ。これはアプリで充分だ。でも、そのうち検索機能(これが一番の目的なのだ)が充実したら使うかも知れない。

そして、今日の夕方くらいから、聴きながらコメントや評価を付けたり過去の感想を転記したりして、実際に使っている。自画自賛だが、なかなか便利だ。最初はそれらはDB管理アプリ(DB browser)で入力・修正していたのだが、段々使う機会が減って来た。

残件で大きいのは、ミニプレーヤーとの連携(履歴や評価のアイコンを出す、手軽に履歴を付ける、コメントを書くなど)だ。それから検索のプリセットの作成(今は検索条件にSQLの一部を打ち込んでいるのを、いくつかのパターンから選べるようにする)だ。

作っていて思い付いたのは、Spotifyのリコメンドでない、「自分のリコメンド」(履歴と評価をもとに、自分の好きな曲だけを選んで掛ける)を再生できるとおもしろそうだ。そこまでは行かなくても、意味があるかは別として、このシステムに自分のプレイリストが作れる。将来、別のプレーヤー(gmusicbrowser)とも連携できたら、プレーヤーをまたいで再生できるようになるからおもしろそうだ。

もう一つのアイデアは、嫌いな曲が掛かったら即座に自動で飛ばす機能だ。これはすごく便利そうだｗ ただ、たまに気まぐれで聴きたい時もあるだろうから、ある程度の猶予時間が要りそうだ。

ちなみに、このシステムを作ろうとしたのは、Spotifyをより便利にしたいこともあるが、自分の再生履歴や感想を記録するためでもある。だから、Spotifyに特化したものやべったり依存するものを作ろうとしている訳ではない。仮に将来、Spotify以外のサービスに乗り換えたとしても、記録した情報は使いまわせるようなデータ構造にしている。ただ、そのサービスにSpotifyのようなAPIがないと、再生した曲の自動記録はできないので、そこが結構重要だ。更に、配信サービスを止めたとしても、いいと思った曲の記録は残っているから、買うなどすれば聴くことができる(DBにはそれぞれの曲のISRCを記録しているので、何らかの形で配布されていれば、その演奏が聴けるはずだ)。

なお、最初に少し心配していたDBのサイズだが、文字しか入れていないので当然ではあるが、とても小さい。今までの約2週間で940曲くらい記録したが、DBファイルのサイズは320KB程度なので、1曲あたり300バイト前後だ。ずっとこのペースで行くとすれば、1年では2.5万曲くらいになり、サイズは7MB程度で済みそうだ。なお、定期的にバックアップや"vacuum"というコンパクト化の処理も行うようにした。

PS. 作っていて思ったが、Googleなどのサーバには、こんな感じで、各ユーザのいろいろな履歴がまさに山のように記録されていて、すごいAIがあれば(きっとあるんだろう)何でも分かってしまいそうだ。技術的にはおもしろいけど、僕はなるべく"Let me out"させてもらいたいｗ

でも、それとは関係ないけど、Googleの画面作り(配色・配置)は嫌いじゃないｗ このシステムのwebページの雰囲気が似ているのは、そのせい(好みの近さ)かも知れない。特に似せているつもりはないが。そして、ダークモードは大嫌いだｗ

以前から何回か触れていた、「実質ガッキー」と言われていた椎木という人がYouTubeを始めたというので、当然ながら酷評はあったものの、観てみたら、頭の1秒未満で「駄目」という結論に達した。

僕は、訳もなく世間から叩かれてしまっている人には、判官贔屓のように「頑張って」と言いたくなる(今までに何回かここに書いた。例えば沢尻や昔のJRスキーの人(川口)だ)のだが、彼女には全く起こらない。やっぱりセンスがないんだろうな。だって、例えばイチローのような国際的な有名人でもないのに、頭っから

Hi everyone♡

はないだろう。もう、1秒未満(0.3秒くらい?)で耐えられずに止めて、Thumbs downを押したよ(キャプチャを見ると、実際には数秒は観たようだ)。まあ、可愛い(かどうかは意見が別れるだろうが)かも知れないが、センス・能力がない。これを観てもらいたい相手を分かってない。いい歳して、「なんか作ればきっと受けるだろう」という安易な気持ちで作ったのではないだろうか。いや、逆にとんでもない数のThumbs downをもらいたくて作ったのかも知れない。それなら大成功だ(観た時はUp: 433/Down: 1.1万で、downはすぐに千増えた)。

いずれにしても、まったくもったいない。だから、これを機に忘れるということもなく、これからも冷ややかな目で見つめ続けたいと思う次第だｗ

(5/28 20時 追記) 本当かどうかは分からないが、彼女は留学経験がないとのことだ。なるほどと思った。それが本当なら僕の違和感の一因だと思う。留学は必須でもなんでもないと思うし、そもそも、英語(=道具)が話せること自体に意味も価値もないとも思うけど、彼女は、真に必要で英語を話したことがないし、それ以前に、英語圏(西洋)の考え方を分かっていないのだろう。だから、日本人しか見ないYouTubeなのに英語で挨拶してしまったのだと思う。

とは言え、僕だって留学したことなんてないし、英語圏(西洋)の考え方を分かっているか まったく怪しいものだがｗ

PS. 今思ったのだが、こう思う理由は、この人は確かにしょうもないけど、決して、「CDで握手/投票」なんてクソみたいなことをするほど世の中を舐めていないからかな? あとは、烏合の衆よろしく何百人もで徒党を組むことなどせず、自分で悪評を引き受けているのは、数少ない認められる点だろう。だから「とりあえず観た」のかも知れないｗ

(5/22 7:34 誤りを修正)

今回の趣味の開発でいろいろ困っては小技を見付けて対処しているのだが、一番困るのは、JavaScriptからPHPが呼べないことだ。もちろん、外部プログラムも実行できない。実際には、それができたらブラウザが危険極まりないものになってしまう(ActiveXみたいな話?)からあり得ないのだが、僕の今の用途では、是非ともJavaScriptやHTMLからPHPや外部プログラムを実行したいのだ。

というのは、例えば、曲の評価の変更のユーザ操作はHTMLとJavaScriptでしか実現できないが、変更した値をDBに書き込むのはPHPや外部プログラムでしかできない。まあ、JavaScriptでライブラリを探して使ってネット経由でDBのサーバにアクセスすることはできるのかも知れないが、大掛かりになってしまう気がする。

そういう時、基本的には、JavaScriptやHTMLからリンク経由で別の保存処理をするページに飛び、その時に必要なデータを引き渡す。飛び先のページではまずPHPが動くので、渡されたデータをDBに書いたり外部プログラムで処理することができる。

そのデメリットはページが変わってしまうことだ。大昔はそういうのばかりだったが、今はページ遷移なしで処理するのが当たり前になっている。見栄えだけならいいが、ページの状態を全部引き継ぐことができないのが問題だ。今回はSpotifyの検索結果(結構大きくなる)を引き継ぐのが面倒だ(遷移するたびに検索し直すのは無駄だし遅くなる)。検索結果を引き継ぐのは不可能ではないが、中間ファイルが必要になるだろう。

そこでいろいろ考えたら、2つの方法を思い付いた。最初に、HTMLのiframeを使う方法を思い付いた。PHPや外部プログラムの機能が要る処理、例えば、データを保存するのに別のページに飛ぶことは必要だとして、今のページも残せる方法を考えたら、iframeが使えた。以下のような流れになる。

1. データを保存する契機になる。
2. iframeにデータを保存するURL(保存するデータも一緒に)を指定して開く。(実際には、このURLは自分自身で、引数を特別なものにして行う処理を指定している)
3. そのURLでデータの保存が実行されるが、結果はiframeの中に(小さく)表示されるので、今のページはそのまま残る。

JavaScriptを使えば一定時間後にiframeを閉じることができるので、下の方に小さく作っておけば、見た目のインパクトも少ない。

しかし、その後もっと簡単な方法に気付いた。JavaScriptでデータを保存するURLを指定して開くのだ。これなら結果は表示すらされない(しかも、JavaScriptで結果が受け取れる)ので、まったく楽だ。昔流行った"AJAX"らしい(今はfetchという機能がいいようなので、それを使っている)。この場合は以下のような流れになる。

1. データを保存する契機になる。
2. fetchでデータを保存するURL(保存するデータも一緒に)を指定して開く。(上と同様に、このURLは自分自身で、引数を特別にしている)
3. fetchでURLの結果を取得して処理を開始する。

ただ、これの問題点は、URLを開いた(処理を実行した)結果を待てないことだ。fetchの中では結果は受け取れるが、fetchを実行した側はそれが終わるのを待つことができない(fetchが開始したことが分かるだけ)。それで、fetchの中(URLを呼んだ節。スレッドのようなもの)でfetchが終わった後に結果に対応する処理を行う必要がある。JavaScriptが非同期なための手間だ。

でもまあ、この(AJAX)の方法に気付いたおかげでiframeすら不要になって、Spotifyプレーヤーでの再生開始やDBのアクセスなどが手軽に(とは言え、実際のプログラムは、実行したい処理を自分自身(のプログラム)で行うにも関わらず、ネット経由で再び起動されたりするので、ものすごく煩雑だし効率も悪い)できるようになったのはありがたい。

ただ、僕としては、そもそもそういうことをネット経由でやるのが気に入らない。もっと普通のやり方があるのかも知れないので、おいおい考えてみたい。まあ、全部JavaScriptで書く(例: Node.jsとかElectronとか)のがそれなのかも知れないが、非同期は「普通」じゃなくてすごく疲れるからねぇ・・・

あれから寝食を忘れてｗ作っていて、web(検索画面)が大分いい感じになって来た。何をどう良くしたのか、思い出したり調べて書くのも面倒だが、僕的には随分良くなった気がするｗ 例えば、評価を色の濃さで出す(図中の♥マーク)とか、平均「完奏率」(最後まで聞いたか)※を棒グラフで出すとか、前の投稿に書いたが、再生をwebでなくSpotifyプレーヤーでできるようにしたとか、トラック情報を開閉できるようにした辺りだ。まだまだやることは多いが、それなりの形にはなって来た。

※「「完奏率」(最後まで聞いたか)」は少し誤解しやすいので補足すると、1曲を最後まで聴いたら1、途中で止めたり飛ばしたら0なのではなく、止めたり飛ばした時点までの再生時間の曲の長さに対する割合が1回の完奏率になる。例えば、半分まで聴いたら0.5である。その合計を再生回数で割ったものが平均完奏率である。

プログラミングしていると時間がすぐ過ぎるし、おやつはもちろん食事も面倒になるから、ダイエットになるうえにお金も掛からないおから、いいことづくめだね。ってなんか、シャレにならないけど、そんなことはないよｗ これからの人は、みんなプログラミングするみたいだから、メタボになる心配はなさそうだね。頑張ってね!(爆)

↓

(5/19 20:58) その後もいろいろ改良していたが、見た目は劇的には変わっていない。Spotifyは、どうしてか、クラシック音楽の作曲者をアーティストに入れてしまうので、ミニプレーヤーでしているのと同様に削除するようにしたことと、「現在再生中の曲」をボタン一発で出せるようになった(図の中央上部の"Now playing")のと、評価をスライダーで設定する(図の右下)UIができたくらいだ。もちろん、普段はスライダーは出ていないし、評価を変えたらアイコンも色も変わるよ!ｗ (→ デモ動画)。HTML5のおかげで、こういうの(inputのrangeというのを使った)が手軽に(とはいえ、何度も書くが、HTMLだのJavaScriptは苦手なのでそれなりに苦労したがｗ)できるようになってありがたい。

今は、コメント欄もトラック情報や評価と同様にアイコン(ボタン)を押すと開いて入力できるようにしようとしているのだが、UIの概形ができたところで力尽きているｗ 不思議なことに、余り考えずに「これだとどうなるかな」とテキトーに作ったら、「こうなったらいいね」っていう感じに入力欄が開いたので、何かの奇跡かと驚いた。 ← イマココ(ってやつ)ｗ

体験談的なことを書くと、SQLはなかなか馬鹿にできない。なんというか、僕から見れば「しょうもないもの」だったのだが、ちゃんと完結していて、(苦労して)使いこなすとかなりいろいろな検索や処理ができることが分かった。DBの基本のトランザクション※も便利だ(普通にプログラムを作るのでは実現が面倒なことが、1行でできたりする)。どういう経緯で今の状態に至ったのかは知らないが、最初からこういうのを考えて作ったのならすごいことだ。ただ、今使っているSQLiteはとっつき安いのはすごくいいものの、他に比べて若干機能が少ないので、凝ったことをしようとすると手間が増えるのが残念だ。

※トランザクションの例: 「DB中の、名前がAのデータの要素bの値が10より小さかったら+1して書き込む」が1行でできる。しかも、この1行(SQL)の処理は不可分なので、複数プロセス間での競合が起こらない。あるプロセスが読み出して+1して書き込む前に他のプロセスが+1して書き込んでしまうなんてことがない。

あと、以前も書いた気がするが、PHPとJavaScriptとHTMLを同じファイルに書くので、ちょっと見てもなんだか分からないし、それぞれ文法が違うからいつも間違うし、その部分がいつ実行されるのかを誤解するし、文字列を囲むレベルが増え過ぎて囲むのに使える文字がなくなったりして、かなり厄介だ。一番不便なのは、JavaScriptからPHPの機能が呼べない(あるいは、戻れない)ことだ。よく考えれば当たり前(実際には、PHPからJavaScriptを呼ぶことだってできない)なのだが、そこが何とかできると楽になると思う・・・ だから、サーバ側も全部JavaScriptで書く例が増えているのかも知れない(ここはよく分からない)。

↓

(5/20 22:09) コメントのUIも何とかなった。(→ デモ動画) 昨日から何も変わってないように見えるが、見た目を変えてないから当然だｗ あとはやっつけ仕事で作った下回りの処理(DBへのアクセス)などをちゃんとしたい。

コメント設定機能も動き出した。

それから、SQLiteへのネット経由でのアクセスは、rqliteというもので可能なようなことが分かった。その他に、socatとsqlite3コマンドを使って自分で実現することも考えられた。後者は全く面倒で安定性に欠けるから論外だが、前者は何となく筋が良さそうだった。が、他にも同様に「自分」に通信する必要があるもの(例: Spotifyでの再生)があるので、ひとまず保留にした。

(5/17 21:00 完奏率について補足; 5/19 20:58 現状を追記; 5/20 22:09 現状を追記)

先日から始めた、Spotifyで聴いた曲を自動で記録し、検索結果と一緒に表示する仕組み(一言で何と言うのか、まだ迷っている)のプロトタイプが動き出した。画面(web)は以下のような感じだ。プロトタイプなので、トップは太古の「ホームページ」ｗのように、余りにもシンプルだ。検索結果は少し(結構)凝って、(力技でｗ)それなりにした(まだ細かい問題は多い)。

もちろん、主目的の再生履歴が出るようにした。再生した日時(自動で記録される)はもちろん(今は最初の日時のみ)、評価(今はDBに手入力する)が♥(好き)や✘(嫌い)で出るし、コメントも出る(これも今は手入力)。そして、ジャケット画像やアルバムや曲のリンクを押すと、ちゃんと再生できる(今はまだSpotifyのwebプレーヤーに飛ぶだけ → Spotifyのプレーヤーアプリで再生できるようになった → デモ動画)。

全体的な構成の概要は以下のとおりである。

Spotifyプレーヤー      ⇔    ミニプレーヤー・リモコン
 ↑                         制御                |
 |                                               ↓
 |        再生曲情報の自動記録 ← (再生曲情報ファイル)
 |再生         ↑↓
 |指示   DB (SQLite)
 |          ↓再生履歴
検索画面(web)  ⇔  Spotifyサイト
                     検索(API)

検索条件の指定方法は模索中だ。今は、Spotifyの条件(これが結構使えない・・・)と再生履歴の条件を別にしている。後者は、なんとSQLの条件式を入れるようにしている(画面上部の"History search"の欄を参照)。今はこの方がいろいろ試せるからいいのだが、将来的には「再生したことがない」/「−ある」といった、プリセットのようなものを選択できるようにしたい(画面中の式は「再生したことがあるアルバム中のトラック」の例)。

RDBのSQLにはなかなか苦労したが、大分使えるようになった。慣れれば便利な感じだ。でも、泥沼のように奥が深いようだｗ それ以外にも山ほど考え・試行錯誤・工夫・苦労した話があるし、「とりあえず」や"TODO"も山ほどあるｗので、あとで書きたい。まずは作るだ。

↓

その後、大分改良できた。検索結果が多い場合に画面がとんでもないことになるので、どうしたらいいものか考え、(良く見るが)開閉ボタンでアルバム中のトラック情報を表示・非表示できるようにした。アルバム情報の下の"♪"を押すとトラック情報一覧が出て、再度押すと消える。(→ デモ動画)

やる前は、大の苦手なJavaScriptを使うのが嫌なので、何とか別の方法がないか考えていたのだが、なかなかなくてJavaScriptでやらざるを得なくなった。もちろん、(僕の技術で)できるのか分からなかったが、その前に検索ページからSpotifyプレーヤーで曲を再生するために使った方法(なかなかトリッキーなので、あとで書きたい)がヒントになったので、意外に容易に「それなり」にできた。

こういうのは、世の中に出回っているいろいろなライブラリを使えば簡単なのだとは思うが、そもそも、何が一番使いやすいのかも分からず、選んで使うのに慣れるまでが大変な(気がする)ので、自分で「適当に」作った。きっと、どこかに落とし穴があるに違いないｗ (5/15 17:32)

(23:51 システム構成を追記; 5/15 10:40 Spotifyプレーヤーでの再生のデモ動画を追加; 5/15 17:32 トラック情報表示の件を追記)

ニュースに「10%の食塩水1kg作るのに必要な塩と水は?　大学生が｢%｣を分からない絶望的な日本」というのがあって、どうももやもやした。僕も間違える気がするのだ。

というのは、これは昔からある引っ掛け問題で(小学校の頃に引っ掛かったか教わって、それ以来、苦手意識がある)、最後に1kgにしなくてはならないので、単純に1Lの水に食塩100gを入れるのでは間違いなのだ。でも、化学の実験はともかく、日常生活ではそれで充分な気がする。

誤差を計算すると、

• 正しい場合: 10% (正答: 900gの水に100gの食塩)
• 誤答の場合: 1Lの水に100gの食塩を入れた場合、9%
• → 誤差率: -10%

なるほど。意外に誤差が大きいようだ。でも、大きな問題はない気がする(ちゃんとした料理だとそうでもないのかな)。

あと、正答を転記して思ったのだが、この%は重量率なのか容積率なのか不明ではないか。全部gだから重量率なのは自明なのか。そこで引っ掛かる人も居そうだ。細かくチェックするならちゃんと書けって言いたい。それに、「水900g」ってすごく違和感がある。器でなく秤で測るの? 濃度を室温に無関係にしたいのか。

それから、そもそも食塩が水に10%も溶けのるかという疑問もある。調べたら、常温で20%以上溶けるようなので問題なかったが、どうも、問題以前にこういうところでつまづいてしまいそうだｗ

PS. このニュースの題は今ひとつ適切でない。本文を読む限り、大学生が食塩水の問題を解いた訳でない(解いたのは中学生のようだ)のだ。近頃はこういうのが多くて、そこにももやもやする。あと、全角スペースは使うなとあれほど(略)ｗ

先日、前回から一か月おいて歯科に行った。随分混んでいるようだ。前回は、左上の奥歯の詰物(金属)と歯の境目に穴が開いているので、セラミック(保険外)か金属(保険)のどちらにするか決めるように言われた。保険の金属はどうも良くない(今回のように、境目から虫歯になってしまう)感じなのでセラミックがいいのだが、ダメ元でレジン(保険)は可能か聞くことにして行った。

その日はなぜか寝不足だった。そのせいか、なぜかハイな感じになっていて、椅子に座るなり、衛生士さんにレジンが可能か聞いた。いつもは聞かれるまで待つのだが。すると、範囲が大きいから無理とのことなので、セラミックにした。

ここまでは想定範囲内だったのだが、ここからが予想外だった。なぜか、ディスプレイには(左でなく)右上の奥歯の写真が出されていて、歯科医師(前回の院長から変わり、息子のようだ)は、「右上奥歯の根本に亀裂があるので、そこを治す」と言った。

はい?

(確かに右は僕も気になっていたけど、)話が全然違うんですが。。。 結構驚いたし、(上述のように)寝不足でハイだったので、いつもと違って少しキツく反論した。前回の写真の確認などをしてもらって、左も要治療なことを分かってもらった。

ただ、謎なのは、前回はちゃんと左の奥歯の金属の写真で説明されたし、右も、写真を見ながら縦筋は割れではなさそうだから様子見という話を聞いたのに、どうして、今回は右の治療になっていたのだろうか。そういう記録があったのだろうが、それはいつ誰が書いたのか。前回の院長がトチ狂っていて言動が一致していないということ?? あとで記録を書いた時に、忘れたとか疲れとかでどっちか分からなくなって取り違えた? いずれにしても結構恐ろしい。こういう感じに医療ミスが起こるのかも知れない。何も言わずにいたら、別の歯を抜かれてしまったとかいうトラブルがあるのも分かる。

そして、セラミックと金属の選択でレジンは無理という話も右のことだったと思われたので、改めてレジンが可能か聞いたら、可能だということだった。もちろん耐久性は劣るとは言われたが、(僕の期待どおりになったので、)聞いてみて良かった。なお、右は削る範囲が大きいのでレジンは駄目だそうなので、セラミックにすることにした(今は昔より広くレジンが使えるようになっていることを読むが、それは都会とか最先端の話だし、常にそれが正しい・可能な訳でもないだろうから、ここで頑張ることはしなかった)。

結局、前回診てくれた院長がボケていた駄目だったようで、その時の鋭い衛生士さん※(と僕)だけが正しかった訳だ。

※今回と同じ人だったかは不明。雰囲気は同じような気がしたが、言動が違う気もした。寝不足のせいで、今ひとつ分からなかったｗ

というか、

あのジジイなんとかしろ!

すごく意外だが、こんなこともあるようだ。ただ、今回の歯科医師は若いせいか技術がありそうで、手際良く、丁寧に確認と説明をしながら治療してくれたので、最終的には安心した。次回も彼だといいのだが・・・

最後に、偉そうにも教訓めいたことを書けば、人は必ず間違えるので、それを前提に行動しないといけない。だから、患者も可能な限り考えて確認しないといけない。「言われたとおりにしていれば問題ない」なんてことは全くない。なんかのドラマで「私はミスしない」とかのたまう医師が居たようだが、アホかバカか、「出直して来い!」だ。そんなのに掛かったら却って怖いよ。

PS. 寝不足のせいでボケていて、隣の治療室(板で区切っているだけ)の衛生士さんの声が大きくて、その「型取りますねー」とかいうのが僕に言われているように勘違いして、数回「はい」と返事してしまった。こっちの衛生士さんは ちょっと驚いていた感じもしたが、無視していた。そこは微妙にいいような悪いような気がした。でも、若い頃と違って、このくらいでは全く恥ずかしく感じないｗ

PS2. レジンにできたおかげで、今回の治療費は2千円未満と、激安で済んだ(彼らにしてみれば、全然元が取れないのだろう)。

PS3. 気付いたら、保険の金属の詰物は2個だけになっていた。以前はかなり多かったが、長年掛けて(悪くなるたびに)セラミックやジルコニアやレジンに交換したおかげで、光るところが大分減って いい感じだ。

PS4. 一見関係ないが、秋のブロンフマンのコンサートは諦めた。冗談のようだが、セラミックの歯と同様の料金なので、歯を優先することにした。さすがに両方は使い過ぎだ。それに、前にも書いたが、今はルガンスキーくんが一番好きなのだ。そして、今はまだ、彼の方がコスパがいいｗ