萌え時計を疑似アプリ化するとラッキーになれる

iOS というか、iOS 版 Safari にはウェブページをアプリみたいにする機能がある。ので萌え時計をアプリっぽくしてみた。仕掛けは簡単で、Javascript で設定を記憶しておくようにしただけである。縦と横の対応は CSS で行った。

最初はただ萌え時計を表示するだけのを作った。この段階では萌え時計の HTML をただ表示してるだけ。

それに CSS で縦横に対応し、作品やキャラの大きさを設定できる UI をつけ、最後に cookie に設定を保存するようにして完成。UI は普段は隠すようにするといいのかもと思い始めている。でもその場合、下の余白に何を表示すべき何だろうか(汗

ところで iPhone で横向きのスクリーン ショットがなぜかとれなかった。結局、アクセシビリティの AssistiveTouch という機能にスクリーン ショットを割り当てて撮った。なんだったんだろうなぁ。

今日行ったランチは、楽喜亭という昭和のラーメン屋というか、店屋物屋というか。ちなみに楽喜と書いて「ラッキー」と読むw
頼んだのは湯麺のミニ炒飯セット。この店はミニ炒飯と半チャーハンがあって、ミニは半のさらに半分くらい(汗)。半チャーハンにしとけば良かったー。ちなみにカレーの写真はミニカレー。給食みたいなカレーだと頼んだ同僚は話していた。

湯麺は塩ベースのオーソドックス。野菜たっぷりだが、この量を食い切るには少し飽きてしまう。途中で胡椒を入れるとよい。量は多かった。

湯浅とトリュフとオレオレ証明書

今日は昨日、ランチを決めるときにすでに閉まっていたんだけど気になったお店に来てみた。名前を『湯浅』。どっかで聞いたことある名前なんだよね。といってもそれはこの店に過去に来たことがあるわけじゃなくて、観光地名かその観光で見たお店の名前……みたいな感じ。と思ったら、地名だった(汗

湯浅、けっこう人気の店らしいがボクが入った頃にはだいぶ席は空いていた。それでも一回は満席、二階席に通される。従業員が凄く多い。一族経営難だろうか? おばちゃんたちが所狭しと駆け回る。
まかないが厨房横のちょっとした空間に、ビールケースを裏返してテーブル代わりにして供されてたw

ボクはミックスフライ定食を注文。他の二人は天ぷら蕎麦としらす丼、海鮮丼だった。お値段いずれも 780 円。
味は二本の定食の見本とも言うべきだろうか。見た目通りの味な上に揚げ物はどれも柔らかく中まで火が通っていつつも固くなりすぎないような揚げ加減。そして写真では解らないけど、お米が美味しい! なのでおかずも自ずと美味しくなる。
いいなぁ、ここは常連になりたい。店員さんと会話を許してくれる雰囲気もあったし。

ところで帰りにマイバスケットによってデザートを物色してたんだけど、なんだか高そうなチョコを見つけたので何となく買ってみるっていうか、カロリーがすごい。そして食べると……あっま~~~~い! 喉が焼ける! 焼ける!!
それぐらいの甘さだ。
思わずお茶をがぶ飲みしてしまった。

日本のチョコ感覚でパクパク行きすぎた。そもそもこれは一人で全部食うものではない。というわけで周囲にも配りつつ(相対ダイエット)、まぁ結局はほとんど自分で食ったんだけどさ!

iPad を買った時、これを Windows ノート PC のように使おうとしたときに、オレオレ証明書で躓いたという話を書いた。結局証明書のエラーは出たまんま使っている。このエラーは iOS 起動後ブラウザを初めて起動するときに出るだけなので、まぁいっかって感じだったので、そのまま放置していたのだが、今日、ふと iOS の設定を見ていたら上のツイートのような画面があるのを発見した。

なんだこれ、いつ追加されたんだ???

というわけでこれを ON にしたら無事、ウチのサーバの証明書でもエラーが出なくなった。

ところでボクは iOS のウェブブラウザには Google Chrome を使っている。理由は単純に Chrome の方が反応が速いからだが、これは iPad では感じられない(マシンパワーが充分なので、両者の差異が出ない)。そもそも iOS は iOS が用意したレンダリング エンジン以外は許可しておらず、Safari も Chrome も速度は変わらないはずなのだが iPhone で使っていると Chrome の方が速く感じる。これはおそらく UI の出来の違いだと思われる。

でね、インターネットのリンクをタップ(クリック)するとブラウザが起動してリンク先のページが表示されるじゃない? このとき、 Windows や Android だとどのブラウザを使って開くのか設定が出来るんだけど、iOS は Safari 固定になってしまう。そのためいつの間にか Safari がとんでもない数のページを開いた状態になっていたりするのだ。

かつて EU が Windows と Internet Explorer を分離させたように、是非とも iOS から Safari 以外のブラウザが選べるように Apple に働きかけて欲しい。マジで頼みます!

iOS 版 Google Chrome はいいぞー!

事の発端は iPhone を使って URI をツイートしたりするときに Safari ではある問題が発生していたことだった。Safari で日本語を含む URI があると日本語の部分はそのままになってしまうのだ。

Safari https://amatsukami.jp/2017/03/21/ネタがない/
Chrome https://amatsukami.jp/2017/03/21/%e3%83%8d%e3%82%bf%e3%81%8c%e3%81%aa%e3%81%84/

Chrome だと日本語の部分が % から始まる変な文字列に変換されているのがわかる。こうしておかないと Twitter などでリンクとして処理してくれないのだ。なので URI をツイートとかするとき、Safari からコピーしてきた URI 文字列から日本語の部分だけエンコードして貼り付けてたんだけど、まーめんどくさい。

そこで、iOS 版 Google Chrome を入れてみた。

するとバッチリ、日本語の部分はエンコードされた状態で貼り付けることができた。有難い!
問題は Safari のブックマークの取り込みなのだが、どうも Chrome に自動で取り込むということはできないようだ。まぁアプリをサンドボックスで動かす iOS の仕組みのせいであろう。
実はボクの iPhone には行きたいご飯屋さんの食べログのアドレスが大量に登録されているのだ(笑)。仕事とかで使うアドレスはほんの少しで、手動でコピー出来るくらい。だが、食べログのアドレスはそういうわけにもいかず……めんどくさいなーw

でね、iOS 版の Google Chrome がすごく速いんだ!
あからさまに表示速度や反応速度が Safari と違う。心地よい速さ!
つーか、なんで Safari こんなに重いんだよって感じ。

もちろん欠点もある。わりと操作系が画面の上の方に固まっているのだ。逆に Safari は下の方に固まっている。片手で持った場合、フリーに動く指は親指なので画面の下の方は届くが上の方は届かないので、上の方を操作するにはもう片方の手が必要となる。
でも、画面を下に引き下げると「新しいタブを開く」「更新」「現在のタブを閉じる」ってのがでてくれるのは非常に便利だ。

そんなわけで、Safari はお役御免になるかもしれない。
下のスクリーンショットは左が Google Chrome、右が Safari。

 

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

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