PHP Archive

iPhone 6 と iPhone 5 との比較レビュー

Posted on 2014/09/24, Updated on 2018/05/16

by PHP-Archive in 一般

先日 iPhone 6 を購入して数日使ってみたので感想を少し書いてみようと思います。
私はこれまで iPhone 4、iPhone 5 を使用していて、5s を使ったことがないので 5 と比較したレビューとなります。

iPhone 6 の最大の特徴は「大型化」です。およそアイコン１つ分縦に伸び、幅も少し大きくなっています。その影響で通常の片手持ちではホーム画面に並ぶアイコンの上二段は完全に親指が届かない状態になります。その救済として、ホームボタンを２回タップ（押しこむ必要はない）すると画面表示全体が下方にスライドして画面上部のにあるものを簡単にタップできるようにする機能があります。

とはいえひとつのボタンを押すために３回のタップ操作が必要になるのはやはり手間です。時々ならまだしも頻繁に行いたい操作ではありません。はっきり言うと iPhone 6 であろうと iPhone 6 Plus であろうと両手持ち専用機です。
縦に伸びたことで重心が上に寄り、親指を浮かすと落としそうになります。どうしても片手でホームボタンを押そうとするなら落とさないフォームに持ち直してから押すことになります。
android ユーザーで大きな端末に慣れている人なら違和感はないかもしれませんが、これまで iPhone を片手前提で使ってきた人にとっては慣れが必要になると思います。今まで親指で操作していたものを人差し指で行うようにするという変化は想像以上に大きなものです。

丸みを帯びた本体も持ちにくくする要因の一つであるように思います。
一見すると角がないほうが手にフィットすると考えてしまいますが、指の関節に引っかかることがないので油断するとストンと落としそうになります。シリコンカバーを付けて滑りにくくするのがベストのようです。

大型化に伴うもう一つの問題は持ち運び方です。iPhone 5 の時は胸ポケットにちょうど収まる長さでしたが、iPhone 6 では少し飛び出ます。具体的には背面カメラがすべて見えるくらいです。（2cm程度）
なるべくかばんに入れて持ち歩くようにしたほうが良さそうです。

iPhone 5s ですでにありましたが、5 ユーザーの私にとっては指紋認証は初めて使う機能です。
App の購入時のパスワード入力やロック解除時のパスコード入力の手間が省けて楽です。今後 Apple の決済機能 ApplePay が国内で使えるようになれば iPhone を指紋認証システム付きクレジットカードとして使えるようになるのでその期待も大きいです。
精度も高く、複数の指紋を登録できるので左右の親指と人差指を登録しておけばスムーズに使えます。

他の違いというとカメラ機能です。ハードウェアの改善もそうですが、ソフトウェアの面でも進化が見られます。オートフォーカスは賢く速くなっているし、電子手ぶれ補正も強化されているように感じます。
また、レンズそのものも良くなったので暗い場所でもノイズが出にくくなりました。
ディスプレイもコントラスト比が上がり、より深い黒を表現できるようになっています。
iPhone 6 Plus であればさらに光学手ブレ補正があるのでうらやましいですね。

バッテリーの持ちもスペック上良くなっているようです。古くなった iPhone 5 とではフェアな比較はできませんが、丸一日普段通りに使ってバッテリー残量は 70% 程度でした。

iOS 8 のほうは未だ多くのバグを抱えたままで、ミュージックアプリが正常に再生できなかったり「iPhone を探す」アプリがインストールできなかったりという問題に遭遇しました。
サードパーティ製アプリも大画面化に対応したものが少ないため引き伸ばし表示になる物がほとんどでしたが、全く使えなくなるようなアプリは今のところありませんでした。このあたりは時間とともに解決すると思います。

総評
初めてスマートフォンを持つ人や、android からの乗り換えをする人にはおすすめできると思います。iPhone 5s からの買い替えでは大きな感動を得られることはなさそうです。iPhone 5 からの場合は指紋認証にメリットを感じるか次第です。iPhone 4、4s の人は本体サイズに大きな違和感を感じると思いますが、動作は滑らかでストレスがないので買い換えるには良い頃合いだと思います。

個人的な感想としては慌てて買う程でもないというのが正直なところです。せめて ApplePay が国内で使えるようになっていれば評価も変わったと思いますが、iPhone 5 の性能には満足していたので iPhone 6 が斬新なモデルであるという印象は受けませんでした。
そう言ってしまうと悪印象に聞こえるかもしれませんが、従来モデルからの変化は小さいものの、ひとつのスマートフォンとして絶対的な評価をするならとても良いものだと思います。

[XML]要素・属性の使い分けと命名規則（要素名・属性名の決め方）

Posted on 2014/09/08, Updated on 2018/02/21

by PHP-Archive in PHP

プログラミングをする上でデータを格納する標準的な形式として XML はよく使われます。
XML には値を入れておくための要素（Element）と属性（Attribute）があり、どちらを使わなければいけないという明確な決まりはありません。
しかしながら何らかのルールに従って要素に格納するか属性を使うかを決め、ファイル全体に一貫性を持たせなければいけません。

<要素 属性="属性の値">要素の内容</要素>

自分一人でルールを決めるよりも一般論を取り入れたほうが無難です。私自身要素・属性の使い分けに悩むことが多いので次のガイドラインを参考にルールについて考えてみたいと思います。

Google XML Document Format Style Guide
https://google.github.io/styleguide/xmlstyle.html

Principles of XML design: When to use elements versus attributes
http://www.ibm.com/developerworks/library/x-eleatt/

要素名・属性名の大文字・小文字

長い要素名を区切る場合、半角スペースは使えないのでそのまま続けて書くか、単語の頭を大文字にする、アンダースコア（_）を利用することになります。

<sampleelement>
<sampleElement>
<SampleElement>
<sample_element>

全て文法としては正しいです。Google のガイドラインは All names MUST use lowerCamelCase. と定めていますし、他の多くの XML 文章を見てもそうなっていることが多いので、ここは「sampleElement」としておくのが良さそうです。

ちなみに「URL」のような略語は「sourceURL」のようにせず「sourceUrl」としたほうが良いようです。しかし「iPhone」や「iMac」をどう処理すべきかは難しいところです。「sampleiPhone」のようにしてしまっては可読性が下がってしまうので、ガイドラインにはありませんが「sampleIphone」とするか「sampleIPhone」のようにしておくしかなさそうですね。

属性に関しても要素と同じ記法を使うのが良さそうです。XHTML などでは属性のみ http-equiv のようにハイフンで書くようにしている場合も多く見られますが特に理由がなければこちらも lowerCamelCase で良いと思います。

要素・属性の使い分け

一般的には要素より属性のほうが制限が多く、長すぎる内容を入れたり改行を含むものを入れるには向きません。要素であれば CDATA セクションも利用できるのであらゆる値は要素だけでも一応表現できます。

ただし、メモリ消費の観点で見ると、要素は同じ要素を複数含む可能性があるため探索に多くのメモリを消費しますが、属性は2つ以上同じ名前を持てないため、少ないメモリで済みます。
とはいえ一つの要素に多くの属性をもたせるのはあまり一般的ではなく、せいぜい 10 個程度にして相関性の強いものを子要素でグループ化してそちらの属性とするのが良いようです。

方向性としては利用者の目に触れるものは要素、管理のために使われる内部的なデータは属性にするのが良いようです。ただし Google は「このルールは別の理由で破られることが多い」と注釈を添えています。

ガイドライン（12. Elements vs. Attributes）によるとおおまかな基準は次のとおりです。（要約＆抜粋）

要素に向いているケース

・データが複数回出現するなら要素を使う。「data1=”..” data2=”..”」のようにはしない。
・一つのオブジェクトとしてまとめることができ、親子関係があるなら要素を使う。
・出現順序に意味がある場合
・複数行のデータ
・データが巨大な場合や BASE64 変換されたバイナリなど。
・内容が自然言語であれば要素に入れ、属性として使用言語を記述するのが良い。

属性に向いているケース

・管理用のIDやコード番号は属性にする。
・別のデータのクラス、役割、処理方法を表すメタデータの場合。
・上書きされない限り子孫要素にも属性の内容が反映される場合（xml:lang や名前空間宣言など）

値の記述

key-value で表すことのできるデータは要素名としてキー、属性 value として value を記述するのが良いとされています。

<genre value="science" />

また、単位系には国際単位を使うのが一般的で、できれば単位を表す属性 unit をつけておくのが理想です。

<weight value="180" unit="kg" />

まとめ

要素名・属性名は lowerCamelCase で記述し、ユーザーに見せる内容は要素に、管理・検索に使う内部的な値は属性に持たせる。
key-value のペアで表せるような単純なものであれば空要素を用いて要素名と value 属性の形で表現する。

ただし Google のガイドラインでは次のように締めくくられています。（拙訳）

“ルールの奴隷となって粗雑で独りよがりのむかむかするような汚らしい設計を作るよりはルールの一部、あるいは全てを破ってしまおう。（たとえそれが MUST とされていたとしても。）特に「シンプルなもの/複雑なもの」「メタデータ/データ」のようにはっきり分けられるなら　子要素・属性を両方使ったほうが良いが、不規則に混在させてしまうと従うのも使うのも難しくなってしまう。”

[PHP]ディレクトリー（フォルダ）の階層構造を維持したまま圧縮する

Posted on 2014/07/31, Updated on 2014/08/01

by PHP-Archive in PHP

ZipArchive クラスを使った単純なファイルの圧縮については前回の記事に書きましたが、ディレクトリーを対象に、そのサブディレクトリも含めて圧縮するには再帰的に処理する工夫が必要です。

<?php
// 圧縮するディレクトリー
$dir = dirname(__FILE__) . '/base/';

// Zipファイルの保存先
$file = './test.zip';

zipDirectory($dir, $file);


// ディレクトリを圧縮する
function zipDirectory($dir, $file, $root=""){
	$zip = new ZipArchive();
	$res = $zip->open($file, ZipArchive::CREATE);

	if($res){
		// $rootが指定されていればその名前のフォルダにファイルをまとめる
		if($root != "") {
			$zip->addEmptyDir($root);
			$root .= DIRECTORY_SEPARATOR;
		}

		$baseLen = mb_strlen($dir);
		
		$iterator = new RecursiveIteratorIterator(
			new RecursiveDirectoryIterator(
				$dir,
				FilesystemIterator::SKIP_DOTS
				|FilesystemIterator::KEY_AS_PATHNAME
				|FilesystemIterator::CURRENT_AS_FILEINFO
			), RecursiveIteratorIterator::SELF_FIRST
		);

		$list = array();
		foreach($iterator as $pathname => $info){
			$localpath = $root . mb_substr($pathname, $baseLen);
		
			if( $info->isFile() ){
				$zip->addFile($pathname, $localpath);
			} else {
				$res = $zip->addEmptyDir($localpath);
			}
		}

		$zip->close();
	} else {
		return false;
	}
}

ディレクトリ内のファイル一覧の作り方に関しては過去の記事のものをもとに少し変更してあります。
関数を使う際は引数として (ディレクトリパス, Zipファイル保存先, 親ディレクトリの名前) を指定します。親ディレクトリの名前は省略可で、指定するとその名前のフォルダがZipファイル内に作られ、ファイルは親フォルダ以下にまとめられます。

zip_root