2007年12月の記事
2007 12/17 11:01
Category : eclat情報
サーバが突如繋がらない状態になっておりました。申し訳ありません。
ホスティング会社に再起動依頼をし、復旧しましたが、原因は現在さだかではありません。
純粋にサーバの機械がどうかしたのかもしれませんが、しかしフリーズというわけでもなく、pingは帰ってくるという状況で。
サーバ自体は問題無いですが、ホスティング会社側でのネットワーク機器の障害だったのかもしれません。
ホスティング会社からは「繋がらないことを確認しましたので再起動しますのでお待ちください」と連絡あっただけでして
原因は分からず仕舞いです。
とりあえず復旧したので、恐らく原因は分からないとは思いますが、
今回の障害でなにか影響が出てないかも含め、いろいろサーバのチェックを本日しておきます。
ホスティング会社に再起動依頼をし、復旧しましたが、原因は現在さだかではありません。
純粋にサーバの機械がどうかしたのかもしれませんが、しかしフリーズというわけでもなく、pingは帰ってくるという状況で。
サーバ自体は問題無いですが、ホスティング会社側でのネットワーク機器の障害だったのかもしれません。
ホスティング会社からは「繋がらないことを確認しましたので再起動しますのでお待ちください」と連絡あっただけでして
原因は分からず仕舞いです。
とりあえず復旧したので、恐らく原因は分からないとは思いますが、
今回の障害でなにか影響が出てないかも含め、いろいろサーバのチェックを本日しておきます。
2007 12/12 16:00
Category : 与太話
GaiaXのeclatコミュニティが契約打ち切りになる発端は
あのアバターのCafestaっぽい新GaiaXです。
あれを新たにはじめるにあたって
GaiaX社の自社ブランドで展開するので旧版を閉鎖することになり、各サイトは閉鎖になりました。
契約の関係でいくつかのコミュニティは閉鎖時期が変わりましたが(契約時期等によってかなり条件いろいろあると聞いています)、
エクラ様から引き継ぐ際にいろいろ聞いておりましたし、
いずれ終わるだろうことは分かっていました。
しかし新GaiaXがこんなに早くに終了するとは思いもよりませんでした。
恐らく以前より大幅に負荷のかかる大掛かりな作りになったこともあり、維持費がかさんだのだろうと思います。
開発費も随分かかってるでしょうに、費用回収できないまま撤退でしょう。よっぽど収益がアレなんだろうな…と想像します。
(うちも開発費回収とか縁遠いですが、そのかわり小さく運営して、さらに手弁当なので会社的に損失が出るようなこともないです。本当に開発やサポートに時間かけるならば費用対効果は見込まなければ倒産しますが)
さて、新GaiaXですが、ログ移行を呼びかけておいて、こんなに早く潰れたら辛いですよね、と思っていたら
ログのダウンロード機能を付けたそうで。
舶来Blogシステムの定番MovableType(以下MT)のログ形式で吐くそうです。
MT形式ログは、MT以外のBlogシステムでもインポートできたりして最近では半ばBlogの共通形式のようになっている部分もありますから良い選択に思います。
3年前の段階ではMT形式ログで残すのは先走りすぎでしたが、現在なら、うちの閉鎖時のログ提供もMT形式を用いるというのはアリかもしれないなと思いました。
MT形式で提供したほうが再利用はしやすいよね、時間あったらそういうの作ればいいんだけどね…と先日社内で話ましたが、いつできるかは名言できません…
(逆にMT形式を持ってこれるというのもおもしろいかもしれませんが)
あのアバターのCafestaっぽい新GaiaXです。
あれを新たにはじめるにあたって
GaiaX社の自社ブランドで展開するので旧版を閉鎖することになり、各サイトは閉鎖になりました。
契約の関係でいくつかのコミュニティは閉鎖時期が変わりましたが(契約時期等によってかなり条件いろいろあると聞いています)、
エクラ様から引き継ぐ際にいろいろ聞いておりましたし、
いずれ終わるだろうことは分かっていました。
しかし新GaiaXがこんなに早くに終了するとは思いもよりませんでした。
恐らく以前より大幅に負荷のかかる大掛かりな作りになったこともあり、維持費がかさんだのだろうと思います。
開発費も随分かかってるでしょうに、費用回収できないまま撤退でしょう。よっぽど収益がアレなんだろうな…と想像します。
(うちも開発費回収とか縁遠いですが、そのかわり小さく運営して、さらに手弁当なので会社的に損失が出るようなこともないです。本当に開発やサポートに時間かけるならば費用対効果は見込まなければ倒産しますが)
さて、新GaiaXですが、ログ移行を呼びかけておいて、こんなに早く潰れたら辛いですよね、と思っていたら
ログのダウンロード機能を付けたそうで。
舶来Blogシステムの定番MovableType(以下MT)のログ形式で吐くそうです。
MT形式ログは、MT以外のBlogシステムでもインポートできたりして最近では半ばBlogの共通形式のようになっている部分もありますから良い選択に思います。
3年前の段階ではMT形式ログで残すのは先走りすぎでしたが、現在なら、うちの閉鎖時のログ提供もMT形式を用いるというのはアリかもしれないなと思いました。
MT形式で提供したほうが再利用はしやすいよね、時間あったらそういうの作ればいいんだけどね…と先日社内で話ましたが、いつできるかは名言できません…
(逆にMT形式を持ってこれるというのもおもしろいかもしれませんが)
2007 12/12 15:31
Category : 与太話
まともにサポート業務に費やす時間が取れず放置状態になってしまっておりますが
ユーザーの方同士の情報交換でノウハウを共有いただいているようでありがたいかぎりです。
ちらほらを見させていただいております。
さて、なにやらサーバが重い、メニューが重い、外部コンテンツをフレームに入れないほうがいいといった情報があるようですが、
恐らくそれはサーバとは無関係です。
外部コンテンツを、ブラウザの別ウインドウに表示しようが、フレームに表示しようが、それはブラウザのレンダリング処理にそう関係するとは思えませんし
サーバ側はテキストファイルをクライアントPCに送るだけですのでもちろんもっと無関係です。
target指定はフレーム内リンクにしてまったく問題ありません。
問題あるとすれば別の部分にあると思います。
メニューはカスタマイズ可能とはいえ、原則はCSSでデザインは分離していますし、シンプルなHTMLの送信にすぎませんから、本来そう重い処理になるとは思えません。
考えられる可能性として以下が思いつきました。
1)単純にサーバーが古い
確かに契約から3年が過ぎたサーバですから、この業界3年も経てば陳腐化する部分はあります。(入れ替えは検討中です)
ですがもっと経年使用しているサービスも世の中あろうかと思いますし、そこまでそれが大きくでるかというと疑問です。
メニューだけが重いという話ではおかしい気も。
2)メニューの中味が重い
メニューのHTML自体は本来単純で、送信する文字数などしれていますが
カウンターやアクセス解析など外部サービスを埋め込んでいる場合、そちらが重ければひっぱられると思います。
またHTMLの書き方も重くなる書き方と軽くなる書き方はあるでしょう。
シンプルなHTMLでCSSで色づけといった今風な書き方ですと相当軽くなるはずですが、標準のメニューを全消しで
全てレガシーなHTMLで自前で書く場合その記述に依存します。
それと気付いた点では、bodyタグが二重になっていたり、閉じタグが無かったりといった文法エラーがよく見られます。それらはブラウザの解釈に時間がかかる元ですので、文法ミスのチェックなども必要かもしれません。
3)移行処理等が負荷になっている
これは確実に現在あります。旧GaiaXからの移行処理や、閉鎖に伴うログのアーカイブ化などはサーバにとって重い処理です。
手元のPCで大量のテキストファイルをダウンロードしたり、LHAで圧縮したりする処理を考えてもらえば分かりやすいかもしれません。
当然そういった処理がちょうど裏で回っている時間帯に行った処理は重たく感じることもあるかと思います。
それがたまたまメニュー操作時であったということはありうるかもしれません。
これは当面落ち着くまでは仕方ないかなと。登録だ削除だ再登録だとみなさんやりまくってますので…
…というわけで、私の感覚では、やはり(3)がありそうかなと。
時々重いということ自体は(3)の理由により多かれ少なかれあるとは思います。
それに(2)が加わっているサイトもあり、いろいろ憶測が出るのだろうという見解です。
個人的にはフレーム内にtarget指定して何ら問題ありませんので、そのほうがよければしていただければと思います。
GaiaXのような１つのサイトとしてのまとまりを考えると、リンク集になってしまうとあまりフレームの意味が無い気もしますし…
私どもとしてはどちらでもサーバに別段負荷とかありませんのでかまいませんし
それによって重くなるとも考えにくいため(重くなるとすれば別の理由でしょう)
使いやすい方法を選んでいただければと思います。
ユーザーの方同士の情報交換でノウハウを共有いただいているようでありがたいかぎりです。
ちらほらを見させていただいております。
さて、なにやらサーバが重い、メニューが重い、外部コンテンツをフレームに入れないほうがいいといった情報があるようですが、
恐らくそれはサーバとは無関係です。
外部コンテンツを、ブラウザの別ウインドウに表示しようが、フレームに表示しようが、それはブラウザのレンダリング処理にそう関係するとは思えませんし
サーバ側はテキストファイルをクライアントPCに送るだけですのでもちろんもっと無関係です。
target指定はフレーム内リンクにしてまったく問題ありません。
問題あるとすれば別の部分にあると思います。
メニューはカスタマイズ可能とはいえ、原則はCSSでデザインは分離していますし、シンプルなHTMLの送信にすぎませんから、本来そう重い処理になるとは思えません。
考えられる可能性として以下が思いつきました。
1)単純にサーバーが古い
確かに契約から3年が過ぎたサーバですから、この業界3年も経てば陳腐化する部分はあります。(入れ替えは検討中です)
ですがもっと経年使用しているサービスも世の中あろうかと思いますし、そこまでそれが大きくでるかというと疑問です。
メニューだけが重いという話ではおかしい気も。
2)メニューの中味が重い
メニューのHTML自体は本来単純で、送信する文字数などしれていますが
カウンターやアクセス解析など外部サービスを埋め込んでいる場合、そちらが重ければひっぱられると思います。
またHTMLの書き方も重くなる書き方と軽くなる書き方はあるでしょう。
シンプルなHTMLでCSSで色づけといった今風な書き方ですと相当軽くなるはずですが、標準のメニューを全消しで
全てレガシーなHTMLで自前で書く場合その記述に依存します。
それと気付いた点では、bodyタグが二重になっていたり、閉じタグが無かったりといった文法エラーがよく見られます。それらはブラウザの解釈に時間がかかる元ですので、文法ミスのチェックなども必要かもしれません。
3)移行処理等が負荷になっている
これは確実に現在あります。旧GaiaXからの移行処理や、閉鎖に伴うログのアーカイブ化などはサーバにとって重い処理です。
手元のPCで大量のテキストファイルをダウンロードしたり、LHAで圧縮したりする処理を考えてもらえば分かりやすいかもしれません。
当然そういった処理がちょうど裏で回っている時間帯に行った処理は重たく感じることもあるかと思います。
それがたまたまメニュー操作時であったということはありうるかもしれません。
これは当面落ち着くまでは仕方ないかなと。登録だ削除だ再登録だとみなさんやりまくってますので…
…というわけで、私の感覚では、やはり(3)がありそうかなと。
時々重いということ自体は(3)の理由により多かれ少なかれあるとは思います。
それに(2)が加わっているサイトもあり、いろいろ憶測が出るのだろうという見解です。
個人的にはフレーム内にtarget指定して何ら問題ありませんので、そのほうがよければしていただければと思います。
GaiaXのような１つのサイトとしてのまとまりを考えると、リンク集になってしまうとあまりフレームの意味が無い気もしますし…
私どもとしてはどちらでもサーバに別段負荷とかありませんのでかまいませんし
それによって重くなるとも考えにくいため(重くなるとすれば別の理由でしょう)
使いやすい方法を選んでいただければと思います。
2007 12/12 14:48
Category : eclat情報
Goo簡単HP及び、GaiaX社の完全撤退のため、eclatへの移行が最近急に多いようです。
全くフォローできず申し訳ありません。
さて、そのせいか最近よく相談メールをいただく内容で、
メニューなどの編集ボタンが消えてしまったというものがあります。
eclatのメニューでは
<html>
<body>
（編集可能域）
編集メニュー
</body>
</html>
という構成になっており、編集可能域はページの一部で
編集ボタンなどは触れない仕様になっております。
ですが、範囲外に影響を及ぼすようなタグやCSS設定によって編集域の外も消す(正確に言えばHTML的にはあるけれど隠す)ようなことも可能なようです。
修正をここ数日で対応しましたが、特に<noembed>タグを開きっぱなしで書いて、編集ボタンが消えるとい不具合が多く見られました。
<noembed>タグとは、MIDIファイルなどプラグインで読み込むコンテンツにつかう<emded>タグの関連タグで、
プラグインが無い場合に代替で表示する内容を<noembed>～</noembed>内に記述するものです。
ですが本来あるはずの閉じタグが無いかたちで、<noembed>だけが意味も無くあり、
それ以後が全て<noembed>の内容とブラウザが判断しているようです。
当然これは普段は表示されず、プラグインコンテンツの代替で表示される特別なものですから、表示が出ません。
そういう内容のトラブルです。
どうも調べますと、広告の入る無料サーバで下部の広告を消すテクニックとして<noembed>開きっぱなしというものがあるようです。
これをそのまま持ってきてしまい、消えてるようです。
これは広告だけを消すのではなく、<nodmbed>以下を全て通常表示しない部分と誤認識させて、表示を隠すという裏技ですから、編集ボタンだろうとログインリンクだろうと全て消してしまいます。
現在eclatには広告はありませんから全く無意味と言えます。
また他社の無料サービスでも、このような規約違反をやってまで広告を消す意味があるのだろうか？と疑問です。
発覚し次第アカウント削除のリスクを負ってまでやることだろうかと思います。
HTMLパズルとしては面白いとは思いますが、まともに運用する気のサイトでやることは私はお奨めしません。
全くフォローできず申し訳ありません。
さて、そのせいか最近よく相談メールをいただく内容で、
メニューなどの編集ボタンが消えてしまったというものがあります。
eclatのメニューでは
<html>
<body>
（編集可能域）
編集メニュー
</body>
</html>
という構成になっており、編集可能域はページの一部で
編集ボタンなどは触れない仕様になっております。
ですが、範囲外に影響を及ぼすようなタグやCSS設定によって編集域の外も消す(正確に言えばHTML的にはあるけれど隠す)ようなことも可能なようです。
修正をここ数日で対応しましたが、特に<noembed>タグを開きっぱなしで書いて、編集ボタンが消えるとい不具合が多く見られました。
<noembed>タグとは、MIDIファイルなどプラグインで読み込むコンテンツにつかう<emded>タグの関連タグで、
プラグインが無い場合に代替で表示する内容を<noembed>～</noembed>内に記述するものです。
ですが本来あるはずの閉じタグが無いかたちで、<noembed>だけが意味も無くあり、
それ以後が全て<noembed>の内容とブラウザが判断しているようです。
当然これは普段は表示されず、プラグインコンテンツの代替で表示される特別なものですから、表示が出ません。
そういう内容のトラブルです。
どうも調べますと、広告の入る無料サーバで下部の広告を消すテクニックとして<noembed>開きっぱなしというものがあるようです。
これをそのまま持ってきてしまい、消えてるようです。
これは広告だけを消すのではなく、<nodmbed>以下を全て通常表示しない部分と誤認識させて、表示を隠すという裏技ですから、編集ボタンだろうとログインリンクだろうと全て消してしまいます。
現在eclatには広告はありませんから全く無意味と言えます。
また他社の無料サービスでも、このような規約違反をやってまで広告を消す意味があるのだろうか？と疑問です。
発覚し次第アカウント削除のリスクを負ってまでやることだろうかと思います。
HTMLパズルとしては面白いとは思いますが、まともに運用する気のサイトでやることは私はお奨めしません。