API構築の基礎を学んだ。QConは、開発者コミュニティにおける知識とイノベーションの普及を促進することで、ソフトウェア開発に力を与える。実務者主導のカンファレンスであるQConは、チーム内のイノベーションに影響を与える技術チームのリーダー、アーキテクト、エンジニアリングディレクター、プロジェクトマネージャー向けにデザインされている。Sheehy氏は、人工知能ハイプ時代における責任ある開発者としてのあり方について、洞察に富んだ開会基調講演をした。Grizzanti氏が、「スタッフ・プラス」への道と、それを「科学」というより「芸術」としてとらえ、芸術を創作することとソフトウェアを創作すること、そして組織のダイナミクスに対処することの類似性について語っている。Codeを採用する:確認するべき6つの適性LCNC(ローコード/ノーコード)プラットフォームは、プログラマーだけでなくプログラマーでなくても、最小限のコーディングとワンクリックのデプロイメントで、アプリケーションソフトウェアを開発できるよう設計されている。ドラッグ&ドロップ方式のインターフェースなどを利用することで、開発・デプロイメントプロセスを簡素化し、効率的なアプリケーション開発とデプロイメントを実現する。連載、「Officeのリッチクライアントアプリケーション」で、我々は、基準としてOffice2007プラットフォームを使い、様々な異なる方法でJavaテクノロジーと相互運用するリッチクライアントアプリケーションをどこから構築するかについて議論しました。その際にカバーされなかったOfficeとJavaの相互運用性の1領域は恐らく最も古びた方法になっているでしょう。OfficeとJavaは、JavaアプリケーションはOffice文書を操作し、文書を作成し、編集し、文書中からデータを抽出して取得する等等、といったように相互に連携するのですから。PowerPoint)がバイナリ形式で保存されることが歴史的に常に何かと問題となってきましたが、これは世界中のCOM開発者には構造化された保存形式として知られており、本来、COMインタフェースを使ってアクセスする階層化されたバイナリ形式なのです。Basic、Delphi、C++/ATLのようにCOMを意識した言語開発者)にとって大変有用なアプローチではあるものの、ファイルの内容が、COMをサポートしていない言語では作成したファイルにアクセスすることは不可能でした。これらのファイルの内容にJavaからアクセスできる回避方法は、アプリケーションからアプリケーションへと大胆に変化していきました。Excelはカンマで区切られた値(CSV)のファイルを読むことができるのはよく知られたことですから、Excelが使える形式にデータを抽出したいJavaアプリケーションは、データをCSV形式(間違いなく見苦しいフォーマットなのですが)に抽出するのです。Wordにしても、勿論のことリッチテキスト形式(RTF)ファイルを読むことができ、RTFの仕様は公開されており、幾分はきちんと文書化されていました。Officeのその後のバージョン、すなわちOffice2003は、それ自身ユニークな(WordMLのように)新しいXML形式を発表しました。Java開発者はそれを使ってOffice文書を読み書きできるのですが、その形式はきちんと文書化されていなかったので、Java開発者は頻繁にトライアル・アンド・エラーの開発により、自分たちでWordML形式を学ぶこととなりました。様々なオープンソースプロジェクトが状況を軽減しようと試みました。ApacheからのPOIフレームワークのように、Excel文書を読み書きするために、また、様々なJava-COMソリューションが、Javaの開発者は、Office自身が使用するのと同様の構造化ストレージAPIを使って、Officeファイルを読み書きできると示唆しました。それはとても十分ではありませんでした。文書の形式の内部構造を解明しなければなりませんでした。それはかなり複雑な形式で、勿論、全く文書化されていませんでした。全般的に、Java/Officeストーリーは、控えめに言っても、極めて不快な状態でした。Javaの開発者はじっと耐えるか、「Officeは最低だ。訴訟問題のせいで、JavaはOfficeを理解することができないのだ、と言ってみるかしかありませんでした。関連スポンサーコンテンツOffice2007で、Microsoftは疑いもなく、これらの問題の重要な部分を「解決」しました。ネイティブJDKそのもの以上に複雑なものは何もなく、言い換えれば、サードパーティのライブラリは必要なく、Javaアプリケーションは今やOffice2007のいかなる文書をも読み書きできるのです。Office2007の文書は今やXML文書のZIPファイル以外の何物でもないからです。XML」の仕様として知られており、C#言語とCLIランタイムの仕様を収めている欧州コンピュータ製造工業会(ECMA)に提出されています。オープンXMLの仕様は、ECMA(サイト・英語)で誰でもフリーでダウンロードできるようになっています。2007の文書を自在にオープンすることができ、うまみのある中心をかきだし、コンテンツを操作し、データを再保存することができます。Halloway氏により最初に開発された、探査テストと呼ばれるテクニックを使うことになるでしょう。探査テストでは、開発者は、自分たちがAPIを探査できるようにユニットテストを書きます。それは、従来のユニットテスト世界のテストアサーションの意味を使って結果を検証するものです。探査テストの副次的な利点は、この例のように、APIの新しいバージョンが利用可能になり、新しいバージョンを検証するため新しいバージョンのOfficeがテストを実行可能な際、APIの利用モデルにおいて何も変更する必要が無いということです。はじめに、Office2007文書を概観してみましょう。シンプルなWord2007文書になり、このように、まさにプレーンなテキストを含んでいます。保存する際は、Word2007は、過去の文書との互換性を持つ形式、すなわちOffice2003のWordMLか更に古いWord97以降のバイナリ構造のストレージ形式かを指定しない限り、このように”Hello.docx”として保存します。”.docx”形式はオープンXMLフォーマットであり、そしてMicrosoft独自の文書化によれば、XML文書のZipファイルであり、以前のバージョンのOfficeでバイナリ構造で格納するAPIがデータを保存していたのと類似した方法でデータを保持し、文書をフォーマットしています。"jar"ユーティリティはファイルのコンテンツを表示することができるはずです。実際、表示は可能です。Word2007の文書形式の基本構造は既に結果出力を見ることにより極めて明確です。(そしてjarユーティリティがこれを理解するという事実はそれ自体、興奮に値することなのです。java.util.zipパッケージが極めて簡単にコンテンツにアクセスできる、ということなのです。)いかなる仕様書をクラックしてオープンすることも無く、コアとなる文書のコンテンツはdocument.xmlに保存され、XMLファイルの残りの部分は様々な補足部分になっています。theme1.xml・・・といったぐあいに。今回は、幾つかの探査テストを書いてみます。4テストクラスにそれらを追加し、イマジネーションがそれらを受け取るようにテストを拡張することをお勧めします。)JUnit4を使った最初のテストは、単純にファイルが期待される位置に存在することを確認します。(これは、残りのテストを実行する際には明白な要件となります。File("hello.docx").canWrite());}次のテストは、Javaライブラリの最も明白な候補であるjava.util.zip.ZipFileを使い、ファイルが開けることを単純に検証するものです。"hello.docx");}今までのところ、うまくいっています。JavaのZipFileは、ファイルが実際にzipファイルであることは認識します。不運に見舞われなければ、コンテンツを繰り返しみて、内部のデータを確認することができるでしょう。さあ、コンテンツの最初から最後まで、”document.xml”というファイルを繰り返し探す、クイックテストを書いてみましょう。assertTrue(documentFound);}しかし、奇妙なことに、実行時、このテストは次のようなテストフェイルを出力します。”document.xml”は見つからないようです。ZipFile或いはZipEntryを使うと、APIはアーカイブの内部にマッチすべき完全なディレクトリ名、ファイル名を要求するからです。上記テストは”word/document.xml”に変更すれば、合格です。文書を探すことが適正であれば、次に、それをオープンし、内部のXMLを見てみましょう。これは極めて簡単です。ZipFileはZipEntryそのものを名前で返してくれるAPIを持っているからです。assertNotNull(documentXML);}驚くことではありませんが、getInputStream()コールがInputStreamを返すのを経由して、ZipFileコードはそれ自身が持っているエントリーの内容を返すことができます。InputStreamをDOMファクトリーノードの中に送り込むと、文書それ自体のDOMを作成します。doc.getDocumentElement().toString());}実際に、document.xmlコンテンツ(下記のように、名前空間宣言は明確にするために削除されます)は、Wordがサポートする必要のある、広範囲の種類のフォーマッティングをサポートする他のXML文書形式に比べ、極めて単調に見えます。</w:document>これらの各要素が何を意味するのかについての十分な詳細については、この記事の範囲を越えているので、読者は、完全なリファレンスについては、オープンXMLドキュメンテーションセットを参照してください。2007!"という1つのセンテンスを見つけることになります。ファイルの内容を読み、今やそれらの内容を変更でき、ファイルに書き戻し、Word2007でオープンすることもできるということは素晴らしいことに違いないでしょう。ZipEntryのAPIを概観すると、ある問題を示しています。これらのクラスはzipファイルを読むのに使うことができますがzipファイルを書くための機能を持っていないのです。この特別な欠陥を是正するために様々な仕組みが用意されています。1つのアプローチは、単純にXMLテキストを文字列に書き出し、その文字列をdocument.xmlファイルに保存し、ZipOutputStreamクラスを使ってコンテンツ全体を再度zipすることです。1つのアプローチはzipコンテンツを適切に編集できるサードパーティのツールを使う(或いは構築する)ことかもしれません。これはコアJDKそれ自体では無いので、この記事では、ZipOutputStreamを取り上げることにしましょう。これら全てが起こるためには、2、3のことが必須になります。第一に、JavaアプリケーションはDOM階層構造を検索し、"t"ノードを発見し、そのテキストコンテンツをWord文書に送り返すべきメッセージで置き換えなければなりません。Java6!"はともかくも妥当であるように思われます。APIを使って実行することが簡単ではないので、結果として生じるDOMインスタンスはディスクに保存されなければならなりません。(一言で言えば、開発者はjavax.xml.transformパッケージからTransformerを作成しなければなりません。identity-transformを実行しなければなりません。ひとたび全てが為されれば、今回はZipOutputStreamを使って、コードは新しいZIPファイルを生成しなければなりません。ファイルのコンテンツが変更される必要があるがために、スタイルやフォント、フォーマットではなく、その他のオリジナルファイルのコンポーネントが再度元からコピーされなければなりません。単純なループは、ソースファイルからZipEntriesをひとつずつ繰り返し処理し、コンテンツ全体(コンテンツが変換されたバイト列である"word/document.xml"は例外とします)を新しいZipEntryにコピーして、そのエントリーに書きだすという単純なループ処理で十分でしょう。全ての処理が終わると、コードは下記のように見えます。docxOutFile.close();}ここに表示されたコードの量についてお詫びしなければなりません。実際、これがJavaの他言語やライブラリに比較して最も弱い領域の1つなのです。幸いにも、結果は、結果として生じる文書がそう見える以外のところに代償を払います。このシナリオを改善するのにいくつかの対策があることは明らかです。DOM構造をディスクに戻す、そのようなXML操作ライブラリはここにあるコードの量を削減するのに大きな助けとなるでしょう。オープンソースのJava/XMLライブラリであるJDOM(jdom.orgで利用可能である)は当然の選択です。ApacheからのXMLBeansも同様でしょう。OpenXML形式を記述するスキーマ文書を取得し、それらを使ってOpenXML文書形式をより綿密に映すjavaクラスのセットを生成することは当然の結果です。開発者は"Document"クラスや"Element"クラスよりもネイティブなJavaクラスを使って仕事をすることが可能になるのではないでしょうか。第二に、これらのアプローチのどちらでも、よりOffice特有のAPI、実際のXMLのストレージから離れ、Word(或いはExcelかPowerPoint)文書と連携する抽象化レイヤーを高め、代わりにこれらはパラグラフ、フォント、等々を有する文書であるという事実に集中するといったAPIに結合することができるかもしれません。基本的に、POIのようなライブラリは新しいOfficeのXML形式を反映した更新が可能ですし、またそのような更新をすべきであり、また、理想的には、新しいOpenXML形式と同様に、旧式のバイナリ構造ストレージ形式もサポートするように記述されるようになることが望ましいのです。三番目に、再度、サードパーティのライブラリを使って実現も可能だったのですが、JavaはZIPファイルのサポートを、わずかな修正で利用することができました。全ての厄介なAPIコールにも関らず、それでも、Javaプログラマにとって、どうやってOfficeプラットフォームを開こうかと考えることは、わくわくして元気付けられることなのです。Officeアプリケーション内でJavaを使うこととJavaアプリケーション内でOfficeを使うこと、そしてJavaからOfficeファイル形式を読み書きできること、これらの相互運用性の間にあって、OfficeプラットフォームはかつてないほどにJavaプログラミングコミュニティにとって、よりオープンになっています。本記事内に付随するサンプルコードは「ここ」(source)でダウンロード可能です。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。Inc.プライバシーBT。