Count:
「Sugaken's Web Page[note]」
2004/08版 その3



2004/08/21 (土)

暮らしのダイエット

PHSカードを持っていたのだが、ここ数ヶ月使っていなかったので、解約してきた。レンタルサーバ引っ越しとあわせると、月額で5000円くらいの節約になる。あまりにもおいしい。今まで知らなかったことが後悔。しょうがないなぁ。

ドコモショップからの帰り道、ふとCDを売ってる家電の店に立ち寄る。なんかグッとくるCDないかなーと思って。ありました。グッと来ます。マツケンサンバ。勢いで購入。

この喜びを誰と分かち合いたいか・・・・・そりゃ、このタグイは両親に決まってるでしょう(そうなのか?)ということで、電話。買ってしまったことを正直に告白(なんか悪いことしたような書き方だけど、そんなことはありません)。両親大爆笑。おまけに「なんでCDなんか買ったんだ、DVDを買わないと、意味がないだろう」とまで諭されてしまう始末。この親にしてこの子あり。親の血はしっかりと受け継いでいます。はい。

こういう買い物してるから、よくないんだよな。



2004/08/22 (日) コーディング依存症(?)

QRコードって、なんだろう?

ちまたで話題の(?)QRコード。規則性さえわかれば、生成するのもそんなに難しくないハズなんだよな。少なくともコンピュータを使って生成させれば(もっとも、その前にロジックを頭で理解することが必要なんだが)。

で、いろいろ調べてみた結果をQRコードを生成してみるページにまとめてみた。結局、ロジックは借り物なのだけど(うーむ、そんなんでいいのかな)。このブログのURLをQRコードにした結果のソースコードを見ればわかるのだけど、結局「0」を示すコードと「1」を示すコードを羅列しているにすぎない。イメージ作成はCGIの負荷があがりすぎるらしく、レンタルサーバで止められる可能性があるということで止めておいた。

とりあえず、こんなもんでいいかなー。


携帯用ゲートウエイCGI

いったいなんのことやらかもしれない。つまりは、CGIとして動作するゲートウエイなのだが、普通のHTMLをそのCGIを通して携帯では見られないタグを落とす機能を持たせる。こうすることで、パケットの量を減らすことができるし、テキスト以上の情報をすべて落とすことで、アクセシビリティのチェックも(あまり本来の目的ではないが)できることになる。

一昔前はそんなモノがあったりしたのだが、今はすっかりなくなってしまった。パケット代を気にしないでできるようになったからなのか、それとも携帯対応サイトが増えてきたからなのか。せめて、この日記くらいは携帯対応したいと思っているのだが。

今のところ、仕組みはこんな感じ。

  1. CGIに対して引数なしの場合は、当然URL入力フォームを表示して終わる。
  2. 引数がある場合は、URLデコードを施して、サーバ名とファイルパスに切り分ける。
  3. ソケットを作成して、当該サーバのポート80に接続。
  4. フルパスをGET属性に指定して送信。
  5. 帰ってきたデータを取得。場合によっては一時ファイルに保存。
  6. 文字化けを想定して、いったんJISコードに変換。
  7. i-modeでは対応できないタグを削除。本来はBODYタグとAタグ以外はすべて削除してしまっても良さそうな気はするが(BODYを生かしているのは、色遣いだけは生かしておきたいから)。
  8. 一気に携帯に出力。

こういうサービスをしてる会社もどこかにあると思うんだけどな。どこかで特許とか取ってるのかな。

自分のサーバの中だけでも(なんちゃって)携帯対応

・・・・またも、へっぽこコーディング依存症SEの夜は更けていく。


勢いで

作ってしまった。この日記だけ携帯向けにタグを落とした。サイズもタグを落とした分、そしてCSSを読み込まなくした分だけ軽くなる。HTMLだけで比較すると、だいたい半分くらいになる。CSSを読み込む必要がなくなるので、だいたいPCで見る場合の3割くらいのデータ転送だけで済んでいるハズだ。しかし、そのCGIもファイルを開いて、正規表現を乱打してタグを落としているだけ(だから、中途半端にタグが残ってしまっている)。なんだか美しくも何ともない。とりあえず動くことしかない。でも、それでいいかな。頭のサビを落とすには。



2004/08/23 (月)

東北と北海道 −津軽海峡を挟んだ文化の境界−

優勝旗は白川の関を越えない、と言われてきた。そして、高校野球で優勝したのは北海道の高校。確かに、通過することなく、ひとっ飛びで飛んでいってしまう。言っていることに誤りはないのかもしれない。

それは、気力、体力、時の運といった勝負強さを味方に付けないと、手に入れることができないものだろう。昔は東北の寒さは、冬のトレーニングが雪に阻まれてしまう。ある意味で甘受していた言葉なのか、それともハングリー精神を喚起するものなのか。

東北人にとっては、まさに頭の上を飛び越えてしまった事件でしかない。または「北海道だったらしょうがないかな」とも思っているのかもしれない。北海道は、自分たちよりも北にあるけど、もっとずっと都会だから。そんな思いもある。

北海道と東京の間にある、そんな単純な構図の中に東北を入れてしまうと、なんだか今回の優勝も、遠い世界の話にしか聞こえない気がする。なぜだろう。




2004/08/24 (火)

SEの能力 −なんのための開発工程なの?−

試験をして妥当性を検証できない設計はない。試験をしても意味がないということは、設計していることに意味がないといっているのと同じこと。そして、バグの傾向から、次の設計にフィードバックしていかないと意味がない。新人は試験工程から「鯉の滝登り」式に、開発工程を逆流して育てていかないといけないのかもしれない。そんなことをふと思った。

試験をすることで、次の設計がどうあるべきなのかを体で覚える。コーディングはやってればイヤでも覚える(そのかわり、何があってもコーディングでは甘えさせないこと、かな)。そして、お客様の対応は運用をやっていればイヤでも身に付く(当然、後ろにお客様がいる恐怖に最初はおびえることになる)。工程を何度も回していれば、身に付くことは当然あるのだとは思うが、逆流させることで前工程と後工程が明確に見えてくるような気がする(この前、監査研修でも講師がそんなことを言っていた)。

「新人か・・・とりあえず試験でもやらせるか」というのは、あながち間違ってはいないのかもしれない。でも、それが設計にフィードバックできるような試験なのかどうか。そして、それを意識させて試験をさせることができるかどうか。

ひょっとしたら、SEになるための学校は、この逆流工程をたたき込むところにあるのかもしれない。




2004/08/25 (水)


2004/08/26 (木)

Webサイトを管理する −魔法の杖を探して−

Webサイトを構築する。当然のことながら、全体に統一感のあるHTMLを作る必要があるし、デッドリンクにならないようにリンクを入れないといけないし、IMGタグのターゲットは存在していなくてはならない(まだUDの観点が出てくる前の段階だ)。サイトマップも必要だろう。その管理は面倒でしかない。コンテンツが増えるたびに、サイトマップを作り直し、ページに前後関係がある場合は取り替えなくてはいけない。ページが増えれば、当然画像も使うことがあるだろう。その管理すべき対象となる画像も、HTMLが増えれば増えていくことになる。ポップアップやフレームを使っていれば、その手間はさらにふくらむ。頭の痛い問題である。

ここにいくつかの選択肢がある。つまり、手で直すか、自動で管理するか。前者の場合、根気と十分な時間、要は手間暇を惜しまなければ、コストがかからない。その代わり、いつまでも同じような作業(これは管理すべきHTMLの数が増えれば等比級数的に増加する)を繰り返すことになる。ページデザインを全面変更すれば、当然、すべてのHTMLを変更するわけだから、これはとんでもない時間が必要になる(大学生だった頃に作った自分のページは、時間があったので手で管理することに時間的な制約はなかったが、驚くほど同じ作業が繰り返されるのに閉口した)。そして後者の場合、ざっと調べたところ、これが結構高い。やすくても2万円、高いモノでは天井知らずになる(独自にカスタマイズして提供する、とうたっている販売会社もあった)。

ニュースサイトのようなところは、当然のように数百万(またはそれ以上)をかけて管理しているのだろうが、たかが100にも満たないHTMLにそんな金をかけるのも、金持ちの道楽でしかない。

こういう時のネット検索・・・・とおもったら、いいツールが見つからない。HTMLのテンプレート、前後関係、そして画像の管理、ついでにサイトマップの作成くらいで機能としては十分。FTPは別のソフトを使えばいいし、HTMLはエディタで直すことができる。単純にそのコンテンツを管理したいだけなのだが、なかなかいいツールが見あたらない。

なければ作ればいいのか、それとも誰かが作ってくれるのを待てばいいのか。悩みどころ(悩むくらいなら作ればいいのか??)ではある。



2004/08/27 (金)


2004/08/28 (土)

魔法の杖を探して −解決策 その1−

なかなかいいものがない。結局、自分で作ることもあきらめ(こういう時のあきらめは非常に決断が速い)、おとなしくXOOPS専用サイトを立ち上げることにした。あいているサーバ名があったので(こういうときに空いているドメイン名があるということ自体が、どうかと思うが??)、MySQLを組み込み、とっととXOOPSをインストール。MySQLは面倒な設定が必要かともおもったが、XOOPSインストール時に自動でテーブルなんかを作ってくれた。

今のところ、使い勝手もなにもわからないので、適当に設定してみた。アドレスは http://sugaken.happy.nu/ で運用してみることにした。結局、利用者登録しないと何もできなくなっているのだが、それはまぁ今のところのご愛敬ということで。



2004/08/29 (日)

魔法の杖を探して −解決策 その2−

で、XOOPSでRSSフィードを展開したり、この日記専用ツッコミフォーラムを作ってみた。ついでに、あちこちからモジュールを探して入れてみた。とにかく、動くようにはなった。デッドリンクみたいなのはこれでなくなるはず。本当はDownloadページを作ったりしないといけないんだろうけどね。ソフトの展開のためには。

つまり、今の段階は「モジュールの組み合わせ」でしかない。だから、この先には「自分好みのサイト構成に変更していく」ことなんだろう。フリーソフトを配布したり、QRコード作成ページにしてみたり・・・・メニューをうまく作ることがまだできていない。これができてしまえば、他のサイトとも統合できるはず(サイト統合はDNSの設定を変更するだけなので問題はない)。

オンラインだけですべて済むと思ってはいけないのかな。オンラインマニュアルのモジュールがあると便利だと思うのだが。




2004/08/30 (月)

魔法の杖 −人を動かすと言うこと−

人を動かすこと。結局、自分が動いた方が速いし、確実なのに、それをお願いすると言うことは、いくつかの前提を元にしないといけない。つまり、自分の作業時間は無限ではないということ、そして相手に期待する歩留まりを考えておかなければならないこと、そして自分の言ったことが100%伝わっているわけではないという前提で考えないといけないこと。

つまり、モノを管理するときの大きさや重さを管理する手法と、人を管理する手法というのは、当然ながら全く異なることになる。同じであることの方がおかしい。

期待通りのレベルで作業結果があがってこない、なかなか進捗しない、そして単純作業者になってしまっているといった、一般的に作業をお願いするときの問題点は、逆に言えば作業を依頼した側の問題に帰着することが多い。つまり、歩留まりを考えているか、作業の周囲、もっといえば全体像をみせているか、進捗はどの単位で管理するのか、といった点を、自分たちはきちんと考えているのだろうか。それができないまま、管理される方のスキルに帰着されて、能力の有無といった問題になってしまうことが多い。

自分がやった方が速いし確実。依頼する側の事実と、依頼される側の前提条件。両方がきちんと提示されていないと、結局、手戻りや無駄作業になってしまう。

自分の反省も込めて。




2004/08/31 (火)

メンタルな怠さ −怠け者−

なんだか疲れた。精神的に。どうしたんだろう。




メールはこちらへ...[sugaken (sugaken @(at) sugaken .(dot) com)]

この日記は、GNSを使用して作成されています。