すた・ばにら

すたは現実世界の私、ばにらは気ままに野山を駆けめぐる野ウサギ…

ホームページ情報

[ リスト | 詳細 ]

ローカルなコアネタを収録する ホームページ の製作裏話や詳細情報です。

(旧書庫名:「趣味のもの」)

http://x7.hatiju-hatiya.com/bin/ll?09548770j
記事検索
検索

全4ページ

[1] [2] [3] [4]

[ 前のページ ]

ホームページ構築中

 
別に続きというほどでもないけど、以前この話題で書いたので続編扱いにしてみる。
 
ホームページを作るにあたって早い段階で取り決めておいた方がいい項目として、個人的には次のようなものがあると思っている:
 
(1) ディレクトリ構造
(2) 記事フォーマット
(3) コンテンツ分類
 
これは以前、ホームページを作成していて経験的に得た問題だ。
 
例えば何か特定の趣味や娯楽を個人のホームページとして載せる程度なら、自分のアカウントに割り当てられたルートフォルダに画像からテキストから全部突っ込んでもそう問題はない。
しかし手作りの工芸品を多数紹介しつつ、個人的な日記も載せたいなら、普通は両者をファイルやディレクトリで分けるだろう。
はじめのうちは一緒くたでも大丈夫だが、ページ数が増えたから分けたくなったという場合、早めに手当てしておかないと大変に面倒なことになる。
 
私の場合、自分の日記は月ごとに HTML ファイルを作成していた。2011年9月なら 201109.htm の如くである。分量が増えたときには 201109_1.htm のようにしていた。
 
ところが三日坊主で終わると思われた日記が意外に続いた。それらを /diary/ ディレクトリに保存していたが、一ヶ月平均3個、一年で40個以上ものファイルが作られることになった。それが数年も経てば、日記ファイルは100を超える。
管理が大変になったから、/diary/2010/、/diary/2011/ … のように年単位のサブディレクトリを作るべきだと気付いた。しかし無造作にそれをやると、日記ファイルに埋め込まれている参照部分がすべてリンク切れになってしまう。
 
結局、特定の文字列を探して置換してくれるフリーソフトを見つけて全部を書き換えることになった。手作業ではまず不可能なレベルであり、こういう事態になる前に早めに計画しなければならない。
 
(2) の記事フォーマットも統一性を持たせるために重要である。ジャンルごとに区別をつけるために例えば背景色だけ変えるなどというのはアリだろうが、連載モノの記事なのに読み進めると文字のレイアウトが違っているなどというのは見苦しい。これを避けるためには、早めに自分の納得がいくテンプレートを拵えて、そこから書き始めたり、全てのページのレイアウトが一致するよう外部CSSファイルを呼び出すなどの措置が必要だ。
 
コンテンツの分類は、最適解がない困難な問題である。それは記事テキストにも画像の分類にも当てはまる。私の場合はテーマ踏査であり、道路、河川、工業用水、発電所などになる。
しかしそれらを完璧に分類することはできない。道路レポートの観点で書いていても主要な河川を渡る橋があるし、ダムと水力発電所は相携えて存在するから、分類しようにも必ず両者に跨ってしまう部分がある。
 
根本的な解決法は恐らくないだろう。Yahoo!ブログにあっても記事に”カテゴリ指定”することができても、用意されているカテゴリは些か粗雑である。YouTubeでも投稿しようとする動画にタグを付けられるが、”自動車と乗り物”、”コメディー”、”教育”…など、どれにも該当しないものが多い。それほどカテゴリ分類というものは、困難な問題なのである。
記事に複数のキーワードを持たせて、指定されたキーワードが含まれる記事を自動的に列挙してリストしてくれる HTML 向けのタグがあれば良いのだが…
 
現在のところ、メニューでは例えば「道路」の親要素に対して、「国道/県道/市道/高速道/その他の道路」のような子要素を設定している。子要素のリンクをクリックすると、そこに収録されている記事レポートの一覧が表示される…という仕様にする予定だ。
 
---
 
さて、先ほど例によって SkyDrive に新たな写真を追加した。そして以前から気になっていた現象が解決した。
 
以前、画像の URL がログイン・ログアウトなどのタイミングで不定期に書き換わり、元の URL では画像が表示されなくなることがあると報告した。
URL が頻繁に変わる理由は不明だが、画像が表示されない現象を回避するには、
 
画像が収録されているディレクトリを
パブリック(全体公開)にする。
 
…という設定が必要なようだ。
 
ログインして各ディレクトリのアクセス許可の表示状況を見ると、次のような文言が表示される:
 
Windows Live にサインインせずに、このフォト アルバムを表示できるリンクを共有しています。このリンクを知っている人はだれでもこれらの写真を表示できます。
 
この表示は固定で変わらないが、実際はパブリック設定にされていなければ URL が分かっていても画像は表示されない。最初、私は「友だち」設定にしていてこの文言が出たので、ディレクトリ全体を見ることはできないけど URL の情報さえ公表されているならログインしなくても表示できるのだろうと思っていた。
 
実際には表示されず、赤ペケになる。何度かやっていて突然、表示されるようになるのは、恐らくログインしたからだ。ログインしたのとホームページを表示させているブラウザが同一なら、単純に表示される。その後ログアウトしても画像は表示されるが、キャッシュを表示しているに過ぎない。
キャッシュを削除してリロードを試みると再度画像部分が赤ペケになる
 
SkyDrive は無料で利用でき、借りられるファイル存置可能容量も大きいのは大変有り難いのだが、個別の機能や仕様に関してはまだちょっと甘い点があるようだ。
ディレクトリ間で画像を移動できない、アクセス権表示は一度でも変更すると既定の”リンクを受け取った人”という表示には戻らないなど
 
パブリック設定にすれば、私のアカウントさえ分かれば最終的には SkyDrive で私が公開しているすべての画像ファイルを一度に閲覧できる。もちろん閲覧だけでなく保存も自由にできる。そういう仕様なので、原典ファイルをそのまま載せるわけにはいかないようだ。
 
なお、ホームページに関しては既にメニューとサブ項目、それから一部の記事レポートを移植済みである。
移植済みなので間上発電所レポート群は削除しました
ホームページ自体はまだ作成途中なので、当然公開はされていない。アップロードしている HTML ファイルもロボット拒否設定にしている。ある程度全体が閲覧できるようになったら検索設定も index, follow なりに変更しようと思うが、ホームページを公開宣言するまでまだ先は長いようだ。
 

開く コメント(2)

 
現在こうしてブログを書けているのだから、ホームページ移行は絶対不可欠というものではない。これから各記事を作成する分はいいとして、既にブログへ書いた記事も再構成する手間がかかる。
その煩雑さを承知してもなお移行するメリットを次の点に見いだしている。
 
(1) 可読性が高まる。
(2) 記事の信頼性が高まる。
(3) 関連記事との連携が容易になる。
 
ブログは元々作りつけの用紙が準備され、利用者は文字を書き込み、簡易な操作で画像などを添付するだけで出来上がるからこそ、今ほど普及した。この裏返しとして、使える文字サイズや色が限られているし、記事の並びを思うままにもできない。この点で連載記事には不適であることは、去年の同じ時期から感じていた。
 
ホームページならタグやスタイルシートを用いることで、自分が望むレイアウトはほぼ間違いなく実現できる。手間がかかり面倒なのは確かだが、それも最初の一度だけである。後で述べるテンプレート(ひな形)として別途持っておけば、ブログと同様にテキスト部分を書くだけで済む。 
 
信頼性の面においても、ブログとホームページでは差があると考えられている。たとえ同じコンテンツだろうと、ホームページで発信される情報は専門的とみなされがちなのに対し、ブログでは内容にかかわらずワンランクもツーランクも割り引かれる。
キーワード検索でブログを対象外にする人は多い。専門用語を調べようと検索し、ホームページがヒットすれば大抵は目的の情報が得られるのに対し、ブログがヒットしても殆ど役に立たない。欲しい情報に行き着かず、その語がたまたま含まれる個人の日記というパターンが目立つからである。
”ブログである”というだけで情報の価値や信頼性が割り引かれる現実がある以上、後々まで遺したい情報は別の方法で記録することを考えなければならない。
 
関連記事との連携は、読者だけでなく私自身にもメリットがある。普通のブログではする人は少ないが、私は本文中にしばしば関連記事のリンクを掲載している。関係する記事や題材を集中的に読む助けになるし、自分としても過去の関連記事を読んで今の記事に反映させることが多いからだ。
 
この操作はホームページでも手間がかかるのだが、ブログだと非常に面倒である。該当する記事を探しURLを拾って来るためにどの書庫でいつ頃書いたか思い出し、延々とページ繰りする作業を強いられる。それもオフラインでサクサクできるならともかく、オンラインで操作するブログはどの会社のものであろうと動作が非常に鈍重なのだ。
かつてYahoo!ブログが極めて重かった時期はこの作業は事実上不可能だった
 
ホームページへ移行したとき、最初の段階でキチンととジャンル毎に書庫を作成し、階層を造って整理しておけば、この作業はずっと軽減されるのである。
 
さて、以上のメリットをホームページで実現するには、ブログでは無縁だった綿密な計画を練る必要がある。どんなホームページにするか、主力コンテンツを何にするかというよりも更に以前の問題で、ざっと思い付くだけでもこれだけある。
 
(1) 記事のテンプレート
(2) コンテンツの階層構造
(3) 画像などの標準仕様
 
ブログではどこの運営会社のものであろうと「新規作成」ボタンがあり、押すだけで初期状態のページが提供される。しかしホームページの場合は原稿用紙となる初期のページは自前で準備しなければならない。
その代わり、あらかじめ自分好みの文字サイズや色を定義した記述を含めたテンプレートを作っておけば、毎回いちいち文字サイズを14ptに変えて、文字色は黒に設定して…という面倒を省略できる。
Yahoo!ブログでは互換性重視のためか初期状態が小さめの12ptで文字色は見づらい灰色…新規記事を書く度に14ptの黒色に変更するのが面倒で仕方ない
必要なら、トップに戻るリンクや階層表示などもあらかじめ入れておけば、どのページからでも容易に移動ができる。
 
このような基本のひな形は、なるべく初期の段階から決めておきたい。ページ数が極度に増えると、後から変更された表示スタイルの記述をコピー&ペーストして回る作業は大変である。統一されないひな形から記事を書き始めた結果、レイアウトや背景が不揃いというのは見苦しいものである。
 
階層の決定は、保守性の良いホームページを造る上で最重要課題である。個人の小さなホームページなら、ルートに置けば済むだろう。しかしいくつかのジャンルに分かれた内容で記事を書くなら、ジャンル毎のフォルダが要る。ルートに全部突っ込むと、重複するファイル名が出てきて支障を来したり、目的のファイルを探しづらくなるのは、ローカルパソコンと一緒である。
 
フォルダ自身の階層も考慮する必要がある。例えば日記を書く人なら、恐らく diary というフォルダを作るだろう。しかし長いこと続いてくれば、フォルダ配下に日記ファイルを並べたら探すのが大変だから、2010年、2011年…のフォルダを作りたくなるだろう。更には1月、2月…まで分類が要るかも知れない。
このような階層構造は、テンプレートよりも更に早めに決定しておく必要がある。後で階層構造を変えるようなことをすると、記事間を相対参照しているHTMLドキュメントは、一斉にリンク切れになってしまう。修正するにもファイル数が多ければ、置換ツールを使わない限り絶望的である。
過去にこの点で非常に面倒な修正作業を余儀なくされた
 
参照されるだけの画像についても、階層に細心の注意が要る。現在画策しているホームページでは大量の画像を参照するので、時間のあるとき早めに画像をアップロードしておきたい気持ちになる。しかし二つの理由で性急な行動を起こさないよう自重している。
そのうちの一つこそまさにこの問題に依るもので、階層構造を確定させてからアップロードしなければ、後からフォルダ名や構造を変えて画像ファイルを移動するのが甚だ面倒だからである。
 
さて、その二つ目の問題が画像の品位に関する問題である。
 
SkyDriveでは画像をアップロードするとき、保存品位を2種類指定できる。原典画像と、Webサイト向けに合わせたサイズである。
原典バージョンではサーバに原典画像そのままが保存され、プレビューするときには 600 * 450 ピクセルの中サイズ・サムネイルが表示される。
クリックすれば原典画像が表示される
Webサイト版では一律 600 * 450 ピクセルにリサイズされた画像が保存され、プレビューと実画像が同じものとなる。アップロードする際に自動的にリサイズされ、原典画像は保存されない。
 
オンライン・ストレージだけが目的なら、原典画像バージョンで行うべきだろう。しかし当然ながらファイルサイズが大きく、ストレージ容量を圧迫する。いくら25GB容量あっても全部原典画像だとすぐ限界が来る。
 
思うに、道路レポート等では道路を対象にした写真にそんな高解像度は要求されない筈だ。サムネイル状態では小さく写っているものを詳細に観たいという需要があっても、大画面の原典画像を観たいという人は僅少だろう。
 
以下は、予定されている 600 * 450 ピクセルの画像サンプルである。
当初掲載していた画像を削除したので差し替えました
 
 
Yahoo!ブログでは、画像は原則として最大 480 * 360 ピクセルと決めている(横スクロールを発生させないため)ので、計画しているホームページ向けの画像サイズはかなり大きい。もっともホームページでは、ブログのように2コラムを要せず横幅を目一杯使えるので、レイアウトの乱れは気にならない。
どの会社のブログも大抵は操作用のコラムが左右に配置されるために記事の有効幅が制限されてしまっている…大変勿体ないと思う
 
ストレージ容量を長持ちさせるために、当面は記事に埋め込み表示させるのに最低限必要なWebサイト版で保存する積もりだ。これなら相当枚数をアップロードさせても当分はパンクしないだろう。
それでも25GBの限界に達してしまったら…そのときには深く考えず新しい ID を取得すればまた25GB使える…事実上制限なく使えると思う
 
画像や動画以外は殆ど嵩張るものがないので、HTMLドキュメントや代替キャラクタ用の微細なGIFファイルなどはそのまま geocities に載せる。
 
HTMLファイルの各種参照は、可能な限り相対形式で書く。ローカルでもネット上でも正しく動作するし、将来もっと大きなレンタルサーバへ移植することになっても修正量が少なくて済むからだ。
 
さて、全く一からのスタートになるように思えて、そうでもない。かつてホームページを運営しており、当時のファイルはすべて保存している。レイアウトだけ借用して新しいサイトへ使う予定である。

開く コメント(2)

総括的なホームページを作るべく独自ドメインを取得し、計画を進めていたものの事が巧く進まず、有償ドメインを解約してしまったということは以前にも述べた
 
頓挫の原因は、コンテンツの中核的存在となる画像の保存が巧く行かなかったところにあった。500MBもの容量を無償で使えるという魅力的な Microsoft Office Live ながら、何故かログイン認証がスムーズに進まず、しかも保存した画像の品位が勝手に落とされてしまう意味不明な現象に悩まされたのである。
この件に関しては結局未だに原因が分からず仕舞い
 
すぐサイトを開設できる状況ではないと考え、取得していた有償ドメインは一旦解約して無償ユーザーに戻った。問題が解決されるまでの間、当面はこことローカルSNSのブログで下書き的に記事を書き進め、将来的には主要コンテンツをホームページへ移植するところまでは立案済みだった。
 
さて、この連休中に別の方法を考え、実験を重ねることで画像保存および参照方法の解決策になるかも知れない手段を見つけることができた。
 
SkyDriveに保存した画像データを
別サイトから直リンク参照させる。
 
ホームページスペースは多いに越したことはない(希望は容量無制限)のだが、記事となるドキュメントだけなら、実際そんなに嵩張らない。今、手元にあるバックアップ済みの Yahoo!ブログ記事を調べたら、概ね40〜60KBだった。この中には記事とは無関係なタグや広告関連の記述が含まれるから、純粋なドキュメントだけなら、テキストで64KBを超えることは稀だろう。
 
他方、画像の場合はデジカメで撮影したファイルをリサイズしても、一枚だけで64KBを超える。しかも単一記事を構成する画像は一枚どころではなく、平均的に12枚程度要る。このデータをドキュメントと同じサーバへ保存すれば、いくら無料で50MB使えるといってもすぐ満杯になってしまう。
光回線以前に契約していたプロバイダでは貸与容量が20MBしかなく、新しいコンテンツを掲載する都度一番古いものを削除しなければならなかった
 
ネットコンテンツで頻繁に登場する割に容量を圧迫しがちなのは、画像と動画である。特に個人サイトで動画を自前のホームページにバンバン掲載しようとすれば、よほど大容量をレンタルしてくれるサイトでなければ運営不可能である。
それでも昔は何とかして無料で動画ファイルもOKで無制限に貸してくれるサイトを見つけた…YouTube以前から高解像度の動画配信を行っていた経緯がある
 
画像データと記事のテキストを完全に分離し、記事に表示させる画像データを外部サーバ参照で呼び出すことができれば、当面は容量を心配することなく記事作成できるのではなかろうか…と考えた。
 
これは容易に思い付く方法であり、ホームページ時代に援用したことがある。ただしレンタルサービス会社の殆どは、この方法を認めていない。画像や動画の単一表示にはバナーが挿入されず宣伝効果がない上に、外部参照されればサーバに負荷だけ喰らって何のメリットもないからである。今でも多くの無償レンタル会社ではこのような”ファイル置き場”としての利用を禁止したり、referrer を調べて外部参照だったら画像を表示しない処理を行っている。
画像や動画を参照するHTMLドキュメントが置かれていれば問題はない
 
そこで今回思い付いたのは、無償レンタルされるホームページスペースではなく、SkyDrive のようなオンラインストレージ系サイトに画像・動画データを置き、外部参照するやり方だ。
 
SkyDrive ではあらゆる種類のファイルを保存可能であり、それぞれのファイルを参照するリンクが付属する。(後で述べるようにこれが非常に重要である
元々がファイル置き場を志向するサービスだから、公序良俗に反する内容でなければ、何をアップロードしてどんな使い方をするのも自由である。
 
SkyDrive は Windows Live ID のアカウント一つで最大25GBまでファイルを保存できる。ID 作成・登録は無償で個数制限もないので、事実上無制限にファイルストレージできる優れものである。
 
「Wikipedia - SkyDrive」
 
他に50MBを超えるファイルを保存できない制約があり、これはデジカメの標準モードで1分以上の動画に相当する。テーマ踏査にあってはそんなに長い動画を撮る機会が殆どないから、当面は大丈夫だろう。
 
それよりも問題となる点が一つあった。
 
SkyDriveに保存される画像すべてに
一意なリンクが与えられるのか?
 
これは絶対に満たされなければならない条件である。記事文中に画像を埋め込み表示させる最も標準的な方法は、<IMG src="sample.jpg"> というタグの使用である。外部サーバの画像を参照するには、src として http:// から始まる URL を指定する必要がある。
 
よくあるのが、サーバに保存した画像を呼び出すとき、特定の画面でボタンをクリックする仕様である。この場合、往々にして保存された画像への固定リンクが存在せずアクセスするたびにダイナミックに変わる。
そのような仕様になっていた場合、ボタンをクリックすれば表示はされるのに記事の中に画像を埋め込み表示できない問題が起きる。
 
この点に関して、保存された画像のURLを逐一チェックして調査した。全く奇妙なことに、画像へ付与されるURLは固定リンクではなかった。
 
SkyDriveで個別の画像をクリックすると、次のような形式のURLを持つページに飛ぶ:
このURLは仮想上のものである
 
hxxp://cid-3bfed1c6de5c75a2.photos.live.com/self.aspx/road/a/190/sample.jpg
 
これは私の ID に割り当てられたスペースで、road/a/190 という階層下に保存された一枚の画像である。末尾部分が self.aspx となっていることから分かるように、サーバへパラメータを渡し、画像情報を返すスクリプト(Active Server Page)である。
このまま記事文中へ <IMG> タグで呼び出しても画像は表示されない。実行している階層やサーバを認識して結果に反映させるからであろう。
 
そこで呼び出された画像自体のURLを調べてみた。それはこんな感じの複雑なものだった:
このURLは仮想上のものである
 
hxxp://public.bay.livefilestore.com/y3qJtPnYZGUAQg3kKDjYDClyucg5vsqaCToPPAIDzJtVjsjiuSI71rfnqbVSpfD2FQOma9JkMPX3ztAtnQZvs25Gg/90531189.jpg?psid=1
 
このURLを<IMG>タグに持たせて記事に埋め込むと、一応画像は正常に表示された。ここで末尾の ?psid=1 は表示に係るオプションらしく、省略しても画像表示に影響はなかった。
 
しかし…である。
 
URLが気持ち悪い。
 
いや、長いのは別に構わない。コピー&ペーストで移植するならそう手間は掛からない。むしろ一枚の画像ファイルのロケーションを指定するのに、どうしてこんな暗号めいた記述が必要なのかという点だ。
 
第一階層にある半角英数字の羅列は、先の cid で始まるページリンクより遥かに複雑である。これは64ビットの数値であり、ID を16進数に置換して割り当てたのではと推測される。
しかし画像のURLではアルファベットの大文字・小文字、数字、そして上の例では現れていないがアンダースコア_ とハイフン-の合わせて64種類のキャラクタが90個程度並べられる形で表現されている。
識別個数は (2^4)^90 ≒ 2.34854258 × 10108 という膨大な数値であり、これほどの文字列なら、もしかして個人情報が暗号化され埋め込まれているのではという疑念が起きる。そんなURLを不特定多数が閲覧するページに埋め込むことに躊躇してしまう。
 
更に調べたところ、このURLは固定されたものではなく、適当なタイミングで再構成される。(ログインしていても一定の条件下で変化する場合があるし、一旦ログオフして再度ログインしても再構成されない場合もある
そうでありながら、取得された異なるURLはどれも画像を表示させる点について有効に働くのである。つまり同一の画像であっても、そのURLを取得したタイミングによってバラバラなURLが提供されるらしい。
 
画像の表示に有効期限が設定されているのだろうか。今のところさっぱり分からない。よし、これで画像の問題がすべて解決した…とばかりに画像リンクを埋め込んだ記事を大量生産したはいいが、最初の一ヶ月は正しく表示されていたものの、半年経ったら画像が全部赤ペケ状態になっていた…では話にならない。
 
サーバに保存しているある画像を基準にずっと調査している。最初に構成されたURLは3日前のものだが、現在のところは正常に表示できている。今後どうなるかは SkyDrive にURL構成の仕様が公開されていないので、さっぱり分からない。
 
記事テキスト自体は、今のところ50MBまで貸してくれる geocities に置いている。ここはホームページ時代から既に利用していて、サイト閉鎖後は無用な閲覧を避けるために HTML ファイルをすべて削除してスペースのみ残されていた。
 
別のどのサイトからも参照できる訳だから、その画像は、Yahoo! ブログにあっても「ウェブにある画像を掲載」機能を用いて埋め込むことができる。もちろん、公開記事で行う気にはならない。もしかすると暗号めいたURLに漏洩させたくないログイン情報パスワードなど)などが埋め込まれている心配があるからだ。
SkyDriveに限らず何処のサイトでもログインして何かを操作した結果得られた半角英数字の長い羅列は安易に公開すべきではないということも言える
 
もっとも SkyDrive で一般公開設定された画像はすべて同様のURLを持つものであり、元々不特定多数の閲覧者に晒されることを前提としている。恐らく何らかの必要があって暗号めいたURL になっているだけだろう。Microsoft たるもの、仕様の齟齬で個人情報ダダ漏れなんて事態は考えるに及ばないかも知れない。
 
そういう訳で、今後新たな技術的問題や致命的な障害が生じない限り、この方向で新規にホームページを造ろうと思う。
巨大なものになったら、テキスト・ドキュメントだけでも50MB制限にかかってしまうかも知れない。しかしそうなるまでは相当に期間がかかる筈だし、記事同士のリンクに相対形式を用いるよう注意すれば、別のサイトへ移植することになってもソースの書き換え手間は殆どかからないだろう。
 
方向性が定まったのなら、すぐにでもコンテンツ制作に専念し、いち早く多くの記事を公開してサイトを成長させたい気になるのだが、ここは今少し慎重に進める必要がある。
それと言うのも、初期の段階で熟考し取り決めておいた方がいい項目が意外に沢山あるからだ。
 
(「ホームページ構築中」に続く)

開く コメント(0)

内容的には「ホームページ移行計画について」の続編になる。
 
ローカルSNSとこのブログでばらばらに記録されている記事を単一のホームページに統合すべく、以前から準備作業を進めていた。
登録先は、掲載容量がほぼ無制限でバナーもない Microsoft Office Live を予定し、ドメイン取得・登録も進めてあった。
 
しかし甚だ遺憾だが、つい先ほど
 
Microsoft Office Live に登録してあった
stavanilla.com ドメインを削除した。
 
 
理由は、前編でも少し触れているように、当初から認識していた問題がどれも解決できないこと、まったく利用しなくても2年目以降からドメイン登録しているだけで課金されてしまうからである。
 
 
Office Live では、既定ではブログと同様にオンライン状態で記事を書いたり写真を添付したりするモードになっている。これはネットの詳細な知識がなくとも操作できる利点があるが、パソコンに原典が残らない。今のブログと同様、自主的にバックアップを行わなければ、サービスが終了したり削除されたりすることによって、すべてのデータが一瞬にして消え去る恐怖がある。
 
幸い Office Live には FTP モードがあり、Microsoft Office Live Small Business Image Uploader と Microsoft Office Live Web Folder Connector をインストールすれば、Windows Explorer でファイルをコピーする要領でパソコンからアップロードできるようになっている。
 
しかし恐らくパソコン設定のどこかに問題があるのだろう。まずここで救い難い不具合に直面することになった。
 
何度も何度もログイン確認してくる。
 
 
次のようなダイアログが現れる。
 
イメージ 2
 
 
ログイン時の初回だけなら仕方ないものの、このしつこさったら半端ではない。ファイルのコピー、階層の移動、表示の都度、毎回必ず入力を求められるのである。それも正しく入力しているにもかかわらず、一度ではまず認証が通らない。4回、5回くらい入力して OK ボタンを押し、やっと表示されるという具合である。
 
それも同じ階層で操作しているうちは、ユーザー名とパスワードが表示された状態のダイアログが現れるからまだいい。認証が通るまで OK ボタンを押し続けるだけである。
 
しかし階層を移動すると、今度はユーザー名とパスワードが全部空白状態のダイアログが現れ、すべてを手入力しなければならないのである。
 
絶対、どこかがおかしい。
 
嫌になってキャンセルボタンを押せば、認証が通らず作業ができない。
 
イメージ 1
 
 
たった一つのファイルコピーですら、この有様で全く作業どころではない。
一体、どうしたことだろうか?
 
 
何とかして認証を通し、階層が表示される状態になった。
そこには作りつけの images フォルダがあり、画像を保存するようになっていた。それで手元にある何枚かの JPEG 画像をアップロードしたら…
 
たった 200KB 程度の画像ファイルのアップロードに15分かかっている。しかも後日、そのフォルダを表示させたら、あろうことか勝手に画像ファイルが低解像度に改変され、40KB位になっていたのだ。
 
多分、このフォルダは作りつけのもので、アップロードされた画像を圧縮する仕様になっているのだろう。もっとも、アップロード関連のドキュメントに低解像度化されるという記述は見つからなかった。
 
いずれにせよ、とにかくファイルのアップロードという最も基本的な部分でコケているならば、遺憾ながらこのままでは使い物にならない。課金されないなら放置でいいものの、ドメイン登録もタダではないのだから解約せざるを得ない。全く使わないものを放置して自動引き落としされるのを容認する利用者も居ないだろう。
 
 
ただし、一連の不具合の原因は Microsoft Office Live ではなく多分私のパソコン側にあると思う。Microsoft は OS の制作元なので、Office Live も OS に密着した仕様になっている可能性がある。たとえば起動時に自動で読み込まれるモジュールの存在を前提とする設計などである。
 
使わないサービスやモジュールを読み込むことはメモリの浪費になり、不具合が起きたときの原因切り分けを難しくするということで、かつて”通常の利用者ならまず使わないであろうサービス”を一斉停止処理したことがある。このあたりに原因があるのかも知れない。
 
思うに、昔のホームページ時代の方が無料サービスにしろ FTP にしろずっと簡素で充実していた。容量が小さいという問題はあるものの、ボタン一つで更新したファイルだけを自動的に選択してアップロードするツールのお陰で、記事の更新だけに集中することができた。
 
作業が終わったら起動させれば、その日一日の更新分だけがアップロードされる…こうしてホムペ更新作業終了…昔はこれほど簡素にできていたことが、何故技術の進んだ筈の今できないのかがとってももどかしい。

開く コメント(2)

開く トラックバック(0)

今に始まったことではなく、以前からたびたび言ってきたことである。
 
ローカル関連の記事に限定して、ブログから
ホームページへ移行することを検討している。
 
現在、このYahoo!ブログとSNS側のブログで、全く独立してローカルな記事を掲載している。どちらを選ぶかはある程度内容に依るものの、殆ど気まぐれである。換言すれば、同程度の重要性を持つ記事が2つのブログに分散してしまっているわけで、データベースという位置づけからすると明らかに不適切である。
 
だからと言って、Yahoo!ブログを畳んでSNSに限定するかとなると、そうも行かない。SNS側には限定公開の記事もあり、すべてをそちらへ移植すれば、Yahoo!ブログ限定でご覧になっていらっしゃる読者(僅少とは思うが)を無碍に斬り捨てることになる。
 
いや、実はそれ以上の問題があるのだ。
どちらか一つのブログへ統合すれば済むという問題ではない。これはブログそのものが持つ仕様に依るものであり、世に普及しているブログが今の仕様を持ち続ける限り、永遠に解決されない。
 
ホームページを一度でも運営したことのある方なら、どういう問題があるか理解して頂けるだろう。ひと言で表現すれば、ブログは
 
「継続的な閲覧を想定したコンテンツには全く不向き」
 
だからである。
 
手軽に書き始めるには、用紙からレイアウトから基本的なものが準備されているブログの方が身軽だが、継続閲覧されることを前提に記事をジャンル毎に整理保存したいなら、明らかにホームページへ軍配があがる。
 
いや、この点についてブログは全く不適格であるとすら言える。
 
この本質的な原因は、ブログの記事がすべて時系列に一元配置されてしまう仕様に基づく。すべての記事に明確な作成年月日が与えられることが災いして、古いが重要な記事でも全体の下の方に、新しいがくだらないネタでもトップに鎮座し続ける。現在のYahoo!ブログでも、たった一本の記事を指定してトップ表示させることしかできない。
 
時系列に並べられれば、過去の記事を探すのが非常に面倒である。既に2千件近い記事を書いているなら、適切な書庫へ収納されていなければ探したい情報を取り出すのは至難の業である。ジャンル毎に書庫へ整理していてもその中で一元的に配列されるのだから、記事が増えれば、極めて退屈なページ繰り作業を強要されるのは同じだ。
 
ホームページでもインデックスを作っておかなければ同じ事態になる。しかしホームページの場合、新着記事を書く都度、その記事をリストに加えるものである。すべき作業が増えるが、後から記事を探すのが容易になる。そのことは後日興味ある記事を探したい読者にとっても有益である。ブログではそれが物理的にできない。インデックスのみ収録したページもそれ自体記事だから、いずれ流れてしまう。
 
 
ブログの普及は、気軽に記事をネットへ載せようというユーザーの裾野を拡げる点では大変に貢献してきた。他方、そのせいでホームページを造る人が少なくなり、重厚で読み応えのあるサイトが激減してしまった感がある。無理もない。新着記事の読み捨てが標準仕様とならざるを得ないブログでは、特定の記事が興味を持たれ、反復して読まれる素地からして放棄している。
 
 
自分にとっての「インターネット元年」が1999年であり、ホームページという「その気になれば無料で誰でも放送局気取りに情報配信できる」ツールに大変な価値を見いだし、同年のうちに記事書きを始めた。それは(末期にはかなり放置気味だったものの)今のアジトへ引っ越し、プロバイダが変更になる去年まで10年以上維持されてきたのだった。
 
だからこそホームページのメリットを理解しているし、今改めて思うのである。
 
「もう一度、ホームページへ還りたい」
 
ネットの検索にかからず、今でも図書館や郷土資料館でしか手にし得ないローカル関連の情報をホームページで供給し、誰でもネットを通じて居ながらにしていつでも一連の情報を入手可能にすることを念頭に置いている。収録される写真や情報は、おそろしく膨大なものになるだろう。これをブログで運営しようということ自体無理がいく話だ。
 
ついでながら言えば、一般にブログはホームページに対して信頼性がないと思われている。例えば Wikipedia ではソースとしてブログからの引用を認めていない。ホームページに比べて流動的であり、誰でも短期に作成できるので、自分に都合のいいブログ記事を書いてソース参照してしまう情報誘導を避けるためであろう。
 
多くの人がブログを始めてネット上に情報を提出したために、検索では支障が出ている。学術的、専門的な情報が欲しいのに、キーワード検索で個人のどうでもいいブログばかりヒットするのを嫌悪する人は多く、検索で「ブログを除外」のオプションが付随したのもそういう背景に依るものであろう。
 
手軽に作成できることが災いし、著作権のある書物やホームページなどを丸写し、引用という名を借りたコピーも後を絶たない。アフィリエイトで小遣いを稼ぐにはアクセスアップが必須であるために、リンクの寄せ集め、内容のないワードサラダなど、業者によってヤリタイ放題されている感すらある。
 
私は、生きた人的交流を旨と成すSNSでは別として、専門的な情報探しをするに当たっては誰の何処のものであろうと、ブログは閲覧の対象外にしている。欲しい情報には殆ど行き当たらず、信頼性がない印象が強いからである。そして特に言えることは、とにかく「読みづらい」に尽きる。読むからには掲載された全部の記事を熟読したい位なのだが、ブログという仕様がそれを容易に提供しない。私のブログもそうだが、連載モノの記事などは、作成年月日の一元配列というブログ仕様が災いして、導入編などをさておいて一番重要なクライマックスが真っ先に読まれてしまう。展開も構成もあったものではない。
 
そして他ならぬ自分がその「信頼性がない」公開方法で記事を書いていること、またそうする以外に容易な選択がないブログの現状をもどかしく感じている。
 
 
将来的にその程度のものを計画しているので、基本となる各種コンテンツを保存するホームページスペース探しも注意深く行っている。ホームページ作成人口が減った今でも無料でスペースを提供してくれる運営元は、今も掃いて捨てるほど存在する。しかし予定している情報量故に、個人が片手間に自分の日常を書き留める程度の容量では全く役不足なのである。
 
バナーがページ内へ入るとか、宣伝メール受信義務が生じるなんてのは特に問題ではない。充分に膨大なものが出来上がった後で、有償で(URLは変えずに)サーバレンタルという手法に移行できる。求められている条件は、
 
(1)保存スペースが大きいこと(できれば容量無制限)
(2)掲載可能なファイル種別の制限が少ないこと
(3)FTPツールでのアップロードが可能なこと
 
である。
 
このたった3つの条件を満たしてくれるホームページスペースが存在しない。
 
例えばバナー表示の義務がありながら、収録可能容量が50MBなんてのでは全く足りない。そんなのではドキュメントしか置けない。
以前使っていたプロバイダは月々の会費を払っているのにたった20MBしか使わせてくれなかった。この程度の容量で一体何を掲載しろと言うのだろうか…
 
そもそも、ローカル探索を始めてまだ2年ながら、手元には12,000枚以上、8GBを超える画像ファイルがある。これでも重複したり不要になったものは削除している。リサイズして掲載するにせよ、上限が500MBでもいずれはパンクしてしまうだろう。
画像の保存先がパーマネントリンク形式で、外部からの参照を許してくれる無料画像置き場が使えるなら画像のみをそこへ保管できるのだが…
 
 
それから、アップロードするファイルの種別に制限が多すぎるホームページスペースも使えない。恐らく著作権のある動画や違法ツールの再配布を防ぐために拡張子を制限しているのだろうが、昔と違ってユーザーのセキュリティ意識は高まっているし、ブラウザやツールでも怪しいファイルを阻止する環境はかなり整ってきている。vbsやregなど、クリックで実行すればパソコン環境をダイナミックに変えてしまうリスクの高いものはまだしも、広いファイル種別に対応してくれていなければ、不便を感じるユーザーが出てくる。
未だにTIFFやPNGを許さないホームページスペースがあるのには呆れてしまう
 
 
ファイルは出来ればFTPツールでアップロードしたい。一旦ローカル環境で作成してそこからアップロードすれば、パソコン保存分がそのままバックアップになるし、差分アップロードツールで自動かつ安全に作業を遂行できる。
オンラインでの編集作業のみでは脆弱過ぎる。サーバ不調や停電などの些末な要因で容易に書きかけ記事が全部失われてしまう
 
 
ここまでの条件に関して一番近い位置にあると思われたのが、Microsoft の運営している "Office Live small business" である。
太っ腹なこのサイトでは、500MBの容量をドキュメントや画像用に貸し出してくれる。しかも最初の一つは独自ドメインを取得することができて、すべてが無料である。いつもはMicrosoftの提供するブラウザなど諸々のモノに批判が寄せているのだが、これは珍しくユーザー寄りのサービスを提供していると評価している。
 
ただ惜しいことに、サイトの構築方法があまり簡単ではない割には造られるものは限定されてしまう。テンプレートは準備されているものの、元がビジネス向けを志向しているせいか、それ以外の用途には使いづらい。ブログと同様にネットへ接続した状態で操作するので、ローカル側にコピーを保存できない。
 
それからしたくても実行できない操作がかなりある。例えば最も基本的と思われるフォルダの階層造りができない。
あちこち操作してみたのだが未だに新規フォルダを作成することができない
ファイル名は変えられないし、ソースを直接いじれない。何よりもFTPでアップロード出来ないのが本当に辛い。これが可能なら、ローカル側でホームページ編集ソフトでサクッと作りアップロードできるのに…
 
 
このままローカル記事を書き続ければ、いずれホームページへ移行するときの負担が増大するばかりである。早い段階で固定的なスペースを確保し、そこへガンガン記事を蓄積したい。究極にはある程度の対価を支払ってサーバレンタルし、独自ドメインもそこへ移して運営するしかないのかも知れない。

開く コメント(0)

全4ページ

[1] [2] [3] [4]

[ 前のページ ]


.


プライバシー -  利用規約 -  メディアステートメント -  ガイドライン -  順守事項 -  ご意見・ご要望 -  ヘルプ・お問い合わせ

Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

みんなの更新記事