…最近は「ウェブサイトの作られ方」なんて基本他人の関心事ではないです、にも関わらずそうした日記を大量にばーばーと書いてきていたな。反省。
最小限書いて終わりにしておくか。ここ最近のとまむさんにおける「大量にサイトを書き換えました（見た目は変わってないどな）」で「何をやったか」の一覧。
・アンテナ表示 → CSSのid名、class名の書き換え。RSSを取得する事で更新時間を取得している訳だが「twitterのRSS」も取得を行う様にした。
本格的な「ソーシャル時代への対応」。…もはや「ホームページ（笑）」、「ウェブサイト（笑）」と言う様な時代でしかない。それが現代社会。
すなわち大衆迎合ではなく部分的、そのまた別の部分的、とする様な個別的区分における利用法。それが現代社会においてのネットの変容した使用法。
だから簡単に書いてしまえば「お友達♪」、「お仲間♪」…以外の感覚はゴミでクズ。でしかないんだよね。それが現実。
但し俺はそうした感情に対して言えば「出生を受けたその刹那からお前らは友達や仲間だったのか？」と。そう言う風にして否定を行う。
だから俺はそうした概念は美しいと思うと同時に醜いとも思っている。それが現実なんで。
従って「比較」が可能な形で以て「比較の為に必要な資料は全てテーブルの上に乗せた上で論理的な解釈で以て問題点を解決していく快刀乱麻」。
それが最良に近いと思っている。しかし現代社会はtwitterの様な簡素なシステムで無いと老若男女が使えないので対応していけばいいだけの事。
・アンテナ表示 → ウェブサイトのRSSの取得は１件、twitterのRSSの取得は１アカウントにつき４件取得。その後数字は変わるかもしれないが
複数件取得すると言う概念その物は不変となっている。時間順ではなくアカウント順。アカウント登録が先に行われた方のアカウントの方がより優先され
画面の上部に更新内容が表示されていく。「基本的にはアカウント順」に並べる事とする。その方が表示も簡潔に行えスクリプトの量も小さくて済む。
・ニュース取得 → 表示件数の一部減少。
・日記表示 → CSSのid名、class名の書き換え。一部機能の名称変更、一部機能のGET引数の変更。
・競馬予想 → 「予想内容を個別化して表示する事が不可能だった内容を可能にした」事における「RSSで個別の予想を引っ張り出す事が出来る」形への変更。
回収率の計算方法のミスを修正、並びにこれまでは複勝予想だけだった回収率の表示がメインレースの予想でも出来る様になりました。
CSSのid名、class名の書き換えは勿論、そもそもCSSをどうやって組むのか？とした組み方もかなりの勢いで変えました。見た目は変わってないけどな。
・感想 → インラインフレームを止めました。CSSのid名、class名の書き換えに、CSSの組み直し。全体的にスリムになったと言う印象を俺は持っている。
・家計簿 → CSSのid名、class名の書き換え。
・資料集 → Android内蔵ブラウザはcolumn-countの表示に関してバグがある。リスト化した内容の一番最後の内容を表示しない。
リンクは正しく張られている物の、リンクを張ってるテキストが出て来ない。「テキストがありそうな部分」を長く指で押してると「新しいウインドウで開く」とする
サブメニューが登場して来るのでリンクはそこにあるんだろうなと言う事は分かるもクリックする事が出来ない。
従って、「一番最後を一番最後にしない。更に一行追加する事で一番最後を一番最後から二番目の位置に変える」事で暫定的な対処が可能。
・資料集 → 動画、音声のアップロードにも対応。実際するかどうかは知らないが。動画、音声をアップロードしてもきちんとRSSに更新情報が載る様に。
と言う風にしたRSSの出力の仕方にスクリプトを書き換えて対応。一部日付表示を変更する事で見やすくなる様にと工夫。
・位置情報 → jQueryのライブラリが数十KBあったので「Google Code」に置かれているjQueryにリンクを張る事で容量の削減と常に最新の物を使える
その２つの理由によるサイト構築の負担を軽量化する様な方向へと実行。CSSのid名、class名の書き換えにCSSの組み方の書き換え。
パソコンと同じ状態でスマートフォンで表示すると表示が崩れてしまう為、スマートフォンからのアクセスであれば１回辺りの出力件数を少なくして出力を掛ける。
これが「表示」の内容をどうやって書き換えたんですか？の一部始終となる。「PHPスクリプトの軽量化」と「CSSの書き換え」と言う２つの内容が主になる。
・「PHPスクリプトの軽量化」 → preg_matchではなくstrposとsubstrを使ってのログ取得。そうした方法に切り換える事で取得速度がこれまでの2/3の時間で
済む様になりました。特に効果を発揮したのは日記の更新。「長文過ぎる日記だとpreg_matchの記述が正しくてもログを取得する事が出来てませんでした」。
「そんな長いのかよこの日記」と自分でも思うぐらいの様相になるので内容を分割したりあるいは内容を一部削ってみたりもしておりましたが
そう言う様な事をする必要性も小さくなりました。長文日記でもきちんとログとして取得する事が出来るのでオンライン上での修正も可能となりました。
・「PHPスクリプトの軽量化」 → arrayで配列に入れて配列を処理〜ではなく、fgetsで１行ずつログを取得して表示する事での加工が可能。
とする様な所では積極的に「配列を使わない」やり方へと変更を掛けました。これによりスクリプトの記述量が小さくなったのでメンテナンス性も高くなりました。
・「CSSの書き換え」 → 過去の日記でも何度か書いた「クロスブラウザへの対応」。すなわちheightを数値で指定してしまうとそれが絶対となってしまって
例えば13pxのフォントサイズで表示すると言うのであればそのheightの数値でもフィットするんだろうが10pxのフォントサイズで表示すると言うのであれば
そのheightは高すぎる数字になってしまうだろ？と言う様なアンバランスさを消す為にheightの数値の指定ではなくフォントサイズを基準とした指定に変更。
marginあるいはpaddingを使う事で「文字の大きさが小さくなる様なスマートフォンでの表示」もしくは「大きい文字で見ているパソコンでの表示」を行っても
そんなに大きく崩れない表示を実現する事が出来る様になりました、とする様な「他の環境」、「他のブラウザ」でもそれなりに表示される様な内容への書き換え。
・「CSSの書き換え」 → 高さや幅の数字は基本指定しないも、指定する必要がある場合、例えばtextareaの大きさなどに対する指定はパーセンテージを使う。
つまり「横幅ほにゃららpx」ではなく「横幅ほにゃららパーセント」とする様な指定へと変更。そうした内容に規則性を持たせてCSSのclass名を使って処理。
例えばclass名が「yoko1（横１）」だったらwidthは１００パーセントと指定しましょうね♪と言う様なやり方でテキストエリアの横幅を指定して表示する。
文字列はmarginもしくはpaddingを使い、背景やテキストエリアなどのwidthやheightはパーセンテージの相対化された概念の数字を使って表示する書き換え。
・「CSSの書き換え」 → たまに現れるここはどうしても数値で指定した方が都合がいい、とする幅もしくは高さの指定。その際にはフォントサイズを表す
数字を使って「フォントサイズを表す数字掛ける特定の数字」とした内容をPHPの内部で計算して出力させる事で指定しておく事にする。そうした書き換え行為。
こうした展開を全体の中の殆どの作業として行い、CSSとPHPの内容がより痩身化した。と言うのがここ最近行っていた「クロスブラウザ」への対応行為。
あとはおまけとして「本来自分の中ではInternet Explorerは使えないブラウザ」とは思っているんだが、それでもそれを使っていると言う連中は結構多い。
例えば一見出来そうなサラリーマンが外食チェーンのお店でノートパソコンを広げてInternet Explorerを使っていたりとかな。それを見た瞬間に「えっ」と思うよ。
基本「対応しない方が無難ではあるんだが、それでも「それなりに」見られる様にと対処しておいた方がいいね。「全く見られない」よりはマシだからな。
と言う意識で以ておまけとして対応致しました。これで表示も更新も閲覧も、それから現代社会のネットの使われ方への対応も、可能な物となりました。以上。