自分用メモです。
毎回あれどっから取ってくるんだっけな…とか思ってるので。
思いついたら随時更新します。自分のために。

一応説明する体で記事公開します。誰かのために。

PHP

都道府県を配列にしたもの

$pref = array("北海道","青森県","岩手県","宮城県","秋田県","山形県","福島県","茨城県","栃木県","群馬県","埼玉県","千葉県","東京都","神奈川県","山梨県","新潟県","富山県","石川県","福井県","長野県","岐阜県","静岡県","愛知県","三重県","滋賀県","京都府","大阪府","兵庫県","奈良県","和歌山県","鳥取県","島根県","岡山県","広島県","山口県","徳島県","香川県","愛媛県","高知県","福岡県","佐賀県","長崎県","熊本県","大分県","宮崎県","鹿児島県","沖縄県");

地方別版

$pref = array(
"北海道"=>array("北海道"),
"東北"=>array("青森県","岩手県","宮城県","秋田県","山形県","福島県"),
"関東"=>array("茨城県","栃木県","群馬県","埼玉県","千葉県","東京都","神奈川県"),
"中部"=>array("山梨県","新潟県","富山県","石川県","福井県","長野県","岐阜県","静岡県","愛知県"),
"近畿"=>array("三重県","滋賀県","京都府","大阪府","兵庫県","奈良県","和歌山県"),
"中国"=>array("鳥取県","島根県","岡山県","広島県","山口県"),
"四国"=>array("徳島県","香川県","愛媛県","高知県"),
"九州"=>array("福岡県","佐賀県","長崎県","熊本県","大分県","宮崎県","鹿児島県","沖縄県")
);

※これはスニペットとは言わないのか？ｗ

PC / スマートフォン / ガラケー切り分け処理

if(preg_match("/(Android|iPhone)/",$_SERVER['HTTP_USER_AGENT'])){
	$type="smartphone";
}elseif(preg_match("/(DoCoMo|KDDI|UP\.Browser|J\-PHONE|Vodafone|SoftBank)/",$_SERVER['HTTP_USER_AGENT'])){
	$type="mobile";
}else{
	$type="pc";
}

※BlackBerry、Windows Phone、Windows CE、emobile、WILLCOMは上に入ってない。
※↑の文字列はユーザエージェントに含まれてるので、どこかに足せばいい。ビーモバイルはよくわかんない。

パスワード生成プログラム

下記のブログで完成してる。

PHP: パスワード生成関数を1行で書いてみた | Suinasia

基本的にこれで事足りる。
なのだけど、僕は一見して読みづらい文字を外してるので、下記のコードになる。

function make_password($chars = 8){
  return substr(str_shuffle('23456789abcdefgjmpqrstuvwxyzABCDEFGJMPQRSTUVWXYZ'), 0, $chars);
}

このへんはお好みだね。。

ハッシュ生成

$token = md5(uniqid(rand(), true));

僕はだいたいこれで生成してる。
↓参考

より高速に、推測困難な一意なIDを生成する方法 – [サンプルコード/PHP] ぺんたん info

画像サイズ変更

# サイズ取得
$fileinfo = getimagesize($old_img_path);
# 長辺を取得
$rate = $fileinfo[0]/$fileinfo[1];
if (@($max_width/$max_height) > $rate) {
  $max_width = $max_height*$rate;
} else {
  $max_height = $max_width/$rate;
}
@shell_exec("convert {$old_img_path} -resize {$max_width}x{$max_height} {$new_img_path}");

max_heightとmax_widthを決めておけば長い辺が調整されるように、計算を入れてある。
ImageMagick必須なので、サーバ環境に注意。
↓参考

ImageMagick vs GD – PHPでサムネイルを作る – INOLOG Ver.2

データ

郵便番号一覧データ
　→ZIPで置いてある。
　→いくつかAPIもあるけど、僕は毎回ここから取ってきてる。

市外局番一覧データ
　→なんでWordで作ったのが謎。
　→なので、エクセルにしといた。（2012/04/03時点のデータ）内容に責任は取れませんが、ご自由にどうぞ。
　→エクセルダウンロード

最近「制作者が客をバカにする」という状況を目にする。
そして、それを疑問にも思わず、「あのクソみてーな客が」云々と話し、それに対して「そうだよね、わかるわかる」と反応する。

そうだよね、わかるわかる。

バカにしたい気持ちも、よくわかる。
口調は違えど、場合によっては私自身も、そういう話しをすることがある。

でも、ちょっと待って欲しい。
ほんとにそれは、正しい感覚なのか？

自分はナニモノか？

まずこの話をする前に、自分の立場を確認しておく必要がある。
それによっては、これからの話は全然関係ないものになってしまうかもしれない。

前提として、私自身が身を置く、いわゆる「Web業界」 …私はこの言葉が嫌いなのだが… で起こっていることを話そう。
Webデザイナー、マークアップ、プログラマ、ディレクタ、その他諸々の立場があるが、近しい感覚を持って読むことが出来そうな人に向ける。
注意して欲しいのは、自分自身の体験だし、実際に聞いた話でもあるし、TwitterやFacebookなどで見かけたことがある程度の、ただほんの一部の話だってことだ。

「分からないから、デザイン／動くものを先に見せてよ。見た後でどうするか決めるから」

よくあるジョークの一種だ。
だが、全くの作り話じゃない。

こう言われた経験のある制作者はほぼ間違いなく「ふざけんなカスが」と思ってしまうだろう。
何故だろうか？

理由は簡単だ。

「無駄になると分かっているものを制作したくない」から。

そうだよね、わかるわかる。

せっかくデザインを作ったって、「気に入らないから」とか「イメージと違うから」なんて理由で作り直すことは、火を見るより明らかだ。
それならば作らないほうがいい。
じゃあ何故クライアントはそんなことを言うのだろうか？

その理由も至極簡単だ。

「作り方を知らない」から。

当然のことだ。
クライアントは、普段Webに触れる機会すら多くない人かもしれない。
ましてや、Webサイトの制作に関して一家言あるというクライアントなんて、いるだろうか？

答えはもちろん「No」だ。

制作者だって、当然そのことを知っている。

それなのに、「ふざけんなカスが」って言ってしまう。
端から見ると、これはひどい話に見える。
何も知らない人に向かって理解しろって言ったって、それが無理な話なのは誰もが知っているはずだ。
一体、どういう心境なんだろうか？

「素人が口を出すな」

制作者の「ふざけんな」という心情に一番近い感覚がこれだろう。
自分がホコリを持ってやっていることをバカにされてしまったような感覚。
何も知らない人が自分の領域に土足で入り込んできて、勝手なことを言っているような感覚。

そうだよね、わかるわかる。

プロとしての意識を持って仕事をしている人ならなおさらなんじゃないだろうか？
そこにホコリを持っているからこそ、出来る仕事もあるし、信頼さえも生むことがあるだろう。

だから、もう一度問おう。
あなたはナニモノか？

山奥に引きこもって、コツコツ木仏を彫る芸術家なのか？

匠と称されるような技術力を誇って、仕事の依頼が絶えないような職人なのか？

はたまた、仕事をもらってお金を得る経済活動の一環を担っているビジネスマンなのか？

自己顕示欲について

さて、ここから少し入り組んだ内容について触れたい。
非常に概念的な話だし、この考え方を全ての人に共有してもらいたいとも思わないけど、ちょうど「芸術」というキーワードを出したので、自分用のメモに書いておく。

仕事であろうと、趣味であろうと、日常生活における全ての行動は自己顕示欲と密接に交わりあっている。
他人が介在しなければ、全ての行動は究極的には意味を為さないものになる。

芸術活動において、自己顕示欲は大いなる敵だ。
表現が他人の目線を気にするようになった時点で、既にそれは芸術たり得る資格を失う。
芸術表現とは、自己と向き合うことだ。
突き詰めれば、誰にも知られる必要など無い。

これは非常に難しい問題だ。
芸術活動をしている人の中には反論も多くあるだろうし、あくまで私個人の考え方であると前置きしておく。

私はそう考えているので、能が無い芸能人とやらが自らの作品と称するものを世に出したときに「出来るだけ多くの人に見てもらいたい」などとほざく行動には反吐が出る。
それは商業活動の一環であって、芸術の要素のカケラも無い上に、当人がそれを理解していない。
御輿に乗るのは勝手だが、御輿に乗せた人間が悪意をもっていることは知っておいたほうがいい。

話が逸れた。

芸術における自己顕示欲は敵だが、日常生活において自己顕示欲は害悪では無い。
他人に認めてもらいたい、という欲求は誰しもが持つものだ。
最近で言えば、Twitterが最たる例だろう。
自らが発信者になることで自己顕示欲が満たされる構図は「居心地」とでも表現すべき感覚の高揚を生む。

しかし、自己顕示欲は日常生活でも害悪とされることが多い。
日本特有なのかどうか分からないが、他人に認められることは「下心」の一つであると認識されることが多いのではないだろうか。
さもしい、卑しい根性が生む、忌み嫌うべき感情。

だが、本当にそうなのだろうか？

認められる先に、金銭的な利害関係が見え隠れする可能性はあるにせよ、だからと言って自己顕示欲そのものを悪だとするのは違う。
多くの人はそのことを感覚的に理解しているが、自己顕示欲というものとうまく付き合うことを深く考える機会が少ないように思う。
自己顕示欲が間違った方向に向かった結果、犯罪を自慢するというような、よく分からない行動に発展してしまう。
Twitterがバカ発見器などと揶揄されるのは、多くの人が自己顕示欲との付き合い方を間違うからだ。

本来、他人に認められたいという欲求は、向上心にも繋がる。
「そのために頑張る」という目的の一つになり得るということだ。
その心を悪用する企業もあるが、今回の記事では触れないでおこう。

仕事へのプライド

自分の仕事に誇りを持つことは、素晴らしいことです。
…と、誰が言ったかは知らないが、どこかで聞いたことがあるセンテンスだ。

しかし何故、自分の仕事に誇りを持つことが素晴らしいのだろうか？
短絡的な答えを出すなら、期待に対して責任を負ってくれるからだ。
依頼した仕事に対して、一定以上のクオリティを担保してくれる。
言葉で表すのは簡単だが、そのクオリティを担保する責任の重圧は生やさしいものでは無いだろう。

プライドとは、自己顕示欲の派生形と考えることが出来る。
その期待に責任をもって応えましょう、という誇り。
それに対する代償は、金銭的なやり取りだけでは解決にならない。
他人から認められる存在であり続けることで、代償とする。

だから、そのプライドは尊重されなければならない。
仕事に対して誇りを持つとはそういうことなのではないだろうか。

参考までに言っておくと、芸術家はプライドなど持たない。

お客様は神様じゃないけどお客様

さて。
今現在、私自身は会社に勤めており、経済活動の一環を担うビジネスマンであると理解している。
金銭を得て家族を養うために働いている。

私がやるべきことは、仕事だ。
仕事に対するプライドは、まだ無い。

正確に言えば、醸成中だ。
私は期待に応えられます、という誇りを持つには至らない。
まだまだ勉強と経験が必要だ。

クライアントが無理を言ってくるシーンはあるが、どうにかそれを実現したいと考えている。
もちろん、ふざけるな！という気持ちになることもある。
だが、自分を振り返って、そんなことを言えた身分で無いことを思い出す。

私は充分に期待に応えられていたか？
それは、私が充分だと思い込んでいただけで、クライアントの期待と合致していなかったのではないか？
クライアントの期待と要望をまず洗い出し、正確に把握する努力を怠っていなかったか？

まずやるべきことは状況を思い返すことであって、クライアントの悪口を言うことじゃない。

一歩間違えば、それは方向を見失った自己顕示欲へと発展する。
クライアントの悪口を言うことは、犯罪自慢とそう変わらないのだ。

さらに言えば、プライドを持って仕事をする人間は、クライアントの悪口を言う必要などない。
責任を転嫁し、負うことが出来ないなら、その人はプライドを持つ資格すら無いからだ。

お客様は神様だと言うつもりなど毛頭無い。
しかし、お客様はお客様だ。
お客様に仕事を依頼され、それの対価を頂戴する。
あなたが向き合っているのは、自分ではなくお客様だ。

その上で、それに対する自分はナニモノか、よく考えてみるまでもあるまい。

まとめ

長々と書き記してみたが、こんな文章は私の独り言でしかない。
これも私の自己顕示欲の一つの形に過ぎないのだ。

認められるかどうかというところにあまり興味は向かなくなってきたが、
ブログに書くということは、誰かに見せることだ。

これを読んだあなたがどう考えるかは自由だし、どうして欲しいとも思わない。

ただもう少し、自己顕示欲と付き合う方法を考えてみてもらえれば、誰かが幸せになるかもしれない。

空前絶後のブームと言っても過言では無い、ステルスマーケティング。
いやー流行ってますねー。
なんかもう、やってないほうが恥ずかしいのかな？って思っちゃうくらい流行ってますねー。
やったらやったで、ものすごい叩かれちゃうんですが、法律的にはグレーというか、明確に裁く手段は無いみたいなんですよね。

しかし、なーんか釈然としない思いがあったので、少し素人なりに調べてみました。
Wikipediaべんり。

さて、まずはそのものの意味から。

ステルスマーケティング – Wikipedia

「消費者に宣伝と気づかれないように宣伝行為をすること」
ふむ。

じゃあ何がダメとされてるのか。

ステルスマーケティングは、自身の身元や宣伝が目的であることを隠して行われるため、消費者をだます側面を持ち、また『サクラ』や『やらせ』との線引きが困難であるため、一部諸外国では法により規制されている。

つまり、「人を騙す」からいけません、と。
そういうわけですね。

ちなみに「サクラ」や「やらせ」はどうなんだろうか。

まずは「サクラ」から。

サクラを使い、顧客に価値判断を誤らせて商品を販売すると、詐欺罪が成立するというのが確立した判例である。
サクラ (おとり) – Wikipedia

やったら捕まります。
詐欺になるんですね。へー。

じゃあ次。「やらせ」。

やらせには倫理的な問題のみならず犯罪行為にまでエスカレートすることが多いため、やらせを行うことで社会的な評価は著しく下がる傾向にある。
やらせ – Wikipedia

…なぜか現状では、法律に触れないらしい…？
マスゴミが広く大衆を騙すという行為は、素人の僕が考える限り、サクラより質が悪いと思うんですけど、法律上はそうでもないみたいです。
これは今回の話から脱線するので、まぁいいや。

じゃあ、ステルスマーケティングってどうなのさ、と。

「顧客に価値判断を誤らせて商品を販売」という点においては、サクラと同じで詐欺罪が成立しちゃうんじゃないかと思うんですが、まだはっきりした判例は無いみたいですね。

そういう意味で言えば、○○円で食べログ某口コミグルメサイトの評価を上げます！みたいな商売って完全にアウトですよねえ。
それに乗っかる店主もアウトですよねえ。
うーん…

こうやって考えると、ステルスマーケティングってそのもの自体グレーっていうかもう真っ黒。
弁解の余地が無いくらい法的にアウト。
って気がするのですが。

しかし、なんかまだ違和感があるんだよなぁ…

「顧客に価値判断を誤らせて商品を販売」って一文を、ハイパープラス思考で置き換えてみると、「顧客に与える商品価値の印象を上げて商品を販売」って無理やり言えちゃうんじゃないかなと。

つまりね、それって広告ってものの本質なんじゃないの？ってこと。

ヨーゼフ・ゲッベルスの手法を思い出すまでもなく、広告なんて捉え方によっては「人を騙す」ことに他ならないわけで。

たぶんなんとなく釈然としないのはその「捉え方」の基準が曖昧だってこと。

一つの基準になるのは、商品価値の印象を上げるために説明する文言（＝コピー）の「根拠」。

これがしっかりしてりゃ、顧客だって文句は言わない。
うん、そっかーそれなら買うわーってなる。たぶん。

でもそれってサクラとしてやったらアウトなんですよ。

なんでかって、立場を偽っているから。
僕は売るほうの人間じゃなくて、あなたたちと同じ、買うほうの人間なんですよーって。

それ以外、サクラがダメな理由が見当たらない。
だって、納得出来る根拠があって、買って下さいよーって言うだけなら、普通の広告だもん。

じゃあステルスマーケティングはどうよ、と。

これもやっぱりサクラと同じで、立場を偽ってるよね。
お金もらって記事書きました、食べログの評価上げました、って、それは立派に広報活動という名目のお仕事ですよね。

…やっぱこれ、アウトだろ(；´Д｀)

あとで、「いやいや、僕は最初から宣伝目的でブログ記事を書いていたんですよ」って言っても、「いやいや、僕は最初から購入する客であって、サクラじゃないんですよ」って言ってるのと同じで、ちょちょいと事実確認されて、あっさりお縄になっちゃうんじゃないかしら。

なんでモノゴトの本質が同じなのに、片方がグレーなのか理解に苦しむ今日この頃。

だらだら長い文章になっちゃいましたけども、まだ釈然としない。
何となくひっかかりがあって、うまく言葉に出来ないなぁ。

もう少し考えてみます。
広告って難しいね。

このブログもWordPressを利用して作られています。
最近ではブログエンジンのみならず、CMSとして利用される例も多くなってきました。
私自身、案件でもよく利用しているわけですが、近頃ではその限界点を感じるようになり、案件では採用しないことが多くなってきました。
企業のWeb担当者や、システムを知らないがWordPressなら構築が出来ると謳う方には、是非一度考えてもらいたいと思い、ここに記します。

※この文章は私自身の個人的な意見であり、WordPressで構築されたサイトを批判、中傷するものではありません。

WordPressに問題を感じる理由はいくつかあります。
もちろんその問題をある程度解消する方法も存在することは承知の上で、挙げてみます。

１．DBの問題

WordPressを案件で採用しない一番の理由がDBの問題です。
CMSエンジンとしても使われるようになったためか、汎用性を意識した作りをしており、DB構造が非常にややこしいです。

その上、HTML吐き出し型では無く、アクセスの度にDBにクエリを投げる形を取っています。
これによりサーバへの負荷が増え、多量のアクセスを捌くことが困難になります。

ApacheやMysqlのチューニングである程度は負荷を下げることが出来ますが、根本的な解決にはなりません。

２．プラグインの問題

ここまでWordPressが広く普及した理由は、プラグインの存在無しには語れないでしょう。
「手軽に導入出来るプラグインによるカスタマイズ」こそがWordPressの魅力と言っても過言では無いと思います。

しかし、それこそが致命的な欠点を作り出しているとも言えます。

まず、その手軽さ。
ほとんどのプラグインがボタン一つで簡単に導入できるわけですが、あなたはその中身の動作を知っていますか？
中でどういう処理が行われていて、どのような脆弱性を持っているのか。

先日、導入したが有効化していないプラグインの脆弱性を突かれて、サイトの中身を改ざんされたという記事を目にしました。
何故こんな事件が発生してしまったのか。

ここからは推測の域を出ませんが、可能性のお話です。
WordPressの管理画面やプラグインのURLは設定を変更しない限り、デフォルトのものが使用されます。
つまり、そのサイトがWordPressを使っていて、かつ、そのプラグインをインストールしていれば、有効化しているかどうかに関わらず、そのプラグインの脆弱性を突くことが可能になってくるわけです。

こうした被害も、個人のブログであれば、たいして問題無いかもしれませんが、企業のホームページに導入していた場合、どうなるでしょうか？
誰が責任をとってくれますか？

WordPressはオープンソースのプログラムですから、作った人が何かを担保してくれるわけではありません。
導入を決定した人が、あくまで責任を負う必要が出てくるわけです。

そのリスクを理解した上で導入を決定しているかどうか。

WordPressの導入を決定した担当者は、そこまでの判断をした上で利用を決定しているのでしょうか。

３．直接のカスタマイズの問題

WordPressはPHPで作られており、PHPの読み書きが出来ればある程度のカスタマイズが可能になっています。
テンプレートを作りたければ、最小限のPHPの知識と、WordPress独自関数の知識があれば良いのです。

しかし、中途半端な知識は脆弱性の温床です。
言うまでもありませんが、「知らなかった」なんて言い訳には出来ません。

また、WordPress本体の問題も多くあります。
歴史的な理由もあり、WordPress独自関数は整備状況が甘く、命名ルールや挙動すらも統一されていないという惨状です。
当然そこで出来上がるコードは、非常に可読性が低く、今後の再利用に適さないものになります。
あとから機能を追加したくとも、まずは解読から、という状況も珍しくありません。
しっかりしたドキュメントを作れば解決…たしかにそうですが、それってスクラッチ開発とどう違うんでしょうね？

WordPress自体は、オープンソースそのものの発展に大きく寄与した面もあり、高く評価しています。
しかし、だからといって盲目的にそれを信頼し、下駄を預けられるか、というとそれは別の問題です。

考えなくなることは楽ですが、そこに潜む危険について知らないことは、思わぬときに悲劇を生む地雷のような存在だと思います。

よく、「プログラミング出来るなんてすごいねー！」と言われますが、言われるたびに「全然すごくないですよ」と言ってしまい、「すごいって言ってるんだから余計な謙遜しなきゃいいのに…」みたいな微妙な空気になることがあります。

まぁそもそも僕がプログラマとしてそんなにすごくないというのはありますが、気にしない方向で…

なんで「すごい」「すごくない」の感覚はこんなにも違うのか。

プログラミングは魔法ではない

これを言われるのって、勉強出来る人が「勉強出来てすごいねー！」と言われるのと同じ構造です。

勉強が出来る人は何故すごくないと思うか？　勉強したからです。

やったんだから出来るのは当たり前です。

それなのに「すごい」と言われるのは、マニュアルに書いてある通りに刺身にタンポポを乗せてたら「君はタンポポ乗せの才能があるね！どう？うちにこない？」って突然言われるくらいの違和感があるわけです。

嘘です。言い過ぎました。

しかし、ここで強く言っておきますがプログラミングのコードは呪文ではありません。

あるルールに従って書かれた文字の羅列です。

分かってる人にはそりゃそうだろ、っていうことですが…

ではなぜ、「プログラミングはすごい」という感覚が生まれるのか。

辞書があれば英語を読める？

僕は、英語の勉強が好きでした。

そこまで成績が良いわけではなかったですが、長文を読むことにも抵抗はあまりありませんでした。

長文と言っても、和英辞書があれば、正確じゃなくても何とか読めます。

もしかしたら、大事なのはこの感覚なのかもしれないと思います。

英語もPHPも、ルールに従って書かれた文章です。

基本的ないくつかのルールを覚えてしまえば、あとは単語を調べるだけで済みます。

英語なら辞書があればいいですし、PHPならほとんどの場合関数リファレンスを見れば良いだけです。

スラスラ読めたらカッコイイかもしれませんが、どんくさくても辞書を片手に読み解くことは、忍耐力があれば出来ることだと思います。

それなのに、挫折する人が多いのは何故でしょうか？

覚えることが多い…ように見える

感覚値ですが、「基本的ないくつかのルール」を覚えるのに挫折する人は意外と少ないです。

ただ、「基本的ないくつかのルールを覚えること」と「単語を覚えること」を混同して挫折する人は多いです。

「こんなに覚えることがあるのか…」と思った瞬間に、やる気が失われてしまうのです。

英語もプログラミングも、同じ傾向にあると思います。

こういう理由ですから、プログラミングを覚えるのは大変なことじゃないですよ

…っていうまとめになるわけですが、何故今回、この文章を書くに至ったかを書いておきます。

端的に言えば、WebデザイナはjQueryを学んだほうが良いと感じているからです。

jQueryと一口に言っても様々なことが可能です。

学ぶなら、主に表示系のインターフェースに関わる部分を学ぶのが良いと思います。

要素の表示／非表示、アニメーションの操作、レイヤーの考え方。

インターフェースの設計については場合によってはSEの範疇かもしれませんが、Webデザイナとしてもインターフェースへの考慮は必須になっていくでしょう。
（僕はデザインと設計は同義語だと考えています）

英語は話せますか？

英語を話せますか？と誰かに聞かれたとき、基本的に僕は「話せます」と答えています。

話せる英語は中学校で習うような基本的なものばかりですが、生活に困ることは無い程度には話せます。

ほとんどの場合、「相手に何を伝えれば良いか」だけ考れば、実際伝えるべき部分は簡単な英語で済むものです。

それはプログラミングの場合、設計に当たります。

jQueryで自分が意図する動作を作り出すには、どのように書いたら良いか、少し考えてみてください。

場合によっては（というよりはほとんどの場合）、インターネット上にヒント（または答え）が転がっていますが、あえて見ないで考えてみてください。

それが実現出来たら、プログラミングの設計から構築まで一人の力で出来る、と言って良いと思いますし、Webデザイナとしてのスキルに一つのエッセンスを加えることが出来るのではないでしょうか。

T/O…というわけにもいかないので思ったことをつらつら書いてみる。

というか、オワコンって言ってみたかっただけだ。すまない。

そもそもSEOってなんだ

検索エンジン最適化 – Wikipedia

ある特定の検索エンジンを対象として検索結果でより上位に現れるようにウェブページを書き換えること。または、その技術のこと。

それ以上でもそれ以下でも無い。

所有するサイトが検索エンジンの上位結果に表示されれば、アクセス数が増えてハッピーというわけだ。

どんなハッピーなのかは人による。

何故オワコンか

Google自身が検索結果を最適化しているからに他ならない。

猪口才な技術を使って検索結果の上位に表示させるだって？

ふざけるのも大概にしたほうがいい。

本来の基準となる「良質な」コンテンツを作れ。話はそれからだ。

どんな基準を持って良質かって？

そんな質問が出る時点で、君は良質なコンテンツの制作者たり得ない。

何か別の職を探したほうがいい。

気付かないんじゃなくて、気付かないフリしてる？

SEOを商売として始めたから後に引けないのかもしれない。

もしくは、本気でSEOには未来があると信じているのかもしれない。

後に引けない人は、気付かないフリを決め込んで、無知な非IT企業に高値で売りつけるくらいしか出来ないだろう。

それだって、あと何年持つか怪しいものだ。

また、もしまだSEOという単語に希望を感じているのなら、はっきり認識しておいたほうがいい。

それは蜃気楼だ。

SEOという技術そのものに未来は無い。

今後想定されるのは「ソーシャルな」繋がりの中から導き出された基準による良質コンテンツの選別だ。

Google+を見るまでもなく、こんなことは誰でも分かることだろうけどね。

この文章の意味が分からない人へ

高円寺に来ることがあったら桃太郎寿司がうまいから、行くと良いよ。

自分用のメモです。

＜追記あり：2011/08/02＞

[sqlfairy-developers] Questions on MySQL -> SQLite translation

このページにTriggerを使った解決方法が書いてあったんだけど、このTriggerの文章だとテーブルのデータ全てに対してUPDATEがかかっちゃう。

ので、書き換えたのがこちら。
ちなみに、IDは一意であるとする前提。

CREATE TRIGGER hoge_modified AFTER UPDATE on hoge FOR EACH ROW
BEGIN
 UPDATE hoge SET modified = current_timestamp WHERE ID = old.ID;
END;

まぁ、WHERE句を足しただけなんですけどね。

＜追記：2011/08/02＞
SQLiteではデフォルトでcurrent_timestampがUTCになってしまい、ローカルの時間になってくれません。
それを解決したのが下記。
ついでに不必要なFOR EACH ROWを取り除いてます。

CREATE TRIGGER hoge_modified AFTER UPDATE on hoge
BEGIN
 UPDATE hoge SET modified = DATETIME("now","localtime") WHERE ID = old.ID;
END;

Webサイトを閲覧していると、一体どこがクリック出来るエリアなのか分からないことがあります。
このプラグインは、画面をスクロールしていって、該当の要素が画面内に登場するとハイライトしてくれるというプラグインです。

デモ
ダウンロード

仕組みとしては、指定した要素の上にdivの透明レイヤーを配置して、ハイライト時に一瞬だけ表示という方法で実現しています。
もともとはaタグにバインドして利用することを想定していましたが、他の任意の要素にもバインドできます。

基本的な使い方

html

オプションを指定した例

オプション

hlColor
ハイライトされる色を#ffffffなどで指定します。色名では指定できません。

cnt
連続してハイライトする回数を指定します。

指定された要素は、ページに登場すると一度だけハイライトされます。

今後のアップデート予定

登場回数指定オプション
その他要望があれば。
不具合、ご要望はこちらからどうぞ。

ライセンス

MITライセンスで公開します。ご自由に。

蛇足

このプラグインは、一般的なWebサイトに対しての提案だと思ってます。
一般的に、クリッカブルな領域であるかどうかを表現するには、デザインでの見せ方が必要と言われますが、そもそも平面でクリッカブルか否かを判断させるのは無理があります。
ならば、動作で見せてもいいんじゃないの？と思って作ったのがこちらのプラグイン。
UIに対する提案はいろいろ考えたいところですね。

Google＋、もうやってますか？

まだ正式版では無いようですが、早くもFacebookに負けず劣らずの胡散臭い動きがあった模様ですよ。

この記事を読んで知りました。

Googleプロフィールを「限定公開」していると、7月31日に削除されることが判明 – ロケットニュース24（β）

こちらの文中、

Google＋を本名で使用することを推進ために、講じた策と思われる。

これが非常にひっかかりました。

極端な発想ですが、今後本名での登録をGoogleが義務付けた場合、どうなるのか、という疑問が浮かびました。

これって、恐ろしいことですよね。

ある意味、行政機関よりも個人に詳しい情報を持った組織が出来てしまう可能性があるってことです。

Facebookは使わなければいいじゃん、で済ませることが出来ましたが、そうもいきません。

本名の登録が無いとGoogleの検索が使えません、と言われたら・・・

どうします？

＜追記：2011/0714 09:27＞
やはり怪しい動きになってきたようですね。

実名でなければGoogle+アカウント停止に【湯川】 : TechWave

今後のインターネットのあり方が大きく変容するかもしれません。

説明は適度に、駆け足でお届けします。
言っておきますが、これを覚えたからと言って「PHP出来ます！（ｷﾘｯ」とか言ったら鼻で笑われるレベルだということは認識しておいてくださいね。

＜追記あり：2012/02/16＞

大前提

HTML/CSSの基本的なところはわかってるものとします。FTPでアップロードするって意味さえわからない人はこのへんで勉強してください。つまり、出直してください。
あと、もっとちゃんと勉強したい人はこんな駄文を読まないほうがいいです。アシアルさんのコンテンツを読んでください。この文章の100倍素晴らしいコンテンツが満載です。

エディタ

Windowsユーザなら、標準で付いてるメモ帳を使うのはやめましょう。
PHPに限らず、プログラムを触るなら、あんなもん使わないでください。文字コードも変更できない、あんな見づらいエディタを使う意味など皆無です。
最低限、PHPのコードが色付けされる、文字コードが変更できるエディタがあったほうがいいです。
Windowsで無料なら例えば、

notepad++　←僕はこれ使ってます。
ＰＨＰエディタ
サクラエディタ
TeraPad

あたりでしょうか。Macは使ってないのでよく知りません。
今回、基本的に文字コードは全て「UTF-8N」（ボム無しUTF-8）という前提で進めます。

環境を確認

エディタで、下記のコードを「info.php」とか適当な名前で保存します。

<?php
 phpinfo();
?>

作ったファイルをアップロードして、ブラウザでアクセスすると、ずらずらと情報が表示されます。
もしこれが表示されない場合は、そもそもそのサーバではPHPが使えません。別のサーバを使ってください。
[2011/03/30 11:00追記]→コメントにてご指摘頂きました。サーバによってはこの関数を使えない場合があります。PHPが使えるかどうかは、利用しているレンタルサーバにお問い合わせください。

細かいことは置いといて、このページを名前をつけてローカルに保存してください。保存したら、サーバから「info.php」は必ず削除してください。

さて、ローカルに保存した「info.php」をブラウザで開いてみましょう。これにはサーバのいろんな情報が書かれています。

とりあえず「DOCUMENT_ROOT」だけ確認すればいいです。絶対パスと呼ばれるものです。
（「DOCUMENT_ROOT」で検索するといくつか引っかかりますが、同じ値だと思います。）

「え？絶対パスって知ってるのと違うよ？」と思った人はHTMLでの絶対パスを思い浮かべた人でしょう。
ここでの絶対パスとは、サーバのシステムルートからの絶対パスであり、Webサーバのルートからの絶対パスではありません。

FTPで見るより、もっと深い階層があるんだと思っておけばいいです。

準備はここまで。

基本的なこと

普通のチュートリアルだとここから丁寧に変数の説明とかするんですが、超ダッシュで一息にまとめます。
コーラでも一気飲みして勢いをつけたら、下記のコードを見てください。

<?php // ←phpを書くための約束。<html>と同じようなもの
# シャープがついたら、それより後ろはコメント。コメントは全部で3種類ある。
// スラッシュ2回。これもそれより後ろがコメント。
/* これもコメント。
これは囲まなきゃいけないけど、複数行コメントに出来る。 */

$hoge="test";
// ドルマークがついたら、「変数」。数値とか文字列とかを入れることが出来る。
// 変数は英数字とアンダーバーのみで、先頭は数字じゃだめよ。
// 値を入れるときには「=」を使う。
// 文字列は「""」（ダブルクオーテーション）か「''」（シングルクオーテーション）で囲まないとエラーになる。

echo $hoge; // ←脆弱なので、通常はこのようには書かない。
// 「echo」は出力して！って命令。
// HTMLみたいに、書けば表示されるもんじゃないので、表示してほしいものは命令しないといけない。
// ちなみに、$hogeには上で"test"って文字列を入れたのでブラウザでは「test」って表示されるはず

$arr=array();
$arr[0]=100;
$arr[1]=500;
$arr[2]=999;
// これは「配列」。変数のすごい版（嘘）で、値を複数入れることができる。
// array()っていうのが「これは配列だよ！」って宣言。
// [0]とか[1]とかが「キー」。中身が対応してる。

echo $arr[1];
// こうすると「500」が表示される。

// ちなみにこのように書くことも出来る。やってることは上と同じ。
$arr=array(100,500,999);

echo $arr[2];
// 何も書かないとキーは 0 から始まる。
// だから、上の中身は[0]=>100, [1]=>500, [2]=>999 ってなってる。
// これは999が表示される。

echo $arr[0]+$arr[1];
// これは100+500で600が表示される。計算できるんだね。だいたい察して。

$arr["aaa"] = "boke";
$arr["bbb"] = "aho";
// こんな感じで文字をキーにすることも出来る。

echo $arr["aaa"].$arr["bbb"];
// これは「bokeaho」と表示される。
// 2つ以上の文字列を連結するには「.」（ドット）を使う。ドットがないとエラーになる。

// 配列の中身を表示するのには、foreachが便利。
foreach($arr as $k=>$v){
  echo 'キー：'.$k.'　中身：'.$v;
}
// 中身とキーを表示する。

// 最初から決まってる特別な変数もある。
// とりあえず使うのは以下の２つ。
$_POST;
$_GET;
// ちなみにこんなふうにコードの中に変数が書いてあるだけだと何も起こらない。何も命令してないから当たり前だね。
// HTMLの<form>タグに<form method="post">って書いてあったら$_POST
// 何も書いてないか、<form method="get">って書いてあったら$_GET
// そこに、それぞれinputタグとかselectタグの中身が入ってくる。
// <input type="text" name="onamae" />ってタグの中身は
// $_POST['onamae']として入ってくる。
// $_GETはURLにくっついてくるので、直接アドレスバーに書いて、値を決めることも出来る。
// http://quoit.jp/hoge.php?aaa=99
// これは$_GET["aaa"]=99; として中身が入ってることになる。

if($hoge=="test"){
  echo $hoge;
}elseif($hoge=="piyo"){
  echo "(´ω`)";
}elseif($hoge!="ika"){
  echo "(　ﾟдﾟ)";
}else{
  echo "(´・ω・`)";
}
// if・・・は「もし・・・だったら」ってそのまんま。
// 「=」一個だけだと「値を入れる」って意味なので、「等しい」を表すには「==」って二個にする。
// だから、$hogeが「test」だったら、中身を表示。
// elseif・・・は「そうじゃなくてもし・・・だったら」なので、「test」じゃなくて「piyo」だったら「(´ω`)」を表示
// $hogeが「ika」以外だったら「(　ﾟдﾟ)」を表示。「!」は否定を表す。
// else「そうじゃなかったら」なので、上のどれにも当てはまらなかったら「(´・ω・`)」を表示

function foo($val){
  $ret=$val."オラオラオラオラ";
  return $ret;
}
// これは「関数」。
// 「機能をまとめておけるもの」かな。
// カッコ（）の中が「引数（ひきすう）」と呼ばれるもので、関数に渡される値。
// 今回は関数の中で引数の中身に文字列をくっつけて、値を返してるので、次のようになる。

$hoge="WRYYYY!";
$hoge2=foo($hoge);
echo $hoge2;

// 表示されるのは「WRYYYY!オラオラオラオラ」。
// 最初に入ってる値が、関数で処理されることで内容が変わるんだよ、ってことですね。

// phpを書くための約束。</html>と同じようなもの↓
?>

ちょっとがっつりだけど、これ読んでなんとなく分かればいいです。
分からない方はコメントくださいな。

メールフォームを作る

使えるものを作りましょう。プログラムを作る時は、まず最初に処理の流れを考えます。
まぁ今回はシンプルに。

1) データを入力する
　　　　↓
2) 送信する

というだけにしましょう。
確認画面は入れない。面倒だから。

言い忘れてたけど、PHPはHTMLと同居出来る。
つまり、こういう書き方が出来る。

<html>
<head><title>テスト</title></head>
<body>
<?php
echo "hoge";
?>
</body>
</html>

ただこれだと見づらくなるから、PHPでHTMLをテンプレートとして読み込んだりすることもあります。（例：Smarty）

今回は上のように同居させます。

さて、画面としては２つ必要です。

１）内容入力画面
２）送信完了画面

送信完了画面を表示する前に、送信処理をしなきゃいけない。
ただ、送信完了画面＝送信処理とすると、完了画面を更新（F5）したときに二重送信になってしまう。
それを避ける方法はいくつかあるのですが、今回は送信後に完了画面にリダイレクトさせる、という方法を使います。

ということで、処理の流れは、

1) データを入力する
　　　　↓
2) 入力内容を確認　→エラーがあったら入力画面に戻る
　　　　↓
3) エラーがなければ送信する
　　　　↓
4) 送信完了画面を表示する

という流れになります。

さて、いよいよ実際のコーディングへ。
まずは１）の内容入力画面。
入力できる項目は「お問い合わせ内容」だけにします。

<?php
// 先にHTMLを書いちゃうと、処理をする前に内容が表示されちゃうので、処理内容を先に書く。
// まずは何か変更があったら書き換えやすいように、設定を書きましょう。

// 宛先
$to="info@quoit.jp";
// From欄の中身
$from="info@quoit.jp";
// メールのタイトル
$title="【お問い合わせがありました】";
// [2011/03/30 11:00追記]完了画面のURL
$url="http://quoit.jp/finish.html";

// 次にデータが送られてきた場合の処理を書く。

if(isset($_POST["send"])){// データが送信されていた場合
  if(!isset($_POST["contact"])){// 本文が空だった場合はエラー文を設定 [2011/03/30 11:00修正]empty関数→isset関数に変更
    $error="本文を入力してください。";
  }else{
    // 本文の入力内容を変数に入れる
    $contact=$_POST["contact"];
    // メール送信時の日本語設定。UTF8にします。
    mb_language("japanese");
    mb_internal_encoding("utf-8");
    // ここからメール送信処理
    // PHPに初めから用意されている関数を使う。（mb_send_mail関数について詳しくはググってください）
    // この関数は、「エラーだとFALSE（否定）を返す」。
    // こういう場合、if(!mb_send_mail()){ ??; } と書くと、「??;」はエラーだった場合に実行される。
    if(!mb_send_mail(
      $to,// 宛先。
      $title,// タイトル
      $contact,// 本文（受け取った値）
      'From: '.$from."\r\n".
      'Reply-To: '.$from."\r\n".
      'X-Mailer: PHP/' . phpversion(),
      "-f ".$from
    )){
      // エラーだった場合にエラー文を設定
      $error="メールを送信できませんでした。";
    }else{
      // 問題なければ、送信完了画面（finish.html）に飛ばす
      header("Location: ".$url);
    }
  }
}

?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>メールフォームの入力画面</title>
</head>
<body>
メールフォーム

<form method="post">

お問い合わせ内容


<p style="color:red;">
<?php echo $error; ?>
</p>
<?php echo htmlspecialchars($contact, ENT_QUOTES, 'UTF-8'); ?>



<input type="submit" name="send" value="送信する" />
</form>

</body>
</html>

このファイル以外に、「送信ありがとうございました」的な内容を書いたfinish.htmlを用意しておけば完了。

どうでしょうか？簡単でしたか？

これを読んで、何となく分かった気になったら、ちなみにそれは勘違いです！

ご質問、ツッコミなどはコメントやTwitterでください。

どうぞ素敵なプログラミングライフを。

2011/03/30 11:00追記

コメントで頂いたご指摘と、はてなブックマークでご指摘頂いた部分を追記／修正しました。

2011/03/30 12:20追記

はてなブックマークでご指摘頂いた部分をちょこっと修正。

2011/03/30 15:00修正

「メール本文に対してhtmlspecialcharsをかけるべきではない」の意味がよく分かってなかったのですが、ご指摘頂いてようやく分かりました…ご指摘頂いた皆様ありがとうございます。一部修正しました。

2011/03/30 19:00修正

はてなブックマークでご指摘頂いた部分をちょこっと修正。コメントを追加。

2011/03/31 19:30修正

コメントで頂いたご指摘を元に、一部文言を修正。

2012/02/16 15:00追記

以前、セキュリティについてツッコミ頂いてたのですが、はまちちゃんがためになるエントリーを公開されてたので、追記としておきます。これは一度読んでおくべき。

5分でできるPHPセキュリティ対策 – ぼくはまちちゃん！(Hatena)