ただの愚痴

7 月だ。まったくその実感がないのだが、7 月だ。
5 月の終わり頃から 6 月はずっと忙しかった上に、ムリして旅行にも行ったものだから、7 月に入ってからの空虚感がすごい(汗)。あの旅行は夢・幻ではなかったのかって言うぐらい遠い記憶になっている(汗)。とはいえ燃え尽き症候群になっているわけでは無い。というのも、仕事は相変わらず忙しいのよ!!

そもそも当初の話だと、某ゲームのティザーサイトだっていう話だったのよね。
台場への出向案件があるのでガッツリはできないけど、ティザーサイトぐらいなら別に大したことではないということで上司には OK を出したんだが……。始まったらスケジュール押し押しになったりはしてた(締め切りの三日前にデザイン上がってくるとか)。
まぁでもティザーサイトぐらいなんてことはない。

と思ったらそれ以降、やれヘルプ画面やゲーム内のお知らせとかをこのティザーサイトのシステムでやると言われる。

は!?

案の定、文章を掲載したらレイアウトが崩れますってクレームが来る。

当たり前だ。そんなことが出来るような CSS の設計にしていない(爆
文章や絵を貼り付けられてちゃんと表示されるようにするには、それこそブログだのをちゃんと書けるように、タイトルなどの見出し(H1 ~ H6)、表(Table)、リスト(ul, ol, li)、そしてフォントの設定、グラフィックや動画の取り扱いなどなどを全部 CSS で定義しないといけない。
そもそもほとんどグラフィックでしか構成されていないようなサイトの作りになっているのに、今さら?

しかもなぁ、どうせ画像がメインとおもって、全部%で組んじゃったよ(レスポンシブ ウェブ デザインは%で組むと楽なのだ)。

さらに PC / スマートフォンからだけじゃなくて、ゲーム内から表示したときでもレイアウトを変えないといけないらしい。

最初から言ってよ~~~~! でも、それはそれで上司的には問題がある。なぜなら、最初からそれを言ったら仕事自体受けてないもんねw 卵が先か鶏が先か問題である(ぁ

そしてたぶんだが、この追加の部分で仕事が遅れたりしたので、上司からは解らないが、少なくともクライアントからのボクの評価は下がったと思われる。もー!

ふくの鳥と AI と WordPress

今日は同僚が鶏の唐揚げが食べたいというので、いろいろと彷徨った結果、『ふくの鳥』というお店に入った。ランチメニューがどれも鶏の唐揚げだったからだ。鶏の唐揚げって言うと、あの丸っこいのを思い浮かべるのだけど、ここのは全て一枚肉だった。
同僚は油淋鶏、ボクはカレーを選んだ。

カレー屋さんじゃないカレーはあれね、業務用ね。
当たり前か(^^;

鶏の唐揚げは美味しかったと思うんだけど、カレーがぬめぬめっとしてた。
イマイチ!

ポイント カードについて、このあいだひどい目に遭ったわけだけど(そこまで言う?w)、ふとこの間 THANK で見たロビを思い出して、そもそも AI が普及したらポイント カードいらないじゃん! ってことに気付いた。
いや、AI とかそういう単語を使わなくても現状でも可能だ。
要するに顔認識システムを店頭に置いておいて、会計の時にその人が常連さんなのかどうかを判別して貰えばいいのだ。その人の来店回数や今まで使ったお金の積算を表示するなんて簡単だ。そしてポイントの付与も楽々だ。
たくさん貯まってたら「○○ポイントたまってますけど、お使いになりますか?」と、店員が聞けばいいのだ。自動割引でもイイし、レジのタッチパネルに表示して使うかどうかを尋ねるのでもいい。

いやー、明るい未来が見えてきそうだ。これで財布が金も持ってないのにパンパンなんてことはなくなりそうだ。頼みますよ!

今、仕事をいくつも抱えているんだけど、どれもが PHP + HTML + Javascript な案件なのね。で管理画面があったりとかいろいろするんだけど、クライアントさんには WordPress でやれるようにすることが多い。要するにデザインとかウェブサイトそのものはクライアントさんが作って、システムというか仕組みの部分はボクが組んで、クライアントが作った WordPress 内に組み込むといった感じだ。

ただ 100% WordPress で済むようにはしていなかった。
ボクが作ったシステムの UI は、ボクが自分で HTML を組み、CSS を組んで提供していた。
でもこれだと見た目が良くない。ボクはデザイナーではないからね。それにシステムごとに CSS を組むのがめんどうくさかった。

そこでボクが作ったシステムを全部 WordPress 側で呼ぶ仕組みを作った。
これでボクが作ったシステムも全部 WordPress を通して表示されるようになった。UI も統一されるし、デザインも統一されるうえにクライアントも操作に戸惑うことも減る(まったくなくなるわけではない)。
今までは WordPress とボクのシステムとで管理画面をアクセスする場所が違っていたりしたので、その辺も統一された。

本当は SS とか貼りたいんだけど、開発中なので貼れない……

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

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

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

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

詳しい記事はこちらに。

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

小ネタ集、続き

憲法九条を持つ日本は国際標準からは外れている。基本的に国家は自衛権集団的自衛権を持っているのが前提で、国連なんかもそれに応じて動いている。だから日本の自衛隊が国連の一部として動こうとしてしまうとどうしても憲法や日本国内法と矛盾が生じてしまうのだ。

織田信長を語る上でよく出てくる『敦盛』。そういえばアレは何だったのだろうと今頃のように検索。平家物語の一部だったのね。そして敦盛本人は 40 年どころか 20 歳にも慣れずに亡くなっているという。

一週間くらい前からモバイル WiFi ルータを紛失した。どこかに落としたんだとは思うんだけど、家の中のどこかだと思うんだよね~。根拠は全くないんだけど(ぁ
NEC の MR04LN とかいう機械。

萌え時計を Firefox で実行してみたら、サイズ変更が全然きいてないことが判明。何だと思っていろいろ調べたら、どうやら Firefox は zoom は受け付けないらしい。transform を使えと言うことなので、そちらのコマンドを使って大きさを変えるようにする。

もー、ほんとに Firefox とボクは相性が悪い。

text-size-adjust とかるかん

いつからか忘れたけど、iOSSafari でウチのサイトを表示すると、妙にフォントがでかく表示される。今のデザインにしたとき、当然 iOS でもチェックしたはずなので、最初はこんな事なかったと思うんだけど……。
まぁ、iOS の Safari のフォントはソシャゲを作っていたときにも悩まされたんだけどね。

とりあえず CSS に以下の一文を追加して応急処置した。

 -webkit-text-size-adjust: 100%;

これで他のブラウザとかに変な影響が出ないといいんだけど(汗
下の SS は iPhone 6 によるもの。CSS ピクセル 375 x 667。左が修正前、右が修正後。
1510226651 1510226652

閑話休題。
出社したらボクの机に誰かからのお土産が置いてあった。よくみると「かるかん」って書いてある! これがかるかんかぁ。水曜どうでしょうで「白くま」っていう 750ml のかき氷の早食い競争をやるんだけど、鹿児島空港にそれが売ってなくて、代わりにこのかるかんで勝負しないかという一幕がある。
なるほど、確かにこれは藤村 D が得意そうな餡子の入った食べ物だった。
衣が独特。食感だ乾いてる感じなのにボロボロ崩れない。へー。
ありがとうございました。
1510076467 1510076469

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

今回はレスポンシブ ウェブ デザインの話。レスポンシブ ウェブ デザインって何かっていうと、一つのデザインですべてのプラットフォームとブラウザに対応することである。つまり 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 だとこうは行かなかったと思う。