Django nonrelプロジェクト終了

Django-nonrelプロジェクトが終了した。

DjangoでリレーショナルDBではないデータベースをサポートする目的で立ち上げられたプロジェクトだ。もっぱらGAEでBigTableベースのDjangoをサポートするためのプロジェクトと言った方がただしいだろう。

GAEはバージョン1.6となり料金体制も含めて比較的大きな変更が実施された。Pythonベースも2.5から2.7へ移管し、Djangoも0.96から1.2へと変更された。今回のプロジェクト終了宣言はこれらの変更に対して追従しているさなかの出来事だった。

PythonベースのGAEに対するアプローチはいろいろとあるが、ここで再度注目が集まるのは「Kay-Framework」だろう。現在2.7への対応は進行中であり、おおよその対応は済んだようだ。
実際に私も使っているが、Djangoの移植ではなく、「GAEでDjangoライク」というのがコンセプトであり、「D.R.Y」のルールにあるように、可能な限り既存のパーツを使うという点もうまくいっている要因の一つだろう。(実際にKAYで使用されていたJinja2は2.7サポートと同時に正式なライブラリに追加された)。また、日本発にも関わらずリリース当初からドキュメントやユーザーグループは日本語と英語の両方が作成されており、海外のユーザーも多い。Django-nonrelの終了に伴い、英語のユーザーグループには、「KAYはフィロソフィーがいい。いまこそKAYをもりあげようぜ」なんていう声があがっている。

PC98でマーケット制圧=>ガラパゴス化=>DOS/Vで全滅
IMODEで囲い込み=>ガラパゴス化=>スマホで全滅

「ものづくりは優秀、世界戦で負ける」が定番化しつつある日本。
はじめから英語によるコミュニティをつくるKAYのアプローチは、これからのスタイルだと思う。

ついでに、日本語サイトではドキュメントが出来てないので認知が進んでいないかもしれないが、英語版のサイトではExperimentalではあるが、Googleが開発した新しい開発言語「Go」によるGAEサポートが開始されている。
こちらも要チェックだろう。

MacでWindows7

メインの作業環境をWindowsからMacに変えてもう数年。
技術的に見ればOSXBSDベースのUNIXであって、日頃からコンソールでの作業も多いサーバーサイドな人からすれば、わざわざWindowsを使っている必要が殆どなくなってしまった。Office for Macもインストールしたし、メールやカレンダー、住所録等はクラウドにあるしと、いまでは完全にWindows離れしてしまった。

しかしである。唯一どうしてもWindowsに触らなければ行けない事がある。IEでのサイトチェックだ。こればかりは実際に見ないと分からない。HTML5が主流になろうと、21世紀になろうと相変わらずWeb屋を悩ませ続けるブラウザによる表示の違いだ。
その度にマシンを起動してチェック等をしていたが、そろそろ仮想マシン使おうと思い立ち、今更ながらMac上に仮想化ソフトを導入して、Windows7をインストールした。

VMware Fusion 3

VMware Fusion 3

MacWindowsを動かすにはParallels Desktopというソフトも有名だが、やはり実績と知名度VMWareを選択した。
VMWareのインストールは15分程度で終了。あっというまだ。


VMWareは64Bit版のWindowsもサポートしている。購入したWindows7のインストールディスクをMacに挿入する。


ディスクの容量や各デバイス等の設定は後に、仮想マシンの設定で調整できるのでここは簡易インストール。
Wizard形式の項目にユーザー名、パスワード、シリアルナンバーを入力する。
ほどなくしてインストーラが起動し、処理が始まる。

待つ事30分程度。インストールが終了。
あまりにあっけなくてつまらないくらいであった。
実際に稼働させてみても、ストレスを感じるどころか、フルスクリーンにすると仮想マシンということを忘れそうだ。DirectX等もサポートしており、3Dゲームも動作するくらいだ。

VMWareの出来のよさもさることながら、マルチコアなCPUや大容量メモリなど、ハードウェアの革新が大きい。やはりクラウドの起爆点はこの「仮想化が実用化出来る程のハードウェア」が安価になったことだと再確認した。

ますます、Windowsマシンを触らなくなりそうだ。

Chromeウェブストア

GoogleのアプリマーケットプレイスChromeウェブストア」が日本向けにリリースされた。
このサイト自体はアメリカ向けに2010年末からリリースされており、既に3000以上のアプリが登録されているが、今回は日本語向けのリリースとしてはてなブックマークや47NEWS等の日本製のアプリが投入された。

マーケットプレイスの最大の機能である「告知」と「課金」。残念ながら今回日本では課金サービスは提供されていない(欧米向けには既にスタート)。また、日本向けの課金システム等のリリース予定などはいまのところ未定とのことだ。

Googleの方針としては独自の決済システムの提供にこだわらず、各ベンダーが課金システムを提供するのも自由との事。Chromeウェブストアでも課金で囲い込むつもりは無いようで、Googleはアプリの登録料金として5$程度の登録料を徴収する予定。これはGoolge Appsのマーケットプレイスと同じ要領だ。この点はAppStoreとの大きな違いだが、利用者が増えてAndroidマーケットのようにカオスな状況に陥れば、マーケットプレイスブランディングも落としかねない。とはいえAppStoreの厳しい制限や値下げの嵐に疲れたという方も多いだろう。

GoogleAppsマーケットプレイスでもGoogle Checkoutを経由するBilling APIがようやく公開されたが、英語のみの情報なので苦手な人には厳しいかもしれない。いずれにせよ、Googleの日本向けのマーケットプレイスは遅れているのが実情だが、AppStoreにしろ他のマーケットプレイスにしろ、IT企業がもつ最大の課題「マネタイズ」のソリューションのひとつであることは間違いない。

Chromeウェブストアで販売が開始されたものの中に「Installable Web App」というものがある。HTML5でストレージやファイルが扱えるようになったことと、Ajax技術が発展したおかげで、サーバーに設置するのではなくローカルファイルだけでアプリを実現出来るようになった。これをパッケージとしてブラウザ(Chrome)向けに提供するというもの。
HTML5時代に突入する中、新しいアプリの提供方法といえるだろう。

EXTJS4 Beta1

ExtJS4 Beta1がリリースされた。

構造的な部分も含めた書き直しが行われ、大幅なパフォーマンスアップをうたっている。

やはりというか、最も注目が集まるのはHTML5への対応だ。IE9のリリースでようやくHTML5の環境が整ってきたこともあり、今後の開発はHTML5への移行が当然となるだろう。

HTML5の恩恵としてこれまでにない変更が加えられている。
SVGの実装によりFlashが使われていたグラフエンジンもJavaScriptベースに書き換えられ、パフォーマンス、自由度も上がった。
■データプロバイダーがローカルストレージに対応。

Betaではあるが、デモをみる限り、これまでExtJS同様かなりの完成度だ。これまでExtJSを使っていた人にはお勧めである。


Ext JS in Action

Ext JS in Action

Flash Builder4 + ASDoc + Ant

Flash BuilderでASDocを使いたいと思い、いろいろと探したがどのサイトでも「外部ツール」としての登録による解説が多い。
しかしながら外部ツールでは以下のデメリットが発生する。

  • 個別のPCに依存してしまう(他のPCでは設定のやり直し)
  • 複数プロジェクトがある場合、個々に登録または随時設定変更する必要がある。
  • 他のチームメンバーと共有できない

さっと作るだけならそれでいいが、上記のデメリットは大きい。

せっかくFlash BuilderはEclipseペースなのに強力なantを使わない手はない。
antベースに移行することで以下のメリットがある。

  • ビルドファイルを個別のプロジェクト毎に作成できる。
  • ソースコード管理へ含められる(他者と共有できる)
  • 他の強力なAntタスクの処理と併用できる。

Flash BuilderにAntをインストールするための情報はたくさんあるのでそちらにゆずる。

antのexecタスクでasdocコマンドを直接起動する方法も多くのサイトで紹介されているがこちらの場合はパス環境等の問題を抱えることが多いようだ。


今回はせっかくなのでFLEX SDKにバンドルされているAnt用のAsDocタグを使った方法を紹介したい。

以下のビルドファイルを各プロジェクトのトップディレクトリに作成する。

build.xml
>||xml|






    




    



     








|

GAE SDK1.4.0

GAE SDK 1.4.0がリリースされた。

詳細な変更内容は記事にゆずるとして、全体でいえば「GAEの規制緩和」がメインであろう。タスクキュー(今回、ようやくExperimentalから正式採用へ移行)関連のほか、URLFetchやMemcache、Image, Mail等の各APIのサイズ制限が引き上げられた。
また、特筆すべきは「Always On」サービスだ。月額9$と有料ながら、インスタンスを3つまで常時稼働させるというオプショナルサービスで、初回稼働に時間がかかってしまういわゆる「スピンオフ」問題への措置だ。これはPythonな人よりもJavaな人に待望の機能だろう。もちろん、初期処理を短くする技術的なアプローチによる解決も引き続き必要だが、オプションでこういうサービスがあると安心だ。

また、GoogleTALKで使用されている環境と同等のものを提供する「Channel API」が新たに実装。クライアント、サーバー間に双方向なセッションを作るもので、チャットやマルチプレイのゲーム等に利用されそうなAPIだ。

全体としてはGoogleApssの現行仕様が規制緩和とともに「安定期」へ向かいはじめたと感じられる。Googleもリリース当初は様子を見るためにも厳しい規制を設けていたものを、実証とともに徐々に外して「通常利用」のレベルまでもってきたという感じだ。ロードマップをみても、機能的に大きな追加というよりは「改善」「利便性、機能性の向上」がメインである。(相変わらず独自ドメインSSLはトップリストだが)

今後のさらなる発展に期待したい。

ちなみに、このリリースは日本語記事で出ていますが、文頭で松尾さん(kay-framework)が翻訳したと書かれています。GAEの日本語情報がこのように流れてくるのもReal Googlerになられた松尾さんの「効果」でしょうね。応援しております。