Wikitcc2について

まともな情報がほしい人は About Wikitcc2
こっちは雑記ですのであしからず

Wikitcc2の宣伝

改善点

デザイン

以前のwikiのデザインを気に入っている人には悪いのだけれど、あれがリリースされて7年余り、そろそろデザインを見直す必要があり、デザインを大幅刷新した。
操作感覚はあまり変わらないよう、以前のwikiのボタンの位置をなるべく踏襲してはいる。
巷で流行っているというレスポンシブデザインというものを取り入れてみた。
これによりPCで見ても携帯で見ても最適な幅、デザインに調整される。
デザインは見る人が見ればどう見てもbootstrapで作ったなといった感じに仕上がった。
このWikiが作られたのがだいたい7?年前くらいだから、きっとこのデザインも5年後くらいには古くなってることだろう。その時は誰かにメンテして欲しいものだ。

履歴

履歴の閲覧を記事から容易に行えるようにした。
これは割りと念願の機能だったし、実現できてよかった。
ただ、差分を記録するのでなくまるまるコピーをDBに残してるだけなので大変容量から見た効率は悪い。

検索

検索機能を追加した。
ページネーションだとかSQL文だとか
たぶん1から書くとかなり面倒くさいんだろうがcakephpとプラグインのおかげで一日で実装できた。

ほとんどすべての再設計

前のコードで引き継いでるのはWikitccパーサだけ
ほぼすべてのコードをモダンphpというか、cakephpフレームワークに沿ってMVCに再設計した。
すこぶるコードの見通しは良くなったんじゃないかと自分では思うけれど、
キャッシュ機能を実装しておらずすべてのページを動的に作成しているため多少重くなった。
あと、コードの中身は他人が読むことを前提に書いてないので注意が必要。
その他、
  • 画像のサムネイルを作る機能
  • RSS生成機能
  • ログイン後、前のURLにリダイレクトする機能
  • ajaxを用いたプレビュー
とかもおまけで作ったりしている。

移行についてのデメリット

  • URLが変わるため、リンクが引き継げない
前のWikiは残すし、コンテンツも移行するが前のページへのリンクが切れている状態になる。
  • 多少重くなる
フレームワークの重さとほぼページをキャッシュしないことより、以前のwikiより重い
たぶん恐ろしい量のアクセスとか来ないし大丈夫だけど
  • 履歴を差分ではなくコピーの形で残すので、ファイルサイズが大きくなる。

なぜWikitcc2を作ろうと思ったか

そこにクソコードがあったから、といえばそれまで。
作る気にされたのは何時だったか忘れたのだけど、あれは直したほうがいい、ということは複数の先輩から聞いていた。
いずれは誰かが手を入れなければ使う人がいなくなり、そうなるとコンテンツごと腐ってしまうし(ほとんど腐りかけだが)メンテできそうな人は自分をおいて他に居なかったので仕事に取り掛かることにした。
と、ここまでが今年の4月ごろの話。
Wikitccソースを見ていてにバグを修正した記録がある。
ソースを見てて、ルーティングを全部index.phpにまとめている割にindex.phpのなかで他の処理もやってたりとか、ファイルに書き出すところが読みづらく、
bokkoさんには誠に申し訳なく思うが、色々いちゃもんをつけているとキリが無くこれを修正するくらいなら1から書いたほうが早いと考える。
良い物を作れば部の広報としても役立ってくれることも期待でき、見返りは十分あるだろうと思っていた。

フレームワーク(言語)候補

Wikiエンジンを作るにはHTTPサーバ, 動的HTML生成, DBとのやりとり, ...等々の機能が必要であるが、
これらを0から作るとなると半端ではない労力が要る。
しかし動的Webページを作る目的に特化したフレームワークを使うことでそこら辺の共通処理を作ることなくプログラムを作成することができる。これらは偶有的な複雑性なので。
というわけで最初に取り組んだのはフレームワーク選びだった。
フレームワークを選んだ基準をこういうのを作ろうと思ってる人のために書く。

言語フレームワーク大きさ工程の長さ(予想)
RubyRails★★★★★☆☆☆
Rubysinatra★★☆☆☆☆
PHPなし☆☆☆☆
PHPCakePHP★★★★☆☆
JavaScriptAngularJS★★★☆☆☆
CommonLisp??????
HaskellYesod★★★★???
フレームワークの大きさで★★★★以上をつけたものは俗にいうフルスタックフレームワークというやつでDBの抽象化から認証、セッション管理、Html出力のための関数等々色んな所で面倒を見てくれるフレームワークのことである。
定義があやふやすぎるのでRailsの流れをくむフレームワークと呼んだほうがいいだろう。
色々面倒を見てくれる分手間は減る代わり、速度が犠牲になるケースもあったり、フレームワーク自体を学ぶ学習コストが高くなる。
実際CakePHPでの開発中もドキュメントとにらめっこしている時間がほとんどだったしね。

逆に★のやつはあんまり面倒見ない系

ここに挙げたのの他にはJavaのフレームワークも色々有名ではあるけれど候補から外していた。
昔(といっても2000年台)はStruts(http://struts.apache.org/)というフレームワークがよく使われていたのでその印象しかなかったけれど、
最近はPlay(http://www.playframework-ja.org/)というナウなヤングにバカウケしそうな感じのイケてるフレームワークが注目されているようなのでオススメしておく。

上に書いてきたように色々考えてはいたが、ずっとやる気と時間がなく開発を進められなかったが冬休みでようやく進めることが出来た。
結局フレームワーク選びは Wikitccパーサを書きたくない & 履歴管理のプラグインがある(RevisionBehavior)
という理由でCakePHPに直前に決めた気がする。
あとRailsはメジャーバージョンアップが多すぎてすぐに動かなくなるのでは、という懸念があった。

仕様書

どっから書けばいいのかよくわからない
ディレクトリ構成とかはたぶん書くけれど、関数仕様とか画面遷移とか書く気になれないのでやめます
やってお金がもらえるならやるけど

ディレクトリ構成

app - appフォルダ以下にアプリケーション本体がある
├── Config
│   ├── core.php - 中心となる設定 パスワードのsaltの設定やデバッグモードを切り替える設定等
│   ├── database.php - データベースの設定
│   └── routes.php - ページ内ルーティングの設定
├── Controller - MVCのC
│   ├── AppController.php - 基底コントローラ
│   ├── CategoriesController.php - カテゴリのコントローラ
│   ├── UsersController.php - ユーザのコントローラ
│   └── WikiPagesController.php - Wikiページのコントローラ
├── Model - MVCのM
│   ├── AppModel.php
│   ├── Attachment.php
│   ├── Behavior
│   │   └── RevisionBehavior.php - 履歴管理部分
│   ├── Category.php
│   ├── User.php
│   └── WikiPage.php
├── tmp - 一時ファイル置き場
├── Plugin
│   ├── Search - 検索のためのプラグイン
│   └── TwitterBootstrap - CSSカスタマイズのためのプラグイン
├── Test - そんなものはなかった
├── View - MVCのV ページのレイアウトを変更したい際はここを編集すること
│   ├── Attachments - 添付ファイル表示のテンプレート
│   ├── Categories - カテゴリ表示のテンプレート
│   ├── Elements - 部品となるテンプレート
│   │   ├── header.ctp - ヘッダのテンプレート
│   │   ├── private_header.ctp - ヘッダのテンプレート ログイン後用
│   │   │── sidebar - サイドバーのテンプレート
│   │   │   ├── private_recent_updates.ctp
│   │   │   ├── recent_updates.ctp
│   │   │   └── sidemenu.ctp
│   │   └── wiki_pages_list.ctp
│   ├── Helper - 表示を補助するプログラム
│   │   └── WikitccParseHelper.php - Wikiパーサ
│   ├── Layouts
│   │   └── default.ctp - すべてのページの元となるテンプレート
│   ├── Users - ログイン画面等のテンプレート
│   └── WikiPages - Wikiページ表示のテンプレート
└── webroot - このフォルダ以下にあるファイルは静的なファイルとして参照できる
├── files
│   └── attachment - 添付ファイル置き場 改ざんを防ぐためApacheユーザーにしか書き換え権限を与えないこと
└── favicon.ico - ページのアイコン

なんとなく思うことなんだけれど、古いものを改修していつまでも使うよりはフルスクラッチで開発したほうが
スッキリしていいことが多いよね、と自分と後世の人へに向けて言っておく。

最終更新日時:2016-06-13 00:12:28

作成日時:2014-01-24 09:53:03