「電波とどいた?」
2006/11版 その3

2006/11/22 (水)

Q10 (雑記)

_ ああ、コエンザイムQ10、必須な物質だけど、人体内で合成 できてしまうので経口摂取の必要がなく「ビタミン」には 入ってない物質ですね。

_ 過剰摂取に害がある(早死にする)という研究結果がでてきて、 魅力を失ったビタミンEに変わる健康食品のホープです。 抗老化作用が売り文句ですが、本当にそんな薬効があるかどうかは よくわかっておらず、また、そもそも摂取する必要がないということもあり、 摂取障害の研究もすすんでないようなので、かなり眉唾つけといたほうが良いです。

_ コラーゲンは保水作用があるので、化粧品に使われる(皮膚にぬる)意味は あるわけですが、それが皮膚から吸収されるような印象を与えたり、 経口でも特別な意味があるように誤認させてるものが多いです。

_ 蛋白質なので、消化の過程で一度アミノ酸までばらばらに分解・吸収されてから、 再合成されるので、普通に豚肉なり鶏肉なりの形で摂取するのと変わらないのに 「老化するとコラーゲンが不足するので補給しましょう」 といった表記をよくみかけます。 お肉食べるより消化はいいのと、脂肪をとらない意味はあるのかもしれません。 ビタミンは確実に不足しますね。あ、それもサプリでとるのか(苦笑)。

_ コラーゲン食品って、ぶっちゃけ「プロテイン食品の一種」なわけですが、 そう書くとなぜか印象がかわる不思議(笑)


なつぽち (えろげ, 吉里吉里)

『なつぽち』応援バナー

_ あ、本日発売じゃん。 システム提供+画面制御系の組上げのみうちが担当。 スクリプティングは中の人が全面的に作業をされています。 さくさくっと KAGEX の諸機能を使いこなしておられました。 さすが。

_ ALCOT さんが旧来つかってたシステムはかなり堅実で、設計思想の発想も とても良いもの(特にセーブロード処理まわり)なのですが、いかんせん 最近よくあるような演出処理を行なうには時代遅れの部分がありました。 が、改良(というか新規開発レベル)してもらおうにも、開発者の方は、 もう疲れてこの業界を引退されていて^^; いかんともしがたく、 めぐりめぐってなんか話がまわってきたという……。

_ 要望のあった演出用の機能はともかく、 セーブロード処理周辺は、KAG も KAGEX も設計が悪いので、 ALCOT さんとこの旧システムに近い発想(=実はまねしたのでうちの 旧システムも同様。あと KAGEX の world 機能でのシナリオ記述スタイル 自体がもともとこれのまねなのは秘密)に直したかったところではあるのですが、 間に合わずでそのままです。これは次にはどうにかしておきたいところ。

_ あー、あと 吉里吉里/KAG のなにがダメかって、UI 記述の言語が 独立していないことですね(断言) まあ、他にできてるものがあるかっつーとなかなか無いとは思いますが。

_ KAG ではもともとノベル用につくられてる「メッセージ窓」を流用 してシステムパーツを組むのが定番です。この時、メインのゲーム 処理を止めるわけにはいかないので、サブの実行系を使えるのですが、 表示の切り替えとかでトランジションをつかいはじめると、けっきょく ゲーム本体側の状態にばりばり影響がでてきて、破綻しない記述は 不可能ではないですがわりと綱渡り。ここを直すとあそこが変になる、 で、バグつぶしに苦労しまくり orz

_ さらに選択窓機能とか UI 系に追加機能を足してある部分との相互作用も かなり悩ましいことに。複数のメッセージ窓だしたときのフォーカス 制御系もよくわかんないというか KAG では制御しきれないとかいろいろ罠が。 テンポラリにセーブしとけばもしかしたら楽勝なんじゃ? という手は作業完了して気付いたので未検証。

_ あとなかなか気付かなかったバグというか、問題動作。 パーツ配置しまくったまま表示OFFにしたコンフィグ画面、 内部的にはのこってるので、トランジションのときに まきこまれて、ちょっとだけどつっかえる orz 私は気付かなくて、スクリプト作業されてた先方の担当者さん がタイミングの差で気付いておしえてくれて判明したのでした^^;

_ そもそも UI パーツが表裏の切り替えに巻き込まれるのが根本的に まちがってるんじゃーってことで、独立した新規のUIフレームワークを いませっせと某氏に書いてもらっております。これのために メモリ余分に食うのがいやだなーとかおもってたのですが、 dee さんが 2.2 系列の改良作業ということでレイヤに hasImage 機能を いれてくれたので万事解決。処理系本体は一般公開部分に入るのでおたのしみにー。

_ 私はコアの再生系の新しいの書いてるので手がまわらないのぢゃよ。 次(年末〜1月リリース予定のもの)の次の世代(来年2月頭以降リリース 予定のもの)では全部差し換えれるといいなー。



2006/11/26 (日)

メモ書きツール (PC)

_ メモのような書きかけレベルの文章を、共同で記述したり、 そのまま半公開するような用途に良いツールはないものですかねぇ。

_ 要件

  1. プレーンテキストではなく、画像を含む構造化文章を扱うことができる
  2. 階層構造をもつ文章群を総合的に扱うことができる
  3. 構成履歴管理機能を持つ
  4. 複数人の同一文章に対するそれぞれの作業をマージできる
  5. オフライン(ローカルディスク上のワーキングコピー)で編集できる
  6. 文書またはフォルダ単位で、グループ/メンバー単位の読み書きアクセス権限が付与できる
  7. 文書またはフォルダ単位で、一般向け閲覧用にWEBにパブリッシュできる

_ パブリッシュ・ユーザ間共有的にわりと有利な(はじめから共有されてるのでマージの必要がない)、 Wikiベースや、オンラインドキュメントツールなどのWEBサービス系のツールは、 いくつか試用はしてみましたが、どうしてもその操作性、特にレスポンスが満足できません。 回線速度がもっともっとあがるとまた変わるかもしれませんが、現時点では まだまだドキュメントはローカルで作業したいものです。容量でかい画像とかも扱ってると特に。

_ MS Office の OneNote は、構造化文章(構造が個人的には不十分だけど) を扱えるメモツールとしてはなかなか良いものなのですが、 共有については基本的に LAN での Windowsファイル共有、 または SharePoint が前提で、 オフライン作業となると Windows 「オフラインファイル」機能の上でのものに なるため同期が本当にうまくいくのかどうかの点でさっぱり信頼がおけません。 多人数作業のマージとか無理ぽ。

_ どうやら OneNote 2007 では、ローカルコピーベースでオフライン作業をした ものをファイル共有上にある共有ノートにうまくマージ処理する「自動同期」 という機能強化が行われているようなのでそれにはちょと期待。 どうせなら Word や Excel にも同種の概念が入ればいいのに。

_ ちなみに MS 的にはファイル単位でのオフライン同期は今後は Office Groove の担当のようですね。 「オフラインファイル」は使い物にならないってのは前から気づいてたんでしょう。 履歴管理は SharePoint で実現したけど、結局オフライン同期の問題は どうしようもない状態だったところに、以前から目をつけてた Groove を買ってきて、 そのワークスペースがうまく SharePoint と連携できるように機能追加して、 履歴もオフライン共有もばっちりだといったところでしょうか。

_ Groove は「サーバいらずのグループウェア」的な取り上げかたを されることが多いですが、この SharePoint との融合による 「ワークフォルダ方式の構成管理ツール」という側面はわりと 重要なんじゃないかと思います。あとは容量と速度的にどのくらいたえられるのか……

_ ああそうか、この方向にすすむのなら、エクスプローラが SharePoint を直接 参照できなくても特に問題はないわけだ。なるほど。 時に、OneNote 2007 のノートは Groove でどう処理されるんだろう。 うまく自動差分と同等のマージ処理が行われるんだろうか。 あと、Groove はライセンスのみで一般通常販売はないみたいだけど。 Action Pack にははいってくるのかなぁ。

_ 話を戻すと、OneNote はメモとるにはいいんですが、部分的に一般公開むけに 調整、とかそういったあたりもむいてません。一応メニューからの HTML や DOC へのエクスポートはあるのですが、かなりいまいちです。せめてデータ形式が XML なら……なのですが、OneNote2003 は独自のバイナリでした。 2007 ではどうなってるんだろう。

_ 結局のところ、私がほしいものってのは、構造的には Subversion などの情報マージ型の構成管理ツール+それへの高度な インポート/エクスポートってですね。 プレーンテキストなら Subversion で管理しきれるので、 プログラミングでのソース共有とかには素のままで十分なのですが、 構造化文章をまともに扱うことが困難なのが悩みの種です。

_ バックエンドとして Subversion を使って、オフライン作業と同期を 担保した、構造化されたドキュメントの編集&差分検出&マージ処理を一手に 処理できる、OneNote のようなメモツールがあればいいんだなー。 一般公開処理のほうは、指定された範囲についてレポジトリからデータを ひきだして、それを HTML に変換かけて公開用ページ群を自動生成とか そんなかんじで。

_ というかあれだな、メモに限る必要はないわけで、 Groove のような P2Pベースのローカルへのファイル同期技術を ベースにしたグループウェアがありなら、構成管理ツールベースの ローカルへのファイル同期技術をベースにしたグループウェアもありなんだな。 スケジュールとか、データ構造をきめて、ファイルとしておいておけばOKな 形にすればいいわけだ。コンフリクト問題は、データ構造を工夫して プログラムにエディットさせることでおおむね回避できるだろうし。

_ だれかつくってくれー。




メールはこちらへ...[わたなべごう (go @(at) denpa .(dot) org)]

この日記は、GNSを使用して作成されています。