アプリケーション
事務連絡
-
pageの仕様を変更。開発時に留意。list.phpなどで、一覧時、$pageは-1でdbへ。
-
サービスの起動状況を確認するスクリプトと、telnet、ping、再起動を検知する。
-
state値の取り扱いが6.1世代より変更となり、基準値が100となりました。新規開発時に注意。
最新の課題
| 状況 | 課題 | 担当 |
|---|---|---|
| - | 課題・提案はありません。 | - |
機能分割
- 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ファイルを使っていた。ディレクトリサービスなどを筆頭に開発。完全なコードの書き下ろしに初めて取り組んだ。
自動整理に関する留意事項
-
ウェブなどから自動で収集し、整理を行う機構については、提供元のデザイン変更などに応じて、収集方法の修正などが必要になります。
収集している対象