iPhone4を1ヶ月使って思った15のこと

iPhoneに乗り換えてちょうど1ヶ月が経ちました。

初めてiPhoneを持ったもんだから、ガラケーからの使い勝手の違いに戸惑いながらも、その中で感じたことをまとめてみました。

上記の写真は、my iPhone。

カバーは

ELECOM iPhone4用 レザーケース ホワイト MPA-P10LCWH/エレコム

￥2,835

Amazon.co.jp

を使ってます。

iPhoneを持って感じた15のこと

1. SMSの表示がチャット形式になるため、使い方に難がある

旧携帯で使ってたメールアドレスはiPhoneに乗り換えても継続して使えるところはありがたいのですが、専用アプリの使い勝手が悪い・・・。

チャット形式となり、個人ごとにスレッドが表示されるような感じになります。

なので、メールが来た順に時系列に見るなんて事ができません。

まぁこれはiPhone買ったときに、i.softbank.jpのメールアドレスが貰えるので、そちらをメインで使うことで回避できますが。

2. SMSは、一斉にメール送信しても個々に返答がばらけて表示されるために、本当にあて先に含まれているのか不安になる

またSMSの件ですが、メールを複数人に一斉送信しても、返答が個人ごとにスレッドが分けられて表示されます。

なので、その人が全員送信して返答しているかどうかがわからない・・・。

別の人から返答があったら、「あー届いているんだなぁ」みたいな。

3. メールアプリの仕様もそれほど便利に作られていない

SMSがあまり使い物にならないから、別で配られたi.softbank.jpのアドレスを使っていても、クライアントアプリの使い勝手がイマイチ良くない。

アカウントの設定変更やフォルダを作るのにMy SoftBankにアクセスしてから作らないといけないとか。

フォルダの振り分けも標準機能では実装されてませんし。

ただ、GmailやHotmailが一発設定できてメールアプリから読めるのは便利と思いました。

4. なんでも途中で抜けられ、途中から再開できる感覚が戸惑った

とりあえずセンターボタンを押せば、アプリ起動中でも途中で抜けられ、またそのアプリを起動すれば再開できるって感覚に最初は戸惑いました。

今までの携帯では、一つの事しかできなかったので。

慣れれば、それってスゲーって感じになりましたけどね。

5. アラームのスヌーズの間隔設定ができないのね・・・

そもそもアラームがどこにあるか探すのに苦労（便利→時計→アラーム）したんですが、朝は一発で起きられない人なので、繰り返しアラームを鳴らすスヌーズ機能を便利に使っていたんですが、その間隔を細かく設定できないようです。

スヌーズは9分固定という中途半端な感覚になるので、複数のアラーム設定しておくかその間隔に対応できるように少し早めに設定しておく必要が出てきます。

6. アプリはかなり便利だけどiPhoneなくしたらオワルなぁとか

使い始めて結構な量のアプリを入れてみましたが、どれもサインインしている状態になるので、iPhone無くしたりしたら大変なことになるなぁ、と思いました。

人に貸すのも少し戸惑うかなぁとか。

パスコードロック（設定→一般→パスコードロック）をオンにしてたら、少しは安心なんでしょうけど。

7. 新品でもアプリ使いまくってたら電池が一日持たない

買ったその日に設定変更をガチャガチャしてたり、アプリをインストールしてずっと遊び続けてたら全然電池が持ちませんでした。

まぁ、平日仕事中とかはそんなに弄ることないので大丈夫なんですが、それでも一日の終わりは残り10%ぐらいになってます。

個人的な感覚として通信系の処理を行うと結構電池が減ります。

なので、メールの取得間隔を長めに設定しておくとか、Wi-Fiを自動で探す昨日をオフにしておくとか、アプリ起動しまくったら一旦iPhoneの電源を落とすとかすれば、結構電池もちがよくなる印象です。

8. カメラがかなり綺麗

カメラの能力自体は500万画素と、日本の中ではその他の携帯に付いているものより劣っています。

ただ、撮影後に見た写真はその他の携帯で撮影したものよりかなり綺麗に見えます。

なので、カメラ撮った後の画像処理やらiPhoneで見る際の解像度とかの影響の方が大きいのかなぁって印象を受けます。

カメラアプリも面白いものが多いですしね。

- iPhoneオリジナル

- MoreLomoアプリで変換した写真

9. デスクトップ上での操作方法に困惑する

要は指でタップしたり、ドラッグしたりして操作するわけで、最初は直感的に何をどうすればいいのかがわからないわけですね。

アプリの削除方法（アイコンを長押しすると削除画面に切り替わる）とか、フォルダの作り方（アイコンを長押しして、アイコン同士をドラッグして重ね合わせる）とか、iPhoneの電源を落とす（上部にあるスリープボタンを長押し）ことさえも。
ただ、説明書をまったく読まなかったわけですが、おそらくこんな感じの操作じゃないかなぁ、ってのをやってみたら意外とそうだったりしてびっくりしたりもしましたけど。

10. ハンドストラップ付きのケースが快適

これは、個人的な意見ではありますが、買うまでに結構iPhone落としてディスプレイ割れたとかいう意見を見てたら怖くなって、ケース選ぶときにハンドストラップ付きのものを買いました。（一番上の写真で掲載しているもの）

見た目は悪くなるんですが、手に巻きつけながら操作できるので、安心感がかなり違うかなぁと。

あと、保護フィルムも付いてたんですが、これも必須かなと。

1ヶ月しか使ってないですが、結構フィルムに傷が付いてます。

11. 画面の縦・横の回転がちょっと鬱陶しい

iPhoneの持つ位置や角度で画面が合わせて縦や横に回転してくれるんですが、その機能が返って煩わしく感じたりすることが。

あと、元に戻すのに反応がイマイチ悪いかなぁと。

縦にしてるのに、横表示のまま戻ってくれなかったり（少し手前にiPhoneを倒すと戻りやすい）。

写真見たりするときは横の方がいいなど、機能自体は合った方がいいんですけどね。

12. Softbankの回線が悪く感じる

フルブラウザで見たり、アプリの容量が大きかったりと、携帯の頃から比べると格段に通信料が大きくなったりしているわけですが、それでもiPhoneを提供しているキャリアとして通信のバックボーンをもう少ししっかりして欲しいかなと思ったりします。

iPhone自体にアンテナ問題があるので、本体の問題なのかキャリアの問題なのか、はたまたTwitterなどアプリを提供するサービスの問題なのか切り分けが難しいところではありますが、結構つながらなくて待ちぼうけていることがあったり。

あと、Wi-Fiスポットであればかなり快適に使えるので、設定しておいて損はないと思います。

13. 誤操作が多い

タッチスクリーンということもあって、ポケットに入れておいたり、手で持って歩いてたりしている時に、勝手に操作が進んでたりすることがあったりします。（しっかりスクリーンロックしてればいいんですけどね）
あとは、慣れの問題だとは思いますが、どこまで操作したらどうなるのか見えづらくて、例えば電話番号を押した後に発信の確認をされると思ってたらいきなり電話がかかったり・・・。

電話とかは、センターボタンを押してもキャンセル扱いにならないので、何をどうすれば取り消し操作がされるのかもちゃんと覚えておかないとなとか感じたりしました。

14. カレンダーが見づらい

なんせ祝祭日の情報がないですからね・・・。

全てがグレーで表示されているカレンダーなので土日もどこかわかりづらかったり。

15. iPhoneアプリはやっぱり凄い

iPhone自体に備わっている機能は、非常にシンプルなものだけが用意されているんですが、それを補うアプリの量と、個々のアプリが秀逸なものが多いです。

ゲームとかは最強の暇つぶしになりますしね。

先に書いたように、カメラアプリとかも種類が多いので、カメラ機能が豊富な携帯がいいという人でも十分に乗り換える価値はあるように思えます。

まとめ

やっぱり使い勝手が全然違うので、その戸惑いによるものが多かったですが、最近はだいぶ慣れてきて快適に使えるようになりました。

そして、常に持ち運ぶ電子機器としてはできることがそれまでの携帯電話と比べ格段に多いので、自分のライフスタイルそのものも変えてくれたりしてます。

少なくとも、ガラケーに戻ろうという気は起きないですけどねぇ。

[PR]iPhone バリュープログラム(i)登場！驚きのスピードを驚きのプライスで。

[PR]SoftBank SELECTION

[PR]So-netでauひかり！今なら20,000円キャッシュバックキャンペーン実施中！

関連記事

家庭内でiPhoneを快適に使うためにWiFi無線ルータを買ってみた

実際に買って使ってみたiPhoneの充電器に関するまとめ

旅行の写真をiPhoneアプリで加工してみた - 2010.10

携帯がPC化するんじゃなくてPCが携帯化しないかね

何故プログラマーはシステムを作り直したくなるのか

システムの構築が無事に完了し、リリースできたとしても何か納得いかなくてそのプログラムを修正したいという衝動に駆られることはよくあったりします。

その理由を探ったときに、所詮は自己満足の世界であったりもするわけですが、その自己満足ゆえに湧き上がってくる感情が、そんな風に駆り立てるのかなと思ったりします。

完璧なシステムではないことの嫌悪感

完璧なシステムというのが無いことはわかりきっていることではありますが、それでも自分の中のベストな設計やプログラミングのイメージというものを持ってたりもします。

そこから外れたものを作ってしまうとその嫌悪感から、作り直したい衝動に駆られたりします。

自分のベストなプログラムが書けなかった理由は、外部的な要因が理由という場合もあるでしょう。

例えば、プロジェクト途中で予算を削られたり、スケジュールが差し迫ってきたり、体制面でサポート受けることができない状態にないなど、やむをえない理由で想定していた対応ができなかったというのは良くあることです。

自分のこだわりを持つというアーティスティックな面がある一方で、その納品先や利用者のことを考えると、いつまでも自分だけのこだわりを押し通すこともできなかったりもするわけです。

なので、自分の中にあるもやもやっとした気持ち悪さがありながらも、そのまま致し方なくリリースをしたものの、やはりそのつっかえがいつまでも気になってしょうがないということになったりします。

また、技術の進歩で作ったものがひどく陳腐化して見えることもあります。

その時の最新技術を用いたとしても数年経てばすでに時代遅れということはよくあります。

そして、新しい技術への憧れというものもあるわけで、そういった感情がより作り直したい感情を促進することにもなったりします。

自分の技術力向上で「こうやっとけば良かった」という後悔

その当時の自分のレベルでベストなものを作り上げたとしても、自分自身が成長していく過程で、あの実装はこうやっとけば良かったのかと後悔が芽生えることがあります。

それは、利用していた技術全般が向上していっているという外的要因ではなく、自己の中にある内部的な要因です。

しかし、これは自分の成長そのものを表していたりもします。

開発の現場での経験をつむにしたがって、様々な開発言語や開発環境、優れたプログラマーとの交流によって、レベルアップをすれば、当然あのときの自分の考えが間違っていたとか、あの時これを知っていたら活用できていたのにと、思い返すことにもなります。

技術以外のことでもそうですが、最初はまったくわからなくただこうすればいいというポツンと点として存在していた知識が、経験の中で線で結ばれていきます。

その過程で、あの時悩んだ事はこうすれば解決できたんだと、急に過去を思い出したりするわけです。

これは、致し方ないことで誰しも通る道にはなるでしょうからあまり考えすぎても仕方ありません。

ただ、その後悔が大きくなるというのは、次のシステムへの愛着が生み出す感情なのかもしれません。

システムへの愛着

後悔が起きる理由は、そのシステムへの愛着というものもあるでしょう。

特にこだわりなく作ったシステムであれば、さほど気にもならないでしょうけど、自分が最初に作ったものや長いプロジェクトと多くの仲間で作り上げたシステムというものには、妙な愛着があって保守をしてあげたい衝動がでてきたりもします。

プロジェクトの立ち上げから携わればその設計思想がわかっていたり、保守の中でも長く付き合えば付き合うほど、その詳細な仕様が把握できて自分の分身のように扱えたりもしてきます。

それがなお更、愛着を増幅させるきっかけにもなるでしょうし、運用フェーズの中で出てきた課題に対してすぐに対応したいという感覚にも陥ります。

システム仕様の詳細が頭に入っていればいるほど、仕様の変更に対して頭の中で解決する方法がすぐに見つかったりもします。

頭でわかっているなら、すぐにでも手を動かしたくなる衝動にも駆られるわけです。

規模が大きくなり、メンテナンスにかかるコストが大きくなってきたため、そのシステム自体を一から再構築しようとすることがあります。

基盤が変わり、開発環境が変わったとしても、気持ち的には前のシステムの継続的に保守している感覚があったりして、前のバージョンのシステム構築で出た後悔を一生懸命に消化しようと考えてたりもします。

まとめ

最初に書いたようにどれも自己満足の世界であったりもします。

なので永遠に終わりにならない対応になったりもするわけですが、どこかしら作ったものに対して喉につっかえたような感覚が作り直したい衝動を継続的に呼び起こし、それがエンジニアの仕事の面白さでもあり、自己の成長の糧にもなるのかと感じたりします。

関連記事

サービス構築の実行コストは構築側より提案側のほうが上回ってるんじゃないかって話

プログラマが知るべき97のこと

形骸化しやすい運用プロセスとその設計

プログラマがウリに出来るデザイン

プログラマがプログラミング以外にしていること

何でも屋であることの強みと危うさ

新しい技術とどう付き合い適用していくかって話

プログラミングが出来る人になるための熱意

「考える」ために作る7つの環境

システム屋が非システム屋と話すときに留意すること

[PHP] デーモンとして動かせるTwitter botの作り方

「OAuthを使ってPHPからTwitterへ投稿する 」にて、OAuth経由でTwitterへの投稿の仕方が把握できたので、Twitter用のbotを作ってみることに。

今回は、さらに以前に書いた「PHPのプログラムをデーモンとして動かしてくれるPEAR::System_Daemon 」を使うことで、cronを利用することなしにbotを常時動かせるようにしてみます。

OAuthの認証はPEARパッケージのHTTP_OAuth を、そしてPHPのプログラムをデーモンとして動かすために同じくPEARパッケージのSystem_Daemon を使って構築します。

それぞれの使い方は、上記エントリを参照してみてください。

日付を定期的に投稿するTwitter bot

今回作るbotは、とてもシンプルに1分ごとに現在の日時をTwitter上に投稿するというものです。

OAuth認証時に必要なコンシューマーキーやアクセストークンの取得方法等については、「OAuthを使ってPHPからTwitterへ投稿する 」に書いています。

<?php

require_once 'System/Daemon.php';
require_once 'HTTP/OAuth/Consumer.php';

$app_name = "tweet_daemon";

// デーモンの起動オプション
$options = array("appName"        => $app_name,
                 "authorEmail"    => "foo@example.com",
                 "appDir"         => dirname(__FILE__),
                 "appRunAsUID"    => 500,
                 "appRunAsGID"    => 500,
                 "logLocation"    => dirname(__FILE__) . "/" . $app_name . ".log",
                 "appPidLocation" => dirname(__FILE__) . "/" . $app_name . "/" . $app_name . ".pid");

System_Daemon::setOptions($options);

// デーモンの起動
System_Daemon::start();

// コンシューマーキー
$consumer_key    = 'Your Consumer Key';
$consumer_secret = 'Your Consumer Secret';

// アクセストークン
$access_token        = 'Your Access Token';
$access_token_secret = 'Your Access Token Secret';

// デーモンが生きてるかチェックしながらループ
while (!System_Daemon::isDying()) {

    try {
        $http_request = new HTTP_Request2();
        $http_request->setConfig('ssl_verify_peer', false);

        $consumer = new HTTP_OAuth_Consumer($consumer_key, $consumer_secret);
        $consumer_request = new HTTP_OAuth_Consumer_Request;

        $consumer_request->accept($http_request);
        $consumer->accept($consumer_request);

// リクエストトークンの発行を依頼
         $consumer->getRequestToken('https://twitter.com/oauth/request_token');

// リクエストトークンを取得
         $request_token = $consumer->getToken();
        $request_token_secret = $consumer->getTokenSecret();

// リクエストトークンをセット
         $consumer->setToken($request_token);
        $consumer->setTokenSecret($request_token_secret);

// 発行済みのアクセストークンをセット
         $consumer->setToken($access_token);
        $consumer->setTokenSecret($access_token_secret);

        $tweet = date('Y/m/d H:i:s');

// OAuthを利用してTwitterの投稿APIへつぶやきを投げる
         $response = $consumer->sendRequest('http://api.twitter.com/1/statuses/update.xml', array('status' => $tweet), 'POST');

// 投稿した結果を取得
         $xml = new SimpleXMLElement($response->getBody());

// 投稿失敗の場合
         if (!empty($xml->error)) {
            System_Daemon::log(System_Daemon::LOG_ERR, $xml->error);
        }

    } catch (HTTP_OAuth_Consumer_Exception_InvalidResponse $e) {
// リクエストトークンの取得が失敗した場合はログを出力し、60秒待機してからリトライ
         System_Daemon::log(System_Daemon::LOG_ERR, $e->getMessage());
        System_Daemon::iterate(60);

        continue;
    } catch (HTTP_OAuth_Exception $e) {
// Twitterへの投稿が失敗した場合はログを出力し、60秒待機してからリトライ
         System_Daemon::log(System_Daemon::LOG_ERR, $e->getMessage());
        System_Daemon::iterate(60);

        continue;
    }

// SLEEP処理(60秒待機)
    System_Daemon::iterate(60);
}

System_Daemon::stop();

基本的に、以前書いたOAuth経由でTwitterへ投稿するプログラムや、System_Daemonの使い方に書いたプログラムをベースに書いています。

60秒待機の処理（System_Daemon::iterate）が、デーモンが動くサイクルになっています。

ここを調整すれば、好きなタイミングでTwitterへ投稿処理が行われます。

ただ、接続処理による遅延などがあるので厳密に投稿が1分ごとに行われるわけではありませんが・・・。

また、エラー発生時も同様に60秒待機してからリトライの処理を行うようにしています。

エラー処理の部分だけは新たに加えていますが、try～の中でリクエストトークンの発行依頼を行い、取得できなかった場合は最初のcatchにてその例外エラー（HTTP_OAuth_Consumer_Exception_InvalidResponse）を取得するようにしています。

また、実際にTwitterへ投稿しようとした際に反応がなかったりした場合は、最後のcatchにてその例外エラー（HTTP_OAuth_Exception）を取得しています。

Twitterの過負荷（鯨さん出現）などによって、結構エラーが発生することが多いです。

例外処理が発生し、適切なエラーを捕捉てあげないとPHPは致命的なエラー（fatal error）を発行します。

（詳細は、マニュアル参照 ）

そして、致命的なエラーが発生するとデーモンも落ちてしまいます。

また、投稿結果のレスポンスを受けてのエラーハンドリングは、「OAuthを使ってPHPからTwitterへ投稿する 」の最後に書いたようなエラーメッセージのレスポンスをTwitterから受け取った場合の対処です。

まぁ、一度正常に動いてしまえばコンシューマーキーやアクセストークンが間違っていたり、投稿内容が重複したりして怒られるということは無いかと思いますがね。。。

- Twitter botからの投稿イメージ

2010.09.09追記

一日中、このbotを動かしてみて拾ったエラーをさらしとく。

メッセージは例外処理でHTTP_OAuthが返したエラーメッセージを拾ったものです。

Unable to connect to tcp://api.twitter.com:80. Error #0:  [l:78]

Unable to connect to ssl://twitter.com:443. Error #136080474:  [l:78]

Failed getting token and token secret from response [l:72]

User is over daily status update limit. [l:67]

しかも、結構出てる量が多い・・・。

API使い切ったのはしょうがないですけど、接続エラーが24時間で60回弱でてました。

[PR]★ロリポップ！★WordPressやMovableTypeの簡単インストール、cron、共有SSL対応！

[PR]キャンペーン開催中！パソコンを買替えるならFRONTIER

[PR]光ファイバー/ADSLを楽しむなら「安心」「安全」の@nifty！

関連記事

Twitterで計画停電のグループ検索BOT作りました

OAuth経由でTumblrの情報を取得・投稿するPHPスクリプト

OAuthを使ってPHPからTwitterへ投稿する

OAuthを通してPHPからタイムラインの情報を取得する

PHPのプログラムをデーモンとして動かしてくれるPEAR::System_Daemon

ソケット通信でサーバーの状況を監視する

cURLを使ってHTTPクライアントプログラムを作る

Twitterのお気に入りをTumblrへ投稿するプログラム書いたよ

Amebloに設置していたツイートボタンをTwitter公式のものに変えました