目標： 月１回以上更新すること
> ホーム <
前回の続き。
図の階層構造そのものがこのWikiの特徴。
一番上の階層「Storage」は、いろいろなデータのフォーマットや保存場所だけが定義されている。
しかし、ユーザーやアドオン開発者は保存データの構造を気にする必要はない。それどころか、このStorage階層に直接アクセスすることは許されない。
データにアクセスするには、真ん中の黄色い部分、「Core APIs」と名付けられた関数群をもちいなければならない。
「～ならない」と表現すると、一見うっとうしい制約がついたように見えるが、「Core APIs」はWikiデータの操作を制限するものではなく、単なるラッパーである。
「ラッパー」がどういうものかについては、この辺を参考にしていただきたい。
つまり、「Core API」を使えば、アドオンの開発者は日本語のページ名をURLエンコードしたり、ファイルのXMLデータを解析したり、セッションの情報からユーザー名を取得したり、…、というコードを書く必要がないのである。
ピンク色の「Cache Controller」は微妙な位置づけの機能。
通常WikiではWiki形式のデータをHTMLに変換する必要があるが、ページが呼び出されるたびに変換するのは負荷がかかるから鬱陶しい。
ということで、
・ページを編集するときはWikiデータを垂れ流し、保存時にHTMLへの変換をしてキャッシュに保存する。
・ページを普通に呼び出すときはキャッシュデータを垂れ流すだけ
という負荷軽減機構だ。よく使われる手段だけどね。
ほかの部分は他所のWikiシステムと大差ないので省略。
強いて違いを挙げるならHTMLだけじゃなくてPDF形式でも表示できる、といってもこれも既存の機能。
さらにユーザーが好きな出力形式を追加できるようにしよう。XHTMLとかTeXとかXPSとか…
まあ、プラグインの簡単インストール機能とかついてたほうがユーザー的には嬉しいけどね。
あと、画像とかのファイルは「Media」の部分にまとめて保存する。ページごとに添付する方式は鬱陶しいから廃止。
一応フォルダとかカテゴリの機能をつけて整頓しやすくするが。でもそうすると画像のパス名が長くなるんだよな…
using namespace ***
的な文法でも付けとこうか。
RIA……それは「リッチインターネットアプリケーション」の略。
FlashやAjaxを多用したブラウザ上で動く高性能ツールの総称だ。
例えば、GoogleカレンダーとかGoogleマップはその典型例。
RIAは意外と何でもできる。
俺のサイトで作っている「電光掲示板メーカー」「爆割」などはその気になればRIAに移植することも可能だと思う。
ということは、我々が作っているダウンロード型のソフトは廃れていく運命にあるのだろうか…
なぜなら、同じ機能のRIAとデスクトップアプリがあったら、消費者はすぐに使えて安全なRIAを選ぶのが当然だからだ。数年後には「なんだ、このソフトダウンロードしなきゃダメなのか、('A`)ﾏﾝﾄﾞｸｾ」ってなるかもしれない。
Kanchi Studioでもブラウザアプリへの移行を進めている。例えば、「液晶モニタ計算機」なんかは、わざわざダウンロードして使おうとは思わないだろう。
だが、RIAには弱点がある。作業中のファイルを保存するのが面倒だ。ツールによってはそのような機能が提供されているが、保存するたびにデータをサーバーに送信しなければならないので処理速度が低下する。また、データがネット上に保存されるので、個人運営のRIAを利用する場合はセキュリティにも十分気をつけるべきだ。（デスクトップアプリの方がデータを収集する悪質な奴が多いがｗ）
というわけで、RIAとデスクトップアプリは市場を奪い合うことはなく、機能が少なかったり、使用頻度が少ないものはRIA、機能豊富なものはデスクトップ、という棲み分けが進むだろう。むしろ、いままでソフトとして配布するのをためらっていたような低機能ツールがRIAとして増えることで市場が拡大する可能性もありそうだ。
FlashやAjaxを多用したブラウザ上で動く高性能ツールの総称だ。
例えば、GoogleカレンダーとかGoogleマップはその典型例。
RIAは意外と何でもできる。
俺のサイトで作っている「電光掲示板メーカー」「爆割」などはその気になればRIAに移植することも可能だと思う。
ということは、我々が作っているダウンロード型のソフトは廃れていく運命にあるのだろうか…
なぜなら、同じ機能のRIAとデスクトップアプリがあったら、消費者はすぐに使えて安全なRIAを選ぶのが当然だからだ。数年後には「なんだ、このソフトダウンロードしなきゃダメなのか、('A`)ﾏﾝﾄﾞｸｾ」ってなるかもしれない。
Kanchi Studioでもブラウザアプリへの移行を進めている。例えば、「液晶モニタ計算機」なんかは、わざわざダウンロードして使おうとは思わないだろう。
だが、RIAには弱点がある。作業中のファイルを保存するのが面倒だ。ツールによってはそのような機能が提供されているが、保存するたびにデータをサーバーに送信しなければならないので処理速度が低下する。また、データがネット上に保存されるので、個人運営のRIAを利用する場合はセキュリティにも十分気をつけるべきだ。（デスクトップアプリの方がデータを収集する悪質な奴が多いがｗ）
というわけで、RIAとデスクトップアプリは市場を奪い合うことはなく、機能が少なかったり、使用頻度が少ないものはRIA、機能豊富なものはデスクトップ、という棲み分けが進むだろう。むしろ、いままでソフトとして配布するのをためらっていたような低機能ツールがRIAとして増えることで市場が拡大する可能性もありそうだ。
PR
おれが使ってたことのあるメールサービス「yesyes.jp」。
プロバイダのメールアドレスがなくても登録できるのが特徴。
だが、2007年4月30日以来「メンテナンス中」らしい。
1年以上たってもメンテナンス中だ。
やはりフリーメールはサービス休止に備えて複数のサービスを使うべきだ。
プロバイダのメールアドレスがなくても登録できるのが特徴。
だが、2007年4月30日以来「メンテナンス中」らしい。
1年以上たってもメンテナンス中だ。
やはりフリーメールはサービス休止に備えて複数のサービスを使うべきだ。
俺が最初の日記と称して書いた怪文書を振り返ってみた。
というのも、このブログに初めてのトラックバックが来たから。
どうやら俺の考案した３つのブログ開設動機はさほど間違ってないようだ。
だが、もう一度熟読して（自分自身に）ツッコミを入れてみよう。
＞ 「アフィリエイト」があれば、ニュー速VIPのスレを延々とコピペする、なんていう面白くもない単純作業でさえ長続きしたのである。
確かに「アフィリエイト」が主目的ではあるが、コピペ作業がおもしろくない、というのは正しくない。なぜなら、VIPのスレ自体はおもしろいから。俺だって２ｃｈの気に入ったスレは自分のPCに保存するし。
＞ 自分に必要な情報を、HDDを増設しなくても保存できる。
いや、ブログのデータが1GBを超えるやつなんて少ない。HDDの残り1GB未満のPCなんて少ない。
＞ ブログのコメント欄とは、スコアアタック機能の一種である
ある記事にコメントが大量についたならば、その記事は悪い記事である場合が多い。
いわゆる「炎上」状態だ。
＞ 結局俺は何を言いたかったのだろうか…
何も言う気はなかったんだ。きっと長文を書いた方がかっこいいと思って書いたに相違ない。うん。
ちなみに今のブログは記事数がようやく２０を突破した。
今後とも（本家サイトで格好つけている）管理人の別人格を楽しんでいただきたい。
ブログは自分の感情に基づいて書くべきだ。あまり更新頻度や収入に囚われると内容に響く。
ブログで収入を得るのは別に悪いことではないが、２ｃｈに生息する嫌儲主義者にはくれぐれもご注意を。
というのも、このブログに初めてのトラックバックが来たから。
どうやら俺の考案した３つのブログ開設動機はさほど間違ってないようだ。
だが、もう一度熟読して（自分自身に）ツッコミを入れてみよう。
＞ 「アフィリエイト」があれば、ニュー速VIPのスレを延々とコピペする、なんていう面白くもない単純作業でさえ長続きしたのである。
確かに「アフィリエイト」が主目的ではあるが、コピペ作業がおもしろくない、というのは正しくない。なぜなら、VIPのスレ自体はおもしろいから。俺だって２ｃｈの気に入ったスレは自分のPCに保存するし。
＞ 自分に必要な情報を、HDDを増設しなくても保存できる。
いや、ブログのデータが1GBを超えるやつなんて少ない。HDDの残り1GB未満のPCなんて少ない。
＞ ブログのコメント欄とは、スコアアタック機能の一種である
ある記事にコメントが大量についたならば、その記事は悪い記事である場合が多い。
いわゆる「炎上」状態だ。
＞ 結局俺は何を言いたかったのだろうか…
何も言う気はなかったんだ。きっと長文を書いた方がかっこいいと思って書いたに相違ない。うん。
ちなみに今のブログは記事数がようやく２０を突破した。
今後とも（本家サイトで格好つけている）管理人の別人格を楽しんでいただきたい。
ブログは自分の感情に基づいて書くべきだ。あまり更新頻度や収入に囚われると内容に響く。
ブログで収入を得るのは別に悪いことではないが、２ｃｈに生息する嫌儲主義者にはくれぐれもご注意を。
前回の続き。
図の階層構造そのものがこのWikiの特徴。
一番上の階層「Storage」は、いろいろなデータのフォーマットや保存場所だけが定義されている。
しかし、ユーザーやアドオン開発者は保存データの構造を気にする必要はない。それどころか、このStorage階層に直接アクセスすることは許されない。
データにアクセスするには、真ん中の黄色い部分、「Core APIs」と名付けられた関数群をもちいなければならない。
「～ならない」と表現すると、一見うっとうしい制約がついたように見えるが、「Core APIs」はWikiデータの操作を制限するものではなく、単なるラッパーである。
「ラッパー」がどういうものかについては、この辺を参考にしていただきたい。
つまり、「Core API」を使えば、アドオンの開発者は日本語のページ名をURLエンコードしたり、ファイルのXMLデータを解析したり、セッションの情報からユーザー名を取得したり、…、というコードを書く必要がないのである。
ピンク色の「Cache Controller」は微妙な位置づけの機能。
通常WikiではWiki形式のデータをHTMLに変換する必要があるが、ページが呼び出されるたびに変換するのは負荷がかかるから鬱陶しい。
ということで、
・ページを編集するときはWikiデータを垂れ流し、保存時にHTMLへの変換をしてキャッシュに保存する。
・ページを普通に呼び出すときはキャッシュデータを垂れ流すだけ
という負荷軽減機構だ。よく使われる手段だけどね。
ほかの部分は他所のWikiシステムと大差ないので省略。
強いて違いを挙げるならHTMLだけじゃなくてPDF形式でも表示できる、といってもこれも既存の機能。
さらにユーザーが好きな出力形式を追加できるようにしよう。XHTMLとかTeXとかXPSとか…
まあ、プラグインの簡単インストール機能とかついてたほうがユーザー的には嬉しいけどね。
あと、画像とかのファイルは「Media」の部分にまとめて保存する。ページごとに添付する方式は鬱陶しいから廃止。
一応フォルダとかカテゴリの機能をつけて整頓しやすくするが。でもそうすると画像のパス名が長くなるんだよな…
using namespace ***
的な文法でも付けとこうか。
現在普及しているWikiに対する不満
・デザインが悪い。画像も殆ど使わずシンプルに見えるが、メニューとか最下部の文字列が過剰である。また、設計が古く、テーブルでデザインされていることが多い。
・プラグインの開発が面倒くさい。Wikiエンジンによっては有志のプラグインが多数あるものの、ちょっとしたプラグインを自作しようと思ってもプラグインの仕様がややこしい（むしろ説明不足）。PHPの初歩的な知識だけで開発できた方がいい。
・中身が（ブログと比べて）文字ばっかり。もっとグラフィカルなページを作るシステムが必要ではないか？
・インストールが面倒くさい。
というわけで巨大プロジェクトの１つが始動した。
(現在計画中の巨大プロジェクト＝Wikiクローン、次世代2chブラウザ、オンラインゲーム)
まずは今後の開発に必要な構想を練ることだ。
↓こんな感じのシステムにしたら開発が楽そうだ。
詳しいことは次回説明するとしよう。
・デザインが悪い。画像も殆ど使わずシンプルに見えるが、メニューとか最下部の文字列が過剰である。また、設計が古く、テーブルでデザインされていることが多い。
・プラグインの開発が面倒くさい。Wikiエンジンによっては有志のプラグインが多数あるものの、ちょっとしたプラグインを自作しようと思ってもプラグインの仕様がややこしい（むしろ説明不足）。PHPの初歩的な知識だけで開発できた方がいい。
・中身が（ブログと比べて）文字ばっかり。もっとグラフィカルなページを作るシステムが必要ではないか？
・インストールが面倒くさい。
というわけで巨大プロジェクトの１つが始動した。
(現在計画中の巨大プロジェクト＝Wikiクローン、次世代2chブラウザ、オンラインゲーム)
まずは今後の開発に必要な構想を練ることだ。
↓こんな感じのシステムにしたら開発が楽そうだ。
詳しいことは次回説明するとしよう。