Windows Mobileアプリ開発のHowTo Windows MobileのOSと各OS毎のエディションの特徴と、それらに伴う使用するSDKの違いを説明させて頂き、Hello Worldを表示するだけの簡単なアプリの作り方をお話させて頂きました。 コンピュータやセンサの小型化が進み、生活の中へと多くのシステムが導入され、人々を支えています。システムでは、センサから人々の行動に関するデータが取得され、コンピュータがそのデータを分析しています。本実習では、マイコン（M5Stack）とセンサ（加速度、ジャイロなど）を用いて、「センシング→行動認識」の流れを体験してもらいます。どのような行動をどのような手法（機械学習など）により認識するかについてアイデアを出すところから始めていただき、実装するまでをチャレンジしていただきます。オンライン参加の場合、マイコンとして、M5Stack Grayを郵

1. The document discusses the low-level API in Google App Engine for Java. It explains how the low-level API allows direct access to services like Datastore without higher-level frameworks. 2. Key concepts covered include the Datastore service, entities, keys, queries, transactions. It provides code examples for storing and retrieving entities using the low-level API. 3. Alternative high-level API

1) The document discusses Google App Engine's Java data store services including the low-level API which allows direct access to entities, keys, and queries. 2) It covers the DatastoreService which allows storing and retrieving entities and keys, managing transactions, and allocating ids. 3) The document also discusses how to perform queries on the data store using Query and PreparedQuery includin

The document discusses using Protocol Buffers over HTTP for making synchronous API calls from an App Engine application to a backend service. It describes how ApiProxy and Delegate classes are used to make calls via Protocol Buffers, with the Delegate making a sync call via an HTTP POST and returning the response bytes. This allows App Engine applications to use low-level APIs via Protocol Buffers

Servletへのアクセスをsecurity-constraintする事を想定し、Client側にAppEngine用のGoogle Account Authentication APIで認証する機能を追加した。

Aplicaciones de drones en el Perú, experiencias de la PUCP

MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜Takahiro Inoue

週報 2024/04/28 川はただ流れている 4/20（土） 初期値依存性 さいきん土曜日は寝てばかり。平日で何か消耗しているらしい。やったことと言えば庭いじりと読書くらい。 ベランダの大改造をした。 サンドイッチ 一年前に引っ越してからこんな配置だったのだけど、さいきん鉢を増やしたら洗濯担当大臣の妻氏…

トランザクションは意識しないのが一番 歴史は繰り返すんだろうか。トランザクションに関しては、こんな感じで話がループしている気がしている。 １）　トランザクション宣言を明示的にコードに記述（ホスト、ODBC/JDBC) ２）　生産性が低くなり新しいフレームワークが出現（EJB、Seasar2) ３）　新しいイノベーション誕生(cloud)、トランザクションを明示的に宣言、以下繰り返し トランザクションについては、2年前にも一度述べたことがある。実装が難しく不具合になりやすいので、生産性、品質を上げるには、開発者にトランザクションを意識させないことが一番である、といった感じのことを書いたつもりであった。 【EC開発体験記-トランザクション処理-】古くて新しい永遠のテーマ GAEにおいても方法論は異なるとは思うが、開発者にトランザクション処理を意識させたくないという私のスタンスは今でも変わってい

世界的な不況が続く中、競争力のある強い体質の企業になるためには、大幅なコスト削減が必要である。とりわけ、ITシステムへのコスト削減圧力は大きく、これに対応するためには、アーキテクチャー見直しや内製化などを含め、抜本的な改善していかなければならない。 Privateクラウドは、ITシステムのコスト削減の一手段として考えることができ、こういった課題に対応できる可能性をもつと考えられる。 今回は、Privateクラウドをテーマに思うところを述べてみたい。 Privateクラウドはクラウドではない？ 11/22の日経新聞にクラウドの特集があった。 そこには、クラウドの定義ははっきりしないが、「ネットの向こう側にあるソフトなどのIT資産を使う」という概念が基本となると書いてあった。また、誤解に関して以下のような感じで書かれてあった。 クラウドがブームになり、最近は関連する一部技術を入れ込んだだけのサ

TaskQueueを使った全文検索 非同期処理、並列処理はPDF生成に限った話ではない。これを応用して全文検索も考えることができる。例えば、下図のように、データを分割して複数のTaskで並行処理することで、検索にかかる時間を短縮することができる。これまで説明してきたように、Datastoreでは、前方一致検索はできるが全文検索はできない。もしこれで全文検索が可能になるのであれば嬉しいことである。Indexを使わずに全件検索するなんて無謀のように思えるかもしれない。でもこれこそがクラウドの醍醐味なのだ。 実装は下図のような感じになる。商品マスタ※検索では、商品名、基本説明、詳細説明を全件検索して、部分的にでもヒットしたら結果を返すようにした。（※ 今ECを作っているので、このBlogでは唐突に商品マスタなどの単語が現れる） 検索項目 商品名 基本説明 詳細説明 URLパラメータ fullte

Request was aborted after waiting too long が出る理由 前記事の実行結果を見てもらえばわかるとおり、"Request was aborted after waiting too long・・"というエラーのせいで、処理が中断されてリトライが頻発しているものが多くある。これがTaskQueueのスケーラビリティを阻害しているのは間違いない。これは、queryの実行時間が10秒を超えると出るようである。（PDF生成処理Taskでは10秒を超えるものがあるのでtaskの経過時間というよりqueryの実行時間によるのだと思う。たぶん） 別にquotaを上回るような処理を流したつもりはないのになぜ出るのか。 この現象については、ココでも質問されているが、Googleからの返事はまだない。 total queue execution rateの定義 Taskの

TaskQueueを使ってPDFを生成する 先の記事で疎結合、バージョニング、非同期がスケーラブルにするための要素だと述べた。私たちが提供するReflex iTextサービスでは、PDF生成サービス(図中 pdfservice)やデータサービスなどは、独立したサービスとして立てられる。独立したサービスは（カッコつけていえば）サービスコンポーネントとして考えることができる。サービスコンポーネントは、ServiceとReferenceの2つの口をもち、いわゆる芋ずる式に（疎）結合できる。そして、TaskQueueを利用することで、それらを非同期かつ並列に実行することができる。これを、ぶいてく流サービスコンポーネントアーキテクチャーと呼んでいる。 例えば、請求書アプリでは、 http://invoice.latest.reflexcontainer.appspot.com/invoice?inv

この記事書いているあいだにこんなニュースを見つけた。これはすごいや。 100万PV／日のmixiモバイルアプリをGoogle App Engineで実装した@gclue_akira氏に直撃インタビュー さて、本題 不可能と思い込んでいたことができることもある 何度かイタい目に遭うことで、またどうせ出来ないだろうと思い込んでしまうことを学習性無力感という。長期間にわたって鎖に繋がれたままの犬は、鎖を外してもしばらくは逃げないそうである。GAEはもともと情報が少ないのと、嵌りどころ満載なこともあって、学習性無力感に陥ることがしばしばある。だから、一人悶々とやるより、Blogに晒したり、GAE Nightなどの集まりに出向くなどして、情報共有に努めるのがよろしいかと思う。そこで重要なのは、ありのままの事実を晒すということ。現時点で正しい答えを識っているものは皆無に等しいのだから、誰かに正しい答え

なーんて、MVCを語れるほどの知識はないのだが、琴線に触れてしまったので、私なりに言いたいことを言うことにする。 本当は、こんな話より先に、先日参加したGAE Nightの話や、Winnyの金子さんが無罪になった話を書きたいのだけど、ココとか、ココとか、ココとか、ココとか、毎日毎日毎日毎日、MVCを語られると、何かいいたくて、もう我慢できなくなってしまった。（これはエンジニアの性なのか！？） 中島さんのBlogのなかで最も釣られてしまうキーワードは「えせ」。これを使うということは、自分の考えだけが正しくて、他は間違いであるということを暗にいっているようなもの。多くの人はそれに反応してしまうから、感情論になって、あまりよい結論は見い出せなくなってしまっているんじゃなかろうか。中島さんの言っていることは概ね理解できるし、RESTfulな設計などは私の考えと被る部分もあって、ほぼ同意できるのだが

TaskQueueによって、何がどう改善されるかについて、Reflex iTextを使って具体的に調べてみたので報告したい。特に、パフォーマンスについて、先日の記事（ココ）と比較しながら説明する。 やりたいことは単純で、大量のPDFをいかに短時間で生成するかである。前回のテストでは、クライアントから大量のリクエストを投げることでこれを実現しようとしたが、リトライ処理が多発してスケールしなかった。では、TaskQueueを使うとどうなるのだろうか。今回はそこにポイントを絞って調べてみた。 TaskQueue概要 まず、TaskQueueであるが、これはWebHook型のキューシステムで、Task自体を通常のServletとして書くことができる。Googleのサンプルを見ればわかるように、QueueFactory.getDefaultQueue().add()を使って、URLとRequestP

JDOが全然使えないことが明らかになるにつれ、最近ではLow level APIを使う方も多くなってきた。Low level APIは、シンプルで扱いやすく、パフォーマンスにも問題ないことがうけて支持されているのだろう。しかし、機能的には全然足りないので、自分たちで何とか解決しなければならない課題も多い。前方一致検索もその一つである。 Low level APIで前方一致かつPagingが難しい件 前方一致検索は、JDOではcontent.startsWithを使えばできるようであるが、Low level APIでも、検索項目をソートすることで一応できることはできる。しかしPagingについては、2Page目以降を特定する方法が必要ななため、できないと思っていた。 例えば、下図のように、”コーヒー”で前方一致検索した場合に、同じ商品名の”コーヒー010”が複数存在する可能性があるため、次ペ

クラウドPDFサービスのパフォーマンス測定について 先日公開したScalable PDFのパフォーマンステストと同様に、クラウドPDFサービス（GAEのReflex iTextサービス）についてもパフォーマンステストを行ったので公開したいと思う。 クラウドPDFサービスは、AmazonEC2のかわりにGAEを使っており、負荷分散機能はGAEまかせとなるが、Reflex iTextのサービスを使っている点はScalable PDFサービスと同じである。ただ、GAEの場合は実行時間など、いろいろな制約があり、リクエストが失敗する前提で設計しなければならないといった考慮が必要となる。今回のテストにおいては、エラー時に時間間隔を置いてリトライする仕組みを取り入れている。 結果としては、以下のように、GAEでも約8千ページを4～5分で処理できたということで、まずまずであったのだが、これがいっぱいいっ

Scaleするかどうか、それが問題だで主張したとおり、クラウドではスケールしなければ意味がない。以下は、GAEで大規模な処理をやって、特にトランザクション処理で悪戦苦闘した際のメモである。本日の発表資料＝＞ココにも含まれている。 大量データをINSERTできない件について 先日、Entityとトランザクション２において、Ownedな関連を使ったUpdateサンプルを紹介したわけだが、実はこれ、大量データをINSERTすると急激に遅くなるという問題を含んでいることがわかった。実際にテストしてみたところ、15000件を超えた時点でタイムアウトが頻発、15300件からはとうとう1件も登録できなくなってしまった。 com.google.apphosting.runtime.HardDeadlineExceededError: This request (c1fe232d20adabba) star

今回は親子関係をもったEntityのUpdateを中心に解説する。例によって、請求書アプリを題材にしている。ソースは＝＞ココで、使用しているReflexGaeライブラリは＝＞ココ 親子関係をもつEntityのUpdate 請求書アプリでは、請求書１枚がEntity１インスタンスとなるように設計されている。１つの請求書(Invoice)が複数の明細レコード(Order)をもち、さらには、Invoiceを親であるInvoiceBaseがListとして複数保持している。また、InvoiceBaseはInvoiceのレコード数、および、Orderのレコード数も保持している。このような関係をownedというが、このような構造をしているのは、EntityGroupとして定義しているからで、１トランザクションで実行する必要があるからである。 これらを更新するには、下図のように、まず、クライアントから受け

Entity設計について GAEではEntityというモデルを定義してJDOを使ってデータを永続化する。Entityはオブジェクトモデルであり画面など実際の業務アプリケーションや外部インターフェースなどを直感的に表現できるという点で優れている。しかし、階層型ということもあり、リレーショナルなモデルとはあまり馴染まない。もしかしたら、これまでRDB的な設計を中心にやってこられた方にとっては苦痛さえ感じるかもしれない。Entityをうまく設計するためには、ひとまずRDB的な頭をリセットしてオブジェクト的な発想をすることをおすすめする。一度慣れてしまうと誰でも簡単にサクサク作れるようになるだろう。逆に、RDBの呪縛から開放されOOに覚醒してしまうともう後には戻れないので注意が必要である。RDBって不要じゃん？とか、これからの時代はOOでKey/Valueだ！などと思うようになれば覚醒した証拠だ。

はじめに ｢人類が使うすべての情報を集め整理する｣ この壮大なミッションを掲げ設立されたGoogleは、そのミッションを遂行するべく、マシン・ネットワークなどのインフラ環境に莫大な金額を投資し、独自の技術を開発し続けています。Googleは検索エンジンだけにとどまらず、Gmail、Google Calendar、Google Maps、Google Analystics、Youtube、Google Apps、Google Earthなど、いまや全世界のユーザーが使用するサービスをリリースしており、その扱うデータ量、アクセス数は天文学的な数になることが予想されます。Googleはそれらのデータ量、アクセス数を高速にさばき、なおかつ耐障害性の高いスケーラブルな大規模分散システムを構築しています。 そんな中、2008年4月にGoogle App Engineがリリースされました。Googleが

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。