親モデルが削除された時、子モデルにセットされている関連（ModelRef< 親モデル>）は消えない様です。

RDBMSのいわゆる参照整合性制約での ON DELETE NO ACTION に相当する仕様みたい。
ON DELETE CASCADEとか、ON DELETE SET NULLとか、SET DEFAULT とかは出来ないようです。
制約が必要ならアプリケーション側での実装することになります。
残念。
あんまりメンドクサイようならがんばってissueを投げてみよう。

でも、RDBMS側の制約に頼ったDAOのコードを書いて仕様書やDBのスキーマを見ないとビジネスルールが判んなくなる、といった事が起こりえないというメリットはありますね。

兎に角スキーマレスは素敵。一貫性の維持とかが自己責任になり大変だったとしても。

で、親モデルを削除した後、子モデルのModelRefでgetModel()しようとすると、
org.slim3.datastore.EntityNotFoundRuntimeException
がスローされます。

こうなった時とかには、ModelRefを削除します。

削除する方法ですが、ドキュメントに明示していませんでした。
試しに ModelRefでsetModel(null) した後にDatastoreにput したら、削除された様に見えます。

その後、Slim3のJavaDocでorg.slim3.datastore.ModelRefのんを見た所、clear()メソッドありました。

ModelRefでclear() してputしても削除された様に見えます。

どっちの作法が正しいんでしょうね。
取りあえず後者を使うことにします。

著者は、朝日新聞の社会部記者、AERA編集長を務めた後、ネットニュースメディア「J-CASTニュースの蜷川真夫氏の本です。

要するに、金も取材力も無いけどネット上の膨大なニュースをピックアップして記事にしたら数年で1000万PVを超える事が出来たよ、それにはすこしけコツがあったよ、と言う内容です。

コピペメディアと揶揄される事もあるJ-CASTニュースの立ち上げから今に至る経験やノウハウがつまっており、なかなか興味深い内容でした。

ウェブはバカと暇人のもの

梅田望夫氏の「ウェブ進化論」は「頭の良い人の話」であるが、この本は中川淳一郎氏がアメーバニュースの運営を通じて経験した、「普通の人」と「バカ」にまつわる話です。

要するに、ウェブは居酒屋の雑談みたいなものだから俗っぽい話が多いよ、日本人はリアルでは兎も角ネットでは村社会バリバリ攻撃的、排他的になりがちだよ、という内容です。

内容は少し辛辣ですが、サイト運営の経験がある人なら、氏の言う事は実体験として判るでしょう。

この2つの本に共通している事は、普通の人には俗っぽい記事がウケると言う実態について書かれている事と、Yahoo!カテゴリの影響力の凄さについて書かれている事です。

日本におけるポータルサイトとしてのYahoo！の地位は揺ぎ無いものがあり、特にニュースサイトをやるなら無視出来ないぞ、と。

これからのソーシャルメディアがどうとかソーシャルグラフがどうとか言う以前に、考えさせられる現実です。

保守できなくなり、塩漬けにしたままのオープンシステム—。いま“オープンレガシー”が情報システム部門を苦しめている。
…
　1990年代から2000年代の初め、オープンシステムは「早く安く作れる」「新しい技術が使える」「1社のベンダーに縛られない」といった輝きを放ち、“自由”の象徴だった。このメリットを追って、多くの企業がメインフレームからオープンシステムへと開発の軸足を移した。
　だが今、その輝きは色あせ、輝きの裏に隠れていたデメリットが情報システム部門に重くのしかかっている。「早く安く作れる」というメリットは「作りすぎて保守できない」というデメリットに裏返された。「新しい技術が使える」というメリットの裏には「選んだ製品が廃れる」というデメリットが、「1社のベンダーに縛られない」の裏には「組み合わせの制約で更改しにくい」というデメリットが存在した。
…
　メリットを追い続けてとにかく作り続けた結果、振り返ればオープンシステムはレガシーとなって企業を苦しめている。しかし、開発コストとスピードを考えるとメインフレーム時代には戻るのは現実的ではない。

今そこにある「オープンレガシー」 – 記者の眼：ITpro

同記事は、「オープンレガシーを救う七つの鍵」をこの様に挙げています。

1. 運用を立て直す (ISMS、ITILを導入する等)

2. 保守切れソフトを更改する

3. 標準化で範囲を狭める

4. 技術マップを持つ

5. 陳腐化させない努力を続ける

6. 仮想化は一時避難所と考える

7. 所有か利用か、スタンスを明確にする

この中で出来ていないとすれば最優先すべきは、「3. 標準化で範囲を狭める」でしょう。

このご時勢ですしIT投資は抑制気味でしょうから、オープンレガシーがどんどん増えていく状態ではないかもしれませんが、ハードウェアやミドルウェアのリース契約更新、耐用年数、保守期限など、ハードウェアやOSやミドルウェアのマイグレーションは定期的にやってくるでしょう。

これ以上増やさない為にも、情報システム、特にハードウェア、OS、ミドルウェア、インターコネクト（ネットワーク）などのインフラストラクチャ部分の「社内標準化」と、情報システム部門による稟議フローへの積極的介入が必要です。

何より、最適化するチャンスでもあります。
モノによっては、SaaSに移行した方がええやん、と言うモノも結構あるでしょう。
特にコモディティ化が顕著なモノは沢山あるでしょう。
例えばDNS、メールサーバ、勤怠管理、グループウェア、等など。

運用系の人は、世の中の技術トレンドをよくウォッチして、積極的に経営層に具申していかなければいけません。
そのためには、まずなんでもオンプレミスでやりたとか言うこだわりは捨てましょう。
あと、レイヤの違う人と話をするスキル、プレゼンテーションをするスキルを身につけないといけません。
最初はなかなか判って貰えないでしょうけど、場数も必要でしょう。
相手に理解してもらうには、辛抱強く訴え続ける事も必要かもしれません。頑張りましょう。

それにしても、どうも「システム運用」系の人々は地位が低い事が多い。

アプリケーションを作る開発系の人々は元より、運用系にも開発系にもどちらにも生息するインフラストラクチャを設計・構築する構築系の人々よりも、一段下の扱いを受ける事が多いです。

原因は色々あるんだけど、運用系は「売り」に直結して無い事で経営層から軽視され、「技術スキルと単価」から相対的に開発系と構築系から下に見られがちです。（あくまで一般論です）

あと、職責上どうしても「安全側」に偏った考え・発言が多いのも運用系の特徴です。それが仕事の一部だから当たり前だけど、嫌われ者役にならざるを得なかったりします。

運用上見つかった不具合を報告するのも仕事なので (ITIL的に言うと RFC、Request For Changeですね)、これまた喜ばれる事は少ないです。開発者の方々、フィードバックをくれる運用系の人にはちゃんと感謝しましょう。

不具合の対処といえば、原因究明できれば治ったも同然なんですが、それが一番難しいんです。
オープン系のシステム、特にオープンソースを多用していると、何が起こっているかを正しく知る事はあまり重要でないというか、難しいんです。それよか怪しい所を交換してみようとか、そういう運用になる事が多いです。Googleのハードウェアに対する考え方がそうですね。

で、原因がアプリケーションだと判明した時、それを直そうと思っても最新のソースコードどこにあるねんとか、ビルド環境ってどうやったけとか、その言語はもう使える人いませんよとか、ドキュメントないですけど直したとして他との影響が無いかどうやってテストすりゃええねんとか、ステージング環境なにそれとか、なんかガッカリな状態だったりする訳ですよ。

結論として「運用対処の方が安くつくよね」と言う事が結構あります。
それはそれで良いんですけど、運用系の人はちょっとだけ傷つきます。
私もその台詞良く言いますごめんなさい。

運用系側の視点に立つと、開発・構築系の方々の担当するフェーズ（企画、設計、開発、実装、試験）での短納期でやっつけちゃったね的な事とか、コスト制約とか、大人の事情とかでの、ムリのしわ寄せ出てるでしょう的なシステムが大半な訳です。ぶっちゃけた話。

何色々ケチってクライアントや上の言いなりになってテキトーにつくってやがんだこのやろうドキュメント出せやとか、本音では思ったりする事もしばしばなんですよ。

それでも運用系の方々の大半は、開発系の方々を技術的にリスペクトしているんです。自分には出来ない事が出来るから。開発系が良いモノを作ってくれた時なんか、我が事の様に喜ぶもんです。

どうです。愛おしい気持ちにさえなってきませんか。

逆に開発系の方々は運用系の仕事が出来るか？と言えば、オペレーションはある程度は出来ちゃうんです。良くも悪くもドキュメンテーションが運用管理の基本だから。

開発系の方々は、なんとか頑張って研修制度とかを設けて3ヶ月位やってみたらえーんですよ。マジで。運用フェーズの経験が無い開発者の方は特に。

なぜなら、運用フェーズがイメージ出来ない人には保守性の高い成果物なんて作れないからです。さもなくば座禅組んでTCOについて72時間位考えて見てください。

電波オークションなどの政策検討が、なぜ「放送と通信の融合」を促すのか。これまで通信キャリアやテレビ局などの放送事業は、国家のもつ有限の資源である電波を利用する免許を与えられ、その見返りに電波利用料を国庫に納めてきた。だが、携帯電話向けサービスを実施する通信キャリアは、一人一台以上の端末保有状況に加え、銀行決済やカード決済、さらにコンテンツ配信や通販といったリアルビジネスへ結合していき、いまや国民の基本的な生活に欠かせないインフラへと成長している。

　片や、テレビ局は慢性的な視聴者離れに悩み、スポンサー収入が落ち込むなど収益性が低下、メディア単体としての魅力を失いつつあるばかりか、新聞社や出版社など、デジタル社会への対応が遅れて急速に経営基盤が悪化している事業もグループ内に取り込んでいる。

　つまり、どちらも同じ電波を使って事業を行なっているものの、その収益性には大きな開きがあり、現在でも通信事業者は放送事業者に比べて数倍の電波使用料を支払っている。結果として国民は、携帯キャリアを通じて事実上の電波税を納めているに等しい状況ではあるが、通信も放送も電波の上で主たるビジネスを行ない、そこでビジネス上の接点が増えることになる以上、着実にこの垣根を取り払い、距離を縮めざるをえない。
右往左往する「通信と放送の融合」／山本一郎（イレギュラーズアンドパートナーズ代表取締役））(Voice) – Yahoo!ニュース

かなり回りくどい表現をされていますが、要するに「携帯キャリアは儲かってるけどテレビ放送事業者は儲かってない。電波オークションなどで稼げる分野（業界、企業）にリソース（電波）をうまく配分しましょう。」という所でしょうか。

今まで、電波の無駄遣いの事は知ってるつもりだったけど、電波利用料ってのがあるんですね。
通信事業者は放送事業者に比べて数倍支払っているとの事です。
たしかに事実上の電波税ですね。
今度調べてみよう。

Twitterでは大量のサーバを運用しており、それらのサーバに対してのアップデートは素早く行わなければならい。しかしGitサーバに対するアクセスによってデプロイを行うことには非常に問題があった。

そこでBitTorrentを使ってデプロイする「Murder」というツールを開発をした。Murderは、BitTorrentを包含して内部ネットワーク用にオプティマイズしたもの。これまで約900秒かかっていたデプロイの時間が約12秒になり、75倍も速くなった。

なぜBitTorrentをベースに選んだかといえば、多くのライブラリがあることが理由の1つだ。
…
Murderはオープンソースで作られており、基本的にはPythonのスクリプトとCapistranoスクリプトでできている。
TwitterがBitTorrentで高速にデプロイしている仕組みについて － Publickey

このLarry Gadea氏と言う人も頭が柔らかい人ですね。

優れた技術力を持ちながら、かつ既に有るものは最大限利用すると言うマインドのある開発者には、なかなかお目にかかれません。

加えて、比較的ネガティブなイメージが強いBitTorrentを利用しよう言う自由な発想と、それを許容する企業風土が無いと、こういうシステムは具現化しないんでしょうね。

請負開発がメインの日本のSIerとかでは絶対に生まれないモノだと思いました。

逆に、こういった大規模システム運用技術は、ネットワークゲームとかを手がける企業こそ得意分野なんじゃ無いでしょうかね。

うーん。ネットワークゲーム屋と大規模WEBアプリーケーション屋。なんか似ているぞ。

ゼロエミッション・エレクトリック　コミューター「EC-03（イーシー ゼロ スリー）」（原付1種）新発売について – ヤマハ発動機株式会社

10月1日に全国発売、50ccの原付き1種に相当するそうです。
25万2000円と言う値段はは、フツーのガソリンエンジンの原付きとそんなに変わらないですね。

家庭用の100V電源で充電できるし、1回の充電に必要な電気代は約18円なのが素敵ですが、走行距離は43kmしかない。それも30km/hの定地走行。

実際には半分位と見ておいた方がいいでしょうね。
うーん、会社までたどり着けんぞ。残念。

往復する為には、航続距離を100km以上にしてもらわんと。
そうなると重くなるからナァ。

バッテリーは座席シート下に配置しているらしいから、メットインでも無いんでしょう。
原チャリでスーパーにお買い物するにはメットインが欲しい訳ですし。
そもそも原チャリて燃費がすこぶる良いので、低燃費のメリットもあまり感じられないし。

環境意識が高く、最寄の駅まで原チャリで通勤しているオトーサン向けですね。

ついに！リリースされましたよ！

人物にあわせて微妙に声色変えておられる様で若干腹立ちます。
いや良い意味で。

今回もクオリティの高い作品をありがとう御座います。

「一般社団法人ブロードバンド推進協議会が23日に開催したシンポジウム「三木谷浩史・孫正義が語る『国民の、ITによる、日本復活』～ブロードバンドアクセス100％がもたらす国民生活の変貌とポテンシャル～」では、同協議会の代表理事である孫正義氏の講演のほか、楽天代表取締役会長兼社長の三木谷浩史氏による講演や、両者によるパネルディスカッションも行われた。

　約2時間に渡るシンポジウムの模様はUSTREAMでネット中継されたほか、Twitterには専用ハッシュタグが設けられた。会場には一般聴講客や関係者向けに1280席を用意、最終的にほぼ満席になったという。

　さらに今回のシンポジウムは、民主党・自由民主党・みんなの党に所属する衆議院・参議院議員ら41名が来賓として名前を連ねており、政治的アピールの濃さが際だっていた。」

【三木谷浩史・孫正義が語る「国民の、ITによる、日本復活」】 NGN＝ネクスト・ガラパゴス・ネットワーク、三木谷浩史氏が批判 -INTERNET Watch

要旨まとめ

• ネットビジネスは中小企業や地方経済にとって有望、内需拡大に貢献する
• 医薬品のネット通販規制など、役人の“ガラパゴス規制”を批判
• 「Next Generation Networkではなく、ネクスト・ガラパゴス・ネットワーク」
• NGNは利用者を囲い込むための独自仕様によって国際性が低く、事業者間のサービス競争も生まれない※
• 日本独特の規制を整理・撤廃し、世界標準へ改めるべき
• 総務省の「光の道構想」を推進し、国内全世帯へ光ファイバー網を整備することによって生まれるパラダイムシフトの意義は大きい

※一応補足：NGN自体はITU-T勧告、問題としているのはNTTが進める日本版NGN

ISDNで大コケし、ソフトバンクの外圧でしぶしぶADSLを始めたNTTが、がんばって進めているのがNGN。

一般人にとっては「光ネクスト」な訳だけど、何ソレBフレッツとどう違うのと言われると今のところ特に無いから説明が正直キツイ。

法人の方も個人的にはたいした需要は無いと思っています。
FAXが高画質で安く送られる様になるからって、回線を敷設しなおしてFAX複合機買いなおしますかね。

ISPとNTTが地味に対立しているとか、IPv6のマルチプレフィックス問題がどうのこうのとかは、普通の人にとっては知ったこっちゃ無いですけど、政治家の人には一応知っておいて頂きたい。

そういう意味で、今回のシンポジウムは、「民主党・自由民主党・みんなの党に所属する衆議院・参議院議員ら41名が来賓」との事ですので、有意義だったんだろうな、と思います。
ちゃんと参加＆寝ないで聞いていれば。

関連記事
「光の道」関連の主な発言まとめ

svc オプション サービス名

参考サイト
daemontools howto

まず、Entity (エンティティ) と聞くと、Codd博士のERモデルや、IDEF1Xとかの拡張ERモデルを思い浮かべてしまいます。
いわゆるリレーショナル・データモデリングにおける「実態」を表すEntityは、RDB上のスキーマの設計の元になるもの、と刷り込まれているんです。

ですが、app engine の話をするとき、Entityという言葉は文字通り実体のほう、RDBにストアされた個々のインスタンス、つまり行、タプルをイメージするべきの様です。

私だけでしょうか。微妙に混乱します。

このへんの微妙な言葉のニュアンスから、Entity Group と リレーションを混同してしまうという弊害があるんじゃないでしょうか。
実は私もそうでしたので。

Entity Group は Entity (＝オブジェクト、≒タプル) を保存するときに決まる(決める)もの。
リレーションはデータクラスで定義し、Entityに保存する時に決めるもの。

エンティティグループはリレーションではない

祖先とか親とか子とかいう単語が出てくるので誤解しがちだけど、エンティティグループは、１：多のようなリレーションを表現するものではない。

トランザクションによりACID特性を保障したいときに設定するもの。

リレーションはkeyをコレクションで持ったり、Slim3のModelRefなどを使って表現する。
app engineのエンティティグループ – 理系のためのTIPS集

あとkindという言葉も、これからGAEを学ぼうとする人には鬼門になるかもしれません。

Google App Engineの本とか記事とかを読んでいると良く出てくるんですけど、日本語のGoogle Codeのドキュメントを見ても、kindの説明はありません。原文で読むとなんとなく判ってきます。

整理しておきます。

Entity (エンティティ)
	App Engine データストア内のデータ オブジェクト。
	key と プロパティ がセットされる。
	リレーショナルデータモデルで言うところのタプル。
	RDBMSで言うところの行、レコード。
	Javaでデータモデルを定義し、そのモデルのインスタンスを生成してDatastoreに保存したら、それがエンティティ。

プロパティ
	名前のついた値。Entityには1つ以上のプロパティがある。
	そのデータ型は整数、浮動小数点値、文字列、日付、バイナリ データなど。
	Javaでデータモデルを定義したデータクラスのフィールドと(ほぼ)同義。

データクラス
	Javaでデータモデルを定義たクラス。

kind
	正確にはEntity's kindでしょう。
	Datastoreに保存されたエンティティのデータクラスの種類。
	リレーショナルモデルで言うところのスキーマ。
	RDBMSで言うところのテーブル。