日曜日, 1月 25, 2009

【雑記】 Yes, we can このエントリーを含むはてなブックマーク


 オバマ大統領の就任演説に感動。(1/24)オバマ新大統領の就任演説内容(全文)
 

我々はこの国の偉大さを再確認するとき、偉大さが決して当然のことではないと理解している。それは働いて得たものでなくてはならない。我々の旅路は近道や妥協であったことはない。憶病者や、勤労より娯楽を好み、富と名声の喜びだけを求める者の旅路だったこともない。むしろリスクをとり、行動し、物を作り出す人々が繁栄と自由への長いでこぼこ道を導いてきてくれたのだ。その中には高名な人もいるが、多くは無名の働く男女だ。

 彼らは私たちのためにわずかな所持品をかばんにしまい、海洋を旅し、新しい生活を探してくれた。

 彼らは私たちのために工場で汗を流して働き、西部を開拓し、むち打ちに耐え、硬い大地を耕してくれた。

 彼らは私たちのために(独立戦争の)コンコード、(南北戦争の)ゲティスバーグ、(第二次大戦の)ノルマンディー、(ベトナム戦争の)ケサンのようなところで戦い、命を落とした。

 これらの男女は私たちがよりよい暮らしを送れるよう何度も何度も苦闘し、犠牲を払い、手が腫れるまで働いてくれた。彼らの目に映る米国は、1人ひとりの大望の集積もさらに大きいものだった。生まれや富や党派の違いを超越した国だった。

 これが今日も我々が続けている旅だ。
<中略>
今日から我々は立ち上がり、ほこりを振り払い、米国を再生する作業をもう一度始めなくてはならない。

 なぜなら、どこを見てもなすべき仕事がある。経済の現状は大胆で迅速な行動を求めている。新しい雇用を創造するだけでなく、成長の新しい基盤を築くために我々は行動する。


 史上最低のバカ大統領のせいで歪んでしまった世界。もういちど原点に返ることで再生していかなければならない。どこを見てもなすべき仕事がたくさんある。私たちもマネーゲームや将来を心配することばかり時間を使うのではなく、「なすべき仕事」を見つけて、そこで働いて得たものを大切にしなければならない。我々の旅路は近道や妥協ではない。むしろリスクをとり、行動し、物を作り出すこと。そして、できると信じること。

 話はかわって、今日優勝した朝青龍。左ひじを痛めて進退のかかった場所での優勝を誰が予想できただろうか。
 もし初日の稀勢の里戦で負けていたら引退していたかもしれない場所だった。
 朝青龍の気迫は並大抵のものではない。場所全体の雰囲気を一変させるものすごい気迫。初日から絶対に負けられないという強い気持ちがオーラとなって溢れ出ていた。そしてそれが他を圧倒していたからこそ優勝できたのだと思う。

 できないと思ったら何もできない。できるという強い気持ちが不可能を可能にする。

 Yes,we can

とりあえず、今のプロジェクトメンバーへのメッセージ。

火曜日, 1月 20, 2009

【雑記】 コモディティかイノベーションか このエントリーを含むはてなブックマーク



IBM 技術理事 中島丈夫が語る「IBMテクノロジー戦略」 - Japan

中島さんの話のなかで「コモディティ VS イノベーション」が気になったので一言。

過去において、また現在もなお莫大な費用をかけてイノベーションに取り組む企業はIBMぐらいである。もちろんJCMベンダーにはそんな真似はできない。

IBMはこれまでイノベーションリーダーであった。JCMなどはIBMが発明したものを真似するだけでよかった時代もあった。しかし、最近は研究開発が実らず空回りしているような感じをうける。

IBMも一企業なのでコモディティに敏感になろうとするのはわかる。また、イノベーションのような顧客が少ないところでの商売のあり方に疑問を感じているのもわかる。しかし、イノベーションに取り組まないIBMなんて想像できない。

寂しいけれど今のイノベーションリーダーは明らかにGoogleである。
GoogleにあってIBMにないもの、それはイノベーションに対する貪欲さかな。

<関連>
失敗しないことがよいことか

日曜日, 1月 18, 2009

【雑記】 性善説と無責任 このエントリーを含むはてなブックマーク



性善説というと聞こえはよいが、この業界は時に性善説が災いをもたらすことがある。
性善説、性悪説とは以下のような考え方をいう。

性善説
(人の本性は善であり)人を信じるべきだという考え方
性悪説
(人の本性は悪であり)人は疑ってかかるべきだという考え方


性善説と性悪説のよくある誤解によれば、そもそもこれが誤解であるそうだが、私は他に適切な言葉を知らないので誤解のまま使うこととする。

私は以下のようなケースで性善説が災いしていると感じている。


1)設計書には間違いがない
2)ちゃんとプログラムを作れば正しく動く
3)ちゃんと管理すれば間違いは起こらない


問題は、ちゃんと動かなかったときにどうするか、ということなのだが、それを考えようと言い出すと途端にK.Y扱いされるので困ったものである。

ちゃんとやるだろうことを私も含めて皆が信じている。そしてシステムはちゃんとやれば動くはずである。もし動かなければ動くまで責任もってやるっていってる。なのに、それのどこが悪いのか?

私に言わせれば、「動かない場合のことをちゃんと考えないのが悪い」ということであるが、どうもうまく伝わらない。

ちゃんと動かすことを考えるのだから、動かない場合のことなんて今は考えられないことはよく分かる。ちゃんと動けばそれが杞憂に終わり、そして時間をかけて考えた「動かない場合のこと」は無駄になることになることも分かる。それでも、自分の力でできない可能性が少しでもある場合には、できない場合の対応策は考えるべきである。私はそれを考えない人は無責任に見えて仕方がない。

できない場合の対応策を考えてもらえない場合は、とりあえず、「何が起きても私は知らないからね。」とか、「その日は出張だから絶対にヘルプできないよ」ということで自己防衛することにしている。さらに、「私はうまくいかない方に賭ける」といって脅すことさえある。別に失敗する原因を知っているわけでも確信しているわけではないのだが、システムというのは大抵動かないもので、逆にシステムがちゃんと動いているのは奇跡のなせる業であり、たまたま動いているにすぎないと思っているぐらいがちょうどよい。(これは自分自身の経験に基づくものである)

しかし、性善説の輩は失敗することを全く考えない。

そして、案の上、失敗して私に泣きつく。
「ごめんなさい。私が間違いでした。だから何とかしてください」

私は君を何とかしたい。

月曜日, 1月 12, 2009

【クラウドコンピューティング】 クラウド予想2009 このエントリーを含むはてなブックマーク



久しぶりによい記事を読んだ。

クラウド型ストレージ「Amazon S3」は安いか?

クラウド・コンピューティングバトル2009


<私なりのクラウド予想2009>

1)コストダウンは急速に進む

実はS3はそれほど安くない。しかし、私は楽観的に考えている。Google、MSなどクラウドプレーヤーの大競争が始まればコストダウンは急速に進むだろう。

2)Google Appsの一人勝ちだが一般的には広がらない

セキュリティは技術以外の問題もあり簡単に解決できないので、多くの企業がGoogle Appsに群がることはない。Microsoft Online Servicesは健闘するがGoogle Appsには太刀打ちできない。Notesやサイボウズなどからの移行はあまりない。

3)クラウドを利用したWebサービスは多く登場する

去年ブレークしたDropboxやMorph Appspaceなどのように、Amazon S3を利用したサービスが多く登場するだろう。そして最初は無料。
企業ではアプリケーションの2次キャッシュやデータバックアップ場所として利用されていくだろう。

4)大手ITベンダはクラウドの大合唱

毎度のことだが自分たちの製品をクラウド対応とか言い出す。コンサルがミソクソな話をしだす。

5)OracleやMSは自己矛盾には陥らないが苦戦する

「マイクロソフトやOracleにとって、自社の収益を共食いせずに従来の顧客とSaaSの顧客の双方を取り込むことは難しい」といわれるが私はそうは思わない。新規の顧客開拓は両者にとっては厳しいが、クラウドをやることで既存顧客の囲みこみは成功するだろう。やらない大手ITベンダーはもっと苦戦する。>IBM

日曜日, 1月 11, 2009

【JavaScript】 ISO8601日時をパースする正規表現。ついでにJavaも このエントリーを含むはてなブックマーク



"2002-06-17T09:25:43.4670000+01:00" のようなフォーマットのISO8601日時をDateにして返す関数はJavaScriptでは以下のようになる。正規表現を使ってマッチした()の1つ目が$1、2つ目が$2・・・7つめが$7に入る。(replace()関数外のためRegExp.$7のように参照している)


// http://www.merlyn.demon.co.uk/js-date3.htm#XML
function parseISO8601(isodatetime) {

   var newdate = isodatetime.replace(/^(\d{4})-(\d{2})-(\d{2})T([0-9:]*)([.0-9]*)(.)(.*)$/,'$1/$2/$3 $4 GMT');
   newdate = Date.parse(newdate) + 1000*RegExp.$5;
   var k = +1;
   newdate -= k * Date.parse('1970/01/01 '+RegExp.$7+' GMT') * (RegExp.$6+'1');
   return new Date(newdate);

}



ちなみにJavaではこんな感じ、


   protected Object fromString(String str) {

      try {

         // Date/Time ISO8601 TIME ZONE FORMAT 2006-02-10T10:00Z.
         // slow but,thread safe

         SimpleDateFormat isoformat = new SimpleDateFormat(
               "yyyy-MM-dd'T'HH:mm:ssZZ");
         return isoformat.parse(str);

      } catch (ParseException e) {
         // try with next formatter
      }

   }

   protected String toString(Object obj) {
      SimpleDateFormat isoformat = new SimpleDateFormat(
            "yyyy-MM-dd'T'HH:mm:ssZZ");
      return isoformat.format(obj);
   }



Javaの正規表現


import java.util.regex.Matcher;
import java.util.regex.Pattern;

public class Iso8601 {

/**
* ISO8601日時を正規表現で分解して取得する
*/

public static void main(String[] args) {

Pattern pattern = Pattern.compile("(\\d{4})-(\\d{2})-(\\d{2})T([0-9:]*)([.0-9]*)(.)(.*)");
Matcher matcher = pattern.matcher("2002-06-17T09:25:43.4670000+01:00");

if (matcher.find()) {
System.out.println("ALL:"+matcher.group(0));

System.out.println("YY:"+matcher.group(1));
System.out.println("MM:"+matcher.group(2));
System.out.println("DD:"+matcher.group(3));

System.out.println("TIME:"+matcher.group(4));
System.out.println("msec:"+matcher.group(5));

System.out.println("+-:"+matcher.group(6));
System.out.println("TZ:"+matcher.group(7));

}
}

}


水曜日, 1月 07, 2009

【JavaScript】 高速化プロジェクト その2 このエントリーを含むはてなブックマーク


 先の投稿からずいぶん時間が経ってしまったが続編「その2」を書いてみる。

まず、問題となったものがどんなアプリかであるが、これは下図のように、スプレッドシートのような動作をするJavaScriptアプリで、サーバから必要なデータを初期表示の際にいっぺんに取ってきて、あとはブラウザ環境だけで動作するというものであった。タブを押すと別の画面が表示されるがサーバへのアクセスはない。表示されているタブの中に複数のテーブルがあり値を入力変更できる。しかし、値を変化させると隠れている他のタブの値まで影響するので、計算が多岐にわたって遅くなってしまう。これにはいくつか問題となるコーディングがなされていた。



問題となっていた部分を改善して効果があった順に挙げると以下となる。

1)イベントリスナーの多用をやめる
2)DOMへの直接参照をやめる
3)数値計算の誤差は最後にまるめる

1)イベントリスナーの多用をやめる

 図を見てもわかるように、入力域は1テーブルで約50で、それが4~5あるのだから、合計約200~300の入力域になる。これら一つ一つにイベントを登録してしまうと、とっても遅くなる。これで悩んでいたころに、JUIというイベントがあって、JavaScriptいろいろ、個人的にOpenID そこでma.laさんが、DEMOを披露してくれて、DOM操作の高速化についていろいろ教えてくれた。懇談会ではイベントリスナーは1つというようなことをおっしゃっていたが、DEMOでは、on click で実装したおられたので真似してみた。これは非常に効果があった。

2)DOMへの直接参照をやめる

 サーバサイドのオーソドックスな手法だと、テーブル内の入力域に表示される初期値はサーバ側でのHTML生成時にセットされることになる。初期表示だけであればいいのだが、今回のアプリのように、その値を基にして再計算するような場合には、すべての値に対してDOM参照が発生することになる。これがとても遅いのだ。そこで、思い切ってHTML動的生成はやめ、代わりにJSONを動的に出力する機能と、静的なHTMLを出力する機能に別けてもらうようにした。JSONを動的に出力する機能といっても別に難しいことを要求したわけではなく、HTML動的生成でHTMLタグを全部削除してJSONタグを書いてもらっただけである。また、静的なHTMLについてはWebサーバに置いてもらっただけである。
 原理としては、一旦JSONをデータとして受け取り、表示の際にJavaScriptで静的HTMLの入力域に代入するということをしているが一瞬で書き換わるため以前のアプリと何ら変わらないように見える。以降、値に変更があった際には、JSONの値を元に再計算を行い、静的HTMLの入力域に代入すればよい。こうすることで、再計算中はDOMへの参照がなくなり、非常に高速になった。
とはいえ、計算後に全表示したのでは大きなテーブルでは遅くなってしまうので、DOM参照のためのリンクを持つようにした。(現時点では、この部分が一番遅くなってしまっている。何かいいアイデアはないものか・・)
 ついでにいうと、このJSONオブジェクトのことを私たちはEntityと呼び、再計算のためのBlogicを呼び出すパラメータとして使用している。Blogicは、揮発性(ステートレス)であり、Entityを元に計算した結果のEntityを返すことしかしない。一方、Controlerへの呼び出しでもEntityをパラメータとして与えているが、これはサーバへの登録や参照機能を呼び出す際に使用している。(参考)3分で分かる設計の話
 また、高速化とは関係ないが、Blogicをステートレスとすることで、分業という副産物を手に入れることができた。単体テストも機械的に行えることができ、JavaScriptを複数人でシステマチックに開発できるという事例にできた。

3)数値計算の誤差は最後にまるめる

 JavaScriptの数値計算には誤差が含まれることをご存知だろうか。演算誤差とは
これを真に受けてしまうと演算を自前関数でやらなければならなくなる。実際に旧アプリではそうやっていたのだが当然ながら非常に遅くなってしまっていた。一つ一つの計算では誤差が発生するが、今回のアプリのように、実際に表示させる最後に丸めることでOKである場合がほとんどだろう。例えば、最終表示部分での丸めが小数点1桁で2桁目以降を四捨五入するとなっていた場合に、JavaScriptの演算誤差である小数点以下15桁が影響するには、どれだけの計算回数が必要かを検証してみればよいことである。影響ないことが検証できれば自前関数など破棄してNativeのまま使おう。

 以上が主な高速化のポイントであったが、他にもカーソル移動時の高速化(参考)TABキーで移動後にFocus、Select などがある。
 また、ワンソースマルチビューを実現する でも述べたが、以下のようにViewを表示するレイヤを機能で分けるという設計も非常に有効であった。例えば、Validatorで入力チェック、Attributeで表示桁や色、エラー処理などである。




1.Templateを選択する機能
- page id(xxxx.html#001)で指定
2.サーバからEntityを取得しBlogicを実行する
- Entityをチェックしてエラーコードをセットする。その後はAttributeによってエラーが表示される
- エラーがなければBlogicを実行する
3.静的なtemplateの上に動的なEntityをマッピングする。その際、Attributeにより値をフォーマットする(カンマを付けたり色を付けるなど)
4.データ入力時にvalidatorを実行する
5.(エラーが含まれていなければ)Entityをサーバに送信する

 一つだけ注意すべきことがある。それは、Entityへのデータ入力点(この場合、サーバから取得した時点とキー入力の時点)におけるエラーチェックを厳密にすることだ。キー入力の時点では、Validatorとして古くからJavaScriptは一般的に使用されてきたが、サーバから読込んだ時点というのは意外な方も多いだろう。この設計では、ここをチェックしないとハングする場合もあるので要注意だ。


<関連>

高速化プロジェクト その1

日曜日, 1月 04, 2009

【雑記】 工数と期間の関係を知る、それから適材適所 このエントリーを含むはてなブックマーク


短納期、低予算をどうやって解決していくかという問題にいつも悩ませられる。

弊社には請負の仕事を年間30%しかやらないという30%ポリシーがある。
特にお客様メンバーの一員として働く派遣は基本的にはやらないのだが、それは請負型が生産的でないからという理由が一番大きい。まず、お客様は無理難題を平気で主張してくる。いつまでたっても仕様がFIXしないので、議論や調整で疲弊してしまいモチベーションが下がる。そこで、生産性向上のための提案をやっていくのだが、まず受け入れてくれない。そのうち提案にも疲れて、しょうがなく言われたことをそのまま作りはじめる。そして一度作ったものはなるべく変更したくないので変更管理を始めて後工程に廻そうとするのだが、納期が迫ってくると、何とか先にやってくれと泣きつかれてデスマーチとなる。

こういう環境でエレガントなコードや斬新なアイデアはあまり生まれてこない。
たとえお客様への納品物が完成したとしても我々には何も残らない。
これは時間をお金に換える考え方であり、あまり生産的ではない。

弊社はより生産的なソフトウェアやWebサービスのビジネスにシフトしたいと考えているのだが、少なくとも30%は請負の仕事をやらなくてはならないのが今の現状である。なので、どうやってデスマーチを防ぐかという点に注力して、この手の開発案件に取り組むようにしている。

 目標は、いかに無駄な労力をかけずに、不幸な人を出さずに終われるかということ。チームとしてストレスなく仕事をやり遂げ、もう二度と一緒にやりたくないという人が出てこないようにすること。品質はクリアーできれば及第点でよい。<=これが請負の悪いところかもしれないが、酷い環境で酷使されている現状を考えると、これでよいと自分は納得している。

 抑えるべきポイントは以下の2つである。

1.工数見積もりを信用しない

お客様の見積もりと期間には根拠がないことが多い。
人と月は可換ではないことは明らかである。人と月は可換ではない
3人で6ヶ月かかる仕事が,18人で1ヶ月で終わるわけではない
「一人の子供を産むのに妊婦一人で約10ヶ月かかります.では同じ一人の子供を産むのに妊婦10人がかりだと何ヶ月かかるでしょうか?」もちろん,これの答は1ヶ月ではない.
 先日、Akamai主催の会で聞いた大槻先生の話のなかで、「人月に対して人と月は交換できない」という興味深いものがあった。
 これは妊婦の話を数式まで落とし込んだものだ。

 開発期間 = C × (工数)^D




 お客様は納期が迫るときまって人を増やせというが、そのくせ予算はない。
どれくらいの期間でどれだけ可能なのか、自分たちであらためて見積もりを作成することが肝要である。また、工数に応じて最適な開発期間が存在することを、しっかり認識しておくべきである。

2.適材適所

  人には様々なタイプがある。コードを書くのが得意な人、人と調整するのがうまい人、淡々と業務をこなしていく人。私は順に、Geek、Suit、Sweeperと名づけて、彼らに専門的に業務に取り組むように指示する。これら3つのスペシャリストがシステム開発で重要な役割(ロール)を果たす。どのロールが欠けても不都合になる。特にSweeperが見落としがちで、ビルドやテスト、リファクタリング、ドキュメンテーションなど、開発で必要な雑用を淡々とやりこなす。この作業はGeekやSuitは嫌がってやらないから、いてくれると本当に助かる人たちである。彼らがいないとGeekやSuitのフラストが大きくなっていく。

 適材は揃えたが適所を誤ると元も子もない。Geekがお客と調整をやっても効果は望めないし、その逆もしかりである。自分の得意とする作業に集中させてあげることが全体の生産性を高める鍵となる。それからコミュニケーション。Geekとそれ以外の人々との間には何か深い溝があり、コミュニケーションが図れない場合が多い。私は、時間とお金、労力と効果の関係、それから経緯をよく理解しないまま、素朴な発想をそのまま主張するGeekが悪いとは思っていない。先日読んだ革新的ソフトウェア企業の作り方にも書いてあったが、変なのは間違いなく我々Geekの方ではあるが、それをうまく通訳し、価値を伝えるべきはSuitの方だと考えている。

 最後に、弊社のロゴマークの意味を付けて締めくくるとする。




木曜日, 1月 01, 2009

初笑い このエントリーを含むはてなブックマーク


新年あけましておめでとうございます。

再出発した昨年は、優秀な社員に支えられながら、なんとか目標を達成することができました。本当にありがとうございます。

今年は100年に一度のなんとか、とよくいわれておりますが、この逆境をチャンスととらえ、さらに発展できるように頑張ってまいりますので、よろしくお願いします。

さて、正月を田舎で過ごしている私だが、ここで初笑いネタを披露します。

「父母漫才」

何かとトロい親父に向かって「のび太」という私。
父は、それをいうなら「プニュ」だろという。(<=ポニョの勘違い)
それを聞いた母はすかさず、「バカ違う。ポニョニョンたい。」(<=ポニョの勘違い)

ボケてる父に真顔でつっこむ母のボケが一番面白かった。
TVの漫才よりおもしろいや。

今年もよろしくお願いします。

水曜日, 12月 31, 2008

【クラウドコンピューティング】 5年後のIT市場 このエントリーを含むはてなブックマーク



クラウドが5年後にIT市場の4割に、上流シフトできないベンダーは消える

日本IBMの中島丈夫エグゼクティブ・テクニカル・アドバイザー(技術理事)は、クラウドをもう少し過激に見ている。
「クラウドは現在、IT業界や企業のIT部門が開発したり構築・運用している業務ソフトやITインフラ環境のすべてを収容し代替するパラダイムシフトとなり得る。
クラウドでデータセンターが産業化、工場化すると、ソリューション提供とかシステム構築などの業界用語は死語になる。顧客の欲しい“最終製品” がクラウドから出荷されるからだ」


IBMの中島理事は昔から過激だ。私が中島さんからe-DataCenterの話を聞いたのは10年以上前のこと。
 新しいものをプロデュースすることは本当に難しい。
Webサービス、SaaS、クラウドと、世の中はそのとおりに進化してきた。中島さんから未来の姿を教えてもらいながら何もできていない自分がもどかしい。
でもあきらめずに、着実に、頑張るしかない。(ちなみに中島理事は私をハマスのように過激だという)

火曜日, 12月 30, 2008

【雑記】 3分で分かる設計の話 このエントリーを含むはてなブックマーク



 外部設計で重要なのは項目の整理。画面->テーブル->I/Fの順番で見ていく。項目の整理で必要なことは名前と型と多重度の定義。ただし長さの定義は内部設計でやってもOK。
 内部設計で重要なのはロジック。主にControlとBlogicが実装できるかどうか考えていく。ウォークスルーをやって項目の抜けや矛盾を見つけ出し不都合があれば外部設計で定義したI/Fを修正する。(ここで修正作業が起きることを懸念してはいけない。修正はおそらく最後の局面まで発生するだろう)
 Modelはdataとblogicに分かれる。(ドメインモデルではこれが一つになる一方、Controlの定義が曖昧になる)blogicでは外部参照をなくし揮発性(ステートレス)とすることが重要。
 テストはUT、IT、STの順番で行う。UTは内部設計書を元にチェックするテスト。ITは外部設計書、STはユースケースを元にチェックする。

<関連>
MVCモデルは進化する
ドメインモデル貧血症、サービスと振る舞いについて

日曜日, 12月 28, 2008

【雑記】 著作権について このエントリーを含むはてなブックマーク


 今日の日経新聞に出ていた「歌詞は盗作」認めずという記事が面白かったので一言。
問題となったのは、CHEMISTRYの「約束の場所」のなかの「夢は時間を裏切らない 時間も夢を決して裏切らない」という部分で、銀河鉄道999の「時間は夢を裏切らない 夢も時間を裏切ってはならない」という表現からの盗作ではないかということ。漫画家の松本零士さんは作詞した槙原敬之さんが電話で参考にしたことを認めたとも主張していた。

結局、「歌詞と漫画の表現は相似も大きく、漫画に依存しているとは断定できない」、「槙原さんが電話で認めたとも認定できない」との理由で、槙原さんに軍配が上がった。

この話のポイントは、著作権が相対的独占権(あるいは排他権)であること。
特許権や意匠権のような絶対的独占権ではない。すなわち、既存の著作物Aと同一の著作物Bが作成された場合であっても、著作物Bが既存の著作物Aに依拠することなく独立して創作されたものであれば、両著作物の創作や公表の先後にかかわらず、著作物Aの著作権の効力は、著作物Bの利用行為に及ばない。・・wikipedia


つまり、明らかに盗作だと思える表現でも盗んだことが立証されなければ有罪とはならないということ。「槙原さんが電話で認めたかどうか」が勝敗の分かれ目だったのだろう。

ソフトウェアの著作権についても同様の考え方ができる。

オリジナルのソースを入手してcopyrightのコメントをすげかえてもNGだし、コピーしたことがわからないように変数名やコメントを変えてもNG。
ただし、結果的に同じものができたと主張できれば、全く同じものでもOKとなる。

特許などと違い、結果的に同じものができても著作権侵害にはならないがオリジナルのソースを見て作った(=盗作)のであれば侵害となる。

木曜日, 12月 11, 2008

【Reflex】 MorphとDropBoxでクラウドPDFサービスを実現 このエントリーを含むはてなブックマーク




 Reflex itextの機能説明にもDEMOをのせているが、これはMorph Appspaceで動いているサービスである。デプロイは簡単で、以下のようにjarを実行するだけである。

java -jar morph-deploy.jar --user hoge --password piyo --config morph_deploy.properties pdfservice.war
Uploading the code...
Creating new appspace version...
Deploying the application...
Deploy Done.

For more information on the status of this deployment, you
can view the Deployment Logs by clicking 'Manage' located
on your subscription widget and by clicking the Logs tab.

In this same page, you can also view your Production logs
and Scheduled task logs.

** transaction commit **


さらに、Dropboxを使うことで、データもサービスもクラウドで提供できる。これが無料だからすばらしい。ちなみに、Morph AppSpaceもDropBoxも裏ではAmazon S3が動いている。

以下のリンクをクリックするとPDFが生成される。実行


http://pdfservice.morphexchange.com/?template=http://dl.getdropbox.com/u/200214/pagesample.html&entity=http://dl.getdropbox.com/u/200214/pagelist.xml


自分のパソコンのDropBox publicフォルダに、pagesample.htmlと、pagelist.xmlを置いて、あとは、これらのリンクをPDFサービスに渡してあげるだけだ。

グラフも出せるが文字化けする。海外のサービスだからしかたないところかな。実行

http://pdfservice.morphexchange.com/?template=http://dl.getdropbox.com/u/200214/areachartsample.html&entity=http://dl.getdropbox.com/u/200214/stocklist.xml


セキュリティの考慮点は暗号化とアクセス制御の2つ。
httpsで暗号化、アクセス制御はDropBoxのグループフォルダの考え方がヒントになると思っている。

クラウドで安全にPDF文書化ができたらWebEDIに応用できる。PDFに署名できたら取引は全部Webだけ、ということになるかもしれない。エンドユーザはサーバもストレージも用意する必要がない。Gmailのように過去のデータもすべてクラウドが保管する。

クラウドの可能性を考えると、とてもわくわくするなあ。



関連: 最初は無料が流行?Morph AppSpaceとdropbox

月曜日, 11月 17, 2008

【本日の嵌り】 Outputstreamをメモリにキャッシュ このエントリーを含むはてなブックマーク


 今作成しているWebアプリは画像生成処理の際に一時保管用としてテンポラリファイルに出力している。それがセキュリティ対策のためファイルへの書き出しが禁止されてしまった。さあ、どうしよう。
 幸い画像のファイルサイズも小さく出力後は消しても構わないのでメモリをテンポラリファイル代わりにして書き出せばよさそうである。そこで以下のようなOutputstreamをメモリにキャッシュするものを作成した。画像作成時にファイル名の代わりにキーを指定して書き出して出力時にキーを元に読み出せばよい。サーブレットなどマルチスレッドに対応するには、ファイル名にスレッド番号をつけてやればよい。

これで解決。


金曜日, 11月 14, 2008

【Reflex】 なぜAkamaiと組んだのか このエントリーを含むはてなブックマーク


非常に単純な理由である。
 
 Reflex iTextはデータとテンプレートを与えることでPDFを生成する。PDF生成処理は重くサーバリソースを圧迫するため、クラウド・コンピューティング・サービスを利用するのは理にかなっているからだ。
 
 また、AkamaiがGoogleやAmazonなどと異なるのはネットワークのクラウドであるということ。特にAmazonは日本にサーバを置いていないためレイテンシーが問題となる。Akamaiであれば心配する必要がない。

「インターネット・エッジに置いたサーバー群でクラウドを加速化」、アカマイがアライアンスを設立

 「クラウド・コンピューティング・サービスを提供する他の企業は、データ・センター内の設備のスケール・アウトを進めている。ところが、インターネット側のスケール・アウトを実施する企業はあまりない。アカマイはそこを狙っていく。グーグルやアマゾンのクラウドを巨大な発電所に例えると、送電線と変電所の役割を果たすのがアカマイだ」(アカマイ日本法人の小俣修一社長)






水曜日, 11月 12, 2008

【Reflex】 アカマイ様とのアライアンスとReflex iTextの発表 このエントリーを含むはてなブックマーク


 アカマイ様と弊社は、Reflex iTextのサービスについてのアライアンスを結び、本日プレスリリースした。

アカマイ、精鋭ソフトウェア開発会社とアライアンスを結成

 また、Reflex iTextのドキュメントを以下にUpしているので興味がある方はぜひ参照してみてください。
Reflex iText Overview

ポイントは、以下の2点です。

1)Akamai様がグローバルに展開した膨大なコンピューティング環境にPDF出力エンジンを分散配置することでシステム負荷軽減を図れる。

2)トランザクションによる従量課金となるため、使った分だけのコストしか発生しない。PDFサーバにかける初期投資を低く抑えることができる。

月曜日, 11月 10, 2008

【JavaScript】 高速化プロジェクト その1 このエントリーを含むはてなブックマーク


 先日、ある家電大手ECサイトのレスポンスが極端に低下するという事故が起きた。すぐに復旧できなかったところを見ると設計に何らかの問題があったのかもしれない。ECサイトにおけるレスポンス低下は致命的である。また、完成後のプログラムのパフォーマンスチューニングは難しい。サービスインしてから発覚したのでは取り返しがつかなくなることもあるので、設計の段階でよく考える必要がある。

今年の春頃のことだが、あるプロジェクトでJavaScriptのパフォーマンスが極端に遅くなるのを何とかしてほしいという相談を受けた。

 AJAXブーム以降、大規模な業務アプリケーションでもJavaScriptはよく使われるようになってきたが、多用するとパフォーマンス低下の心配が出てくる。これは特にDOM操作の多いアプリで起こりがちである。今回のプロジェクトでも、ベンチマーク結果によるとDOM操作に問題があるアプリであることがわかった。とりあえず、アプリの修正は行わないで以下のような対処療法をやってみた。


1.prototype.jsライブラリ改善

    ・HTMLファイル内のparentをいじる参考
    ・$()にcacheを持たせる参考
    ・prototype.jsファイルのサイズ縮小参考

 初期表示にかかる時間を計ったところ、9秒強(サーバ経由だと17-18秒) => 書き換え後8秒強(サーバ経由だと16-17秒)

2.変数格納

・for文の.lengthを一旦変数に格納

     初期表示にかかる時間を計ったところ、変化なし

3.jsファイルの圧縮

・他のjsファイルの圧縮もしてみたが、まったくと言っていいほど変わらなかった。



 対処療法ではまったくといっていいほど効果がなかった。しょうがなく設計からやりなおしてスクラップ&ビルドすることにした。結果は以下のように、初期ロードで倍のスピードとなり、また瞬時にタブ移動やページ移動ができるようになった。それでも初期ロードに時間がかかっているのは、DOMのリンク生成とサーバにおける検索処理時間が短縮できなかったことが原因である。DOMのリンク生成についてはどうしても時間がかかってしまうが、遅いのは最初だけなのでお客様にはなんとか納得してもらうことができた。
 どのようにしてこれだけの高速化ができたのか、詳細については「高速化プロジェクト その2」以降で説明したい。

旧アプリ(Core2 2.0GHz、メモリ2GB) 単位ms

初期ロードタブ移動ページ移動
APPL117.94.16.8
APPL212.54.03.8
APPL318.85.76.5
APPL411.31.42.3


新アプリ(Core2 2.0GHz、メモリ2GB) 単位ms

初期ロードタブ移動ページ移動
APPL18.90.10.1
APPL26.10.10.1
APPL315.50.60.1
APPL43.10.10.1


<関連>
高速化プロジェクト その2

木曜日, 10月 30, 2008

【雑記】 失敗しないことがよいことか このエントリーを含むはてなブックマーク


 小野さんのサイトで勧められていたので今こういう本を読んでいる↓。



 この本では、IBMのトーマス・J・ワトソンの言葉が数回出てくる。トーマス・J・ワトソン・シニアの名言・格言

 早く成功したいなら、失敗を二倍の速度で経験することだ。成功は失敗の向こう側にあるのだから・・・・


 要は失敗を恐れずに何事も果敢に取り組めということだが無謀な挑戦をやれといっているわけではない。やる前に少なくとも次の2つの検証は必要だと思われる。


 1)目的がはっきりしているか
 2)致命的な失敗にならないか


 発明王トーマス・エジソンも、「失敗は成功の母である」という言葉を残している。失敗から学んで次に生かすことは、「電球を発明する」などの目的があってはじめて成り立つことだと思う。
 また、何かをやるには大小のリスクは必ずある。それを無謀というかどうかは意見の分かれるところでもある。失敗には致命的な失敗とそうでない失敗の2種類あり、致命的な失敗さえしなければリスクを取っても気にする必要はない。失敗することを心配するのではなく致命的な失敗の危険性をどれだけ回避するかが重要である。致命的な失敗さえしなければ次のアクションをとることができる。(←こういう感じの話が本に書いてあった)

 ところで、失敗を好んでやっているとしか思えない確信犯的な企業がある。

 GoogleはGmailでメールをWeb化している。メール情報を預かるリスクは相当高いが、それを使う側にも分担させる(覚悟してもらう)ことで成り立たせている。つまり、データ損失や漏洩などの事故が起きる危険性はゼロではなく無償サービスということで免責されているが、それを承知で私を含め多くの人が使っている。
 その他、Youtube、Google Book Searchでは著作権問題を抱えており、Street Viewではプライバシー問題と向き合っている。これらのサービスが問題になることはやる前から分かっていたはずで、googleにとっては、ある程度起こることを見越した問題であったことは間違いないだろう。

 googleのすごいところは決して目的がぶれず後ずさりしないこと。以下の記事は一例であるが、情報公開の自由化と著作権者保護という2つの相容れない問題を「手打ち」により同時に解決させている。動画像のアップロードなどは限りなく違法コピーに近く、著作権をないがしろにしているように見えるが、一方で著作権者を保護することで著作権者と消費者の双方に支持されるモデルとなった。そのベースには広告モデルがあり、この文化が定着すれば広告モデルの可能性がまた大きくクローズアップされるかもしれない。いずれにしても、Googleが人柱となってこの業界を進化させているのは間違いない。恐るべしGoogle。

「Google Book Search」訴訟で米出版業界と和解合意

YouTubeとJASRACが利用許諾契約、演奏動画の投稿が可能に

水曜日, 10月 29, 2008

【クラウドコンピューティング】 Microsoft Azure このエントリーを含むはてなブックマーク


丸山先生のPDC報告です。


ロスアンゼルスで開催されている、MSさんのイベント、Professional Developer Conference 2008に出ています。
他のメーリングリストに投稿した内容ですが、次回の僕のCloud研究会での報告に関連していますので、ダブル・ポストします。
---------------------------------------------------------------------------------------------------

初日のレイ・オジー(チーフ・ソフトウェア・アーキテクト)のキーノートは、
すべて、同社のクラウド製品、Azure Software Platformにあてられました。MS
が、公式にCloudサービスへの参入を表明したことは、とても大きな意味のある
ことだと思います。すでに、日本のメディアにも、いろいろな紹介が行われてい
ると思いますが、僕には、とても面白いものでした。

どんなものかといわれると、AmazonのEC2/S3+SimpleDBにGoogleのGoogle App
Engineを足して、もっと、使いやすくしたようなものです。サービスの中核は、
前から僕が予想していたように、SSDS(SQL Service Data Service)によるデー
タ・サービスです。

AmazonのEC2との対比で言うと、EC2が潜在的には前提にしていた、Cloud上での
サーバやディスク等のリソース管理の機能を、明示的に、「CloudのOS」として
のAzureが担うことを明確にしています。EC2では、Cloudの利用者は、具体的に
は、AmazonのCloud OSが提供する、個々のマシンを利用するのですが、Azureで
は、MSのCloud OSであるAzureの提供するサービスを利用することになります。
同じだろうと思うかも知れませんが、その違いは、大きいのです。

Google App Engineでも、利用者は、知らないうちに、Googleの提供するCloud
サービスを利用しているのですが、Azureでは、Cloudサービスの利用は、もっと
Cloudのリソースの利用に、自覚的です。例えば、EC2のように、個々のサーバ利
用を意識する必要はないのですが、Webのサーバをいくつ立てて、ビジネスロ
ジック用のプロセスをいくつは知らせるかというような設定が、Azureでは可能
になります。その点では、僕のCloud研究会の第一回の資料で指摘した、「Multi
-TierアプリのScale-out戦略」の図を見てもらうと、そのイメージはわかりやす
いと思います。Cloud内のいくつかの基本的なサービスのブロック(ロードバラ
ンサ、Web、Worker)のコンフィグが、AppLogicのように、簡単にできます。

この点では、Azureは、Google App Engineと同様に、エンタープライズでの開発
の中心である、Webアプリの開発のCloud化に、明確に焦点を合わせています。
MapReduceのような、汎用の分散アルゴリズムのサポートは、ありません。た
だ、Cloudで動くWebアプリの開発、deploy、実行は、Google App Engineより、
はるかに、簡単で、直観的です。

余談になりますが、キーノートでは、Cloud上で動く、Hello Worldのデモが行わ
れたのですが、これはちょっとわかりにくかったかも。だって、Hello Worldの
文字列が、直接ページに埋め込まれているのか、あるいは、隣のサーバが返す
ページに入っているのか、はたまた、Cloudから来たものかは、見ている人には
わかりませんからね。もっとも、このあたりは、Cloudを概念的にとらえること
の難しさを示しているのかも知れません。

その他、いくつかの特徴があります。思いつくままに触れると、

・Cloud アプリの開発環境の提供。
・Cloud上でのユーザの認証、アクセス管理。(OpenIDを使うのだと思います)
・既存のWeb Appsをクラウド化する手段の提供。
これは、.NET Servicesという製品群にまとめられていますが、以前の
BizTalkの機能をまとめたものですね。個人的には、SOAの発展形としての
Cloud利用という切り口が明確で、面白かったです。
・Cloud内のサービスの連携に、非同期なメッセージングを使うとか、Queuを
使うという話も、なるほどと思って興味深いものでした。もっとも、この
あたりは、数年前から、SOAの世界では言われてきたもので、大事だと思い
つつ、僕は、爆睡してしまいましたが。
・MSのOffice製品群のCloud利用を可能にする、SharePointとの連携。
・企業内(On Premise)既存サービスと、Cloudとの区別と関連付け

最後の点は、IBMさんにしろOracleさんにしろ、既存の製品群とCloud利用が、あ
る点では競合するという問題を、MSさん自身も抱えているという点を示している
訳で、面白い問題だと思っています。

聞いていたひとの反応は、「地味だった」という声が多かったように、思いま
す。以前、マルメでも書いたのですが、このPDCの焦点の一つが、MSのCloudへの
参入の表明にあるという意識は、事前には弱かったのですが、まだ、ちょっと実
感がわいていないようです。(Vistaの後継としてのWindows 7に対する関心の方
が、ずっと高いですね) 講演者も、例えば、Cloudにとって、本質的に重要
な、SSDSのScale-outする特徴に、踏み込まないまま、SSDSの説明をしようとし
たり、MS内部でも、明確な語り口が統一されていないようなところもありました。

ただ、初日のキーノート、まるまるすべてAzureに使ったわけで、それなりに関
心は高まったとは思います。Bill Gatesが引退して、はじめてのPDCらしいので
すが、僕には、別の意味でも、歴史的な会議になるだろうと思っています。

http://www.microsoft.com/azure/solutions.mspx
に、すでに、情報が出ています。是非、チェックしてください。

P.S. CloudのSOA利用のセッションは、激しく寝てしまったのですが、
寝ようと思って出た、「C#の未来」というセッションは、とても
面白かったです。C# 4.0って、Dynamic言語に対応するんですね。
「静的な型として、dynamicという型を導入するんだ」という彼の
説明に、つい笑ってしまったのですが、なかなかの人でした。

火曜日, 10月 28, 2008

【本日の嵌り】 SVNレポジトリを作成する このエントリーを含むはてなブックマーク


SVNレポジトリを最初から作りたい。さあ、どうしよう。

まず、

mkdir /usr/local/svn/repos
svnadmin create /usr/local/svn/repos


とやってsvnのdbを作成する。(bdbとかfsとか細かいことは省略)

実際に作業したいフォルダに移動して、
home/hoge/svnの上で


svn import file:///usr/local/svn/repos -m "" 


とするとインポートされる。次に、


svn co file:///usr/local/svn/repos      


とやってチェックアウトすると


  home/hoge/svn/repos


ができるので以後、


svn up /home/hoge/svn/repos/fuga.csv    アップデートや
svn ci /home/hoge/svn/repos/fuga.csv -m "" コミット


などができるようになる。これで解決。

月曜日, 10月 27, 2008

【EC開発体験記-EDI-】 SVNを業務で使い倒す このエントリーを含むはてなブックマーク



 EDIで外部システムとの連携を考えるときに最も注意しなければならないのはデータの不整合である。これは、送ったはずのデータが送られていない、あるいは、受け取ったはずのデータがなくななるといったことであるが、基本的にこういったものは「性悪説のスタンス」で設計した方がよく、むしろ、日常茶飯事でトラブルが起きるぐらいの覚悟でいるとちょうどよいと思われる。
 
 ということで、EDIをSVNで管理することを考えてみた。SVNといえば、ソースコードやドキュメントの履歴管理によく使われる、開発者にとってはお馴染みのバージョン管理ソフトである。これをEDIに活用して、送受信データをいつでも再送/再受信できるようにしようというわけだ。特に人手を介して入手するマスター類の登録などでは真価を発揮する。いつも送った送らないで揉める人間系でもSVNの履歴には反論の余地がない。SVNを業務アプリケーションに使うことに違和感を覚える方も多いと思われるが一度利用してみることをおすすめする。


<SVNによるEDI> 


<SVNをEDIで使うメリット>

1)一貫性確保 ・・・ コミットしたものと送受信したものが同一であることを保障できる
2)実績確認  ・・・ いつ何をどれくらい送受信したか実績を確認できる
3)リカバリ対応・・・ 履歴から過去データを取り出せるためいつでも再送できる

<SVNをEDIとして使うケース>

1)物流      ・・・ 物流業者への出荷指示データの送信と出荷済データの受信
2)商品マスタ  ・・・ 商品部からの商品マスタの受信とホームページへの反映
3)在庫管理    ・・・ 倉庫からの在庫データの受信とたな卸しデータの送信


 一貫性が保障できて実績が確認できればエビデンスとしても利用できる。対外システム側との取り決めが必要だが、例えば、SVNファイルを正と取り決めておけば、物流業者の請求金額についてはSVNファイルの「出荷済」のレコード数をカウントすることで確認できる。また受け取ったデータをそのままコミットしておけばトラブルがあったときにリカバリーも確実に行えて原因を突き止めることが容易になる。
 EDIでは、まず、送ったものと受け取ったものを確実に管理することが重要である。基本はトランザクション処理と同様の考え方で、成功でコミット、失敗でロールバックとすればよい。以下の例では、SVNのDIFFをとり新規分があればupdateして送信するが、失敗すればリビジョンを元に戻すという動きをする。これは実際に使っている全銀システムと通信するコードの抜粋である。全銀ISDN回線で話中で数回に1回の確率で失敗するようなFuck!な連携システムでもSVN履歴管理はとても有効である。


# 未送信分チェック(送信すべき新規のファイルがSVNにあるかどうかをDIFFを使って調べる)
DIFF1=`svn diff --revision BASE:HEAD hoge.dat`
if [ $? != "0" ]; then
    echo [`date`] ファイルが未更新
else
    if [ -n "$DIFF1" ]; then
      echo [`date`] ファイルが更新されています
      svn update hoge.dat

      # 送信処理
       ・・・
      # 送信成功?
      if [ $? != "0" ]; then
        # もし送れなかったらエラーを報告してリビジョンを1つ前に戻す
        echo [`date` ] エラーが発生したため処理を中断します。
        svn update -r PREV hoge.dat

      else
        # 送信成功
        echo "送信成功!"
      fi
    fi
fi



 また、TortoiseSVNとの組み合わせにより、Windowsフォルダを操作する感覚でSVNを扱えるのも嬉しい。これにより、オペレータさんなど、SVNコマンドの特別な知識がない方でも扱えるようになる。オペレータさんは通常はデータを生で見ることはあまりないが、エラー発生時のファイルの状態やコミット時間、件数を報告してもらうとトラブルに迅速に対応できるようになる。

 たまに、SVNのdb内で不整合が発生してエラーになることがあるが大抵svnadminコマンドでリカバリーできる。


/usr/bin/svnadmin recover /usr/local/svn



 SVNエラーは大きいファイルをhttp(https)でコミットしようとすると起きやすいため、svn+sshで接続することをおすすめする。実際にsvn+sshで50万件の商品マスタを毎日コミットしていたが特に問題なく運用できていた。
 TortoiseSVNからsvn+sshで接続するのは以下のように設定するとよい。






 ちなみに、弊社では上記のSVN EDIソリューションを、Reflexパッケージとともに提供していきたいと考えている。SVNは内部的にberkeley dbを使用しているため再販するためにはOracleライセンスが必要になるが、弊社はReflexパッケージのなかでライセンス許諾権を結ぶことでOracle社と基本合意している。(11月中に締結予定)
 
<関連>

【EC開発体験記-スケーラビリティ-】信頼性とジレンマ
【EC開発体験記-トランザクション処理-】古くて新しい永遠のテーマ

 
© 2006-2015 Virtual Technology
当サイトではGoogle Analyticsを使ってウェブサイトのトラフィック情報を収集しています。詳しくは、プライバシーポリシーを参照してください。