HTMLとGitHub Copilot
HTML
以前修正したHTMLと、あの後もちまちま作業してたHTML、順次アップ中。
エラーが起こらないかどうかと、デザイン崩れの目視確認もしながらなんで、あんまり進んではないです。
GitHub Copilot
GitHub Copilotちょっとお試し中。
コミットメッセージ生成が便利かなと思ったけど、何でもかんでも「読みやすさのためのリファクタリング」扱いしてくる印象。
以前修正したHTMLと、あの後もちまちま作業してたHTML、順次アップ中。
エラーが起こらないかどうかと、デザイン崩れの目視確認もしながらなんで、あんまり進んではないです。
GitHub Copilotちょっとお試し中。
コミットメッセージ生成が便利かなと思ったけど、何でもかんでも「読みやすさのためのリファクタリング」扱いしてくる印象。
アンパンマンの状態いろいろから転記。
今日はひとまずこのひとつだけだけど、変身パターンとかも含めて、この手の記事も増やしていきたいですね。
アンパンマンDBに限っての話ではないのですが、アクセス統計が6月ごろから全然更新されていませんでした。
まあ、一般ユーザーにもわかる範囲だと結局アンパンマンDBだけではあるのですが。
修正したんで、明日から最近のTOP10とかが動き出すかと思います。
動かなかったらまた調べます。
同じ意図のコードなのに変数名が全然統一されてなくてコピペでコードが動かないことが多かったので、ばらばらな変数名を統一する作業をしていました。
もちろん、全部の変数は無茶なので、よく使う型の変数に限ってですが。
それでも数百ファイルはいじったかも。
HTML修正中。
Lintかけたら「align使うな」が山ほど出てきてる。
自動テスト方面で出た問題、解決しました。
最初に作ったオブジェクトを次々受け渡していかなきゃいけないんだけど、途中で断絶しちゃっていたんですよね。
本番環境では、断絶しても最終的にデフォルト設定で再生成するから問題にはならないんですが、テストでは、テストケースごとに別オブジェクトを作るのでデフォルト設定じゃダメだったのです。
うーん、オブジェクトオブジェクト言ってても説明になってない気がするのでもうちょっと具体的に言うと、データベース接続オブジェクト(以下、DBO)です。
表示ロジックでは、表示に必要なデータはそろっている前提なので、余計なことをできないように、DBOを渡さないようにしています。
しかし、表示ロジックの最後の最後で、画像タグや記事間リンクなどのリンク処理を行うため、DBOが必要になります。
本番環境では、本番データベース以外に繋がないので、DBOをいくつデフォルト設定で再生成しても問題ありません。
テスト環境では、デフォルト設定でもテスト用データベースに繋がるのですが、テストケースごとに別々の条件に分けたいので、データベースもテストケースごとに作っています。
ここで断絶が起こると、途中までテストケースごとのデータベースだったのが、最後にいきなりテスト環境の共用データベースに繋がることになります。
最初と最後で別々のデータベースに繋がるので、テストが動かなくなるというわけです。
解決には、表示ロジックにDBOを渡さないようにしつつ、リンク処理ではDBOを使えるようにする必要があります。
このため、表示ロジック呼び出し側が、リンク処理を司るオブジェクトに適切なDBOを持たせ、表示ロジックにはリンク処理オブジェクトのほうを渡すようにしました。
リンク処理オブジェクトからDBOを取り出すことはできないので表示ロジックが悪さをすることはできません。
一方、リンク処理オブジェクトは適切なDBOを自分で持っているので、あるべきデータベースを使ってリンク処理を行うことができるというわけです。
中身HTML4.01のガワLiving StandardのページをちゃんとしたLiving Standardにするやつ、途中まで作業したやつを途中までアップしてます。
目次自動生成システムを成立させるために、<a name=~>を<h2 id=~>に変更するのを優先的に作業しています。
h3タグを使うと目次の階層化とかもできるようにはなっているのですが、そこまで対応しているとしんどいので、ひとまずはh2まで。
他には、属性をクォートで囲ってないのとか、タグ自体が廃止されたのを別のタグに置き換えるのとかもやってます。
サーバーサイドでの自動生成の目次の仕組みを作って、各ページに適用中。
うちのサイトって、昔はいろんなページに自動生成の目次がありました。
ただ、それはInternet Explorer、それも古いバージョン専用だったので、もう動いてなかったんですよね。
静的HTMLファイルに労せず目次を取り付けたいという動機でJavaScriptを使ったのですが、動かなきゃ世話ないですね。
私の思想として、サイトの基本的な機能はなるべくJavaScript抜きでも動作するようにしたいというのがあり、この思想にも反する仕組みでした。
一方で、URL上は.html拡張子に見えるファイルは、現在は大部分をHTMLファイルに見せかけたPHPファイルを裏で動かしています。
詳しく言うと、ただのHTMLファイルに見せかけたPHPファイルが出力したただのHTMLファイルを最終的に表示しているのですが、とにかくサーバー側でいったん動的な処理を挟んでいるわけです。
この動的な処理の部分に目次自動生成を差し込めば、JavaScriptに頼らず、ブラウザに依存せず、それでいて労せず目次を作れるのです。
今のところ、自動生成の仕組みはできたので、今は各ページに適用するのを頑張っているところです。
先ほどまで自動化だの労せずだの言っていましたが、目次以前にまずHTMLそのものを修正しないといけないのです。
PHPを使う仕組みに切り替えた時点から、HTMLも4.01から5をすっ飛ばしてLiving Standardに切り替えているのです。
…切り替わってないのです!
PHPに切り替えた時点で、自動生成のヘッダとフッタにより、ガワだけはLiving Standardになりましたが、中身はほとんど手付かず。
4.01のままのHTMLからじゃ、Living Standard用のシステムで目次を自動生成はできないのです。
ブラウザはだましだまし動いてくれますが、ブラウザほど気を利かせてない自作システムは、だませないのです。
ということで、労せず目次を自動生成するために、現在、労しています。
セキュリティ診断かけてみたら、X-Content-Type-OptionsとX-Frame-Optionsに不備があるって言われたんで、わかる範囲でつけておきました。
ここtgws.plusドメインは過去に対応済みだったので、それ以外の、dq10player.eventsとか、andraw.uvs.jpとか、そのあたりですね。
ほかに、「Permissions-Policy "interest-cohort=()"」も付けたんですが、今もこれが必要かどうかはよくわかっていません。
昨日のポジ不死さんもその一環だったんですが、アキヤメ中心に、サイト内で一貫性がない部分を修正していました。
今日のところは、レゴのページなど、文字コードがShift_JISになっている部分をUTF-8に変換する作業を主に行いました。
あと、すぐできる範囲で共通デザイン導入したり。
PHPUnit自体の機能とは特に関係ないんですが、うちのサイトの自動テストでは、HTMLの表示とかのテスト(結合テストに近いところ)もある程度やっていて、出力結果の保存とかもやっているんですね。
テストやるたびに、たとえ何の変更もなくて何の問題もなくても、何百ページ分ものHTMLファイルが出来上がります。
たとえ何の変更もなくて何の問題もなくても、改めて毎回テストをやること自体は、回帰テストといって、とても有意義なのですが、回帰テストは正しいか正しくないかだけわかれば充分なので、何が出力されたかまで細かく残す必然性はありません。
とはいえ、たとえ何の変更もなくても問題が起きることがあるから、回帰テストが必要なわけで、回帰テストに落ちたときだけは、何がおかしくなったのかを残す必要があります。
なので、普段邪魔になるからと言って、一律で保存をやめるなんてことはしないほうがいいでしょう。
だからといって、テストに落ちたときだけ保存するという器用なこともなかなか難しいわけで。
ということで、出力結果を破棄するオプションを作って、それをON/OFFすることで、保存するかどうか切り替えるようにしてみました。
TODOコメントつけてたところの整理とかしてた。
やってないものは課題化したり、終わったものは消したり。
うちのサイトにもエラーログを仕込んでいるわけですが、サーバーやPHP自体が持っているエラーログの他にも、独自のエラーログも記録するようにしています。
で、PHPには、例外によるエラーと、それ以外のエラーがあるのですが、独自のエラーログではそれぞれで処理が違っています。
そうすると、エラーという意味では同じなのに、見え方が違っていて、地味ーに問題の調査が面倒でした。
ということで、エラー発生ファイルとか行とか、共通する部分は同じように記録するように修正しています。
減るもんじゃないので、無料のうちにライセンス取得しておきました。
ひとまずは素材目的だったけど…BGMがMIDIだ!
使えそうな素材探しは作りたいものができてからでいいとして、ちょっと何かしらクソゲーの一つでも作っておきたいな。
ってことをウディタの時にも言ってた気がするぞ?
アンパンマンDBのみんなのタグのシステムの調整とかをしていて、アンパンマンDBのユーザー機能がTGWS自体のユーザー機能と噛み合わない部分があるのが気になって、そっちのほうを改修していました。
修正内容としてはそんなに大変なものではないのですが、様々な場所で無造作に使っているシステムで、影響範囲が実質全体に及んでいるので、念入りめに確認してからリリースする予定です。
他のことに忙しくてなかなかできていなかったコードの整理、久々にやりました。
アンパンマンDBと日記で使わなくなったSmarty関連のコードを中心にごっそり消えて、なかなかすっきりしました。
とはいえ、Smartyを使っている場所はまだまだあるので、Smarty自体をすっきりさせるのはなかなか道のりが長そうです。
Smarty脱却を進めるため、脱却しても動作が変わらないことを確認するためのテストコードをいろいろ作成していました。
肥大化・複雑化して手に負えなくなったのにいたるところで使われていて長年でかい技術的負債になっていたADB_DBとADB_Viewをやっと一掃できました。
いや、一応まだ滅ぼし残しがある可能性を考えて実体は残していますが、呼び出すと警告のログを残すようにしています。
これでやっとシステムとしてはしっくりくる形になり、アンパンマンDB4としては完成形になったかな。
完全に内部処理の話だから表向きは何も変わってないけど。
テスト環境の方で、ファイルをアップロードできないトラブル発生中。
本番環境の方はアップロードできるので、運営には今のところ支障はないのですが、新機能の開発とかには影響があります。
PHPの方の設定には問題なさそうだから、Webサーバーあたりかなぁ。
浴槽を置く方はレイアウトが定まらないので奥の部屋の方を整えてみました。

浴場の奥から部屋に入るとボイラー室兼水槽。
浴場の広さ的にただの暖炉で火力が足りるわけないんですが、メインは浴場側なので細かいことは気にしない。

さらに奥の部屋は、私室。
とりあえず本棚とベッドを中心にして、入浴客が来る場所ではなく個人的な居住空間である雰囲気を作っています。
キッチンとかも置いてさらに生活感を出すかどうかは考え中。
ちなみに、ベッドは玄関に置いてある浴槽の中にも隠れているので、単に寝たいだけの場合は奥まで来るより玄関で湯に沈んだ方が早いです。
日々細かい修正はしているんですが、今やっているのは、セキュリティ向上のためのちょっとした仕組み。
うちなんか狙ってどうにかなるようなものではないと思うのですが、一応可能性は下げておきたいので。
具体的な内容は一応伏せておきますが、割と有名な対策の一つです。
キャッシュ機能もできたので、旧掲示板ログ、公開しました。
他人の昔の書き込みなので、更新履歴に入れず、ここでひっそり告知しておきます。
キャッシュ機能の方は、残件として、古いキャッシュの自動削除・手動全削除の機能が残っています。
古いキャッシュは、PHPが提供されなくなっても残ったものとか、誰もアクセスしてなくて残す意味がないものとか、手動削除漏れで最新になってないのをリフレッシュする目的です。
手動削除の方は、PHPを新しくしたとき用ですね。
「かまめしどんとムッシュ・キッシュ」の作品情報を追加
「ジャムおじさんとらーめんてんし」の作品情報を追加
来週放送分。
らーめんてんしは割とお久しぶり。
ちょっと思いつきで、Composerのディレクトリをそっくりそのまま別の場所にコピーして、それを参照するようにしてみました。
ソースコードは問題なく、サーバー自体も壊れているわけではないということは、どこかが局所的に不安定なのでは?という仮説から、別の場所に置いて安定するかどうか確認します。
これでうまくいけば本格的にディレクトリ構成見直そうか。