トリチウムは流せないけど 2GB の動画は流せるの

東電で貯まり続ける汚染水を海に流すことの問題をわかりやすく説明している記事。記事を書いているのは理系の方でなかなか合理的・科学的にまとまっているとおもうので、ぜひ読んでみて欲しい。

他にも三陸沖の水深 200 ~ 300m あたりに海流が循環している部分があって、薄めて流しでもそこで濃縮されてしまうと言う記事も前に見たのだが、もう探しても解らなくなってしまった(汗)。
ボクは原子力推進派の部類に入る人間なのだが、こういういい加減な対応をするのはやはりよろしくないし、責任を取る人も方法も確立していない中でとにかく流すこと前提で進めるのはなんとも情けない限りである。

一応原子力の素晴らしいことも書いておこう。原子力発電所の燃料(いわゆるウランやプルトニウム)補給は三ヶ月に一回で済む。また、原子力空母や原子力潜水艦は 15 年に一回だ。どれほど原子力が夢のエネルギーかは理解して欲しい。
そして我々が宇宙に進出していくには、この原子のエネルギーでさえも足りないのだ。
だから原子力の研究は怠ってはいけないと思うし、さらにその先(太陽をまるごと利用するとか、反物質とか)も研究すべきだと思っているので、原子力推進派なのである。

ところでファイルサイズが 2GB 以上の動画を <video> タグで貼り付けると Firefox がフリーズしていたんだけど、それが直っていた。やっとだよ、ほんと Firefox ってクソだわー(ぁ
まぁそもそも HTML で 2GB 以上の動画を置くことが仕様として許されているのかどうか知らないけどね!<ヲイ
Firefox は RFC 原理主義者なので、動作としては Firefox の方が正しいと言うことは多々ある。ボクはすちゃらかプログラマなので、IEChrome では動くのに Firefox では動かないなんてソースをよく書く。テヘ!

下の写真はお気に入りの揚げ物屋さん『串竹』のロースランチ+メンチカツなんだけど、おまけに脂身だけのとんかつを一切れいただいた。一番右の写真がそれだ。この脂身だけのとんかつ、ボクの同僚が大好きでわざわさ串竹の人に注文して揚げてもらっているものだ。
脂身なんて揚げたら、全部とけて流れてっちゃうんじゃない? とか思っていたけど、実際はこんな感じになる。すごい、たしかにほとんど脂身だ(笑)。

日乃屋の野菜カレーは根菜だった

日乃屋カレーへスペシャルカレーを食べに行った。最近、日乃屋カレー率高いなw
まぁ好きなんだからしようがない。
そして今回は、野菜とウインナーと鶏南蛮をトッピングに選んだんだけど、野菜がサツマイモにズッキーニ、パプリカ、レンコンというラインナップで驚いた(笑)。いやまぁ、全然いいんだけど、ただサツマイモはやっぱりモサモサしちゃうねー。ルーが甘いから余計甘くなっちゃうし。
レンコンはイイ感じ。パプリカとズッキーニも水分少なめでベチャッとならないようになってた。

そして今日も 9/25 だというのに 30 ℃越えである。

萌え時計をレスポンシブデザインに対応させた。サイズ指定がいっさい必要なくなり、萌え時計が配置された要素に従うようになった。だいたいは iframe を使って貼ると思うのだが、その iframe の大きさに勝手に合わせるようになる。
上のツイートでもブラウザいっぱいに表示された萌え時計の文字が、画像の大きさに合わせてちゃんと拡大されて、位置も概ね合っていることが解る。

詳しい記事はこちらに。

ただ今回の対応では縦横比が 1:1 じゃないと正常には表示されない。
萌え時計はそもそも 1:1 なので、まぁ別にいいかって感じではあるのだが……これが長方形だと今の組み方では文字の大きさを幅に対してしか見てないので、横幅に関しては正しく認識するけど、縦幅に関しては正しい大きさにならない。縦横比が 1:1 だと横の%=縦の%でもあるので正常に表示されるのだ。
縦に対して考慮してないのは、Microsoft Edge が対応してないから(汗
なのでそのうち、対応する予定。

なんか動画のリエンコードで一日が終わった件

文化の日を忘れていた

今日が旗日だというのに気付いてなかった。気付いていれば月曜日も休みをとって 4 日の旅行に出来たのに、とかちょっと思った。あと日曜日草津温泉田沢温泉の宿が妙に埋まっていたことも合点がいく。月曜に休みを取っていた人がいたのだろう。
なんか悔しい。

さて、今日は一日中ドラレコの画像をリエンコードしてた。
今まで Microsoft 製の Moive Maker っていうのを使ってたんだけど、コイツの画質があまりよろしくない。さらに音質もよろしくない。ということでせっかく Adobe CC に入ってるんだし Premiere 使おうと言うととで Premiere でやってみてるんだけど……なんかそれでもドラレコの紅葉の方がキレイ……。
とくに黄色が色あせるんだよなー。
H264 の 2 Pass の 5Mbps。
あと暗い部分でのブロックノイズがひどい。
それでいてエンコード時間は 3 倍くらい伸びた気がする(汗)。まぁ倍速以上の動画は 60fps で書き出しているので、30fps よりは時間がかかるのは解るが……。それにしてもうーむ……。

で、とりあえず今回は Youtube に上げてみた。いつもは自分のサーバに上げるんだけど、Youtube だとどうなのかなーと。Youtube はアップされるとそれをさらにまたリエンコードするんだよね?
なんかファイル サイズは 128GB まで OK みたいなので、25Mbps で作ったヤツをアップした。
アップが終わった後 360p しか有効にならなくて、なんだーと思っていたら、解像度の低い順番に見られるようになるらしい。ということはソースが一つあってそれを元に各解像度のデータにしているのではなくて、各解像度のデータを使っているってことか。容量食いそうだがその方がサーバには優しいのかな?

紅葉ドライブは Youtube の再生リストにしました。

あと、圏央道の動画も。

もう一つの問題は、Youtube の動画を自分のサイトに貼る場合、インライン フレーム(iFrame)を使って貼るんだけど、これだとうまく % で貼れない。高さの % も必要となる。
うちのサイトみたいに一つのデザインでスマフォも PC も OK ですみたいなサイト(こういうデザインをレスポンシブ デザインという)だと、高さってちゃんとやろうとしたら JavaScript で要素の高さを出してやらないといけない(と思う)。この辺、レスポンシブ デザインをやってるひとはどうやって解決してるんだろう?
気になる。
自分のサイトにデータを置く場合は、Video タグで横幅とあと縦横比は固定ってのを指定しておけば縦は特に指定しなくても良い。こうすることによってウィンドウ サイズが異なる場合でもちゃんと動画の全体が表示される。Youtube の場合、横幅が 560 ドットとドット数で指定してしまっているため、iPhone とかスマフォで見ると動画が欠けてしまうのだ。

まぁ、モンハンとか猫とか仕事とか

1/2 から仕事が始まっていた。HTML 以外にも何故かバナーとか作っているヲレ。あれ、これボクの仕事か!?(笑)とか思いながら、グラフィッカー デビュー!(マテ
まぁお年玉ガチャとか振り袖祭りだったかなんだったか、その辺の更新をしていた。

ところでウチには二匹の猫がいるのだが、とにかくツメを出す。こんなに間抜けな猫、見たことないっていくらいツメの使い方が下手。例えばカーテンによじ登って、カーテンに爪が引っかかって降りられなくなったりとか。
今まで何度も猫は飼ってきたけど、こんな猫はじめて。
でね、甘えるときもよくツメを出すんだけど、そのおかげでボクの腕はボロボロである。カサブタだらけだ。
だがいつしか、「痛い」と言うとツメを引っ込めるようになった。
へー。
ツメを立ててボクの身体をよじ登ってくるときとか、あとゴロゴロ言いながらボクの肌の上で足を踏み踏みするときとか、傷だらけだったんだけど、最近は「痛い」というとツメを引っ込める。
でも相変わらずカーテンには引っかかって下りられなくなってるけど(ぁ

甘えるとき、ツメ、出さないで欲しいなぁ……。

閑話休題。
仕事は始まっているけれども、大晦日までのようなずっと詰めて作業をするほど忙しくはなかったので、久しぶりにモンハンにお金を払ってログオンしてみた。
が……うーむ、なんの素材を集めなくちゃ行けないのかとか、サッパリ解らん……。
武器屋に行って、素材リスト見て、倉庫の中の既に持っている素材を見て……。
………。
……………。
そっと閉じた。それ以来やってない(ぁ

MP4 で Firefox がこける

Firefox ユーザからウチの日記を表示しようとすると Firefox がフリーズするという報告を前々からいただいていた。ボクは IE しか使っていないので、他のブラウザで見たことはなかったのだが、Firefox を使っている人たちに見てもらうと、確かに飛ぶことがあるらしい。
はてさて、何が原因か?
ぱっと見たところ、ビデオだろうな、と何故かすぐ思い、ビデオを外すと案の定、Firefox でもフリーズしなくなった。

が、ビデオを埋め込むとなぜ Firefox だけ飛ぶのかは解らなかった。フリーズするビデオとそうでないビデオがあるからだ。
TAMA Networks の他の何かと干渉しているんだろうかと思い、そのフリーズするビデオを、単純に video タグだけ使った、CSS も使わないシンプルな HTML を作って、Firefox でアクセスしてもらったが、やはりフリーズ。
これはもうこのビデオのデータそのものが何かおかしいのだろうと結論。
ちなみに TAMA Networks で貼ってあるビデオはどれも Microsoft のムービーメーカーというもので作ってある。このムービーメーカーがヘッダに何か Firefox がフリーズするような情報でも埋め込んでいるのだろうか?

でも IE のみならず、Google ChromeOpera でも大丈夫らしい。
んん~~~~??

そして今回はここで諦めてしまった。
現在(2015 年 4 月段階)でつかんでいるのは、4GiB 以上の動画を貼り付けると Firefox が飛ぶというのが解っている(その時のツイート)。
ところで今日は 0 度で、車のフロントガラスに霜が降りていた

写真は会社帰りに寄った、中村橋の祥龍房の海老のマヨネーズ和え。
出てきたとき、色が変だなぁと思いつつ食べたら、ひどかった。
海老は衣がついてたんだけど、その衣が電子レンジをやり過ぎたような硬さ。そしてマヨネーズの臭いがひどすぎる。まさしくうんこの臭い。腐ってるのか?
とにかく、とてもじゃないが食えず、ほとんど残した。

1412230866 1412230868

レスポンシブ デザインのめんどくささ

今回はレスポンシブ ウェブ デザインの話。レスポンシブ ウェブ デザインって何かっていうと、一つのデザインですべてのプラットフォームとブラウザに対応することである。つまり PC でアクセスしてもスマフォでアクセスしても、同じデザインで出力される……というわけではなくて、一つのデザインしか定義してないんだけどそれで PC でもスマフォでもちゃんと表示されることである。

今やっているスマフォのゲームも最初、レスポンシブ デザインで作っていた。
このレスポンシブ デザインの肝は簡単に言ってしまえば%で作ると言うことである(ぁ
どういうことかというと、例えば 2 段組をするとき、全体幅が 1024 ドット、左側がメイン コンテンツで 640 ドット、右側がメニューとかで 384 ドットにしよう……ってのが今までの作り方。
レスポンシブ ウェブの場合は、全体幅は 100% で作り、本文左側は 62.5%、メニューとかの右側は 37.5% にしようってこと。そうすればどんな機器だろうが割合で区切られるので、それらの機器に従った大きさになる。
これはレイアウトだけでなく、画像の大きさに至るまで何もかも%で指定する。

ところが、この作り方には二つの欠点がある。

  • 文字の大きさは変わらない
  • ドット単位の微調整は不可能

ブロック要素や画像などは画面の大きさに従って勝手に変わってくれるのだが、文字の大きさはそれに追随してくれない。なので細かいディスプレイに出しても、荒いディスプレイに出しても同じ大きさ(ドット)で表示されてしまうため、要素の中に表示される文字数が変わってしまい、結局レイアウトが乱れる。
これはディスプレイの画素数と CSS ピクセル比ごとに文字の大きさを定義しておく必要がある。
さらにゲームではインターフェースに凝るため、ドット単位でのボタンやゲージ(メーターやプログレス バー)などの表示が必要となる。ブラウザは小数点第三位くらいまでの%値しか見てくれず、ドット単位での微調整はできない。これの回避方法は、ドット単位で組んだあと、Javascript や CSS の ZOOM を使って最適な大きさに表示するのだが、iOS の Safari などでバグが発生し使えないことが多い。これに関しては、まだボクの中では特に解決策は見いだせていない。
今回はドット単位で調整が必要なところは、合成した画像を変化する種類分作って対応するというわりと原始的な方法で回避した(^^; どういうことかというと、下地があってその上にボタンをドット単位で並べなければいけないような場合、下地とドット単位で並べたボタンを合成してしまい、どのボタンが光っているかというパターン分の画像を用意することによって、ドット単位での調整をしなくて良いようにした。ただこの方法は、パターンが膨大にある場合は使えない……。

まぁ、一番いいのは Javascript の ZOOM である。コイツさえ正常に動いてくれれば、レスポンシブ デザインは一気に楽になる。何故かというと、ドット単位で自由に作れるからだ。従来の作り方のように、例えば全体幅を 1024 ドットとか 640 ドットとかと固定して自由にレイアウトした後に、Javascript で機器のディスプレイの大きさに合わせて拡縮するようにすれば楽ちんなのである(爆。

他にも Table を使うのが難しかったり、横幅を必要とするモノがどうしてもスマフォなどだレイアウトが崩れてしまったりなど、一つのデザインで様々な機器に対応するのは一筋縄では行かない。TAMA Networks も燃費なんかの表の部分や、説明付きの画像の場合はスマフォで見ると崩れてしまう。
この辺、何とかしたいなぁと思いつつ……。
写真はこの日食べたもの。バーガーキングのブルーベリーのハンバーガーと、秋葉原の万豚記。

1412080730 1412080731 1412080737 1412080740 1412080741 1412080747

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 だとこうは行かなかったと思う。