< | >

CMSを試す・・・CMSimple
  • (2009-02-16 07:41:13)

コンセプトも構造もシンプルなCMS



この数ヶ月「何かよいCMSはないか?」と心に引っかかっていたが、CMSimpleは文字通り「シンプル」な点がなにかと便利。

※一応ソースを見てみた。全然わからない。シンプルといえども初心者がカスタマイズするにはハードルが高い。

※感想:変数や関数のつけ方がアルファベット1語だったりとネーミングが短い。ヨーロッパ風流儀だろうか?プログラミング可能な人でもソースを追うのは大変かも?

記事はすべてプレイン・テキストファイルに落とされる(MySQLなどのデータベースは不必要)。しかもわずか1個のテキストファイル(content.htm)に。CMSimpleは中身のテキストをいくつかのページにダイナミックに分解・生成するというコンセプトのプログラム。

ページ生成のロジックに使われているのがHTML文法の<h>タグ。<h1>・<h2>・<h3>のわずか3種類のタグを使うだけでよい。このテキストファイル(content.htm)をCMSimpleに噛ませると、プログラムは3種類のタグをマーカーとして別々の個別ページに切り分け、かつ、それぞれのページタイトルにするという仕組みだ。

各ページは相互にリンクされるだけでなくパンくずリスト(パンくずリンク)も自動的に作成してくれるし、サイトマップも自動生成される。SEO的にも効率的と判断されるので企業ユースにも効果的。文字通り「Simple CMS」(シンプルなCMS)。

ライセンス形態はGPLで「Powered by CMSimple」と「CMSimple Legal」を明示しオリジナルサイトにリンクするという規則がある。1万円程度のコマーシャルライセンスを購入すればこれらの表示・リンクを削除できる。

基本コンセプトが素敵なプログラム



こうもすっきり単純で効率的なロジックを思いついて、サラサラとPHPで実装してくれたのはデンマーク人。彼も「プレイン・テキスト」お気に入りに違いない。複雑な事象がごく単純なロジックに落とされている様子が美しい。

3種類の<h>タグでページ階層の深さも判断される。逆に言えば各章最大で3階層までしか構築できないがとりえあず問題はない。PHPの心得があれば多少いじって階層を増やすカスタマイズも可能だろう。

やはりよく使う道具は"単機能で使いやすいヤツ"に限る。考えてみれば大工のカンナもお医者のメスもプロの道具は「単機能で使いやすいヤツ」が多い。

今時のPCやサーバーにとって5Mや10Mのテキストファイルの開け閉め・保存は何の負担もないので、仮に1ページ1k程度の記事とすると10Mのテキストファイルで1万本(1万ページ)の記事が書ける。

Simpleといいながら1万ページもあるwebサイトは相当大規模なwebサイト。1万ページのwebサイトをCMSimpleだけで運用可能かどうかは別の話だが、記事を書き足していくという作業に関して、拡張性の問題はまずないだろう。

記事の新規追加・編集はオンラインで画面から直接編集可能だが、醍醐味はテキストファイルをローカル編集し、ftpでアップロードすれば速い。秀丸の編集機能がフルに使える点が私には嬉しい。

メンテナンス方法



ftpもCMSimple専用のbatファイルを作成しワンクリックでアップロードできるようにした。ftpはいつもお世話になっているFFFTP。コマンドラインのバッチファイルか、コマンドラインのオプションを加えたショートカットで直アクセスアップロードが速い。

"C:\Program Files\ffftp\FFFTP.exe" -s (ffftp登録名) -m -d -f -q

日本語の問題



日本語表示に若干の問題(ある特定文字で文字化け発生)があった。文字化けはCMSimpleを試した人が多く遭遇する問題のようだ。

「CMSimple 文字化け」で検索すると数件が上がってくる(「CMSimple 文字化け」で検索して数件しかが上がってこないことは逆に言えば日本ではCMSimpleのユーザー数は限られているようだ。シンプルすぎて人気がないのだろうか?)。

文字化けについてはすでに解説や内容を公開してくれている人がいて参考になる(下記リンク参照)。問題箇所はPHPのプログラム内、cms.phpの中のrfc()、h()、l()の部分に問題があることを指摘してくれているサイトがあり、またCMSimpleの台湾バージョン・twCMSimpleがどのように修正しているか見よう見まねで変更してなんとか現状問題を回避している。

コンテンツを書き加えながらCMSimpleの使いやすさや使い勝手を見ていきたい。私の仕事はコンテンツの制作なので、プラットフォームが入手できれば、とにかく記事を制作することに邁進したい。

CMSimple 実使用の感想

CMSを試す・・・CMSimple

・CMSimple.ORG(CMSimpleのオリジナルサイト。最新版がダウンロード可能)

 www.cmsimple.org

・twCMSimple(中文版・台湾バージョンのCMSimple。文字化け問題でお世話になる)

 cmsimple.cycu.org








< | >

CMSを試す・・・DokuWiki
  • (2009-02-14 10:25:14)
PukiWikiのついでに海外で人気のDokuWikiを試す

-------------------------------

PukiWikiを試したついでに今度はDokuWikiをダウンロード。試す。インストール自体はPukiWiki同様、極めてスムーズ。DokuWikiはネットを検索しても評判がすこぶる良い。バックエンドにデータベースは必要とされず記事はテキストファイルに落とされるので軽く扱いやすい。オリジナルは海外製で世界的に使用されているためユーザー数も多そうだし汎用性も高い。開発者参加者も多いに違いない。他に例を見ないくらい豊富なプラグインの数も魅力的とよいことずくめ。しかし、PukiWiki同様、私にはまだ使いこなせない。






< | >

CMSを試す・・・PukiWiki
  • (2009-02-13 10:59:51)
CMS・Wikiシステムの何たるかを少しだけ知る

-------------------------------

ブログシステムには満足している。テキストを流し込むだけでページの生成と既存ページとのリンク生成や既存ページとの整合性を調整してくれる。

WEBのコンテンツは今までHTMLタグを入れて一つ一つページを制作していたもの。ブログシステムの登場は文屋さんがシステム・デザイン・レイアウトといった雑多な行程から解放され、純粋にコンテンツ(記事)の制作だけにより多くの時間と労力を投下できる環境を提供した。

文屋さんの生産性は格段に上がった。多少の不自由はあっても魅力は大きい。ブログが多くの文屋を魅了した原因だと思う。

これに味をしめてブログに触れて依頼、私の中では「これからのWEBサイトはCMSで構築してくもの」という考え方にすっかり変わった。

しかし、ブログはニュースやログ、記録のようなタイムライン(時系列)方式の記事制作や情報公開には向いているものの、書籍のようにあるテーマを取り扱うまとまった知識の体系をまとめるには不合理である。ブログとは違ったCMSが欲しいと捜している。

ネットを検索するとXOOPSやEC CUBEのようなものがいたるところに露出しているが、私が捜しているものはサイト全体を丸々リプレースするCMSではなくそのときどきの目的に応じた小さなCMSから積み上げたい。

今回は「書籍のようにあるテーマを取り扱うまとまった知識の体系をまとめる」CMS。

「○○事典」なるサイト制作を計画している。ブログでは無理だし、大型のコマース用CMSでは大きすぎる・・・と捜しているうちに「wikiクローン」なるCMSがあることを発見。Wikipdiaの中身はよくわからないものの、その存在はもちろん知っている。wikiクローンというからにはWikipdiaのシステムに近いCMSだろうか?

PukiWikiをダウンロード。試す。インストール自体は極めてスムーズ。ファイルのパーミッションの設定で多少動かなかったが、とりあえずラッキーセブン「777」で動かすと1時間もせずに動作するようになった。

問題はWikipdia文化を私は知らないので、そもそものスタートラインから難解に感じた。

新しいページの作成のし方が全然わからない。

また、記事の書き込みには独特のタグが準備されており、装飾やリンク付けはタグで行うらしい。タグの種類はたいして多くないだろうが、とりあえず「書き方の流儀」(文法)を修得しないといけないらしい。これは少々気が重いハードル。

そして「ヘルプ」を読んでいて悟るところがあった。

質問:「誰かが書き込みを書き換えてしまう」

解答:「Wikiとはそういうものです」

なるほど。私ははじめてWikiシステムの何たるかを理解した。これはキーワードベースのグループウエア。キーワードオリエンティッドな解説集。しかも不特定多数の参加者の加筆で構築する知識データベース。

新しいキーワードに説明を継ぎ足していくことで新しいページを増殖していくシステムらしい。過剰に残されるログもそれは必要だろうし、誰もが書き込みを加えることができるのも納得できた。それが目的だから。

自分だけが書き込めばそれなりに本のように体系たった知識ベースは構築できそうなので使えないこともない。しかし、Wikiシステムの前提条件自体が今回の私の目的とはズレている。システムは大きく、PHPプログラムを解析できない私の手に負えるシステムではない。

しかし、かなり素敵なシステムで、キーワードオリエンティッドな解説集の制作には理想的だろう。データベースを必須としない点もうれしい。日本のケータイブラウジングに対応している点のメリットは大きい。いつの日か利用してみたい作品。






< | >

CMSを試す・・・Concrete5
  • (2009-02-11 15:57:08)
ウワサのCMS・Concrete5は私の手に負えるか?

-------------------------------

「コンクリート・ファイブ」と呼ぶのだろうか? マイコミジャーナルに「ある意味CMSの理想型かも。『Concrete5』」という記事が掲載されていた。そんなに凄いのかConcrete5、という感じで試した。

Concrete5も今時の流行である「PHP&MySQL」という組み合わせ。X11ライセンスなので自由度も高い。編集の考え方が「ブロック単位」になっている。おそらく全体の基本レイアウトは変更できないが、事前に定義・準備されている「標準ブロック」内は自由に編集可能で、基本レイアウト内でのブロックの移動も可能。

CMSの目標であるシステム(ロジック)・デザイン・コンテンツの分離という意味でかなり洗練されているCMSのように見える。編集モードに入れば見た目のデザインやレイアウトのままオンラインかつリアルタイムに編集可能という点は凄い・・・などなどの評価が「CMSの理想型かも」ということなのだろう。

おそらくデフォルトのデザインの美しさに多くの人が唸る。小規模な会社のホームページならデフォルトのデザインとレイアウトをそのままに内容だけを差し替えればかなりクールなホームページになりそうである。私が今まで試したCMSでは抜群のデザインとコンセプト。

しかし、デフォルトのフレームワークのまま会社のホームページにできる程度の小規模なホームページだとすると、逆に「PHP&MySQL」という組み合わせ自体が妙に過剰のような気もする。特にMySQLと使う必要があるのかという疑問はいつも脳裏をよぎる。将来性を考えてのことだろう。大規模WEBサイトにするとしたら、やはりPHPのカスタマイズは必須。

また「見た目のデザインやレイアウトのままオンラインでリアルタイムに編集可能」な点も逆に動作が冗長になり、自由な編集の気力が殺がれる。この辺は個人の好みだろう。「見た目のままの編集」が好みでDreamweaverを購入する程ではないという人にはステキなチョイスであることは間違いない。

本当にいろいろな凄いソフトがでてくる。しかもフリーソフトの多さ。驚きの毎日。とはいえConcrete5も同様に、現状の私では使いこなせるレベルではなかった。






< | >

RAMDISKで、激速を期待してACCESS
  • (2009-02-07 15:58:32)
RAMDISKがちょっと気になって昨夜試した。

32bit Windowsのメモリー空間は4GBが限界。ところが、実際に32bit Windowsが使用できる空間は理由は不明ながら、3.5GB程度。4G搭載したユーザーなら管理外領域の利用されていない500MB程度を有効利用したいと思うのは当然。

作者不明の「Gavotte Ramdisk」(ガボット)や「Free RAMDisk」(Qualitative Software)というRAMDISKソフトが話題らしい。

もっとも私には「管理外領域をRAMDISK化」などOSの限界に挑戦といった気概はない。単純に使用していないメモリ空間の一部をRAMDISKとして割り当て、データベースの動作が改善するかどうか試してみたいと考えた。それで少しでもACCESSが速くなるならビジネスに役立つ。

予想は「激速か!?」と大いに気になっていた。500MBのRAMDISKを作成。そこに400MB程度のACCESS(mdbファイル)をコピー。mdbファイルをACCESSで起動し、レコード検索やレコード移動などの操作してみる。

しかし、結果は意外にもACCESSの起動は高速化しただが、それ以外は何ら変化を感じない。

理論的に考えてみればこんなもんだろという気もする。ACCESSは起動後、大半のテーブルをメモリにコピーするのだろう。であれば、高速化する部分は最初の起動とデータ更新の保存時だけとなる。検索やクエリなどは同じメモリ内でなんら変化なし。

昨夜の限られた時間内での判断なので、これが真実かどうかは自信ないが、データベースの高速化はRAMDISKでは大して期待できないというものだった。現時点RAMDISKを導入する価値はなかった。データベースの高速化はインデックスのつけ方やクエリの張り方など、データベース内のオプティマイゼーションの方が重要。








search
layout
admin

[▲page top]