アプリケーション

事務連絡

  • pageの仕様を変更。開発時に留意。list.phpなどで、一覧時、$pageは-1でdbへ。
  • サービスの起動状況を確認するスクリプトと、telnet、ping、再起動を検知する。
  • state値の取り扱いが6.1世代より変更となり、基準値が100となりました。新規開発時に注意。

機能整備に関する総合計画

主たる機能の整備については、総合計画として承認された範囲を基礎とする。 

主体機能

  • ページ管理(CMS)
  • 文書管理(blog)
  • リンク管理(ブックマーク)
  • 新着情報
  • 掲示板
  • 写真
  • 会員管理
  • 商品管理
  • フォーム
  • 幾何情報
  • 求人
  • 不動産
  • 帳簿

外部連携

  • 認証(OpenID)
  • 部品単位(html)
  • API
  • RSS

機能分割

  • apiの提供などができれば良いとはいえ、いまいちサービスの形成方法が分からない。
  • 代替などの観点から、RSS提供する形を採用し、サーバを越えても対応できるような構造が欲しい。
    • データベースへのアクセスがサーバを越えないといけないとか、複数のデータベースが必要という場面がある。 

基本処理

全体の処理を再考し、より分かりやすい構造を持って、アプリケーションの動作を整理したい。

  • データベースへ接続
  • 初期設定を読み込み
  • 外部入力を整理
  • データを取り出し
  • 表示

Zend Framework

  • 現在、最新のアプリケーションについては、Zend Frameworkを使った開発に移行しています。1.0.0がリリース。
    • 修正利用
      • Feed/Abstract.php - RSS1系への対応。
      • Filter/HtmlEntities.php - $charSetをUTF-8に修正。
    • 採用状況
      • 1.0.0については、採用に必要な準備を行っています。
        • test10が1.0.0に対応しました。

認証

  • zend aclを使った認証機構を実装する方向で検討中です。
  • zend authは、認証作業の条件に見合わないため、見送ります。

世代

  • 第六世代
    • 現行、最新世代。Zend Frameworkを使った開発に移行。フレームワークはいくつかを試す中、もっとも将来性があり、扱いやすいものを選んだ。
    • 6.1世代
      • 第6世代のものに、文書管理をデータベースに移動、Zend Framework 1.0.0以降に対応させたもの。自由なuriに対して、引き出す文書が選択できる構造となり、すべての機能が文書上で呼び出せるようになった。
  • 第五世代
    • フレームワークとなる基盤部分を書き直したもの。現行のスタイルシートなどに全面対応させるなど、世情に合わせた設計。フレームワーク自体の開発を問題視していたので、ほとんど営業部分に採用されないまま、短命に終わった。主に管理機能を置き換えている。
  • 第四世代
    • PHP。class化を行い、実質のフレームワーク化。多くのアプリケーションに対して、共通の構造を採用。コード量は多くなり、拡大するコードを抑えるため、フレームワーク側に機能を吸収する作業が増えた。
  • 第三世代
    • PHP。一部をfunctionに移行、コード自体を自動生成する。POG(PHP Object Generator)のような構造を持っていた。functionは必要な機能をまとめた。
  • 第二世代
    • PHPに移行、完全に独立したアプリケーションとして設計していたもの。テータベースを初めて採用した。requireなどの機能は知らず、1ファイル上にコードを継ぎ足した。
  • 第一世代
    • CGI/Perlで開発。CSVファイルを使っていた。ディレクトリサービスなどを筆頭に開発。完全なコードの書き下ろしに初めて取り組んだ。

自動整理に関する留意事項

  • ウェブなどから自動で収集し、整理を行う機構については、提供元のデザイン変更などに応じて、収集方法の修正などが必要になります。

収集している対象

  • フィード取得・汎用対応 - 10分間隔。
  • Yahoo! 地震情報
  • 警察庁
  • 日本海新聞
  • 神戸新聞 - 但馬、西播、姫路。

主な機能

関連事項

検討

注意