Analytics のレポート表示期間を一発変更してみた

コンピューティング 作ってみた JavaScript

毎日 Google Analytics をチェックしては溜息ついたりしかめっ面したり、たまにニヤッとすることもある野良プログラマ兼細腕ウェブサービス運営者の Mariyudu です、ども。

レポートで前日のデータがすぐ表示されない件

さて、このほぼ毎日利用している Google Analytics ですが、レポートの表示期間が前日までではなく、その1〜2日前になってしまうことがあります。プロファイルのタイムゾーン等は日本に設定してるんですがねぇ。この件はヘルプフォーラムにも載っていて、回答にある「米国時間0時切り替わり説」に従うなら、それが東部標準時の場合、日本では14時にならないと前日のデータがデフォルトでは表示されないことになります。成程そんな雰囲気はあるみたいですが、私が Analytics をチェックするのは午前中が多いので、いちいち手作業で表示期間を変更するのが煩わしいんですよね。この辺、JavaScript とかで自動化できんか? と思い、ブックマークレットの作成を思い立ちました。

調べてみた件

簡単に経緯を少し。最初は、ポップアップで出てくる表示期間設定カレンダー横のテキストボックスに前日の日付を計算してブチこめばいいかな、くらいに考えてましたが、Analytics は全体的にハンパなく JS バリバリな Web アプリになっていて、静的 Web ページ操作レベルな付け焼刃は通用しないみたいです。もう少し調査を進めて、表示期間をクエリストリングに指定できるレポートの URL があることがわかりました。ページ左上付近の「マイレポート」に適用されているリンクです。この URL は

https://www.google.com/analytics/reporting/dashboard?dashboard=1&id=<プロファイルのID>&pdr=<期間開始年月日>-<期間終了年月日>&cmp=average

という書式になっているらしいのでこれを有難く使わせてもらうことに。

黙ってコードかけよ、な件

方針が決まったら後はガンガンコーディングっと。jQuery とかが使えないので若干ツラいですが。以下はそのコードです。何をやってるか等はコード嫁ということで(つかコメント添えました)。

(function(){
	// id="email_button_item" の td 内にあるリンク先からプロファイルの ID を取得
	var td = document.getElementById( "email_button_item" );
	var link = 0;
	for ( n=0 ; n<td.childNodes.length ; n++ ) {
		if ( td.childNodes[n].nodeName == 'A' ) {
			link = td.childNodes[n].getAttribute( 'href' );
		}
	}
	if ( ! link ) return;
	var id = (matches=/[\?\&]id=(\d+)/.exec(link)) ? matches[1] : 0;
	if ( ! id ) return;
	// 期間(前日から遡って1ヶ月)を計算
	var lastDate = function(d){return (new Date( d.getFullYear(), d.getMonth()+1, 0 )).getDate();};
	var d2 = new Date;
	var d1;
	d2.setTime( d2.getTime()-86400000 );
	if ( d2.getDate() == lastDate(d2) ) {
		d1 = new Date( d2.getFullYear(), d2.getMonth(), 1 );
	}
	else {
		d1 = new Date( d2.getFullYear()-(d2.getMonth()>0 ? 0 : 1), (d2.getMonth()+11)%12, 1 );
		d1.setDate( d2.getDate()>=(ld=lastDate(d1)) ? ld : d2.getDate()+1 )
	}
	// ページ遷移
	var pdr = ("0000"+d1.getFullYear()).slice(-4) + ("00"+(d1.getMonth()+1)).slice(-2) + ("0000"+d1.getDate()).slice(-2) + '-' + ("0000"+d2.getFullYear()).slice(-4) + ("00"+(d2.getMonth()+1)).slice(-2) + ("0000"+d2.getDate()).slice(-2);
	window.location.href = 'https://www.google.com/analytics/reporting/dashboard?id=' + id + '&pdr=' + pdr + '&cmp=averag';
}).call();

これをブックマークレット用に短縮したのが以下のごにょごにょです。

javascript:(function(){var td=document.getElementById("email_button_item");var link=0;for(n=0;n0?0:1),(d2.getMonth()+11) % 12,1 );d1.setDate(d2.getDate()>=(ld=lastDate(d1))?ld:d2.getDate()+1)}var pdr=("0000"+d1.getFullYear()).slice(-4)+("00"+(d1.getMonth()+1)).slice(-2)+("0000"+d1.getDate()).slice(-2)+'-'+("0000"+d2.getFullYear()).slice(-4)+("00"+(d2.getMonth()+1)).slice(-2)+("0000"+d2.getDate()).slice(-2);window.location.href='https://www.google.com/analytics/reporting/dashboard?id='+id+'&pdr='+pdr+'&cmp=averag';}).call();

どーぞ勝手に使って下さい責任は持ちませんがな件

使い方はカンタン。

  1. 上記のごにょごにょをお手持ちのブラウザにブックマーク登録
  2. Google Analytics にログインして、所定のプロファイルのレポートページを表示
  3. 表示期間が前日を含んでいなかったら、登録したブックマークを実行!!

ということで、同じようにお困りの方は試してみて幸せになって頂ければと。尚、このプログラムは公式アナウンスされたサービス仕様に基づいたものでは全然なく、勝手対応なので Google 先生のご都合により突如動かなくなるかも知れません。ご承知おきを。

ScraperWiki を使って勝手 RSS フィードしてみた

コンピューティング

なでしこジャパンやら政変やらで一喜一憂していた夏も終わりますね。という訳でこんにちは。今年の夏もバカンスともロマンスとも縁の無かった Mariyudu@セミの抜け殻状態、です。

さて先日、Web ページスクレイピング処理関連の作業をしていて、前に某ブログさんで知った ScraperWiki なるサービスを思い出し、道草というか、少し試してみることにしました。

ScraperWiki とは

ScraperWiki ってのは、文字通りスクレイピングプログラムを共有することで、Web 上にある有用なデータを皆で共有して幸せになろう、って主旨のサービスらしいです(About ページを参照のこと)。以下のような特徴があります。

  • Web ページ内のエディタ上でスクレイピング処理のプログラムを書いてトライ&エラーで実行きる。
  • プログラム言語は Python, Ruby, PHP から選べて、それぞれスクレイピングに必要なライブラリも用意されている。
  • スクレイピングして得られた結果は SQLite データベースに保存できる。
  • 保存したデータは SQL で自由に取り出して「ビュー」プログラムにより様々な形式で HTTP 出力することができる。
  • 書いたスクレイピングプログラムの実行をスケジューリングできる(最頻で1日1度)。

特にスクレイプ結果を DB に保存するあたりは、オブジェクトを丸ごと放り込むようなインターフェースの API が用意されていて、スキーマの構築も不要だわ複数レコードも一発格納だわ、恐るべきお手軽さです。

お題

さて、このサービスを試すにあたって課したお題は、私が以前から愛読させてもらっている「下町音楽夜話」という音楽エッセイ記事の RSS フィードです。このページ、古くからあるだけあって RSS フィードに未対応なのはもちろん(苦笑)、最新記事ページはフレームで個別の記事ページを埋め込んであるというように、記事の更新を検知しづらい構造になっています。これまでは、はてなアンテナで更新を知るようにしていたのですが、勝手に RSS フィードを作って愛用の Google Reader 上で他のサイトとまとめて購読できるようにしちゃえ、という目論見です。

実際にスクレイパーを作ってみる

じゃあ、サービスが英語表記のみということもあるので、RSS フィードに至るまでの手順を簡単に説明しましょうね。まずは、ScraperWiki のトップページ右上から [Log in] > [Create an account] と辿って(下図)、ユーザ登録します。

では、スクレイパー(ページをスクレイピングして結果を DB に保存する処理)を作成してみましょう。ダッシュボードページ右側の「New scraper」をクリック(下図マル1)すると、使用する言語を選択するポップアップが表示される(下図マル2)ので、好きな言語をクリックします。私は Ruby を選びました。

するとスクレイパーのエディタページに遷移します。ここでコードを書き(下図マル1)、「RUN」ボタンをクリックして実行することができます(下図マル2)。私が書いたスクリプトがここから閲覧できるので、ご参考までに。

スクレイパーが書けたら保存しましょう。ダッシュボードページで DB に保存したデータをプレビューしたり(下図マル1)、実行スケジュールを設定したり(下図マル2)できます。

前述のようにスクレイパーは結果を DB に保存する役割のコードなので、これに HTTP 経由にて何らかの形式でアクセスできるようにするには「ビュー」というコードを対で書く必要があります。手順は、スクレイパーと同じようにダッシュボードページ右側の「New scraper / view」の「view」をクリックしてビューのエディターページに遷移します(下図)。ここで同様にコードをかいて、適宜実行という手順でビューを完成させます。私が書いたビューはここです。

ビューを完成させたら、ダッシュボードページ上部の「Click to open this view」をクリック(下図)することで公開用の出力が表示されます。上記で提示した私の書いたものの URL は、https://views.scraperwiki.com/run/shitamachi_ongaku_yawa_rss/ となっています。

以上です。スクレイピングの一連の作業が全てブラウザ上でできるので、とても使い勝手がいいですね。コードはそれぞれの言語やライブラリに属することがらなのでここでは特に触れませんが、唯一ハマった箇所として、ビューを XML 形式で出力する際にどうしても末尾に広告バナー(?)の div が付加されてしまう件がありました。これはサンプルコードにあるように

ScraperWiki.httpresponseheader( "Content-Type", "text/xml; charset=utf-8" )

と Content-Type を XML と明示してやる(デフォルトは HTML)ことで回避できます。ScraperWiki 謹製のライブラリについてはドキュメントページを参照して下さい。

オチ、というか後日談というか

さて、こうして「勝手 RSS フィード」はいちおう実現できたのですが、これを Google Reader に登録してみたところエラーになってしまいました。内容が悪いのかと、出力された RSS をダウンロードして自分のサーバに置き、それを登録してみたところ問題なかったので SSL でのフィードを Google Reader が扱うあたりに何か不具合があるのかもしれません。結果として当初のミッションは達成できなかったことになりましたが、ScraperWiki を試してみるという面では良い体験になりました。

尚、このサービスは Wiki と銘打っているように、公共性の高い情報に対してのスクレイピングを共有してこそ価値を発揮するサービスだと思っています。今回のチャレンジの目的は極私的なものでしたが、つぎは多方面に何らかの貢献ができるようなネタを考えてみたいと思います。

Re: iOSがAndroidより信頼性が高いと言われる本当の理由

コンピューティング

ちょっと気になる bLog 記事(↓)を見かけちゃったので、今回はそのトラバということで(別に反論という訳ではないです)。

愛と苦悩の日記 - iOSがAndroidより信頼性が高いと言われる本当の理由

この記事はおそらく、オープンソースソフトウェア(以下、OSS)やその開発者へではなく、ソフトウェア工学の都合の良い部分だけを都合よく解釈して吹聴する一部の「不誠実で声の大きな人達」への批判だとは思うのだけど、文中では批判の対象が「マイクロソフトが大嫌いなITの専門家」なのか「自称ITジャーナリスト」なのか明確でなかったんですよね。私はコンピュータ・プログラマを生業としている者なので一応 IT という方面の専門家の端くれと見るべきだし、マイクロソフトも嫌いなので「あ、何か言わなきゃダメかな?」と思いw 自分なりの「伽藍とバザール」観をまとめてみました。

まず、揚げ足を取るようで申し訳ないですが、誤解を招きやすい文章が多いように思うのですわ。

その一つに、Linuxはソースコード（プログラムそのもの）が公開されているので、Windows Serverよりもウィルスなどの不正なプログラムが混入されにくい。したがってWindows Serverよりもウィルスの攻撃に強い、というものがあった。

とか、

なので、たとえ誰かが悪意で不正な働きをするプログラムを忍び込ませても、あっという間に見つかってしまうし、誰かがLinuxの弱点を突くようなウィルスを開発しても、あっという間に誰かがその弱点を改善してしまう。

とか。これだとまるで、コンピュータ・ウィルスの実体が、プロダクトのソースコードに紛れ込まされた悪意あるコードであるかのように読めてしまうのではと。そういったケースは時々ありますが、それはそのまま「混入された悪意あるコード」等と表現され、コンピュータ・ウィルスとは呼ばれません。おそらく筆者の方は、プログラムの脆弱性の事を言いたかったんだと思いますが、そこは大事なポイントなので明確に書いて欲しかったです。

さて、エリック・レイモンド氏が「伽藍とバザール」の中で、ソースコードをオープンにした前提での共同作業によるソフトウェア開発方式(所謂バザール方式)において、「ウィルスの攻撃に強い」と言ったかどうかは知りませんが(すみません、原典を読み直している時間がなくて)、私としては主旨は「伽藍方式に比べて目玉の数(つまり関与するプログラマ数)が多い開発・保守体制を作り易く、そのぶん(脆弱性等も含めた)バグや不具合の原因となりうるコードが発見・手当されるチャンスが多い」ということだと解釈しています。これは例えば、OSS であっても少人数で開発されて誰のチェックも受けていないマイナーなプロダクトであれば、恩恵に預かれないということが分かります。つまり、バザール方式は「目玉の数」という一定の条件を満たした場合に長所を発揮する訳ですね。

「目玉の数」を左右する条件は、プロダクトの人気・不人気以外にも、ソフトウェア・プログラムとしての難易度等もあるんじゃないかと思います。高度な数学を用いて構築された理論の実装としてのソフトウェア(暗号や画像・音声処理等)は、プログラム言語が読めたからといって簡単に理解できるものではないので、それだけ関与できる「目玉の数」を制限することになるのではないでしょうか。こういった場合には潤沢な開発リソースを用意できる企業の方がむしろ「目玉の数」を増やせるのかもしれません。また自信はありませんが、暗号ソフトウェア等でアルゴリズム自体が堅牢性の要である場合には、ソースコード(=アルゴリズムの具体)をクローズドにした方が有利ということも考えられます。

また、ソフトウェアの品質はリリース時にすべて決定される訳ではなく、不具合が発見された後にどれだけ迅速な手当がなされるかというサポートの側面も大きいと思いますが、この点でバザール方式の方に安心感を覚える IT 関係者は多いのではないでしょうか。私自身、ずいぶん前の話ですが、マイクロソフト主催の開発者向けプログラム(有料)に参加した後で製品(開発用ミドルウェアの類)に不具合を発見、現象を報告したところ原因不明との解答をもらい、「んなこと言ったってこっちは納期があるんだよ!!」とブツブツいいながら調査を進めてどうやら特定箇所の日本語処理に原因がありそうなことまで推定できたので、対処療法的に問題を回避した、という経験があります。日本語処理の件は勿論マイクロソフトに報告しましたが、その後修正プログラムが出たという話は聞きませんでした。お金払ってバグレポートから原因調査までして、何やってんだか... これが OSS であれば、自分でソースコードを追いかけることが可能ですし、技術的に敷居が高い場合でもバグレポートを送ることで他者による手当が「期待」できる訳です。

というように、バザール方式は品質の高いプログラムを作る魔法の杖ではなく、ごく当たり前のスジ論に基づいたひとつの開発方式に過ぎない訳で、プロダクトの種別や開発期間・資金と様々なファクタを考慮に入れて開発方式の選択はなされるべき、という当たり前の結論に落ち着いちゃいました。

※あれ? iOS って Darwin を含んでるんでしたっけ? そうなら一部 OSS ってことだよなぁw

便利でちょっと賢い Web フィンガーボード「iFRET」始めました

作ってみた コンピューティング Webサービス

いやー、昨日からうって変わって過ごしやすくなりましたねぇ。ギターやウクレレなんかを弾くのにちょうど良い気候になってきました... てな訳でw そんな時にちょっと役に立つ Web アプリケーションを作ってみました。「iFRET」といいます。今回はその紹介を。

iFRET とは? (開発動機等)

ギターなんかを弾くようになって30年以上経ちますが、私の場合、楽譜をそのまま弾くというよりは、気に入った曲を耳コピーしたり自分流にアレジンして弾いてみる、という楽しみ方が多いです。そんな時いつも思うのが「ここはこう押さえると思うんだけど、何のコードだろ?」というもどかしさです。指盤上の音やコードの構成音が全部頭に入っていれば直感的に分かるのでしょうが、万年素人の悲しさとでも言いましょーか orz また、最近はブルーズやハワイアン方面にも食指を伸ばしつつあるので、レギュラーチューニングではない調弦で弾くことも多く、そうなるとコードフォームがちんぷんかんぷんになってしまうのも困りモノです。

さて、プログラマとしてこんな状況を要求分析すると

  • 様々な楽器・チューニングに対応していて、構成音を特定ポジションだけじゃなく指盤全体で教えてくれる、万能コードブックが欲しいっ。
  • 判っている音からコードを類推してくれる「コード計算機」みたいなものがあればいーよね。

てなソリューションとなるのではないかと。iFRET はその具現化を企図した Web アプリケーションです(下図)。使い方なんかは About ページをご参照下さい。


開発メモ (使用したミドルウェア等)

上で書かなかった開発動機として「そろそろ HTML5 の目玉機能である Canvas 要素を本格的に試してみたいな」というスケベ心がありました。という訳で、指盤は Canvas 要素によるビットマップとして実装してあります。IE は ver.9 未満だと excanvas.js で動作させるしかなく、極端に遅くなってしまうのが困りものでしたが、そこは全て Micro$oft が悪いのじゃ、とゆーことにしてしまいます。ではいつものように、お世話になったミドルウェアや Web サービス等を明記しておきます。

  • 今回はプログラムの殆んどがフロントエンド側(つまり JavaScript + HTML + CSS)で実装されており、サーバサイドはこれといった役割を担っていませんが、いつものように CakePHP を使用してます。
  • Web ページのレイアウトには、これまたお決まりの Blueprint CSS を。
  • Canvas 要素プログラミング用のライブラリには jCanvaScript を選びました。
  • そしてこれが無いと何もできない体になっちゃった... の jQuery。
  • ページのカラースキームは、colorapi さんのズバリこれからw

今後

当初はコードだけじゃなくてスケール(各種音階)も機能に含めようと思っていたのですが、そこは省略してリリースを優先しました。私自身、スケールで悩むことはコードに比べて圧倒的に少ないですし。また、公開してみて、世間的にニーズがあるようだったら初めて Google AdSense なんかも導入してみようと思ってます。サーバ代くらいは稼ぎたいのでw

それでは弦楽器愛好家の皆様、よろしくおながいしますぅー。

十徳ナイフな JavaScript ライブラリ、「Sugar」を使ってみた

コンピューティング JavaScript

今回も JavaScript トピックです(たまたまですが)。

JavaScript の穴ぼこ

先日仕事で、毎度お決まりな日時関連の JavaScript プログラミングをしてて思ったんですが、JavaScript のビルトインオブジェクトって「そろそろ何とかしてくれてもいいのに」って思うような欠落箇所がいくつかありますよね。Date の日時演算とか、String の各種エンコード/デコード等など。まぁ自助努力で何とかなるレベルの話なので、「自分ライブラリ」をシコシコこしらえたり、出来合いのライブラリやコードスニペットをネットでその都度探したりして、そういった穴ぼこを埋めている方が多いのではないかと思います。そんな貴方に朗報ですw 「Sugar」ライブラリ、もうこれで決まりです。

直観的で多彩、チェーン可能なメソッド群

Sugar は Andrew Plummer 氏が作成した、JavaScript のビルトインオブジェクトを拡張するライブラリです。自分は Sugar をまだ少し使ってみただけですが、メソッドの構成が実によく練られているな、と感じました。その場限りの必要性で積み上げてしまった「自分ライブラリ」だと、機能の重複や規則等の不統一でだんだん便利になるどころかカオスとファイルサイズだけがどんどん増えていく、てなことになりがちです(すんません、ヘボプログラマで)。その点、Sugar は、

  • メソッドの機能が網羅的でバランスが良い。
  • 命名やインターフェースが優れていて直観的。
  • jQuery のようなメソッドチェーンが可能。

という優れものなので、一度使ってしまうと手放せない十徳ナイフのような逸品です。jQuery と共に常に head タグ内に書いておきたいですね。

Date API の使用例

論より証拠。冒頭で触れた作業ってのは DB から取り出した YYYY-MM-DD hh:mm:ss 書式の日時文字列を、ヒューマンフレンドリな書式(OSX のファインダーみたいな)に変換する」というものだったんですが、これを Sugar を使って書き直してみます。こんな感じです。

/**
 *	与えられた 'YYYY-MM-DD hh:mm:ss' が、
 *	今日なら 'h:mm:ss' に、
 *	昨日なら '昨日 h:mm' に、
 *	それ以外は 'M月D日 h:mm' に変換して返す
 */
function easyDate( ymdhms )
{
	var d = Date.create( ymdhms ); // Safari だと new Date(ymdhms) でうまく変換できないので...
	if ( d.is('today') ) {
		return d.format('{h}:{mm}:{ss}');
	}
	else if ( d.is('yesterday') ) {
		return d.format('昨日 {h}:{mm}');
	}
	else {
		return d.format('{M}月{d}日 {h}:{mm}');
	}
}

うん。コード量が半分以下に減って、なおかつぐっと可読性が良くなりました。それにしても、jQuery を初めて使った時にも感じましたが、メソッドチェーンってドラッグのような常習性がありますね。普段なら関数にしちゃう少し長い処理でもワンライナーでバリバリ書いちゃいそうです。

Sugar には Date の他にも String (日本語変換や各種エンコード・デコードが充実!)や Number (Math のメソッドが多数移植されてて合理的)、Array、Object、Function、RegExp の拡張メソッドが多数用意されています。JavaScript 使いの人はすぐに使い始めて幸せになっちゃいましょー。

追記 : この記事を公開後、作者の Andrew Plummer さん( http://twitter.com/l_andrew_l )からツイッターで Mention を頂きました。元々は語学を専攻されていたとかで、現在は東京にお住いらしいです。どーりで String API の日本語関連機能がムチャクチャ充実してる訳だw

jQuery EasyUI を使いこなしてみる (ProgressBar 編)

コンピューティング jQuery

こんにちは。カッワーリーを聴きながら気分はパキスタン、で仕事中な野良プログラマ Mariyudu です。

jQuery EasyUI、スゲぇ

最近、いくつかのアルファブログでもちらほら取り上げられつつあるようですが、jQuery EasyUI っていう jQuery 用の U/I ライブラリが何気に凄いです。Web アプリのコントロールパネルなんかを作ろうとすると必要になるパーツやウィジェットがだいたい網羅されていて、ぱっと見た目は Ext JS みたいでもあります。グッドなのは

  • jQuery ベースなので、jQuery ユーザには学習コストが低くて他のライブラリとの併用も出来て嬉しい。
  • シンプルにできていて見通しが良く、困った時やちょっと変わった事をしたい時もさほど苦労しない。
  • ライセンスが GPL(商用ライセンスは若干の制限付)。

ってとこでしょうか。

欲しい所から使っていく

OSS を使うとき、私はそれがどれだけ自分の仕事にベネフィットをもたらしてくれるか? というプラグマティックな評価というか、取り組み方をしています。実際、このプロダクトを知ったのは、バーの中にパーセンテージだけじゃなくて任意の文字列を埋め込めるプログレスバーを探していた時でした。なので、jQuery EasyUI は多くの機能を持ちますが、今回はインストール(デプロイ)とプログレスバーの使い方を紹介します。

インストール(デプロイ)

EasyUI のドキュメントページには特別インストール手順等は無いようですが、デモページの HTML ソースを見ればどんなふうにデプロイすれば良いかは分かります。とはいえ、初心者向けに一応書き留めておきますね。まずは、サイトのドキュメントルートに「jquery-easyui-1.2.4」みたいな EasyUI 用フォルダを作成します。それからダウロードページから得た Zip ファイルを解凍して、jquery-1.6.min.js・jquery.easyui.min.js・locale・plugins・themes をEasyUI 用フォルダにコピーするだけで OK です(下図)。

使用の際は head タグ内に以下のように記述して下さい。

<link rel="stylesheet" type="text/css" href="/jquery-easyui-1.2.4/themes/default/easyui.css" />
<link rel="stylesheet" type="text/css" href="/jquery-easyui-1.2.4/themes/icon.css" />
<script type="text/javascript" src="/jquery-easyui-1.2.4/jquery-1.6.min.js"></script>
<script type="text/javascript" src="/jquery-easyui-1.2.4/jquery.easyui.min.js"></script>

プログレスバーの使い方

プログレスバーを使うには、配布元のデモページにあるように、div 等のブロック要素を用意して、クラスに easyui-progressbar を指定してやり、CSS でサイズを指定するだけです。jQuery UI のプログレスバーの様に初期化してやる必要さえありません。ただ、このやりかただとプログレスバーを動的に増やす場合等に「?」となってしまうかも知れないですね。プログレスバーを動的に作成する時はこんなふうにします。

// ブロック要素を生成して、適当な親要素に追加してやる
var pbar = $('<div id="PBar" class="easyui-progressbar" style="width:400px;"></div>');
$('#SomeBlockElement').append( pbar );
// プログレスバー初期化(バー内テキストの書式を指定したり、バーの色をデフォルトから変えたり)
pbar
	.progressbar({text:'処理その1 : {value} %'})
	.find('.progressbar-value').css('background-color','#fc6');

プログレスバー初期化の際に、バーのテキストを「処理その1 : 99 %」という書式に指定してます。また、バーの色はデフォルトだと濃いオレンジなので、これを変えたい場合は初期化後に生成された progressbar-value というクラスの要素について background-color を変えてやればいいみたいです。この処理の実例(下図)を http://mariyudu.net/labo/easyuiDemo に用意しましたので、ご覧頂ければと。

という訳で jQuery EasyUI、すっかり気に入っちゃいました。今後も継続的に他の部品など試してみるつもりでので、いいネタがあればまた報告します。それでは。

超簡単デプロイの fluxflex で WordPress サイトをサクッと立ち上げる

コンピューティング Webサービス

昨年から IT 系ニュースサイトで報じられていた fluxflex という新しいクラウド型ホスティングサービスですが、7月11日に正式ローンチしたようですね。

[参考] 簡単デプロイ、開発に没頭できるクラウドホスティング「fluxflex」正式版

私が興味を惹かれた、このサービスの特徴をかいつまんで挙げてみます。

  • Amazon EC2 上で構築されており、ほんの数ステップでアプリのデプロイを完了でき、スピーディに「使えるサイト」にできる。
  • GitHub との連携機能が用意されており、アプリ開発工程のブーストが期待できる。
  • オートスケール機能による負荷分散。
  • 既存の OSS (オープンソースソフトウェア)がいくつかラインナップに用意されており、ワンクリックでインストール可能。
  • 利用可能リソースやスケーリングで制限はあるものの、無料で3つまでのプロジェクト(サイト)を作成可能。

最後の二つはイイですね。もし CMS 的な OSS プロダクトが用意されているのであれば、必ずしも開発案件でなくともクライアントへの提案段階から幅広く利用することができそうです。確認してみたら WordPress 3.1.3 日本語版がラインナップにありますね。よしゃ!! という訳で、「fluxflex で WordPress サイトをサクッ立ち上げる」をミッションにして、試してみました。以下はそのおおまかな手順です。

まずは fluxflex のサイトへ Go !!。

ここでユーザ登録が必要ですが、Twitter や Facebook の OAuth が用意されているのでカンタンですね。私は Twitter 経由でサブスクライブしました。登録が済むとダッシュボードのページに遷移します。

左側の Your Projects に注目(図中①)。この段階で既に、これから構築しようとするサイトが Project として用意されています。これを使ってもいいのですが、Project 名はサイト URL の一部となるようなので、ランダムな文字列ではない、ちゃんした名前の Project を作ってみましょう。ボタン「Create A New Project」をクリックします。

適当な名前を付けて、プロジェクトを生成します。
さて、あとはプロジェクトで WordPress のインストールをするだけです。ダッシュボードの中で Setup > One Click Install と進むと Redmine や WordPress 等のプロダクト一覧が表示されます。

インストール作業で必要なのは、当該のプロダクトの「Install」ボタン(図中②)をクリックするだけです。数十秒程度でインストールが完了し、ページ上部に「Project is Available」と通知が表示されるので、そこの URL をクリックすれば WordPress の設定ページが表示されます。この後は WordPress のインストール手順に属する事柄なので割愛します。

ちなみに、これが上記の手順で立ち上げた WordPress サイトです(習作的なものなので何時まであるかわかりませんが)。

いやー、素晴らしい。謳い文句どおり、本当に数クリックで Web アプリケーションのビルド・アンド・パブリッシュが出来てしまいました。おそらく、ワンクリックインストールできるアプリケーションは今後さらに増えてくると思われますので、楽しみですね。今回ははじめの一歩だったので「この辺でカンベンしたるわ!!」ですが、未だ用意されてない OSS プロダクト(個人的には MODx あたりを希望)を fluxflex にデプロイ&シェアしたり、オリジナルの Rails or CakePHP アプリのデプロイなども試してみようかと思います。