WB-BT300 とか PHP とか VPN とか

Twitter から拾った、コンピュータ関係の話。

iPhone の音を PC の音とミックスして出したくて、使っていなかった Bluetooth レシーバを引っ張り出してきた。Onkyo の WB-BT300 という機械だ。コイツはなにをする機械かというと、iPhone など Bluetooth 対応機からは音響装置に見え、WB-BT300 に対して音声を飛ばしてくれる。WB-BT300 は iPhone からきた音声を、デジタル信号かアナログ音声信号に変換して出力してくれるのだ。

で、会社の開発機には TEAC の US-366 というミキサー兼 USB 音源があるのでそいつと接続すると、PC からの音と iPhone からの音をミキシング(混ぜて)出せるようになるのですな。ちなみに US-366 と WB-BT300 は光デジタルケーブルで接続。

ところが、iPhone からの音しか出ない!! なんだこれ??

原因は WB-BT300 のデジタル フォーマットがサンプリング周波数 192kHz、量子化ビット数が 24bit のせい。このフォーマットは統一しておかなければならないのだが、たかが Bluetooth の音声受信装置でなんでこんな高い設定なんだwww
ちなみに CD はサンプリング周波数が 44.1kHz、量子化ビット数が 16 ビットだ。CD よりも音が悪いクセにデータ量は CD の 6.5 倍もあるwww

仕方がないので PC 側の出力も 192kHz の 24bit に設定した。こうすることによって無事 PC と iPhone の音が同時に出るようになった。

某絵描きから、イベントの福引きみたいなクジをデジタル化できないかという依頼があり、ごりごりと PHP と HTML と Javascript で作った。今流行の HTML5 というヤツだ(ぁ
中身はすぐに出来た。そりゃまぁ、そうか。クジ振るだけだから、出た乱数が何等賞なのかに変換して表示するだけである。

問題は管理画面である。単純にクジ、と言っても誰でも彼でもアクセスしてクジが引けるというワケにはいかない。以下の様な機能が入っている。

  • ユーザ登録して、ユーザ登録した人がクジを作れる
  • クジはいくつでも作れる
  • それぞれのクジには 1 ~ 10 等賞まで設定でき、さらに残念賞、参加賞が設定できる。そしてそれぞれの賞及びはずれがいくつあるのか設定するようになっている。
  • QR コードの表示
  • クジを引く画面を Javascript でアニメーションさせる。
  • 何等賞が出て、残り何の賞がどれくらい残っているかリアルタイムで監視する、モニター

使い方はユーザ(主催者)がクジを作ったら、そのクジを iPad などの端末で表示し、お客さんがそれをタップしてクジを引くというものだ。
さらに QR コードを吐いて、それをお客さんが撮影してクジを引くという機能もつけた。この場合、ちゃんと一回しかクジは引けないようになってるのだが、残念ながら Javascript では機種固有の識別番号を取得できないので、cookie になってしまった。そのため、cookie を消去すれば何度でもクジは引けてしまう。

ツイートでの愚痴は、HTML というかサーバのプログラムは一回一回が初めてのアクセスになるというか、仕組み上、同じ人が何度アクセスしようが、サーバ側は初めての人が初めてアクセスしたことにしかならない。
今アクセスしに来た人が前の○○という場所にアクセスしに来て、今のアクセスはそれの続きであるということは実は認識できないのだ。それを実現するために、cookie やらセッションやらっていう仕組みがあるのだが、とにかく一回一回のアクセスがすべて関連を持たせられないので、渡す数値だのなんだのも全部もらい直さないといけないので、プログラミングがすげーめんどくさいっていう話。

これが普通のプログラムだったら、さっききたアクセスは変数に残ってるし、その変数を参照して関数を呼び出せば済むんだけど、PHP だとアクセスが来るたびにプログラムは先頭から実行されてしまうのだ。

あと処理は PHP なんだけど、それを表示するのは HTML なのね。組み方としては PHP が処理の結果に応じて HTML を吐き出してるワケなんだけど、そうなるとプログラム ソースの中に PHP と HTML が混在してけっこう美しくない結果に……。今回は仕様書も何もないままテキトーに作り始めてしまったので分離されてないのだけど、予定してたより大きなプログラム(PHP 部分で 2000 行程度、Javascript が 500 行程度)になってしまったので、今後は気をつけたい(汗


(MP4 / 750×1334 / 25fps / 1’05” / 126MB / iPhone)

amatsukami.jp サーバの様々なサービスは、色々がんばって外に出してるんだけど、それでもやっぱり一部の機能は VPN を張らないと使えない。そのたびに端末(iPhone など)から VPN を張ってるんだけど、けっこうめんどくさい。
モバイル WiFi ルータに VPN を張る機能があれば、端末でいちいち張らなくても済むのになぁ……。

GD ライブラリに、しばし苦戦する

 

萌え時計というボクがテキトーに作ったウェブアプリ(?)があるのだが、それにキャラクタの大きさを変えられるようにしようと思いついたので、ちょっと組んでみることにした。萌え時計の仕組みはとても簡単で、背景画像とキャラ画像が別々になっていて、建物の外か中・時間帯・場所・表示するキャラの種類が決まったら、それに適した背景にキャラクタを合成して表示しているだけだ。

だから、キャラクタを拡縮して背景に貼り付ければそれで終了である。

って思ってたんだけど、そもそも読み込んだ画像を単純に拡縮する命令は、PHP5.5 以上じゃないと使えない(amatsukami.jp はPHP5.3)。ちょwww
では拡縮はどうするのかというと、背景と合成する時にキャラのどこからどこまでを、どこからどこまでとして貼り付けるなんて方法でやるのである。たちえば (0.0) – (99,99) という 100 x 100 ドット四方の画像を、貼り付け先の (0,0) – (199, 199) にってやると倍の大きさで貼り付けられるわけだ。
%指定ですらない!

そしてこの仕様では問題が起きる。背景の画像は 512×512 ドットあるのだが拡大率によっては立ち絵がこの大きさを超えてしまうこともあるのだ。そうなると貼り付け先の領域が存在しないことになって合成がうまく行かないのだ。
そこでどうしたかというと簡単に%指定できるように、立ち絵を読み込んだら、それに%分拡縮した何もない画像を作成し、そこに元の立ち絵を目一杯貼り付けて拡縮するようにした。そしてあらためて、背景にこの拡縮済みの立ち絵を貼り付けるのである。

まぁそんなわけで、キャラの大きさが指定できるようになった。

気温とか 4K とかカレーのシミとかミルクとか

またまた Twitter から拾った、いろいろくだらない&どうでもいいネタ。

暑い! ってただそれだけである。残暑は長し。

まぁメモ程度に。1080p と較べるとファイルサイズはほぼ倍。電池は 10 ポイント多く使用した。さすがに 4K クラスとなると HEVC で録画したいんだけど、Premiere で読み込めないので未だに互換フォーマット。というか、PhotoshopHEIF に対応してくれないと移行でできない……orz
すぐ対応すると思ったのになかなか対応しないなぁ……。

そう!こういうのないの? ボクは白が好きなので、割と白を着るんだけど……時々食事の時失敗しちゃうんだよねぇ。そしたらもうそれは選択肢なくちゃいけなくなる。上のようなウェットティッシュがあれば、ちょいちょいってその部分に薬品(?)を浸透させて、そのあとウェットティッシュ側に吸い取るみたいな……そういうのないのかなぁ。

先日 TAMA Networks の旧コンテンツを別サーバに移した。そしたら、訪問者カウンタがおかしくなった。理由は簡単で、リバースプロキシ(Application Request Routing)経由でアクセスするため、旧コンテンツから見たらリバースプロキシしかアクセスしてこないためだ(笑)。
旧コンテンツに何千人、何万人来ようが、全部リバースプロキシが間に入るので、旧コンテンツからしたら一人がすげー勢いでアクセスしてくるな、って事にしかならないのだw

と言うわけで、リバースプロキシ側で HTTP ヘッダに HTTP_X_FORWARDED_FOR という名前で、アクセスしてきた人の IP アドレスを入れて、それを旧コンテンツに渡し、また旧コンテンツでは REMOTE_ADDR でカウントするのではなく、先ほどの HTTP_X_FORWARDED_FOR でカウントするように書き換えた。これで解決。

シティハンターだったっけなぁ? キャッツアイだったかなぁ。女子高生とかを「ミルク臭い」と呼んでいたのを思い出した。確かに 10 代の女の子って代謝が早いせいなのか、ミルクのような臭いがしてた。でも最近、JC も JK も大人びちゃって化粧やら香水やらするから、あの臭いはしなくなったよなぁなんてことをふと思う(ぁ
脱いだら解るけど。

そしてエロゲを作ってるからかもしれないけど、アレだよね、すっかりミルク臭いなんて表現は使わなくなったって言うか、もう女子高校生や女子中学生くらいが恋愛のターゲットになっても驚かれなくなったよなぁ……。エロゲだと容姿的にそれくらいが普通だもんなぁ。

リバースプロキシって便利!

TAMA Networks の旧コンテンツは Pukiwiki Plus ! というシステムで動いている。コイツは PHP 5.2 じゃないと動かない。5.3 以降では動かないのだ(どうも動くらしいのだが、IIS ではセキュリティ関連の機能がまったく働かない)。そのおかげで、amatsukami.jp サーバはずっと PHP を更新できないでいる。そうこうしているうちに PHP は 7 になってしまった。

一方、現在の TAMA Networks は WordPress というシステムで動いていて、これは現役のシステムであり、バージョンアップもされている。
そしていつかは WordPress が PHP5.2 では動かなくなるはずだ。現に WordPress のプラグインなどは 5.2 で動かないものもチラホラ出始めている。
しかし、先の Pukiwiki Plus ! のおかげで、こちらは PHP のバージョンを上げられない。
何かいい方法はないものか? と、色々考えたあげく、二つの方法を思いついた。

  1. amatsukami.jp サーバで複数のバージョンの PHP が動くようにする
  2. リバースプロキシを使って、Pukiwiki Plus ! を amatsukami.jp サーバから追い出す

と言うわけで①を試そうとしたんだが、IIS7.5 ではこれがどうもうまくいかない。
いや、7.5 でもできると思うんだけどなぁ……。結果的に旧コンテンツが動かなくなるw
そこでやる気を失って放置してたら、ウェブサーバが落ちたwww
どうやら旧コンテンツの実行にものすごく時間がかかるようになってしまったためで、旧コンテンツそのものにアクセス出来ないようにしたら、復活した。

これが 9/11 頃である。

その後も①に色々挑戦するも、何故かうまく動かない。まぁ amatsukami.jp サーバは 6 年も稼働し続けているし、その間、いろんな設定ミスだのなんだのをしてきたから内部がけっこうヤバいことになっているのかもしれない。
さっさと新しいサーバに移行しなければ……という結論には達するものの、技術的な勉強も兼ねて仮想サーバ(こちらは IIS8.0)に PHP を 2 バージョン(5.2 と 7)をセットアップした。するとすんなり両バージョンで PHP が動くではないか。なのでこの設定をそっくりそのまま amatsukami.jp サーバに持ってくると……やっぱり動かないorz
う~む、やはり amatsukami.jp サーバが怪しいんだなぁ……(実は PHP の設定が不味かった)。

そこで amatsukami.jp サーバにリバースプロキシを設定する。そして https://amatsukami.jp/scripts/pukiwiki/ 及び https://amatsukami.jp/pukiwiki/ にアクセスしに来たら、それは仮想サーバの Pukiwiki を呼び出すように設定した。
と言うわけで上のメニューにある「今は昔」のリンク先は amatsukami.jp サーバではなく、仮想サーバで動いているコンテンツだったりする。

将来的にサーバを新調したら、どっちの方法でやるかは悩むな。サーバを新しくしたら当然そっちでは複数のバージョンの PHP が動かせるはずだ。となれば別にリバース プロキシに頼らなくてもよい。
ただ将来的な設計で、ロードバランサなどを置く場合は、そもそも全てのサイトがリバース プロキシでの運用になるだろうし……。まぁそれはその時になったら考えよう。

下の写真はシャンブラとボクが勝手に呼んでいる『上海ブラッセリー』の塩やきそばと半チャーハン。ここのチャーハンは紅生姜が入っているのが特徴だ。半チャーハンの写真がフタルあるのは、ここ、半チャーハンはお代わり自由だったんだけど、それがなくなり、「普通」「大盛り」「特盛り」が選べるようになった。その大盛りと特盛りの比較写真が、チャーハンが二つ並んでる写真だw
あくまでも半チャーハンの大盛りと特盛りなので、大盛りが普通のチャーハンくらいの量だと思ってもらえれば間違いないと思われる。ただし、残っているチャーハンの量に影響されるのか解らないが、けっこう日によって量は違ったりするw

WordPress 3.5 アレコレ

bs_ruri01f
TAMA Networks で使っている CMSWordPress)がバージョン・アップして、3.5 になった。特に何の気もなく、バージョンアップしてしまった(マテ)。そしたら予想以上にいろいろ変わっていたので、ちょっとびっくり。今度からはちゃんとリリース・ノート読もう!<サーバ管理者としてあるまじき行為
なんと言っても一番変わったのは画像などを貼り付ける画面。今までと全然違う。今まではアップロードが前提となっていて、画像を貼り付けるたびにアップロード画面になって面倒だった。何故面倒かというと、日記で毎日使われているキャラクタの顔は、既にアップロードされているデータであるため、既にあるデータを選ぶ画面(ライブラリ)に切り替えてなくちゃいけなかった。っていうのと、アップロードされたファイルは新しい順に表示されるので、古い方に切り替えなくちゃいけなかったし。それに、写真などをアップロードしたときも、まとめてアップロードしたあとはアップロード画面ではなく、ライブラリ画面から選ぶわけで、アップロード画面なんていうのは、最初だけしか使わないのである。
3.5 になってから、ライブラリ画面がデフォルトとなった。さらに複数の画像が一度に貼り付けられるようになった。今までは一枚貼ってはメディア画面を開き、ライブラリ画面に遷移し、画像を選んでいたのだが、3.5 からは貼り付けたい画面を CTRL や Shift キーで選べば OK。あとはどばーっと並べて貼っ付けてくれる。

トラブルと言えば、アップデート機能が動かなくなったこと。エラー・メッセージを見てみると、C:\Windows\Temp にアーカイブ・ファイルがねーよと出ていた。そこで原因はすぐに分かった。そのフォルダはそもそも PHP などで書き込みできるようにはしていない。CGI でアクセス出来る場所は別に用意してある。今までのバージョンでは php.ini に書かれているテンポラリ・フォルダを見に行っていたようだが、3.5 では Windows の環境変数を見に行ってしまうようだ。
そこであれこれ色々調べて見ると、どうやら WordPress には WP_TEMP_DIR という定数があるっぽい。ここに、CGI 用のパスを設定すればよいのだろうと勝手に推測<ソースを見んかい! wp-config.php に勝手に以下の一行を追加。

> define(‘WP_TEMP_DIR’, ‘テンポラリ・フォルダへのパス’);

無事に更新機能が動くようになった。めでたし、めでたし。

Perl が動かない

今日こそは PHP を動かす!
というわけで、色々悪戦苦闘。0 から入れ直してみたりとか……でも、そもそもあんまりやることもない。
仕方がないので手がかりを見つけるために、PHP HTTP エラー 500(内部サーバエラー)で検索しまくった。
そもそもエラー 500 というのは漠然としたエラーというか、「なんか CGI がこけてんぞ」っていうようなことを表す程度のもので、CGI が動かなかったらだいたいこのエラーが返ってくる。だから HTTP エラー 500 なんかで検索しても、様々な原因がヒットするわけで……もはやこれを一つ一つしらみつぶしに見ていって、心当たりのありそうなものを探すしかない。
まさにローラー作戦である。

が、思いの外、原因はすぐに特定できた。
php.ini にTIMEZONE を設定する項目があるのだが、そこが何も書かれていないとエラーになるらしい。
そんなの今まで設定したことありませんけどー<マテ
とおもって、amatsukami.jp の方の php.ini を見たんだけど、特に TIMEZONE の設定はされてなかった。
んー、違うんじゃないかなぁと思いつつも、Asia/Tokyo を php.ini に設定してみる。
すると、動いた……orz

うが─────!!!!

この二日間はなんだったんだ……orz
まぁそんなこんなで PHP は動くようになったのだが、5.4.4 を入れたため、Pukiwiki Plus! は動かなかった……。
どうしようかなぁ、これが動かないといろいろ困るんだよなぁ。

で、新しい社屋には会議室が二つある。
で、本社にも一つある。
本社の人がこちらの会議室を使うこともある。
誰がどの会議室をいつ予約しているのかというのをウェブ上で見られるようにすればよいかなと思い、テキトーな会議予約システムを設定してみたのだが……今度は Perl が動かない!! うぎゃー、なんでじゃ!? と思って、サーバ インストール時に仕掛けた Perl で作られたシステムは動く。どういうことだ??

調べて見ると、Perl.exe では CGI としてちゃんと動くことが判明。
ところがこの Perl.exe は相対パスとかその辺に  UNIX と互換性がなく、Windows 版の Perl.exe で動かすことを考えて作られているプログラムなら問題ないが、それを考慮してないものは、ISAPI 版を使わないと行けないんだけど、この ISAPI 版の Perl が動かない。なんか、無許可の動詞を実行しようとしたといってエラる。そもそもすべての動詞を許可していますけどー。
その後、色々調べるも、IIS で POST(動詞の一つ)を受け付けなくなるというところにはたどり着いたんだけど……うーん、なんか違うような、あっているような??

というわけで Perl と悪戦苦闘するハメに……うもー、なんなんだ。
しようがないので Perl はおいておいて、会議室の予約システムを PHP のものを設置してみた。
phpScheduleIt というシステムで、なんでもこの手の予約システムでは定番のシステムらしい。で、設置はすんなりいったんだが、これが重い!! なんでこんなに重いんだ!? というわけで、ボクの感触としては設置に失敗しているような気がするんだよなぁ。だって 3GHz オーバーの最新の CPU のサーバだし、それでこんなに重いのはおかしい……。
実際に使ってみた人からも「重いんですが」という苦情が……うーん、PHP そのものの設置に失敗しているのか、それとも MySQL の設定が不味いのか、それとも phpScheduleIt の設置そのものが悪いのか……しっかしこんなにサーバ設定で苦労するのも久しぶりだなぁ……orz

そんなわけで、サーバの設定はまだまだ続きます。
だいたい、VPN とか証明書回りとかもぜんぜんできてないし(T_T)

PHP が動かない

開発機が安定したのでやっとこさ、サーバの設定に戻る。
まずは PHP の続き。
とにかく動かない。
HTTP500 エラー出っぱなし。出しっぱなし。困った。
ログを色々見てみるのだが(Windows イベント、IIS のログ、PHP のエラー出力 ON、localhost で実行)、まったく手がかりナシ。仕方ないので VPN とか証明書関係とかそういうのをやりつつ、時々「PHP、動くようになってないかなー」とか思ってテストしてみたり(動くようになっているワケがない)。
そうして一日が終わっていった<バカ
ちなみに直接コマンドラインから PHP を叩くと動くんだよねー。

いやー、こんなこと初めてだわー。
ちなみに Perl はあっさりと動いた(ただし、後日事件が起きるのだが)。

閑話休題。
引っ越し先の事務所のすぐ近くにあるつけ麺屋「来吉」に行ってきた。
基本、大勝軒などでおなじみの魚出汁のスープなんだけど、柚か何か柑橘系のモノが入っていて、後味がちょっとスッキリ。チャーシューは炙りチャーシュー。普通に美味しかったけど、麺が乾きすぎて、箸で麺を取ろうとすると、ボソッと全部取れてしまうw カウンターを見るとごま油が置いてあって「麺が取りにくいときはこれでほぐしてください」って、いやー、もうちょっと水分多くてもいいんじゃなかろうか(汗)。
 
ところで建物が民家を改造したモノなのかな? 外は雰囲気イイナーって思って入ると、中は普通のカウンターという(汗)。まぁいいんだけれども。なおカメラは iPhone ではなく Android 機(N-05D)。