Vistaで変更されたユーザー用フォルダの位置 前回紹介した通り、Windows Vistaには、ユーザーのドキュメントを格納する場所として「\Users\＜ユーザー名＞」フォルダが用意されている。Windows XPでは「\Documents and Settings\＜ユーザー名＞」というフォルダを利用していたため、フォルダの位置は大きく変更されたことになる。その違いは下表に示した通りだ。 Windows XPでは、OSをインストールしたドライブの直下に「Documents and Settings」があり、その下にユーザー名の付いたフォルダを用意していた。ユーザー名の付いたフォルダの下には「マイドキュメント」や「お気に入り」「デスクトップ」などのフォルダが設けられ、「マイドキュメント」の下に「マイミュージック」や「マイピクチャ」を配置するといった階層構造になっていた。 これに対し、V

DDS／DATテープストレージ、その知られざるベストセラーの秘密：バックアップストレージ図鑑（1/3 ページ） 登場から17年たったDDS／DATテープストレージ。全世界で1700万台以上出荷され、テープストレージ市場の50％を占めるベストセラーだ。コストとパフォーマンスの上で、中小企業に最適なバックアップ装置の秘密を探ろう。 世の中に多くのストレージデバイスがある中で、コストとパフォーマンスの最適なバランスを考えると、磁気テープストレージの右に出るものはない。フラッシュメモリやHDDは、即時のデータアクセスのしやすさでは群を抜いているものの、メガバイト当たりのストレージコストは比較的高い。その点で、フラッシュメモリやHDDはバックアップストレージよりオンラインで一次ストレージに適している。 一方で、CDやDVDドライブのような光記憶媒体は、適度な容量でかつデータアクセスにも優れる。しかし

LTO製品は、「さまざまな技術の長所を集約したオープンフォーマット技術」であると前回説明した。DLT製品などほかの技術で経験した不具合を学び、LTO製品ではそれを克服している。それだけでなく故障モード影響解析（FMEA）などの解析方法を使い、発生の可能性があるフェイルモードを予測し、事前に防止する設計を行っている。 ここでは、HP製のLTOフルハイトドライブを実例として、LTOメカニズムを見ていこう。 HP Loadメカニズム HPでは、特許を取得している独自のリーダースレッディング方式を採用し、信頼度の高いLTO製品を開発している。下図にあるのが、HPドライブで使われているリーダー連結部となる。リーダーブロックと呼ばれる硬いプラスチック製の部品が、鋼製のカートリッジリーダーピンと確実にスナップするようになっている。テープカートリッジがドライブに挿入された後、このカプラーメカニズムがリーダ

現在最も成長しているテープストレージ技術といえば、LTOテクノロジーだ。オープンスタンダード技術として、健全な競争を行っている結果、ユーザーが安心した投資を行えると判断できる製品となっているからだ。 テープストレージの市場シェアという意味では、前回紹介したDDS/DATテクノロジーは50％弱と右に出るものはいない。だが、いま最も成長しているテープストレージ製品といえば、LTO（Linear Tape-Open）テクノロジーが挙げられる。 2000年にリリースされた初代製品以来、LTOテクノロジーは大きくマーケットシェアを拡大させてきた。ユーザーに幅広く受け入れられた理由はさまざまだが、最大の理由としては、明確なロードマップに裏付けされたオープンスタンダード技術であることだろう。この結果、各参加メーカーの健全な競争が価格や製品仕様に反映され、ユーザーが安心して長期的な投資を行うことができたと

Webアプリの性能やメモリ関連の問題を、コーディング時に回避：Java Review（1/2 ページ） アプリケーションの“作り”が悪いと、Webシステムの運用時に性能やメモリ関連の問題が発生する原因となる。今回は、Javaアプリケーション作成時に留意しておくべき基本的なポイントについて紹介する。 性能やメモリ関連で問題が発生した場合に、原因を判別するのは非常に骨が折れる作業だ。これらの問題を回避するためにも、基本的なことであるが、Javaアプリケーション開発時に次の2点は必ず配慮しておこう。 適切なAPIを使用しているか？ 不要なオブジェクトを生成していないか？ また、アプリケーションの処理がシステムに対して間接的に影響を及ぼすこともある。今回はこういった事例についても紹介する。 適切なAPIを使用しているか？ コーディング上で性能問題の要因を発生させないようにするには、適切なAPIを使

Webアプリの性能やメモリ関連の問題を、コーディング時に回避：Java Review（2/2 ページ） 不要なオブジェクトを生成していないか？ 次に、Javaアプリケーション内で不要なオブジェクトを生成していないかを見直そう。例えば、ログの出力時に、ログの出力レベルを考慮しないでログ出力データのオブジェクトを大量に生成してしまうと、Copy GCが多発し、パフォーマンスの低下に繋がる。オブジェクト生成については、不要なオブジェクトはできるかぎり生成しないことを念頭においてコーディングしよう。 また、オブジェクトの生成を抑えるためには、キャッシュしておいて再利用するという方法もある。ただし、オブジェクトを再利用する場合は、過度なキャッシュをしないよう留意してほしい。これは、キャッシュが多過ぎるとオブジェクトの生存期間が長くなってしまい、メモリに影響が出てしまうからだ。Java VMの高速化に