2011年11月28日月曜日

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サポートが開始されている。


こちらも要チェックだろう。





2011年9月7日水曜日

MacでWindows7



メインの作業環境をWindowsからMacに変えてもう数年。

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

しかしである。唯一どうしてもWindowsに触らなければ行けない事がある。IEでのサイトチェックだ。こればかりは実際に見ないと分からない。HTML5が主流になろうと、21世紀になろうと相変わらずWeb屋を悩ませ続けるブラウザによる表示の違いだ。

その度にマシンを起動してチェック等をしていたが、そろそろ仮想マシン使おうと思い立ち、今更ながらMac上に仮想化ソフトを導入して、Windows7をインストールした。


VMware Fusion 3







MacでWindowsを動かすにはParallels Desktopというソフトも有名だが、やはり実績と知名度でVMWareを選択した。

VMWareのインストールは15分程度で終了。あっというまだ。

f:id:cypher911:20110906220201p:image:w640

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

f:id:cypher911:20110906220157p:image:w640

ディスクの容量や各デバイス等の設定は後に、仮想マシンの設定で調整できるのでここは簡易インストール。

Wizard形式の項目にユーザー名、パスワード、シリアルナンバーを入力する。

ほどなくしてインストーラが起動し、処理が始まる。

f:id:cypher911:20110906220150p:image:w640

待つ事30分程度。インストールが終了。

あまりにあっけなくてつまらないくらいであった。

実際に稼働させてみても、ストレスを感じるどころか、フルスクリーンにすると仮想マシンということを忘れそうだ。DirectX等もサポートしており、3Dゲームも動作するくらいだ。

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

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




2011年8月8日月曜日

Macでユーザー毎のPEARを構築

Mac[Lion]でPhingやPhpDocumentor等、PHPのツールを使用する必要があったためPHPのコマンドライン(CLI)環境を構築した。

PHP自身はもともとインストールされているものを使用し、システム関連の設定を変更することなく個人用の環境を構築する。

PEARのインストール

pearのホームは~/pearとする
その他PEARの作業用ディレクトリも作っておく

$ mkdir ~/pear
$ mkdir ~/pear/work

$ mkdir ~/pear/work/temp
$ mkdir ~/pear/work/cache

$ mkdir ~/pear/work/downloads

go-pear.pharを取ってくる。

$ cd ~/pear
$ wget http://pear.php.net/go-pear.phar

wgetコマンドがインストールされていない場合はPortsから取得
$ sudo port install wget

ダウンロードしたPharを実行
$ php ./go-pear.phar

各ディレクトリを聞かれるので以下を設定。もちろん値は自由だが以下は参考。

 1. Installation base ($prefix)                   : /Users/xxx/pear
 2. Temporary directory for processing            : /Users/xxx/pear/work/temp
 3. Temporary directory for downloads             : /Users/xxx/pear/work/downloads
 4. Binaries directory                            : /Users/xxx/pear/bin
 5. PHP code directory ($php_dir)                 : /Users/xxx/pear/php
 6. Documentation directory                       : /Users/xxx/pear/docs
 7. Data directory                                : /Users/xxx/pear/data
 8. User-modifiable configuration files directory : /Users/xxx/pear/cfg
 9. Public Web Files directory                    : /Users/xxx/pear/www
10. Tests directory                               : /Users/xxx/pear/tests
11. Name of configuration file                    : /Users/xxx/.pearrc

設定後php.iniを変更するかと聞かれるが後に設定するためNoを指定。

インストールを終了した後、環境変数の設定
$ vi ~/.profile
export PATH=~/pear/bin: xxxxxx <= 追加

反映
$ source ~/.profile
これでpear/bin内の各コマンドが実行できる。

以下のコマンドで現在の設定内容を確認できる。
$ pear config-show

各値を再度設定したい場合は以下のように行う
$ pear config-set キー名 値

例えばキャッシュディレクトリを変更する場合
$ pear config-set cache_dir /Users/xxx/pear/work/cache

これらの設定は各ユーザの設定がシステムの値を上書きするため
システム本来の設定にはなんら影響がない。

しかし、これだけではphp.iniのinclude_pathが合わないため
コマンドでエラーが発生する。
phpコマンドの設定ファイルの状況を確認するには以下のコマンド
$ php --ini (ハイフン2つ)

通常だと/private/etc/php.iniが読み込まれているはずだ。
sudo で設定を書き換えることもできるが、好ましくない。
よって環境変数によって個人用のphp.iniを読み込ませる。

オリジナルをコピー
$ cp /etc/php.ini.default ~/pear/php-cli.ini

include_pathを修正
$ vi ~/pear/php-cli.ini
...
include_path = ".:ユーザーディレクトリ/pear/php"
...

環境変数の設定
$ vi ~/.profile
export PHPRC=~/pear  <= 追加

変数を反映
source ~/.profile

これでユーザー用に作成したphp.iniをコマンドラインで読み込ませることができる。
確認は以下で、作成したファイルが読み込まれていれば完了

$ php --ini






2011年5月17日火曜日

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時代に突入する中、新しいアプリの提供方法といえるだろう。





2011年4月6日水曜日

EXTJS4 Beta1



ExtJS4 Beta1がリリースされた。


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


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


HTML5の恩恵としてこれまでにない変更が加えられている。


■SVGの実装によりFlashが使われていたグラフエンジンもJavaScriptベースに書き換えられ、パフォーマンス、自由度も上がった。


■データプロバイダーがローカルストレージに対応。


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






Ext JS in Action

Ext JS in Action










2011年2月19日土曜日

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 version="1.0" encoding="UTF-8"?>
<project name="OnyxPDF" basedir="." default="asdoc">


<property name="sdk.version" value="4.1.0"/>
<property name="sdk.dir" value="${eclipse.home}/sdks/${sdk.version}"/>
<property name="FLEX_HOME" value="${sdk.dir}"/>
<property name="src.dir" value="${basedir}/src"/>
<property name="doc.dir" value="${basedir}/doc"/>
<property name="lib.dir" value="${basedir}/lib"/>

<target name="asdoc">
    
<available property="flexTasksJar" value="${sdk.dir}/lib/flexTasks.jar" file="${sdk.dir}/lib/flexTasks.jar"/>
<available property="flexTasksJar" value="${sdk.dir}/ant/lib/flexTasks.jar" file="${sdk.dir}/ant/lib/flexTasks.jar"/>
<taskdef resource="flexTasks.tasks" classpath="${flexTasksJar}"/>

    
<asdoc output="${doc.dir}"
   lenient="true" failonerror="true"
warnings="false" strict="false" locale="ja_JP" fork="true"
main-title="ドキュメントタイトル"
window-title="ウインドウタイトル"
footer="フッター">
<doc-sources path-element="${src.dir}"/>

     


</asdoc>
</target>

<target name="clean">
<delete includeEmptyDirs="true">
<fileset dir="${doc.dir}" includes="**/*"/>
</delete>
</target>
</project>


プロパティ定義の部分は各自のプロジェクトの環境に合わせて変更する必要がある。


ここで注意したいのはsdk.dirおよびFLEX_HOMEのプロパティだ。


上記の設定はMac用に作成したもので、素直にSDKをインストールしていれば/Application/Adobe FlashBuilder 4/の下にFlex Sdkが展開されている。FlashBuilderのパスはexlipse.homeと同じなのでそれを使ってSDKのパスを指定している。


もちろん、SDKを独自の場所に設定している場合はそのパスを指定する必要がある。各PCでの環境依存を排除したいのであればbuild.properties等の別ファイルに記述し、それを読み込む(コメントアウト行)事で設定する。


このbuilder.propertiesのファイルをソースコード管理から外しておけばチームメンバーはそのファイルを修正するだけで利用することができる。


(このあたりはAntの活用方法なので他者にゆずる)


FLEX_HOMEというプロパティは必須プロパティで、必ずFlexSDKのパスを設定する必要がある。これは今回使用するasdocタグ等、Flex関連タグを使用する場合にこの名前でプロパティが設定されていないと実行時にエラーが発生する。


タスク定義の部分では、Flexのバージョンによってタスクタグのjarファイルの場所が違うため、availableタグを使って値を設定している。多くの場合は後者のパスなのでバージョンが固定されている場合はpropertyタグで直接定義してもかまわない。


その後のtaskdefタグで、Flex用のタグを読み込む。


asdocタグで重要な属性はoutputだ。こちらはドキュメントの出力先を指定する。


failonerror属性はエラー発生時に処理を中断するかどうかを設定。その他のlenient, warnings, strict等の構文解析の許容レベルを設定で、main-title, window-title, footer等は出力するドキュメントの各パートに表示する文字列を指定することができる。これらの設定の内容自体はasdocのコマンドラインオプションと同じなのでasdoc-help等を参照してほしい。


次にソースの指定だが、これはいくつかの方法があるが最も手っ取り早い方法は上記のようにディレクトリを指定する方式だ。


AsDocはある意味コンパイルすることと同じ処理を行うので、外部パッケージ等が解決できない場合はエラーが発生する。上記の例ではコメントアウトしているが、もし対象プロジェクトがswc等を使用している場合はexternal-libraryで指定する必要がある。また、AIRのライブラリを含めている場合は2番目の例のようにしてAIRのライブラリを取り込む必要がある。


AsDocの処理は重いためメモリが足りなくなる場合がある、その場合はjvmargタグで-Xmx512m等と調整すると解決できるかもしれない。





以上、ざっとした解説ではあるが、プロジェクトのASDocをantベースで生成するには上記のビルドファイルでも十分だろう。このasdocタグに関連する情報はネット上でも極端に少ない上、その設定は非常に多岐にわたる。(タグというよりasdoc自体のオプションが非常に多い)


より詳細な情報が欲しい場合は、FLEX SDKに含まれているSDK自体のドキュメント生成用のビルドファイルが非常に参考になるだろう。


$FLEX_HOME/asdoc/build.xml


その前に、ソースコードにコメントつけなければ何もはじまらないが(笑)