きゃらりこ日誌

最近の記事

ChatGPTに御朱印データベースを作ってもらいました

インターネット / 技術
最近、ChatGPTでいろいろと遊んでいるのですが、プログラミングもできると知り、PHPで簡易な御朱印データベースを作ってもらいました。
仕様の提案・整理からプログラミングまで、ほぼすべてをChatGPTにお任せしています。
たまに仕様にないものを盛り込んできたり、仕様に入っている機能が抜けていたりすることに悩まされましたが、指示し直したり、たたき台をこちらから提示したり、手動で修正したりして解決しました。
しかし、ここまでのレベルのことができるとは、AI恐るべし。
なお、このデータベースは文字通り簡易でセキュリティよわよわなので、一般公開はしていません。
一覧画面
一覧画面
編集画面
編集画面
とりあえず、こんな要求仕様を作ったよというのをメモとして残しておきます。
ちなみに、これもChatGPT製です。

御朱印データベースシステム - 要求仕様書

1. システム概要

御朱印データベースシステムは、御朱印の情報をデータベースに登録・管理できるWebアプリケーションである。
PHPとSQLiteを使用し、スマートフォン対応のレスポンシブデザインを採用する。

画像のアップロード・管理機能を備え、安全なデータ操作を行うためのセキュリティ対策を実施する。

2. システム要件

2.1 ハードウェア要件

  • サーバー: PHP 7.4以上、SQLite 3.0以上が動作する環境
  • クライアント: HTML5/CSS3対応のWebブラウザ(Google Chrome, Firefox, Edge, Safari)

2.2 ソフトウェア要件

  • OS: Linux / Windows / macOS
  • Webサーバー: Apache / Nginx(PHPが動作する環境)
  • 開発言語: PHP(バックエンド), HTML/CSS(フロントエンド)
  • データベース: SQLite(goshuin.db
  • セキュリティ: SQLインジェクション対策(PDO)、XSS対策、ファイルアップロードのバリデーション

3. 機能要件

3.1 ユーザー機能

機能説明詳細
御朱印の登録御朱印情報をデータベースに登録フォーム入力、画像アップロード
御朱印の編集既存の御朱印情報を変更画像変更時は古い画像を削除
御朱印の削除御朱印情報を削除画像も削除
御朱印の検索キーワードで検索タグ・寺社名・住所を対象
御朱印の一覧表示登録データを一覧で表示カード形式、サムネイル付き
画像アップロード御朱印の画像をアップロードJPEG/PNGのみ、サイズ調整

3.2 データ管理

機能説明備考
データベース作成goshuin.db を自動生成初回起動時に作成
データバリデーション不正データの排除入力チェック、XSS対策
画像リサイズ画像の高さを200pxに統一幅は自動調整

4. データベース設計


4.1 データベース構造

goshuinテーブル

フィールド名制約説明
idINTEGERPRIMARY KEY AUTOINCREMENTユニークID
jisyanameTEXTNOT NULL寺社名
typeTEXTNOT NULL種別(神社 / 寺院 / その他)
visitdateTEXTNOT NULL訪問日(YYYY-MM-DD)
addressTEXTNULL住所
contentTEXTNULL記述内容
book_nameTEXTNULL御朱印帳名
tagsTEXTNULLタグ(カンマ区切り)
memoTEXTNULLメモ
imageTEXTNULL画像パス

5. セキュリティ要件

項目内容
SQLインジェクション対策PDO::prepare() を使用
XSS対策htmlspecialchars() でエスケープ処理
CSRF対策フォームにCSRFトークンを埋め込み
画像アップロード制限MIMEタイプを image/jpeg, image/png に制限
ファイル名のランダム化uniqid() でランダム名を生成
ディレクトリトラバーサル対策basename() を使用し、パスを制限
古い画像の削除新しい画像をアップロード時に unlink() で削除

6. UI/UX設計

6.1 デザイン仕様

  • レスポンシブ対応(スマホ・タブレット・PC対応)
  • カード形式の一覧表示(画像付きのタイルレイアウト)
  • フォーム入力は必須項目に required を使用

6.2 スタイル仕様(抜粋)

css
body {
font-family: Arial, sans-serif;
margin: 20px;
text-align: center;
}
.form-container {
width: 100%;
max-width: 600px;
margin: 0 auto;
text-align: left;
}
button {
background-color: #4CAF50;
color: white;
font-size: 16px;
border: none;
cursor: pointer;
}
button:hover {
background-color: #45a049;
}

7. システムフロー

7.1 登録フロー

  1. ユーザーが入力フォームに御朱印情報を入力
  2. 画像をアップロード(バリデーション)
  3. データベースに保存
  4. 一覧画面にリダイレクト

7.2 編集フロー

  1. ユーザーが edit.php?id=XX を開く
  2. 既存の情報を取得し、フォームに表示
  3. 変更後に保存ボタンを押す
  4. 画像が変更された場合、古い画像を削除
  5. データベースを更新

8. 例外処理

事象対応
必須項目が未入力エラーメッセージ表示
画像アップロード失敗エラーメッセージ表示
データベース接続エラーtry-catch で例外処理



[ | この記事のURL ]


今夏の北海道旅行について、あれこれと計画を練ってます

散歩・旅行

今年8月に実施予定の北海道旅行について、随分と気が早いことに昨年11月に古本ですが北海道のガイドブックなんかも買い込んで、いろいろと計画を練っていました。
そして先日は暇に飽かして、とうとう北海道旅行の旅程まで作成してしまいました。
いやいや、旅行は半年先の話なのに旅程作成はまだ早いでしょうに……
また北海道旅行がポシャったときの代替として、金沢・白川郷旅行の旅程案まで作ってしまいました。

北海道の旅行ガイドブック
北海道の旅行ガイドブック

そんなこんなで策を練った結果、今夏は3泊4日で札幌・小樽に行くことに決定しました。
帰りはフェリー泊なので実質2泊3日の旅になりますが、夏の北海道を満喫していきます。

大まかな旅程は、今回は初日午前は飛行機で羽田空港から新千歳空港に飛び、午後には小樽観光。
翌日・翌々日は札幌観光。
翌々日の夕方にはフェリー さんふらわあに乗船。
4日目はフェリーで旅の疲れを癒しつつ、まったり過ごしして、茨城 大洗港から横浜の自宅に帰宅といった計画になりました。
しかし北海道は外国人にも人気の観光地なだけあって、ビジネスホテルであっても宿泊料金が高いですね。
試しに旅費を見積もってみたら、3泊4日で7.5万円でした。
いろいろな割引を効かせてこの金額に収まっているので、これを正規料金で支払うとしたらとんでもない額に……

旅程を組んでいるときに実感したのですが、北海道は広いですね。
当初は大自然を堪能しようとして、帯広や旭川や稚内・網走・釧路・富良野などにも寄って行くという案もありました。
しかし札幌市の面積だけでも東京23区の2倍弱もあるし、北海道の端から端まで行こうとすると南北方向に約400km(東京-大阪間とほぼ同じ)、東西方向に約500km(東京-岡山間とほぼ同じ)もあります。
他の地域への移動だけで、だいたい3時間もかかります。
どだい無茶な話です。
そんな訳で、札幌と小樽だけとなりました。
でも札幌観光だけでも行きたいところの半分しか行けてませんし、余裕のある旅程を組めたのでそれはそれで良しとしましょう。

とはいえ、北海道旅行はまだ半年も先の話です。
旅行の手配すらまだ行っていないのですが、気持ちが先走りがちになってますね。
気持ちの高ぶりは、旅行当日まで取っておいて、その日が来るまでのんびり気長に待つとしましょうか。


[ | この記事のURL ]


令和8年(2026)暦要綱

雑学 / メモ
来年の暦要綱が2/3付の官報に掲載されたので、毎年のことですがこのブログにも転載しておきます。
テキスト版は、国立天文台暦計算室の暦要項のページを参照してください。

振替休日は、5月6日がこどもの日の振替休日に、 9月22日が敬老の日の振替休日になります。
そして、3/3に皆既月食が見られるそうです。
令和8年(2026)暦要綱
令和8年(2026)暦要綱

[ | この記事のURL ]


ドメインの終活ってどうしたらいいのだろう

インターネット / サイト管理

先日、かつて「ポケモンファンサイト ポケサテ!」で使っていたpokesate.comのウェブサーバを停止しました。
サイト閉鎖から、もう20年も経つので、これを機に完全に閉じました。
……え、20年⁉

停止したpokesate.comのウェブサーバにアクセスすると…
停止したpokesate.comのウェブサーバにアクセスすると…

ドメインって取得するのは簡単なんですが、ドメイン廃止後に誰かにドロップキャッチされて悪用されてしまうことを考えると、いつまで維持し続けたらいいのだろうかと悩みます。
Googleの対策もあり中古ドメインを利用したSEOは効果が低くなっているので、ドロップキャッチされてしまうリスクは少なくなっているのは救いです。
ただ、使わないドメインを後生大事に持っておくっていう選択肢も、無駄に維持費を垂れ流すことになり、お金がもったいないです。

ではどうしたらいいのかというと、サービス終了後、ドメインを10年間保持しておいて、10年たったらドメインを廃止するという方法が一部では推奨されています。
10年の根拠がどこから来たかというと、ドメインを更新する際に更新することができる年数が最大9年だから、今年+9年で10年ということらしいです。
私の経験から言っても、サイト廃止後10年も経てばリンクを張ってくれていたウェブサイトもあらかた無くなり、アクセスもほぼウェブクローラーだけになるので、10年は妥当だと思います。

ちなみにpokesate.comは、メールサーバーはまだ使っているので、当面はドメインの廃止はしないつもりです。
ただサイト廃止後10年の話から言えば、いつ手放してもいい時期には来ているですよね……


[ | この記事のURL ]