【雑記】 Yes, we can

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

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

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

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

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

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

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

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

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

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

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

　Yes,we can

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

【雑記】 コモディティかイノベーションか

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

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

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

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

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

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

＜関連＞
失敗しないことがよいことか

【雑記】 性善説と無責任

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

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

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

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

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

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

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

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

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

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

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

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

私は君を何とかしたい。

【クラウドコンピューティング】 クラウド予想2009

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

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

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


＜私なりのクラウド予想2009＞

１）コストダウンは急速に進む

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

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

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

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

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

４）大手ITベンダはクラウドの大合唱

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

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

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

【JavaScript】 ISO8601日時をパースする正規表現。ついでにJavaも

"2002-06-17T09:25:43.4670000+01:00"　のようなフォーマットのISO8601日時をDateにして返す関数はJavaScriptでは以下のようになる。正規表現を使ってマッチした()の1つ目が$1、2つ目が$2・・・７つめが$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));

  }
 }
 
}

【JavaScript】 高速化プロジェクト その２

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

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



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

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

１）イベントリスナーの多用をやめる

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

２）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をパラメータとして与えているが、これはサーバへの登録や参照機能を呼び出す際に使用している。（参考）３分で分かる設計の話
　また、高速化とは関係ないが、Blogicをステートレスとすることで、分業という副産物を手に入れることができた。単体テストも機械的に行えることができ、JavaScriptを複数人でシステマチックに開発できるという事例にできた。

３）数値計算の誤差は最後にまるめる

　JavaScriptの数値計算には誤差が含まれることをご存知だろうか。演算誤差とは
これを真に受けてしまうと演算を自前関数でやらなければならなくなる。実際に旧アプリではそうやっていたのだが当然ながら非常に遅くなってしまっていた。一つ一つの計算では誤差が発生するが、今回のアプリのように、実際に表示させる最後に丸めることでＯＫである場合がほとんどだろう。例えば、最終表示部分での丸めが小数点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は一般的に使用されてきたが、サーバから読込んだ時点というのは意外な方も多いだろう。この設計では、ここをチェックしないとハングする場合もあるので要注意だ。

＜関連＞

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

【雑記】 工数と期間の関係を知る、それから適材適所

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

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

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

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

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

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

１．工数見積もりを信用しない

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

　開発期間　＝　C × （工数）＾D

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

２．適材適所

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

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

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

初笑い

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

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

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

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

「父母漫才」

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

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

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