Macbook Pro 2016 Late 13インチ一週間使用報告

MacBook ProとMacBook Airの共演
MacBook ProとMacBook Airの共演

一週間前の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 BarTouch ID よりは未だソフトウェア的な熟成も図られぬ内には時期尚早とも思われ 此の記事ではほぼ新環境の構築の話柄に振られるのはご寛恕いただきたく思います。 世の中には様々MacBookを入手したら先ずインストールすべきアプリ〇〇選などのような情報を溢れていますが 基本的には既に使い慣れたMacBook環境であるのは変わりませんので 其れ等の情報に戸惑わされるのも馬鹿馬鹿しいですし独自の環境を独自の手法で構築する様子も記述せらる記事となります。 又前機種MacBook Airではアップル社の Time Machine をシステムを用いてバックアップを取っていましたが何某かの開発に特化した環境を構築する訳でもありませんし データはクラウドで運用するためクラウド連携すれば問題もなく 使わなくなったアプリもあれば既に古くなった構築環境もあるのを鑑みて MacBook Airとは似て非なる環境を構築する様子の記述でもあります。

"Macbook Pro 2016 Late 13インチ一週間使用報告"の続きを読む

Macbook Pro 2016 Late 13インチ発注物語

昨日辺りから次々と届き始めているらしく 各所で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の美点に数え上げられるべきだとは常々思う処でもあります。

"Macbook Pro 2016 Late 13インチ発注物語"の続きを読む

固定ページ内のショートコードでショートコードを含む埋め込みウィジェットを機能させる方法

WordPressに於いてショートコードは使い出があり2015年3月12日に最終更新されているサイト WordPressの実 の記事のもある通り投稿ページや固定ページの記事内でPHPコードを実行させるべく下手にプラグインを用いるよりは 安心も出来るため頻繁に用いる処です。 固定ページにはPHPコードではなくショートコードを利用する!

処で今回固定ページの中ほどにウィジェットを表示させたい要請がありました。 元来ブログシステムはオンラインで記事編集出来るのが旨味であり 其の延長線上にあるのが通常はサイドバーなどに表示させるウィジェットです。 然るにウィジェット上の編集を固定ページや投稿ページの中ほどに反映させたい要請も必然です。 此処でウィジェットに記述された内容をコピー&ペーストすれば宜しいではないか、 という解決法が先ず想起されますが今回此の方法の採用はなりません。 なんとなれば中ほどに表示させたいウィジェットにもショートコードが用いられていたからです。 ウィジェットの記述をそのままコピー&ペーストすればショートコードが実行されないで ソースコードが其の儘出力される結果となります。 此れを避けるべく当該ショートコードに対応する処理をfunctions.phpに記述するのは 返って複雑化を招き難儀な状態となる処か、 利用者に取ってはブログシステムの旨味も享受出来なくなり本末転倒です。

"固定ページ内のショートコードでショートコードを含む埋め込みウィジェットを機能させる方法"の続きを読む

親テーマをTwenty FifteenからTwenty Sixteenに移行する

只ほど高いものはない、と言う訳で無料ブログサービスシステムから WordPressに二つのブログ、1,000以上に及ぶ記事をまとめて移行したのですが 合間、合間の作業ともあって随分と時間が掛かってしまいました。 テーマは親テーマに独自のカスタマイズを少々施す子テーマを宛てがう手法を採用しました。 移行作業開始時の親テーマには最新のWordPress標準のテーマ Twenty Fifteen を利用しましたが年も改まって最新の標準テーマ Twenty Sixteen が提供されていますので 移行のほぼ完了した段階で親テーマを最新のものへと更新した次第。

確認したところTwenty Sixteenがインストールされてもおらない状況でしたので 先ずは其のインストールからです。

管理画面 >> 外観 >> テーマ >> 新しいテーマを追加  Click!
Twenty Sixteen >> インストール  Click!
"親テーマをTwenty FifteenからTwenty Sixteenに移行する"の続きを読む

不審なアクセスとWP-Banプラグインの導入

WordPressで作成したブログサイトのメンテナンスとしていつものように 404 Not Found 出力を見ていれば不審なアドレスへのアクセス試行が幾つか見受けられたので対処が必要となりました。

先ず一つ目の不審なIPアドレスが得られたのは 2016年10月11日午後0時26分に立て続けに6回のアクセスの試行が記録されていたログからでした。 以下が其のソースURLのリストになります。

  • /admin​/fckeditor​/editor​/
  • /fckeditor​/editor​/
  • /common​/fckeditor​/editor​/
  • /manage​/fckeditor​/editor​/
  • /js​/fckeditor​/editor​/
  • /include​/fckeditor​/editor​/

リファラーは記録されておらず如何にも怪しいアクセス試行です。 大体が運営ブログに上記リストに該当するアドレスは用意してありません。 其処で fckeditor をWikipediaで調べてみると以下の引用の如き記述があります。

FCKeditorはオープンソースのWYSIWYGテキストエディタでWebページ上で使うことができる

また fckeditor​ セキュリティ でネットを繰ってもどうも場合に因っては脆弱性を有する恐れも有り勝ちな情報が目に止まります。 恐らくは、不自由と言うと語弊がありますがWordPress上のエディターより Web上のエディターに特化した此のツールを好んで使用している多くのユーザーが居て 彼等の使用ツールの脆弱性に付け込むべくWordPressを利用しているサイトを見付けては 上のアドレスをクロールして回っている輩ではないかと思われます。

"不審なアクセスとWP-Banプラグインの導入"の続きを読む

SKLabelNodeの基準位置(座標原点)を変更する

iPhoneアプリに限らずとも開発場面に於いては座標の把握は大切でしょう。 Xcode の2Dゲームフレームワーク SpriteKit に於いても例外ではなく先祖ノードの当たるシーンに配置する 各子孫ノードには其々、座標原点、即ち基準位置があり標準では上下左右ともセンターに規定されています。

さて但し原点を左上に取るSpriteKit座標系では座標を考える上で 各ノードの左上に基準点があった方が具合が良い場合も多いでしょう。 此の中央に標準設定される基準点を変更せしめるプロパティは SKSpriteNode には anchorPoint として用意されています。

myNode.anchorPoint = CGPoint(x:0, y:0)

以上の如く記述すればノードの左上に基準点が設定されるのは屡々用いる所でもあります。 ところで文字を画面に表示せしむる SKLabelNode も同じで良いかと言うと此れは anchorPoint プロパティは持ちませんのでどうすれば良いかを調べ、検証します。

"SKLabelNodeの基準位置(座標原点)を変更する"の続きを読む

Asset Catalogで画像を管理する

既に Xcode のバージョンは8を数える2016年秋現在、 バージョン5から画像管理用に特別な機能が導入されていました。 Asset Catalog です。 アイコンやローンチ画像管理に於いては所与のものとして用いていた .xcassets 拡張子の付与されるフォルダの外見を有したこの機能ですが 本来画像管理用の機能であれば此れを用いて画像を管理したいところです。 調べてみると此の機能を利用するだけでアプリ容量の低減にも有用だという記事もあります。

iOSアプリの画像を最適化してアプリの容量を減らす

ブログ shobylogy の2016年3月16日の記事ですが Asset Catalogを利用すると Slicing が有効になりデバイスごとに必要な画像のみが配布されるバイナリに含まれるためであるとの言及があります。 また併せてXcode6からはベクターデータが使えるようになったとの旨情報も有り あわよくば画像の作成をベクターデータで一つで済ませたい目論見もあり 本記事で其の為の検証をするものです

"Asset Catalogで画像を管理する"の続きを読む

画面解像度を鑑みた画像サイズを検証する

此れからのアップル社のiPhoneの画面解像度に関する方針としては launchimage.xib ファイルでローンチ画像を設定の上、 相対的な数値で全体を構成するべく予想されれば 此れに反する本ブログに2016年9月25日に公開した記事 ローンチイメージソースで解像度を指定し2サイズ対応で済ます方法 に於いて記す手法を採れば孰れアプリ申請拒否の憂き目に遭わぬとも限らず と懸念した処で当該記事は筆を擱きました。 さて、どちらの手法を採用するか躊躇う所考えているばかりでは埒も明かず 取り敢えずは25日の記事とは異なる手法の採用を鑑みた検証も実施しておくに如かず、 とてものする記事になります。

  • 3.5インチ(iPhone4s)
  • 4インチ(iPhone5, 5s)
  • 4.7インチ(iPhone6, 6s, 7)
  • 5.5インチ(iPhone6 Puls, 6s Plus, 7 Plus)

先ず画面サイズを簡単に一覧にすれば上のようになるでしょう。 画像は既存の前二者の2サイズに加え新しく後二者に対応させる必要がありますから 都合4サイズへの対応となるのでした。 しかし巷間用意する画像に関する情報に於いては 等倍、2倍、3倍の3種類で宜しいとの流布が喧しく其れが真実がどうかも併せ検証したく思います。 検証用に用意したのは以下の3サイズの replay-test ボタン画像です。

"画面解像度を鑑みた画像サイズを検証する"の続きを読む

ローンチイメージソースで解像度を指定し2サイズ対応で済ます方法

開発対象機種がiPhoneであればこそ様々なフラグメントに悩まされもせず 安心して開発に専心出来るのが良点でもあったのですが 時代の趨勢はいつ迄も其れを許す訳もなく 愈々アップル社も旗艦iPhoneの画面サイズを多種類擁するようになりました。 以前、此のブログにiPhoneアプリ開発を扱うようになってからは iPhone4s及びiPhone5、5sの2サイズの解像度に対応すれば良かったのですが iPhone6以降ではPlusが加わり4サイズに対応する必要が生じたのです。

print(self.view?.bounds.width)

以下にシミュレータで上記コードを実行して取得した、 即ち画面横幅の各デバイスのサイズを記し置きましょう。

  • iPad2:320
  • iPad Pro:375
  • iPhone4s:320
  • iPhone5s:320
  • iPhone6:375
  • iPhone6 Plus:414

此の状況に於いて以前のように2サイズ対応の処理で済ます方法はないのか、 検証してみたのが本記事の趣旨となりますが、 その際サイト ぐーたら書房 の2014年9月10日の以下記事が役立ってくれました。

"ローンチイメージソースで解像度を指定し2サイズ対応で済ます方法"の続きを読む

入れ子になったUIViewの座標の把握

入れ子になったUIView座標系

2Dゲーム開発に於いては座標の把握を難儀に思う処です。 2Dゲームフレームワークの SpriteKit を用いれば Scene 中の座標はその親 View たる UIKit の支配下にあるものとはY軸が逆転しますから尚更です。 Viewの入れ子はキャラクターの行動制限や把握などに便利なので利用したいのですが 入れ子にすればする程多重化した座標系は複雑化しますから トレードオフの関係となりジレンマで歯痒さを感じる処です。

iPhoneアプリ開発に於いて画面構成の基本となるのは UIView クラスです。 此のクラスは bounds プロパティと frame プロパティを持ち両者は CGRect を型としています。 開発を進めていけば両者の使い分けに混乱を来して来るのを感じた向きも多いのではないでしょうか。 どうやら入れ子になる座標系の把握については 先立って此れ等UIViewのプロパティを確り把握する必要があるようです。

ついてはサイト Sun Limited Mt. の2010年4月3日の以下の記事が大変参考になりました。

"入れ子になったUIViewの座標の把握"の続きを読む