ゆるゆるファクトリー

　●Amazon Elastic MapReduce

Hadoop をホストしてる模様
Hadoop 広がるな・・・。

●twitterがrubyからscalaへスイッチ

scala かよ！
最近、JavaでWebサービス作りましたというベンチャーって
あんまり見ないけど、JavaVM使ってますという話は時々聞く件

あ。でも Hadoop は来るかも。

●これぞ完璧企画書――「1枚企画書」パターン実例3題

これは、本買っちゃうかも

　●MIX 09：Nigel Ellis氏、Azure SQL Data Servicesについて語る

　SDSは、ここに来て急にリレーショナルを目指し始めたからな～

　クラウドのストレージは、Hadoopを初めとしたKey-Valueになるのか

　はたまた、SDSのリレーショナルでも実現可能なのか。

　大きく分かれそう。

　リレーショナルで本当にスケール可能なのかどうかだな～

今日の注目記事

●アマゾンとグーグルとマイクロソフトとセールスフォースのクラウドはどこが違う？

Google App Engineは、Javaが使えるようになるかもしれないので
あとは、ストレージの違いがどうなるか、、、

Google、AppEngineでJavaのサポートを開始


●MySQLのEXPLAINを徹底解説!!


前回の「なぜMySQLのサブクエリは遅いのか。 」に続く良記事


ここまで踏み込んだネタを勉強会で出したかったな～
ソース読まないとダメなんかな、、、
 

FlashのSWFファイルを解析する処理をJavaで作っていて
すったもんだの末、上記の疑問に到達して立ちすくんでおります。

SWFの中には、普通にUI16( unsigned int 16, 符号なし整数１６ビット）が出てくるんですが、、、
32767を超える整数が保存されてたら、Javaに読んだ瞬間マイナスの数字として誤認識されるのでは・・・？

符号なし整数１６は、符号付き整数３２で読めってことなのかなー？

例えば、読んだ２バイトのデータをそのまま処理せずに
頭に２バイト分ゼロを付け足して、４バイトのデータとして扱うとか？？

いやいや、事情はもう少し複雑だったりする。

不幸なことに、SWFファイル中の数字はリトルエンディアンで保存されている。
Javaでリトルエンディアンを扱うにはByteBuffer を使うのが良さそうなのだけれども、用意されているメソッドは getShort, getInt というように、「ｘバイト分データを取って、数字に変換する」がワンセットになってしまっているのだ。

つまり数字に変換する前に、頭にゼロを付けるという技が使えないのだっ。


うえぇぇぇ


こうなったら、素直に１バイトずつ読んで、２バイト目のデータだけ８ビットシフトさせて足し算するしかない？
しかししかし、１バイトずつ読んだとしても足し算する時に符号を間違えてしまう問題がっ。
（論理演算すればいいのかっ？？）

うえぇぇぇぇぇ



どうすんねんこれ〜。

※注意

私のアホがばれるので、円周率とか円の面積とか得意な方は以下の文章を読まないでください。





うおお！
Wikipediaの円周率のページすごい！
http://ja.wikipedia.org/wiki/%E5%86%86%E5%91%A8%E7%8E%87

このアニメーション感動的・・・
そうかー。円周率って、直径１の円に対する円周率の比率か〜。
そういう値だっけ。

ということは、
直径 ２の円の円周は ２π。
直径 x の円周は x π
半径 y の円周は 2y π

か、、、
なるほどー。

すっかり忘れてました。
てか、学生の時にこのアニメ見てたら、確実に記憶してたんちゃうかなー。
すげー。

是非、教育関係者の方、こういうやつで教えてあげてください。



円の面積を求める公式さえも忘れていたのだけれども
円周率が理解できれば導けるように。すげーすげーー

円の面積＝半径 ＊ （円周の半分）
↓
円の面積＝半径 ＊（円周）／２
↓
円の面積＝半径 ＊（２＊半径＊π）／２
↓
円の面積＝半径 ＊ 半径 ＊ π


うほーー。
そうかそうか。そうだったかも。

世界地図を縦x横の方眼に分割したものに対し
指定した緯度・経度は、どの方眼上にあるのかを求める。
みたいな計算をするソースコードを読んでる訳ですが
上記のような基礎知識が抜けてて苦戦中・・・
＃球体の表面を長方形にのばしてるので、単純な計算では求まらない模様。

でも、一部でも分かると面白いかも。


あー。
三角関数とか扱えるようになったら、３Dでオブジェクトを回すのも楽勝なんじゃないのかな〜

うあー。やりてぇ〜。



とか夢は大きいけど、ラジアンが何だったか。みたいなところで詰まり中。
全然わからねぇ。


参考：

3D表現にチャレンジしよう！

PHP＋Flashで、携帯サイトの調査をやってたりして・・・


あれ？Seaser(Teeda)は？ SilverLight は？

ウゥム・・・
Blog で、「やるぞ！」というと、その直後に終了する謎のパワー健在・・・。

でもまぁFlash 楽しいからいいか。
きっと SilverLight もFlashに似せて来てるだろうから、スキルは活かせるに違いないっ。
（あんまり違いすぎるとFlashデザイナーを呼び込めないだろうし）


それにしても、携帯のFlashLite って激しく低機能ですな。。。
自分が読み込まれたURLやパラメーターも取れないので、一旦PHPでリクエストを受けて、その中で swf ファイルのバイナリを編集してパラメーターを埋め込まないと行けないという罠・・・
ありえん。
（具体的なやりかたは次回に書きます。多分）

※ FlashLite 2.0 からはURLが取れるみたいです。


でも、おかげでバイナリファイルの中を覗いてデバッグするという経験が積めてしまった。
なんだ。分かってしまうと結構簡単かも。


しかし、、、

「.net がやりたい！」と念じるとJava の仕事になっちゃうし
「Windows サーバーに詳しくなりたい！」と思うと、Linux でWebサイト構築になるし
「SilverLightがやりたい！」と思うとFlash、、、

惜しい、、、惜しいけど違うぞ！！！



あ。
今年は、Remix 07 いってみようっと〜
http://remixj.com/

TeedaでSelect ボックスを描画するときに、optgroup を出す方法ですが
Page クラスの、リストのアイテムを返すメソッドの戻り値を、SelectItemGroup と、SelectItem で作ると動きます。

例えば、以下のようなHTMLの場合。
（かなりのタグを割愛してます。かつ、括弧を全角にしてます。）

＜form＞
　＜select id="meke" ＞＜/select＞
＜/form＞

Select に表示したいアイテムは、Pageクラスに用意した mekeItems プロパティ に設定して
getMekeItems メソッドの戻り値として取れるようにするのが決まりなわけですが、、、
このとき mekeItems の値を、SelectItemGroup と、SelectItem で作ると、optgroup が出せます。
＃世の入門本は、ListとMapを使った方法しか解説してないので路頭に迷いました・・・。(;´д⊂)


例えば、prerener メソッドで、こんな感じに。
＃変数スコープを制限してコピペ効率を上げるために、無駄に中括弧使ってます。（ダメ）


import javax.faces.model.SelectItem;
import javax.faces.model.SelectItemGroup;

...

 public Class prerender() {
  SelectItem item;
  mekeItems = new ArrayList();
  
  {
   SelectItemGroup group = new SelectItemGroup();
   group.setLabel("地域で指定");
   mekeItems.add(group);
   
   SelectItem[] items = new SelectItem[2];
   int index = 0;
   
   item = new SelectItem();
   item.setLabel("北海道地方");
   item.setValue(101);
   items[index++] = item;
   
   item = new SelectItem();
   item.setLabel("東北地方");
   item.setValue(102);
   items[index++] = item;
   
   group.setSelectItems(items);
  }
  
  {
   SelectItemGroup group = new SelectItemGroup();
   group.setLabel("都道府県で指定");
   mekeItems.add(group);
   
   SelectItem[] items = new SelectItem[2];
   int index = 0;
   
   item = new SelectItem();
   item.setLabel("北海道");
   item.setValue(1);
   items[index++] = item;
   
   item = new SelectItem();
   item.setLabel("青森県");
   item.setValue(2);
   items[index++] = item;
   
   group.setSelectItems(items);
  }
  return null;
}


これで、うまいこと　optGroup タグが出せました。やった！！



Teedaの使い方を調べるのに、Google先生頼みで作業してるんだけど
的確な回答に、なかなか行き当たらない・・・。

ので、結局ソースを追う羽目に・・・orz


読むべきドキュメントを見逃しているのだろうか、、、（確かに、あんまりドキュメント読んでないけど）



リファレンス系のマニュアルも SEO対策キボンヌ　ヽ(;´Д`)ノ

Tapestry５で、この夏はシボンヌ確定！とか思われていた今回のプロジェクトですが、最終的にSeaser2.4 （画面はTeeda）で行くことになりました。


ふぅぅぅーーーっ！

命拾いしたーー！！




でもまぁ、まだまだ気は抜けないわけですが。。。

とりあえず、そんな感じです。＜各位 （誰？）

Teedaを使って開発していると、内部エラーが発生したときに、エラーメッセージ表示用のページにリダイレクトされてしまう。
が、これだと、エラー修正したあとイチイチアドレスバーに、エラーになった画面のURLを入力しなおさないといけないので面倒くさい。

＃デザイナーさんが作ってきたHTMLをベースにページを作ってるときなんか、SAXエラーの度にエラー画面に遷移しちゃって結構大変なのです。
というわけで、Teedaのエラーハンドラーをちょっと変更したクラスを作って、リダイレクトしないようにしてみました。


これで、不具合を修正したらブラウザのリロードするだけで確認！という
良い感じの動作になりました。




というわけで、その手順を貼り付けます。

手順は以下

１．エラーハンドラー用クラスを作る。
２．teedaErrorPage.dicon のエラーハンドラーの記述を置き換える。


具体的に必要なコードは以下
＃半角の＜＞　は、イザのブログエディタだとうまく扱えないっぽいので、全角に置き換えています。
＃コピペする場合は注意・・・。


■　今回作ったエラーハンドラークラスのソース

package jp.co.mekefactory.sample.helper;

import java.io.IOException;

import javax.faces.context.ExternalContext;
import javax.faces.context.FacesContext;
import javax.servlet.ServletResponse;

import org.seasar.framework.log.Logger;
import org.seasar.framework.util.AssertionUtil;
import org.seasar.teeda.core.util.ServletErrorPageManagerImpl;
import org.seasar.teeda.core.util.ServletExternalContextUtil;

public class BaseErrorPageManager extends ServletErrorPageManagerImpl {
 
    private static final Logger logger = Logger.getLogger(BaseErrorPageManager.class);
 
    public boolean handleException(Throwable exception, FacesContext context, ExternalContext extContext) throws IOException {
     
        AssertionUtil.assertNotNull("exception", exception);
        if (logger.isDebugEnabled()) {
            logger.debug(exception.getMessage(), exception);
        }

        ServletResponse response = ServletExternalContextUtil.getResponse(extContext);
        response.setCharacterEncoding("UTF-8");
        
        StringBuffer buffer = new StringBuffer();
        buffer.append("＜html＞＜head＞＜meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /＞＜/head＞");
        buffer.append("＜body style="FONT-FAMILY: MS Pゴシック,Osaka,Hiragino Kaku Gothic Pro,Verdana,Helvetica,sans-serif"＞");
        Throwable curException = exception;
        while(curException != null){
            buffer.append("＜br＞");
            buffer.append("＜B style="font-size:11pt" ＞").append(curException.getClass().getName()).append("＜/B＞＜br＞");
            buffer.append("＜B style="font-size:10pt" ＞").append(curException.getMessage()).append("＜/B＞＜br＞");
            StackTraceElement[] elements = curException.getStackTrace();  
            for(int i = 0; i < elements.length; i++){
                buffer.append("＜span style="font-size:9pt"＞").append(elements[i]).append("＜/span＞＜br＞");
            }
            curException = curException.getCause();
        }
        
        buffer.append("＜/body＞＜/html＞");
        
        response.getWriter().write(buffer.toString());
        
        return true;
    }
}


■　teedaErrorPage.dicon の内容


＜components namespace="teedaErrorPage" ＞
 ＜component class="jp.co.mekefactory.sample.helper.BaseErrorPageManager"＞
 ＜/component＞
＜/components＞

よーし。
ちょっと、本気で自分の技術を SilverLight にシフトしてみよう。
半年以内には、サクサクプログラムを作れるようになるぞっ。


というのも、最近、自分の中で「開発の仕事が億劫」になってきていまして
まぁ、それはそれで歳のせいかなとか思ったりもしていたわけですが
気がつくと、ニュース記事なんかでも、「ITエンジニアに人気が無い、つまらない」みたいな記事を見かけるじゃありませんか。

あっれー？
ちょっと前まで開発はとても楽しかったし、「もっと凄いものを作りたい！！」という熱意で
いろんな言語、いろんな技術に興味があったのになー。

なんでつまらなくなったんだっけ？？

と言うわけで、振り返ってみたのが事の始まりでありました。


■ 開発が楽しかったのはなぜか？

アプリケーション開発って、自分で作ったものが「グリングリン」動いて、それを誰かに見せられるから楽しいのだ！！

そう。この一言に尽きると思うわけです。

いや、もちろんミドルウェアにOS、フレームワークを作るのがすきとか
UI と関係ないところに楽しさを感じる人も居ることと思います。

しかし、、、その趣向は結構マニアックな人種じゃないかと思うわけです。
そして、、、そうした人たちは、恐らく今でも「開発を楽しんでいるのです！！」（たぶん）


でも、もうちょっとライトで大多数のエンジニアの意見としては
「GUI がグリグリ動くものが作れて、誰かに見せられるから楽しい」から始まってるんじゃないのかなぁ。
と思うわけです。

そして、このブログエントリは、その前提で話が進むわけです。



■ なぜ楽しくなくなってきたのか？

これは、Webアプリケーション作成ではプログラマがGUIを作ることが出来なくなったことにあります。
そして、その根源はHTMLの非力さから来ています。（突き詰めると）


WebでGUIを作るのに必要な要素は、HTML、CSS、JavaScript、Flash と、結構イロイロあります。
これは、ひとえにHTMLが非力すぎる為に、いろんな言語・ツールの組み合わせで表現せざるを得ないからです。
その為、ユーザーをそれなりに驚かせる為には、結構な知識と経験が必要になってきます。

DivとCSS組み合わせて、JavaScriptでグリグリ動かしてウィンドウっぽく見せちゃうって、よく考えるとありえない。
無理しすぎっ！
そういうのは、Windowコンポーネントとして提供されていて、スタイルやサイズはプロパティで設定。というのが普通の流れだろっ！（＋CSSで設定の切り出し）

しかし、HTMLだけでは、こうしたコンポーネント化は出来ないので、いろんな技術を無理やり組み合わせるしかないのです。。。

そしてさらに不幸なことに、業務処理側は、Javaに、Perlに、PHPに、、、と GUIとは違う言語を覚える必要があります。
そして、こちらも、安定した品質で一定の生産性を保つには、それなりの知識と経験が必要になってきます。


そうです。
HTMLが非力なせいでGUI の表現力は完全な独自技術で進化を遂げ
業務処理系とは、全く違う言語、ツールを使うに至り、、、「デザイナ」と「プログラマ」の作業分業化が完全に確立してしまったのです。

その結果、プログラマには与えられたHTMLを維持しながら、変更部分だけを埋める作業に甘んじるか
ショボショボHTMLを自分で書いて、ユーザーから冷ややかな視線を浴び、自分のデザイン力の無さを恨みながら、涙で枕を濡らすかの
どちらかの道しかなくなったのです。


■　世の中の状況も、これを裏付けているはずだ！

開発基盤が成熟して、生産性も上がり、動作もリソースも安定しいるはずのJavaの話題があまりパッとしないことは
デザイナとプログラマの作業の完全分業化　＋　フレームワークのリッチ化による開発作業の単調化 と
何か関連があるような気がしています。

＃私も、Javaの方が経験が長いですし気に入ってもいるので、この流れは残念ではあるのですが。

そしてその一方で、（マニアな）プログラマからは言語仕様が不評のPHPが人気を博しているのは
GUI を操れるデザイナさんが覚えやすく、自分の作った画面に動作を与えるのに最適だったからじゃないでしょうか。

一世を風靡したVBにも、「まずは動く画面が作れる」という点に、PHPと共通の何かを感じます。


ユーザーは製品を見た目で評価しがちです。
多くの人に、凄い！と言ってもらえるかどうかと、GUI は分かり易く直結しており
ライトなエンジニアのモチベーションとも、割と分かり易く直結していると思うわけです。


■　しかし、なぜSilverLight　？

「なぜ楽しくなくなってきたのか？」で書いた、エンジニアからGUIが切り離されたポイントをまとめると、以下の３つになります。

・GUI 用の多くの言語とツールの習得が必要。（HTML、CSS、JavaScript、Flash 等）
・これらのツールは、業務ロジックを開発するツールと直結していない。（完全に別スキル。別作業）
・全く異なる２つの開発言語、ツールをマスターできるほどの時間は、大抵の人には無い。

SilverLight を使うと、この状況はどう変わるでしょう？

・GUIと業務ロジックで、共通言語で記述可能 （フロントもバックも .net framework の言語が）
・デザイナ用ツールと、開発者用ツールがシームレスに結合 （どちらのツールでも扱える）
・XAML＋.net framework 言語で、GUI から業務ロジックまで扱える。
・XAMLでリッチなGUI表現基盤！（HTMLの限界突破！無理やりなテクで頑張る必要なし）

なんか、説明になってるような、なってないような。

つまりっ！
SilverLightは、単なるFlashの対抗技術ということではなく
「デザイナとプログラマの分業化」という関係は維持しつつ、プログラマにもGUI デザインの領域へ踏み込ませ
開発の楽しさをよみがえらせるパワーを持っていると思うわけです！！


（ASP.NETではなく）SilverLight こそが、Web版VBになりえる可能性を秘めていると思うわけです！！


■　今後

ふぅぅ。
熱く語ってしまった・・・。

SilverLight によって、GUI がプログラマの手に戻ることでライトな楽しさが復活する可能性を感じる思いを書ききったった・・・。

プログラマの仕事は楽しくないとあかんのじゃぁぁぁ！！
作ったもので、ユーザーをアッ！！と言わしてナンボなんじゃぁぁぁぁ！！
＃でもデザイナとの分業は時代の流れというか、「餅は餅屋」

しかしながら、大規模開発となると分業化は必然であり、結局ビジネスではプログラマは、フレームワークの型の上で単調なコーディングの毎日になるような心配は、相変わらず残っています。


しかし単調な作業こそ、機械にやらせる方法を考えるべきです。
人間は、もっとクリエイティブなことに頭を使わなくては！！
ユーザーを驚かせることに頭を使わなくては！！（良い意味でな）


次回は、現在のフレームワークの限界と、ソフトウェア開発の次の進化とパラダイムシフトについて熱く語ります。（うそ）

友達がDSの「もっと英語漬け」のランキングでAAが連続で出たりしてるらしい。

最初はF（アルファベットが読めるレベルという判定）だったらしいのにっ！！

これは、Eランク（身振りで意思を伝えられる、、、という英語とは関係ない判定）のワシも頑張らなくては！！

てか毎日やってたら、そんなに伸びるもんなん？
ためしにLv７のレッスン受けてみたら、駅のホームのアナウンスの聞き取りで、殆どわかりませんでしたが・・・。


と、ここでおもむろに、ワシの中で英語の見え方が変わった瞬間を振り返ってみる。
３つのポイントがあった気が。


１．英語も日本語も難しいのだ。という謎の親近感。
２．学校で習う文法は嘘だった。と自分に合う方法で解説してくれた本との出会い。
３．言語とは、自分の気持ちを表現するものなのだ。という気づき。



最初のブレークポイントのきっかけになったのは、実は「ダーリンの頭ン中」という漫画でした（笑）
外国人の旦那を持つ奥さんの漫画なんですが、旦那が言語オタク研究者らしく、日本語と外国語の違いや類似点を説明していくなかで、日本人が持っている英語に対する偏見や敵対心（？）みたいなのを見事に払拭してくれるのです。


たとえば、「外人はなぜ、単語の通りに発音しないんだ！”Get up！” は”ゲットアップ”って言え！！　その点、日本語はひらがなの読みが全てだ！！」
と思ってませんか？

でも実は、、、日本語の「ん」でも発音記号が結構違うらしいのです！！
「ハンコ」「反応」と比較しても、実は「ん」の音が違うんだって！！

ショック！！
外国の人は、この辺が結構難しいらしい。

そして、外人にとって「ゲロッパ」は「Get Up」ってチャンと言ってるやん。
と思えるらしい。


むおお。
そうなんかーーー。

ネイティブの聞き取りと第二言語の聞き取りの違いを頭で理解してしまうと、いきなり親近感（笑）
あぁ。慣れるしかないのねん。


とはいえ、闇雲に勉強するわけにも行かないので英語の文法書を探しに探して出会ったのが
「ネイティブスピーカーの英文法絶対基礎力」って本でした。

http://www.amazon.co.jp/%E3%83%8D%E3%82%A4%E3%83%86%E3%82%A3%E3%83%96%E3%82%B9%E3%83%94%E3%83%BC%E3%82%AB%E3%83%BC%E3%81%AE%E8%8B%B1%E6%96%87%E6%B3%95%E7%B5%B6%E5%AF%BE%E5%9F%BA%E7%A4%8E%E5%8A%9B-%E5%A4%A7%E8%A5%BF-%E6%B3%B0%E6%96%97/dp/4327451924


これはもうね衝撃だった。

「あぁーーー。英語って、語順がルールのプロトコルでしたかー」みたいな目からウロコ。
（ちょっとマニアックな反応ですんません）

「が」とか「を」に該当する語が無いから、単語の順番が命なのだね。

はっはーーーん。
SQL文と同じか。（違）



この気づきに、「言語とは、自分の気持ちを表現するためのものなのだ」という気づきが加わると
同じような意味なのに沢山単語があることも、似たような言い回しなんだけど複数の文型がある理由も
すんなり納得できてしまう！

あぁ。英語使ってる人はきっと「ちょっと深い味を持たせたくて、関係代名詞使っちゃうんだね」とか
「微妙なニュアンスの違いを伝えたくて、こっちの単語とこっちの単語を使い分けてるんやなー」とか
思えてしまうのだっ！


プログラムだって、そこは if じゃなくて switch だろー。とかあることを思えば
そりゃ、日常会話では文型も単語も駆使して、細かく表現したいわなっ！！

むおお！
いつか、イメージした通りのニュアンスでクールに決めてやる！！



とりあえず、今日もまたEランクでました・・・orz