１ＴＢのデータを転送するなら、ネットワークよりフットワーク

ここのＧＩＧＡＺＩＮＥの記事
大容量のデータを効率よく転送する方法
http://gigazine.net/index.php?/news/comments/20070521_tb_data_transport/
によると（以下斜体は上記サイトより引用）

もし1TBのデータを100Mbpsの通信回線で転送した場合、100Mbpsの回線は1時間ごとに45GB程度のデータを転送することができるそうです。もちろんこれは100Mbpsフルの速度が出た時の話。そして1TBのデータすべてを転送し終えるには、およそ丸一日かかるとのこと。

そしてこれを言い換えると、1TBを超えるデータを転送する場合、FedExなどの宅配サービスを利用した方が早く転送できるそうです。つまりデータが入ったHDDなどのストレージを宅配業者に預けて、相手に直接渡してもらった方が早いということ。


検算：
１００ＭＢＰＳ＝１秒間に１２．５Ｍバイト
　　　　　　　＝１時間に３６００秒＊１２．５Ｍバイト＝４５０００Ｍ＝４５Ｇバイト
ほんとーだー（＾＾）
１Ｔバイトだいたい１０００ギガバイトなので１０００／４５＝２２時間以上
ほんとーだー（＾＾）！！

むかし、ＤＴＰの人たちが言ってた、
ネットワークよりフットワークっていうやつですね（＾＾；）

似たような世界の話で、
Ｅｘｃｅｌでマクロ組むより、
電卓たたいたほうが早いっていうときもあります（＾＾；）

YouTubeを一日中見ている「検索Gメン」とか出来るのかな（＾＾）

ここの痛いニュース
「著作権法の非親告罪化」で“同人作家”等に深刻なダメージか
http://blog.livedoor.jp/dqnplus/archives/977113.html
が話題のような。。。

これの元ネタ、
たけくまメモ
【著作権】とんでもない法案が審議されている
http://takekuma.cocolog-nifty.com/blog/2007/05/post_b72f.html
をみると、

知的創造サイクルに関する今後の課題（保護分野）
http://www.kantei.go.jp/jp/singi/titeki2/tyousakai/cycle/dai8/8siryou2.pdf
（PDFです）の１５～１７ページが問題となっているらしい。。

一瞬、
えー、著作権って言ったら、ニュースも著作権あるよねえ。。
ニュースをコピーするのとかもダメなの（＞＿＜！）
うーん、そしたら、政府に都合が悪いニュースを引用してブログ書いたら、
つかまったり、消されちゃうのかなあ。。
って思ったけど、そこを読んでいくと

（以下斜体は、上記PDFからの引用）

（２）具体的方策
　　著作権等侵害のうち、一定の場合について、非親告罪化する。

　「一定の場合」として、例えば、海賊行為の典型的パターンである営利目的又
は商業的規模の著作権等侵害行為が考えられる。

　営利目的の侵害行為は、その様態から侵害の認定が比較的容易であるとともに、他人に損害を与えてまで金銭を獲得するという動機は悪質である。また、営利目的ではなくても、例えば愉快犯が商業的規模で侵害を行った場合には、権利者の収益機会を奪い、文化的創造活動のインセンティブを削ぐなど、経済的・社会的な悪影響が大きい。


っていうことだから、ブログに引用するって言う程度では、営利目的ではないのでOK。。。かなあ。。たぶん（＾＾；）

---

　でも、後者の「商業的規模の著作権等侵害行為」っていうのは微妙ですよねー
　これって、YouTubeにアップするのとかも入りそうな気がする。。

　もし、そーなったら、YouTubeを一日中見て、
　「はいこれ、著作権侵害！」っていうことで、逮捕に向かう
　検索Gメンとか、できるのかしら。。。

　なんか、そのGメン、楽しそうだな。。
　一般公募かなあ。。（＾＾；）

　。。。そーいう問題じゃないだろって、おこられそうなので、
　このへんで。。

プログラムやテストデータを自動生成する方法 その１０ TIPS

雛形ソースを作成し、Excelの仕様書を用意すると、プログラムのソースやテストデータを生成する方法について説明するシリーズ、「プログラムやテストデータを自動生成する方法」です。

　第二回目でインストールをしました。
　それから５回目までで、概要を説明しました
　そして前回までで、DBの例を説明しました
　過去のものに関しては
　ここ http://www.geocities.jp/xmldtp/index_zido.htm
　にリンクしてあります。

　今回は説明していない部分っていうか、TIPSです。

---

■タグ開始、終了記号$#$を出力するには

　たとえば、雛形ソースから雛形ソースを出力するなどというケースでありえるのですが、タグ開始、終了記号である$#$を出力するには、どうしたらいいかというと（雛形にこう書いてあると、すべて、タグの開始または終了とみなすのでかけない）

１．仕様書のどこかのセルに$#$と書きます
　（たとえば、セルN1に$#$って書いたとしましょう）

２．CELLタグでそこを指定します
　（$#$CELL N1$#$とかきます）

そうすると、 $#$と出力できます。以上

---

■作業一覧をみせたくない

　作業一覧を見せたくない場合、
　　書式→シート→表示しない
　にすれば、シートが見えない。。。って、そーいう問題じゃない（＾＾；）

　もし、作業一覧に書く内容が自動化できるのであれば、

　前処理（initAppData）で「作業一覧」シートを作成し、
　後処理（freeAppData）で「作業一覧」シートを削除してもかまいません。

---

■複数のシートの情報を利用したい

　前処理で、複数のシートを元に、作業用シートを作成し、
　作業用シートを「作業一覧」に指定してください
　（後処理で作業用シートを削除する人もいると思います）

---

■雛形ファイルを、仕様書の内容によって書き換えたい

　前処理で、好きなように書き換えてください。

---

■出来上がったファイルを１つにまとめたい

　後処理で、出来上がったファイルを読み込み、１つにまとめてください。
　その場合、読み込んだファイルは削除するのかな（＾＾）

---

こんなかんじです。
次回から、実際に中で、何をやっているのかについて説明します。

天才を多く作っても、現場は救われなさそう（－＿－；）

ここのニュース
IPA、未踏ソフト事業で「スーパークリエータ」15名認定
Web APIのパッチ合成やWeb上の“けもの道”マッピングなど
http://internet.watch.impress.co.jp/cda/news/2007/05/15/15705.html

IPAの施策は、天才といわれる人を多く作って、世界に売り出そうって言うみたいだけど。。。どーのかなあ。。現場のニーズの感覚と離れすぎちゃったりしないかなあ。。

　むしろ、天才じゃなくってもつくれるフレームワークをじゃんじゃん公開しちゃったほうが、産業的にも発展するし、多くの人々が救われるし、層が厚くなれば、世界的なソフトも出てくるだろうと思う。

---

具体論でいこう。

そこに
PatchService　http://www.patchservice.net/
というのが紹介されてるけど、現場的にほしいのは、SOAP、RESTだけじゃなくって、普通のプログラムでも何でも、関数なりメソッドなりが登録できて、それを、フローチャートみたいな分かりやすい図で可視化して表示する方法だと思う。

　これを実現するには、

（１）SOAP、RESTだけじゃなくって、普通のプログラムでも何でも、
　統一的に表現し、登録できる方法（仕様書と変換方法、共通形式）

（２）フローチャートみたいなものを作るプログラムの考え方、
　　　フレームワーク

（３）それらをプログラムに落とし込むための方法

だと思う。

---

（１）に関して言えば、
（あ）クラスをXMLで表現し、入力も出力もXMLで表現すれば、DOMで扱える。
　この形式をXMLフォーマットをまず決めて、

（い）REST,SOAP,普通の関数をこの変換方法に展開する方法を考える

（う）（い）は、XMLを出力する雛形フォーマット
　。。とくれば、このブログをお読みの賢明な読者ならおわかりのとおり。。
　あとは、それぞれの仕様書のフォーマットをきめれば、
　自動生成に落とし込め、
　既存の仕様書を今回決めた仕様書にマクロとかで変換できれば。。
　って言う話になってくる。

---

（２）に関して言えば、
　こういった、DTPやドローイングソフトなんかのつくりかたは大体決まっていて、

（あ）それぞれの構成要素のクラスをつくり

（い）それを、リンクさせていく（連結リストの応用なのだ）

（う）表示時は、それぞれの構成要素が座標を持っているので、それを表示させ
　（というか、構成要素のクラスでdrawメソッドがあり、そいつを使う）

（え）構成要素の追加削除があったら、
　　　　リンク関係を変えて、
　　　　位置の再評価をして、
　　　　再度draw
　　（変更の場合は、構成要素の内容を変えて、再度drawでOK)

（お）あとは、画面上でリンクされたオブジェクトをチェックする方法
　　→メモリ保持方法はカオル姫方式にしておけば、ばっちし

　なんだけど、なに言ってるかわかんないと思う。
　これについては、土日シリーズのＤＴＰの構造を考えるの、あと数回先から書くと思います（DTPソフトの基本構造のところで。。次回はカラーマネジメントの予定なんで関係ないけど）

---

（３）に関しては、
・それぞれの図で表現されたもののプログラム対応
　→これも雛形があればOKなのだ。。

・REST,SOAP,普通の関数を統一的に扱うラッパー

っていうことになる。

---

　むしろ、こーいう部分に関して、どんどん紹介していって、雛形を作って、ワーカーさんでもつくれるように、いや、一般企業の情報システム部の人でも作れるようにすることのほうが、現場と直結して、ビジネスも大きくなると思う。

　天才が、ワーカーさんから離れて、完成品を出すよりも。。。



　え、そーいう紹介は、お前がやるからいいだろうって。。



　確かにそのとおりですね（＾＾；）