気質にとって 801 とは?

ボクはよく、語呂合わせになるナンバーを見つけると、ついカメラに収めてしまう。今日見たのは 801。しかも分類番号が 583 ってことは、この車の持ち主が決めた数字であり、他に少なくともこの番号とこのかな文字のナンバープレートが 53 台はあることになる(330 から始まるので)。かな文字違いを合わせると、一体何台になるんだろうか(かな文字は自由に決められない)。
何が気になっているかというと、普通の人にとって 801 ってどういう意味があるのかなと思って。オタクだと「ヤヲイ」なんだけど、801 ナンバーが全部オタクじゃないと思うんだよね。

誕生日とか、車を買った日とか、日付でとってるのかなぁ?

まぁ、そんなどうでもいい話。

1412150784

Redmine を BTS に使うのはどうかと思う

今やっているスマフォの案件でデバッグが始まった。
作りはじめてまだ一ヶ月半だけど(笑)。
まぁ、サービス インはクリスマスなので(ぁ
いやー、よくまぁ、この短い時間でやったもんだと思いつつ……ネトゲっていいよね、後からいくらでも補修効くから。エロゲーもそうなって欲しいわ~。

でね、クライアントさんはバグ報告に Redmine を使ってるのよ。
これがもー使いにくいのなんのって。
Redmine ってのは確かにバグ報告的な機能もあるんだけど、もともとはプロジェクト管理システムであって、タスク毎のスケジュールとかどのタスクがどれくらい進んでいるかとかを管理できる。
それの応用で、そのタスクを一つのバグとして扱い、スケジュールが修正の度合い(確認、対応中、対応済み、確認済み、終了)に対応している。

で、バグ報告を受ける立場のボクとしては、どのバグがどの状態(ステータス)なのかを知りたかったりする。例えば、ボクに確認を求められているバグはいくつで、ボクが対応中のモノはいくつで、対応済みはどれだ……みたいな感じ。
ところが Redmine はこれらのステータスを一発で見ることができない。
BTS というバグ管理に特化したシステムだと、対応中を一操作で表示できるし、対応中以降のバグすべても簡単に表示できる。が Redmine だとソート条件を各状態ごとに追加して、さらに担当者がボクという条件も追加しないと見られない。
他の状態を見たいときは、せっかく設定したソート条件をいったん外して、また別のソート条件を追加しないといけない……。

うがー!!

素直に BTS 使おうよ……orz
まぁ、Redmine に BTS プラグインとかあるのかもしれないけどね。

というわけで、バグ対応がめんどくさいんじゃ、このクソがっていうお話。

あと関係ないけど、東京は今冬、初雪だったそうな。都心部でも降ったらしい。

大慶

会社の帰り、阿佐ヶ谷にある大慶に寄った。
味については過去に書いているので、あまり書くことはないのだが……まぁとにかく食べやすくてまろやかなラーメン。背脂とかがあまり気にならない。今日は会社の同僚と行った。同僚は初めて食べる。

相変わらず混んでいて、ボクらともう一人が入ってちょうど満席に。

同僚はご飯にスゴく合う、と言って、気に入っていた。
そういえばご飯と食べることは考えてなかったなぁ……ボクも今度してみようかな。

1412130768 1412130766

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

奏(sou

浅草橋にある大食い系の店を、もう一つご紹介。
』というイタリアン バー。
店そのものは大食い系を目指しているわけではない。ただランチタイムは何故かカレーとサラダがお代わり自由なのだ。
どうでもいいけど、バーのことを「バール」って言い始めたの、いつから? 最近よく見かけるようになったけど、正直、解りづらいんだけど(ぁ。最近の若い人にはバールって言った方が通じるのかなぁ??
店のシステムはこうだ。店の一角にサラダバーとカレー ルーの鍋と炊飯器が置いてあって、ランチを注文すると、そこから好きにとっていってイイというわけだ。ランチのメニューはパスタやグリル料理など。
パスタを頼むと炭水化物祭りになってしまう。

冒頭で大食い系の店ではないと言ったのは、店の雰囲気もオシャレ方向だし、女性客が多い。そして炊飯器の大きさが小さい。なのでバカバカお代わりされることは前提としてないのである。
なのでボクのような客が来ると迷惑であろう(ぁ
現にご飯の供給が追いつかなくなってしまった(^^;

味の方はカレーはまろやかで食べやすい。パスタはなかなか腰のあるパスタで、味も濃くなくて、つるっと行けてしまった。夜、イタリアンをちゃんと食べに来たくなるお店。

1412090750 1412090752 1412090754

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

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

平和島 P.A.

今日は弟一家を羽田に送りに行ってきた。
その羽田から会社に向かっていたら、平和島 P.A. の看板を見付けた。そういえば首都高のサービスエリアやパーキングエリアに入ったことないなぁと思い、ちょうど、朝食も摂っていなかったので寄ってみることにした。

想像したものより立派なパーキングだった。

ただやはり狭い(^^;

ところでサービルエリアやパーキングエリアの定番メニューと言えば、ボクはカツカレーである。特に食べたいものがない場合は、だいたいカツカレーを頼む。と言うわけでここでもカツカレーを注文。
なんかぬめっとしたルーに、味のぼやけたカツであった。
まずい!
まぁ、そんなもんか(ぉ

売り場の方は思ったよりお土産とか充実していて、面白かった。
下町のお土産が多い。とりあえず飴を買って帰った。

首都高のパーキングエリア巡りってのも、面白そうだなぁ。
わりとすぐにできそう。

1412070720 1412070725 1412070726 1412070722 1412070723