投稿日:

MAMP でバーチャルホスト

このエントリーをはてなブックマークに追加
はてなブックマーク - MAMP でバーチャルホスト

MacOSX Lion + MAMP 2.0.5 でのバーチャルホストの設定メモです。

１）MAMP 上のポート変更（任意）

MAMP のデフォルトのポートは 8888 ですが、いろいろ面倒なので 80 に変更します（好みですので、別に、やらなくても良いです）。

MAMP の管理パネルを開いて [環境設定] > [ポート] 内の Apache ポートを 80 に変更します。

以下、この前提でのお話です。
ポートを変更されない場合は、適宜読み替えてください。

なお、ついでに、MacOS の [システム環境設定] > [共有] の「Web 共有」が OFF になっていることを確認しておきます。もし ON になってたら、OFF にしておいてください（80番ポートが競合するため）。

２）バーチャルホストの設定

ターミナルを起動して、mamp の中の httpd.conf を編集します。

httpd.conf の末尾に、以下の記述を末尾に追加します。

ディレクトリのパスや、サーバー名は個々の環境に合わせて設定します。

ここでは、/Users/yuka2py/Projects 以下に複数のバーチャルホストのディレクトリを配置する前提で、local.foreignkey.jp のドキュメントルートを /Users/yuka2py/Projects/foreignkey/public としています。

３）hosts ファイルの編集

local.foreignkey.jp のドメインでアクセスできるように、hosts ファイルにエントリを追加します。
root パスワードを聞かれるので、入力します。

末尾に以下の記述を追加します。

以上で、http://local.foreignkey.jp で /Users/yuka2py/projects/foreignkey/public にアクセスできるようになります。

 

 

 

投稿日:

phpfog に git で接続する

このエントリーをはてなブックマークに追加
はてなブックマーク - phpfog に git で接続する

phpfog に git で接続します。…というかこれが出来ないと、phpfog では何も出来ないっぽいですから誰しもがやるし、それにぜんぜん難しくも無いことですが、例によってやっぱりちょっとつまづいたので、以下、メモを残しておきます。環境は MacOS X Lion です。

Public key の作成とコピー

まずは、ssh 接続の為の公開鍵の作成です。

phpfog の ssh key 登録画面にある、「Learn how to create a key>」の先の説明書の手順を参考にしつつ、以下のコマンドで作成しました。

ここで、ssh-keygen に -C オプションで phpfog に登録しているメールアドレスを指定しています。
また、key のファイル名はデフォルトで僕は OK なので、そのまま [enter] しました。

これで、id_rsa および id_rsa.pub のキーファイルが作成されました。

次に、公開鍵の id_rsa.pub を次のコマンドでクリップボードにコピーします。

これでクリップボードにコピーされます。

余談ですが、実は最初、vim で開いて範囲選択してコピーしてたのですが、その後の行程が何だか上手くいかず、選択が悪かったのかも知れませんが、とりあえず上記の方法は確実で、安心です。

phpfog へのキーの登録

さて、phpfog への公開鍵の登録です。

phpfog の管理画面で MY ACCOUNT > SSH Keys にアクセスします。

Nickname は誰のどんな接続用のキーか分かるようなラベルです。適当で OK です。

Public Key は上で作成してコピーした内容です。そのままペーストしてください。

最後に [Save SSH Key] で登録完了です。

成功したら、以下のような画面になると思います。

git で接続する

phpfog 上のアプリケーションをローカルに clone します。
プロジェクトディレクトを作成するロケーションまで cd して、以下のコマンド実行です。

ここで、git@git01…. の文字列は、php fog のアプリケーションコンソールの右上に表示される文字列です。

以上で、無事 clone できました。

 

 

投稿日:

IE6外しを上手く説明するトーク

このエントリーをはてなブックマークに追加
はてなブックマーク - IE6外しを上手く説明するトーク

第2回「HTML5など勉強会」 に行ってきました。

その中で、「IE6問題」を強く投げかける発表がありました。「IE6」がいつまでも Web 制作会社を苦しめ続けるのは、「そもそも Web 制作会社が IE6 をサポートし続けていることが一番の原因」と言う提言があって、僕的にはまったくその通りだなぁーと思ったりしたわけです。…とはいえ、実際のところお仕事の中には競争があります。お仕事を失うリスクを考えたりして、なかなか IE6 外しをお願いできない状況があることも事実みたいです。

そこで、僕なりのお客様とのコミュニケーション例を少しですがまとめてみました。少しバイアス掛けているトークもありますが、嘘は無いと思っています。どなたかの参考になればー嬉しいです！

IE6は既に10年も前のブラウザです。国内で7%ぐらいのシェアを残していますが、主にシステム移行が難しい企業内ユースですので、コンシューマでのシェアは無視できる程度だと考えています。

IE6は最近のモダンなブラウザと比べてセキュリティに劣る部分もあります。 Webアプリケーション全体のセキュリティを重視するのであれば、IE6を対象外とするのも、ひとつのアプローチです。（ちょっと無理あるかな？）

最近では、IE6を対象外とするメジャーなサイトも増えて来ましたね。実際、弊社がデサインで参加させて頂いている月間数千万ページビューの或るサイトでは、IE6を対象外とするよう、先方の担当者さまより依頼がありました。その理由として、十分にシェアが下がったという認知はもとより、無駄なマークアップやハック、JSの採用を減らせることで、結果、サイトの構造がシンプルになりSEO性能を高めやすく、またサイトの保守性が向上するため、将来に渡る保守コストの低減が期待できるからでした。

IE6の対応は正直なところコストが掛かります。…古いブラウザですし、コンシューマシェアも殆どありません。これにコストを掛けて対応するよりも、IE6非対応であることを利用者に明示する方法もあります。たとえばこういったアプローチも紹介されています。 http://moongift.jp/2011/01/20110114-2/

ie6alert-js の採用は、最新の Flash バージョンを採用してアプリケーションを開発するよりも、利用者に与えるインパクトは少ないのではないでしょうか？ ie6alert-js は、IE6のユーザーに対して、なるべく違和感のない方法で、ブラウザアプリケーションのアップグレードを提案します。

同じ見積もり額で、IE6にも対応する業者様があるとのことですが、よく考えてみてください。IE6対応コストが無くなる訳でありません。サイトの本質的なクオリティを高めるために本来適用されるべきコストを、その業者はIE6対応に割くわけです。

明かな嘘があればご指摘くださいまし。
また、他にも良いのあれば教えてくださいまし♪

投稿日:

Androidで必須なのに意外に抜けている処理

このエントリーをはてなブックマークに追加
はてなブックマーク - Androidで必須なのに意外に抜けている処理

Androidでアプリ作ってたら普通にハンドルしなきゃ行けない処理だろうだけど、意外に抜けてしまっているっぽい処理エトセトラです。見積もりやディレクションの際にも抜けないように注意したいですね。

インターフェース

  • もろもろ処理に時間が掛かって ANR 発生
    ⇒時間のかかる処理は別スレッドで処理
  • 何かでユーザーを待たせたら…
    ⇒プログレスを出す。終わったら知らせる

ネットワークアクセス

  • ネットはだいたい時間掛かるので
    ⇒別スレッドで処理
  • オフラインに処理しようとして失敗
    ⇒処理前にオフラインチェックして、オフラインの時はユーザーに知らせる
  • 通信に時間が掛かり過ぎて帰ってこない
    ⇒タイムアウトを設定する
  • 通信に失敗
    ⇒適切に例外をハンドリング。必要なら処理をリトライさせる

スレッド

  • 複数のスレッドが同じ変数に同時にアクセスして時々変になる
    ⇒synchronized や volatile を使って正しく同期制御する。
  • いくつかのスレッドが同時に走って重たい。そもそも同時に走る必要無ければ…
    ⇒タスクのキューを用意して、１つ以上のスレッドでタスクを順次処理
  • スレッドを途中でキャンセル（UI的にキャンセルに見せて、実際にはキャンセルしないで走らしたままじゃないか？）
    ⇒Interrupt を正しく使い、また適切に自分で終わらせる（スレッドの基礎知識は正しく身に付けましょう）
  • ボタンタップでスレッド起動する処理とかで、連打されて同じ処理のスレッドが乱立するようになっていないか？
    ⇒今の処理が終わるまで次の処理要求はスキップする
    ⇒今の処理をキャンセルして、次の処理要求を実行する
    ⇒今の処理が終わるまでボタンを無効にして連打できないようにする
  • ファイル保存（インターネットやカメラなど、さまざまなデータをデバイスに保存する時）
    • どこに保存するかちゃんと検討する？（ローカル領域 or SDカード）
    • そのまま保存してても大丈夫か考える？（データを抜かれるリスクと対策の検討？）
      ⇒暗号化して保存するなど
    • ディスクいっぱいでエラー（大きなファイルなら意外にある）
      ⇒ちゃんと例外を処理しよう

他にもあると思いますが、ご指摘いただけると幸いです。

投稿日:

Androidでのプッシュ通知の検討と実装メモ

このエントリーをはてなブックマークに追加
はてなブックマーク - Androidでのプッシュ通知の検討と実装メモ

お知らせなどのプッシュ通知の実装は、ユーザービリティなどを考慮すると、非常にセンシティブな要件項目です。情報を出したいお客様は、時に過度な情報送信を主張されますが、それがお客様の目的と合致するかというと、必ずしもそうではない…というか、私の経験上は、どちらかというと間違った選択であることが多いですね。ディレクションにおいてはお客様とよく相談し、お客様にプッシュ通知の利害をよく説明し、ご理解いただくこと、またご理解頂けるように説明する能力が、制作会社にも求められると思います。

さて、例えば目覚まし時計などのように、通知されること自体が、ユーザーがアプリケーションに求める主たる機能である場合を除いては、コントローラブル（ON/OFF可能）であること、かつ「あまりうるさく無い」こと、といったあたりが良い落としどころのようです。

今回は、先日制作したアプリケーションについて、その仕様検討・実装のメモを残しておきます。

通知仕様の検討

アプリケーションの概要

まず、アプリケーションの要件は次のような感じでした。

  • 定期的に電力会社の情報をチェックする
  • 電力不足になると、ユーザーに通知する

アプリケーションの目的は、「節電」です。ユーザーはアプリケーションをインストールすることで、節電の為の行動を促される仕組みを持っています。通知は、電力不足の傾向が高まった時にそれをユーザーに知らせて、さらなる節電を促すものです。

ユーザー特性

今回、ユーザーには次のような特性があると推定しました。

  • 能動的に節電に取り組む意思がある
  • ある程度頻繁な通知も、許容される可能性が高い
  • 通知はなるべくタイムリーに欲しいと考えている
  • 電池消費の多いアプリは困る
  • 過度な通知を嫌う

検討

これをもとに、次のような検討をしました。
  • どんなふうに通知するか？ 画面表示だけで良いか？
    …音声やバイブレーションでの通知は過剰ではないか？
  • 画面表示だけの通知なら、お知らせは画面ONの時だけで良くないか？
    …OFFの時はどっちみち見えないし
  • じゃ逆に、画面OFFの時は、電力チェックしなくて良い
    …電池節約できる
  • 最低チェック間隔は必要か？
    …頻繁に画面ON/OFFする人もいると思われる
  • 電源つないでデスクトップに置いてる人もいるよね？
    …画面ONの時だけじゃしばらくお知らせ出ないから、画面ON時は定期的なポーリングが必要
  • 通知のON/OFFは必須

決定された仕様

以上から、結果的に以下の通知仕様とすることになりました。

  • 通知方法
    • Notificationで表示する
    • 音やバイブレーションでの通知はしない
    • 次回の電力チェックで通知要件が無くなったらNotificationをキャンセルする
  • 電力チェックのタイミング
    • スクリーンON時、電力チェックする
    • 最低チェック間隔を設けて、過度な電力チェックをスキップ
    • スクリーンON中、定期的にポーリングして、電力チェックする
    • ポーリング間隔は、電力会社の情報更新間隔と合わせる

実装メモ

今回は上記の仕様を満たす為に、以下のような実装を行いました。

  • BroadcastReceiver
    • android.intent.action.SCREEN_ON
      1. bindService して、サービスの checkAndNotify() でチェックして必要なら通知
      2. Alarmで次回の定期チェックをセット
    • android.intent.action.SCREEN_OFF
      1. Alarmをクリア
    • android.intent.action.BOOT_COMPLETED
    • android.intent.action.PACKAGE_CHANGED
      1. SCREEN_ON/OFF 用の IntentFilter を登録（これらは動的にしか登録できないから）
  • Service
    • checkAndNotify
      1. 前回チェック時間を確認、最低チェック間隔を超えていたら：
        1. 別 Thread でチェック～必要なら通知
      2. 前回チェック時間として現在時間を保存（Preference）