今の所、Google App Engine for java でWEBアプリケーションを作ったとしても、既存サービスからの移行の場合にはデータの移行という最大の関門があります。
Python版ではデータのアップロード/ダウンロードが出来るそうなのですが、Java版は未だです。
やっぱり自作せなダメなんでしょうか。面倒です。
データストアへの保存自体はTaskQueueを使うとしても、30秒ルールがあるからあまり大量のデータをアップロード出来ないだろうし。
移行データに大量の画像が含まれている事が、最大の悩みです。
原則1Entityの最大サイズは1MB、画像は適宜リサイズが必要になるでしょう。
Blobstoreで解決できる。1オブジェクトのサイズ上限は2GB。
それに、既存コンテンツのimgタグの書き換えも要ります。
うーん、弱りました。
一応メモっとこ。
ビンボなんで管理サーバの無いスタンドアロンなOracleを立てて、バックアップをリモートのWindows機で取る、なんて運用を結構します。
DOSバッチファイルはこんな感じです。
RMAN target sys/pass@dbname @C:\pathtobatch\rman.txt log C:\pathtobatch\rman.log
rman.txt の中身はこんな感じ。
run {
allocate channel Channel1 type disk format 'C:\path\to\backupset\bk_%u_%p_%c';
backup ( archivelog all delete input );
backup ( database include current controlfile );
}
allocate channel for maintenance device type disk;
delete obsolete device type disk;
DBAもいない現場では最低この程度を日次でやっといてもらう事でサイアクの事態だけ防ぐです。
小規模システム超モノグサ運用むけ。
ちなみにこの方法だと最新のバックアップListを含んだ制御ファイルが取れてないので、良い子は別途制御ファイルのバックアップを取りましょう。
無くてもなんとか不完全リカバリできるけど、Point In Timeなリカバリが出来なくなっちゃうので。
開発機でOracle の RMAN (Recovery Manager) でアーカイブログのバックアップを実行しようとするとエラーになった。
RMAN-06059: expected archived log not found, lost of archived log compromises recoverability ORA-19625: ファイルXXXXXの識別中にエラーが発生しました。 ORA-27041: ファイルをオープンできません。
OSから手動でアーカイブログを削除した事が原因らしい。
(制御ファイル中のlistと実ファイルが矛盾する)
バックアップの前に、
crosscheck archivelog all;
を実行すればOK。
参考サイト
[Oracle] RMANでのバックアップ実行時にアーカイブログファイルの識別エラーが発生する｜Archive Redo Blog
これは土地利用でいえば、土地を細分化しないで高層ビルを建て、サービス業者はその部屋を借りて営業するようなものだ。こうすれば土地の高度利用が可能になり、サービスが失敗しても店子が交代すればよい。たとえばアメリカで700MHz帯を落札したベライゾンはLTEを採用し、他のサービスはLTEを使って行なわれる。これは今後の世界標準になると予想されているので、放送サービスも汎用の携帯端末で行なえばよいのだ。
ところが総務省は、いまだに特定の周波数に特定の技術を割り当て、帯域ごとに固有の業務用無線にしようとする。これは一つの土地を細分化して一戸建ての家を建てるようなものだ。土地の利用効率は悪く、失敗しても他の人がその土地を使えないので、遊休化してしまう。土地より悪いのは、遊休化した不動産を転売する市場メカニズムがなく、地代もないため、失敗した業者が居座ってしまうことだ。
電波行政はなぜ失敗するのか
酷い話です。
問題点を要約するとに、従来の電波行政のまま、お上が限られた電波帯域を特定の用途（主に放送局）に割り当てる方法は、電波の利用効率としてはきわめて非効率だからイカン、と。トップダウンが上手くいかなくなってきた。
それに国際標準化への準拠への観点からも、日本独自方式を作り出して国際標準化へ提案するというアプローチで過去に失敗を繰り返しているのだから、はじめから国際標準化の動向に協調する方が、利用者にとってメリットが大きい、と言う話です。プロダクトアウトだけでなくマーケットインの視点も大事。
地デジ移行後の周波数再編がとっても心配。
この記事、
少し前に社内向けに作ったプレゼン資料と内容が凄くかぶっています。
だから、我が意を得たりと言うか、ちょっと嬉しくなりました。
特に、
・ネットサービスはローンチ後にスピーディーに改善を積み重ね
なければならないため、内製化が鍵。
ここは激しく同意です。
産み出す苦しみより、育て上げる難易度の方が遥かに高いです。
最初に外注で作ってしまうと楽だけど、内製できる技術力が無いからといってそれをすると、自分たちで保守出来ない様になる危険性が高いです。
極端な話、ボタン1個増やすのに見積もり取って稟議あげて・・・とかあほらしい事になる。
それならば少し遠回りでも、基本的に自分たちで作る、足りないパワーはうまく外のマンパワーを借りるとか、SaaSと連携するとか、コアな部分だけを内製する努力をする方が良い。
・twitterやiphoneの良さは企画書や口頭の説明では解らない。
プロトタイプ（試作品）を造れるのがエンジニアの強み。
これも激同です。
私の言い方ではWEBサービスは特にウォーターフォール型よりアジャイル型、スパイラルアプローチでの開発が向いている、となります。
反応を見ながら作っていく事が大事。時には壊して作る。
ユーザ自身も、経営層も、そして開発者や企画者も、実は何が欲しいのか、何がユーザに受け入れられるのか、事前に判っていない。
ユーザにニーズを聞いてから作ると、極端な話しょーもないモンが出来る。
大勢で相談しながらみんなで仕様を練り上げると、無駄が多く高機能な割には焦点がぶれまくりとか性能が悪いとかのアホなシステムになってしまう危険性が高い。
プロトタイプか、最低でもモックアップがありきで、それをたたき台にしてブラッシュアップしていく方法の方が良いです。この方法で議論を大勢でするのは大いに結構。
それでも、ユーザが知覚する情報、デザイン、コンセプトの一貫性は、誰か一人が責任を持つ事で担保した方が良いです。
船頭が多いと船が山を登る事があると聞いたことがあります。
・ソーシャルアプリ、クラウドによってより小資本でスピーディーに
事業を立ち上げられるようになった。
ですよね。
だからといって起業する程身の程知らずではありませんが、中小企業ほどクラウドを活かさない手は無い。
・スマートフォンの急激な伸びによる新たな事業機会
スマートフォンに加えてiPadのようなタッチパネルでタブレットなデバイスが伸びるでしょう。何故なら、情報を消費するだけの普通の人々にとって、パソコンなんて判りにくいモンを使わせようと言う事自体が間違ってます。
これらのデバイスの普及は、デジタルデバイドがある程度解消されるチャンスです。
もうちょっと普通の人向けのサービスが求められるんじゃ無いですかね。
最大の問題は、どうやってマネタイズするかですね。
WEBサービス単体で利益を上げるのは、バンドマンがメジャーデビューする事よりも難しい。