伊藤くんの開発メモ https://ameblo.jp/camesys/ 色々な開発をしている中で、調べたことを忘れてない様にメモを残していきます。間違った記述が有ったら、ご勘弁・・・やさしく指摘して下さい。(笑) ja PHPにおける@（アットマーク）の意味 （これから頑張ります）

時々、PHPのソースをみていると、
関数などの前に@（アットマーク）を使用している時があります。

これはエラー制御演算子といって、
エラーがあってもエラーメッセージを出力させないようにするものです。

PHP 5では…


$ito = $_GET["ito"];

という書き方をすると、
エラーが出ることがあるので（原因は不明らしい）、
そんな時には…

@$ito = $_GET["ito"];

と書けば回避できます。

他にも、エラー判定が返り値で判断できるものは、
エラー制御演算子を使用したほうがいいかもしれません。


PHPerな方には常識かもしれませんが、
まだまだビギナーなもので。。。


参考WEB：
PHPでの@（アットマーク）の意味
PHPの疑問～変数前の@(アットマーク)～
]]> https://ameblo.jp/camesys/entry-10951917737.html Wed, 13 Jul 2011 01:14:11 +0900 filter_var関数とRFC規約違反アドレス
$result = filter_var($address, FILTER_VALIDATE_EMAIL));

というようなシンプルな書き方でメールのフォーマットチェックを行ってくれるのですが、
RFC規約違反アドレス（ドットが連続使用されたアドレス等）に対しては、
FALSEを返すようです。なんてお利口！

ただ！

RFCという世界的な基準の規約に違反しているとは言え、
日本、特にケータイの世界において、
RFC規約違反のアドレスはまだまだ現役なので、
個人的にはメールフォーマットチェックは、
filter_var関数使用しないほうがいいんじゃないかなーと思います。

ちなみに、このRFC規約違反のアドレスは日本のケータイ市場で数年前問題になったようですが、
現在は新規でダブルドット等のアドレスを取得することは各キャリアともに出来なくなりました。

このような状況と、filter_var関数がPHP5.2以降に正式に登場したことを考えると、
filter_varがRFC規約違反をはじくというのは至極真っ当なことだと思います。

何が言いたいかというと、悪いのはfilter_varじゃないよってことです！
（filter_var自体はURLのチェック等も行ってくれるとっても素敵な関数なので）
]]> https://ameblo.jp/camesys/entry-10938450691.html Thu, 30 Jun 2011 00:59:40 +0900 JavaScriptでのIE判別
JavaScriptでIEかどうかを判断するのは１行で出来ちゃいます。


<!-- IE判別 -->
<script type="text/javascript">
　var isMSIE = /*@cc_on!@*/false;
　if (isMSIE) {
　　　　　/*
　　　　　IE用の処理
　　　　　*/
　} else {
　　　　　/*
　　　　　非IE用の処理
　　　　　*/
　}
</script>

というように、
var isMSIE = /*@cc_on!@*/false;
だけで実装出来ます。

もちろん、クロスブラウザの観点からひとつの処理系でまとめることがベストですが、
JavaSriptの敵であるIE6に対応させるためには一筋縄では行かない場合もあるので、
思い切って、IE用の処理と非IE処理を書いた方が手っ取り早くベターなケースもあると思います。
]]> https://ameblo.jp/camesys/entry-10927039093.html Sat, 18 Jun 2011 14:09:17 +0900 auto_incrementでゼロ埋めしたい IDの利用等で、桁併せをしたい時等、０埋めをしたくなります。
こんな時は、テーブルのカラム属性に、「zerofill」を指定することで実現出来ます。

設定は、こんな感じ！
alter table animals change id id int(3) unsigned zerofill auto_increment;


]]> https://ameblo.jp/camesys/entry-10923988624.html Wed, 15 Jun 2011 11:50:44 +0900 MySQL小ネタ① 僕はなんと…外れてしまいました。

やっぱり世の中そんなに甘くないみたい…。
また一からコツコツと頑張っていきます。

一からコツコツと言えば（強引）、
MySQLでは整数のデータ型が定義されているカラムに対して、
auto_increment属性を指定することが出来ます。

こいつは（デフォルトでは）１からコツコツと勝手に採番してくれるので、
とても便利ですが、ID系カラムのような明らかにマイナス値を必要としない場合、
さらにunsigned属性を設定すると、正数値だけを取得するようになり、
実質、扱える数が２倍になります。

例えば、int型は通常、-2147483648から2147483647までの範囲を扱いますが、
unsigned属性を使用すると、0から4294967295までの範囲を扱うことになります。
超ざっくり言うと、扱えるIDが20億から40億に増える！


大規模なサイトのID系カラムには、
auto_incrementと共にunsigned属性も、
忘れずに設定しておきたいですね。

※１点、MySQL5.0以降の場合、unsigned属性を設定した状態で、
0から１を引くと、4294967295になるので注意が必要です。
]]> https://ameblo.jp/camesys/entry-10923783169.html Wed, 15 Jun 2011 03:14:45 +0900 簡単にネットワークキャプチャ！<ngrep> ※インストールが必要です。

コマンドのは、以下の通りです。
・TCPポート番号８０でフィルタリング
＞ngrep -d eth0 tcp port 80 -W byline

・送信元IPでフィルタリング
>ngrep -d eth0 src 192.168.1.1 -W byline

・送信先IPでフィルタリング
>ngrep -d eth0 dst 192.168.1.1 -W byline

・送信元IPとポート番号８０でフィルタリング
>ngrep -d eth0 src 192.168.1.1 and tcp port 80 -W byline


詳細は、参考URLを見て下さい。

]]> https://ameblo.jp/camesys/entry-10920150589.html Sat, 11 Jun 2011 17:10:40 +0900 月末の日付を取得する
date("Y-m-t")と書くと、今月の月末の日付が取得出来ます。
]]> https://ameblo.jp/camesys/entry-10919293228.html Fri, 10 Jun 2011 20:25:34 +0900 MySQLでプロセスのENDステータスが滞留する ※SQLのENDステータスは、ドキュメントに記載されいませんが、SQL自体の処理は終了して、後処理（キャッシュのクリア等）を実行している際に表示される様です。

おそらくキャッシュ領域の更新処理が排他される為と思われ、大きなクエリーキャッシュを設定した際に、更新SQL毎に実行されるデータクリア処理に時間が掛かり全ての処理を止めてしまう様です。

今回、私が設定したクエリーキャッシュは３Gで設定したのですが、あっと言う間にサーバをダウンさせてしまいました。現在では、512Mbyte（デフォルト）に設定し快適に動作しています。

サーバプログラムにPHPを利用し、さらにPHPにてDBセッションを利用している為、PHPプログラムが終了する度にSESSIONデータの更新が常に発生している事も負荷を上げる要因の一つの様です。

しかし、クエリーキャッシュサイズを上げる方法が無いものですかね。。。

]]> https://ameblo.jp/camesys/entry-10919112544.html Fri, 10 Jun 2011 16:38:21 +0900