ウェブアプリ開発、色々

正式にはまだ発表出来ないんだけど、ウェブアプリをまた作り始めている。今度のはかなり規模が大きいので、言うだけ詐欺になりかねないのだが、まぁとりあえず(ぉ

HTML と Javascript で画面を作っていたんだけど、縦で使ったときと横で使った時を%だけで表現出来るかなと思ったら無理だった……orz あと上のツイートの立ち絵あるじゃない? この立ち絵をタップできるようにしたんだけど、抜けはタップしても反応しないようにできるかなーと思って調べたら、それをやるには canvas を使わないといけないらしい……。めんどくさい。最近 canvas 使わなくてもイロイロ出来るようになったので、canvas 使うことを考えてなかった(汗)。

ところで、前回当てた大型アップデートから Egde の挙動が変わった。何度更新押しても、CSS と Javascript が更新されない。くそー。仕方ないので、デバッグ画面から常にサーバを読むようにして使ってるけど、これ、普段使いにもどるときにはいちいち OFF にしないとダメだよね? もー……。

最後に、今日は三軒茶屋にある音楽団の PC を診てきたんだけど、その帰り、浅草橋に戻るのに首都高を使ったんだけど、至る所(ジャンクションとか出入り口とか)で検問やってた。検問と言っても、たぶんだけどカメラで撮ってるだけなのかな? 警官と移動交番らしき車両がところどころに配置されていた。ああいう検問の方法もあるんだなぁ。

サイトによるマイニングは不評らしい

 

広告を表示する代わりに仮想通貨マイニングする JavaScript が出回り始めたんだけど、こちらのほうが広告表示よりもぜんぜん理にかなってるなってボクは思っている。そのサイトを利用するからには何らかの代償を払う必要があるわけで、それを広告ではなく自分(サイトの利用者)の持っている CPU や GPU の計算力を提供するわけだ。

ところが、これに対してけっこう怒る人が多くてびっくりした。

えー!? 広告の方がヤじゃない?
まったく広告でない方がイイと思うんだけど……。
利用してその対価を払う、という意味ではマイニングの方が直接的だしいいなぁとボクは思っている。

と、悠長な事を書いてはいるが、この後、マイニングのスクリプトをウェブサイトに仕組んだ人が逮捕されるという事件が起きた。警察の無知の結果である。計算力やネットワーク リソースを盗んでいるということらしいのだが、それは広告も一緒である。場合によっては広告の方がマイニングより盗んでいるかも知れない。

ちなみに TAMA Networks は世間がやっているほど広告は置いてないし、置きたくないから自前のサーバでやってるんだけど、全くないわけではない。自分が作った作品の Amazon へのナバーや、自分が買ったものの Amazon へのバナーなんかが置いてある。これらは Amazon のアフィリエイト情報が含まれているし、そのことはサイトにも書いてある。

ついでにウチのアフィリエイトの効果はどんなもんかと白状すると、一年間で 5000 円くらい(笑い
ここ最近はもっと低くて 2000 円とか 1400 円くらいだったりする。

萌え時計の設定生成ページを作ってみる

Twitter にウィジットってあるじゃない? 自分のサイトにリアルタイムに自分のツイートを貼り付けたりできたりするやつ。あんな感じで萌え時計の設定を GUI で出来ないかなーと思って Javascript で組んでみた。

GUI で色々調節すると、サイトに貼り付ける HTML が生成されるというもの。

仕組み自体はわりとすぐに作れたんだけど、これを WordPress 上で動かすことができなくて……色々調べたらプラグインを入れなくちゃダメらしいので、それで解決した。

使ったプラグインは CSS & JavaScript ToolBox とかいうもの。
プラグインなしでやりたい場合は、function.php だったかなぁ、そこにゴリゴリソースを追加すればいいんだけど、function.php が肥大化するのとスパゲッティになっちゃうので、とりあえずプラグインを頼ることにした。

時給とモバイル WiFi ルータと JavaScript

東京にいるとあんまり実感しないんだけど、旅行先だと確実にバイトの時給って上がってるように感じる。というのも、アベノミクス前は地方都市(例えば高崎、宇都宮など)の時給って東京より 100 ~ 200 円は低かったけど、最近はそう言った地方都市でも時給 1000 円以上なんてぜんぜん珍しくない。特に飲食店は高い。1200 円とか平気で見る。
すごいなぁ。東京で 1200 円だと生活も大変そうだけど、地方都市で 1200 円だったらけっこう助かるんじゃないだろうか? そうでもない?? 物価はそんなに変わってなさそうだし。

2015 年の 9 月に買ったモバイル WiFi ルータ『MR04LN』がもう半年以上も使われずに机の中で眠っている。使わなくなった理由は単純に非常回線としての用をなしてないからだ。現在は au 系の MVNO を使っている。ボクは普段はこの au の回線を利用し、Docomo の回線に余裕を持たせている。ちなみに Docomo 回線はボクを含め三人が使い、容量は 5GB。au 回線はボクだけが使い、こちらは 6GB である。今のところこれで容量が少なくて困ると言うこともないし、当分 MR04LN の出番はなさそうだ……。

誰かに貸してもイイよな、と思いつつ……。

以前作った福引きシステムで、リラルタイム モニターを作ってみたんだけど、一秒に一回サーバを見に行くので、たくさんの人が使ったらダメだなぁと思いつつwwww
どういう機能かというと、自分で設定した福引きの状況(何等がいくつ出てて、それぞれの現在の確率がどれくらいか)っていうのをリアルタイムでモニターするためのもの。福引きが引かれたらモニターに通知する方法とかないかなぁ(ぁ
ちなみに 5 分以上福引きが引かれないと、自動的に止まるようになっている。

まぁ、将来のためにいろいろ考えよう……。

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 を張る機能があれば、端末でいちいち張らなくても済むのになぁ……。

CreativeJS と Flash

今日はウェブ上でのエフェクトのお話。
今回ボクが担当しているプロジェクトは期間が短いこともあり、余り凝ったことがやれない。とはいえゲームなので演出は派手に越したことはない。
そこで考えたのが、Adobe Flash で作ったものをそのままウェブ上で再生すること。実は以前にも別のプロジェクトでアバターのアニメーションなんかを Flash でやってたりするので、今回もそれで行こうと思ったのだ。

ん? スマフォで Flash なんて再生できないって?

Adobe Flash CC は作ったアニメーションなんかを HTML5 にコンバートできるのだ。
なのでできあがった HTML5 をあとは再生するだけ……!
って思ったんだけど、HTML5 化されるのはエフェクトやアニメーション部分だけなのね……orz
Flash の中で変数を使ったり、条件分岐したりしてるんだけど、それらは全部無視されるみたい。
で、結局どうしたかというと、その部分は Javascript で書いた。

Flash でコンバートされた HTML5 は CreativeJS というのが使われていて、この CreativeJS というのは元 Flash のプログラマが作ったようだ。なので、Flash で利用される様々なエフェクトは CreativeJS の中に関数として用意してあって、ほぼ同じように再現できるらしい。

まだ完全にファイルの構成を理解出来たわけではないのだけど、一応、Flash から HTML5 にコンバートされた Javascript を色々と制御できるようにはなった。
写真は今日食べたもの。かくやという立ち食いソバ屋。けっこう気に入っている。

1412090757 1412090758 1412090760 1412090762

Webkit オンリーで組んでも……

スマフォの開発を相変わらずしているんだけど、今回の案件は別に PC で動作する必要はない。で、スマフォというと iOSAndroid が主流で、他のプラットフォームに関しては、ほぼ無視して良い(ゲームの場合の話ね)。となると、ボクが思ったのは「じゃぁ、Webkit に対応して作ればいっか」であった。
iOS に搭載されている Safari も、Android の Chrome も Webkit というレンダリング エンジンで作られているからだ(Chrome は Webkit からさらにフォークして Blink となった)。

ところが、けっこう iOS と Android で表示が違うんですな。
更に困ったのが Android の標準ブラウザ。
実は Android に最初からついてくるブラウザというのは Google Chrome ではない。なんでなのかというと、これはボクの予想でしかないのだが、Android デビューに Chrome は間に合わなかったからだと思われる。ちなみにエンジンは Webkit である。
Android 版の Chrome は Android のバージョンが 2.3 だか 2.4 だかくらいにようやくデビューした。なので Android には「標準ブラウザ」という、別のブラウザがずっとついてきている(Android 4.4 でようやく標準ブラウザが Chrome となった)。

この標準ブラウザがとにかくタコい。
まず Javascript の実行速度が圧倒的に遅い。そして HTML5 からついた修飾(ぼかしや縁取り、グラデーション)などの再現率が低い。特にぼかしがおかしい。

次に Safari。コイツのフォント処理はおかしい。とにかく文字の大きさが合わない。
なんだこれー!?
しかもバグがあって、Javascript で拡縮をやると正しい大きさにならないという……orz(CSS でも ZOOM を使うと同じ症状が出るらしい)
これが実に問題で、先の記事の CSS ピクセル問題で、CSS を書き直しせず、Javascript で最適な大きさに拡縮するという風に逃げたのだが、この Safari のバグのおかげで結局この方法は使えなくなってしまい、CSS を全面書き直さなければならなくなった。

だ、ダメすぎる……orz

だが今回、「ブラウザの場合分けはしない」というポリシーで組んでいる。これは別にボクの勝手なポリシーなんだけど。場合分けってのは何かっていうと、Safari だとこっちの処理、Chrome だとこっちの処理というようにブラウザことに処理をわけることだ。
CSS / HTML は一種類の定義ですべてのブラウザで通用するように書いた。まぁ、なんだかんだ言ってもレンダリング エンジンが一つだったというのが大きいだろう。これが PC だとこうは行かなかったと思う。