kimada's weblog

JDBC2.0から、スクロール可能なResultSetがサポートされています。それによって、ResultSetから、データをフェッチするときに、開始位置を指定したり、カーソルの移動を逆方向にすることができます。

このように便利な機能なのですが、Oracleで使用するときには、注意する必要があります。たまたまそのことを思い出したので、特に目新しいネタではないかもしれませんが、自分のメモを兼ねて、書いておこうと思います。

ResultSet からデータをフェッチする場合、setFetchSize(int)メソッドの規則に定められた行数のデータが、DBサーバから取得されるという前提で、プログラミングします。ところが、Oracleで「スクロール可能なResultSet」を使った場合、そのResultSetで対象となるデータが、一度に全件クライアント側にキャッシュされてしまいます。したがって、バッチ処理のように、大量のデータが対象になっていると、OutOfMemoryErrorが発生する可能性があるので注意が必要です。

以下に、そのことについて書かれた、Oracle社のドキュメントへのリンクを示しますので、詳細はそちらをご参照ください。
Oracle Database JDBC開発者ガイドおよびリファレンス 10g リリース2（10.2）
Oracle Database JDBC開発者ガイドおよびリファレンス 11g リリース1（11.1）

ちょっと思いついた比較的軽めの話題について、気軽に書き込んで行くためのミニブログを、tumblr で始めてみました。

kimada's tributary weblog

タイトルのtributaryという単語は、このブログを本流と例えた場合の、「支流」というのイメージしたものです。

tumblrは、アカウントを作って、その瞬間に始められるので、まだ、ブログを持っていない方が、ちょっと試してみようという感じで、やってみるのもいいかもしれませんね。

現在、多くのWebアプリケーションは、Ajaxと呼んでいる、一連の高度なJavaScriptの応用技術によって、リッチなユーザインタフェースを持っています。クライアント側でのプログラミングを行わず、プレーンなHTMLだけで構成されているものはほとんどなくなって来ています。そんな中、ここ最近は、さらに進化した、クライアントサイドのデスクトップアプリケーションとして動作するRIA技術が、注目されています。

RIA技術の代表的なものとしては、以下の3つが挙げられます。

• Adobe AIR
• JavaFX
• Microsoft Silverlight

この中で、Adobe AIRについて、ちょっと調べてみました。とりあえず、AIRを選定した理由にはあまり深い意味はなく、これまでのWebアプリケーション開発技術をそのまま引き継いだものなので、JavaEE系を始めとする、多くのWebアプリケーション開発者が、比較的入りやすいのではないかといったところです。

Adobe AIRのアーキテクチャを分類すると、以下の3パターンに分けることができます。

• Ajaxベース
• Flexベース
• Flashベース

この中で採用するアーキテクチャを選択する場合、企業向けのアプリケーションを開発しているJavaEE系の開発者の場合は、まず、直感的にAjaxベースにすることが多いでしょう。「Ajaxベース」の技術要素を整理すると、以下のような感じです。

• 開発言語
  HTML + CSS + JavaScript
• 実行環境
  Adobe AIRランタイムに組み込まれている、WebKit HTMLエンジン上で動作する。
• 開発環境
  
  • 無料で使えるもの
    • Adobe AIR SDK + テキストエディタ
    • Aptana Studio(Eclipse + Aptana用Adobe AIRエクステンション)
  • 有料のもの
    • Adobe Dreamweaver CS3＋Adobe AIR Extension for Dreamweaver CS3

ここから見ると、従来のブラウザ上で実行されていた、Ajaxアプリケーション開発のスキルが生かせるという印象を持つことができます。あと、無料で使える開発環境でも、今までの開発作業と、あまり変わらずに行けそうな感覚もありますね。

では、「Flexベース」の方はどうでしょうか。こちらも、同じ観点で技術要素を整理してみます。

• 開発言語
  MXML + ActionScript
• 実行環境
  Adobe AIRランタイムに組み込まれている、Adobe Flash Player 9の仮想マシンで動作する。
• 開発環境
  
  • 無料で使えるもの
    • Flex 3 SDK + テキストエディタ
  • 有料のもの
    • Adobe Flex Builder 3 Professional(Adobe Flex Builder 3.0.2 Professional Eclipse Plug-in)

FlexはふつうのGUIアプリケーションを、Flashコンテンツとして開発するためのフレームワークです。コンパイルすると、MXMLもActionScriptに変換され、最終的にはSWFファイルとなります。
すでにFlexでアプリケーション開発を経験しているのであれば、迷わずこちらを選択するでしょう。
未経験の場合は、MXML、ActionScriptという「独自言語」を習得しなければならないことが気になるところかと思います。それに関しては、HTML、XML、JavaScriptがわかっていれば、容易に習得できるので、あまり重要な条件ではないでしょう。
そういうことだけでなく、例えば、以下のようなことも考えた上で、総合的に判断することが必要です。

• 現在、Ajaxベースで、効率の良い開発ができているか?
  WebアプリケーションのAjaxに比べて、明らかにJavaScriptのコーディング量は多くなるので、そのあたりのことも考慮しておくべき。稼働環境が、AIRランタイムのWebKitエンジンに限定されるので、
  • クロスブラウザの考慮が必要ない
  • AIRやFlushで用意されているAPIが使える。
  といった部分によって、開発しやすくなる部分はあると思われる。
• 要件として、Flashの機能が必要かどうか?
  クールなGUIが要求され、それがFlashだと作りやすいのであれば、無理にAjaxでがんばるのは考えもの。
• 新しい技術にチャレンジする状況かどうか?
  これには、プロジェクトの状況や、会社の方針、開発者の想いなど、いろいろな要素があるが。。。
• 有償の開発環境を導入できるか?
  Flexの場合、SDK + テキストエディタベースで開発するには、熟練が必要と考えられる。Flex Builderを使った方が、効率よく開発できる。

すでに、Ajaxベースの開発で、高い技術を持ち、Flushテクノロジーを使わずに機能が実現できるのあれば、「Ajaxベース」を採用するのが自然な流れです。どうしてもFlushは採用できないという事情がある(AIRを前提で、そんなものはないと思いますが。。。)以外の場合には、楽に簡単にできそうな面があるのなら、Ajaxで無理をすることばかりを考えず、Flexの採用を検討してみてもいいかもしれません。

新しい技術にチャレンジする時は、できること、やりたいこと、必要なこと、コストなど、いろいろな角度から見て判断することが重要ですね。

システム開発プロセスについての話の中で、ウォーターフォール型 vs. アジャイル型という観点で議論されることは、よくあることです。その場合、ウォーターフォール型を、単なる思想とか文化として捉えられていることが多いように感じます。

ウォーターフォール型プロセスの誕生の背景的なことが、こちらに説明されています。
ウォーターフォール・モデル

当時は、そのときの環境に適したプロセスとして、採用され、広まっていったものと考えられます。
個人的には、当時の開発環境が、1つの大きなポイントだったのではないかと推測します。
1980年代くらいまでは、メインフレームが開発環境の中心でした。メインフレームで運用されるアプリケーションだけでなく、ワークステーション上で実行されるプログラムも、メインフレームでクロスコンパイルすることもありました。なので、多くの開発者が、1つのホストコンピュータを共同利用して作業を進めていました。
ところが、端末はすべての開発者に1つずつ行き渡っているわけではなく、限られた数しか用意できませんでした。そのような環境下では、よほどの理由がない限り、一人の開発者が占有するなどということは許されませんでした。端末は、「作業場所」であり、ものを考える場所ではなかったのです。
では、ものをじっくり考える場所はどこかというと、「机上」です。「机上」の作業だけで、ある程度精度の高い設計ができていることが前提で、開発プロセスが策定されていました。ソースコードまでも、紙に書く場合がありました。
このような環境の中では、必然的にウォーターフォール型になるように思います。すでに、基本アーキテクチャは決まっており、開発という側面では、技術は安定していました。それにより、技術的リスクがあまりなかったということも背景としてあったと思います。

そのような状況からの変化が始まったのは、90年代前半くらいからかなと記憶しています。「ダウンサイジング」「クライアント/サーバ」「EUC(End User Computing)」などのキーワードとともに、それまでメインフレームでしか動かせなかったアプリケーションが、ワークステーションやPCという、ユーザに近いところに降りてきました。当然、基本アーキテクチャは大きく変わりました。それまで、書類が並んでいた「机上」に個人専用のPCが置かれ、インターネットを通じて、さまざまな情報にアクセスできるようになりました。言うまでもないですが、前段で述べたときとは、かなり環境は違います。
私の観点では、主要な変化として捉えるべき点は、以下のようなものだったかなと思います。

• 各自が専用のPCを持つことによって、考えながら開発することができるようになった。


• 技術トレンドの変化が激しくなり、「初物」に出会う確率が高くなった。


• マルチベンダー化により、1つのことを実現するための選択肢が増えた。

当たり前の話ですが、このあたりの開発では、「R&D」や「プロトタイピング」といった「トライ & エラー」を経由せずに、「机上」の理論だけで作業を進めて行くことは、不可能であり、やりにくいということは明白ですね。こういった環境の中では、仮にウィータフォール的にスケジュールが策定されていたとしても、実態はアジャイルっぽくなるのが必然ですね。

前置きがちょっと長くなってしまいましたが、ここで言いたかったのは、ウォーターフォール型 vs. アジャイル型というのを、単純に思想とか文化として考えたり、どちらか一方に偏るのではなく、必要に応じてやりやすい最適な方法を選ぶことが重要だと言うことです。
現在、企業システムの世界は、JavaEEによって基本アーキテクチャがかなり安定して来ており、90年代や00年代前半に比較すると、「初物」に出会う機会もかなり少なくなってきました。それでも、メインフレームの時代にくらべると、「トライ & エラー」が必要な場面は多いと思います。
ウォーターフォール型だけではやりにくい部分があるのは明白です。現実的に、最もやりやすいと思われる方法を検討し、柔軟に計画を策定することを考えて行くことが適切なのでしょう。

ちょっと前のことになりますが、ゴールデンウィーク直前の4/24に、アップルから、このような発表がありました。

アップルの革新的なApp Storeからのダウンロード、わずか9ヶ月で10億本を突破

この記事の中ではもう一つ、以下のような数字が出ています。

現在、画期的なApp Storeでは35,000本以上のアプリケーションが世界77カ国のお客様に提供されており、デベロッパには、世界中の何千万ものiPhone™およびiPod touchユーザにリーチする機会を提供しています。

1ユーザが平均で50本ダウンロードしていると仮定した場合でも、単純計算で2000万ユーザという数字になるので、「何千万ものユーザ」というのは、決して大げさではないでしょう。
ニンテンドーDSは、初代が発売開始から1年で、1637万台ということなので、それと比べても遜色ない数字ですね。

ニンテンドーDSシリーズ１億台販売

ただ、これはあくまでも、世界レベルでの比較です。日本国内に限定した場合は、また違うでしょう。
あと、AppStoreには「無料のアプリケーション」も多くリリースされており、それらがこの10億本という数字を底上げしてる可能性もあります。
このように単純比較はできないですが、勢いがあることは事実だと思います。

私も、昨年の秋くらいから、iPhoneアプリケーションの開発に参加しています。そんなわけで、インターネット上で、いろいろなIPhoneアプリケーションデベロッパーの方々のブログなども、よく読ませていただいてます。そこから感じるのは、こんなにさまざまなタイプのデベロッパーが1つのプラットフォーム上に集まっているというのは、今までに例がないのではということです。
たぶん、自らやってみたいと思う人々が、積極的かつ、自然に集まった結果なんでしょうね。
(「業務命令」で、仕方なくiPhoneアプリケーション開発をやっている人は少ないんじゃないかと感じてます)

そして、半年ほど前になりますが、AppStoreから、無料のアプリケーションを1本リリースしました。
自分のアプリが、海外の見知らぬ人からダウンロードされたり、どこかのブログや雑誌で取り上げてもらったりといった、今までになかった新しい経験ができました。でも、現時点では、今後自分たちのビジネスに、どのように結びつけることができるかについては、まだ未知数です。
ただし、この勢いは見逃してはいけないと思うので、これからもウォッチして行きたいと思います。

当然ながら、自分もiPhoneユーザの一人なので。。。

大規模なSIプロジェクトでは、人海戦術に頼らざるを得ない場面が少なからずあるので、開発作業を単純化し、要員確保をしやすくするといったアプローチが必要になります。
従来は、「SE」と「プログラマ」という分業体制の中で、「SE」が「詳細に記述された仕様書」を作って、「プログラマ」に渡すことを前提に、プログラミングを「単純作業」として捉えていた部分があったと思います。今でもその風潮は根強く残っていることがあるようですが、はたして、それでいいのでしょうか?

Javaのようなオブジェクト指向言語で開発する場合、そんなレベルの仕様書を、机上で頭の中で考えただけで書くことは、ほぼ不可能に近いと思います。というよりも、そこまで書けるのであれば、その人が実装までしてしまう方が効率がよいことは自明の理です。でも、この時点で、旧来のプログラミングが単純労働であるという前提は崩れてしまっていますね。

とはいっても、作業を単純化(シンプルに)することで、生産性の向上が期待できるので、何とか実現したいところです。 そこで、「SE」という立場の人たちの仕事として、プロジェクトの目的に合ったシステムアーキテクチャを考えることが重要になってきます。そのときに考えるべきことは、ビジネスロジック開発担当者が、エラーハンドリングやトランザクション管理などといった、制御ロジックから解放され、ビジネスロジックの実装に集中できるような、「シンプルでわかりやすい」環境を作ることです。重要なのは、単純化の真の目的は、考えることを減らすのではなく、本来考えてほしい部分に注力できるようにすることです。
そのために必要なライブラリやフレームワークは、既存の製品だけでは不十分なので、自前で開発しなければならないものが出てきます。当然、そのためのプログラミングもすることになります。
そういったことを考える中で、ビジネスロジック開発担当者に、何をしてもらえばいいのかも見えてくるので、どういった仕様書を作れば、効率よく作業を進めて行けるのかも明らかになるでしょう。

このように、事前の環境整備や準備をして複雑さを緩和することによって、開発作業はシンプルなものにすることができます。
旧来のような「SE」と「プログラマ」という分業体制を前提に、安易に「上から目線」で「プログラミングは単純作業である」とは、言えないのです。

MoFuseというサービスを使って、このブログのモバイルバージョンを作ってみました。(最近、全く更新が止まっているのに、意味あるのかって思うかもしれませんが......)
このページの右下にある、

をクリックすると、そちらに切り替わります。
一般の携帯電話と、iPhoneに対応されているようです。 例えば、iPhoneからの場合、以下のような感じで表示されます。

そのサイトのRSSの情報から、モバイル用のページを自動生成してくれているようですが、無料サービスなので、生成されたページには広告が挿入されます。その他、自分でページの追加やロゴの挿入などのカスタマイズもできるようです。

興味がある方は、覗いてみてください。

Mail.appを使っていて、ずっと気に入ってないことが1つありました。メッセージヘッダーが日本語化されてしまっていることです。
メッセージを表示している画面ではいいのですが、転送するときにも、引用されたメッセージのヘッダーのキーが日本語になっているのは、いただけませんね。「Begin forwarded message」が英語なところも、アンバランスだし。。。

Begin forwarded message:

> 差出人: XXXXX XXXXX 
> 日時: yyyy年mm月dd日 hh:MM:ss:JST
> 宛先: XXXX XXXX ,......
> 件名: XXXXXXXXXXXXXXXXXXXXXXX
........

もしも、英語で海外の人とメールをやりとりしている場合、この部分が必ず文字化けしてしまいますよね。とりあえず、Mail.appのプリファレンスの設定では、ここを英語にするための設定はないようです。そこで、アプリケーションのリソースを変更してみようといろいろ探ってみたところ、目的のものを見つけることができたので、自分自身のメモを兼ねて、以下にまとめました。

注: この操作の危険度はそれほどないと思いますが、Appleよってサポートされているわけではなく、正式な手順でもないので、もしも試す場合は、オリジナルファイルのバックアップを保存しておくなど、あくまでも自己責任でお願いします。

• 対象ファイル

  /System/Library/Frameworks/Message.framework/Versions/B/Resources/Japanese.lproj/Message.strings

• ファイルの編集
  上記のファイルを、どこか書き込み権限のあるフォルダにコピーし、Xcodeを使って開き、コメントに"header of a message"と書かれている要素の値を、英語に変更する。

  編集例
  /* String used when displaying the From header of a message in the main window. 
  This value is only ever used for display and will not be part of any outgoing email. */
  // "From" = "差出人";
  "From" = "From";
  

• 編集したファイルを、元のファイルに上書きする。
• 日付の書式に、漢字が含まれないようにする。
  「システム環境設定」の[言語環境] - [書式]で日付の[カスタマイズ]を選択し[長]の書式に漢字が含まれないように変更する。
• マシンを再起動する。

設定が成功した場合、転送の引用メッセージのヘッダーには、以下の例のように、自分で設定した文字列が表示されます。

Begin forwarded message:

> From: XXXXX XXXXX 
> Date: yyyy/mm/dd hh:MM:ss:JST
> To: XXXX XXXX ,......
> Subject: XXXXXXXXXXXXXXXXXXXXXXX
..........

将来のアップデートで、このあたりの設定がプリファレンスで簡単にできるようになることを期待しています。(そもそも、メッセージヘッダーの日本語化自体が必要ないと思うのは、私だけでしょうか。。。)

ついに、日本にも、iPhoneがやってくるようですね。

「iPhone」について

この度、ソフトバンクモバイル株式会社は、今年中に日本国内において「iPhone」を発売することにつきまして、アップル社と契約を締結したことを発表いたします。

高解像度のカメラや、おサイフケータイ、ワンセグなどの機能を売りとする日本の携帯電話市場の中で、どんな展開になるのか楽しみですね。
個人的には、ぜひ欲しいと思いますが、現実的に考えると、今使っているものはキープしたまま、2台目として持つことになるんでしょうかね。。。

Time Machineのバックアップで、対象データが数百MBしかないのに、1時間経っても終わらないときがあるので、かなりストレスを感じてました。ちょっと調べてみたところ、Adjusting Spotlight for your Time Machine backup!を見つけました。

バックアップ先として指定しているHDDが、Spotlightの検索対象になっていることが原因のようです。

1. Open System Preferences.
2. Choose Spotlight.
3. Click on the Privacy tab.
4. Click on the "+".
5. Navigate to your backup disk and find the folder called "Backups.backupdb".
6. Click "Choose".
7. That's it. The backup should now be excluded from Spotlight searches.

私の場合、"Backups.backupdb"を選択するとエラーになったので、HDDのルートを選択してみたところ、うまく行きました。