このページの右下にある、
をクリックすると、そちらに切り替わります。
一般の携帯電話と、iPhoneに対応されているようです。
例えば、iPhoneからの場合、以下のような感じで表示されます。
興味がある方は、覗いてみてください。]]>
このように便利な機能なのですが、Oracleで使用するときには、注意する必要があります。たまたまそのことを思い出したので、特に目新しいネタではないかもしれませんが、自分のメモを兼ねて、書いておこうと思います。
ResultSet からデータをフェッチする場合、setFetchSize(int)メソッドの規則に定められた行数のデータが、DBサーバから取得されるという前提で、プログラミングします。ところが、Oracleで「スクロール可能なResultSet」を使った場合、そのResultSetで対象となるデータが、一度に全件クライアント側にキャッシュされてしまいます。したがって、バッチ処理のように、大量のデータが対象になっていると、OutOfMemoryErrorが発生する可能性があるので注意が必要です。
以下に、そのことについて書かれた、Oracle社のドキュメントへのリンクを示しますので、詳細はそちらをご参照ください。
Oracle Database JDBC開発者ガイドおよびリファレンス 10g リリース2（10.2）
Oracle Database JDBC開発者ガイドおよびリファレンス 11g リリース1（11.1）]]>
タイトルのtributaryという単語は、このブログを本流と例えた場合の、「支流」というのイメージしたものです。
tumblrは、アカウントを作って、その瞬間に始められるので、まだ、ブログを持っていない方が、ちょっと試してみようという感じで、やってみるのもいいかもしれませんね。
]]>Adobe AIRのアーキテクチャを分類すると、以下の3パターンに分けることができます。
では、「Flexベース」の方はどうでしょうか。こちらも、同じ観点で技術要素を整理してみます。
すでに、Ajaxベースの開発で、高い技術を持ち、Flushテクノロジーを使わずに機能が実現できるのあれば、「Ajaxベース」を採用するのが自然な流れです。どうしてもFlushは採用できないという事情がある(AIRを前提で、そんなものはないと思いますが。。。)以外の場合には、楽に簡単にできそうな面があるのなら、Ajaxで無理をすることばかりを考えず、Flexの採用を検討してみてもいいかもしれません。
新しい技術にチャレンジする時は、できること、やりたいこと、必要なこと、コストなど、いろいろな角度から見て判断することが重要ですね。]]>
ウォーターフォール型プロセスの誕生の背景的なことが、こちらに説明されています。
ウォーターフォール・モデル
当時は、そのときの環境に適したプロセスとして、採用され、広まっていったものと考えられます。
個人的には、当時の開発環境が、1つの大きなポイントだったのではないかと推測します。
1980年代くらいまでは、メインフレームが開発環境の中心でした。メインフレームで運用されるアプリケーションだけでなく、ワークステーション上で実行されるプログラムも、メインフレームでクロスコンパイルすることもありました。なので、多くの開発者が、1つのホストコンピュータを共同利用して作業を進めていました。
ところが、端末はすべての開発者に1つずつ行き渡っているわけではなく、限られた数しか用意できませんでした。そのような環境下では、よほどの理由がない限り、一人の開発者が占有するなどということは許されませんでした。端末は、「作業場所」であり、ものを考える場所ではなかったのです。
では、ものをじっくり考える場所はどこかというと、「机上」です。「机上」の作業だけで、ある程度精度の高い設計ができていることが前提で、開発プロセスが策定されていました。ソースコードまでも、紙に書く場合がありました。
このような環境の中では、必然的にウォーターフォール型になるように思います。すでに、基本アーキテクチャは決まっており、開発という側面では、技術は安定していました。それにより、技術的リスクがあまりなかったということも背景としてあったと思います。
そのような状況からの変化が始まったのは、90年代前半くらいからかなと記憶しています。「ダウンサイジング」「クライアント/サーバ」「EUC(End User Computing)」などのキーワードとともに、それまでメインフレームでしか動かせなかったアプリケーションが、ワークステーションやPCという、ユーザに近いところに降りてきました。当然、基本アーキテクチャは大きく変わりました。それまで、書類が並んでいた「机上」に個人専用のPCが置かれ、インターネットを通じて、さまざまな情報にアクセスできるようになりました。言うまでもないですが、前段で述べたときとは、かなり環境は違います。
私の観点では、主要な変化として捉えるべき点は、以下のようなものだったかなと思います。
前置きがちょっと長くなってしまいましたが、ここで言いたかったのは、ウォーターフォール型 vs. アジャイル型というのを、単純に思想とか文化として考えたり、どちらか一方に偏るのではなく、必要に応じてやりやすい最適な方法を選ぶことが重要だと言うことです。
現在、企業システムの世界は、JavaEEによって基本アーキテクチャがかなり安定して来ており、90年代や00年代前半に比較すると、「初物」に出会う機会もかなり少なくなってきました。それでも、メインフレームの時代にくらべると、「トライ & エラー」が必要な場面は多いと思います。
ウォーターフォール型だけではやりにくい部分があるのは明白です。現実的に、最もやりやすいと思われる方法を検討し、柔軟に計画を策定することを考えて行くことが適切なのでしょう。
この記事の中ではもう一つ、以下のような数字が出ています。
現在、画期的なApp Storeでは35,000本以上のアプリケーションが世界77カ国のお客様に提供されており、デベロッパには、世界中の何千万ものiPhone™およびiPod touchユーザにリーチする機会を提供しています。
1ユーザが平均で50本ダウンロードしていると仮定した場合でも、単純計算で2000万ユーザという数字になるので、「何千万ものユーザ」というのは、決して大げさではないでしょう。
ニンテンドーDSは、初代が発売開始から1年で、1637万台ということなので、それと比べても遜色ない数字ですね。
ただ、これはあくまでも、世界レベルでの比較です。日本国内に限定した場合は、また違うでしょう。
あと、AppStoreには「無料のアプリケーション」も多くリリースされており、それらがこの10億本という数字を底上げしてる可能性もあります。
このように単純比較はできないですが、勢いがあることは事実だと思います。
私も、昨年の秋くらいから、iPhoneアプリケーションの開発に参加しています。そんなわけで、インターネット上で、いろいろなIPhoneアプリケーションデベロッパーの方々のブログなども、よく読ませていただいてます。そこから感じるのは、こんなにさまざまなタイプのデベロッパーが1つのプラットフォーム上に集まっているというのは、今までに例がないのではということです。
たぶん、自らやってみたいと思う人々が、積極的かつ、自然に集まった結果なんでしょうね。
(「業務命令」で、仕方なくiPhoneアプリケーション開発をやっている人は少ないんじゃないかと感じてます)
そして、半年ほど前になりますが、AppStoreから、無料のアプリケーションを1本リリースしました。
自分のアプリが、海外の見知らぬ人からダウンロードされたり、どこかのブログや雑誌で取り上げてもらったりといった、今までになかった新しい経験ができました。でも、現時点では、今後自分たちのビジネスに、どのように結びつけることができるかについては、まだ未知数です。
ただし、この勢いは見逃してはいけないと思うので、これからもウォッチして行きたいと思います。
当然ながら、自分もiPhoneユーザの一人なので。。。]]>
Javaのようなオブジェクト指向言語で開発する場合、そんなレベルの仕様書を、机上で頭の中で考えただけで書くことは、ほぼ不可能に近いと思います。というよりも、そこまで書けるのであれば、その人が実装までしてしまう方が効率がよいことは自明の理です。でも、この時点で、旧来のプログラミングが単純労働であるという前提は崩れてしまっていますね。
とはいっても、作業を単純化(シンプルに)することで、生産性の向上が期待できるので、何とか実現したいところです。
そこで、「SE」という立場の人たちの仕事として、プロジェクトの目的に合ったシステムアーキテクチャを考えることが重要になってきます。そのときに考えるべきことは、ビジネスロジック開発担当者が、エラーハンドリングやトランザクション管理などといった、制御ロジックから解放され、ビジネスロジックの実装に集中できるような、「シンプルでわかりやすい」環境を作ることです。重要なのは、単純化の真の目的は、考えることを減らすのではなく、本来考えてほしい部分に注力できるようにすることです。
そのために必要なライブラリやフレームワークは、既存の製品だけでは不十分なので、自前で開発しなければならないものが出てきます。当然、そのためのプログラミングもすることになります。
そういったことを考える中で、ビジネスロジック開発担当者に、何をしてもらえばいいのかも見えてくるので、どういった仕様書を作れば、効率よく作業を進めて行けるのかも明らかになるでしょう。
このように、事前の環境整備や準備をして複雑さを緩和することによって、開発作業はシンプルなものにすることができます。
旧来のような「SE」と「プログラマ」という分業体制を前提に、安易に「上から目線」で「プログラミングは単純作業である」とは、言えないのです。]]>
をクリックすると、そちらに切り替わります。
一般の携帯電話と、iPhoneに対応されているようです。
例えば、iPhoneからの場合、以下のような感じで表示されます。
興味がある方は、覗いてみてください。]]>