IT database for myself
アップル社のエコシステムは1社によりハードウェア及びソフトウェアが提供されるに依って至極便利な環境となっています。 少し前からは AirDrop なる機能が追加され同じApple ID端末では ドラッグ&ドロップでファイルの共有がとても便利になりましたし、 最近では iOS10及びmacOS Sierraに依ってクリップボードが共有されるのも便利に使い始めています。 其れ等便利な機能がアップル社のクラウドシステムに先鞭を告げたのが iCloud にて此れを通じて実現される 写真、連絡先、カレンダー、リマインダー、メール、メモ、iCloudドライブ、などの中にも 例えばメモでは取材などで手に入れた情報はその場でiPhoneに記録して 後から同期したPC端末のMacで加工し活用しますし 写真の扱いは最早此れ無くしては撮り貯まったものの整理整頓は難しく iPhoneをカメラとして活用するにエコシステム内での共有の簡単さは利用者に欠くべからざる環境としてあるでしょう。
商売上のホームページではヘッダーやフッター、及び必要コンテンツ内に 電話番号を表示するのは閲覧者に連絡を取って貰いたいならば欠かせません。 表示させるだけならばHTML上で記述すれば済む話です。 しかし最近ではスマートフォンが充分普及し個人個人が所有するようになり ホームページの閲覧も多くがスマートフォンからのものを配慮する必要があるようになりました。
スマートフォンは携帯電話ですから出来得るならば
電話番号の表示をタップしたと同時に通話発信して欲しいものであるのは言わずもがな、
此の事情を配慮して電話番号と
ところでデザイン上の配慮などで画像で電話番号を表示させたい要請も多くあります。 此の時画像をタップして通話発信させるには例えば以下のようなリンクを張る必要があります。
此のHTMLコードはもちろん スマホでもPC画面上でも適用されますので 機能して欲しくないPCに依る閲覧時にもクリックで電話発信しようとして 警告ダイアログを閲覧者に拝ませる羽目になります。 此の事態は出来るならば避けたいものです。
一週間前の2016年11月19日の夕方にアップル社に発注していた Macbook Pro 2016 Late 13インチ が届き開梱し様子をレポートしたのが翌日2016年11月20日の本ブログ記事 Macbook Pro 2016 Late 13インチ発注物語 でした。 前の所有機種に於いては Windows XP機からMacBook Air Mid 2013（11インチ）への移行 であるとともにWindows機の故障でもあったため仕事上シームレス且つ迅速な移行を必要としましたが今回は MacBook Air Mid 2013（11インチ） は未だ現役で未だ未だ活躍して貰わなければならないため移行作業は急がず緩りと進めている状況でもあります。
一週間の使用報告と称しても巷で話題の Touch Bar や Touch ID よりは未だソフトウェア的な熟成も図られぬ内には時期尚早とも思われ 此の記事ではほぼ新環境の構築の話柄に振られるのはご寛恕いただきたく思います。 世の中には様々MacBookを入手したら先ずインストールすべきアプリ〇〇選などのような情報を溢れていますが 基本的には既に使い慣れたMacBook環境であるのは変わりませんので 其れ等の情報に戸惑わされるのも馬鹿馬鹿しいですし独自の環境を独自の手法で構築する様子も記述せらる記事となります。 又前機種MacBook Airではアップル社の Time Machine をシステムを用いてバックアップを取っていましたが何某かの開発に特化した環境を構築する訳でもありませんし データはクラウドで運用するためクラウド連携すれば問題もなく 使わなくなったアプリもあれば既に古くなった構築環境もあるのを鑑みて MacBook Airとは似て非なる環境を構築する様子の記述でもあります。
昨日辺りから次々と届き始めているらしく 各所でMacBook Pro到着のレポートが上がっており ご多分に漏れず当方にも昨日2016年11月19日夕方に発注していた MacBook Pro 13インチ 2016 late モデルが届きましたので到着時の様子など書き残しておくのも 備忘録として用立つ際もあれば一報をものしたく考えました。 使用レポートを求めれば本記事は然に非ずしてご寛恕願いたく思います。
アップル社に発注したのは続々と届き始めた面々も恐らくは様子を同じくするでしょう、 去る2016年10月27日、日本時間では日の変わった28日深夜の Hello, again イベントの直後でしたので様子をライブストリーミング配信で見て仮眠を取って朝打ち合わせに出掛ける前に アップル社のサイトから注文をしたのでした。
何故評判も出揃っていない新機種をネット配信された僅か数時間の動画で購入判断したかと問われれば 信頼感 の一言に尽きます。 本ブログにも配信した Windows XP機の終了とMacBook Air Mid 2013（11インチ）への移行 にはWindows機からMacに乗り換えた事由が様々挙げられていますが 今となってはWindowwも10となってOS上の問題は少なくなり 相変わらず機種選定には労力は必要ないものの 今回の新機種となれば決してコストは低廉なものではありません。 ただ此の記事に記された MacBook Air Mid 2013（11インチ） はなんのかんの言っても一番廉価なモデルでありながら 3年間此れと言う支障もなくきっちり仕事に用いるに応え稼がせてくれたのが強い信頼に繋がり 今回のリピート購入に繋がったという処です。 ジョナサン・アイブ氏インタビュー に言われるデザインのシンプルさは何も見た目に効用のあるだけではなく 構造の簡素さは丈夫さに繋がると思われ 斯くも頑丈な点もMacの美点に数え上げられるべきだとは常々思う処でもあります。
処で今回固定ページの中ほどにウィジェットを表示させたい要請がありました。 元来ブログシステムはオンラインで記事編集出来るのが旨味であり 其の延長線上にあるのが通常はサイドバーなどに表示させるウィジェットです。 然るにウィジェット上の編集を固定ページや投稿ページの中ほどに反映させたい要請も必然です。 此処でウィジェットに記述された内容をコピー＆ペーストすれば宜しいではないか、 という解決法が先ず想起されますが今回此の方法の採用はなりません。 なんとなれば中ほどに表示させたいウィジェットにもショートコードが用いられていたからです。 ウィジェットの記述をそのままコピー＆ペーストすればショートコードが実行されないで ソースコードが其の儘出力される結果となります。 此れを避けるべく当該ショートコードに対応する処理をfunctions.phpに記述するのは 返って複雑化を招き難儀な状態となる処か、 利用者に取ってはブログシステムの旨味も享受出来なくなり本末転倒です。
只ほど高いものはない、と言う訳で無料ブログサービスシステムから WordPressに二つのブログ、1,000以上に及ぶ記事をまとめて移行したのですが 合間、合間の作業ともあって随分と時間が掛かってしまいました。 テーマは親テーマに独自のカスタマイズを少々施す子テーマを宛てがう手法を採用しました。 移行作業開始時の親テーマには最新のWordPress標準のテーマ Twenty Fifteen を利用しましたが年も改まって最新の標準テーマ Twenty Sixteen が提供されていますので 移行のほぼ完了した段階で親テーマを最新のものへと更新した次第。
確認したところTwenty Sixteenがインストールされてもおらない状況でしたので 先ずは其のインストールからです。
WordPressで作成したブログサイトのメンテナンスとしていつものように 404 Not Found 出力を見ていれば不審なアドレスへのアクセス試行が幾つか見受けられたので対処が必要となりました。
先ず一つ目の不審なIPアドレスが得られたのは 2016年10月11日午後0時26分に立て続けに6回のアクセスの試行が記録されていたログからでした。 以下が其のソースURLのリストになります。
リファラーは記録されておらず如何にも怪しいアクセス試行です。 大体が運営ブログに上記リストに該当するアドレスは用意してありません。 其処で fckeditor をWikipediaで調べてみると以下の引用の如き記述があります。
FCKeditorはオープンソースのWYSIWYGテキストエディタでWebページ上で使うことができる
また fckeditor セキュリティ でネットを繰ってもどうも場合に因っては脆弱性を有する恐れも有り勝ちな情報が目に止まります。 恐らくは、不自由と言うと語弊がありますがWordPress上のエディターより Web上のエディターに特化した此のツールを好んで使用している多くのユーザーが居て 彼等の使用ツールの脆弱性に付け込むべくWordPressを利用しているサイトを見付けては 上のアドレスをクロールして回っている輩ではないかと思われます。
iPhoneアプリに限らずとも開発場面に於いては座標の把握は大切でしょう。 Xcode の2Dゲームフレームワーク SpriteKit に於いても例外ではなく先祖ノードの当たるシーンに配置する 各子孫ノードには其々、座標原点、即ち基準位置があり標準では上下左右ともセンターに規定されています。
さて但し原点を左上に取るSpriteKit座標系では座標を考える上で 各ノードの左上に基準点があった方が具合が良い場合も多いでしょう。 此の中央に標準設定される基準点を変更せしめるプロパティは SKSpriteNode には anchorPoint として用意されています。
以上の如く記述すればノードの左上に基準点が設定されるのは屡々用いる所でもあります。 ところで文字を画面に表示せしむる SKLabelNode も同じで良いかと言うと此れは anchorPoint プロパティは持ちませんのでどうすれば良いかを調べ、検証します。
既に Xcode のバージョンは8を数える2016年秋現在、 バージョン5から画像管理用に特別な機能が導入されていました。 Asset Catalog です。 アイコンやローンチ画像管理に於いては所与のものとして用いていた .xcassets 拡張子の付与されるフォルダの外見を有したこの機能ですが 本来画像管理用の機能であれば此れを用いて画像を管理したいところです。 調べてみると此の機能を利用するだけでアプリ容量の低減にも有用だという記事もあります。
iOSアプリの画像を最適化してアプリの容量を減らすブログ shobylogy の2016年3月16日の記事ですが Asset Catalogを利用すると Slicing が有効になりデバイスごとに必要な画像のみが配布されるバイナリに含まれるためであるとの言及があります。 また併せてXcode6からはベクターデータが使えるようになったとの旨情報も有り あわよくば画像の作成をベクターデータで一つで済ませたい目論見もあり 本記事で其の為の検証をするものです
此れからのアップル社のiPhoneの画面解像度に関する方針としては launchimage.xib ファイルでローンチ画像を設定の上、 相対的な数値で全体を構成するべく予想されれば 此れに反する本ブログに2016年9月25日に公開した記事 ローンチイメージソースで解像度を指定し2サイズ対応で済ます方法 に於いて記す手法を採れば孰れアプリ申請拒否の憂き目に遭わぬとも限らず と懸念した処で当該記事は筆を擱きました。 さて、どちらの手法を採用するか躊躇う所考えているばかりでは埒も明かず 取り敢えずは25日の記事とは異なる手法の採用を鑑みた検証も実施しておくに如かず、 とてものする記事になります。
先ず画面サイズを簡単に一覧にすれば上のようになるでしょう。 画像は既存の前二者の2サイズに加え新しく後二者に対応させる必要がありますから 都合4サイズへの対応となるのでした。 しかし巷間用意する画像に関する情報に於いては 等倍、2倍、3倍の3種類で宜しいとの流布が喧しく其れが真実がどうかも併せ検証したく思います。 検証用に用意したのは以下の3サイズの replay-test ボタン画像です。
