IT database for myself
以前に良く見掛けた、 タイトルで言い切った 、的なエントリーです。 知ってる向きには何を今更、と言った処にて、 以下読む必要はありません。
上にリンクを貼り置いた Standing on the Shoulder of Linus ブログの2010年4月8日の記事では、 WordPressのバージョン2.9に於いて 投稿サムネイル機能 が追加され、バージョンが3.0に上がると其れは Featured Image と命名されたそうで、其の和訳こそ今WordPressユーザーに一般に流通する アイキャッチ画像 なのでしたが、日本語の決まっていないベータ版で訳が割り振られたそうなのです。
恥ずかしながら此の事実に気付かされたのは…
仕上がりイメージは斯うです。
先ずは最下層に背景画像があります。 上の例では神社の写真が其れに当たります。 其の上に帯がのり、其の上、左方に白のアイコン、右方に白のフォント文字が乗ります。 アイコンとフォント文字を包含した帯は元は紺色ですが、 乗算で其のまた背景画像に重ねられており、 唯に単色の不透過色の場合とは異なる深みを感じさせるイメージを醸し出しています。 此れを皆、CSSのみで実現したく試行錯誤しました。
参考のために唯に単色の不透過の紺色の帯の場合を下に貼り置きましょう。 随分イメージが異なるのがはっきりします。
CSS3 から追加されたプロパティ Flexbox は其のレイアウトの柔軟さ故に現在主流の レスポンシブ （Webデザイン）と相性が良く、 行列のグリッド配置を扱わねばならない場合、 Floatプロパティに代わり頻繁に用いられるようになりました。 端末幅に応じて横5つ並びのアイテムが 4つ、3つと減じても見た目に違和感は抱かれない塩梅となっています。
処でレスポンシブに於いてはプロパティの値の単位に 百分率も頻繁に用いられる処です。 従来PCでの閲覧に限られて考えられていたデザインに於いては サイズは固定で主に単位としてピクセルが用いられていましたが、 閲覧者の環境に応じて多くのサイズが考えられるデバイスの 横幅にピタリと合わせる為には其れでは間に合わず パーセンテージの採用されるに至りました。
また主流の座からは滑り落ちたものの Microsoft社製のブラウザもまだまだ残念ながら健在です。 世の中のデファクトスタンダードにも総意とも言える標準にも従わぬ、 Windows独占時代の残滓の如き路線たるオレオレ詐欺ならぬオレオレ仕様から 忌み嫌われたブラウザはインターネットエクスプローラ（IE）から今では Edge（エッジ）へと装いを改められていますが、其の中身はどうでしょうか。
今回、Edgeに特有に発生するFlexboxプロパティで パーセンテージを単位に使った場合に問題が発生するのを端無くも発見しましたので 本記事に共有するものです。
恐らくは世の中で最も遅いセキュアサーバー化ではないでしょうか。 Google社が提供するブログサービス Blogger （ブロガー）の独自ドメイン（カスタムドメイン）に於いてです。
セキュアサーバー化とはホームページデータを保存しているサーバーをSSL化することで 表示のリクエストを送ったユーザーのブラウザとの間で其の通信が暗号化されるようにすることを言います。 セキュアサーバー化されたホームページにアクセスすると アドレスバーのドメインの前のお馴染みの HTTP の表示がHTTPSと変化します。 此の S はセキュアのSを表しています。 こうすることで通信の途中経路で通信内容を傍受されても内容が漏れ難くなりますから 早くからパスワード入力やメールフォーム、ネットショップのカートでは必須のものとされ、 現在では其れがWebサイト全体に敷衍されるに至ったのでした。
古くはコンピュータの処理能力も低く 通信毎に暗号化と複合化をホスト、ブラウザ共に繰り返すのは好まれない面もありましたが、 現在ではコンピュータの能力は数桁単位で向上しています。 また暗号化と言うからには信頼できるものが必要で 其のための第三者機関からのSSL証明書発行には多額の経済的負担もあり Webマスター連から厭われる理由でもありましたが現在では其の負担も低減しています。 従って現在ではセキュアサーバー化は推奨されこそすれ決して拒まれる理由はない訳です。
およそ検索エンジン最大手たるGoogle社が推し進めており 検索結果の順位上もHTTPS化は優遇されるとの情報もあって 多くのWebマスターは挙って自ら運営するWebサイトのセキュアサーバー化を推し進めました。 しかし当のGoogle社が提供するBloggerサービスでは今の今迄 遂にHTTPS化は提供されるには至りませんでした。
ディープラーンングなどは及びもつかないものの、 iPhoneアプリにゲームとしてユーザーをもてなす以上、 規模は小さいながらもユーザーの入力に対する反応を返すアルゴリズムを用意すべし、 とて此れを ゲームAI として手元の開発ゲーム バルーンズ・オキュパイ への実装の取っ掛かりを記した記事が2017年10月6日に本ブログに配信した以下の記事でした。
本記事には此の前記事に紹介したコードを今一歩進めた考察を記す処です。 其の要件としては前記事に於いては キャラクターの出現ポイント検出の処理と移動の処理を任意単位時間、2秒に1回 としており、 此れを同時に処理していたのでユーザーの待ち時間が多くてゲームとして成り立たないので 此れを解決したい、と言うものです。 従って任意単位時間の取り扱いについて考える必要があります。 本ブログには此れに関して2017年10月24日に以下の記事を配信しています。
アップル社からiPadがローンチされて以来すっかりタブレットは市民権を得た感があります。 従って今でもiPadはタブレットの代表として世の中に認知される所となっていると言って過言ではないでしょう。 PCよりお手軽に起動出来、ソファに腰掛けて利用可能ながら、 スマートフォンより表示領域が大きいタブレットは、 電子書籍閲覧や、動画サイト閲覧などに威力を発揮しますが、 矢張りWebサイト閲覧は其れ等の中でも最も利用頻度の高いものでしょう。 iPadでは標準装備のWebブラウザ Safari が大いに用いられる処です。
さて現在Webサイト実装の主流として台頭して来ている手法が レスポンシブWebデザイン です。 昔風に言えばリキッドデザインと言えば通りが良いかも知れません。 リキッドデザインが現代風に進化して一つのHTMLファイルで 様々な表示領域の端末に対応可能としたのがレスポンシブWebデザインで、 一般に「レスポンシブ」と言えば其れを指す程普及した様に思います。
処で此のレスポンシブWebデザインをタブレットの代表格たるiPadで表示すると多くの場合、 表示崩れなど問題が生じる様です。 共に現在の主流たる手法と端末が相性が悪いのは由々しき事態です。 願わくばW3Cなど規格制定組織やアップル社など大企業の対応が進み 何の考えもなく問題なく表示されるのが最も宜しい解決法でしょうが、 現時点ではどうも其の様な方向に進んではいないらしいので、 どうしてもWebサイト制作側で其々対応が必要となります。 折角の表示領域の広いiPadであれば是非情報の一覧性の優れたPC版の表示を求めたく、 本記事ではiPadでレスポンシブWebデザインの表示崩れを防ぎPC版の表示を目論見ます。
スマートフォンに於けるWebサイト表示では PC表示に比べて一般的に表示領域が狭くなります。 スマートフォンでは縦に構えて閲覧される場合が多ければ特に横幅は制限が生じるものです。 此の為、一覧性が劣れば工夫が表示にも必要になります。
例えば図に見られる様にリンクリストをカテゴリ毎にまとめ 上部にタブを設え該当するリンクリストのタブがタップされた場合に リンクリストの表示を切り替えるのはしばしば見られる手法でしょう。 図ではデフォルトでオレンジ色のリンクリストAがアクティブとなって表示されており、 他の緑色のリンクリストB、薄紫色のリンクリストCは非表示となっています。
処で、其々のリンクリストカテゴリ内のリンクが増えれば、 此れ又、縦に長くなってスクロール必須の一覧性の劣る事態が生じますから、 下の図の如く其々のリンクリスト下部に示した様な其々のカテゴリに応じた ページングを表示するのも良く用いられる処でしょう。
此れを何も考えず其々のリンクリスト上のページングリンクをタップすると どのカテゴリのリンクリスト上あったとしても 新しく開かれるページはデフォルト状態であり、 上の図で言えばリンクリストB上のページング、リンクリストC上のページングから遷移して開かれるページでは リンクリストAが表示されてしまうでしょう。 閲覧者の身になればリンクリストB上のページングから遷移したページでは 開かれるタブはリンクリストBでなければ困惑してしまいます。 此れではユーザービリティ上、大きな問題を抱えていると言わざるを得ません。
其処で此の問題を解決する為に…
スマートフォン閲覧用のWebサイト制作にあたって、 「/sp/」などと命名したディレクトリを立て、 ルート「/」のPC版と一対一で対応させた上でスマートフォンからのアクセスの場合には スマートフォン専用ページを表示させるのは以前は一般的な手法でした。 現在ではレスポンシブWebデザインが主流となり余り見られなくなった手法ではありますが、 当該手法を採用したWebサイトのメンテナンスに於いては PC版との整合性を取る必要に迫られる事案もあります。
例えばブログシステムに於いて一般の利用者が記事投稿する際に 内部リンクを記載すればPC版にリンク先を求めるのは当然でしょう。 すると然るべきリダイレクトが施されていない場合には スマートフォンで当該サイトを訪れた閲覧者はPC版リンクを踏みますから 折角用意したスマートフォンページは表示されはせず、 一般的に横幅の広い、従って小さな文字のページの閲覧を強いられる格好になってしまいます。
其処で問題のあるリンクに於いては スマホ版での巡回に支障をきたさない様に配慮し、 PC版のリンクアドレスをリンク時に改変して「/sp/」を先頭に挿入したい要請があります。 本記事では此の実現にjQueryを用いて解決を図りたく思います。
ゲーム開発に於いては単位時間の処理が欠かせないものとして iPhoneアプリの製作の際、基本的な統合的開発環境のXcode上での処理について 本ブログに稿をものしたのが以下の2017年3月27日の配信記事でした。
-(void)update:(CFTimeInterval)currentTimeメソッドに於ける任意時間のコールバックメソッド
処で斯くも重要な要素たる単位時間処理は 唯に一箇所のみで必要となるに限られるものでもなく 手元の開発ゲーム バルーンズ・オキュパイ でも複数箇所で利用するに如くはない事態が出来しました。 具体的にはキャラクターの移動処理とバルーン陣地の拡大処理が異なる単位時間に処理されるのが其れで 而して一つでは間に合わない様相を呈したのです。
其処で対処として考えたのが…
デザイン上、問題ないレベルのレイアウトを安易に実現出来るため屡々採られる一部を幅広に取るモデルがあります。
中でも図示した様にメイン画像の部分を幅広にするだけでなく 其の画像が次々に切り替わる所謂画像スライダーを実現したいと言う要請は決して少なくはないようです。
しかし此の要請の実現に於いては問題が発生します。 画像スライダー部分をページ全体を規定する一定の幅より広く取ると ブラウザの表示時、デスクトップパソコンなどで充分画面サイズが広ければ問題ないのですが 一般にノートPCなどの小さな画面では横幅が収まり切らず横スクロールが発生し、 ちょっとしたことで画面が左右に動き扱い難いだけでなく 此の様なデザインを良しとする向きには許容範囲を超える横スクロールバーが表示されてしまいます。
処で解決のために画像スライダー部分をレスポンシブ対応にすると ブラウザの横表示が狭い場合には横幅はきっちり収まるのですが 縦幅も応じて小さくなってしまい、 他のコンテンツ部分と著しい差が生まれてしまいます。 此の時画像だけならまだしもメイン画像部分には惹句などが記されることも多く 其れ等の文字は極めて読み難い状態が招かれざるを得ません。
此の問題を解決するためにメイン画像部分を背景画像、即ちスタイルシートで background-images に指定する方法が考えられるでしょう。 此の手法を取れば画像を常に一定のサイズで表示されるにも関わらず 幅広の部分の横幅がブラウザサイズを超えても ブラウザサイズがページ全体を規定する一定の幅以上であれば横スクロールは発生しません。
