Skip to main content

Home/ Cloud Computing/ Group items tagged xml

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Toshiro Shimura

旧版Office for Mac向けのOpen XMLファイル・コンバータがようやくリリース：ITpro - 0 views

itpro.nikkeibp.co.jp/...309415

macosx office office2007 xml

shared by Toshiro Shimura on 29 Jun 08 - Cached
  • 旧版Office for Mac向けのOpen XMLファイル・コンバータがようやくリリース
  • 米Microsoftは米国時間2008年6月24日に，Open XML形式のOfficeドキュメントを初期バージョンの「Office for Mac」で扱えるようにするコンバータ「Open XML File Format Converter for Mac 1.0」をリリースした。同社のWebサイトからダウンロードできる。 　「Office 2008 for Mac」あるいは「Office 2007 for Windows」で作成したWord文書，Excelワークブック，PowerPointプレゼンテーションなどのファイルを，「Office 2004 for Mac」や「Office v. X for Mac」で開いて編集することが可能。 　米メディアの報道（CNET News.com）によると，コンバータは当初，Office 2007のリリースに近い日程で提供する予定だった。 　2007年5月にベータ版をリリースし，その時点では最終版を「Office 2008 for Macの発売から6～8週間後」としていたが（関連記事：MicrosoftがMacユーザー向けにOffice Open XMLファイルのコンバータを公開），延期が重なっていた。
Balaji Ramamoorthy

XML Technolgies Specifications - 0 views

www.xml-training-guide.com/xml-specification.html

shared by Balaji Ramamoorthy on 29 Mar 10 - Cached
  • Balaji Ramamoorthy on 29 Mar 10
     
    "XML specification means a syntax created by an existing international text-processing standard for use on the World Wide Web"
Toshiro Shimura

「シン vs.ファット」―― MS Officeの牙城に切り込むGoogle Apps : Googleウォッチ - Computerworld.jp - 0 views

www.computerworld.jp/...96349-2.html

google googleウォッチ office

shared by Toshiro Shimura on 02 Aug 08 - Cached
  • その好例がMicrosoft Officeだ。これほど広く普及しているにもかかわらず、ほとんどの人は「Word」「Excel」「PowerPoint」といったスタンドアロン・アプリケーションの単なる詰め合わせと考えている。しかし、Officeは、そうした単純なスイート製品にとどまらない。Officeは統合化された堅牢なAPI（VBA、OLEオートメーション、その他のアドイン・インタフェース）のおかげで、それ自体が商用ソフトウェア開発の有力なターゲットになっている。事実、Windows開発市場に参入する最も簡単な方法は、Microsoft Officeをターゲットにすることである。このスイートの機能を新しくしたり、強化したりするすぐれた製品を開発すれば、世界中の人々が売り場に殺到するだろう。
  • こうしたMicrosoftの相互補強戦略を崩壊させうる1つの力がWebである。ブラウザ・ベースのシン・クライアントとユビキタスな接続性の組み合わせは、Microsoftの支配力を奪いつつある。しかし同社は、愚鈍そうに見えて、実はこの脅威に敏感に反応しており、ここでも有効性が実証済みの囲い込みと拡張の戦略を推し進めている。いわばゆっくりとした足取りで、足早に逃げ回る獲物を追い詰めているわけだ。 　まずは囲い込みだ。Googleや新興勢力のZoho（画面3）などの成功を見たMicrosoftは、写真共有やブログ・ツールといったコンシューマー向けのWindows Liveサービスや、契約管理、Webサイト設計といった中小企業向けのシン・クライアント型Office Liveサービスなどを投入して、積極的に反撃している。
  • 次に拡張だ。例によって、Microsoftは伝統的なデスクトップOSやアプリケーション・プラットフォームに新しいサービスを組み込み、Office LiveとWindows Liveサービスを拡張している。前述したOffice Live Workspacesや、「Windows Live Mail」（画面4）、「Windows Live Writer」（画面5）などは、どれも成長著しいLiveアプリケーション市場をターゲットとしたものだ。いずれもWindows仕様であり、Webとデスクトップの統合を実現する独自のハイブリッド・アーキテクチャを採用している。 　さらにMicrosoftは、近い将来、アプリケーション仮想化を通してWord、Excel、PowerPointの全機能をシン・クライアントで提供し、ユビキタスな接続性を実現したいと考えており、高性能ファット・クライアントに残された他のアプリケーションについても、ストリーミング・サーバの大規模分散ネットワークでサポートしていく姿勢を見せている。 　こうしたアプローチは非常に魅力的だ。Microsoftの最新のアプリケーションが低コスト、あるいはほとんどコスト・ゼロでデスクトップに配信されるようになれば、わざわざAjax（Asynchronous JavaScript＋XML）アプリケーションを我慢して使う理由がなくなる。それはGoogleに困難な課題を突きつけるはずだ。
  • ...2 more annotations...
  • ただ、Microsoftの明確なミスと言えるものが1つある。それはVistaとOffice 2007に対するユーザーの冷めた反応だ。どちらの製品も当初約束していた機能を実現しておらず、デザインの不備や安定性の欠如がIT部門の仕事を増やしている。巨大なインストール・ベースのおかげで、Microsoftはなんとか面目を保っているにすぎないのだ。 　さらに戦況を悪化させたミスとして、海賊版対策のキャンペーン展開が挙げられる。そこでとった過剰な措置が将来のWindowsユーザーを追い散らしていることに同社は気づいていない。問題は「WGA（正規Windows推奨プログラム）」にある。MicrosoftはWGAでアクティベート・プロセスとアクティベート・ステータスの管理を複雑にしてしまい、結果的に新規ユーザー獲得の障害となってしまっている。実際に筆者が体験したケースでも、WGAが原因のエラーによって、システムに問題が生じて機能が低下したり、デスクトップが完全にロック・アウトしたりしたことがあった。
  • Windowsに関するもう1つの弱点は、仮想化に関するものだ。Microsoftは近い将来、同社のアプリケーション仮想化技術「SoftGrid」を活用して、主要なアプリケーションの全機能を月次または四半期ごとのサブスクリプション・モデルで提供する見込みだが、もしMicrosoftがこの方式を採用すれば、ホスティング型のアプリケーション配信が可能となり、Googleなどのシン・クライアント陣営を結果的に助けてしまうことになる。その場合、MicrosoftはGoogleよりも安価ですぐれたサービスで勝負しなければならなくなる。 　もしMicrosoftが攻撃的な価格でOffice製品群のストリーミング・バージョンを提供すれば、おそらくGoogleに勝つことができるだろう。だが、欲を出して既存の収入チャネルの保護に走るようであれば、ユーザーは一斉に“仮想Office”ソリューションではなく、Google Appsなどの代替製品の採用を積極的に検討し始めるだろう。 　また、Googleが現行のサービスを強化し、新たなISVコミュニティを構築するとともに、Microsoftが今後も製品のアクティベーションに厳格な制約を課し続け、今後投入するサブスクリプションの価格設定でミスを犯せば、Microsoftの市場支配力と伝統的なファット・クライアント型のコンピューティング・モデルが大きく揺らぐのはまちがいない。
DJHell .

OpenSocial in the Cloud - OpenSocial - 0 views

wiki.opensocial.org/index.php

OpenSocial Cloud Computing Open Source development IT articles Wiki

shared by DJHell . on 15 Apr 09 - Cached
  • Apps can grow especially fast on social networks, so before you launch your next social app, you should think about how to scale up quickly if your app takes off.
  • Unfortunately, scaling is a complex problem that's hard to solve quickly and expensive to implement.
  • If this app grows to serve millions of users and photos, shared hosting or even a dedicated server won't have the bandwidth or CPU cycles to handle all of the requests. We could invest in more servers and network infrastructure, shard the database, and load-balance requests, but that takes time, money, and expertise. If you'd rather work on the new features of the app, it's time to move into the cloud.
  • ...9 more annotations...
  • It's important to focus on the interactions between the app and your server when designing an application that will run in the cloud. If we standardize the communication protocol and data format, we can easily change the server side implementation without modifying the OpenSocial app.
  • You can configure the makeRequest method to digitally sign the requests your app makes to your server using OAuth's algorithm for parameter signing. This means that when your server receives a request, it can verify that the request came from your application hosted in a specific container. To implement this, the calls to makeRequest in the OpenSocial app spec XML specify that the request should be signed, and the code that handles requests on the server side verifies that a signature is included and valid
  • When our server receives a request, we can verify that it came from our application by checking that the digital signature was signed by a valid container and that the application ID is correct.
  • Since our server isn't storing any relationship data, the app will need to send us a list of user IDs so we can fetch the appropriate photos.
  • Although it's outside the scope of this article, we could provide a mechanism for our OpenSocial app to request a one-time-use token that it would include in the request to upload a photo.
  • Note that the post data is URL-encoded in the request so the post method uses urllib.unquote before splitting the comma-separated list of person IDs.
  • Since the server doesn't store any relationship data, the PhotosHandler class checks the post data of the request for a list of IDs from the container.
  • A common misconception when coding in the cloud is that storage space, CPU cycles, and bandwidth are unlimited. While the cloud hosting provider can, in theory, provide all the resources your app needs, hosting in the cloud ain't free so these resources are limited by your budget. Luckily, OpenSocial provides several mechanisms to cache images and data that will reduce the load on your server.
  • In addition to reducing traffic to our server, this technique has the added benefit of being fast—requesting data from the Persistence API is much faster than making the round trip to your server.
  • DJHell . on 15 Apr 09
     
    Some OpenSocial apps can be written entirely with client-side JavaScript and HTML, leveraging the container to serve the page and store application data. In this case, the app can scale effortlessly because the only request hitting your server is for the gadget specification which is typically cached by the container anyway. However, there are lots of reasons to consider using your own server: * Allows you to write code in the programing language of your choice. * Puts you in control of how much application data you can store. * Lets you combine data from users on multiple social networks. * Enables interaction with the OpenSocial REST API. Setting up an OpenSocial app that uses a third party server is fairly simple. There are a few gotchas and caveats, but the real issues come up when your app becomes successful - serving millions of users and sending thousands of requests per second. Apps can grow especially fast on social networks, so before you launch your next social app, you should think about how to scale up quickly if your app takes off. Unfortunately, scaling is a complex problem that's hard to solve quickly and expensive to implement. Luckily, there are several companies that provide cloud computing resources-places you can store data or run processes on virtual machines. These computing solutions manage huge infrastructures so you can focus on your applications and let the "cloud" handle all the requests and data at scale. This tutorial focuses on a simple photo-sharing app that uses a third-party server to host photos and associated metadata. If this app is going to host millions of images and support many requests per second, we won't be able to run it on a single dedicated host. We'll break the app down and analyze the interactions between the OpenSocial App and the back end server. Then we'll implement the app in the cloud, first using Google App Engine, then leveraging Amazon's S3 data storage service. Finally, we'll look at s
1 - 4 of 4
Showing 20▼ items per page