2009年3月アーカイブ

昔から参考書籍をザッピングするの好きです。
池袋のジュンク堂／新宿の紀伊国屋でよくやってます。基本的に書籍は高いので選ぶほうも慎重になります。基本的に一冊全部速読してから決めるので相当な時間本屋に居座る場合もあります。

ジュンク堂は座るスペースがいっぱいあり、ゆっくり立ち読みならぬ座り読みして書籍を決める事が出来ます。図書館ははっきり言って、書籍が古すぎるので使い物にならず、ジュンク堂が自分の図書館代わりになってます。気に入った書籍があったら全部買うので1万円を超える事がざらです。

本屋でのザッピング歴が長いので参考書を選ぶコツはかなり得ていると自負しています。そんな自分の参考書を選ぶ上でのポイントは！

０．事例で始まり事例で終わる。構文や関数名はネットで調べれば出てくるし、長年プログラミングしてれば直感でわかるので、できるだけ多くの事例を紹介してくれる方がいいです。
１．キャプチャ画面を多用しフルカラーである事。画像を用いない書籍であっても単色でなく3色刷りとか4色刷りだと見やすい。
２．オリジナリティのあるサンプル題材。同様のテーマの本をザッピングしていると大体似たり寄ったりのサンプルプログラムが出てくるので、出来るだけオリジナルのニッチな物を好むようにしてます。
３．日本語が長いものは×。あるテーマの説明だけで日本語文章1ページ以上にまたがるものは敬遠。
４．お気に入りの著者・シリーズ・出版社の同一物は大体気に入ります。
５．システム開発以外の、例えばマーケティングなどの参考図書はさらに、著者の主観がまったく入っていない、客観的な技術紹介内容ものだけを買うようにしています。

とまぁそんな感じです。

最初はそう、メールですよね。その後スケジュール管理とか、ブックマーク等をオンライン上で管理できるようになって、管理データが一元化する事ができました。

複数の環境下で、普段管理しているデータを場所問わず利用できる事がこんなに便利だとは。最近だとオンラインストレージサービスやアプリケーションなんかもオンラインで提供されてます。いわゆるSaaS／ASPとか言われるあれです。

いわゆる帳票出力や工数勤怠管理のERPから始まって、会計／財務／人事／給与システム。E-learning教育、営業支援、CRM／顧客管理、生産・仕入れ・物流。社内／グループウェア、WEBサイト構築（ブログなどのオンラインCMSも広義のSaaS/ASPでしょう）、あとは劇的に生活が便利になったと感じるE-コマース（電子商取引関連）ですね。
すでにワープロ／表計算／CAD他多数アプリケーションもネットワーク越し利用するスタイルが登場してますし。

ローカルアプリケーションのライセンス販売の方がビジネスモデル的には単純で儲けやすかったのではないでしょうか。だから業者は方向転換を迫られている訳です。

サービスを提供する側は大変だと思いますが、利用するユーザー側にとっては、便利この上ないですね。

最近では、レンタルサーバの業者も増えサービス／価格も多種多様。とても便利になりました。月額数百円で複数のサイトの管理も十分にまかなえるほどです。

ただ、最近MySQLDBを多用しているのですが、このDBのリソース制限について、レンサバ業者のQ&Aに小さく書いてあるのを発見。
この記述も非常に曖昧で、DBの使用容量に制限は設けていないが、なにぶん共有リソースの為、50MBを目安にお使いください。それ以上使うと制限を設けさせていただく可能性がございます・・・とか。

契約しているレンサバの容量がそもそも数十GBなのに、DBの容量が50MBて。まぁだから専用レンタルサーバサービスがある訳なのですが。

一応、複数の業者に同じ様な質問をしてますが、やはり共有レンサバの場合、DBには数十MB～数百MBくらいの使用にとどめてくださいとの回答が多いです。

数ある業者の中でサービスを選択するのも大変ですが、最近はさくらインターネットのレンタルサーバがいいなと思ってます。そういえば、さくらは大学の時使った事あるから、結構昔からやってる老舗ですね。。
要件を満たすサービス内容の業者の中では、格段に安いです。あっ回し者ではありません。

ちなみに専用サーバだったら断然メガファクトリーがおススメです。

現在のコーポレートサイトについて昔の会社員時代の先輩からアドバイスをいただいたので早速反映させたいと思う。

"経営理念"と"成功事例"。確かに新たに協業先を考える際にサービスと価格だけでは、甲乙つかない事が結構ある。
"経営理念"と"成功事例"はお客様の判断材料として不可欠という事だ。

言われてみれば、他の会社を評価する際、かなり気にしているところだ。
"成功事例"も脚色を加えず、お客様の声としてダイレクトに公開する事に意味がありそうだ。

経営理念というか活動指針というか、座右の銘というか、常に意識している事はある。ベタな事を書いてもつまらないので、天邪鬼な考えをさらに誇張して書く。

１．拡大志向よりも、幸福志向
売り上げ拡大が全ての社員の幸福に合致しないと意識する。

２．営業はしない
そもそも商材が良ければ営業しなくても売れるくらいのスタンスで営業するリソースを商材練磨に費やす。営業を否定している訳ではない。

３．努力を強制しない
成功は成功する術を行使できたものが成功するのであって、努力したものが成功するのではない。

・・・とまぁ、他にもいくつか。パッと見やる気なさそうに感じるかもｗ。やる気はあります。

2008年末にアメリカでスタートしたGoogleのGoogleSearchWikiは、表示された検索結果でユーザー側で"ふさわしくない"と判断したサイトを検索結果から削除できる機能を備えている。

簡単に言うならフィードバックを繰り返す事で、よりユーザーの好みに合った検索結果を返す様になっていく。
検索結果をパーソナライズする事が、検索エンジン（ここではGoogle）の指針（ユーザーが欲している情報をより上位に表示する）に最も合致する仕組みだと思う。

ただ全ての検索エンジン全てでこの仕組みが浸透するとは思えない。Yahooなどの検索エンジンは、Yahoo自身がより収益を上げる事ができる検索結果を作り出すアルゴリズムになっていると言える。例えばYahooビジネスエクスプレスなどでカテゴリ登録したサイトが現在でもかなり強力なSEO効果がある。（企業は収益を上げる為に存在しているので特に悪いと言っている訳ではない）

要は、完全にユーザー毎に検索順位を自在に変える事ができるとしたら、上記の収益を上げる仕組みは無くなると言えるので、また別のビジネスモデルを考えなければならないからだ。

ただ検索エンジンを利用する末端のユーザー視点で言えば、検索結果を全て同一のアルゴリズムに当てはめて出力してくれる（検索エンジンを運営する企業の有利不利で検索結果を操作しない）方がありがたいと思う。

GoogleSearchWikiの様なパーソナライズ検索が今後流行るかどうか。

WEBマーケティングツールとして現在開発中の「SEOBY」仮称。
複数のサイトに複数のキーワードを設定し、検索エンジン毎の日々のランキングをデータベースに蓄積する他。
外部要因（バックリンクやSBM）を把握したりする。
機能についてはおいおい、紹介する事にする。

基本的にマッシュアップにより構成されているが、取得されたデータを当方独自の計算式で算出する指標はWEBマーケティングの有力な参考材料となるはずである。

とはいえ、まだベータ版よりも前の段階かな・・。

ただのメールフォームを作成してFirefoxで動作検証問題なく、IEで検証したらエラー。

サーバサイドで処理するCGIなのになんでブラウザによって、結果が違うのかとまどっていたら、何の事は無い、IEのGETリクエスト時のクエリの長さの制限にひっかかっていただけの様でした。

いつのまにかメールフォームの入力項目が多くなって、クエリが長くなったんです。・・・ソースを追って損した。

URL に使用可能な文字数は最大 2,083 文字という事で、素直にPOSTで送信します。

業者選択チェックポイントをまとめてみる。

○制作技術
業者が抱える人材、または外注の技術レベル。制作実績やアイミツを取る際のコンペラフ等で判断。打ち合わせのしやすさや担当の人となりなども考慮するポイントとなる。

○制作方法
１．あらかじめ用意されているCMS（テンプレート）に、お客様提供のテキストや写真を当て込める方式。制作期間が短く、あらかじめデザインを把握する事が出来る。
反面、オリジナリティがなく、完全オーダーメイドに比べると細かい部分までこだわる事が出来ない。
２．制作ソフトを使い、GUIで直感的に制作していく。制作期間は比較的短く、工数も短いが内部のソースに関して、乱れるケースが多くSEO的には不利な面がある。
３．エディタを用い位置からコーディングしていく。デザイン部分とコンテンツをCSSとXHTMLで分離し、制作後の保守が極めて容易。
デザイン的にも細部にこだわる事が出来、SEO的な内部対策も講じることが出来る。

○デザインレベル
制作実績や、業者のWEBサイト自身のデザインを判断材料にする。

○SEO／WEBマーケティングレベルは？
よいWEBサイトを作っても、実際誰の目に触れるか、何人の目に触れるか・・そこまで考慮した業者を選定すべき。

○価格は絶対価格ではなくコストパフォーマンスでご判断を！
初期費用無料、月額費用のみ形態は結局高くつくケースが多い。
実際に仕事を頼んだ業者のサービスの比較を繰り返し、パフォーマンスの高い業者が見つける。仮に見つかっても常に比較、対象を繰り返す。

○問合せフォームや予約受付、アンケートフォーム、自社ブログ、ショッピング機能などシステム開発を一貫でフォローできるか？これらのシステムを構築する技術のみではなく、必要なシステムを提案するコンサル力も評価の対象。

○閲覧者の心を掴むキャッチコピー！制作業者のライティング能力は？
広告代理店の要素も含むが、ただ単に提供されたテキストを埋め込む業者よりも、より効果的なキャッチで顧客の心をキャッチするセンスのある業者を選ぶようにする。

最近、色々なWEBサービス（API）をマッシュアップ（組み合わせ）して見栄えを良くして楽しんだりしてますが、完全に独自のオリジナルサービスを立ち上げようとした場合、ぱったりと思考が止まる。
今作っているWEBマーケティングツールも基本マッシュアップ。オリジナルの要素をもう少し取り入れなければ・・。

Googleの様に、湯水の様にアイデアは出てこないもんですね。
そもそも日本人って、もともとある発想にアレンジする能力には長けているけど、独自の物を発明するのは少し苦手な感じしますね。
はぐれ者を干す風潮があるからかなｗ。

なんにせよ、オリジナルの仕組みを作ろうと思ったら、OSの根幹であるとか、低階層のプロトコルであるとかより階層の低い部分をもう少し知らないと駄目かな。

最近ではWEBサイト制作後にIE6,IE7,Firefox3,Chrome等でデザインの検証を行ってますが、まぁ、最初はかなりズレますよね。

ベースはFirefoxで見ているので、それを特にIE6で見ると大概ひどい事になっていて、それから修正した後、Firefoxに戻るとまたズレる・・みたいな。

この作業って結構パズルみたいで以外に楽しかったりするんですが、バグが起因で再現率が100％じゃない時は、ストレス100％。

閲覧する人のせいにする訳にはいかないので、そのバグをも考慮したCSSにする訳です。特にIE6はバグが多い・・。

今、解いているのがFirefoxのTableのborderが消える現象。
ローカルだと消えなかったりするのが不思議。

こういう意味でもクロスブラウザ対策ばっちりのテンプレートとかCMSとかたまに使いたくなりますね。
うちは一から手打ちがモットーなので（ソバみたい）、毎回このパズルを解く訳です。

少し前まで常識とされていたSEO対策が、ほぼ何の意味もなさなくなってきた。特に内部要因。ペイドリンク／ペイパーポストに対するペナルティも強化されそうな気配。

GoogleにしてもYahoo（若干違うが）にしても、入力されたキーワードに対してコンテンツが有意義であるものがより上位に表示されるというベースがある訳だが、それを機械的に判断させた場合、タグやキーワード密度等の内部要因、バックリンク・SBM等の外部要因をある計算式に当てはめるしかない。

人間なら直感で求めてる情報かどうかすぐわかるが、この人間の直感で順位付けたランキングとアルゴリズムが返すランキングは、まだイコールではない。
検索順位を決定付けるアルゴリズムに詳しい、SEO業者などがコンテンツの内容ではなく、テクニックでランクを意図的に上げようとするのが一因と言えなくも無い。

検索エンジンとスパムテクも辞さないSEO業者とのイタチごっこは、今も続いているが、結局いつまで通じるかわからない小手先のSEO対策を講じるよりは、コンテンツの拡充を推し進めた方がはるかに効率が良い。

ソメイヨシノが提供するSEO対策とは検索エンジンの理念に合致するように、コンテンツの拡充を提案するコンサルティングな要素と到底スパムとは呼ばない、手間はかかるが効果的な手段を着々と講じる手法である。

関数単位だけど書いて残しておこう。
$attach　には作成したHTML形式のデータを格納

sub sendmail {
my( $mailto, $mailfrom, $subject, $body ) = @_;
open( MAIL, "| $sendmail -f $mailfrom -t" );

local $attach = "";
local $boundary = "-*-*-*-*-*-*-*-*-Boundary_" . time . "_" . $$;

### サブジェクトを jis にして、MIME エンコード
$subject = mimeencode( $subject );

### 添付するデータを、base64 でエンコード
$attach = &bodyencode($body, "b64");
$attach .= &benflush("b64");

#本文
local $message = "添付ファイルを開いて確認してください。";
&jcode'convert(*message,'jis');

########################## メールの組み上げ
### 全体のヘッダ
print MAIL "MIME-Version: 1.0\n";
print MAIL "Content-Type: Multipart/Mixed; boundary=\"$boundary\"\n";
print MAIL "Content-Transfer-Encoding:Base64\n";
print MAIL "From: $mailfrom\n";
print MAIL "To: $mailto\n";
print MAIL "Subject: $subject\n";

### メール本文のパート
print MAIL "--$boundary\n";
print MAIL "Content-Type: text/plain; charset=\"ISO-2022-JP\"\n";
print MAIL "\n";
print MAIL "$message\n";

### 添付ファイルのパート
print MAIL "--$boundary\n";
print MAIL "Content-Type: application/octet-stream; name=\"entry.html\"\n";
print MAIL "Content-Transfer-Encoding: base64\n";
print MAIL "Content-Disposition: attachment; filename=\"entry.html\"\n";
print MAIL "\n";
print MAIL "$attach\n";
print MAIL "\n";

### マルチパートのおわり。
print MAIL "--$boundary" . "--\n";

close MAIL;

}

最近ではPerlのCatalyst、PHPのCake、Ethna、Zendの参考書を
ザッピングしながら、作業効率／クォリティを飛躍的に高めては
くれないものかなぁと思案している訳であります。

結局フレームワークを導入する事の恩恵はよくわかるんですが、
それこそ大規模の案件とか複数人でとか、ずっと一つのフレームワークを使い続けるとかじゃないと、パフォーマンスを発揮する前に、覚えるだけでクタクタになってまう・・。

昔、他の人が作った完全オリジナルの自作フレームワークを使ってコーディングした時、フレームワークの挙動を調べながらの開発で能率が極端に悪くなったのを思い出す。

結局使いこなすなら、なんだかんだでフレームワーク自体のコード部分も追う必要あるだろうし。せめてデファクトスタンダードがあればいいんだけど、種類多いんだよなぁ。

WEB界のガリバーというか第一人者Google。
Googleのおかげ、この世に神秘は無くなった。とかなんとか偉い人が言っていた。

この前、ストリートビューで自宅を見つけたら、干していた洗濯物（トランクス）までバッチリ確認できたｗ。
今では、世界中の海底や、月だって散策できる。
世界中の書籍をDB化の真っ最中らしい。
広範囲のWEBシステムがGoogleから提供されるAPIでまかなわれたりしている。

そして大概それらの情報は無償で一般ユーザに提供される。
これほどのスピードで情報が集積され、公開されて行く。
WEBに携わる他の企業がマネタイズする余地もほとんど無くなるほどに。

Googleの行く末に興味深深。次はどんな仰天サービスが飛び出すやら。

WEBの業界に入ってから、慌ててAdobeのCS買って、Photoshop／Illusratorを覚えたのを思い出します。

CS買った割には、その他のアプリは使わないまま。
Fireworksってなんじゃらほいと暇な時に調べて使ってみたら、まぁ簡単。
簡単って言っても、機能がスカスカとかそういう訳でなく、以外に高性能。

PhotoshopとIllustratorもその機能に驚かされますが、ユーザビリティ的にはどうなのと思ってました。初めて使う機能は何かしらの参考書か誰かに教わらないとわからない・・。

Fireworksで済むものは最近、全てFireworksでやってます。
それにしてもFireworksPNG形式って何者なんだろう。
性質について申し少し調べておこう。

今日はPerlでシステム開発をする過程で、過去につまづいた小ネタを。

レンタルサーバ等でPerlを用いてシステム開発をしている場合、レンサバにインストールされていないモジュールをuseで指定した場合、下記のエラーが出力される。Cron実行などでルートディレクトリが普段と異なる場合も、下記のエラーが出力される事がある。

Can't locate XXXX/Xxxxxxxx.pm in @INC (@INC contains:

そういった場合は、モジュールをCPAN等からダウンロードしてきて、プログラムファイル群配下のライブラリフォルダ(例：lib)に格納し、それもアップロードします。
あとは絶対パスでライブラリフォルダのパスを通せば、上記エラーは出なくなります。

use lib qw(/home/xxxxxxxx/xxxx/public_html/cgi/lib);

運営しているサイトがYahooでのみ検索されなくなった。
条件付で、ある特定ページ（トップページ）のみ。

なんでコンテンツが凝縮されているトップページのみ検索結果に表示されなくなったか調べていると、なんでもTDP（トップページダウンペナルティ）という、処置をYahooにされている様で、他にも体験されている方が大勢いた。

どういう条件でこの様な待遇を受けるかはYahooのYSTのアルゴリズムを知るYahoo内部の方しか知らない訳だが、どうやら行き過ぎたSEO対策が起因しているらしい（当方ではごく一般的なSEO対策しかしてないが・・）。

GoogleやMSNでは、まだこの様な待遇はされていない。
どうやらYahooは、いわゆるSEO業者のリンクファームの意図を潰そうとしており、その対策が今回当方で見舞われた現象に関係していると、勝手に思い込んでいる。

まぁなんにせよ、検索エンジンを利用する一般ユーザが最も利益を得られる検索結果になれば、一番よいが、全てYahooの手の上という状況はいかがなものかと思う。

検索エンジンを利用する一般的な方にも、この検索エンジンがどういう仕組みで結果を出力し、どういう形態で収益を上げており、他にどの様な類似検索エンジンがあるか、その辺にもっと興味を持って利用する検索エンジンを決めて欲しいと感じる今日この頃であります。

いやはや、数字にはめっぽう弱い自分。
昔は数学が一番得意だし、好きだったのに・・。

昔から金には無頓着で、どんぶり勘定だったのが、
ここにきて、かなり向かい風となってます。

弥生会計と弥生販売を導入して、使い方、会計についても
徐々に覚えてきました。

ただ、この弥生会計と弥生販売、サポート契約しないと、
よりよく使い続けるのは困難の様です。
まず、よくある質問の回答を見るのが、いきなりサポート
契約してないと見れません・・。
そして毎年更新される可能性のある、確定申告やその他オフィシャルな様式の用紙に対応するにはサポート契約をしてバージョンアップをし続ける必要がある訳です。

毎年何万円か払ってサポート契約をするのが前提っぽい製品の特徴なので、導入する方は、その辺も考慮した方がいいですね。

その姿勢がアリアリだったので、現時点で自分はサポート契約してませんが・・。
経営を早く軌道に乗せて、会計・経理は外部のプロに任せるか、精通した事務の方を採用するかしたい。