現在、ウェブマイスター系列のサイトを別サーバーに移転中です。
サブドメインで分けていてよかったなと思う。
もし、サブドメインでわけていなかったら、移転作業が大変な事になっていた。
コレを気に、またちょこちょこ更新していこうかなと。
しかし、かなり古いサーバーから、比較的新しいサーバーへの引越しで、ＰＨＰのバージョンやらなにやらが違います。
でも大した修正もなしにスムーズに引越しが進んで安心かな。
このブログも引越し中です。トップページとエントリーページは正常ですが、その他で表示が崩れています。
テンプレートを移すのを忘れていた・・・・どうでもいいページですけどね。
移転が終ってるのは、ウェブマイスタートップ、本館、ＣＳＳ、ブログ、ウェブツールです。
あと少し、のんびりがんばろっと。
最近は、様々なウェブツールが登場し、手軽に利用できるようになった。
ウインドウズ用など、ＯＳ専用のプログラムを組む必要性が一気に減った時代にも見える。
高いプラグラミング環境を買う必要も無く、高いソフトを買う必要も無く、ソフトをインストールする必要も無く。
こんな時代が見え隠れしている。
ここで問題になってきたのが、ウェブツールはオンラインでなくては機能しないこと。
常時接続があたりまえの国はそんな多くは無い。そのため、オフラインで使えるようにして欲しいという要望が高まった。
そこで登場したのは、Adobleの『Apollo』や、Googleの『Gears』。
Google Gearsは、ウェブブラウザの拡張機能として、ウェブアプリをオフラインで使えるようにするもの。
ただし、Gearsに対応したウェブアプリに限る。
現時点では、Google Readerにのみ対応のようだ。
必要なデータをクライアントに保存して、オフラインでも使えるようになる。
問題は、ＩＥとFirFoxにしか対応していないということかな。
Adoble Apolloは、Gearsと違い、ウェブブラウザの限界を超えたウェブアプリを作れるように、専用の実行環境を開発した。
早い話、ウェブアプリに特化したまったく新しいコンプセントのブラウザと思えば良い。
これにより、ウェブアプリがよりディスクトップアプリに近い物となる。
もちろんオフラインでも動く設計だ。
オフラインでもウェブアプリを使えるようにするという技術。
日本では流行らないだろうな。
各家庭ブロードバンド常時接続があたりまえだからね。
そうでない家庭では、そもそもウェブアプリ自体が不要だろう。パソコンを使わないのだから。
そして、オフラインで扱えるアプリにも限度はある。
オンラインだからこそ可能な物もある。
セキュリティ、データ量、著作権、その他もろもろの問題で制限される場合もある。
プログラミングをしていて、おのずと学んでいく事になるコーディング方法。
綺麗で見やすく分かりやすいコーディング方法ね。
知らなくても、長くやってれば自然と分かってきて、身についてきます。
でも初心者は思うでしょう。
なぜ、綺麗に分かりやすく書かなきゃいけないのか。
動けばいいじゃん。一人でやってるんだから、自分がわかればいいじゃん。
初心者は必ずそう思います。
でも、初めての方はまず動かしてプログラミングになれることも必要なわけで、
めちゃくちゃでも、始めの頃は動けば良いとも思います。
挫折するよりはね。
プログラミングにある程度慣れてきたら、わかるはずです。
自分が書いたプログラムが汚くて自分でもわかりにくい。
時間がたつほど、自分が書いたルーチンなのに、何しているのかわからなくなる。
汚いから、ミスが多くてバグフィックスばっかしている。
機能を増やそうとしたら、１からやりなおしたほうが早い。綺麗に書いておけば・・・。
そう、たとえ他人が見なくても、綺麗に書くことは大切だとわかってきます。
短いプログラムなら『どうにでもなる』、という初心者の頃とは違ってきますからね。
これに気が付いたら、一歩前進してみると、プログラミングがぐっと楽になると思います。
綺麗になるヒントは、php コーディング規約 で検索するとわかります。
phpを書いて長いですが、実は初めて見直してみました。
これら規約の内容は、あくまで基本です。
実際のプログラミングは、もっと様々なことに注意をはらわなければ、大きなソフトは作れないでしょう。
複数の規約を見ると、どれもほとんど内容は同じです。
行き着く先は、同じということです。それぞれが真似してるわけではないのです。
全てを真似る必要性はまったくありません。
異なったルールでやっているグループもあります。
一番大切なのは統一性です。
最も変化があるのは、名称ルールでしょう。
現在一般的なのは、『getBlogData』というような書き方です。
小文字から初めて、次の単語からは大文字で始めます。
昔の標準的な書き方は、『GetBlogData』でした。
自分で定義したものは大文字からはじめ、外部ライブラリは小文字というルールです。
ライブラリにある関数なのか、自作関数なのかを明確にするためです。
そうすれば、ライブラリの関数を全て覚えていなくても、他の人のソースをスムーズに読めます。
また、あるコーディングルールには、変数の型を変数名に含めるという方法もあります。
キャラクタ型なら c_abc、数値型なら i_abc という感じです。 c はchar型で、i は int型です。
でもphpには型の定義が無く、自動で変換されるのでこういった定義方法は使う事は無いでしょう。
私がよく使う関数名のルールにはこんなのもあります。
関数の置かれているソースのファイル名を頭につけて、関数の重複回避や、ソースを追うのに役に立っています。
『filename_functionName』 です。
html内に無造作に複数の独立したphpをインクルードする場合に都合が良いです。
この関数はどこのライブラリだっけ？という疑問も、関数名でわかり便利です。
全ての関数をクラス分けでもいいですが、長くなって面倒ですからね。ケースバイケースです。
ずっと疑問に思っていたことも、これら規約を見て解決したのもある。
文字列を囲むとき、『 ' 』にするか『 " 』にするか。
なんとなく『 ' 』にしていたけど、やっぱこの方が変数が無いか調べない分サーバーの負担も減るのでしょうね。
そこまでは書いてないけどね・・・・。
ただどの規約にも書いてないのは、『 " 』で変数を混ぜるのと、『' ' . $abc . ' '』のように外にだすのとで、どっちが良いのか。
文字の連結には『.』を使うようにって書いていながら、『""』で一緒に書くルールも書いてある。
おそらく文字列変数同士を連結させる場合は『.』という意味なのだろうけど。
混ぜる場合は、『" {$abc} "』 のように通常は『 {} 』でくくるよう配慮したほうが良いと思う。
どっかの規約の例では『 "あいうえ$abcおかき"』のようになっていたが、やってはいけない方法だ。
たぶん、日本語訳を書いた人のうっかりミスだろう。
これはエラーの原因になる。実行する機械から見ると、どこまでが変数名か判断しにくいからだ。
後ろに続く文字によっては、変数名と認識されてエラーになる。
たとえば、『$abcおかき』という変数名と認識されるかもしれない。（この文字では試していない）
自動認識を当てにしてはいけない。
コーディング規約を見ていて一番びっくりしたのは、 『 { } 』の扱い方です。
昔調べたときは、様々な方法が書いてあって、どれが良いのか答えがわかりませんでした。
そこで色々試した結果、行き着いた最善の書き方。
それがどのコーディング規約にも書かれていた。
関数は、『 { 』を関数の頭にそろえて書き、ifなどのルーチンでは その行の最後に書く。
昔調べたときは、どっちかに統一する書き方ばかりでした。
それで色々試した結果、別々の書き方が見やすいと結論したわけです。
と、色々試行錯誤した内容は、私がこっそり？配布しているスクリプトに現れています。
すなわち、統一性がちょっと低いという、素人じみたソースです。
その日によって、ルールを変えてやりやすさを調べていました。
理論より実践です。
さて、書き方のルールがわかったら、次はルーチンを組み方に慣れる必要があります。
だらだらと書くのではなく、関数等にわけてスマートに書くのが楽です。
これも初心者は疑問に思うでしょう。
何故、関数に分ける必要があるのか。一気に書いちゃった方が楽じゃないの。
昔から多くの人にこういった質問を受けていました。
確かに、一回しか使わないルーチンなら関数にまとめる必要は無いかもしれない。
しかし、同じ処理をする一連のルーチンを何度も書く場合はどうか。
初心者は思う。 「コピペすればいいだけじゃん。」
それでできたのが、同じ処理が数箇所に記述される長いソース。
もし、その処理にバグがあったら？
もし処理内容を改善したくなったら？
もしかしたら、その修正過程で、あるルーチンだけ記入ミスするかもしれない。
たいだい、同じ処理をしている箇所を全部探すのが大変、書き直すのが大変、長くてみにくい。
長くてみにくいと、そこにバグが生まれる。
だから一箇所にまとめて共通で使ったほうが便利。修正もその一箇所ですむ。
実際にそうすると、もっと様々な利益（効率）があることに気が付くでしょう。
オブジェクト指向はこうやって始まりまりました。
たとえその時は一回しか使わない処理内容でも、区切りのいい場所でわけて関数等にすると良い。
そうすれば、ソースが見やすくなり、どういった処理をしているのか一目でわかり、バグが発生しにくくなる。
これが、オブジェクト指向と呼ばれる考えの原点です。
各処理をオブジェクト（関数等の部品）としてつくり、それらオブジェクトを組み合わせて一連の処理を行う方法です。
これをやりやすくするために、クラスと呼ばれる物が生まれました。
長くなってきて、初心者向きでなくなってきたのでここまでにしておきましょうか。
こんな記事がある。
もしも・・・ネット世界に検索エンジンがなかったら
昔はＢｏｔ型の検索エンジンは無かった。登場してもしばらくはマイナーだった。
初期の頃からインターネットをしている私が、当時の状況を解説してみる。
Ｂｏｔ型の検索エンジンが無かった昔は、リンク集が全てだった。
Ｙａｈｏｏ！がここまで発展したのも、Ｂｏｔ型検索エンジンが無かったからだ。
インターネットのホームページはYahoo!という時代でもあった。
そして、個人サイトに設置してあるリンク集も需要が高かった。
さらに情報を探すのに欠かせないのが、各サイトのリンク集でもあったからだ。
また、ウェブリングというのも流行っていた。
もう一つ、インターネット関連雑誌に掲載されるサイト情報も非常に需要があった。
毎回様々な個人サイトが紹介されている。
今でもあるが、検索できない時代は重要な情報源であった。
本屋で立ち読みしてＵＲＬを目盛る事もよくあったっけ・・・。
友人にＵＲＬを教えるのは、別に言葉で言う必要はない。
メールを送れば済む事だ。
あともう一つ、最近まで携帯がどうだったかを見れば少しわかるかもしれない。
検索エンジンは最近できたような物だ。
しかし、ブームはもっと前から来ている。
そして重要なのは、やはりディレクトリ型のリンク集だった。
私はあまり携帯はつかわないので、詳しい事情はわかりませんが。
しかし、携帯とＰＣでは時間が違うのだから状況も違う。
後発の携帯は様々なウェブサービス（コミュニティー）があり、Ｂｏｔ型検索エンジンが無くてもヒットする土台がすぐに出来た。
そしてＰＣサイトに戻ってみよう。
確かにGoogle等検索エンジンはウェブ業界に革命を起こしたかもしれない。
でも、ウェブがヒットした原因の一つにすぎない。
ヒットする原因の様々なサービスが生まれ、Ｂｏｔ型検索エンジンもその一つだった。
それぞれの相乗効果というのが、私の結論である。
そもそも、Googleのような検索エンジンが一般に広く認知されたのは最近のことだ。
そのため、Yahoo!でも最近になってやっとＢｏｔ型検索のほうをメインにもってきている。
使わなきゃ、無いのと同じだからね。その無い時代にどんどんサイトは増えていった。
今ほどに増えた一番の原因は、ブログが一番の理由であり、ブログやウェブスペースレンタルサービスを提供しているコミュニティーの存在が大きい。
検索エンジンからブログに訪れるのではなく、コミュニティー内のブロガー同士が繋がるというものだ。
ブログが無かった時代の従来のウェブサイトも、同様にして広がっていっていた。
ソーシャル系サービスが成功してるのも、そういった理由からだ。
検索は無くても成功した、しかしあったから今でも勢いが止まらないといった感じだ。
ということで、Ｂｏｔ型の検索エンジンは原因の一つにすぎないというお話でした。
裏を見ると、Ｂｏｔ型検索エンジンのおかげでアフェリエイトサイトが大量発生して・・・いう話なら、大きな原因となる。
争いが好きな人は多い。
人気サイトではよく討論が行われる。
昔から、掲示板は多少荒れた方が活気があって良いとも言われていた。
すなち、討論する場を与えれば、人があつまりやすい。
討論がされれば、立派な情報となる。
そしてそれはコンテンツにもなりうる。
そしてさらに人が増える。
こういった手法には、かっこいい英語名があったのだが・・・・・・忘れた。
ブログで言うと、記事の内容をちょっと攻撃的にするというもの。
たとえば、ある情報の反対意見を書くなど。
すると、それについての討論がコメントにずらずらという仕組みだ。
言うなれば、ブログの掲示板化だ。
記事をスレッドとして、討論しやすい内容でアップすれば良い。
とまぁ、書くのは簡単だが、肝心の人がある程度通ってくれないと意味は無いだろう。
あとはいかにして、多くの人に読ませるか。これが一番難しい気もする。
今もなおβテストで公開されているサービス AboutUs。
これは、世界中のサイトの情報を集めたWikiサイトだ。
基本情報はサイトやWhoIs情報によって掲載される。
その他情報は、誰でも編集できるという、ちょっと怖くて楽しそうなアイディアだ。
自分のサイトの宣伝に使ってもらうのがメインなのだろうけど、他人が荒らす事もありえる。
使い方は、上の検索ボックスに自分のサイトのドメインを入れてみよう。
たとえばウェブマイスターならwebmeister-jp.comだ。
残念なことに、トップドメイン単位でしか対応していない。
すなわち、サブドメインのサイトはダメだ。
そう・・・・ちょっと微妙。
共有サーバーで無料ドメインを利用している人は、無理ということだ。
もう一つ特徴的なサービスがある。
サーバーの細かな情報が見れるだけではなく、ＳＥＯの視点から見た評価も見れる。
サイト情報の右にある 「DomainTools.com」だ。
ページ内容を分析して、クリーンなＨＴＭＬであるかを判定してくれる。
クリーンなＨＴＭＬは結果的にＳＥＯに繋がるという考えなのだろう。
しかし、実際の判定方法には少し疑問も残るが。
何を直したらよいのかは、英語で表示される。
右のSEO Text Browserをクリックし、出てきたやつの左上隅にある「！」をクリックで解析内容表示となる。
そこに、何が悪いかが英語で表示される。
しかし、判定材料の種類も少ないので、まだまだこれからといったところだ。
imgタグに画像の大きさを指定しろなど、ＳＥＯと関係あるのか不明なものまで含まれている。
まぁ、指定するべきなのは確かだが。
ちなみに、ＵＴＦ８以外のページは一部機能が使えない場合がある。文字ばけが発生する。
どうもマルチバイトの変換が不安定のようだ。meta情報は日本語が通ってるのに、title情報は文字化けとか。
この機能の使い方は、指示にしたがってページを修正し、ツールのリロードボタンを押して再確認。
１００％を目指して修正していくというものだ。
機能が充実すれば、ＳＥＯとは関係無しにサイト作成の補助ツールとして便利かもしれない。
こんな記事をみつけた。
PHPを今まさに使っている（学んでいる）人へ
非難されやすい言語というのは初耳だった。
まぁ、どんなジャンルでも人気が出ると、それを受け入れてない人からは攻撃されるもだ。
phpが最も優れている徹底的証拠はこれだ。
>PHPを使ってる有名サイト：Yahoo!, GREE, digg, facebook, CNET, Wikipedia, goo, wordpress, 楽天
他にも、はてなや、その他思い浮かぶほとんどの有名サイトはphpを使っている。
今あるメジャーは言語はというと（phpびいきな説明。あくまでwebアプリ開発が前提）
・perl(CGI) （昔使っていた）
Web用ではなく、汎用的な言語。
それだけに細かいところを操作しやすい。
逆に言えば、細かいところを操作しないといけない。
Ｗｅｂに特化していないため、余計な処理が多く開発に手間がかかりやすい。
また、短くもできるが、難解なコードとなりやすい。
そうなるともう、ソースの可読性を保つのが大変。
何でも取り込み肥大化し、枯渇した言語とも言われている。
伝統的に今も使われているだけにすぎない、マイナー化しつつある言語なのが現状。
perlといえばCGIなので、CGIについて書くと。
CGIは、呼び出されるたびにインタプリタが実行され、その上でperlが動く。
結果、大量のメモリ、大量のＣＰＵ処理が必要となる。
だいたい、php(mod_php)の１００倍遅いと思って良い。
たとえば、同時に１００人きたら、１００個のインタプリタが起動するわけだ。
・mod_perl （使った事が無い）
採用しているレンタルサーバーは無いに等しい。
したがって、perlといったら普通はCGIのことを指す。逆もまたしかり。(他言語のＣＧＩもマイナーすぎるため)
もしmod_perlが使えれば、今主流のphpと同等の実行速度となる。
どっちが早いかは、処理内容でわずかに違う程度。
でもやっぱ、webに特化した大きなソフトは、仕組み上phpのが速いと思うが。
mod_** とは、サーバーにあらかじめインタプリタを組み込んだ形式と思えば良い。
なので、呼び出すたびに起動する必要もなく、１つですむ。
結果、最低限のメモリとＣＰＵ処理で実行し、高速になる。
・php(mod_php) （今使っている）
Webに特化した言語。perlが使いにくいために登場した。
最小限の手間で最大限の効率を得る今もっとも効率的な言語だ。
Webに特化しているため、とてもスマートに記述でき、htmlに記述を埋め込めるため、とても柔軟となっている。
perlに比べて、初心者から上級者まで楽に扱える言語である。
なんせ主流なので情報に困る事も無い。
欠点は、楽に組み込める代償として、セキュリティー上の問題に注意しなくてはならないというのがある。
ちなみにPHP5.2以上を強く推奨。様々な強化がされ、よりいっそう使いやすくなっている。
大幅な高速化、強力なライブラリ、クラスの強化などがある。
ただでさえ強力なPHPがさらに強力になっていっている。
・ruby （使った事が無い）
国産のインタプリタ言語。
これもまた、phpと同じくperlが使いにくいために誕生した言語である。
オブジェクトパスカル（Delphi）に近い書式を採用のように見える。
オブジェクト指向に特化させて、開発の保守性を向上させている。
ただし、実行速度はperlよりもかなり低速となる。数倍の時間が掛かると思って良い。
これは、コンパイル無しで実行するインタプリタ形式によるためだ。
他言語は、実行する直前にコンパイル/最適化するため速い。
（しかしrubyでも同様の処理をするためのテスト中。これでperlと同じ速度にまでいくかもしれない）
rubyはさらに、ドキュメントも少なく、ライブラリも少なく、敷居は高くなっている。
ただし、言語の仕組みで海外からも高い評価を受けており、これからの発展で変貌するかもしれない。
他に、たまに登場するマイナー言語には
・Python （ほとんど知らない）
可読性に特化した言語なのだろうか。とにかく見やすいソースになりやすい。
スタイリッシュな言語と言えるだろうか。
ほとんど見ないので、よく知らないが。
ということで、今から始めるなら、PHP以外に選択脇は無いと思ったほうが良い。
わざわざ多言語から開始する理由は、ほとんどの人には無い。
perlを使っている人は、昔から使っているからであり、rubyを使っている人は、元々プログラミングに精通している人である。
長い間パソコンを使っているとやがて訪れるのが、データ消滅。
ＨＤＤの破損や、故障はいつ起きるかわからないもの。
私の場合は・・・・・
ＨＤＤが爆発。（電源入れたらものすごい音が出て逝ってしまわれた）
リカバリ失敗。（Win2kで大容量使うときは注意。一見認識して正常に使えていてもね）
ＯＳ入れ替えＨＤＤフォーマットでバックアップ忘れ。
などなど、何が起きるかわからない。
バックアップに使うメディア候補としては。
・ＨＤＤをもう一台使って、バックアップツールで自動バックアップ。これが一番安全。
今はＨＤＤも安いからね。
＊ＲＡＩＤを使ったバックアップもあるが、これはあくまでバックアップを補助するだけにすぎないので注意。
もしデータを削除してしまったら、バックアップも削除される。
もしデータを上書きしてしまったら、バックアップも上書きされる。
もしＲＡＩＤシステムに障害がでたら、これもまたバックアップが削除されることもある。
こういった事があるし、一世代しか作れない。なので別途複数の世代のバックアップをとる必要がある。
複数の世代が必要なわけは、破損したデータのバックアップを取る可能性、間違ったデータのバックアップを取る可能性があり、正常な頃のバックアップが欲しいという状況もあるからだ。
ということで、mySQLのデータベースのバックをちゃんと行うシステムを構築しなくては。
今はただたんにwebminで定期バックアップを指定しているだけなので、ほとんど意味が無い。
このバックアップファイルをメールで送信すれば非常に便利なので作ろうと思っていたが、ちょうどいいスクリプトを見つけたので、これを使う事にした。
MySQLを自動バックアップする
コメント＆トラックバック対策をしてから長らく”放置”した結果、かなり有効と判断。９割以上はカットできている模様。これだけカットできれば、残るたまに来るスパムはたまに消せば良いだけかな。
こういったスパム対策が広まると、今度はスパム対策の対策をしたスパムが来るようになる。ちょっとややこしいかな。そのために、やり方は公言しないようにと言われてきている。スパムの９９％以上は海外からと思えば、おのずとやり方は見えてくるだろう。そして今ではMovableTypeの公式サイトからプラグインをダウンロードできるようになっている。
このプラグインは使った事無いが、おそらく私が導入しているのとほぼ同じだろうから、海外からのスパムに困っている人は導入すると良い。
しかしやはり、対策が広まってきたためか、気が付く外人も増えてきている。久しぶりにコメント一覧を見たら、そこそこスパムがきていた。でも対策前に比べれば遥かに少ない量だ。たとえイタチゴッコであっても、目に見えて効果があれば良しだろう。
増えてきたらさらに制限を厳しくしなくてはと思ったが、その前にアーカイブのテンプレートを直さなくては。表示がすざましく壊れている。
ＰＨＰ４とＰＨＰ５では仕様が色々と違う。
と言っても、高度？なプログラミングをしていなければ、問題になることは無い。
ＰＨＰ４用のスクリプトの多くはＰＨＰ５でも動くだろう。あくまで多くの。
ＰＨＰ５のサーバーを使っていて、欲しいスクリプトがＰＨＰ４用に作られたものとする。
そして、運が悪くＰＨＰ５の仕様だと動かないとする。
しかし諦めるのはまだ早い。ＰＨＰ５にはＰＨＰ４互換モードが存在していて、ＰＨＰ４のみ動くスクリプトを動かせる可能性がある。
やりかたは、php.iniか、.htaccessに記述となるが、通常は.htaccessに記述となるだろう。
php.iniに記述したらサーバー全体に適用されてしまい、php5の機能が制限されてしまう。
php_flag zend.ze1_compatibility_mode On
もしＰＨＰ５のサーバーに引っ越して動かなくなったら、試してみると良いだろう。
地域によって物の考えはある偏りが現れる。それはオンラインゲームでも例外ではなく、同じゲームでも国によってユーザーの要望は異なり、その結果、実装する内容も国によって異なってくる。
それがよくわかる記事を見つけたのでまとめてみることにした。
http://www.4gamer.net/news.php?url=/news/history/2007.06/20070604231337detail.html
日本、韓国、中国、台湾での違いがいろいろと書かれている。
もちろん個人差があり、全体的に見た傾向である。
簡単に（良い意味で）まとめてみると。
日本：平和好きで、内向的。趣を大切にする。（戦闘以外も楽しむ）
韓国：細かい事は気にしない。ゲーム自体を楽しむ。（ゲームをする）
中国：ヒーロー志向。戦い好きで、人より優れた見た目と能力を求める。（ＰｖＰを楽しむ）
台湾：柔軟に何でも好む。（何でも楽しむ）
他のゲームからヨーロッパ・アメリカとアジアと比べると。
・アメリカなどは、かっこいい大人が好き。
・アジアは、かわいい子供（童顔）が好き。
ゲームのキャラクタを見ればわかる。アメリカ産のゲームのキャラは、昔から日本人には受け入れがたい物だった。可愛くない、リアル、エグイといった理由からだ。
アメリカ人から言わせれば、アジアのゲームはロリコン、変体となる。
着せ替え人形でも、日本向けは可愛く、アメリカ向けは大人っぽくなっているのは有名な話だ。
しかし最近のMMORPGは、どれも似たり寄ったりの量産型ばかりになってしまったね。
やはり、金儲け優先だと難しいのかな。
個人的な趣味としては、初期のＵＯ＋セカンドライフ＋Oblivionなゲームが欲しい。
一言で言えば、ＭＭＯワールドシミュレーションゲーム。
少しずつコンテンツを新しいサーバーに移転中で、まだ終っていません。
移転ついでに、不要と判断したコンテンツは削除しています。
徐々に最適化して、余分なのを削除し、必要なのを拡大します。
リンク集も、業者の登録しか無い今、登録は無期限停止にし、縮小します。
掲示板は、管理する暇が無いので既に削除済みです。
国内でウェブリングと言えば、かつての最大手『ウェブリングジャパン』だろう。
ついひと月ほど前に閉鎖となり、参加者は散り散りとなったが。
このウェブリングジャパンの閉鎖で、また一つ、インターネットも変わってきたなと実感した。
閉鎖理由はおそらくこうだ。需要の低下。
YahooやGoogleの検索が中心となった今、ウェブリングの必要性が急激になくなってきている。
今では、一部の女性向けジャンルの間で使われている程度である。
昔は私も活用していた。たとえば素材系サイトを探す場合、リンク集の一つとしてウェブリングも使っていた。（ウェブリングという形式の必要性は別として）
ウェブリングに参加すれば、沢山の人が自分のサイトにやってきた。そんな時代があった。
次に消えゆくサービスは何だろう。
ＰＣ用と携帯用の両方作りたい場合。 面倒だ。
この面倒をやってくれるのが、自動変換システム。
AUでGoogle検索をしている人は、自動で使われているシステムだ。
http://www.google.com/gwt/n
ここに、自分のサイトのＵＲＬを入れれば、携帯サイトのＵＲＬの出来上がりだ。
No Imagesは、画像を表示させるかどうかで、通常はチェックして非表示にしたほうが良いだろう。
どのように変換されるかを見て、変換後も綺麗になるようにページを構成すれば完璧だ。
ＰＨＰでページを構成している場合は、もっと最適化することもできる。
ユーザーエイジェントに『Google Wireless Transcoder』という文字がある場合、余分な情報をカットするようにすると良い。
実際に携帯からこのシステムでアクセスする人は多く、別途携帯用ページを作るよりも有効かもしれない。
携帯用ページ作ったのに、携帯からのアクセスはＰＣ用ページばかりという状況もありうる。
cronを使えるウェブサービスは少なく、国内で私が知っているのはバリュードメインのサービスぐらいだ。
cronを知らない人に簡単に説明すると、指定したスクリプトをスケジュール通りに自動実行してくれるシステムだ。
何に使うのかと言うと、定期的にログを削除したり、定期的にブログを投稿したり（ＭＴにある機能）、定期定期にキャッシュを作ったりと様々な事に利用できる。
cronが使えないレンタルサーバーを借りたとき、諦めるのはまだ早い。
WebCron という、定期的に指定したＵＲＬにアクセスするサービスが存在する。
左上メニューの『Register』でメンバー登録をすると無料で使えるようになる。
cronが使えないサーバーで定期的に実行させたい物がある時、使ってみてはどうだろうか。
ここで言う静的アドレスとは、cgi等のパラメーターが無い、静的ページのアドレスのこと。
たとえば、『 hoge.cgi?b=12 』といった、パラメーター付が動的アドレス。パラメーターの内容でページ内容が変わるのが一目瞭然だ。
『hoge/12/』といったアドレスは、一見CGIとはわからず、普通の静的ページのようだ。これを擬似静的アドレスと呼ぶことにする。現在ではこういったアドレスが多く、本当に静的ページか動的かは判別しにくくなっている。（しっかり作れば、完璧に判別不可能となる）
これのメリットは、かつてはＳＥＯ対策としてAmazonが真っ先に導入したのが有名だ。
動的アドレスだと、インデックスされにくかったからだ。特にパラメーターが多いと顕著となる。
もう一つ、もっと大切なメリットがある。パラメーターを勝手にいじる悪戯の抑止力となる。
他にも、アドレスを短くしたり、メールや掲示板にアドレスを書いた時の自動リンクを正しく行わせるメリットもある。
デメリットは何か。特に無い。
設定方法は慣れれば簡単で、既存のcgi等のスクリプトにも使える。
設定は、『.htaccess』に書くだけ。このファイルを扱えるサーバーでないとダメだが、バリュードメインやロリポップ！
といったメジャーなところでは使えるようになっている。
たとえばこのように記述する
RewriteEngine on
RewriteRule ^hoge/(.*)/(.*)/$ hoge.cgi?b=$1&t=$2 [L]
意味を説明すると、windowsのショートカット機能のようなもので、別のアドレスでアクセスできる機能である。
RewriteEngine on は、アドレス置換機能のＯＮ。
RewriteRule ルール記述開始
^hoge/(.*)/(.*)/$ このアドレスでアクセスされたら
hoge.cgi?b=$1&t=$2 このアドレスの内容を表示する。
[L] この行を処理したら、置換作業終了。
『^』は、ドメインの省略形と思って良い。『http://www.aaa.com/』の部分だ。
省略してもいいが、誤動作させないためにつけると良い。
『(,*)』（かっこ、どっと、あすたりすく、かっことじる）は、何か文字があったら、取り込むという意味と思えば良い。
その行の最後の$は、アドレスの終わりを意味する。省略できるが、誤動作に気をつけよう。省略すると、この部分にどんな文字列がきても反応してしまう。
$1や$2は、取り込んだ文字を挿入する命令だ。取り込んだ順番に$1、$2となる。
すなわち、 hoge/12/43/ でアクセスされたら、 hoge.cgi?b=12&t=43 の内容が表示されるようになる。
また、hoge/12/でアクセスされた場合は、条件にあわないので「404エラー存在しません」となる。
[L]は、以後に続く他の置換処理をさせないためである。
cgi側は、普通にパラメーターで受け取ることになるから、何の問題も無い。
ただ、cgiが生成するリンクアドレスは普通のパラメーター付きになるので、リンクアドレスをいじってやると完璧だろう。いじらなくても動作に支障は無いが、同じ内容のページが２つ存在することになる。（ＣＧＩが生成するリンクアドレスと、手動で作ったアドレス）
条件を増やせば、どんな複雑なアドレスにも対応できる。それには正規表現のお勉強も必要だが。
詳しく知りたい場合は、「RewriteRule」と「正規表現」で調べると良いでしょう。
少し前に書いた、『ブログに人を集める方法 』の続編。
ちょこっとためしに、ある記事を投下したりして様子をみてみたのだが、予想通りの展開を見せた。
コメントは静かだが、あるサイトで多少の話題を呼べたので成功としておこう。
その道の人から見れば、当然の反応だ。(他言語愛好家の反感)
しかし、そういった人（目的）を対象にした情報ではないため、問題は無い。適材適所というわけだ。
これは、マスコミなどでは手軽に人を呼べるとして、ごく当たり前に行われている古くからある手法である。
極端にすればするほど人があつまる。過激にすればするほど人があつまるというわけだ。
しかし、あまりやりすぎると『祭り（収拾不能）』状態となるので注意が必要である。
ＴＶや雑誌では、収拾不能となり謝罪している場面もよく見る。
私がよく読む情報系ブログにも、この手法がメインのところがある。
内容は適度に攻撃的で、知らない人が見れば鵜呑みしてしまうというものだ。
やはり、こういった攻撃的内容を読むと、再認識や考えさせられる場としての面白みがある。
ただ残念なのは、そのブログのコメントは同意意見のみということだ。
以上のことから、軽度のものでは、反対意見のコメントがつきにくく、他サイトで話題になるのみに留まる傾向にある。
これは理に適っており、他のもっと大勢がいるサイトで反論した方が、仲間が多いためだ。
また、同じような事をする仲間が多いため、行いやすい。結果、反論が目立つ事になる。
その場が、『2ch』や『はてな』といった巨大コミュニティーサイトであり、こういった行為を『晒し』と言う。
そして、読者が多ければ、コメントで討論or祭りとなる。
しかし、毎日のように記事を書いている人はすばらしい。
ネタが続かないよ・・・・。
今最もポピュラーなMySQLというデータベースシステムについて、基礎をまとめみてみる。
MySQLは、データベースを扱う言語の一つと思って良い。
すなわち、MySQLには、様々なデータベース形式(ストレージエンジン)が存在する。
中でも重要なのは、『MyISAM』と『InnoDB』の２種類だ。これ以外を使う事は無いに等しい。
■２種類を簡単に説明すると。
・『MyISAM』は、読み込みに特化した形式。大量の同時書き込みが苦手。
ある行を書き込み中は、他の行を書き込みできない。読み込み中も書き込みができない。
・『InnoDB』は、複数行の同時書き込みが可能。書き込みに特化した形式と思えば良い。
ただし、読み込みが遅く、メモリを大量に必要とする。
一般には、小さなサイトや、大量の同時書き込みが発生しないテーブルはMyISAMを使う。
個人サイトレベルはMyISAMと思っても良い。
逆に、大手サイトでは沢山のユーザーが同時に書き込みを行うから、同時書き込みができないMyISAMでは順番待ちでタイムアウトしてしまう。だからInnoDBを使うケースが多い。
■MyISAM
仕組みを分かりやすく説明すると
データベース ＝ ディレクトリ（フォルダ）
テーブル ＝ ファイル
となっている。
テーブル数の上限は、サーバーのシステムによって違う。
Windowsなどでファイルの多いフォルダを開く時、長く待たされることを経験した事は無いだろうか。
データベースでも同じである。テーブルが多ければ、接続時に時間がかかる。
■インデックス
インデックスとは、目次のこと。目的のデータに瞬時にアクセスするために必要なものだ。
ただし、初心者には少し難しいシステムでもある。
まず、インデックスが必要なのは、１万件以上に及ぶ大きなテーブルのみである。
千件程度の小さなテーブルでは、逆に遅くなる場合が多い。
また不必要にインデックスを増やせば、そのインデックスを作成するぶん遅くなる。
検索を行う時、最も適したインデックスが自動で選ばれて使用される。
ただし、使うインデックスはどれか一つのみである。
すなわち、複数のフィールドを検索（ソート）する場合、注意が必要である。
検索条件にあった複数対応のインデックスを用意しなければ意味が無い。
その他にも色々制約があるため、使いこなすにはマニュアルをよく読む必要がある。
■MySQL4.1以降
バージョン4.1から、文字コードの扱いが変更となった。
今までは、MySQLを呼び出すソフト側で文字コードを変換する必要があったが、4.1からはMySQL側が自動で行うようになった。
すなわち、自分で文字コードをいちいち変換させる命令を書く必要が無くなり、楽になったと言える。
これにより、実質、MySQL側の文字コードを気にする必要が無くなった。
MySQL上のデータがSJISだろうがEUCだろうが、関係なくなったわけだ。（ソース側の文字コードを気にする必要は今までどおりあるが）
ではデータベースの文字コードは何を意味するのだろうか。
それは、ソートである。どの文字コードでも意識しないで扱えるようになったが、ちゃんと指定しないとソートがうまくいかない。あたりまえである。
また、文字変換のタイムロスをなくすため、ウェブと同じ文字コードにすると良いだろう。
問題が無い限り、『ＵＴＦ８』をお薦めする。日本語特有の問題がなくなるからだ。
気をつけることは、ソース側の正しい文字コードをMySQLに知らせることだ。でなければ、コード変換が正しく行われない。あたりまえである。
iniファイルに記述する方法や、MySQL構文でそのつど指定する方法などがある。
正しく指定しなくても、読み書きは大抵正常に行われる。間違った変換で記録しても、読み込み時に元のコードに変換されるためだ。このため、ウェブ側では文字化けが起こりにくい。
ただし、ソートはめちゃくちゃとなる。
もちろん、他の違う文字コードで書いたソース（ページ）では、文字化けを起こす。
なので、きちんと文字コードを指定する必要がある。
一つのデータベースを使い、EUCで表示するページやUTF8で表示するページがある場合もあるだろう。
古いサイトはEUCで作られており、最近のサイトはUTF8で作っている人も多いはずだ。
この場合の文字コード指定方法の一つに
mysql_query("SET NAMES UTF8"); （PHPでの書式）
がある。
データベースに接続後、一度だけこれをやれば、接続を閉じるまで有効となる。
■MySQL4.1未満から、4.1以上へ移転する場合
上記の文字コードの扱いのみに注意するだけである。
デフォルトの文字コードは、おそらく『latin1』となっているだろう。
エクスポート＆インポートで移転する場合は、注意が必要である。
まず、エクスポートしたファイルはEUCかSJISとなるはずだ。
この文字コードは、そのままにし、UTF8に変換してはならない。
そして、『CREATE TABLE』文の最後に、テーブルの文字コードを書き足そう。
『) ENGINE=MyISAM DEFAULT CHARSET=utf8;』
などとすれば良い。
そしてインポートすれば、正しく文字コード変換がされるはずだ。
以上が、まず知っておきたい基礎事項である。