スモールビジネスのIT日誌

• (2011-09-04 07:00:18)

カート不具合の指摘

カートが動作していないとの連絡を同じ日に別々のお客様からいただく。調べると動作に何ら問題はない。

・IE8

・Chrome

・FireFox

・Opera

・Safari

お客様のブラウザでjavascriptが止められているのではないかと疑ったが、しかし、2人から指摘されるとなると個人の環境の問題でないかもしれない。

IE8以前のプラウザのシェアは？

自分自身、Windows7よりもXP愛用者なので、デフォルトではIE6がインストールされるが、IE8を使用するようになって時間が経ってIE6利用者がまだ存在するという事実を忘れがち。

考えてみれば、ブラウザシェアなど気にしていないが、自社サイトのシェアをAnalyticsで調べると予想外の結果。

【自社サイトのブラウザシェア】

・IE・・・60%

・Safari・・・13%

・FireFox・・・10%

・Chrome・・・6%

・Android Browser・・・5%

【自社サイトの各IEバージョンシェア】

・IE8・・・60%

・IE9・・・16%

・IE7・・・13%

・IE6・・・10%

・IE5.5・・・0.02%

IE6で別トラブル発見する

さすがにIE5.5はもはや無視してよいだろうが、IE6の10%は大きな数字に見える。

そこで「もしや、IE6で不具合が出るのかも」と疑い、自分のPCをIE6に落として見てみると、カートは動作していたが、CSSがうまく動作しないことが判明した。

トップページから、いきなりレイアウトが変形している。

IE7でも若干レイアウトの異常が発見された。これもCSSの問題に見える。

結局、カート問題は未解決のままで別の問題を発見するというシステム管理者にありがちなパターンで推移している。

IE8でチューニングしたサイトを、どこまでIE6にも対応させるのか、そういう余力は少ない。多くのECサイトが同じ問題で苦しんでいると考えられるが、対応の仕方は経営判断の領域だろう。

緩慢なシステム管理

なお、もう一つ印象深かったことはSafariのシェアの高さ。当社にはMacとiPhoneユーザーが多い事実を知る。

考えてみればAnayticsも用がなければ開かないし、その頻度は半年に一度程度。緩慢だ。大企業さんだとこういう状況を見て「システム管理者が不足している」と判断するだろうか。

• (2011-08-31 11:48:21)

突然動かなくなったプリンタのトラブル事例

プリンタが突然動作しなくなった。その前日まで問題なく動いていただけに不可解な現象。

「昨日まで動作していた」ものが急に動かなくなると何が悪いのか原因の特定さえとっさに思いつかない。

結果的に何らかの理由でIPアドレスが変化しソフト的な通信コネクションが切れていた。

そういえば、新しいPCをLANに接続するため他のLANケーブルを抜き差ししていたが、その過程で何かやってしまったのだろう。

IPを設定し直すことでトラブルは乗り越えたが、こういうトラブルはムダである。このプリンタは関しては今後DHCPを利用せず、固定IPにすることで、今後の同じトラブルを回避できる。

トラブル発生リスクは極力抑える

昔の電気製品と違い、PCやIT機材はスイッチを入れるだけではダメで何らかの「設定」が必要なものが多い。設定はシステム担当者以外には大きな負担。

・設定しなくてよいようにデフォルトで動作する環境を構築

・設定はその方法と内容をシステム担当者の頭の中でなく、外部に記録して第三者も見ることができるようにしておく。

特にシステム担当者が不在時に発生するトラブルはビジネスの継続性に問題がある。システム担当者が不在時に起きたら困ることは日頃からリストアップしておくことが大切。

「システム担当者が不在時に起きたら困るリスト」

Todoリストと同じだ。

手を打つべき内容がビジュアル化される。

これがあるだけでも、システム担当者は出張など不在にする時点で事前準備もスムーズにできるはず。

そして、重要なことは「困るリスト」は人間の体質上、後から作成することはないので(トラブルになって作成することはあっても)、システムや機材を導入・設置しるタイミングで必ずリスト化する習慣にしたい。

つまり、最初からトラブルを想定した運用ポリシーを描く態度が、システム担当者の持つべきスキルだろう。システムや機材を導入して「便利になったね」ではまだ未熟という覚悟が欲しい。

• (2011-08-17 17:02:50)

チカッパは終了？

ロリポップに自動的に移動させられた。チカッパというサービスは終了ということだろうか。名称程度は残りそうだが、新しいコンパネを見る限り、ロリポップそのものだった。

似たようなサービスを複数維持することはビジネス的に厳しいと判断されたのだろう。経営的には正しい判断に違いない。そもそもなぜ似た別サービスを立ち上がったか、それは教訓かもしれない。

移行作業ではまったこと

2点はまった。

SMTP AUTHへの変更

excelのvbaからbasp21を利用して配信している発送通知メールが動作しなくなった。

メールサーバは変更ないが認証方式が、POP before SMTP から SMTP AUTHのみに移行。

認証が必要なかったSMTPから、POP before になって、今時は SMTP AUTH が主流。スパムメール対策として世界中のプロバイダーが SMTP AUTH を導入してくれたら、スパム業者へのプレシャーになるので歓迎だ。

ぜひ、SMTP AUTH も CRAM-MD5 でお願いしたい。

vba変更箇所：

・mailfromのパラメータ：メールアドレス＋id&パスバド

　basp21では下記のような感じで記述する：

　mailfrom= "氏名＜sales@123.com＞" & vbTab &

　　　　　　　"123-sales:12345" & vbTab & "CRAM-MD5"

　※SMTP AUTHの認証方式は CRAM-MD5 固定の模様。

　※メルアドだけの場合、以前は山括弧不要だったが、

　　501 could not parse your mail from command というエラーが。

　　今回から山括弧で囲まないとエラーになる模様。挙動が若干変化。

.htaccessの記述

移行後、ホームページにアクセスすると、画面が表示さず、htmlファイルがダウンロードされる現象が発生。チカッパのページに解説があった。

【 サービス移行前 】

AddType application/x-httpd-php .htm .html



【 サービス移行後 】

AddHandler php5.2-script .htm .html

Webページが表示されない現象に遭遇したとき、しばらく原因不明でのたうち回る。「これが止まるとビジネスが止まる」と考えて自分のバックアップ体制の弱さを痛感。

結果的にすぐに回復したが、一週間前には24時間以上メールサーバがダウンしたこともあり、バックアップ体制については考えさせられた。

後日談：影響は予想より大きかった

変更前、SMTP AUTHになることに影響の大きさは予想しなかった。実際のところ、メールソフト(クライアントソフト)の設定の直し程度だろうと予想していた。

しかし、ビジネスでは顧客通知専用の「自動送信メール」を至る所に多用していて、その存在さえ忘れているものが多かったことを実感。

「自動送信メール」を利用しているアプリケーションは多彩で、Excel・Access・自作プログラム内などにあり、どれもたいてい動作しなことではじめて、そして、不具合が起きるたびに五月雨式にトラブルに気付く有様。

状況に対して緩慢である。

まら、リマインダーのアプリケーションも動作しなくなっていたが、これも気付かずに見逃すところだった。偶然発見しなければ今も気付かずにリマインダーは放置されていただろう。

また、サーバーに置かれたのPerlプログラム(sendmailを使用)は日ごとの取り込みの切れ目(セパレータ)を自動メールするプログラムだが、何の変更もなく動作していることが逆にふしぎだ。

時間がないので放置しているが、メールを利用したシステムの多さを考えると、メール関連の変更は軽視できないという教訓を経験した。

• (2011-07-26 10:05:21)

uft-8とshift_JISの混在は混乱の元ながら・・・

webサイトのhtmlページは長年のShift_JISだったが、最近は気付くごとにutf-8への移行を試みている。

しかし、今日はperlで書かれたフォームメールプログラムではまる。uft-8で書かれたhtml上にフォームからプログラムを呼び出す際にトラブる。

・メール

・氏名

・題名(タイトル)

・本文

のような日本語で表記された変数はフォームからの文字列が、プログラムに渡されたとき、文字化けを起こしているようだ。文字化けした変数では正常動作しない。

はじめはプログラムが正常に動作しない理由がわからず、ムダに体力と時間を浪費した。

対応策

日本語変数をすべて英語にするか、htmlページをShift_JISにするか、プログラムをuft-8に対応させる、のどれかしかないように思う。

【選択1】

perl内変数の英語化。

・mail

・name

・Subject(Title)

・Content

【選択2】

htmlのキャラクターセットをShift_JISにし、ファイルもShift_JISにする。

・html宣言：＜META content="text/html; charset=Shift_JIS" http-equiv=Content-Type＞

・htmlファイルの文字コードをShift_JIS化

【選択3】

時間切れ。

日本語の文字コードの問題はプログラマーにとって余計な開発負担で、webのhtmlページ制作者にとってもムダに時間をとられる仕事になっている。致命的でないにしても、長期的にウジウジと悩ましい。

• (2011-07-15 18:41:40)

簡易CMS的発想

小規模なwebサイトではフレームワーク全体を下手にCMS化するより、必要や実需要に応じて、静的なhtmlの一部にphpなどの動的html導入(コンテンツのダイナミックな生成)した方が自然発生的で無理がないweb制作手法かもしれない。

「動的html導入」の考え方が発展するとCMSという発想になるが、そういう需要に至っていない小規模なwebサイトがはじめからガチガチのCMSを導入することはむしろ柔軟性が極端に悪くなり弊害が多いと感じるようになった。

フッター部分など共通部分の切り出し案

当社ホームページはコンテンツの一部にCMSを取り入れているが、やはり主要部分はhtmlファイルが占めている。

しかし、フッターはどのページにも同じ内容で、またGoolge Analyticsの長いスクリプトを全ページに挿入するのも大変。この共通部分は切り出してもよいのではと昔から思いつつそのままだった。

一括置換ソフトを使えば、共通部分の変更もそれほど苦ではない。しかし、時間の経過で微妙にフッターに違いが発生すると一括置換の効用も効きが悪くなる。

共通部分の外部ファイル化

●外部ファイル(external files)化できそうな部分：

・ヘッダー

・サイドメニュー(左)

・サイドメニュー(右)

・フッター

●htmlファイル内でのphpの記述方法：

include、include_once、require、require_once が使える。

デフォルトは include がおすすめか。

＜?php include("/home/users/mydomain/ex_footer.php"); ?＞

※外部ファイルの拡張子は問わない。txt,html,php,cgi,pl,incなど可。

※相対パスでも絶対バス(フルパス)でもよいが、httl://で始まるURLは不可。

●htmlファイルをphp実行可能(phpモード)にする設定

.htaccessに下記の一行を追加：

AddType application/x-httpd-php .htm .html

※処理速度の差について。phpモードではいったんphpコードを実行しhtmlデータをダイナミックに生成したあと、通常htmlのようにテキスト・画像などを送出するので2段方式の処理となる。

そのため通常htmlより負荷が発生し全体のスループットが低下すると推測される。平均的なWebサーバーとコンテンツでは体感できるほどのスピード差になるとは思えないが、やや悩みどころ。

外部ファイル化を実際にやってみて

上気、外部ファイル化が有望と考えた4部分のうちで、ヘッダー部分はあきらめた。＜title＞や＜description＞など個別に記述したいタグがあること。

通常ヘッダー部分にはcssファイルの指定が含まれる。そのため他のパーツや本文の個別の作成やメンテナンス時、cssなしの表示となりメンテナンス性が極端に悪くなる、などがその理由。

＜title＞、＜description＞、スタイルシート以外のヘッダー部分を外部ファイル化すれば問題ないかもしれない。