Pukiwiki
今日はPukiwikiのインストール方法を書いてたらこんな時間に。
某主任が部署を離れてしまうので、内部が結構混乱状態。とまぁそんな話はおいといて
プロジェクト内で情報共有基盤としてPukiwikiに限らずWiki全般を利用する場合、
「開発機とは別サーバで立てるのがいいですよ」という語句を入れてみた。
これは経験則で去年の年末に応援しにいったプロジェクトで開発サーバにWikiを立ててたもんだからリリース時なんかにWebサーバの再起動とかあった場合にWikiまで見れなくなっちゃうという事が何回（そう頻繁にはなかった）か発生した為。
うちの会社は大手メーカーの系列会社なので親会社が作った結構優秀（らしい）なサーバ製品を使う事が多いんですが、その製品のWebサーバがApacheをベースにしてるんです。
でもベースにしてるバージョンの情報がどこにもないんです！！
（そのサーバ製品が手元にないのも原因ですが）
確か、Apache1.3.x系だった気がするんですがそれ以上の情報皆無。
終了。
難敵現る。
やっとこさカタチにしてみた課のソフトウェア貸出システム。
ここに来て見事にこちらのずさんな仕様の穴を突く敵が発生。
先週末、ある資産がうちの貸出資産として追加されました。
そいつは某UMLモデリングツールなんですが今回コーポレートライセンスで購入した為、
一定条件下において無制限インストールが可能。
正直、「うちの課でコーポレートライセンス購入なんか予算的にもないだろうから考慮の必要はないだろう」と適当に考えていたので結構なダメージを・・・。
現在の貸出システムだとマスタテーブルのライセンス数は整数必須になっているので、まずこれをどうするか考える必要がある。
次に貸出期間。
通常の資産は課の規定で「貸出期間<=３ヶ月」なんですが、これまたコーポレートライセンスなので返却してもらう必要がない。
しかし、システム上では貸出期間の入力必須。
アーキテクチャを変更するか。
無理矢理運用で対処するか。
無理矢理運用で対処すると後々またそのしわ寄せをくらいそうなんでシステムのアーキテクチャを考え直す必要がありそうな・・・orz
システムのデモ
今日はユニットのメンバーにTuigwaaで作ったシステムのデモをやった。
挙がった要望は
「フォームからの登録時に確認画面が欲しい」
「マスタテーブルメンテの機能が欲しい」
「もっと集計して欲しい（意訳）」
といったもの。
確認画面は他の機能の組合せで代替できないかMLに投げねば。
マスタテーブルメンテはささっと作れちゃうので対応。
集計は・・・calcプラグインの改良待ち（笑）
とりあえずおおまかな形にはなったのでよしとしよう。（自己満足）
申請部分改良
西岡さんにMLで確認画面の実装方法を教えて頂いたのでそれを反映させてみる。
フローは
申請画面（履歴テーブルのカスタムフォーム）
↓
DBに追加、確定フラグは0
↓
申請確認画面
「はい」が選択されたらThanksページに遷移&ロジックで確定フラグ1
「いいえ」が選択されたら「申請を取り消しました画面」に遷移&ロジックで該当レコード削除
この仕組みの場合、確認画面でユーザがブラウザを閉じちゃったりするとDBにゴミレコードが出来ちゃいますが、運用で定期的に削除すれば問題ないかな。
とりあえず、新しいバージョンまではこの方法で対応というカタチで。
冷静に眺めて見ると、申請確認画面まで行くと申請内容の修正とか出来ないんだよな･･･。
破棄か登録か。
うーん、漢気あふれるシステムだ（笑）
Tuigwaaのメモ
レコード指定ページでDBのカラム内容に改行とかハイパーリンクをつけたい場合は、
カラム内のデータに直接HTMLタグ（リンクならa、改行ならbrとか）を書くといける
（セキュリティ的にどうなのかは別として 笑）
さらにメモ。
既にカスタムフォームとかのフォームを用意してる場合に後から対象テーブルにカラムを追加した際、コンテナの再起動をしないとデータ追加時にエラーがでる。
tablefeedプラグインの要望
内容的にとてもMLに流せなそうな個人的なヤツなのでここにコッソリ。。。
feedを発行するターゲットのテーブル毎にfeedのtitle部分に表示する文字列を選択できるようになったらいいなぁ・・・。
表示候補としてはそのテーブル（フィルタが選ばれてる場合はフィルタで表示される）カラムの中から選べるようにするとか・・・。
作ってるシステムの軽いレビュー
公式じゃないので正確にはウォークスルーですな。
Tuigwaaで作ってるシステムを主任に一通り触ってもらってご指摘を頂きました。
いやー色々大変だ。
こーいう感じでソースいじればできそうかなーってやつから実現方法すら思い浮かばないモノまで様々。ちょっとげんなり。
