Skip to main content

Home/ Cloud Computing/ Group items tagged Wiki

Rss Feed Group items tagged

Toshiro Shimura

Google Gearsの課題と可能性--アプリ開発の現場から:スペシャルレポート - CNET Japan - 0 views

  • Synkiはユーザーごとに細かく権限を設定でき、複数のWikiサイトを開設できる点が特徴だ。ワークスペースと呼ばれる作業スペースごとに権限を設定できる。もちろんオフラインでも使用でき、オンラインになった時点で最新の情報に同期される。  「Synkiは『Sync(同期)するWiki』という意味。Wikiは次世代CMSとして着目している。非常に生産性の高いツールで、仕事で利用するのに向いている。特に他人と共同作業をする場合に有効だ。社内ブログは、将来Wikiに置き換わっていくかもしれない。いずれはSynkiとGmailだけあれば仕事が完結するような環境を提供したい」  Wiki記法を知らない人でも利用しやすいように、リンクタグなどを自動的に埋め込むボタンを用意する。今後はタグを不要にするWYSIWYGに対応するほか、スプレッドシートの共有などができるようにする。また、企業が使いやすいテンプレートも用意する。
  • ほかの企業システムと連携しやすいよう、APIの公開も考えている。「Synkiはプラットフォームに過ぎないと考えている。ユーザーの権限設定ができるので社外の人とも利用できるし、社内のデータを外部に出さないようにもできる。組織がフラットな構造で、社外とのコミュニケーションが多い司法書士や弁護士、PR業などが最も向いているだろう。ただ、それぞれの企業が独自の使い方を追加できるようにしていきたい」
  • ここまで苦労してでもGoogle Gearsを採用した、その最大の魅力は何だったのか。朴氏は将来的に標準になるという可能性に賭けたと話す。また、開発したサービスをオープンソースとして公開することも視野に入れていたことから、Google Gearsがオープンソースであることは大きな後押しになったようだ。  「きちんとした製品を作り、ユーザーの支持を得てからオープンソース化しようと考えていた。Googleが専門部隊を持ち、オフライン機能に特化したモジュールを開発するのであればそちらを採用したほうがいいと思った」(朴氏)  自社でモジュールを開発したほうが楽だったのではないか、という意地悪な質問をしてみた。すると朴氏は、「自社でやったらもっと時間がかかったかもしれない」とした上で、「でもコードのリファレンスがなくて苦労したので、最終的には同じくらいかな」と笑った。
Toshiro Shimura

【レビュー】Wiki以上! 『Google Sites』は情報統合プラットフォームだ (1) WikiがベースのGoogle Sites | ネット | ... - 0 views

  • 機能としてはやはりWikiがベースになっている。HTMLを使わず、サイトを編集し、新しいページを追加することができる。WYSIWYG(見たまま編集できる)のHTMLエディタを搭載しているので、HTMLを編集しているという意識は必要ない。Wikiというと複数人でのコラボレーション、というイメージがあるが、もちろんひとりで使ってもまったく問題ない。最近はASPのブログサービスなどを活用していて、自分のサイトを持っていない(または持つ必要がない)という人は多い。Google Sitesは、そうした人がちょっとした特別サイトを作りたいといった時にも便利に利用できるだろう。
Rich Hintz

FrontPage - Cassandra Wiki - 1 views

  •  
    Cassandra Wiki
Toshiro Shimura

【レビュー】Wiki以上! 『Google Sites』は情報統合プラットフォームだ (2) Google Sitesを使ってみる | ネット | マイコ... - 0 views

  • ページの種類を選択可能新しいページを作るときに気付かれたと思うが、ページの種類を5つの中から選択することができる。「Web page」はトップページのような通常のページ、ウィジェットを貼り付けるための「Dashboard」、ファイル管理する「File Cabinet」、バグ管理やToDo登録などを行なう「List」、さらにアナウンス用の「Announcements」がある。それぞれに特徴があるので、必要に応じて使い分けてみてほしい。
Toshiro Shimura

【レビュー】Wiki以上! 『Google Sites』は情報統合プラットフォームだ (3) Google Sitesならではの魅力はココ! | ネット ... - 0 views

  • ほかにもGoogleカレンダーを取り込んだり、Picasaの写真をスライドショーで表示、YouTube/Googleビデオの挿入といったこともできてしまう。iGoogleで提供されているガジェットも取り込み可能だ。Googleが提供する各種WebサービスをGoogle Sites内で簡単に利用できるというわけである。
  • Google Sitesは単なるWebサイト構築ツールじゃない! Google Sitesの魅力は、Googleの各サービスを使いこなしているとさらに強く感じることができる。スプレッドシートやカレンダーをリンクしておき、それを更新すればGoogle Sites側も自動更新されるといった具合だ。さらに言えば、既存のGoogleサービスのWeb APIを使ったライブラリやソフトウェア、同期ツールなどの類が相当数存在する。それらを活用すればGoogle Sitesは単なるWebサイト構築ツールではなく、コラボレーションを促進する情報統合プラットフォームにさえなりえるのだ。
DJHell .

OpenSocial in the Cloud - OpenSocial - 0 views

  • 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.
  •  
    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 - 10 of 10
Showing 20 items per page