2010-07-25

あたたたた・・・・・

動画編集って難しいな。ソフトとの相性かな。
そもそもネットブックに毛が生えたようなものでやるもんじゃない。

とりあえずは動画出来たし、開発に戻りますか。

なんかなー・・・
オブジェクトごとのデザインがバラバラで整ってないような気がするな。
でもアプリは自由に作れるようにしたいし・・・
別の方向からデザインの統一って所を考えて反映出来るようにするのが課題すね。

あとは、、アプリをどんどん作るのと、
その前にパフォーマンスのチューニングを何とかしよう。
まだコード量が爆発する前にやっておいた方がいい。
それに基本的なフレームワークの部分も、もっと固く修正していこう。

2010-07-10

Cloud 系OS まとめ

youOS http://www.youos.com/

MIT卒業生４人が作ったウェブOS。2006年の時点で既に登場していたが現在は終了している様子。2006年でこの思想を形にしているという事に驚く。このアプリの登場がウェブOS開発のスタートなんだろうか。

youtube http://www.youtube.com/watch?v=AH58sDjF2zc

eyeOS http://eyeos.org/index.php?p=whatiseyeos_tryitnow

バージョンとして stable の 1.x と、beta の 2.0 が存在する。1.x の方はyouOSと類似していてデスクトップと同様な形をまねている。2.x の方はウェブOSとして新しい形を表現しようとしたのか、iGoogleのようなブロック単位のドラッグアンドドロップの移動がベースになっている。とても完成度が高い。

youtube http://www.youtube.com/watch?v=G7KEVAyMDkE&feature=fvst

iCloud http://os.icloud.com/

最近知ったOSで、こちらの完成度もとても高い。デザイン性の高さを売りにしているだけあって、個々のアプリの作りこみも相当なもの。ロードやアプリが重いのが欠点だが、とても可能性を感じるOS。

youtube http://www.youtube.com/watch?v=qpRMbtGpDwc

Pip.io http://pip.io/

ウェブOSというか、ソーシャルをOSの上に乗せてみた感じのもの。ソーシャルを中心に人々の行動が行われるという事で作ったのか。とても興味深い。デザインも良い。

youtube http://www.youtube.com/watch?v=Ud4rb1zLNHM

その他の関連サービス

CorneliOs http://www.cornelios.org/

Glide OS https://account.glidesociety.com/register/default.aspx

Xcerion http://www.xcerion.com/

Jolicloud http://www.jolicloud.com/

Live Mesh https://www.mesh.com/welcome/default.aspx

Goowy http://www.goowy.com/index.aspx

Craythur http://www.craythur.com/

おわり

クラウドという言葉がどうと言うのではなくて、個人的にリソースとアプリのほとんど全てをオンラインで持つという事が、これまでインターネットが見てきた未来そのものの様な気がする。暫くはローカルとの使い分けで、ローカルストレージの重要性がさらに上がってくるとは思うが、ただクラウドというような状態に向かうのは間違いないと思っている。

2010-06-27

( ╹◡╹) ちょーやばい

今月いっぱいでデザインを一通り終えるはずだったのに・・・来月の第１週までかかるな。
デザインと言うのもおこがましいですけどー。

どの口がデザインというんだ、自分よ。いくらなんでもこれはひどすぎだろ。。
海外のホスティング環境構築は会社の人雇うって、自分の中で決まってるようですし・・・、それであれば来月はちょっと機能追加の開発時間を確保したいな。

あー。。動画、どうしよう。買って以来数回しか開いていないMacブックを開いて、入っているであろうiMovieで作れるかな。簡単に作れればいいけど。
さて、定時退社ウィークになる予感だ。

2010-06-13

画像つくってる

VMwareのNAT接続も出来たので、外で開発したりも出来るようになった。
NAT接続の方法は後でメモがてらアップしておこう。既に忘れてるという噂が脳内を全力疾走しておるがね。

デザイン期間という事で色々ペタペタしてるけど、結構画像作れるもんだな。
天気パーツの天候画像とか、スマートフォンっぽい画像がほしくて自分で作ってみたけど結構作れちゃうもんだな。ネットに感謝だ。

結構それっぽくなってるような・・・・ん、いんじゃないかな！
左が晴れ時々曇りで、右がとりあえず雨っぽい感じを試してみたやつで・・・
んー、水滴の感じがもっとうまく出せればな。量を増やせばいいのかな？色々やるしかないか。
でも、、背景黒じゃないんだよねー・・・雰囲気変わっちゃうかな・・・

とりあえず明後日までに天気パーツをかたずけて、finderのデザインをやらないと。
あ、あと動画作りの調査とかしないと。youtubeに高画質でアップする方法とか、多分アップしてテストしまくらないとダメかな。。

やばいーっ。やばいー。

肩いたいー

2010-05-24

ねる

新しいノートを購入したので、開発環境を移動させた（開発環境＝VMware）。
持ち運ぼうと思ったらホストから仮想環境への直接アクセスができない。んん？
ブリッジ接続してるから当然か。これはNATにしてやればいいのかな？あれこれ悩んでると開発時間が削られそうだ、週末にやってみよう。

なんだか本当に自分用メモになってきた・・
とりあえず、いま開発中のものは今月いっぱいでプログラム的なものは一旦切り上げて、来月からはデザインや画像作成に入りたい。というか入らないと多分間に合わない。機能とか全然足りてないけど。。

予定をメモしておこう。
５月：機能開発の一旦終了
６月：画像・デザインの対応
７月：レンタルサーバ確保と構築
８月：動画作る
９月：微修正？
１０月〜機能開発再開

いや、やばいな。
レンタルサーバ確保と構築がハマりそう。見積もれない。。
いざとなったら会社の人を雇うか。とりあえず、、有給使おう。

もっと技術力がほしいな。特にサーバ周りだな。
環境構築をサクサクできるくらいには早くなろう。な？自分。

もう一人自分がほしい。

そしてぶん殴りたい。

2010-04-04

タイムスタンプの管理について

mysql

DB

仕事で Oracle を２年程やっていたので、MySQL のタイムスタンプ管理が結構面倒だなと感じてしまう。（単に自分の技術力がまだ浅いだけなのかもしれないが

タイムスタンプ

通常テーブルにはシステム領域として、作成日、更新日、作成者、更新者、論理削除フラグ、あたりを保有するかと思う。MySQL は時間を扱う型に TIMESTAMP 型を持っていて、時間をこちらで入れる必要がなく、勝手に更新してくれる。なので初めて MySQL をやる人は結構頭を傾げるんじゃないだろうか。しかも、更新してくれるのは、テーブルの中で初めて出てくる TIMESTAMP 型のカラムだけ。何だそれは。。
つまり INS_YMD, UPD_YMD の並びで TIMESTAMP を定義したら、更新の度に INS_YMD が勝手に書き変わる。だから UPD_YMD, INS_YMD の並びにして定義するのが方法の１つらしい。

UNIX_TIMESTAMP

そもそも UNIX のタイムスタンプで管理した方が楽なのかもしれない。と思って調べたら。いい情報を見つけた。
MySQLで DATETIME型のデータを高速に検索する方法
つまり　UNIX_TIMESTAMP を利用する事で、DATETIME型より3倍〜4倍高速化をする事が出来るらしい。デメリットとしては人が直感的に理解しづらい事。おｋおｋ、そんなのいいです。

表示の場合

UNIX_TIMESTAMP() で insert したデータを実際に表示する時のフォーマット化は、FROM_UNIXTIME() を利用する。日付フォーマットは MySQL リファレンスを参照。

例) FROM_UNIXTIME( UPD_YMD, '%Y/%m/%d %H:%i:%s')

※ UPD_YMD に UNIX_TIMESTAMP が入っているとする

システム領域を必要しないであろうテーブルにも、考えなしで付けたりしてるけど、個人的には要らないなら付けたくない。やっぱり付けとくのがあるべき姿なのかな。。レコード数でかいと結構喰うと思うけど。。

2010-04-03

jQuery droppable の複数要素が重なった場合の問題

javascript jQuery

第５回ジオメディアサミット

東大駒場キャンパスで開催された「第５回ジオメディアサミット」行ってきた。特に地域情報とかソーシャルのサービスを担当している訳じゃないんですけど、誘われて面白そうだったので。色々試作サービスも見せてくれて楽しかった。古地図アプリ多分買うな。

本題の jQuery

今製作中のもので派手にハマッたので、今後バージョン上がった時に対応が必要になるかもしれないのでメモをしておく。対象箇所は jQuery UI の droppable 系（jquery-1.4.2 + jquery-ui-1.8）。

はじまり

jQuery UI で、指定要素に doroppable を指定してドロップ領域を作成する。ここまでは問題なし。問題なしどころか実装が簡単すぎて涙がでそう。一般的なアプリならここで終わるので特に問題はない。問題となるのは異なるドロップ領域がレイヤーとして重なっている場合。

こちらの想定としては、オレンジ色の部分にドロップしたらオレンジへのドロップ、青い部分にドロップしたら青い部分へのドロップとしたいし、それが普通だと思うんだけど、jQuery.ui.droppable は内部的に硬いやり方をしていて、交差した黒い部分へドロップすると、オレンジ色へのドロップと認識されてしまう（※オレンジ、青の順に作成した場合）。なんだ、と。

理由

３日前に書いた自分のコードでさえ見たくないのに、ましてや jQuery のライブラリとか見たくないんですけどオーラ全開でソースを見てみた訳で、、、結論から言うと確認した範囲で以下の流れで処理されるようだった。

droppable 実行
対象の要素情報を内部配列にpush
drop イベント発生
内部配列をループさせて drop 位置が要素の領域内であるかを判定
最初にヒットしたものを drop 対象とする

っざけんな！！！

大切な事なのでもう一度、っざけんな！！！

つまり、複数のレイヤが画面上の同じ領域を含んでいて、そこに drop した場合、droppable でドロップ領域化したのが早い方のレイヤに drop が持ってかれるって事みたい。設計時の考慮漏れ？それとも別のやり方があって自分の認識不足？結構調べたけどそれらしい情報は見つけられなかった。

対応策

jQuery UI の該当箇所を修正する。
custom 版を使っていたのでそれを元に書くけど、修正場所は $.ui.ddmanager だけでよさそう。droppables.default が droppable オブジェクトの格納配列で、対象要素の情報も含まれている。で、さらに修正ポイントを絞ると、$.ui.ddmanager._drop の関数。

drop: function(draggable, event) {

	var dropped = false;
	$.each($.ui.ddmanager.droppables[draggable.options.scope] || [], function() {

		if(!this.options) return;
		if (!this.options.disabled && this.visible && $.ui.intersect(draggable, this, this.options.tolerance))
			dropped = dropped || this._drop.call(this, event);

		if (!this.options.disabled && this.visible && this.accept.call(this.element[0],(draggable.currentItem || draggable.element))) {
			this.isout = 1; this.isover = 0;
			this._deactivate.call(this, event);
		}

	});
	return dropped;

これを以下の様に修正した。

drop: function(draggable, event) {

	var dropped = false
		 ,max_z = -1
		 ,_that, z, trgt, pos
	;

	$.each($.ui.ddmanager.droppables[draggable.options.scope] || [], function() {

		if (!this.options) return;
		if ( !this.options.disabled && this.visible ) {

			// get z-index
			trgt = this.element;
			z = ( ( trgt.css('zIndex') == 'auto' ) ? 0 : trgt.css('zIndex') ) || 0;

			// 最大z-indexのものを処理対象にする
			if ( z > max_z ){

				// 対象要素の位置	
				pos = trgt.offset();

				// ドロップ位置に要素が重なっている場合処理
				if ( pos.left <= event.pageX && event.pageX <= parseInt(pos.left) + parseInt(trgt.width())
				  && pos.top  <= event.pageY && event.pageY <= parseInt(pos.top) + parseInt(trgt.height()) ) {
					_that = this;
					max_z = z;
				}

			}

		}

		if (!this.options.disabled && this.visible && this.accept.call(this.element[0],(draggable.currentItem || draggable.element))) {
			this.isout = 1; this.isover = 0;
			this._deactivate.call(this, event);
		}

	});

	return (_that) ? _that._drop.call(_that, event) : false;

}

汚いコードだけど。。基本的に ui のコードに直接修正はやらない方が良いので、自分のコードでオーバーライドした方が良いです。修正ポイントとしては、配列に入った要素の中で最大のz-indexを持っていて、drop 場所を要素領域内に含む要素を処理対象としています（$.ui.intersect ここら辺とかを上手く使えばもっと良かったのかな）。

まとめ

jQuery とその周辺ライブラリの威力は大きくて、これまで独自に作ってきたものを桁違いのコストで置き換える事が出来るのは周知の事実。でもやっぱりライブラリ。細かい事を突き詰めると結局自分で手を入れる必要が発生する事もある。ライブラリに依存しきってしまってる人は悲惨だな。

binary-lifeの日記