foreigner.blog.so-net.ne.jp

新しい記事に付いて行けていませんが，こちらの48x48画像というのは，自記事の画像をすべて外部から参照した際の管理画面の記事アイコンの空白を避けるため，それ用の必要最小画像（ソネブロサーバー必要最低使用）を，見えなくして貼付けておくという理解でよかったですね。

追記です。その画像の埋め込みに時間が掛かっているのだとすると，そこを空白のままにしておくが一番スムーズなのではないかなと思うのですが，むしろこれはソネブロサーバー画像を沢山付けた際，その処理時間が飛躍的に向上するという理解でよろしいですね。

Enrique さん、こんにちは。　２つのコメントに対して１つにまとめてみます。 わたしは昨年の２月より利用を開始し、様々な「躓き」を経験し、最初は「自分が悪いのだ」と思いながら、後戻りを繰り返し、そんな無駄な経験でも経験値が「実証実験」の背中を押し、実験の結果から類推を重ねてきました。
＞ 管理画面の記事アイコンの空白を避けるため
　これは自分だけの「記事アイコン」では無いのですね。 記事を新規に投稿する時も、再度保存する時も、「共通テーマ」を決めることが可能であって、その「共通テーマ」の「新着」に掲載され、nice!を１つでも戴くと「nice!記事」の最新・デイリーに掲載されますが、そこでの記事アイコンとなります。 故意に「NO IMAGE」を狙うのなら構いませんが、やっぱり「プリティー」な、つまり48x48ピクセルでも「目を引く」表現力は利用しないよりは利用した方が良いだろうと言う事です。 折角の記事が内容が濃いわけで、それでも「あらっ！可愛い」であったとしても、例え１人の方でも訪問して下さるのは貴重なことですので、より芸術的な記事アイコンの表現は無駄では無いだろうと言う立場です。（微笑）
＞ 見えなくして貼付けておく
　トップページなど「アーカイブ」や個別記事の先頭に小さ過ぎる48x48画像を表示しても「美しい」のであれば隠す必要はありません。 わたしの場合は独自デザインを決めており、48x48画像を無用だと決めていますので、48x48画像領域をゼロにして「人間には見えない画像」にしております。　あらゆるカラクリで、絶対座標値を-10000,-10000に画像を表示させ、待機させる利用もございます。 人間にとって「見えない工夫」は決してエラーではありません。 必要なのは、So-netブログで「保存」ボタンを押した時に、So-net側が文中のHTMLを順番に読みながら最初に出現するSo-netアップローダーで扱った画像から記事アイコンを毎回生成させていると言うことです。 ですから文中の先頭にSo-netアップローダーで扱った48x48ピクセル画像を配置しないと無効となります。
＞ そこを空白のままにしておくが一番スムーズなのではないか
　管理画面の「設定」⇒ 「基本設定」、「画像の初期設定」内の「サムネイル」を試しに「１」にセットしたところ、記事アイコン画像は１ｘ１のまま採用されました。 つまりSo-netアップロードした時にサムネイル画像にダウンサイジング処理をされるが、記事を「保存」によって受領処理される時にはサムネイル画像から48x48画像を毎回作成している模様です。 「NO IMAGE」のままで、わたしも運用を続けてきました。 理屈を理解していなかったからです。 「どうしたら記事アイコンが出るのだろう・・・・？」と疑問でした。 「外部の画像サーバー（他社ブログ・フリッカーなどなど）の引用だと記事アイコンは付かない」がSo-netブログのポリシーです。 「同じオーナーの他の４つのSo-netブログのアップローダーで扱った画像でも記事アイコンは付かない」がSo-netブログのポリシーです。
　確かに、GoogleやYahoo!など検索サイトからの訪問者にのみ重きを置き、So-netブログの http://blog.so-net.ne.jp/ 辺りからの訪問者を「気にしない」のであれば、記事アイコンが「NO IMAGE」でも良いと言う結論も、ある意味、良いかと存じますが、「１つの記事に対する思い入れ」を考えますと、48x48ピクセルのJPEG/PNG/GIFと言う正方形の画像としては極小なデーターを用意して配置すれば、以後、勝手に記事アイコンを掲載してくれるのですから、便利なものと考えられるのなら利用するのが So-net流と存じます。
＞ むしろこれは・・・処理時間が飛躍的に向上する
　何度も読んだのですが、理解力がありません。 記事の先頭から最初にSo-netブログサーバー側が遭遇するSo-netアップローダーで扱った画像を発見した場合に「記事アイコンを自動生成するプロセスが発動される」と言うことです。 探すのにコンピューターが「もたもた」しているとは考えられず、仮に全ての画像がフリッカー利用だったとしても遅くなるとは思えません。 最初に出現するSo-netアップローダーで配置した画像のサムネイル容量が大きいと、極端に待たされたり、最悪は広告付きのエラー画面で落胆します。 最初にSo-netブログサーバーが遭遇するSo-netアップローダーで扱った１枚目の画像のサムネイル画像の容量に注目するべきかと存じます。 実は、管理画面の「記事管理」⇒ 「ファイル管理」で、個別に画像のサムネイルを小さくできるのですが、そこで記事に現れる最初の画像のサムネイルサイズを都度小さくしてから「保存」投稿し、必要ならサムネイルサイズを元に戻す・・・・なんて技は、「痴呆」老人には不可能です（爆笑） 返答になったでしょうか？みなさん

> 処理時間が飛躍的に向上する
　「個人プレー」の限りにおいては効果は出難いと存じます。 ブログのシステムを改良しないと無理かと存じます。 特に毎日「新規投稿」をSo-netブログのアップローダーを利用したサムネイルサイズも小さくない設定で、どんどん決まった時刻に投稿する方々が、全員が48x48ピクセル画像の運用を、全員が実施すれば「劇的」なる効果は出るかも知れませんが、それを強要するのは不可能ですし・・・・・
　何か判り易い例え話を考えました。 スーパーのレジに、ある日、お客全員がキャッシュ１万円札しか持参しなかったなら、レジがストップするのと似ているかも知れません。 床屋に行くと「いつもの様に待ち客がいる」ものの、その日に限って全員がパンチパーマを希望したら、待てど暮らせど自分の順番にはならない。 So-netブログサーバーも軽い時がございます。 きっと利用者の特に「保存」ボタンを押す絶対数が少ない時間帯なのでしょう。 そして重くてエラーとなる時間帯とは「保存」ボタンを押す絶対量が多くて、処理に対する待ち行列が多過ぎる状態なのでしょう。 いわゆる「パンク」状態。
　「遅くする原因の１つです」と、ご案内しました通り、他にもございますが、こと記事アイコン画像の生成については、各オーナーのブラウザーを待たせないで、処理の計画行列に加えるだけにして遅延してでも後処理のバッチ処理とするか、それとも最初から記事投稿画面で対話式に「48x48記事アイコン画像の登録」メニューを配置すれば、問題の１つは解決します。 どうやら利用者数が増えた割には、利用者数に対処できるパワーと、システム設計の見直しはされていないのでしょうか。 GoogleもYahoo!も最初から利用者数目標値が高く設定され、「無料ですけど遅くも無い」インターネット・スペースを与えてくれますが、So-netブログは、今後、どうなるのでしょう？

朝の寝ぼけ眼のコメント入れで，言葉足らずおよび選択の不適切があったようです。ご当惑と余分のお時間おかけした様です。
二つ目コメントの訂正です。「貼付け」に時間が掛かるのではなくて，So-netサーバー側の画像の読み込みやらサムネイル画像への変換加工処理に時間が掛かっている模様なので，処理がラクそうな最小画像を食わせてやって少しでも快適かつ素敵に使いこなしたいと，そのための様々な技の公開ですね。分かっているつもりでしたが，うまく言葉になっていませんでした。
以前の記事でのご指摘で，この画像の埋め込みをしておりましたが，だんだんめんどうになって来て（さしたる手間でもないのですが），nice記事ランクに載る事も余り無いので，自分の自らの管理画面内だけのことならまあ良いかと，空白画面のままで投稿しておりました。私の場合，記事内容が薄いのか，nice数が少ないからなのか，たまたま混まない時間帯なのか，予約投稿併用だからなのか，一時期感じたストレスはこの頃なく，ひょっとしてソネブロシステムが改善されたのか！？などと思っていました。必殺ボタンも滅多に押す必要がありません（２，３日前nice数が合わなかったので，何ヶ月ぶりかでボタン押下しました）。
そんな事で，御記事の生まれた背景を慮る事もしないまま，お気軽コメントをしてしまいました。

Enrique さん、こんにちは。
＞ 必殺ボタン
　済みません！ 過去記事の呪縛の犠牲者ですか・・・・ 済みませんっ！ 後述しますが「どうしたら過去記事の nice! もコメントもキープしたままに共通テーマで新記事」扱いされるのかの実験として、最初に必殺ボタンを押してから再保存してみたり、再保存してから必殺ボタンを押してみたり、前後で必殺ボタンを押してみたりと・・・・ 実験検証を繰り返す日々です。（大笑）
＞ ご当惑と余分のお時間
　全然、結構なことです。 自分が自分で考えて「言葉」にして自分が投稿する記事が「どれだけ不完全」であるかを知り得ますが、もうこの年ですから（笑） 精度の良い記事を書けないなと諦めておりますが、だからと言って投稿のボリュームを落とそうとは思いません。 まあ~作家だと「売れない」訳で生活苦となって困りますが、無料のブログシステムに、無報酬で投稿するのですから、これからも自由気ままに「徒然」なる「何なのココは？」で通そうと存じます。 毎朝、「今日も起きた」不思議を噛み締めながら、尊厳が続く以上は「脳内神経網」の限りを尽くそうと存じます。（笑）
＞ だんだんめんどうになって
　非常に理解できます。 そこで本文記事を推敲し以下の文言を追記しました。 － わたしは記事アイコン画像にだけ利用するのでは「もったいないっ！」（笑）ので、記事内の装飾に利用しています。 － ※ 「記事毎に48x48ピクセル極小画像が必要！」と決めてしまうと、苦しくなります。（笑） わたしの場合は「シリーズもの」で流用しています。 －
　音源再生記事の場合の記事アイコンとか、バロック時代の記事アイコンとか・・・・・記事カテゴリーと言いましょうか、シリーズ毎に決まった記事アイコンを毎度埋め込むことにすれば、少し楽な気持ちになれるのかも知れません。
　わたしには「So-netブログのカラクリ」において摩訶不思議な現象がございます。 nice!数が「ゼロ」であるのに、恥ずかしげも無く共有テーマのnice!レポートページに出現する手合いです。 「枯れ木も・・・」でしかない情報をSo-net側は採用するのですが、これはブログシステム初期の時代のインパクトであって、システム・フラグで制御している筈です。 もう、これだけオーナー数が増えたのですから、nice!数が「ゼロ」であるレポートを共有テーマに掲載しないのがスマートです。 そすれば、本当に枯れつつあるテーマが明確になります。 テーマ編成替えのチャンスでありますが、放置しかしないのは衰退したローマ帝国と同じであって、いつしかブログは化石・遺跡となります。 それでも、共通テーマの新記事に載る場合と載らない場合の違いが理解できず、判明するものなら手順を公開したいと画策中です（大笑） 中には内容もタイトルも同じなのに、新記事として上げているオーナーだったなら、人間として「新たな作品を書けよ！」と頭を強打して足を踏み付けながら罵倒したくなります。

　さて、月日は光陰の如く過ぎ去りますが、過去記事を「再保存」してみるのは無駄では無いのかも知れません。 わたしはHTMLタグの noscript ~ /noscript を記事の本当の先頭に入れて、RSS専用の記事内容のエッセンスを書き入れるように自分独自の標準フォーマットにしております。 そして、noscript ~ /noscript 直後に、表示させない48x48画像を書き入れて、そこからjavascript呼び出しによる軽減策を取る様に変更しています。 また、「再保存」のインパクトにと、48x48画像の直後に、So-netブログのアニメーションGIFを入れたり、入れ換えたりを行います。 新記事に登録されればと願いながらジタバタ致しております。 これって「暇人」だからこそ出来る「無駄通信」であるのかも知れません。 言える事は「不断の努力」が必要かなと言う事ですね。 「遊び心」を持てるか持てないかかも知れませんし、「コスト意識」を持ってしまうと・・・・何もかもが「くだらない」と感じるのかも知れません。 個人が何を実行するのかは、個人だけが知り得る「秘密の花園」と言えるのかも知れません。 わたしは「サイフォンコーヒー」を淹れるにも極意を見出しており、パイプで煙を燻らせる折にも極意を熟考している変人でありまする。 お気遣いには及びません。 これからも宜しくお願い致します。