Google、「エンタープライズ Blog」を開設

ここのニュース
Google、「エンタープライズ Blog」を開設
http://headlines.yahoo.co.jp/hl?a=20071210-00000033-inet-inet
によると(以下斜体は上記サイトより引用）

グーグル株式会社は2007年12月10日、エンタープライズの Blog を開設し、Google 検索アプライアンスと Google Apps の情報を発信していく、と発表した。


これって、グループウエアとか、文書管理とかやってた会社にとっては、やばいんじゃない！
Googleも、スケジュールとか、そーいうサービスをやっているけど、エンタープライズ用というのが実はある（そうだ）。だけど、みんな知らなかったから使わなかったけど・・・そーいうのが分かっちゃうと（＾＾；）

　ただ、ウィリアムのいたずら的には、Google Mapの完全な社内利用が、Google Apps によって、OKになるのかどうか（Google Map APIが商業利用できるのは、たしか、あくまでも、それが他にアクセスされる場合であって、完全に社外の人に見えないものに対しては認めていない）っていうところに、興味しんしんなので、そーいうのを書いてくれたらと思うんだけど。。

　あ、ちなみに、そのGoogleの「エンタープライズ Blog」ってのは
ここ　http://googleenterprise-ja.blogspot.com/

DTPなどのアンドゥや受発注の取り消しを考える

■在庫の取り消しと受発注の取り消し

在庫は、

　　現在の在庫＝期首の在庫－期中から現在の出庫＋期中から現在の入庫

となることが知られている（っていうか、ちょっと考えれば分かる）
　したがって、入庫のキャンセル（すなわち返品になるが）する場合は、入庫なら入庫数マイナス、出庫なら出庫数マイナスをすればできる。何日前の在庫を求めるのでも、その日にちの在庫数を持っていなくても、出庫数、入庫数が分かればもとまる。

　受発注の取り消しの場合は、入庫・出庫のキャンセル＋入金、出金のキャンセルがあるが、これは、出来ない場合がある。理由は、入金や出金のキャンセルは、銀行やカード会社で決済されてしまうと、それを取り消すことが出来ないからだ（決済前であれば、決済金額を変更すればいいだけなので可能だけど）。
　この場合は、単純なキャンセルではなく、なにか、別業務を考えなければいけない。

---

■DTPのアンドゥ

　DTPなどのアンドゥ（元に戻す）を実現する場合、２つの方法が考えられる

（１）操作ごとに関連するデータを全部保持し、スナップショットとして持っている
（２）操作履歴をとっておいて、逆操作を行う

（２）が、いままでの話の、入庫・出庫のキャンセルに相当する。

（１）の場合、データが大量になる。（２）の場合、逆操作をおこなっても、かならずしも、元のものと一致しない。では、（２）で元のものと一致しない操作というのは、どのような場合なのか？（さっきだと、決済があるときは戻らない）、一致しない場合は、どのような操作を考えればよいのか？

---

■どういうときに、取り消し可能なのか？

　ちゃんと証明できないけど、以下のときに可能な気がする

（１）単位元の存在
　　これは、何もしない操作だと思う。ふつう

（２）逆元(逆操作）の存在
　　何もしない操作に戻る方法がある。

---

■DTPの操作で考える

DTPの操作は、こんなかんじ。

（１）切り取り
（２）貼り込み
（３）移動
（４）変換（ポイントからミリなど）
（５）設定（幅、高さ、フォント、色そのたもろもろ）

で、このとき、（１）切り取りの逆操作は、（２）貼り込みで、（２）の逆操作は（１）になる。
　ただし注意したいのは、大きな丸の上に、小さなまるが重なっていたとき、
大きなまるを削除し、小さなまるの上に貼りこむと、小さなまるは隠れて見えなくなり、以前の絵とは違う。

　このように、絵の場合は、重なり具合を考慮し、レイヤ番号を導入し、そのレイヤに貼りこむことになる
（１図形１レイヤにしておく）

　（３）の移動は、基本的に、逆操作は存在する。
　なぜなら、移動とは、コンピューター上、XYZ座標の加法、または減法である。そして、XYZは、実数または整数である。実数や整数における加法・減法は、群をなしている。群は
　　G１.結合法則
　　G２.単位元　０
　　G３.逆元
が、あるとき、群になる。このうち、今話題にしているのはG２、G３の性質だから、逆操作は存在することになる。


（４）の変換は、存在しないことも多い。
　変換は、XYZ座標や色空間（RGB,CMYK)における単位系を変える為の四則演算だが、
　XYZ座標を整数で表す場合、四則演算に関して、割り算は群をなさないし、RGB,CMYKなど、色空間の変換は、逆元以前に、１対１ではない（表現できない色というのがある）
　なので、変換においてはなりたたない。

（５）設定も成立しない、というか、設定は１対１対応ではなく、以前の値が何であれ、この値にするという形である。つまり、設定された値から、元の値を推測することはできない。

　とすると、切り取り貼り込み移動くらいしか、できない？

---

■逆元が成立しないものに関して

　ここで、ある属性の置換というものを考える

　replace("対象.属性項目",元の値,設定値）;

　この場合、"対象.属性項目"を設定値にするという操作だが、この逆操作は、
　"対象.属性項目"をもとの値にする、すなわち

　replace("対象.属性項目",設定値,元の値）;

　である。（４）、（５）に関しては、上記のように、

・設定したい値の項目の変更前の値をとっておいて
・replace関数に置き換えれば
・元に戻る

ということである。

---

■操作番号と位置を入れる

１回の操作において、複数の値をかえることになる。
そこで、操作一つ一つに、操作番号を導入し、かつ、複数並んでいる項目（文字列とか）もあるので、その場合、位置番号も入れる。そうすると、

ある操作をおこなったとき
その操作の位置の、元の値と、操作後の値を

　replace(操作番号,"対象.属性項目.位置",元の値,設定値）;

で残しておけば、（すべての値を保持しておかなくても）

一つ前の操作は

　replace(一つ前の操作番号,"対象.属性項目.位置",設定値,元の値）;

の処理を全部行えば、元に戻る・・

といえそうな気がする・・・

どーだろー（＾＾；）

P.S　社会的に絶対に可逆しない、決済のようなものが含まれている場合は、
　replace(一つ前の操作番号,"対象.属性項目.位置",設定値,元の値）;
をやっても、もとにはもどらないので、だめ。

ロボットって、部品ごとに、IPV6で通信してくれると、いいと思うんですよ！

　きのう、IPV6の話を書いたので、今日も・・

　あくまでも、インターフェースボードが小型化しないと無理ですけど、ロボットって、部品ごとに、IPV6で通信してくれると、部品が交換できて＆部品ごとに集められて、いいとおもうんですよ。

---

　たとえば、手のパーツとかがあって、手の部分から、線が出ていて、それが、通信部分とつながっていて、通信部分では、IPV6で入出力するジャックがあると。
　で、ロボットに組み込むときは、腕、足とかは、真ん中を空洞にしておいて、手の線は、そこをとおして、ロボットのおなかの部分に、通信部分を置くと（ネットワークカードみたいにさすようにするのかな？）。

　そうすると、手を動かすときの命令、足を動かすときの命令というのは、共通化できる（差異の部分は、その通信部分から出る信号を、部品ごとに変えればいい）。そーなってくると、ロボットに対する命令も、(ロボット自身には、差異があっても）共通化できる

　たとえば、走れ！という命令をしたら、ロボットがそれを受け取って（ロボットの中に、コンピューターがあって）、手をどれだけうごかせ、足をどれだけ動かせと、指示を変換する。この変換方法は、ロボットによって異なる。で、指示を出すには、足とIPV6アドレスの対応テーブルを作っておいて（接続したときにつくる。接続されると、部品はブロードキャストするようにすれば良い）、足とか手とかに命令を出す。この命令も共通化されているので、足（タイヤの場合もあるかも）や手は、それに応じて、独自に変換して、走り出すことが出来る。

　で、IPV6にしておけば、パソコンに直接つないで、そーいうソフトを作って、共通化して、操作、テストすることができる。パソコンから、直接命令することもできる。

---

　っていうメリットもあるけど、ウィリアムのいたずら的には、部品がバラで買えて、集めて言って楽しめる、部品ごとに高級なものにも変えられるし、壊れたとき部品だけ直せばいいって言う点がいいですね。

　安くてロボットがたのしめそうだ。。