Task Queue API for Java
Python developers have been processing tasks offline using App Engine Task Queues since mid-June, but until now the feature was not available in the App Engine for Java SDK. The 1.2.5 SDK now includes support for creating Tasks and Queues in our Java runtime.
１． SONでは、要素名の"-"が"__"に変換されるため"type_str-ing"は、"type_str__ing"となります。
２． XMLの名前空間で用いる”：”は、JSONでは"___"に変換されるため、"xml:atom"は、"xml___atom"となります。
３． XMLの属性は、JSONでは"要素名____属性名"プロパティとなるため、"attr1"は、JSONでは"type_str__ing____attr1"プロパティとして表現されます。
４． XMLのテキストノードは、JSONでは、"_______text"プロパティに変換されます。
ReflexGae 0.9.6
* KeyUtils : 親キーのnameを指定できるようにした
* EntityConverter : Entityのプロパティ名を指定する時、"$"を"24"に、先頭の"_"を""に変換するよう修正
（訳：ぼくはXHTML構文が好きだ。なぜなら、そうやって学んだから。小文字で書くこと、引用符で括ること、brやimgにスラッシュを書くことに慣れているんだ。この書き方は、とても気持ちがいい。オバルチンを飲みながら、テレビでEvil Deadを見るような感じさ。でも、君はそうじゃないかもしれない。まるで叫んでるように見える大文字のタグや、スラッシュなしのimg, br要素、属性の省略表記が好きかもしれない。HTML 5だと、これらはぼくらの好きなように書けるんだ。“pave the cowpaths”っていう原則のおかげで、書く人のおまかせになるんだ。「お気に召すまま、お好きなように、好きなだけ、どうにでも」ってね。）
what-wgが「HTML5はモジュールに分割せずモノリシックな規格を作る」って決めてしまったからなぁ…
<video src="video.ogv" xmlns:cc=" http://creativecommons.org/ns#"
rel="cc:license" resource=" http://creativecommons.org/licenses/by/2.1/jp/"/>
XHTML 5でこういうことができたらいいのになあ。video要素とRDFaを両方使うとオレオレXHTMLになってしまう。せっかくスキーマを取り払ったんだから、モジュール化して他のモジュールも自由に取り込めるような仕組みがいいと思う。
validatorにかけると
Error: Attribute rel not allowed on XHTML element video at this point.
などのエラーを返される。@relや@resourceをvideo要素に書くとHTML 5準拠にはならないんだよね。ブラウザでの表示やRDFの抽出はできるだろうから実際あまり問題はなさそうだけど、そのXHTML文書が準拠する仕様はどこにも存在しないってのは、ブラウザの独自拡張時代を思い出させてあまり好きではない。HTML 6あたりで「やっぱりCSSみたくモジュール化しよう」ってことになり、Multimedia ModuleとかMetainformation Attribute Moduleとかが定義されて、制作者はいろいろなモジュールの中から好きなものを選んで組み合わせて使えるようになったりしないかなあ。
今後の方向は、お仕着せスキーマにちょっと手直しをして、従来は誂えスキーマでしか得られなかったような利点を
得ることだろう。名前空間も、もともとそのための試みで
あった（残念ながらうまく行っていない）。
XHTMLがモジュール化されたもの、
RELAX NGがスキーマのモジュール化を重視しているのも、
NVDLが名前空間による分割検証を提供しているのも、すべて
この方向を目指す試みである。あと10年もすれば、
お仕着せスキーマにちょっと手直しをするという方法が
有効かどうか結論が出るのだろう。
XHTML 2が打ち切りになったのは皆さんご存知だと思うのですが、以下の記事のなかで、XHTMLをHTMLのXMLシリアライゼーションとみなす、といった説明があります。
「W3CはXHTMLをHTMLのXMLシリアライゼーション（XML形式への変換）と見なしている。HTML
5仕様にXMLシリアライゼーションを含め，引き続きHTML WGで検討していく。」
http://itpro.nikkeibp.co.jp/article/NEWS/20090703/333143/
名前空間がXHTML1.xのままだとHTML5のタグを使えないものがあるので、完全なシリアライゼーションはできないと私は思います。
単純に、HTML5のままで、welformedなものをXHTML5と呼ぶと解釈したとしても、welformedかどうかを示すヘッダーなり何かがないと不都合です。（つまりXML宣言なんですけど）
その場合、名前空間はXHTML1.x以外の何かになると思われるのですが、最新のDraftにも新しい名前空間は見当たりません。
この話は以下にも書いているように、去年からずっと気になっているところなんですが、いまだにモヤモヤしています。
http://www.virtual-tech.net/blog/2008/08/html5-htmlxml.html
http://www.virtual-tech.net/blog/2008/09/html5-xml.html
また、弊社のReflex iTextのテンプレートの文法をHTML5にあわせるかどうか考え中なんですが、このテンプレートはXMLが前提なんでどうしたもんかと。
つまり、HTML5のタグを使いたいのだけど、welformedなHTML5であることを知ることができるのか、あるいは、HTMLとしてパースしないといけないのか、という点がはっきりしないのです。
このあたりで何かわかる方がいれば、ご意見を伺いたいのですが。
よろしくお願いします。
Y氏）
XML宣言が必要であることと、名前空間がこれまでのXHTMLと別になることの関連、またそれが「完全なシリアライゼーションにならない」にどう繋がるのかがよく分からないのですが、そこは置いといて。
HTML5で言うところの「XHTML」は、「well-formedなHTML5文書を、application/xhtml+xml または
application/xml で送出したもの」になります。
これが text/html で送出されている場合、それはXHTML5ではなく、HTML5になります。
「どう書いたか」ではなく「どう扱うのか」によって、HTMLとXHTMLという区別がつけられるわけです。
> また、弊社のReflex iTextのテンプレートの文法をHTML5にあわせるかどうか考え中なんですが、このテンプレートはXMLが前提なんでどうしたもんかと。
> つまり、HTML5のタグを使いたいのだけど、welformedなHTML5であることを知ることができるのか、あるいは、HTMLとしてパースしないといけ ないのか、という点がはっきりしないのです。
XMLのどの機能を利用しているかによって答えが変わるのですが、たとえば「
」のように空要素のXML的表現は、HTML構文でも利用できるように定義されています。
＝＝＝＝＝
私）
早速のご回答、ありがとうございます。
＞具体的に何が利用できないか、教えていただけますか？や などは、XHTML1.0や1.1では使えないと思います。
使うためには別の名前空間が必要ですよね。
> HTML5で言うところの「XHTML」は、「well-formedなHTML5文書を、application/xhtml+xml または
> application/xml で送出したもの」になります。
> これが text/html で送出されている場合、それはXHTML5ではなく、HTML5になります。
> 「どう書いたか」ではなく「どう扱うのか」によって、HTMLとXHTMLという区別がつけられるわけです。
なるほど。たとえ中身がXMLであっても、「どう扱うのか」ということを、content-typeで区別しましょう、という話ですね。わかります。
では、application/xml
で送り出したXHTML5とは具体的には何になるのでしょうか。welformedなHTML5なのか、XHTML1.1なのか、あるいは、両方が可能なのか。それが知りたいのです。
それにこだわっているのは、要は、XMLパーサしかもっていない当方の実装上の都合だけなんですが、HTML5互換のXMLが扱えるか、もし、application/xmlで送り出すことで、welformedなHTML5を縛れるとすれば、簡単に目的を果たせて嬉しいんです。
=======
S氏）
ちょうど仕様を読み返しているところでしたので、ご質問を受けて、XHTMLに関して言及しているところも軽く読み直してみました。
正しく理解できているかどうかはわかりませんが・・・(^^;
もし間違いがあったら、皆さんご指摘お願いします。
で、ご質問の意図は以下のようなものかと捉えたのですが、いかがでしょうか？
1. ファイル形式がXHTML5か、XHTML1.xかを見分ける手段がないように思えるが、その通りか？
2. 名前空間がXHTML1.xと同じく「http://www.w3.org/1999/xhtml」のままでは、HTML5のボキャブラリを扱えないのではないか？
こういった意図のご質問だと仮定して、僕の意見を述べさせて頂きますと、
1に関してはその通りだと思います。名前空間も同じですし、配信時のContent-Typeも特殊なものではありませんし。
2に関しては、ボキャブラリを扱えるかどうかは実行系に依存するのではないでしょうか。XHTML1.0しか扱えないブラウザは新要素を取り扱えないでしょうし、今後出てくる新しいブラウザはそれらを扱えるようになる、と。
なので、僕はXHTML5というのは、竹嵜さんのおっしゃった
> 単純に、HTML5のままで、welformedなものをXHTML5と呼ぶ
と言うことで良いのかな、と思っています。
（もちろん、文字エンコーディングの指定方法とか、細かい部分は違うにせよ）
ちなみに、仕様（http://www.w3.org/TR/html5/introduction.html#relationship-to-xhtml-1.x）では
"This specification is intended to replace XHTML 1.0 as the normative
definition of the XML serialization of the HTML vocabulary"
意訳:この仕様（HTML5）は、HTMLボキャブラリをXMLシリアライゼーションするための標準定義である、XHTML 1.0の置き換えとして意図されている
と述べられてます。
その上で、
> また、弊社のReflex iTextのテンプレートの文法をHTML5にあわせるかどうか考え中なんですが、このテンプレートはXMLが前提なんでどうしたもんかと。
ちょっと、この部分の問題意識がとらえきれていないので、役に立つ意見になっているかどうかはわかりませんが・・・
何かの参考になれば幸いです。
＝＝＝＝＝
私）
質問の意図をまとめていただきありがとうございます。まったくそのとおりです。
ご回答内容で、だいぶ見えてきたのですが、新たな疑問もうかんでいます。将来的に、XHTML5の名前空間って何になるのだろう？、と。
>> 単純に、HTML5のままで、welformedなものをXHTML5と呼ぶ
> と言うことで良いのかな、と思っています。
> 2. 名前空間がXHTML1.xと同じく「http://www.w3.org/1999/xhtml」のままでは、HTML5のボキャブラリを扱えないのではないか？
＞ボキャブラリを扱えるかどうかは実行系に依存するのではないでしょうか。
ということは、XHTML5は実質的に当面はXHTML1.xと同じ名前空間を使うということになりますね。XMLで新たなボキャブラリを追加する際に、名前空間を変えるべきかどうかは設計者によるといわれていますが、HTML5の要素が加わったXHTMLと、これまでのものとを区別できないのは、やはり不便な感があります。ああ、モヤモヤ。
http://www.ibm.com/developerworks/jp/xml/library/x-namcar/
「最終的には、XHTML 1.0のすべての範囲に1つの名前空間を使用する新たな仕様を発行することで、XHTMLワーキング・グループは軌道修正を行ないました。この教訓から多くを学ぶべきです。命名された物の間に本当に違いがある場合にのみ、XML名前空間を区別すべきでしょう。
残念ながら、物事に白黒をはっきりと付けられることは滅多にありません。新しいバージョンのボキャブラリが、新たな要素を追加するのはよくあることです。前のバージョンから持ち越された要素の意味は変更されていないかも知れないので、名前空間の変更は不適切であると思うかも知れません。しかし仮に、元の同じ名前空間を使用するとしたならば、新たなボキャブラリに追加された要素を元の名前空間内に設置するのも不適切であると思うでしょう。また、新たな要素のみに違う名前空間を使用するのは、とても賢明な選択とは言えません。結局、ボキャブラリで名前空間を改変するかどうかを判断する（自分自身の）判断力が必要です。」
com.google.apphosting.runtime.HardDeadlineExceededError: This request (c1fe232d20adabba) started at 2009/08/11 07:12:31.975 UTC and was still executing at 2009/08/11 07:13:05.802 UTC.
一度に100件登録した場合
＜所有関係の負荷＞
* 所有関係あり: 15秒くらいから。件数が増えるとだんだん遅くなる。
* 非所有: 3秒くらい。件数が増えても変わらない。
＜Index作成の負荷＞
* インデックスなしと、インデックスありの、どちらも100件登録で3秒くらい。
* インデックスありのテーブルで、100000件弱登録できた。
* 登録にかかる時間も100件約3秒と変わりなし。
* エラーがあれば時間間隔を置いてリトライする仕組み（時間間隔＝100msec*リトライ回数*10msec)
* １リクエストで生成できるページ数の限界は８０ページ（処理時間は３０秒でこれ以上はタイムアウト）
* リクエストを１００並列で実行するとエラー数が膨大となった（失敗）
* リクエストを１回目より減らして９５並列で実行すると４～５分かかった（成功だがリトライが多いもので８～１０回程度発生した）
* 一回目より二回目の方が明らかにエラーの数は減っている（GAE側でスケールしている？）
* JSONでは、要素名の"-"が"__"に変換されるため"type_str-ing"は、"type_str__ing"となります。
* また、XMLの属性は、JSONでは"要素名___属性名"プロパティとなり、"attr1"は、JSONでは"type_str__ing___attr1"プロパティとして表現されます。
List をJSON に変換するのは基本的に構造化が必要です。
以下のサンプルがわかりやすいかと思います。
http://reflex.sourceforge.jp/reflexitextsample_function4.html
EntityはStockInfo.javaで、StockList.javaで値を詰めています。
構造化をイメージしやすいのはstocklist.xmlですが、stocklist.jsonも同じentityから生成したものですので、同じ構造をしているといえます。
Reflexでは構造を意識しないといけない仕様になっていますので慣れるまでちょっと不便ですが、そういうものと思っていただくしかないでしょうね。
ただ、JSONの配列の便利さも損ないたくないので、以下のサンプルのような、配列の要素数
を与えてムリクリ変換できるような方法も用意しています。
http://reflex.sourceforge.jp/reflexjsonsample.html
Morph AppSpaceやGoogle App Engineなどのクラウドサービスにデプロイして使用する場合は、１インスタンスにつき１ライセンス料が発生します。1ライセンスはトランザクションの量に関係なく固定で月額￥3,000となります。warファイルの提供はありません。基本的に弊社にて導入支援を行います。サービスレベルはMorph AppSpaceやGoogle App Engineに依存します。また、利用料は別途お客様負担となります。
受託開発でGAEを利用することは規約的に可能でしょうか？
またデメリットとしてどのようなことが考えられるのでしょうか？
＞情報漏えいやシステムダウンは、どんなに注意を払っていてもおきるときはおきます。
私もそう思います。
ただ、実際には、Googleは免責されている（事故が起こっても損害金額などを払ってくれない）ので、発注者側がリスクを負うことになってしまいます。
少ない確率であっても、実際に情報漏えいやシステムダウンが起きる可能性があるため、発注者は導入の際に、事故が起きたときに誰がリスクを負うのかということを、会社に説明できなければなりません。（私も数年前までは発注者側にいたので、少なくとも会社はリスクを負わないということを、役員会などで説明する必要がありました。私に限らず皆そうなんだと思います）
その点、アウトソーサが管理しているシステムであれば、サービスレベルの質はどうであれ、彼ら自身が担保してくれている（個人情報漏洩であればほぼ無限責任）ので、発注者側はとても楽です。ただ、この形態は、ものすごく高くつくので、本当に会社の利益になっているかどうかは、経営者自身がよく考える必要があると思っています。Googleのシステムだからとか、彼らは優秀だからといった形容詞を使ってリスクをいかに少なく示したところで、担当者による説明はとても難しいと思いますので、結局は経営者判断になるんじゃないかと。
最近、私は逆の立場になり、GAEを提案しています。
お客様の意見としては、安さが会社の競争力になるという評価をしていただいている一方で、やはり、セキュリティの課題をクリアーできずに導入できないというところが多いようです。
また、抵抗を示している多くがIT部門なのもおもしろいと感じています。彼らは、個人的には導入にものすごく意欲的なんですけど、大企業だと会社ルールの壁を突破できないというか、政治的に動く必要があって、それがなかなかできないみたいです。事例もない現時点では無理もないことだとも思います。
結局のところ、大企業に浸透するまでには時間がかかりそうだから、中小企業か個人をターゲットに数多くのユーザを獲得する以外なさそうかな、と私は感じています。コンシューマをターゲットに小売的な商売を行って、請負でいくらというより、使ってもらってナンボといった感じの方が合うような気がしています。
１．InvoiceとInvoiceBaseのPersistentオブジェクトをそれぞれ取得する
２．invoicePersistentから、いったんdetachCopy
３．コピーしたものに子要素のorderを追記補完
４．invoiceからinvoiceSource(1品一葉)を取得する。
５．クライアントからのリクエストデータで更新があったものだけをinvoiceTargetにコピーする
６．Revisionを更新
７．InvoiceBaseにaddすることでInvoice以下子要素のorderなどもpersistentになる
Android向けの開発意向表明を行って数ヶ月になるが、もっとも良く投げかけられる質問は「iPhoneへのプラットフォームでは開発しないの？」というものだ。
少し前までは、ObjectiveCの開発スキルやリソースに目処がつけばやってもいいけど、学習コストが重いよねえ、などと答えていたが、最近は少し見方が変わってきた。
今の勢いでHTML5が進化・浸透してくれるのであれば、わざわざ移植コストをかけてiPhoneやWindows Mobile向けにネーティブ・アプリを開発するよりは、少なくともUIの部分をすべてHTML+Javascriptにまかせたアーキテクチャでのインタラクティブなアプリの開発というのも十分に可能性があるように思えてきたのだ。
この「HTML+Javascriptですべて出来るじゃん」という発想は、そもそもマイクロソフト時代のInternet Explorer 4.0やNetDocs（９０年代の終わりに開発していたマイクロソフト版Google Docs）のころから持ち合わせて来たもの。パソコン向けではWindowsの成功が故に日の目を見なかった発想が、数多くのプラットフォームが混在・競合しているスマートフォンの時代になって大きな意味を持ってきたというところが興味深い。
そもそも、「AppleがiPhone」を発表する、と聞いた時には、「ついに超高速・超小型のJavascriptエンジンの開発に成功したか」と過大な期待を抱いてしまった私にとって、ObjectiveCでNativeコードを書かなければならないiPhoneははっきり言って期待はずれの拍子抜け。明らかにGoogleの「ウェブアプリケーション中心」というの基本路線から外れており、せっかくiPhone向けのアプリを作った開発者がAppleに途中ではしごを外されて途方にくれる可能性は大きいと私は見ている。
現時点で、最新のハードウェア向けのアプリを作りたければAndroidがiPhoneよりも魅力的なプラットフォームなことは火を見るよりも明らかだし、どうしても「Googleに縛られたくない」のであれば、標準になりつつある、HTML5上でJavascriptを駆使した本気のインタラクティブなアプリを作るノウハウを蓄積しておく方がよほど魅力的に思える。もちろん、現時点でもっともすぐれたHTML5の実装を持つモバイル端末は iPhoneだし、ちゃんと作っておけば、Android端末でもPalm Preでも動くはずなので、投資効率は高い。
ということで結論から言ってしまえば、「移植性を無視して最新のハード向けにばりばりのネーティブコードを書きたかったらiPhone向けのアプリを Objective Cで作るか、Android用にJavaで作り、さまざまなデバイスへの移植性が重要ならHTML5+Javascriptでインタラクティブなアプリを作ってiPhone上のSafariでテストしておく」というのが現時点でのスマートフォン向けの開発投資の仕方としては、最も賢い選択肢だと考えている私である。
ちなみに、JavaとかFlashとかはどうなの、という質問が来そうなので答えておくと、「スマートフォン向けではなく、現状の端末向けのアプリの開発であればまだまだJava、BREW、Flash liteは健在。ただし、３〜５年後にそれらのプラットフォームがHTML5によって駆逐されてしまう可能性は大」というのが私の見方。もちろん、「ガラパゴス携帯」とか「Windows Mobile」という局所的な抵抗勢力はそれなりに残るだろうけど、WebKitがモバイル端末でさくさく動くことをAppleが証明してしまった今、世界の流れはHTML5に一気に向かっている。
entity = create(entity);
entity = retrieve(entity);
entity = update(entity);
entity = delete(entity);
Invoice invoice = (Invoice) getEntity(req, MODEL_PACKAGE);
jdoUtils.insert(invoice);
Invoice param = new Invoice();
(new RequestMapper()).setValue(req, param);
・・
jdoUtils.getEntriesByParam(param, pagesize, nextid);
Invoice invoice = (Invoice) getEntity(req, MODEL_PACKAGE);
JdoUtils jdoUtils = new JdoUtils();
jdoUtils.update(invoice);
fieldMapper.setValue(invoice,target);
1. ReflexServletをextendsしてRESTful機能をもたせる
2. RequestパラメータをEntity（Invoice）にセットする
3. パラメータInvoiceを与えてdatastoreを検索
4. 結果をJSONもしくはXMLにして返す
5. エラー発生時はエラー内容をJSONもしくはXMLにして返す
1. クライアントから受け取ったXML（JSON）をEntityオブジェクトに変換
2. すでに登録されている場合エラー
3. 登録されていなければinsert
4. エラー発生時はエラー内容をJSONもしくはXMLにして返す
(HTTP Status) : (現象)
* 204 : 内容なし
* 409 : java.io.IOException
* 404 : java.io.FileNotFoundException
子要素までaddしたときのキー(実際はBase64でエンコードされている)
j reflexworksr, InvoiceBase" InvoiceBase Invoice"ID2
j reflexworksr, InvoiceBase" InvoiceBase Invoice"ID1
Key childKey = keyUtils.getChildKey(Invoice.class, param.invoiceNo);
query.addFilter("id", Query.FilterOperator.GREATER_THAN , Long.parseLong(nextId));
FetchOptions fetchOptions = FetchOptions.Builder.withLimit(limit);
// 検索項目（Indexがあるもの） を指定してnewする
QueryUtils queryUtils = new QueryUtils(new String[]{"invoiceNo","companyName","job","issuedDate"});
// paramの検索項目がnullでなければaddFiler(FilterOperator.EQUAL)される
queryUtils.setParam(param, query);
Listresult = entityConverter.convert(Invoice.class, resultIterable,null,condition);
Marcel,
ASAP means that it is one of our top priorities. Rather than give you a specific date and disappoint you if we don't meet it, we're working hard to release it as soon as we feel it has reached a quality level people can be happy with it. We typically provide new SDK releases on the order of weeks, so you can do some extrapolation from there.
* GoogleSpreadSheetCsvParser
http://csv2xml.latest.reflex-itext.appspot.com/
* GoogleSpreadSheet > Shre > Get the link to share
1. Allow anyone with the link to view (no sign-in required) にチェック
2. Also allow them to edit にチェック
3. Save&Close
4. スプレッドシート共有URLをコピー
5. http://csv2xml.latest.reflex-itext.appspot.com/csvparserservlet のGETパラメータとして
row=record
url=スプレッドシート共有URL
を指定
Google Chrome OS の重要な要素は、スピードと使いやすさ、安全性です。
ユーザーが数秒でコンピューターを立ち上げてウェブにアクセスできるように、非常に高速で軽量の OS を設計中です。ユーザーインターフェイスはユーザーの妨げにならないよう最小限に抑えられ、ユーザーエクスペリエンスのほとんどはウェブ上で提供されます。
