デジタル教科書教材協議会の設立シンポジウムをUStreamで見ました。（iPhone、iPadはこっち）
孫正義さんの話は、先日の光の道の討論の時の話と重複する部分が多かったですが、改めて、子を持つ親の立場として教育の改革の必要性を再認識させられました。
それより驚いたのが、パネルディスカッションでの藤原和博さん（東京学芸大客員教授らしいですね）の話。この人すごいですね。
いや、よう説明せんです。オトーサン、オカーサン、センセー、ここだけでも見てみてください。
slim3での1対多関連（片方向でも双方向でもどっちも）での参照整合性の話です。
親モデルが削除された時 Datastore#deleteで親モデルを削除した場合、子モデルにセットされている関連（ModelRef< 親モデル>）は消えない様です。(2010/07/30修正)
RDBMSのいわゆる参照整合性制約での ON DELETE NO ACTION に相当する仕様みたい。
ON DELETE CASCADEとか、ON DELETE SET NULLとか、SET DEFAULT とかは出来ないようです。
ON DELETE CASCADEにしたい場合は、Datastore#deleteAllで親モデルを削除すると、子孫モデルは連鎖削除されるようです※。
※ひがやすをさん、コメント有難う御座いました。
制約が必要ならアプリケーション側での実装することになります。
残念。
あんまりメンドクサイようならがんばってissueを投げてみよう。
参照整合性は連鎖削除のみサポートされていて、ON DELETE SET NULLとかSET DEFAULT は出来ないようです。多分。
コンシューマ向けのWEBサービスの場合は通常はコレで十分でしょう。
(2010/07/30修正)
※後で確認しましたが、参照整合性の連鎖削除（deleteAllで子孫モデルも削除）
を実現するには、親と子孫エンティティを同じEntityGroupにする必要がある様です。
つまり、slim3の機能としての「リレーション」だけではやはりダメで、
EntityGroupを併用する必要があるようです。
(2010/07/30追記)
でも、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社のベンダーに縛られない」の裏には「組み合わせの制約で更改しにくい」というデメリットが存在した。
…
メリットを追い続けてとにかく作り続けた結果、振り返ればオープンシステムはレガシーとなって企業を苦しめている。しかし、開発コストとスピードを考えるとメインフレーム時代には戻るのは現実的ではない。
同記事は、「オープンレガシーを救う七つの鍵」をこの様に挙げています。
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!ニュース
かなり回りくどい表現をされていますが、要するに「携帯キャリアは儲かってるけどテレビ放送事業者は儲かってない。電波オークションなどで稼げる分野（業界、企業）にリソース（電波）をうまく配分しましょう。」という所でしょうか。
今まで、電波の無駄遣いの事は知ってるつもりだったけど、電波利用料ってのがあるんですね。
通信事業者は放送事業者に比べて数倍支払っているとの事です。
たしかに事実上の電波税ですね。
今度調べてみよう。
