go4it

先日、あるクライアント様のサイトでコンテンツ管理サーバーからＵＲＬでアクセスして、ページに表示する内容をＸｍｌで取得するという実装をやっていたのです。他でもやっているようにfile_get_contents(<url>)でｘｍｌを取得して．．．．
とやろうと思ったのですが、このクライアント様が利用しているYahoo small business　のホスティングサービスでは、file_get_contents()をＵＲＬで使用することに制限がかかっているようです。
穴を開けて直接ＤＢで接続しようかと思ったのですが、そういえばcurlを使えば同じようなことができるわけですね。
例えば、次のような関数を用意しておけば　curlGet(<url>でfile_get_contents(<url>)と同じことができる。
ただし、当然PHPでcurlが使える場合に限りますが。

mysqlのチューニング。
key_buffer_sizeを大きくするなど、メモリの設定をひととおり/etc/my.cnfにやり終えたら、一応SQL文そのものでチューニングが必要ないかどうかを確認するためにも、遅いSQL文をslow.logに書き込む設定をして確認するのも良いでしょう。

設定は/etc/my.cnfに
   long_query_time=1
   log-slow-queries=/var/log/slow.log
の２行を追加します。
long_query_timeの単位は秒数。この秒数よりも時間がかかったSQL文は、log-slow-queriesで指定したファイルに記録されますので、この中のSQL文からチューニングすると良いば効率的です。

さて、ここで１つ注意すべきことがあります。
上記の設定後にmysqlを再起動しても、一向に記録されない(/var/log/slow.logが作成されない）場合があります。
実際は遅いSQL文があるのに記録されないからといって安心してしまうようなことがないように、
    /var/log/mysqld.log
を確認してみましょう。
　　File '/var/log/slow.log' not found (Errcode: 13)
という記述があるとすると、mysqlのデーモンがログ・ファイルを作成できずに、slow.logの機能が実質的に無効になっている場合があるのでご注意を。

自動でslow.logが作成される訳ではないようですので、空のログファイルを作成してから、もう一度mysqlを再起動しましょう。

# touch /var/log/slow.log
# chown mysql:mysql /var/log/slow.log
# /etc/init.d/mysqld restart

SQLのパフォーマンスチューニング。

インデックスを貼ったり、
Group by、distinct、　副問い合わせ、in句、union、exists句、などなど、join、outer join を使ってテーブルの結合順序を制御したり、やるだけやって見ても、どうしても速くならなかった場合には、SQLの最後に
      　OPTION (FORCE ORDER)
を追加すると、うまく高速化が図れる場合があります。ただし、ある程度RDBMSに精通していて、効率の良いテーブル結合順序に配慮したSQL文であることが前提となるので、上級者向けだと思います。

FORCE ORDER は　SQL SERVER で使うことができるクエリヒントで、テーブル結合順序をオプティマイザに委ねるのではなく、from 句に記述したとおりに強制的に結合させることができます。通常はオプティマイザの方が賢いということで頻繁に使用することは推奨されていませんが、テーブル結合順序を調整したSQLを発行しても、どうしても速くならない、特に結合するテーブルの数が多い場合などは、使っても良いかと思います。
Oracleで言う、/*+ ORDERED */　ヒント句に相当するものですね。

私は普段デルのデスクトップPCのWindows XP環境で仕事をしており、外出先からはParallelsDesktopをインストールしたMacでWindows XPを動かしてリモート・デスクトップ接続します。

ところが最近、先日まで問題なくリモート・デスクトップ接続できていたのに、急に接続できなくなってしまいました。とほほ。
しかも状況は最悪で、Windowsのリモート・デスクトップ画面でユーザーID、パスワードを入れて接続をクリックすると、接続ウィンドウは黒いままで、接続される方のマシンがフリーズしてしまいます。
マウスもキーボード入力も効かなくなってしまうので、電源ボタンを押して再起動するしか復旧方法がないのです。勘弁してよー。

しばらく放置して途方に暮れていたのですが、原因が判明しました。
グラフィック・ボードのドライバソフトが、ある時から相性が悪くなったようで（Windowsアップデートが怪しい）、ドライバソフトを最新にしたら直った。

私のデスクトップ・マシンのグラフィック・ボードは、
NVIDIA GeForce 8600 GTS
NVIDIAコントロールパネルの「システム情報」でドライバーのバージョンを確認したところ、たしか170番代だったのですが、これを本日時点の最新である195.62にバージョン・アップしたら、無事にリモート接続できるようになりました。よかった。


インストールはNVIDIAのサイトから。
http://www.nvidia.co.jp/
「ドライバーダウンロード」をクリックした画面で、製品タイプなどの選択項目を選ぶ画面がありますが、少し下にある「グラフィックドライバ」ボタンをクリックした方が楽です。
インターネット・エクスプローラに限定されますが、ActiveXを使って自動で今インストールされているドライバとバージョンを認識してくれて、対象の最新ドライバのインストールプログラムをダウンロードすることができます。

exeファイルのダウンロードが完了したら、それを実行してインストールします。
本当は一度、ドライバをアン・インストールしてから実行すべきだったかも分かりませんが、既にインストールされているドライバとの関係で、警告画面が表示されます。
そのままOKをクリックしてインストールを完了して再起動すると、VGAの６４０X４８０解像度でXPが立ち上がるので、ちょっとあせりますが、大丈夫です。この状態でもういちどインストールプログラムを実行すれば、正しくインストールできました。

ノートPC側から、リモート・デスクトップ接続を起動して、ID、パスワードを入力して無事接続できました。
と思ったら、画面のサイズが小さいぞ〜！　まだ何か問題あるのかと思ったら、クライアントのリモート・デスクトップの設定が必要でした。
接続の前に「オプション＞＞」をクリックして、「画面」タブを選択し、リモートデスクトップのサイズを大きく設定すれば大丈夫です。

無事にトラブル以前の環境に戻りましたです。

Javaでアルファベットを大文字／小文字変換するプログラム。

まずは、大文字と小文字を対にした配列を用意する。

private static String alphabetLowerUperTbl[][] ={
{"a","A"},{"b","B"},{"c","C"},{"d","D"},{"e","E"}
,{"f","F"},{"g","G"},{"h","H"},{"i","I"},{"j","J"}
,{"k","K"},{"l","L"},{"m","M"},{"n","N"},{"o","O"}
,{"p","P"},{"q","Q"},{"r","R"},{"s","S"},{"t","T"}
,{"u","U"},{"v","V"},{"w","W"},{"x","X"},{"y","Y"}
,{"z","Z"}
};

この配列を利用して引数で与えられた文字列中のアルファベットを
変換する。


/**
* 大文字を小文字に変換
* @param str
* @return
*/
public static String utol(String str) {
String lstr="";
String ustr="";
for(int i=0;i ustr=str.substring(i,i+1);
for(int j=0;j if(ustr.equals(alphabetLowerUperTbl[j][1])) {
ustr=alphabetLowerUperTbl[j][0];
break;
}
}
lstr=lstr+ustr;
}
return lstr;
}

/**
* 小文字を大文字に変換
* @param str
* @return
*/
public static String ltou(String str) {
String lstr="";
String ustr="";
for(int i=0;i lstr=str.substring(i,i+1);
for(int j=0;j if(lstr.equals(alphabetLowerUperTbl[j][0])) {
lstr=alphabetLowerUperTbl[j][1];
break;
}
}
ustr=ustr+lstr;
}
return ustr;
}

久しぶりのJava言語によるServlet開発。
知ってる人は知っている、HttpServletRequestのインスタンスrequestオブジェクトから取得できる主な情報をメモる。

クラスドキュメントは別途参照するとして、具体的にどのような情報が格納されるのか？

Tomcat上のWebアプリ「test」を[TOMCAT]/webapps/test に配置して、
http://localhost/test/aaa/bbb/ccc/?p1=1&p2=2
というURLリクエストを投げた場合では以下のようになる。

request.getContextPath()="/test"
request.getMethod()="GET"
request.getQueryString()="p1=1&p2=2"
request.getRequestedSessionId()="xxx5xxxA3BBxxx20xxxA8FxxxE7xxx1x"
request.getRequestURI()="/test/aaa/bbb/ccc/"
request.getRequestedURL().toString()="http://localhost/test/aaa/bbb/ccc/"
request.getServletPath()="/aaa/bbb/ccc/"

getRequestedURL()はStringBufferを返すので、文字列で取得する場合はtoString()メソッドで変換します。

今回このメモを書くにいたった経緯は、servletのFilterを使ってリクエストされたURLを解読して、実際は動的コンテンツのURLにフォワードすることを考えているからです。Apacheで言うRewriteEngineみたいなものです。他にもFilterを間に挟むことによって、IPアドレスに基づくセキュリティチェックとか、携帯キャリアからのアクセスの場合は携帯用のURLにフォワードするとか、独自のアクセスログ情報を書き込むなどいろいろできそうではあります。

そのFilterのdoFilter(ServletRequest req, ServletResponse res,FilterChain chain)に渡ってくる第一引数はServletRequestなので、上で述べたような情報を取得するには、(HttpServletRequest)にキャストすることをお忘れなく。

...
HttpServletRequest request = (HttpServletRequest)req;
String contextPath = request.getContextPath();
...

あと、このFilter処理の中で、web.xmlで指定したコンテキスト・パラメーターを取得したい場合があると思います。
その場合は、init(FilterConfig filterConfig)メソッドの中で、tomcataまたはアプリが起動された時に取得したい訳ですが、Filterのinit()の時点では、まだコンテキスト・パラメータは初期化されていない訳ですから、init(FilterConfig filterConfig)内では、

this.sc=filterConfig.getServletContext();

としてサーブレットコンテキストの参照先を格納しておいて、実際のパラメータ取得はdoFilter()の方で、

this.sc.getInitParameter("parameter_name");

とすべきです。

PHP導入の最初の頃によく陥りそうな話。

PHPをHTMLに埋め込みで使っていて、かつ、HTMLをXHTMLで記述した場合に

Parse error: syntax error, unexpected T_STRING in ○○○ on line 1

みたいなエラーがでることがある。”line 1”というのがポイントでそれ以外の場合は本件には該当しないと考えてよい。

ご存知のようにXHTMLで記述する場合は、
<?xml version="1.0" encoding="utf-8"?>
という記述を文法にのっとれば１行目にする必要がある。

このとき、先頭の『<?』がPHPコードのオープンタグと勘違い
されてPHPのパースエラーが出ている訳である。

回避策としては、まずPHPコードのオープンタグに<?は使わず<?php を使うようにして、PHPの設定でショート・オープンタグ（<?）を無効にする設定にします。

.htaccess に記述する場合
php_flag short_open_tag Off

php.ini　に記述する場合
short_open_tag = On

これでXmlの最初の一行の『<?』がPHPコードの開始と勘違いされなくて済みます。

つい先ほどから、
“このサイトはコンピュータに損害を与える可能性があります。”
Googleで検索すると、その検索結果全てに上記のメッセージが表示されてリンク先を直接閲覧できなくなってしまった。
（リンクがhttp://www.google.co.jp/interstitialというページを経由するようになっている！！！）

どうしちゃったのだろう。Google側の問題だろうか？
困ったなー。

PEAR::Authは大変便利で活用してます。

オプション設定で、
"db_fields" => "*"
のように指定するとgetAuthData("name")のようなメソッド関数を用いて合致するユーザーの付加情報を取得することができると言及されています。
たとえばこちらを参照

ほとんどの説明では、上記オプションを設定すると、
　　$name=$authobj->getAuthData("項目名");
のようにして付加情報が取得できると記述されているのですが、私の場合はこれではうまく行きませんでした。
いろいろ調べていると、以下のようにgetAuthData()には引数を指定せずに呼び出した結果を一旦配列に格納して、その配列からインデックスを指定すればうまく行きました。
　　$arr=$authobj->getAuthData();
　　$name=$arr['項目名'];

仕様が変わったのかな？

↓大手ニュースサイトのニュース記事を集約したサイトを作ってみた。
最新ニュースの検索さいと−ダイジェスト・サーチ
未だいろいろと改善したところがあるのでベータ版だが。

カテゴリ別に閲覧、キーワード検索に加えて、見出しで出現頻度の高いワードを日別に集計している所が特徴。

たとえば昨日（１月２１日）にニュース記事見出しで出現頻度が最も高かった語（ワード）は“オバマ”。
大統領就任演説のニュースが注目を集めたからだろう。

その他、この日は小室哲哉被告の初公判があった日で、“小室”という語（ワード）も頻度が多かった。