2012年2月20日月曜日

【備忘録】ファィルを更新したのに画面が更新されない時のチェックリスト @iis_hara_dev

ほぼ自分用にまとめました
ありがちな順です

(1)ブラウザのキャッシュの問題
 いわずもがな。
 【対策】Ctrl+F5をしてみる


(2)アップロード先あるいはアップしているファイルが違う
 【対策】再確認

(3)システムのキャッシュの問題
・smartyやtomcatなどフレームワークなどがキャッシュを持っている場合
 イリーガルな更新をした場合などにキャッシュが更新されない時が
 あります
 【対策】キャッシュを削除してみる

(4)2に近いがmod_rewriteなどで見た目のディレクトリと違うファィルを参照させている
 【対策】.htaccess、httpd.conf、web.xml、server.xmlなど確認

(5)一部の設定ファイルは記述の仕方を誤るとエラーとならず古いままの状態を
 維持することがある
 【対策】チェックコマンド、webサイトを利用する

(6)windowsサーバーの場合、管理者権限で更新しない場合、反映されない場合がある
 【対策】管理者権限で更新してみる

2012年2月18日土曜日

ブログなどでブログラムを公開する時に気をつけたいなと思うこと @iis_hara_dev

最近某所でブログでプログラムを書く時に留意点などを話す機会があったので
その時の会話内容を簡単ですがまとめました

そのプログラムの背景を書く

単にプログラム内容を載せるだけでなくそれが
どういう場合にどうして必要になったかのを合わせて書く。
そうすることによって、使い所が理解できるし
必要とする人にとって検索にひっかかりやすくなります。


他人のプログラムは扱いは慎重に
このブログは自分の書いたものを公表する以外にも
備忘録として他の人のプログラムも転載することがありますが
必ずどこのサイトかのリンクは張るようにしてます。

まして本人が公開していないプログラムは必ず確認はとるべきです。
著作権がどうこうという法的な問題だけでなく、それ以上に信用問題です

また他の人のプログラムを自分のものかのように転載することで
見た人が「そのレベルのプログラムが書ける人」と誤解する可能性があります

これは他人の期待値を無駄に高めてしまい、結果として評価を
落としてしまう可能性もあります。
引用している時ははっきりと明示してかくようにしましょう




2012年2月5日日曜日

共有サーバー(ロリポップ、さくら、チカッパ)で簡単にPEARをインストール方法 2012年2月 @iis_hara_dev

何かと面倒な共有サーバーでのPEARのインストールを簡単に
行える方法としてgo-pear.phpがありますが
現在webの検索で引っかかるものでは古かったりするものが多いのでまとめました。

今回はロリポップで設置・動作をしましたが基本的に共有サーバーで動くはずです

参考サイト
  1. http://www.karate-style.jp/2007/06/13/pear-2/
  2. http://masha.maakikaku.jp/2008/05/gopearpear.php
  3. http://d.hatena.ne.jp/tdoi/20111228/1325054820

(1)まずgo-pear.phpを用意する必要がありますが
よく出てくる http://go-pear.org/ はドメイン切れ。
http://pear.php.net/go-pear では古いためエラーとなって
動きません
の中で記述されている
を使う必要があります。
こちらをダウンロードしてgo-pear.phpという名前で保存してください

(2)これを適当なディレクトリにFTP等でアッフロードします。
今回は
/home/foo/bar/web/lib/go-pear.php とします

そしてブラウザから
http://xxxxxx/lib/go-pear.php にアクセスします

(3)下部のnextをクリックします

(4)もろもろの設定します
Installation prefixがインストール先ののディレクトリ
php.exe path, optional (CLI command tools)がPHPのパスとなります
PHPのパスに関しては各サーバーのマニュアル参照のこと
だいたい /usr/local/bin/php になるはずです
あとはとくにデフォルトのままで問題ありません

(5)Installをクリックします
いくつか警告が出ることもあるようですが
Installation Completed !
と出れば問題ありません

(6)index.phpの修正
/home/foo/bar/web/lib/にindex.phpができているので
こちらをDLして下記の修正をします
$pear_dir = '@pear_dir@';
$pear_dir = ' /home/foo/bar/web/lib/PEAR';
※各自の環境にあわせてください

(7)各パッケージのインストール
http://xxxxxx/lib/index.php にアクセス

Quick-install a package
に欲しいパッケージ名を入れてinstallボタンを押すと自動的に
インストールされます。今回は
Net_URL2などをいれてます。

(8)インクルードパスの設定
最後にhtaccessで
php_value include_path ".: /home/foo/bar/web/lib/PEAR/"
を設定してあげると
phpで使う際には
require_once('HTTP/xxx.php');
で呼び出せます。

またPEAR内部ではrequire_once('HTTP/xxx.php');で
呼び出されているのでこれがないと動キません

ただし、ロリポップでは上記の記述が効かなかったので
phpに
ini_set('include_path', " /home/foo/bar/web/lib/PEAR/ ");
と書いて対応しました

※なお、ディレクトリの絶対パスをしらべるPHPを参考として下記に書いておきます
echo getcwd();


2011年11月11日金曜日

nullと比較するif文かくときに、一歩レベルあげる書き方

多くの言語で

if($hoge == null)

といった書き方をしますが、少しの工夫で後の多大な
バグ取りの時間を防げるかもしれません。

その「少しの工夫」の書き方とは下記のとおりです。

if(null == $hoge)

逆にしただけです。なぜこの書き方が良いのか説明します。


まず前提として多くの言語では
$hoge=1;
という代入が成功した場合、"true"を返す仕様になっています
※1 ためしてみたところ、PHPの$hoge=null;でもtrueがかえります。
※2 javaは代入された値そのものがかえるようです。

つまりif($hoge = null) という文が文法エラーとならず成り立ってしまいます。
たった一個=を忘れただけで全く意図しない動きになり、かつあとから修正するときも
非常に気づきにくいバグです。

ですが

if(null == $hoge)

と書くことによってたとえば

if(null = $hoge)

と書いてしまっても、nullに代入ができるわけではないので
コンパイルエラーや実行時エラーになります。よって早い段階でミスに気づけます。


この書き方の大きなメリットは上記の単純ミスに気づくというだけではなく、
いかにしてバグの起こりにくいソースを書くかという意識づけができることです。
PGやSEの大切な仕事として「いかにしてヒューマンエラーを防ぐか」がありますが
こういった些細な書き方一つがその意識向上のきっかけになつていただければ幸いです。

2011年11月4日金曜日

Javaの数値チェックでNumberFormatExceptionを使ってはいけない理由

この前、Javaの半角数値チェックでぐぐっていたらわりと下記みたいな
ソースコードを見つけました

private static boolean isNumeric(String hoge) {
 try {
  Integer.parseInt(hoge);
  return true;
 } catch(NumberFormatException e) {
   return false;
 }
}

これは動きとしては正しい結果をだしますが
好ましくありません。
下記のような書き方のほうが好ましいです


private static boolean isNumeric(String hoge){
 char c = null;
 for (int i = 0 ; i < hoge.length(); i++){
  c = hoge.charAt(i);
  if (c < '0' || c > '9'){
    return false;
  }
 }
 return true;
}


理由1
Javaはガベージコレクションのおかげでスマートなメモリ管理を
可能ですが、例外もあります。それは名の通り"例外"の時です。

Exceptionがthrowされると一時的でもヒープを大幅に使うので
やはりexceptionはなるべく避けるように使うべきです。

これが何十万件のデータを処理するバッチならば当然避けるべきです

理由2
上記とかぶりますがExceptionはその名の通り、「例外」ですので
プログラマの想定しなかったケースのみ発生するようなあり方が
好ましいためです。チェックのために使うというのはプログラム設計
としてよろしくないためです(※理由2は個人的見解です)



余談
たとえばほとんど数値以外の文字が入ってくること無いが
想定される場合はNumberFormatExceptionを使うケースでもよいかもしれません

ただその場合NumberFormatExceptionをthrowする、あるいはラッピングされた
なんからのExceptionをthrowするという設計のほうが正しい気もしますが

2011年9月30日金曜日

FacebookアプリでPHP SDK(v.3.1.1)を使ったバックエンド側処理

FBアプリを作るとき、フロント側とバック側で分けて作るときのサンプルみたいなもの

今回したいのは
フロント側をフラッシュやJSで実装して
通信することでバックエンド側で処理させたい
ということ

使うのはPHP SDK(v.3.1.1)

渡されるのはfacebookのIDのみ
渡される値のnameはidとアプリで個人ごとに発行されるaccess_tokenが必要
ユーザーのセッション内に
fb_(アプリID)_access_token
の名前で入っている
なお認証時に必要なpermissionを取ることを忘れないこと

以下サンプル

require 'facebook.php';//SDK読み込み
//自分のあふりにあわせて変更
$facebook = new Facebook(array(
'appId' => 'xxxxxxxxxxxxxxxxxx',
'secret' => 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
));

//ユーザーIDなし
if(!$_REQUEST['id']){
//エラー処理
}
//ユーザーID不正
if(!is_numeric($_REQUEST['id'])){
//エラー処理
}
//ユーザー情報取得
try {
$user_profile = $facebook->api('/'.$_REQUEST['userID'],'GET',array('access_token'=>$_REQUEST['accessToken']));
//print_r($user_profile);
} catch (FacebookApiException $e) {
//エラー処理
}
//友達一覧取得
try {
$friends = $facebook->api('/'.$_REQUEST['userID'].'/friends','GET',array('access_token'=>$_REQUEST['accessToken']));
} catch (FacebookApiException $e) {
//エラー処理
}
//写真をアルバムへ
try {
$facebook->api('/'.$_REQUEST['userID'].'/photos','post',array('access_token'=>$_REQUEST['accessToken'],'message' => 'hoge','picture' => '@/some/where/hoge.jpg'));
} catch (FacebookApiException $e) {
//エラー処理
}
//ウォール投稿
try {
$facebook->api('/'.$_REQUEST['userID'].'/feed','post',array('access_token'=>$_REQUEST['accessToken'],'message' => 'hoge'));
} catch (FacebookApiException $e) {
//エラー処理
}